Одним из вариантов реализации на практике хранилища данных является построение витрин данных (Data Marts). Иногда их называют также киосками данных. Витрина данных - это предметно-ориентированная совокупность данных, имеющая специфическую организацию. Содержание витрин данных, как правило, предназначено для решения некоего круга однородных задач одной или нескольких смежных предметных областей, либо для выполнения конкретных бизнес-функций, либо для конкретных подразделений. Например, для решения задач, связанных с анализом кредитных услуг банка, используется одна витрина, а для работ по анализу деятельности банка на фондовом рынке - другая.

Следовательно, витрина данных - это относительно небольшие и специализированные хранилища данных, содержащие только тематически ориентированные данные и предназначенные для использования конкретным функциональным подразделением. Итак, функционально-ориентированные витрины данных представляют собой структуры данных, обеспечивающие решение аналитических задач в конкретной функциональной области или подразделении компании, например управление прибыльностью, анализ рынков, анализ ресурсов, анализ денежных потоков, анализ клиентской базы, маркетинговое исследование, управление активами и пассивами и т.д. Таким образом, витрины данных можно рассматривать как маленькие тематические хранилища, которые создаются с целью информационного обеспечения аналитических задач конкретных управленческих подразделений компании.

Организация данных в витрину определяется необходимостью обеспечить возможности анализа данных той или иной предметной области наиболее оптимальными средствами.

Витрины данных и хранилище данных значительно отличаются друг от друга. Хранилище данных создается для решения корпоративных задач, присутствующих в корпоративной информационной системе. Обычно хранилища данных создаются и приобретаются организациями с центральным подчинением, такими как классические организации информационных технологий, например банк. Хранилище данных составляется усилиями всей корпорации.

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

Следующее отличие состоит в степени детализации данных, поскольку витрина данных содержит уже агрегированные данные. В хранилище данных, наоборот, находятся максимально детализированные данные.

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

В отличие от хранилища витрина данных содержит лишь незначительный объем исторической информации, привязанной только к небольшому отрезку времени и существенной только в момент, когда она отвечает требованиям решения задачи. Витрины данных можно представить в виде логически или физически разделенных подмножеств хранилища данных. На рис. 2.20 представлена взаимосвязь витрин данных и хранилища данных на примере банковской сферы.

Рис. 2.20.

Витрины данных, как правило, размещаются в многоуровневой технологии, которая оптимальна для гибкости анализа, но неоптимальна для больших объемов данных.

Структура витрин данных также ориентирована на многомерную организацию данных в виде куба. Однако их построение в силу ограниченности информационного диапазона, обеспечивающего потребности одной функциональной области, значительно проще и выгоднее.

Существуют два типа витрин данных - зависимые и независимые. Зависимая витрина данных - это та, источником которой является хранилище данных. Источником независимой витрины данных является среда первичных программных приложений. Зависимые витрины данных стабильны и имеют прочную архитектуру. Независимые витрины данных нестабильны и имеют неустойчивую архитектуру, по крайней мере при пересылке данных.

Надо отметить, что витрины данных являются идеальным решением наиболее существенного конфликта при проектировании хранилища данных - производительность или гибкость. В общем, чем более стандартизирована и гибка модель хранилища данных, тем менее продуктивно она отвечает на запросы. Это связано с тем, что запросы, поступающие в стандартно спроектированную систему, требуют значительно больше предварительных операций, чем в оптимально спроектированной системе. Направляя все запросы пользователя в витрины данных, поддерживая гибкую модель для хранилища данных, разработчики могут достичь гибкости и продолжительной стабильности структуры хранилища, а также оптимальной производительности для запросов пользователей.

Данные, попав в хранилище, могут быть распространены среди многих витрин данных для доступа пользовательских запросов. Эти витрины данных могут принимать различные формы - от баз данных «клиент-сервер» до баз данных на рабочем столе, ОЬАР- кубов или даже динамических электронных таблиц. Выбор инструментов для пользовательских запросов может быть широким и отображать предпочтения и опыт конкретных пользователей. Широкий выбор таких инструментов и простота их применения сделают их внедрение наиболее дешевой частью реализации проекта хранилища данных. Если данные в хранилище имеют хорошую структуру и проверенное качество, то их передача в другие витрины данных станет рутинной и дешевой операцией.

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

КОНТРОЛЬНЫЕ ВОПРОСЫ

