Проверяемый текст
Птицын, Сергей Вячеславович; Моделирование процессов принятия решений в автоматизированной системе управления региональным газораспределительным предприятием (Диссертация 2007)
[стр. 38]

ботки и предоставления информации.
Непосредственный доступ к последним обеспечивает ПО промежу точного слоя.
В этом случае избыточность данных нулевая.
Конечные пользователи фактически работают с транзакционными системами напрямую со всеми вытекающими отсюда плюсами (доступ к "живым" данным в реальном времени) и минусами (интенсивный сетевой трафик, снижение производительности OLTP-систем и реальная угроза их работоспособности вследствие неудачных действий пользователейаналитиков).
Витрина данных (Data Mart) по своему исходному определению э
го набор тематически связанных баз данных, которые содержат информацию, относящуюся к отдельным аспектам деятельности корпорации.
По сути дела, витрина данных это облегченный вариант хранилища данных, содержащий только тематически объединенные данные.
Целевая база данных максимально приближена к конечному пользователю и может содержать тематически ориентированные агрегатные данные.
Витрина данных, естественно, существенно меньше по объему, чем корпоративное хранилище данных, и для его реализации не требуется особо мощная вычислительная техника.
В последнее время все более популярной становится идея совместить концепции хранилища и витрины данных в одной реализации и использовать
хранилище данных в качестве единственного источника интегрированных данных для всех витрин данных.
Тогда естественной становится такая трехуровневая архитектура системы: На первом уровне реализуется корпоративное хранилище данных на основе одной из развитых современных реляционных СУБД.
Это хранилище интегрированных в основном детализированных данных.
Реляционные СУБД обеспечивают эффективное хранение и управление данными очень большого объема, но не слишком
хороню соответствуют потребностям OLАР-систем, в частности, в связи с требованием многомерного представления данных.
На втором уровне поддерживаются витрины данных на основе многомерной системы управления базами данных (примером такой системы явля
[стр. 47]

для баз данных объемом в 100 гигабайт потребуется внешняя память объемом в 4.87 раза большая, чем нужно собственно для полезных данных.
При дальнейшем росте баз данных этот коэффициент увеличивается.
Варианты реализации хранилищ данных • Виртуальное хранилище данных • Витрины данных • Глобальное хранилище данных • Многоуровневая архитектура хранилища данных В основе Виртуального хранилища данных репозиторий метаданных, которые описывают источники информации (БД транзакционных систем, внешние файлы и др.), SQL-запросы для их считывания и процедуры обработки и предоставления информации.
Непосредственный доступ к последним обеспечивает ПО промежуточного слоя.
В этом случае избыточность данных нулевая.
Конечные пользователи фактически работают с транзакционными системами напрямую со всеми вытекающими отсюда плюсами (доступ к "живым" данным в реальном времени) и минусами (интенсивный сетевой трафик, снижение производительности OLTP-систем и реальная угроза их работоспособности вследствие неудачных действий пользователейаналитиков).
Витрина данных (Data Mart) по своему исходному определению это
набор тематически связанных баз данных, которые содержат информацию, относящуюся к отдельным аспектам деятельности корпорации.
По сути дела, витрина данных это облегченный вариант хранилища данных, содержащий только тематически объединенные данные.
Целевая база данных максимально приближена к конечному пользователю и может содержать тематически ориентированные агрегатные данные.
Витрина данных, естественно, существенно меньше по объему, чем корпоративное хранилище данных, и для его реализации не требуется особо мощная вычислительная техника.
В последнее время все более популярной становится идея совместить концепции хранилища и витрины данных в одной реализации и использовать
47

[стр.,48]

хранилище данных в качестве единственного источника интегрированных данных для всех витрин данных.
Тогда естественной становится такая трехуровневая архитектура системы: На первом уровне реализуется корпоративное хранилище данных на основе одной из развитых современных реляционных СУБД.
Это хранилище интегрированных в основном детализированных данных.
Реляционные СУБД обеспечивают эффективное хранение и управление данными очень большого*1 объема, но не слишком
хорошо соответствуют потребностям OLAP-систем, в частности, в связи с требованием многомерного представления данных.
На втором уровне поддерживаются витрины данных на основе многомерной системы управления базами данных (примером такой системы является
Oracle Express Server).
Такие СУБД почти идеально подходят для целей разработки OLAP-систем, но пока не позволяют хранить сверхбольшие объемы данных (предельный размер многомерной базы данных составляет 10-40 Гбайт).
В данном случае это и не требуется, поскольку речь идет о витринах данных.
Заметам, что витрина данных не обязательно должна быть полностью сформирована.
Она может содержать ссылки на хранилище данных и добирать оттуда информацию по мере поступления запросов.
Конечно, это несколько увеличивает время отклика, но зато снимает проблему ограниченного объема многомерной базы данных.
Наконец, на третьем уровне находятся клиентские рабочие места конечных пользователей, на которых устанавливаются средства оперативного анализа данных.
Аналитические средства СППР на сегодняшний день представлены двумя основными технологиями "добыча данных" (Data Mining) и Оперативная аналитическая обработка данных (OLAP).
"Добыча данных” как процесс аналитического исследования больших массивов информации (обычно экономического характера) с целью выявления определенных закономерностей и систематических взаимосвязей между переменными, которые затем можно применить к новым совокупностям дан48

[Back]