Создание модели хранилища данных на основе корпоративной модели данных

Алгоритм преобразования корпоративной модели данных в модель хранилища данных

Общее описание алгоритма

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

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

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

Поскольку объемы сохраняемых данных в ХД очень велики, проектировщик должен решить вопрос, хранить или нет в ХД производные атрибуты (или вычисляемые поля). Сохранение в ХД вычисленных значений позволит увеличить производительность обработки запросов.

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

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

Далее проектировщик ХД может приступить к формированию схемы ХД типа "звезда" из таблиц корпоративной модели данных.

Таким образом, имеем базовый алгоритм преобразования корпоративной модели данных в модель ХД ( рис. 16.4):

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

Рис. 16.4. Базовый алгоритм преобразования корпоративной модели данных в модель хранилища данных

В модификации этого алгоритма, согласно У. Инмону (W.H Inmon), проектировщику ХД предлагается решить еще два вопроса.

Первый вопрос — о выявлении периодических групп данных или массивов данных и представлении их в модели ХД (отношения "многие ко многим").

Второй вопрос — о разделении атрибутов согласно параметрам стабильности, известном в дисциплине обработки данных как вопрос о "трех массивах". Исходный массив данных с точки зрения алгоритмов обработки разбивается на три массива: очень медленно обновляемый, периодически обновляемый и очень быстро обновляемый.

Рассмотрим основные шаги алгоритма подробнее.

Отбор данных из корпоративной модели

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

Ответ на этот вопрос можно получить непосредственно, как результат анкетирования или опроса заинтересованных лиц, а именно лиц, принимающих решения. Если возможность всестороннего анкетирования отсутствует, то проектировщик ХД пытается исключить из рассмотрения следующие данные:

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

На рис. 16.5 приведен пример отбора элементов данных сущности "Позиции заказа" ( Order Item ) корпоративной модели данных для модели ХД.

Рис. 16.5. Отбор данных корпоративной модели данных для модели ХД

Маловероятно, что атрибуты "Номер телефона" ( Phone ) и "Время вызова" ( Hour_call ) будут иметь значение для принятия решений спустя несколько месяцев после прохождения заказа. Поэтому эти атрибуты можно не включать в модель ХД.

Атрибуты "Позиция заказа" ( line_item ) — другими словами, закупаемый товар, "Стоимость" ( cost ) и "Количество" ( amount ) — практически всегда будут необходимы для анализа продаж. Эти атрибуты обязательно должны быть включены в модель ХД.

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

Добавление временных элементов

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

Тогда при импорте данных из OLTP-системы в ХД будет выполняться мгновенный снимок данных сущности, который будет фиксировать состояние объекта в момент импорта.

Проектировщик ХД должен ввести в модель ХД временную метку, соответствующую времени сохранения снимка в ХД. На рис. 16.6 приведен пример добавления атрибута " Временная метка " ( Time_of_snapshot ) в модель ХД для сущности "Покупатель" ( Customer ) как часть ключа сущности.

Рис. 16.6. Добавление временной метки в модель ХД

Если в сущностях, переносимых из корпоративной модели данных в модель ХД, временные атрибуты входят в составной ключ сущности, то никаких действий проектировщика ХД по изменению ключа сущности не требуется.