• 1. Сформулируйте понятие информационного обеспечения. Каковы его цели и задачи?
• 2. Какова структура подсистемы «информационное обеспечение»?
• 3. Как можно определить понятие внемашинного и внутримашинного информационного обеспечения?
• 4. Что включает в себя внемашинное информационное обеспечение?
• 5. Что понимается под системой классификации и для чего необходима классификация?
• 6. Какими свойствами характеризуется любая система классификации?
• 7. Каковы основные особенности фасетной системы классификации?
• 8. Какие требования необходимо соблюдать при классификации?
• 9. Перечислите основные особенности иерархической системы классификации.
• 10. С какой целью разрабатываются и какие бывают классификаторы?
• 11. В каких случаях используются регистрационные системы кодирования? Какие системы относятся к этому классу?
• 12. Для чего используются классификационные системы кодирования? Какие системы входят в эту группу?
• 13. В чем сущность штрихового кодирования?
• 14. Дайте определения документа, унифицированной системы документации.
• 15. Что представляют собой схемы информационных потоков и каково их основное назначение?
• 16. Каковы основные способы организации внутримашинного информационного обеспечения?
• 17. Перечислите основные недостатки систем с файловой организацией.
• 18. Дайте определение базы данных. В чем ее особенности?
• 19. Каковы основные структурные единицы базы данных и их взаимосвязь?
• 20. Перечислите и охарактеризуйте основные этапы жизненного цикла базы данных.
• 21. Раскройте основные этапы проектирования базы данных.
• 22. В чем заключается сущность концептуального проектирования?
• 23. Для чего используется?7?-модель? Каковы ее сущность и достоинства?
• 24. Дайте характеристику основных типов логических моделей данных.
• 25. Опишите иерархическую и сетевую модели данных.
• 26. Поясните назначение ключевых полей в реляционной базе данных.
• 27. Какие виды связей между объектами вам известны?
• 28. Какие нормальные формы вам известны? Опишите их основные свойства, назначение.
• 29. Что такое отношение в реляционной модели? Назовите основные свойства отношения.
• 30. Дайте определения следующим понятиям: отношение, кортеж, атрибут, домен.
• 31. В чем заключается принцип нормализации отношений?
• 32. Каковы особенности постреляционных баз данных?
• 33. В чем основные особенности технологии «Хранилище данных»?
• 34. Дайте определение хранилища данных и витрины данных. В чем их отличие?
• 35. Какие основные типы витрин данных вам известны?
• 36. В чем сущность понятия «многомерный куб»?
• 37. Охарактеризуйте основные функциональные блоки системы управления «Хранилище данных».
• 38. Опишите многомерную структуру хранилища данных типа «звезда» и «снежинка».
• 39. Каковы основные источники поступления данных в информационное хранилище?

Семантика

Технологии Big Data создавались в качестве ответа на вопрос «как обработать много данных». А что делать, если объем информации не является единственной проблемой? В промышленности и прочих серьезных применениях часто приходится иметь дело с большими данными сложной и переменной структуры, разрозненными массивами информации. Встречаются задачи, способ решения которых наперед не известен, и аналитику необходимы средства исследования исходных данных или результатов вычислений на их основе без привлечения программиста. Нужны инструменты, сочетающие функциональную мощь систем BI (а лучше – превосходящие ее) со способностью к обработке огромных объемов информации.

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

Для рассказа нам понадобится простой пример сложной задачи. Рассмотрим некий промышленный комплекс, обладающий огромным количеством оборудования, обвешанного различными датчиками и сенсорами, регулярно сообщающими сведения о его состоянии. Для простоты рассмотрим только два агрегата, котел и резервуар, и три датчика: температуры котла и резервуара, а также давления в котле. Эти датчики контролируются АСУ разных производителей и выдают информацию в разные хранилища: сведения о температуре и давлении в котле поступают в HBase, а данные о температуре в резервуаре пишутся в лог-файлы, расположенные в HDFS. Следующая схема иллюстрирует процесс сбора данных.

Кроме конкретных показаний датчиков, для анализа необходимо иметь список сенсоров и устройств, на которых они установлены. Оценим порядок числа информационных сущностей, с которыми мы имели бы дело на реальном предприятии:

Способы хранения для данных разных типов зависят от их объема, структуры и требуемого режима доступа. В данном случае мы выбрали именно такие средства для создания «разнобоя», но и на реальных предприятиях чаще всего нет возможности свободно их выбирать – все зависит от сложившегося ИТ-ландшафта. Аналитической же системе нужно собрать весь «зоопарк» под одной крышей.

Пусть мы хотим предоставить аналитику возможность делать запросы такого типа:

• Какие единицы маслонаполненного оборудования работали при температуре выше 300 градусов за последнюю неделю?
• Какое оборудование находится в состоянии, выходящем за пределы рабочего диапазона?

