Проектирование хранилищ данных

Хранилища данных (Data Warehouse) предназначены для хранения данных, которые редко меняются, но на основе которых часто требуется выполнение сложных запросов. Обычно они ориентированы на выполнение аналитических запросов, которые обеспечивают поддержку принятия решений для руководителей и менеджеров. Хранилища данных разгружают промышленные БД, и тем самым позволяют пользователям более эффективно и быстро извлекать необходимую информацию. К проектированию хранилищ данных предъявляются следующие требования:

Структура данных должна быть понятна пользователям;

Должны быть выделены статические данные, которые модифицируются по расписанию: ежедневно, еженедельно, ежеквартально;

Должны быть упрощены требования к запросам с целью исключения запросов, которые могли бы требовать множественных утверждений SQL в традиционных реляционных СУБД;

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

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

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

Схема "звезда" обычно содержит одну большую таблицу, называемую таблицей факта (fact table), помещенную в центр, и окружающие ее меньшие таблицы, называемые таблицами размерности (dimensional table), соединенные с таблицей факта в виде звезды радиальными связями. В этих связях таблицы размерности являются родительскими, таблица факта - дочерней. Схема "звезда" может иметь также консольные таблицы (outrigger table), присоединенные к таблице размерности. Консольные таблицы являются родительскими, таблицы размерности - дочерними.

В размерной модели иконка показывает роль таблицы в схеме "звезда":

Прежде чем создать БД со схемой типа звезды, необходимо проанализировать бизнес-правила предметной области с целью выяснения центрального вопроса, ответ на который наиболее важен. Все прочие вопросы должны быть объединены вокруг этого основного вопроса, и моделирование должно начинаться с этого основного вопроса. Данные, необходимые для ответа на этот вопрос, должны быть помещены в центральную таблицу модели - таблицу факта. Например, если необходимо создавать отчеты об общей сумме дохода от продаж за определенный период как по типу товара, так и по продавцам, следует разрабатывать модель так, чтобы каждая запись в таблице факта представляла сумму продаж, осуществленных тем или иным продавцом, с указанием доходов по каждому покупателю и типов проданных товаров (рис. 2.87). В примере таблица факта содержит суммарные данные о продажах (SALE), а таблицы размерности содержат данные о заказчике и заказах (CUSTOMER), продуктах (PRODUCT), продавцах (SALESPEOPLE) и периодах времени (TIME).

Рис. 2.87. Схема звезда

Таблица факта является центральной таблицей в схеме "звезда". Она может состоять из миллионов строк и содержать суммирующие или фактические данные, которые могут помочь ответить на требуемые вопросы. Она соединяет данные, которые хранились бы во многих таблицах традиционных реляционных БД. Таблица факта и таблицы размерности связаны идентифицирующими связями, при этом первичные ключи таблицы размерности мигрируют в таблицу факта в качестве внешних ключей. В размерной модели направления связей явно не показываются - они определяются типом таблиц. Первичный ключ таблицы факта целиком состоит из первичных ключей всех таблиц размерности. В примере (таблица факта SALE) первичный ключ составлен из четырех внешних ключей: Customer ID, SalespeopleID, TimeID и ProductID.

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

В примере на рис. 2.87 таблица SALE - таблица факта; CUSTOMER, TIME, SALESPEOPLE и PRODUCT - таблицы размерности, которые позволяют быстро извлекать информацию о том, кто и когда сделал покупку, какой продавец и на какую сумму продал и какие именно товары были проданы.

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

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

Если денормализованная таблица размерности получается слишком большой, при этом к части колонок запросы делаются чаще, чем к остальным, целесообразно для повышения эффективности разбить одиночную таблицу размерности на две отдельные таблицы размерности. Две полученные таблицы можно связать неидентифицирующей связью. В примере на рис. 2.87 таблица размерности PRODUCT'содержит как информацию о конкретном товаре, так и информацию о типах товаров. Если запросы, связанные с типами товаров, делаются чаще, чем по отдельным товарам, можно создать новую таблицу PRODUCT_TYPE и перенести в нее информацию о типах (рис. 2.89). В этом случае за счет того, что колонки, к которым наиболее часто обращаются запросы, переносятся в новую таблицу, уменьшается время выполнения запроса.

Рис. 2.89. Нормализация таблиц размерности

ERwin поддерживает методологию размерного моделирования благодаря использованию специальной нотации для физической модели -Dimensional. Наиболее простой способ перейти к нотации Dimensional -при создании новой модели (меню File/New) в диалоге ERwin Teamplate

Selection выбрать из списка предлагаемых шаблонов DIMENSION (рис. 2.90).

В шаблоне DIMENSION сделаны все необходимые для поддержки нотации размерного моделирования настройки, которые, впрочем, можно

установить вручную, преобразовав обычную диаграмму в размерную модель:

