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

Константин Лисянский, архитектор хранилищ данных линии программных продуктов DiasoftMIS

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

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

Основные отличия систем поддержки принятия решений от традиционных оперативных систем

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

На данный момент существует масса публикаций, в которых эти отличия рассматриваются весьма подробно [4, 6, 8]. Такой анализ выходит за рамки данной статьи, по этому мы ограничимся отличиями, влияющими на приемы моделирования тех и других систем.

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

Варианты архитектуры СППР

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

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

• Функциональная СППР.
• Независимые витрины данных.
• Двухуровневое хранилище данных.
• Трехуровневое хранилище данных.

Функциональная СППР

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

Характерной чертой функциональной СППР является то, что анализ осуществляется с использованием данных из оперативных систем.

Преимущества:

• Быстрое внедрение за счет отсутствия этапа пере грузки данных в специализированную систему
• Минимальные затраты за счет использования одной платформы. Недостатки:
• Единственный источник данных, потенциально сужающий круг вопросов, разрешаемых системой
• Оперативные системы характеризуются очень низким качеством данных с точки зрения их роли в поддержке принятия стратегических решений. В силу отсутствия этапа очистки данных данные функциональной СППР, как правило, обладают невысоким качеством
• Большая нагрузка на оперативную систему. Сложные запросы могут привести к остановке ра боты оперативной системы, что весьма нежелательно.

СППР с использованием независимых витрин данных

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

Преимущества:

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

Недостатки:

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

СППР на основе двухуровнего хранилища данных

Двухуровневое хранилище данных (рис.3) строится централизовано для предоставления информации в рам ках компании. Для поддержки такой архитектуры необхо дима выделенная команда профессионалов в области хра нилищ данных.

Это означает, что вся организация должна согласовать все определения и процессы преобразования данных.

Преимущества:

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

Недостатки:

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

СППР на основе трехуровневого хранилища данных

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

Преимущества:

• Создание и наполнение витрин данных упрощено, поскольку наполнение происходит из единого стан дартизованного надежного источника очищенных нормализованных данных
• Витрины данных синхронизированы и совместимы с корпоративным представлением. Имеется корпо ративная модель данных. Существует возможность сравнительно легкого расширения хранилища и добавления новых витрин данных
• Гарантированная производительность

Недостатки:

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

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

Подробное описание преимуществ и недостатков каждого варианта архитектуры можно найти в литературе [2, 3].

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

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

Особенности моделирования времени в хранилищах данных

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

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

Модель снимков данных

Снимок данных — это представление данных в опре деленный момент времени. Данная модель характерна для оперативных систем (OLTP). Обновления данных носят деструктивный характер, то есть предыдущие значения атрибутов замещаются новыми (рис. 5). Модель имеет достаточно ограниченный круг применения в хранилищах данных, поскольку не обеспечивает хранения истории изменений.

Событийная модель

Событийная модель (рис. 6) используется для модели рования данных о наступлении событий в определенные моменты времени. Данная модель хорошо подходит для моделирования транзакций, таких как: продажи, финансовые транзакции, складские операции и т.д.

Статусная модель

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

Существует три способа моделирования изменяющих ся во времени статусов:

• непрерывная модель — для хранения промежутков времени используется одно поле даты. Дата начала следующего периода совпадает с датой окончания предыдущего;
• начало и конец — для хранения промежутков времени используется два поля — дата начала и дата окончания периода действия статуса;
• начало и длительность — для хранения промежут ков времени используется одно поле даты (дата начала) и поле длительности периода. Большее распространение при создании статусных моделей получил способ "начало и конец" (рис.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).

4. IBM, "Business Intelligence Certification Guide". SG24574700, IBM Corporation(2000).

5. IBM, "Data Modeling Techniques for Data Warehousing". SG24223800, IBM Corporation (1998).

6. Inmon, W., "What is a data warehouse?" White Paper.

7. Kimball, R., "A Dimensional Modeling Manifesto". DBMS Magazine. August 1997.

8. Kimball, R., "The Data Warehouse Toolkit. Practical Techniques for Building Dimensional Data Warehouses". John Wiley & Sons, Inc (1996). ISBN 0471153370.

9. Kimball, R. et al., "The Data Warehouse Lifecycle Toolkit: Expert Methods for Designing, Developing and Deploying Data Warehouses". John Wiley & Sons, Inc (1998). ISBN 0471255475.

10. Silverston, L., Inmon, W., Graziano, K., "The Data Model Resource Book. A Library of Logical Data Models and Data Warehouse Designs". John Wiley & Sons, Inc (1997). ISBN 0471153672.

11. Winsberg, P., "Modeling the Data Warehouse and Data Mart". InfoDB, 10, No 3, 110

12. Hitchhiker’s Guide to Decision Support (http://members.aol.com/fmcguff/dwmodel/)