Заранее построить и запрограммировать все подобные запросы не получится. Выполнение любого из них требует связывания данных из разных источников, в том числе из находящихся за пределами нашего модельного примера. Извне могут поступать, например, справочные сведения о рабочих диапазонах температуры и давления для разных видов оборудования, фасетные классификаторы, позволяющие определить, какое оборудование является маслонаполненным, и др. Все подобные запросы аналитик формулирует в терминах концептуальной модели предметной области , то есть ровно в тех выражениях, в которых он думает о работе своего предприятия. Для представления концептуальных моделей в электронной форме существует стек семантических технологий: язык OWL, хранилища триплетов, язык запросов SPARQL. Не имея возможности подробно рассказывать о них в этой статье, сошлемся на .

Итак, наш аналитик будет формулировать запросы в привычных ему терминах, и получать в ответ наборы данных – независимо от того, из какого источника эти данные извлечены. Рассмотрим пример простого запроса, на который можно найти ответ в нашем наборе информации. Пусть аналитик интересуется оборудованием , установленные на котором сенсоры одновременно измерили температуру больше 400 0 и давление больше 5 мПа в течение заданного периода времени. В этой фразе мы выделили жирным слова, соответствующие сущностям информационной модели: оборудование, сенсор, измерение. Курсивом выделены атрибуты и связи этих сущностей. Наш запрос можно представить в виде такого графа (под каждым типом данных мы указали хранилище, в котором они находятся):

При взгляде на этот граф становится понятной схема выполнения запроса. Сначала нужно отфильтровать измерения температуры за заданный период со значением больше 400 0 C, и измерения давления со значением больше 5 мПа; затем нужно найти среди них те, которые выполнены сенсорами, установленные на одной и той же единице оборудования, и при этом выполнены одновременно. Именно так и будет действовать витрина данных.
Схема нашей системы будет такой:

Порядок работы системы таков:

• аналитик делает запрос;
• логическая витрина данных представляет его в виде запроса к графу;
• витрина определяет, где находятся данные, необходимые для ответа на этот запрос;
• витрина выполняет частные запросы исходных данных к разным источникам, используя необходимые фильтры;
• получает ответы и интегрирует их в единый временный граф;
• выполняет пост-обработку графа, заключающуюся, например, в применении правил логического вывода;
• выполняет на нем исходный запрос, и возвращает ответ аналитику.

Вся «магия», конечно, происходит внутри витрины. Перечислим принципиальные моменты.

1. В хранилище триплетов Apache Jena (можно использовать и любое другое) у нас хранится как сама модель предметной области, так и настройки мэппинга на источники данных. Таким образом, через редактор информационной модели мы задаем и набор терминов, в которых строятся запросы (устройство, сенсор и т.д.), и служебные сведения о том, откуда брать соответствующую им фактическую информацию. На следующем рисунке показано, как в нашем редакторе онтологий выглядит дерево классов модели демонстрационного примера (слева), и одна из форм настройки мэппинга данных с источником (справа).

2. В нашем примере данные одного и того же типа (измерения температуры) хранятся одновременно в двух разных источниках – HBase и текстовом файле HDFS. Однако для выполнения приведенного запроса обращаться к файлу не нужно, т.к. в нем заведомо нет полезной информации: ведь в файле хранятся измерения температуры резервуара, а давление в резервуарах не измеряется. Этот момент дает представление о том, как должен работать оптимизатор выполнения запросов.

3. Витрина данных не только компонует и связывает информацию из различных источников, но и делает логические выводы на ней в соответствии с заданными правилами. Автоматизация получения логических выводов – одно из главных практических преимуществ семантики. В нашем примере с помощью правил решена проблема получения выводов о состоянии устройства на основе данных измерений . Температура и давление содержатся в двух разных сущностях типа «Измерение», а для описания состояния устройства необходимо их объединить. Логические правила применяются к содержимому временного графа результатов, и порождают в нем новую информацию, которая отсутствовала в источниках.

4. В качестве источников данных могут выступать не только хранилища, но и сервисы. В нашем примере мы спрятали за сервисом расчет предпосылок к возникновению аварийного состояния при помощи одного из алгоритмов Spark MLlib. Этот сервис получает на вход информацию о состоянии устройства, и оценивает его с точки зрения наличия предпосылок к аварии (для обучения использованы ретроспективные данные о том, какие условия предшествовали реально случившимся авариям; в качестве исходных данных нужно рассматривать не только мгновенные значения физических характеристик устройства, но и элементы основных данных – например, степень его износа).
Эта возможность очень важна, так как позволяет аналитику самому выполнять запуск расчетных модулей, подготовленных программистами, передавая им на вход различные массивы данных. В этом случае аналитик будет работать уже не с исходными данными, а с результатами вычислений на их основе.

