Архитектурные решения и моделирование данных для хранилищ и витрин данных

начало и длительность — для хранения промежут ков времени используется одно поле даты (дата начала) и поле длительности периода. Большее распространение при создании статусных моделей получил способ "начало и конец" (рис.7).  

  

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

 

Выбор ключей 

Выбор ключей для  таблиц хранилища данных является непростой  задачей. Перед разработчиком модели хранилища встает вопрос: использовать ли в хранилище данных ключи из оперативных систем, и если нет, то — как их сформировать? Рассмотрим варианты решения этой задачи.

Использованиеключей из оперативных систем 

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

Генерация ключей 

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

Существует несколько  подходов к генерации ключей:

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

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

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

 

Вопросы целостности  данных 

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

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

Моделирование витрин данных 

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

Как правило, для  моделирования витрин данных используются типы модели под названием: схема "звезда" и схема "снежинка". Остановимся подробнее на каждом из этих типов моделей.

Схема "звезда" 

Схема "звезда" — популярный тип модели данных для витрин данных. Данная модель характеризуется  наличием таблицы фактов, окруженной связанными с ней таблицами размерностей. Запросы к такой структуре включают простые объединения таблицы фактов с каждой из таблиц размерностей. Характеризуется высокой производительностью запросов.  

Проектируется для выполнения аналитических запросов. Характеризуется небольшой избыточностью данных и высокой по сравнению с нормализованными структурами производительностью. Некоторые промышленные СУБД и инструменты класса OLAP/Reporting умеют использовать преимущества схемы "звезда" для сокращения времени выполнения запросов.  

На рисунке (рис.8) изображен пример схемы "звезда" для анализа остатков на счетах и  количества транзакций в разрезе  времени, клиентов, счетов, продуктов, отделений, статусов счетов. Данная модель позволяет ответить на широкий спектр аналитических вопросов.  

Давайте рассмотрим компоненты схемы "звезда".  

Размерности  

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

Типичные размерности, встречающиеся практически в любой модели:

Клиент 

Продукт

Время

География

Сотрудник  

Размерности, как  правило, имеют многоуровневую иерархическую  структуру. Например, размерность ВРЕМЯ  может иметь следующую структуру: ГОД КВАРТАЛ МЕСЯЦ ДЕНЬ  

Факты  

Факты — это  величины, обычно числовые, хранящиеся в таблице фактов и являющиеся предметом анализа. Примеры фактов: объем операций, количество проданных  единиц товара и т.д.  

Факты имеют  ряд свойств, на которых мы вкратце  остановимся. Более подробное описание фактов и их свойств можно найти в литературе [1, 8, 9].  

Аддитивные факты  

Аддитивность  определяет возможность суммирования факта вдоль определенной размерности.  

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

Полуаддитивные  факты  

Полуаддитивный  факт — это факт, который можно  сум мировать вдоль определённых размерностей, и нельзя — вдоль  других. Примером может служить остаток  на счете (или остаток товара на складе). Данную величину нельзя суммировать вдоль размерности ВРЕМЯ. Однако сумма остатков по счетам вдоль размерности смысл для анализа.  

Неаддитивные  факты  

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

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

Таблицы покрытия  

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

Схема "снежинка" 

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

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

Моделирование времени в витринах данных 

Витрины данных, как правило, характеризуются нали чием явной размерности ВРЕМЯ. При  этом структура данной размерности  может меняться в зависимости  от моделируемой предметной области и требований, предъявляемых пользователями к представлению времени.  

Помимо стандартных  атрибутов времени, как правило, возникает необходимость моделирования  специальных атрибутов времени, таких как:

Недели 

Времена года

Сезоны

Выходные и  праздники 

Рабочие смены  

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

Критерии, определяющие выбор инструментов для моделирования 

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

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

Поддержка традиционного ER-моделирования (для моделирования  хранилищ данных) и многомерного моделирования (для моделирования витрин данных)

Открытый репозиторий  метаданных (возможность обмена данными  с приложениями класса ETL, OLAP/Reporting, репозиториями  метаданных, инструментами контроля качества данных)

Поддержка коллективной разработки (контроль версий, checkin, checkout)

Поддержка свойств, определяемых пользователем (UDP) - для  расширения круга метаданных, поддерживаемых моделью 

Поддержка возможности  проверки качества моделей (стандарты  именования объектов, полнота описания объектов)

Поддержка повторного использования компонентов моделей

Поддержка обратного  проектирования (reverse engineering)

Многоплатформенность (поддержка промышленных СУБД)  

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

Литература 

1. Adamson, C., Venerable, M., "Data Warehouse Design Solutions". John Wiley & Sons, Inc (1998). ISBN 047125195X.  

2. Devlin, B., "Data warehouse: from architecture to implementation". Addison Wesley Longman, Inc. (1997). ISBN 0201964252.  

3. IBM, "Business Intelligence Architecture on S/390. Presentation Guide". SG24574700, IBM Corporation (2000).