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

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

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

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

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

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

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

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

запросов к БД.

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

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

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

- Таблица факта (fact table);

- Таблица размерности (dimensional table);

- Консольная таблица (outrigger table).

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

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

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

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

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

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

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

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

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

ER-win поддерживает методологию размерного моделирования благодаря использованию специальной нотации для физической модели, Dimensional. Наиболее простой способ перейти к нотации Dimensional, при создании новой модели (меню File/New) в диалоге ER-win Teamplate Selection выбрать из списка предлагаемых шаблонов DIMENSION (рис. 2.90).

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

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

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