5. Аналитик строит запросы при помощи интерфейсов нашей Системы управления знаниями, среди которых – как несколько вариантов формального конструктора запросов, так и интерфейс поиска на контролируемом естественном языке. На следующем рисунке слева показана форма построения запроса на контролируемом языке, а справа – пример результатов другого запроса.

Конечно, в любой бочке меда найдется ложка дегтя. В данном случае она состоит в том, что на действительно больших данных приведенная архитектура будет работать не так уж быстро. С другой стороны, при работе аналитика в режиме «свободного поиска» решения проблем быстродействие для него обычно не принципиально; в любом случае, витрина будет выдавать результаты куда быстрее, чем программист, к которому при ее отсутствии аналитику придется обращаться за ручным выполнением каждого своего запроса.

За рамками нашего рассказа осталось немало интересных моментов:

• как организован сбор данных сенсоров в HBase с помощью Flume;
• запросы к источникам данных могут выполняться не просто асинхронно, но даже при отсутствии онлайн-связи с ними – на этот случай предусмотрен специальный механизм передачи запроса и получения ответа;
• результаты выполнения запроса могут не просто выдаваться пользователю в виде таблицы или выгружаться в Excel, но и попадать напрямую в BI-систему в виде набора данных для дальнейшего анализа;
• способы конвертации идентификаторов и ссылок на объекты в разных источниках, вопросы транспорта сообщений между компонентами системы, и многое другое.

Разумеется, реальные промышленные применения витрины данных куда сложнее описанного примера. Нашей целью в этой статье была демонстрация того, что использование семантических технологий и концептуального моделирования в тандеме со средствами Big Data позволяет расширить число доступных аналитику способов использования данных, решать прикладные задачи в самых неординарных условиях. В сочетании с возможностями

В хранилище данных хранится информация по всем аспектам деятельности организации.Витрина же данных (data mart ) – это специализированное хранилище данных, содержащее данные по одному из направлений деятельности предприятия. Витрины данных - это комплекс тематически связанных баз данных, относящихся к конкретным аспектам деятельности компании. В этом случае аналитики видят и работают не со всеми имеющимися в компании данными, а только с реально необходимыми данными. Это максимально приближает их к конечному пользователю.

Витрина данных представляет собой срез хранилища данных, представляющий собой массив тематической, узконаправленной информации, ориентированный на пользователей одной конкретной рабочей группы. Часто витрины еще называют киосками данных.

Т.к. Витрины Данных обычно содержат тематические подмножества заранее агрегированных данных, то их проще проектировать и настраивать. Витрина данных проектируются для ответов на конкретный ряд вопросов. Данные в витрине оптимизированы для использования определенными группами пользователей, что облегчает процедуры их наполнения, а также способствует повышению производительности

Т.к. конструирование хранилища данных - сложный процесс, который может занять несколько лет, некоторые организации вместо этого строят витрины данных, содержащие информацию для конкретных подразделений. Например, витрина данных отдела маркетинга может содержать только информацию о клиентах, продуктах и продажах и не включать в себя планы поставок. Существуют также витрина данных отдела продаж, витрина данных финансового отдела, витрина данных отдела анализа рисков и т.п. Несколько витрин данных для подразделений могут сосуществовать с основным хранилищем данных, давая частичное представление о содержании хранилища. Витрины данных строятся значительно быстрее, чем хранилище, но впоследствии могут возникнуть серьезные проблемы с интеграцией, если первоначальное планирование проводилось без учета полной бизнес-модели.

Достоинства Витрин данных:

· Витрина данных максимально приближена к пользователю - аналитики работают только с теми данными, которые им необходимы для принятия решения.

· Витрины Данных значительно меньше по размеру, чем Хранилища данных.

· Создавать Витрины данных просто, наполнять их и работать с ними также просто.

· Витрины Данных содержат агрегированные данные по определенным темам, что упрощает их проектирование.

· Витрины данных внедряются достаточно быстро.

· Витрины проектируются для ответов на конкретный ряд вопросов.

· Данные в витрине оптимизированы для использования определенными группами пользователей, что облегчает процедуры их наполнения, а также способствует повышению производительности.

Недостатки Витрин данных:

· сложно контролировать избыточность, целостность и непротиворечивость данных в витрине данных, т.к. одни и те же данные могут храниться сразу в нескольких витринах. Дублирование данных - данные хранятся многократно в различных витринах данных. Это приводит к увеличению расходов на хранение, а также к потенциальным проблемам, связанным с необходимостью поддержания непротиворечивости данных.

· сложно работать с витриной, если для наполнения витрины используется очень большое количество источников данных - Потенциально это очень сложный процесс. Наполнения витрин данных при большом количестве источников данных – процесс очень сложный (требуется команда профессионалов в области их построения и работы с ними).