Рис. 2.90. Выбор шаблона DIMENSION

Для физического уровня выбрана методология DM (Dimensional Modeling). Эта опция устанавливается в закладке Methodology диалога Preferences (меню Option/Preferences), рис. 2.91. При этом показываются иконки размерности для таблиц. В списке выбора в левой части панели инструментов физический уровень показывается как Dimensional и изменяется вид палитры инструментов на физическом уровне (рис. 2.92).

Рис. 2.91. Выбор нотации DM

Установлена опция отображения связей диагональными линиями (Orthogonal). (Устанавливается в группе Relationship lines закладки General диалога Stored Display Editor, меню Edit/Stored Display.)

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

Рис. 2.92. Палитра инструментов размерной модели

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

таблица факта не является в связи дочерней (рис. 2.93);

консольная таблица не является в связи родительской;

установлена идентифицирующая связь между консольной таблицей и таблицей факта.

Рис. 2.93. Предупреждение о нарушении синтаксиса

Для внесения новой таблицы в модель можно воспользоваться кнопкой в палитре инструментов. В диалоге описания свойств таблицы Table Editor появляется новая закладка Dimensional, в которой задаются специфические свойства таблицы в размерной модели (рис. 2.94):

Роль таблицы в схеме (Dimensional Modeling Role). По умолчанию Erwin автоматически определяет роль таблицы на основании созданных связей (таблица факта, размерности или консольная). Таблица без связей определяется как таблица размерности, таблица факта не может быть родительской в связи, таблица размерности может быть родительской по отношению к таблице факта, консольная таблица может быть родительской по отношению к таблице размерности. Для задания роли таблицы вручную необходимо выключить опцию Calculate Automatically.

Рис. 2.94. Закладка Dimensional диалога Table Editor

Тип таблицы размерности (Dimension Type). Каждая таблица размерности может содержать неизменяемые либо редко изменяемые данные (slowly changing dimensions). Поскольку хранилище данных имеет ненормализованную структуру, редактирование таблиц размерности может привести к коллизиям. Для того чтобы избежать противоречий при хранении данных, ERwin позволяет задать тип редко изменяемых данных, который отличается способом редактирования данных:

Перезаписывание старых данных новыми. При этом старые данные теряются.

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

Запись новых данных в дополнительном поле той же самой записи. В этом случае сохраняется первоначальное и последнее новое значение. Все промежуточные данные теряются.

Правила хранения данных (Data Warehouse Rules). Для каждой таблицы можно задать шесть типов правил манипулирования данными: обновление (Refresh), дополнение (Append), резервное копирование (Backup), восстановление (Recovery), архивирование (Archiving) и очистка (Purge). Для задания правила следуем выбрать имя правила из соответствующего списка выбора. Каждое правило должно быть предварительно описано в диалоге Data Warehouse Rule Editor (меню Edit/Data Warehouse Rule) (рис. 2.95).

Список в верхней части диалога показывает все описанные правила. Для каждого правила должно быть задано имя, тип, определение. Например, определение правила дополнения данных может включать частоту и время дополнения (ежедневно, в конце рабочего дня), продолжительность операции и т. д. Связать правила с определенной таблицей можно не только с помощью диалога Table Editor, но и непосредственно из Data Warehouse Rule Editor (закладка Attachment).

Рис. 2.95. Диалог Data Warehouse Rule Editor

При проектировании хранилища данных важно определить источник данных (для каждой колонки), метод, которым исходные данные извлекаются, преобразуются и фильтруются, прежде чем они импортируются в хранилище данных. Хранилище данных может объединять информацию из текстовых файлов и многих БД, как реляционных, так и нереляционных, в единую систему поддержки принятия решений. Чтобы поддерживать регулярные обновления и проверки качества данных, необходимо знать источник для каждой колонки в хранилище данных. Для документирования информации об источниках данных используется редактор Data Warehouse Source Editor (рис. 2.96).

Рис. 2.96. Диалог Data Warehouse Source Editor

Внести новый источник можно щелкнув по кнопке WS в списке источников. Имена таблиц и колонок источников данных могут быть импортированы как из БД, так и из других моделей ERwin (закладка Detail, кнопка Import). Каждому источнику может быть задано имя и определение.

В закладке Data Source редактора Column Editor (рис. 2.97) можно внести информацию об использовании источников данных для каждой колонки в таблице. В поле Transform Comment вносится дополнительная информация о переносе данных из источника в хранилище данных.

Рис. 2.97. Диалог Column Editor

Для выбора источника данных следует щелкнуть по кнопке Д| в правой верхней части закладки Data Source. Появляется диалог Data Warehouse Source Selector (рис. 2.98), в окне Available Sources которого показываются все предварительно описанные источники. Для выбора источника следует выбрать в списке необходимую колонку и щелкнуть по кнопке Select.

Дата добавления: 2017-01-14