Подходы к организации хранилища данных

Хранилища данных – это сравнительно новое технологическое решение, которое стало широко использоваться только в начале 1990-х годов, после того как Билл Инмон[447], опубликовал в 1991 году свою первую книгу по этой теме – «Построение хранилища данных»[448]. Хотя отдельные элементы этой концепции и их технические воплощения существовали и ранее начиная с 1970-х годов, только к концу 80-х была в полной мере осознана необходимость интеграции корпоративной информации и надлежащего управления ею, а также появились технические возможности для создания соответствующих систем, первоначально названных хранилищами информации (information warehouse)[449], а после выхода книги Инмона получивших свое нынешнее наименование хранилищ данных[450].

На сегодняшний день существует два основных подхода к архитектуре хранилищ данных. Это так называемая корпоративная информационная фабрика (Corporate Information Factory, CIF) Билла Инмона[451] и многомерное хранилище данных Ральфа Кимбалла[452][453].

Подход Инмона отражает метод проектирования «сверху вниз» и рассматривает хранилище как централизованное место хранения всех данных организации. После реализации централизованной модели данных для этого хранилища организации могут создавать на ее основе витрины данных (Data Marts, DM) – специальные хранилища для отдельных бизнес-направлений.

Подход Кимбалла основан на методе проектирования «снизу вверх». При этом подходе основным способом хранения данных являются витрины данных. Хранилище данных в целом представляет собой набор витрин, которые позволяют выполнять унифицированные аналитические задания, отчеты и другие необходимые процессы бизнес-аналитики[454].

Рассмотрим эти подходы подробнее.

 

14.1.4. Корпоративная информационная фабрика (архитектура Инмона)

DW, согласно определению Инмона, представляет собой предметно-ориентированный, интегрированный, поддерживающий привязку ко времени, неизменяющийся набор сводных и детализированных исторических данных. Исходя из этого определения, можно выделить основные концептуальные компоненты, которые формируют отличия хранилища данных от операционных систем (систем поддержки операционной деятельности организации)[455],[456].

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

● Интегрированность: данные в хранилище унифицированы и связаны. Используются единообразные для всех компонентов хранилища структуры ключей, кодов шифрования, определений данных и условных наименований. Поскольку данные в хранилище интегрированы, они не являются простой копией операционных данных. Вместо этого DW, по сути, система записи (system of record) данных[457]:

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

● Привязка ко времени: данные в записях DW сохраняются «как они есть» по состоянию на каждый заданный момент регистрации. По сути, записи в DW являются «моментальными снимками» состояния данных об описываемых объектах. Каждый снимок имеет метку времени. Как следствие, сколько бы вы ни запрашивали данные за один и тот же период времени, результаты выдачи будут неизменными вне зависимости от даты и времени обработки запроса.

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

● Исторические данные: операционные системы обрабатывают текущие данные, а в DW содержатся записи об истории операций, причем нередко в огромных объемах.

Хранилище на основе архитектуры Инмона построено в соответствии с реляционной моделью данных. Основные особенности реляционной модели были рассмотрены в главе 11 (см. раздел 11.2). Там мы, говоря о связях между сущностями и об атрибутах сущностей, выделили такие понятия, как первичный и внешний ключ. Прежде чем продолжить обсуждение особенностей корпоративной информационной фабрики, остановимся на понятии нормализации.

 

* Intersoft Lab. Основные подходы к архитектуре Хранилищ данных. Intersoft Lab: Журнал ВРМ World. 2005. – URL: https://iso.ru/ru/press-center/journal/2056.phtml.

 

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

Правила нормализации разделяют и организуют атрибуты в соответствии с первичными и внешними ключами. Правила последовательно распределяются по уровням, и на каждом следующем уровне повышается степень детализации и добавляются новые требования по учету специфики сущностей при подборе корректных первичных и внешних ключей. Каждому уровню соответствует отдельная так называемая нормальная форма (normal form, NF). Всего выделяют пять нормальных форм (они обозначаются номерами в соответствии с уровнем), но на практике, как правило, достаточно третьей (3NF). Под нормализованной моделью обычно понимают данные, приведенные в форму 3NF[458].