· информация накапливается в различных витринах, но дальнейшее объединение информации (т.е. ее консолидация) не предусматривается. Данные не консолидируются на уровне предприятия, поэтому получить полную единую картину бизнеса нельзя.

· каждая витрина содержит информацию о конкретном аспекте деятельности компании, что не дает возможность руководству компании увидеть как работает его бизнес в целом.

В большинстве случае Витрина данных - это аналитическая структура, которая обычно поддерживает область работы одного приложения, бизнес-процесса или отдела. Сотрудники отдела обобщают требования к информации и приспосабливают каждую витрину к своим нуждам. Затем они обеспечивают персонал, работающий с информацией, средствами интерактивной отчетности (например, инструментами OLAP, средствами формирования незапланированных запросов или параметризованных отчетов).

Независимые витрины данных (см. рис.24) часто появляются в организации исторически и встречаются в крупных организациях с большим количеством независимых подразделений, зачастую имеющих свои собственные отделы информационных технологий.

Рис.24 Независимые Витрины данных

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

Но уже в 1994 году концепцию Хранилищ данных и концепцию витрин данных было предложено объединить и использовать хранилище данных в качестве единого интегрированного источника данных для витрин данных (см. Рис.25)

Рис. 25 Трёхуровневое хранилище данных

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

Преимущества Трёхуровневого хранилища данных:

· Создание и наполнение витрин данных упрощено, поскольку наполнение происходит из единого стандартизованного надежного источника очищенных нормализованных данных.

· Витрины данных синхронизированы и совместимы с корпоративным представлением. Существует возможность сравнительно лёгкого расширения хранилища и добавления новых витрин данных.

· Гарантированная производительность.

Недостатки Трёхуровневого хранилища данных:

· Существует избыточность данных, ведущая к росту требований на хранение данных.

· Требуется согласованность с принятой архитектурой многих областей с потенциально различными требованиями (например, скорость внедрения иногда конкурирует с требованиями следовать архитектурному подходу).

Data Mart ; другие варианты перевода: хранилище данных специализированное, киоск данных, рынок данных) - срез хранилища данных , представляющий собой массив тематической, узконаправленной информации, ориентированный, например, на пользователей одной рабочей группы или департамента.

Концепция витрин данных

Концепция витрин данных была предложена Forrester Research ещё в 1991 году . По мысли авторов, витрины данных - множество тематических баз данных (БД), содержащих информацию, относящуюся к отдельным аспектам деятельности организации.

Концепция имеет ряд несомненных достоинств:

• Аналитики видят и работают только с теми данными, которые им реально нужны.
• Целевая БД максимально приближена к конечному пользователю.
• Витрины данных обычно содержат тематические подмножества заранее агрегированных данных, их проще проектировать и настраивать.
• Для реализации витрин данных не требуется высокомощная вычислительная техника.

Но концепция витрин данных имеет и очень серьёзные пробелы. По существу, здесь предполагается реализация территориально распределённой информационной системы с мало контролируемой избыточностью, но не предлагается способов, как обеспечить целостность и непротиворечивость хранимых в ней данных.

Смешанная концепция витрин данных и хранилищ данных

Идея соединить две концепции - хранилищ данных и витрин данных, по-видимому, принадлежит М. Демаресту (M. Demarest), который в 1994 году предложил объединить две концепции и использовать хранилище данных в качестве единого интегрированного источника данных для витрин данных.

И сегодня именно такое многоуровневое решение:

• первый уровень - общекорпоративная БД на основе реляционной СУБД с нормализованной или слабо денормализованной схемой (детализированные данные);
• второй уровень - БД уровня подразделения (или конечного пользователя), реализуемые на основе многомерной СУБД (агрегированные данные);
• третий уровень - рабочие места конечных пользователей, на которых непосредственно установлен аналитический инструментарий;

постепенно становится стандартом де-факто, позволяя наиболее полно реализовать и использовать достоинства каждого из подходов:

• компактное хранение детализированных данных и поддержка очень больших БД, обеспечиваемые реляционными СУБД ;
• простота настройки и хорошие времена отклика, при работе с агрегированными данными, обеспечиваемые многомерными СУБД.

Реляционная форма представления данных, используемая в центральной общекорпоративной БД, обеспечивает наиболее компактный способ хранения данных. Современные реляционные СУБД уже умеют работать с БД имеющими размер порядка нескольких терабайт. Хотя такая центральная система обычно не сможет обеспечить оперативного режима обработки аналитических запросов, при использовании новых способов индексации и хранения данных, а также частичной денормализации таблиц, время обработки заранее регламентированных запросов (а в качестве таких, можно рассматривать и регламентированные процедуры выгрузки данных в многомерные БД) оказывается вполне приемлемым.

