Интегрированное ХД - хранилище данных
В 1994 году M. Demarest предложил объединить концепции ХД и ВД в одной реализации, и использовать ХД в качестве единого интегрированного источника для многочисленных ВД. В таком варианте корпоративная информационно-аналитическая система имеет трехуровневую структуру:
Общекорпоративное централизованное ХД
Общекорпоративное централизованное ХД на основе одной из развитых современных реляционных СУБД. Это ХД интегрированных в основном детализированных данных. Реляционные СУБД обеспечивают эффективное хранение и управление данными очень большого объема, но не слишком хорошо соответствуют потребностям OLAP-систем, в частности, в связи с требованием многомерного представления данных;
Тематические ВД (витрины данных) на уровне подразделений
Поддерживаются ВД на основе многомерной системы управления базами данных (примером такой системы является Oracle Express Server ). Такие СУБД почти идеально подходят для целей разработки OLAP-систем, но пока не позволяют хранить сверхбольшие объемы данных (предельный размер многомерной БД составляет 10-20 гигабайт). В данном случае это и не требуется, поскольку речь идет о ВД. Заметим, что ВД не обязательно должен быть полностью сформирован. Он может содержать ссылки на ХД и добирать оттуда информацию по мере поступления запросов. Конечно, это несколько увеличивает время отклика, но зато снимает проблему ограниченного объема многомерной БД;
Рабочие места конечных пользователей
Рабочие места конечных пользователей, снабженные аналитическим инструментарием оперативного анализа данных.
|
Непроектируемые витрины данных
Появление непроектируемых витрин данных (Non - Architected Data Marts) объясняется, прежде всего, сложностями, связанными с реализацией систем EDW и FDW. «Грязные» и быстро получаемые наборы данных не подвергаются очистке и, следовательно, не могут использоваться для дальнейшей интеграции с любыми другими источниками данных систем ХД. Очень быстро они превращаются в устаревшие системы, отдельно стоящие информационные "дымоходы", которые только добавляют проблемы, а не решают их. Для этих систем характерны многочисленные процессы извлечения, множество бизнес-правил, недостоверность информации (см. рисунок).
Достоинства непроектируемых витрин данных
быстрота
низкая стоимость
Недостатки
недостоверная информация.
многочисленные процессы извлечения.
многочисленные бизнес-правила.
множественная семантика.
повышенная сложность при интеграции.
|
Система постепенно развиваемых витрин данных
Данная архитектура является альтернативой ХД предприятия. Для наполнения таких витрин обычно используется инструментальное средство класса предприятия, реализующее стратегию "извлекаешь один раз, наполняешь много" (см. рисунок).
Достоинства постепенно развиваемых витрин данных
общая семантика и бизнес-правила.
единый набор процессов извлечения.
выполнимый масштаб.
пошаговая природа.
Недостатки
наиболее эффективны при использовании инструментального средства класса предприятия.
необходимость в архитектуре витрин данных предприятия ( Enterprise Data Mart Architecture , EDMA ).
требуется согласованность с EDMA по всем it-группам.
|
Архитектура ХД
В этой главе мы рассмотрим:
Corporate Information Factory
Реляционные базы данных
Что такое пространственная модель
Data Warehouse Bus
Объединенное
(федеративное) ХД
|
Corporate Information Factory, Корпоративное хранилище данных
Когда-то этот подход был известен под названием классического ХД ( Enterprise Data Warehouse , EDW). Корпоративное ХД является широко распространённым и уникальным репозиторием информации предприятия. Среда Хранилища предназначена только для чтения и состоит из детальных и агрегированных данных, которые полностью очищены и интегрированы; кроме того, в нем хранится обширная и детальная история данных на уровне транзакций. С точки зрения этого архитектурного решения ХД реализует свои функции, прежде всего, через подмножество зависимых Витрин данных.
Корпоративное ХД - хранилище данных - это:
проект корпоративного масштаба, охватывающий все отделы и обслуживающий нужды всех пользователей корпорации
не механическая коллекция Витрин Данных, а физически целостный объект.
Работа такого Хранилища начинается со скоординированного извлечения данных из источников. После этого загружается реляционная база данных с третьей нормальной формой, содержащая атомарные данные. Получившееся нормализованное ХД используется для того, чтобы наполнить информацией дополнительные репозитории презентационных данных, т.е. данных, подготовленных для анализа. Эти репозитории, в частности, включают специализированные Хранилища для изучения и "добычи" данных ( Data Mining ), а также Витрины Данных.
Реляционная база данных
Реляционная база данных - это совокупность отношений, содержащих всю информацию, которая должна храниться в базе. Физически это выражается в том, что информация хранится в виде двумерных таблиц, связанных по ключевым полям. В основе этих БД лежит реляционная модель, разработанная англо-американским ученым Эдгаром Коддом в 1960-70 гг.
При таком сценарии конечные Витрины данных создаются для обслуживания бизнес-отделов или для реализации бизнес-функций и используют пространственную модель для структурирования суммарных данных. Атомарные данные остаются доступными через нормализованное ХД. Очевидно, что структура атомарных и суммарных данных при таком подходе существенно различается.
Пространственная модель - dimensional model
Пространственная модель - это одна из моделей ХД, в которой данные организованы не по третьей нормальной форме, а в виде тематических таблиц, каждая из которых содержит характеристику отдельных категорий информации ( dimensions ). Основная цель пространственной модели - минимизировать время выполнения запроса, поэтому допускается денормализация данных. С этой же целью данные группируются вокруг центральной задачи (или вопроса), которую придется выполнять наиболее часто. Центральная таблица связана со всеми описательными таблицами, но последние напрямую не связаны между собой (так называемая архитектура "звезда").
Отличительные характеристики подхода Билла Инмона к архитектуре корпоративного ХД - хранилища данных :
использование реляционной модели организации атомарных данных и пространственной - для организации суммарных данных
использование итеративного или "спирального" подхода при создании больших ХД, т.е. "строительство" не сразу, а по частям. Это позволяет при необходимости вносить изменения в небольшие блоки данных или программных кодов и избавляет от необходимости перепрограммировать значительные объемы данных в ХД. То же самое можно сказать и о потенциальных ошибках: они также будут локализованы в пределах сравнительно небольшого массива без риска испортить все ХД
использование третьей нормальной формы для организации атомарных данных, что обеспечивает высокую степень детальности интегрированных данных и, соответственно, предоставляет корпорациям широкие возможности для манипулирования ими и изменения формата и способа представления данных по мере необходимости
Достоинства архитектуры корпоративного хранилища данных
непротиворечивость информации.
один набор процессов извлечения и бизнес-правил.
общая семантика.
централизованная, управляемая среда.
легко создаваемые и наполняемые витрины данных.
единый репозиторий метаданных.
Недостатки такого архитектурного решения ХД
реализация требует больших затрат.
высокая ресурсоемкость.
потребность в системах и ресурсах в масштабе всего предприятия.
рискованный сценарий ("все поставлено на карту").
|
Data Warehouse Bus - ХД с архитектурой шины
Альтернативный подход к архитектуре ХД, известен как ХД с архитектурой шины или подход Ральфа Кимболла.
В этой модели первичные данные преобразуются в информацию, пригодную для использования, на этапе подготовки данных. При этом обязательно принимаются во внимание требования к скорости обработки информации и качеству данных. Как и в модели Билла Инмона, подготовка данных начинается со скоординированного извлечения данных из источников. Ряд операций совершается централизованно, например, поддержание и хранение общих справочных данных, другие действия могут быть распределенными.
Область представления пространственно структурирована, при этом она может быть централизованной или распределенной. Пространственная модель ХД содержит ту же атомарную информацию, что и нормализованная модель, но информация структурирована по-другому, чтобы облегчить ее использование и выполнение запросов. Эта модель включает как атомарные данные, так и обобщающую информацию (агрегаты в связанных таблицах или многомерных кубах) в соответствии с требованиями производительности или пространственного распределения данных. Запросы в процессе выполнения обращаются к все более низкому уровню детализации без дополнительного перепрограммирования со стороны пользователей или разработчиков приложения.
В отличие от подхода Билла Инмона, пространственные модели строятся для обслуживания бизнес-процессов (которые, в свою очередь, связаны с бизнес-показателями или бизнес-событиями), а не бизнес-отделов. Например, данные о заказах, которые должны быть доступны для общекорпоративного использования, вносятся в пространственное ХД только один раз, в отличие от CIF-подхода, в котором их пришлось бы трижды копировать в витрины данных отделов маркетинга, продаж и финансов. После того, как в ХД появляется информация об основных бизнес-процессах, консолидированные пространственные модели могут выдавать их перекрестные характеристики. Матрица корпоративного ХД с архитектурой шины выявляет и усиливает связи между показателями бизнес-процессов (фактами) и описательными атрибутами (измерениями).
Типичные черты подхода Ральфа Кимболла
использование пространственной модели организации данных с архитектурой "звезда" ( star scheme ).
использование двухуровневой архитектуры, которая включает стадию подготовки данных, недоступную для конечных пользователей, и ХД с архитектурой шины как таковое. В состав последнего входят несколько витрин атомарных данных, несколько витрин агрегированных данных и персональная витрина данных, но оно не содержит одного физически целостного или централизованного ХД.
ХД с архитектурой шины обладает следующими характеристиками:
оно пространственное;
оно включает как данные о транзакциях, так и суммарные данные;
оно включает витрины данных, посвященные только одной предметной области или имеющие только одну таблицу фактов ( fact table );
оно может содержать множество витрин данных в пределах одной БД.
ХД не является единым физическим репозиторием (в отличие от подхода Билла Инмона). Это "виртуальное" ХД. Это коллекция витрин данных, каждая из которых имеет архитектуру типа "звезда".
|
Объединенное (федеративное) ХД
В наше время уже нет необходимости доказывать, как важно для многофилиальных корпораций наличие согласованной управленческой информации, необходимой для четкого понимания того, как функционирует бизнес. К сожалению, сегодня очень немногим компаниям удалось достичь высокого уровня информационного обеспечения.
Во многих организациях сложилась практика реализации многочисленных ХД. Хотя, по определению, существует только одно ХД, а все остальные объекты являются его подмножеством или постепенно развиваемыми витринами данных, не все организации придерживаются этого правила. Таким образом, во многих компаниях существует два, три, десяток и даже более систем ХД.
Обычной подход к улучшению информированности о бизнес-операциях - проведение стандартизации "сверху вниз" как структуры отчетности, так и модели данных. Однако с практической точки зрения стандартизация бизнес-структур оказывается для большинства организаций исключительно нецелесообразной - требуется слишком много средств, времени. Кроме того, данный подход может быть просто нереализуем, поскольку в любом бизнесе присутствует чрезвычайно мало простых и однообразных областей, которые не потребовали бы учета местной специфики. Если, например, можно стандартизировать коды валют по всей корпорации, введение полностью стандартизированной линейки продуктов редко оправданно, а в некоторых случаях - даже нежелательно.
Поэтому даже если стандартизацию и удалось бы полностью реализовать на практике, необходимость обеспечения согласованности лишала бы филиалы компании возможности приспосабливаться к условиям местного бизнеса и происходящим на нем изменениям. Такая ситуация чревата возникновениями противоречий между центральным офисом и местными отделениями - центральная система неспособна отвечать потребностям пользователей, а сотрудники филиалов не стремятся тщательно проверять качество данных, и поэтому возникает опасность, что данные, отправляемые в головной офис, могут оказаться ошибочными.
Выше описанные проблемы могут быть решены на основе подхода, в основе которого лежит создание Федеративного ХД. В соответствии с данным подходом, с помощью иерархии связанных ХД можно обмениваться данными, бизнес моделями и структурами отчетности, благодаря чему можно, с одной стороны, осуществлять общий контроль и предусмотреть определенную степень стандартизации, а, с другой - позволить региональным отделениям сохранить автономность и учесть местную специфику.
Система объединенных ХД характеризуется совместным использованием общих информационных точек, устраняя, таким образом, избыточность и гарантируя достоверность информации по всей организации (см. рисунок).
Федеративное ХД состоит из ряда экземпляров ХД, которые функционируют на полуавтономной основе и, как правило, организационно или географически разнесены, однако могут рассматриваться и управляться как одно большое ХД. Поскольку построение федеративного ХД можно осуществлять постепенно - "шаг за шагом", при его создании разумно воспользоваться методом "начинай с малого, планируй в глобальном аспекте". Такой подход существенно снижает риск неудачи при глобальном развертывании системы, поскольку каждое локальное ХД меньше по масштабу, незамедлительно отвечает местным требованиям и может управляться сотрудниками регионального бизнес-подразделения.
Каждый из экземпляров ФХД хранит копию базовой бизнес-модели и общие основные данные ( common master data ), причем каждое ХД более высокого уровня содержит итоговые транзакционные данные более низкого уровня. Общие основные данные - например, схема организационной структуры компании - отправляется «вниз», т.е. из корпоративного (глобального) ХД, а суммарные данные о транзакциях отправляются "верх", т.е. из локального ХД. Таким образом "федерация" ХД может предоставить местным отделениям необходимую гибкость, а также обеспечить общий контроль и согласованность; при этом каждое ХД функционирует независимо от всех других остальных.
Данный подход выгоден не только с точки зрения ежедневных операций, но и при процессе внедрения - при построении "федерации" ХД, которые позволяют вносить изменения, предприятия могут начать с одного единственного проекта, а затем построить корпоративную систему, добавляя новые ХД в соответствии с приоритетами бизнеса. Таким образом, возможность настройки используемых ХД с учетом изменений, снимает необходимость заранее устанавливать окончательную архитектуру, другими словами рискованный монолитный проект может быть разбит на многочисленные, менее крупные и рискованные, но более доходные проекты.
Достоинства системы объединенных ХД
общая семантика и бизнес-правила.
один набор процессов извлечения и бизнес-правил.
децентрализованные ресурсы и управление.
параллельная разработка.
Недостатки такого архитектурного решения
необходимость в координировании работ.
сложности в преодолении "политических" моментов и решении вопросов авторских прав.
требуется согласованность среди различных отделов по вопросам архитектуры, бизнес правил и семантики.
сложнейшая техническая среда.
очень часто наличие многочисленных репозиториев метаданных.
| |
Скачать 2.04 Mb.