На рисунке 14.1 представлена укрупненная архитектура корпоративной информационной фабрики.

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

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

Подводя итог вышесказанному, можно выделить следующие отличительные характеристики архитектурного подхода Инмона[459].

● Использование реляционной модели организации детализированных данных и многомерной – для организации агрегированных данных.

● Использование итеративного подхода при создании больших хранилищ данных, построение хранилища не сразу, а по частям. Это позволяет при необходимости вносить изменения в небольшие блоки данных или программных кодов и избавляет от необходимости реструктурировать значительные объемы данных или осуществлять сложное перепрограммирование. То же можно сказать и о потенциальных ошибках: они также будут локализованы в пределах сравнительно небольшого массива данных без риска испортить все хранилище.

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

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

● Хранилище данных – это не механическая коллекция витрин данных, а физически целостный объект.

 

14.1.5. Многомерное хранилище данных (архитектура Кимбалла)

Архитектурный подход к представлению хранилища данных Кимбалла основан на многомерной структурной модели данных. Кимбалл определяет хранилище как копию транзакционных данных, особым образом структурированную для обработки запросов и анализа. «Копия» в данном контексте не означает точной копии оригинала. При переносе в хранилище данные подвергаются реструктуризации для обеспечения соответствия схеме многомерной модели, которая специально проектируется таким образом, чтобы сделать данные предельно понятными и полезными для потребителей, но при этом сохранить и достаточный для обработки запросов уровень формализации. Важнейшее отличие многомерных схем хранения данных от традиционных реляционных – отказ от нормализации[460],[461].

Многомерные модели, часто называемые также звездообразными схемами (star schema), представляют собой подборки фактов (facts), под которыми понимаются числовые данные или характеристики бизнес-процессов (например, объем продаж) в проекции на измерения (dimensions), которые используются для описания атрибутов, соответствующих фактам и позволяющих пользователям правильно интерпретировать фактические данные (например, с объемом продаж сопоставляются артикул продукта X и отчетный квартал). Таблица фактов связана со множественными таблицами измерений, и в графическом представлении такая схема организации данных имеет форму звезды, откуда и возникло название. При наличии в модели множественных таблиц фактов они проецируются на общие для различных таблиц так называемые конформные (conformed) измерения через шину (bus), подобную компьютерной шине[462]. Множественные витрины данных на корпоративном уровне могут интегрироваться посредством подключения их к общей шине конформных измерений.

Матрица шины DW отражает доступные фактические данные на пересечениях строк бизнес-процессов (фактов) и столбцов предметных областей (измерений). Возможности для интеграции через конформные измерения появляются там, где множественные процессы используют одни и те же данные[463].

В таблице 14.1 приведен простейший пример матрицы шины DW.

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

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

 

* DAMA. DAMA-DMBOK: Data Management Body of Knowledge: 2nd Edition. Technics Publications, 2017. (Русский перевод: DAMA-DMBOK: Свод знаний по управлению данными. Второе издание / Dama International. – М.: Олимп-Бизнес, 2020.)

 

На рисунке 14.2 представлена укрупненная архитектура многомерного хранилища данных.

 

* Intersoft Lab. Основные подходы к архитектуре Хранилищ данных. Intersoft Lab: Журнал ВРМ World. 2005. – URL: https://iso.ru/ru/press-center/journal/2056.phtml.

 

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

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

Хранилище содержит как детализированные, так и агрегированные данные, сформированные в соответствии требованиями в части производительности или пространственного распределения.

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

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

На основе вышесказанного можно выделить следующие отличительные характеристики архитектурного подхода Кимбалла[465]:

● использование многомерной модели данных;

● хранилище включает как детализированные данные о транзакциях, так и агрегированные.

● хранилище данных не служит единым физическим репозиторием (в отличие от подхода Инмона). Это виртуальное хранилище, представляющее собой набор витрин данных, каждая из которых имеет архитектуру «звезда».