В свою очередь, использование многомерных СУБД в узлах нижнего уровня обеспечивает минимальные времена обработки и ответа на нерегламентированные запросы пользователя. Кроме того, в некоторых многомерных СУБД имеется возможность хранить данные как на постоянной основе (непосредственно в многомерной БД), так и динамически (на время сеанса) загрузить данные из реляционных БД (на основе регламентированных запросов).

Таким образом, имеется возможность хранить на постоянной основе только те данные, которые наиболее часто запрашиваются в данном узле. Для всех остальных хранятся только описания их структуры и программы их выгрузки из центральной БД. И хотя при первичном обращении к таким виртуальным данным время отклика может оказаться достаточно продолжительным, такое решение обеспечивает высокую гибкость и требует менее дорогих аппаратных средств

Хранилище данных Хранилище данных - это предметно-ориентированная, интегрированная, содержащая исторические данные, неразрушимая совокупность данных, предназначенная для поддержки принятия управленческих решений. (Уильям Инмон) Термин "хранилище данных" можно представить в виде объединения двух основных идей: интеграция разобщенных данных в едином хранилище и разделение наборов данных и приложений для обработки и анализа.

Данные из различных источников помещаются в хранилище, а их описания в репозиторий метаданных. Конечный пользователь с помощью различных инструментов может анализировать данные в хранилище. Результатом является информация в виде готовых отчетов, найденных скрытых закономерностей, каких-либо прогнозов. Так как средства работы конечного пользователя с хранилищем данных могут быть самыми разнообразными, то их выбор не должен влиять на структуру хранилища и функции его поддержания в актуальном состоянии. Физическая реализация данной схемы может быть самой разнообразной. Концептуальная модель хранилища данных

Подходы и имеющиеся решения реализации Компания IBM A Data Warehouse Plus. Целью является обеспечение интегрированного набора программных продуктов и сервисов, основанных на единой архитектуре. Основой хранилищ данных является семейство СУБД DB2. Преимуществом IBM является то, что данные, которые нужно извлечь из оперативной базы данных и поместить в хранилище данных, находятся в системах IBM. Поэтому естественна тесная интеграция программных продуктов. Предлагаются три решения для хранилищ данных: Изолированная витрина данных. Предназначена для решения отдельных задач вне связи с общим хранилищем корпорации. Зависимая витрина данных. Аналогична изолированной витрине данных, но источники данных находятся под централизованным контролем. Глобальное хранилище данных. Корпоративное хранилище данных, которое полностью централизовано контролируется и управляется. Глобальное хранилище данных может храниться централизовано или состоять из нескольких распределенных в сети рынков данных.

Подходы и имеющиеся решения реализации (продолжение) Oracle Решение компании Oracle основывается на двух факторах: широкий ассортимент продуктов самой компании и деятельность партнеров в рамках программы Warehouse Technology Initiative. Возможности Oracle в области хранилищ данных базируются на следующих составляющих: наличие реляционной СУБД Oracle 7, которая постоянно совершенствуется для лучшего удовлетворения потребностей хранилищ данных; существование набора готовых приложений, обеспечивающих возможности разработки хранилища данных; высокий технологический потенциал компании в области анализа данных; доступность ряда продуктов, производимых другими компаниями.

Подходы и имеющиеся решения реализации (продолжение) Hewlett Packard OpenWarehouse. Выполнение этой программы должно обеспечить возможность построения хранилищ данных на основе мощных компьютеров HP, аппаратуры других производителей и программных компонент. Основой подхода HP являются Unix-платформы и программный продукт Intelligent Warehouse, предназначенный для управления хранилищами данных. Основа построения хранилищ данных, предлагаемая HP, оставляет свободу выбора реляционной СУБД, средств реинжиниринга и т.д. NCR Решение проблем корпораций, у которых одинаково сильны потребности и в системах поддержки принятия решений, и в системах оперативной аналитической обработки данных. Предлагаемая архитектура называется Enterprise Information Factory и основывается на опыте использования СУБД Teradata и связанных с ней методах параллельной обработки.

Подходы и имеющиеся решения реализации (продолжение) Informix Software Стратегия компании направлена на расширение рынка для продукта On-Line Dinamic Parallel Server. Предлагаемая архитектура базируется на четырех технологиях: реляционные базы данных, программное обеспечение для управления хранилищем данных, средства доступа к данным и платформе открытых систем. После выхода Универсального Сервера, основанного на объектно-реляционном подходе, можно ожидать, что и он будет использоваться для построения хранилищ данных. SAS Institute Компания считает себя поставщиком полного решения для организации хранилища данных. Подход основан на следующем: обеспечение доступа к данным с возможностью их извлечения из самых разнообразных хранилищ данных (и реляционных, и не реляционных); преобразование данных и манипулирование ими с использованием 4GL; наличие сервера многомерных баз данных; большой набор методов и средств для аналитической обработки и статистического анализа.

