I квартал 2011

IV квартал 2010

III квартал 2010

II квартал 2010

Пермь

Казань

Коломна

I квартал 2010

Тверь

Москва

А23

А24

А25

А26

А27

А28

А29

А30

А31

Рис.4.7 – Пример куба данных по мерам Квартал, Артикул, Город.

Такая структура хранения данных позволяет реализовать следующие типы запросов к базе:

- Средства реализации запросов для многомерных баз данных позволяют делать «срезы» информации для менеджеров разных направления.

Можно выбрать «срез» только для одного города, для одного артикула товара, для одного квартала. Возможен и одновременные показ трех и более размерностей, но это уже OLAP-технология.

- наличие иерархии измерения [4] (рис.4.8) позволяет реализовать запрос, указывая только одну из мер.

Например, можно указать страну или только год. При этом данные, соответствующие разным городам одной страны или разным кварталам одного года, агрегируются.

- Запросы из нескольких кубов, имеющих одинаковые измерения.

Страна

Год

Артикул

Город

Квартал

Рис.4.8 – Иерархия измерений.

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

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

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

В этом случае информация о фактах и измерениях хранится в отдельных плоских таблицах, связанных с помощью ключевых полей. Простейшая схема организации связей называется «звезда» [4] (рис.4.9). Эта же схема часто используется для хранения информации в витринах данных. Схема проектируется с учетом построения будущих аналитических запросов.

Факты-Продаж

●	Ключ времени
●	Ключ заказчика
●	Ключ товара
	Сумма продажи
	Объем продаж

Размерность-Время

●	Ключ времени
	День года
	День месяца
	Месяц
	Квартал
	Год

Размерность-Заказчик

●	Ключ заказчика
	Наимен. компании
	Имя контакт лица
	Адрес
	Город
	Телефон

Размерность-Товары

●	Ключ товары
	Артикул товара
	Наимен. товара
	Описание товара
	Категория товара
	Цена продукта

Рис.4.9 – Схема организации связи при реляционном подходе.

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

Время-День

Товар

Заказчик

Время-Месяц

Категория

товара

Регион

Город

Страна

Время-Год

Рис.4.10 – Иерархия размерности.

При использовании такой иерархии приходим к схеме типа «снежинка» (рис.4.11) [4], которая и помогает избежать дублирования информации. Характеристики повторяющихся данных хранятся в отдельных таблицах (например, регион) и связаны ключами с верхними уровнями иерархии размерностей.