Проверяемый текст
Кахутин, Павел Викторович. Повышение качества системы поддержки принятия решений в технологической подготовке машиностроительного производства путем организации хранилищ данных (Диссертация 2004)
[стр. 150]

150 правило, сначала устраняются проблемы на уровне каждого источника данных, а после этого происходит очистка данных от ошибок, порождаемых множественностью источников.
Тестовое преобразование помогает проверить, насколько хорошо реализованные правила преобразования данных могут решить задачу их очистки.
Инструментами преобразования могут служить как поставляемые с СУБД ETL-средства, так и специально созданные программные средства,, имеющие доступ к извлеченным из различных источников данных.
Проведение полного преобразования данных подразумевает выполнение корректирующих процедур уже над всеми данными, которые предполагается добавить в ХД.
Противоток данных.
Эта процедура предполагает обратное перемещение очищенных данных в оперативные БД с целью улучшить состояние данных в источниках и не допустить повторного попадания тех же самых «грязных» данных в ХД при последующих его пополнениях.
Рассмотренные выше проблемы качества данных требуют обязательного решения, поскольку «грязные» данные, помещенные в хранилище, могут стать источниками неверных результатов в ходе анализа данных, а, следовательно, и причиной принятия решений, сильно отличающихся от оптимальных.

Полная очистка данных требует колоссальных временных ресурсов, поэтому данные необходимо очищать только до той степени, которая является приемлемой с точки зрения решаемых задач по анализу данных и поддержки принятия решений.

Выбор оптимального способа взаимодействия клиентского приложения с хранилищем данных
Взаимодействие технолога с ХД осуществляется посредством клиентского приложения, которое служит для формирования запросов пользователя к хранилищу данных, аналитической обработки результатов и представления их в удобном для восприятия виде.
В зависимости от количества автоматизированных рабочих мест технолога и сложности решаемых задач,
[стр. 96]

уровне каждого источника данных, а после этого происходит очистка данных от ошибок, порождаемых множественностью источников.
Тестовое преобразование помогает проверить, насколько хорошо реализованные правила преобразования данных могут решить задачу их очистки.
Инструментами преобразования могут служить как поставляемые с СУБД ETL-средства, так и специально созданные программные средства, имеющие доступ к извлеченным из различных источников данных.
Проведение полного преобразования данных подразумевает выполнение корректирующих процедур уже над всеми данными, которые предполагается добавить в ХД.
Противоток данных.
Эта процедура предполагает обратное перемещение очищенных данных в оперативные БД с целью улучшить состояние данных в источниках и не допустить повторного попадания тех же самых «грязных» данных в ХД при последующих его пополнениях.
Рассмотренные выше проблемы качества данных требуют обязательного решения, поскольку «грязные» данные, помещенные в хранилище, могут стать источниками неверных результатов в ходе анализа данных, а, следовательно, и причиной принятия решений, сильно отличающихся от оптимальных.

Однако, при проведении очистки необходимо помнить, что полной очистки данных достичь невозможно [76].
Полная очистка данных требует колоссальных временных ресурсов, поэтому данные необходимо очищать только до той степени, которая является приемлемой с точки зрения решаемых задач по анализу данных и поддержки принятия решений.

96

[стр.,97]

3.4.
Выбор оптимального способа взаимодействия клиентского приложения с хранилищем данных
97 3.4.1.
Выбор оптимальной модели взаимодействия клиентского приложения с хранилищем данных Взаимодействие технолога с ХД осуществляется посредством клиентского приложения, которое служит для формирования запросов пользователя к хранилищу данных, аналитической обработки результатов и представления их в удобном для восприятия виде.
В зависимости от количества автоматизированных рабочих мест технолога и сложности решаемых задач,
взаимодействие СППР с ХД может строиться в соответствии с двухуровневой или трехуровневой моделью взаимодействия клиентского приложения с источником данных [5] (рис.
22).
Способы взаимодействия клиентского приложения с хранилищем данных (а —трехзвенная архитектура, б архитектура «клиент-сервер») Хранилищеданных Хранилище данных Г Ч К Сервер приложений 1 < V \ Сервер приложений 2 4 > 0 ( 0 " V .
/ / // / / Ь V\ \ 1 \ 1^2 рабочие станции а) рабочие станции б) Рис.
22 Двухуровневая модель «клиент-сервер» [49] предполагает, что клиентское приложение осуществляет как формирование запроса к ХД и

[Back]