Подходы и имеющиеся решения реализации (окончание) Sybase Стратегия компании основывается на разработанной ей архитектуре Warehouse WORKS. В основе подхода находится реляционная СУБД Sybase System 11, средство для подключения и доступа к базам данных OmniCONNECT и средство разработки приложений PowerBuilder. Компания продолжает совершенствовать свою СУБД для лучшего удовлетворения потребностей хранилищ данных (например, введена побитная индексация). Software AG Open Data Warehouse Initiative. Программа базируется на основных продуктах компании ADABAS и Natural 4GL, собственных и приобретенных средствах извлечения и анализа данных, средстве управления хранилищем данных SourcePoint. SourcePoint позволяет автоматизировать процесс извлечения и пересылки данных, а также их загрузки в хранилище данных.

Правила для хранилищ данных (Уиллиам и Келли) 1. Хранилища данных и операционная среда должны быть разделены. 2. Данные в хранилище должны интегрироваться. 3. В хранилище содержатся данные, накопленные за долгое время. 4. Данные в хранилище- это мгновенный снимок данных, полученный в данный момент времени. 5. Данные в хранилище предметно ориентированы. 6. Данные в хранилище предназначены для чтения с периодическим обновлением на основе операционных данных. Данные в хранилище обновлять оперативно нельзя.

Правила для хранилищ данных (продолжение) 7. Жизненный цикл в хранилище данных отличается от классической информационной системы. В хранилище данных во главе - данные, а в операционной базе данных - процесс. 8. В хранилище данных хранятся данные с несколькими уровнями детализации (текущие, старые, слабо обобщенные, данные высокой степени обобщения). 9. Среда хранилища данных характеризуется транзакциями, выполняющих чтение только большого числа данных. (Среда операционной базы данных – большое число транзакций обновлений). 10. Хранилище данных в составе имеет систему, которая отслеживает источники данных, преобразование и хранение.

Правила для хранилищ данных (окончание) 11. Метаданные хранилища - важнейший компонент этой инфраструктуры, так как он описывает источники, преобразование, хранение, использование, связи, интеграцию и историю каждого элемента данных. 12. В хранилище данных должен иметься механизм использования ресурсов для оптимизации всех процессов. Два подхода: данные хранятся в виде кубов; каждый раз создается виртуальный куб. Стараются создать куб, чтобы хранить в нем данные – например, на нижнем уровне – сами данные, на следующем – первая степень детализации, на следующем – вторая и т.д. – до самого обобщенного показателя.

Виртуальное хранилище данных Виртуальное хранилище данных - это система, предоставляющая доступ к обычной регистрирующей системе, которая эмулирует работу с хранилищем данных. Виртуальное хранилище можно организовать двумя способами: создать ряд "представлений" (view) в базе данных использовать специальные средства доступа к базе данных (например, продукты класса desktop OLAP)

Преимущества и недостатки виртуальных хранилищ + простота и малая стоимость реализации + единая платформа с источником информации + отсутствие сетевых соединений между источником информации и хранилищем данных - работа с иллюзией хранилища данных - низкая производительность - сложность трансформации данных и интеграции данных с другими источниками - отсутствие истории - проблемы с чистотой данных - зависимость от доступности и структуры основной базы данных

Витрины данных Концепция витрин данных была предложена в 1992 году. Появление витрин данных было попыткой смягчить требования к хранилищам данных. Под витриной данных понимают специализированные хранилища, обслуживающие одно из направлений деятельности. Из всего хранилища данных выделяют направления и они автоматизируются. Как правило, в первую очередь берутся те процессы, которые легко автоматизируются, хорошо изучены, не так сложны и внедрение этих витрин данных позволяет уже на маленьких примерах быстро получить окупаемость. Очень часто разработка хранилища данных и витрин данных идет параллельно, то есть в перспективе нужно хранилище данных, но походу разрабатываются витрины, которые начинают давать отдачу, с другой стороны позволяют разработчикам показать заказчикам, что эффект есть.

Преимущества витрин + простота и малая стоимость реализации + высокая производительность за счет физического разделения регистрирующих и аналитических систем, выделения загрузки и трансформации данных в отдельный процесс, оптимизированной под анализ структурой хранения данных +поддержка истории +возможность добавления метаданных

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

