Проектирование информационно-аналитической системы на основе хранилища данных

Методология проектирования и построение хранилища данных

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

• · Схема «Звезда»;
• · Схема «Снежинка»;
• · Схема «Data Vault».

Прежде чем приступить к анализу возможных методов построения хранилища данных, необходимо ввести следующие определенияInmon W.H. Building the Data Warehouse. John Wiley & Sons Inc., 2002, 432 p.:

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

Теперь рассмотрим каждый метод подробно.

Схема «Звезда»Горбач И.В. Microsoft SQL Server 2005 Analysis Services. OLAP и многомерный анализ данных. М.: БХВ-Петербург, 2007, 928 с.

Схема «Звезда» (рис.5) состоит из одной таблицы фактов, окруженной таблицами измерений. Главной считается таблица фактов, которая содержит суммируемые или фактические данные и может включать в себя несколько миллионов строк. Что касается таблиц измерений, то они имеют меньшее количество строк, чем таблица фактов и содержат описательную информацию. При соединении таблиц фактов и измерений с помощью идентифицирующей связи первичный ключ таблицы измерений мигрирует в таблицу фактов в качестве внешнего ключа, прописанного в поле таблицы фактов как суррогатный ключ.

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

Рисунок 5 Схема «Звезда».

Схема «Снежинка»¹⁴

Схема «Снежинка» (рис.6) является разновидностью схемы типа «звезда». В основе лежит одна таблица фактов, окруженная таблицами измерений. Однако в отличие от схемы «звезда», здесь некоторые атрибуты агрегации вынесены в отдельные таблицы. В схеме «снежинка» агрегированные данные могут храниться отдельно от исходных данных.

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

Рисунок 6 Схема «Снежинка» .

Схема «Data Vault» (DV)Материалы Web-сервера [Электронный ресурс]: http://www.olap.ru/.

В основу данной архитектуры также вошла схема «звезда». В отличие от предыдущих схем, DV (рис.7) может обрабатывать массивные наборы данных, занимая при этом значительно меньше физического места. В роли таблиц, хранящих уникальные ключи, выступают Хабы. Таблицы также содержат поля с дополнительными данными для отслеживания изменений: искусственный ID, дата загрузки в хранилище данных, источник данных и т. д. Отличительной особенностью Хабов является отсутствие поля внешних ключей. Все таблицы Хаб связаны между собой с помощью Линков, содержащих такие поля как искусственный ID, суррогатные ключи Хабов, дату загрузки и источник данных. В роли таблицы измерения здесь выступает компонент Сателлит, включающий в себя информацию о Хабах и Линках. Данная таблица состоит из искусственного ID Хаба или Линка, даты загрузки, дату окончания, источника данных. Аналогично Хабу, Сателлит не включает в себя внешних ключей.

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

Рисунок 7 Схема «Data Vault».

Итак, проанализированы три методологии построения хранилища данных. Возвращаясь к задачам данной работы, изложенных выше, отметим, что архитектура «Звезда» в полной мере не удовлетворяет заданным требованиям для выполнения поставленной задачи. Отсутствие агрегированных таблиц упрощает построение хранилища данных, сужая функционал задачи. Архитектура Data Vault, на первый взгляд, демонстрирует приемлемую гибкость своей модели, но существенен факт сложных и длительных ETL-процессов загрузки данных в хранилище данных, что также негативно сказывается на продуктивности выполнения поставленной цели. В конечном счете, несмотря на недостаток, выбрана схема «снежинка», чья архитектура соответствует критериям, необходимым для реализации поставленной задачи.