В 1994 году было предложено объединить концепции витрин данных и хранилища данных и использовать хранилища для витрин данных. Целью объединения было то, чтобы сами витрины данных основывались на данных, которые хранятся в хранилищах. Была предложена так называемая многоуровневая архитектура из трех уровней: 1-й уровень общекорпоративной базы данных на основе распределенной СУБД; 2-й уровень базы данных подразделений. Здесь хранятся агрегированные данные, то есть реляционные базы данных хранят операционные данные, а агрегированные данные отбрасываются на 2 уровень. 3-й уровень - это конкретные места пользователей-аналитиков. Те пользователи, которые на основе витрин данных делают какие-то выводы.

Иногда анализ, проведенный в одном отделе, противоречит результатам, полученным в другом. Отсутствие согласованности связано с противоречивым определением общих бизнес-терминов и несоответствием данных по всей организации. Непосредственным решением этой проблемы является создание координированных витрин данных, иначе называемое интегрированным хранилищем. Создание координированных витрин данных подразумевает проектирование системы для всей организации в целом и последующую детальную разработку по отдельным функциям. Такой итерационный подход снижает возможный риск и сразу дает множество преимуществ, а также позволяет со временем развивать систему, пока аналитические возможности не охватят всю деятельность организации.

Оптимизация координированных витрин заключается в создании такой структуры, которая позволила бы наиболее оперативно анализировать данные и составлять отчеты, быстро предоставляя клиенту необходимую информацию о его бизнесе. Для этой цели лучше всего подходит схема "звезда". В схеме звезда представлено два типа таблиц - таблицы фактов и таблицы измерений. Первые содержат историю транзакций, связанную с конкретным моделируемым видом деятельности. В них хранятся соответствующие числовые показатели и поля ID (идентификаторы) для каждого из измерений. В схеме "звезда" таблицы фактов окружены вспомогательными таблицами измерений, благодаря чему пользователь может быстро углубляться в данные для выявления корреляций между измерениями и элементами в таблицах фактов.

Архитектура хранилища данных На сегодняшний день предложено множество архитектур, рассмотрим пять наиболее распространенных: 1. независимые витрины данных (independent data marts) 2. шина взаимосвязанных витрин данных(data-mart bus architecture with linked dimensional data marts) 3. архитектура «звезда» (hub-and-spoke) 4. централизованное хранилище данных (centralized data warehouse) 5. федеративная архитектура (federated architecture).

Независимые витрины данных Нередка ситуация, когда каждое подразделение компании разрабатывает свою собственную витрину данных. Все эти витрины удовлетворяют потребностям, для которых создавались, но при этом не зависят друг от друга и не обеспечивают единого представления о ситуации в компании. В них несогласованно заданы данные, используются разные измерения и показатели, а следовательно, анализ данных между витринами затруднен.

Шина взаимосвязанных витрин данных (Ralph Kimball) Создание такой архитектуры начинается с анализа требований для конкретных бизнес-процессов, таких как заказы, клиенты, счета и проч. Первая витрина данных строится для одного бизнес-процесса с использованием измерений и показателей, которые в дальнейшем будут применяться в других компонентах. Последующие витрины данных разрабатываются с использованием этих измерений, что в результате приводит к созданию логически интегрированных витрин.

Архитектура «звезда» (Bill Inmon) Представляет собой централизованное хранилище данных с зависимыми витринами данных. Эта архитектура разрабатывается на основе корпоративного анализа требований к данным. Важно обратить внимание на создание масштабируемой и поддерживаемой инфраструктуры. На основе использования корпоративного представления данных выполняется итеративная разработка архитектуры, при этом вовлекается одна предметная область за другой. Детальные данные хранятся в нормализованной форме в хранилище данных. Зависимые витрины данных получают данные из хранилища данных. Зависимые витрины данных разрабатываются для подразделений или конкретных функциональных областей, целей и могут быть как нормализованными, так и денормализованными, либо в виде любой агрегированной структуры данных. Большинство пользователей выполняет запросы на зависимых витринах данных.

Централизованное хранилище данных (без зависимых витрин) Эта архитектура похожа на архитектуру «звезда» за исключением отсутствия зависимых витрин данных. Хранилище данных содержит детальные данные, некоторое количество агрегированных данных и логические представления. Запросы и приложения выполняются как на реляционных данных, так и на многомерных представлениях.

Федеративная архитектура В этой архитектуре используются уже существующие структуры поддержки принятия решений (операционные системы, витрины и хранилища данных). Данные извлекаются из перечисленных систем на основе бизнес-требований. Данные логически или физически интегрируются с помощью метаданных, распределенных запросов и других методов. Эта архитектура является практическим решением для компаний, которые уже пользуются аналитическими средствами и не хотят от них отказываться.