3.3.1. Структура хранения информации в Хранилище

Далее рассмотрим структуру хранения информации в Хранилище. Мы помним, что Хранилище создается для целей поддержки принятия решений. Наше мышление многомерно. Принимая решение о целесообразности расширения торгового предприятия в каком-то регионе, мы, например, анализируем объемы продаж в зависимости от многих факторов: численности населения региона, его среднего достатка, наличия конкурирующих организаций и так далее. Очевидно, чтобы быстро получить отчет с результатами такого анализа, необходимо, чтобы база данных Хранилища также была многомерной [69]. В таких базах информация располагается как бы в многомерном кубе. Результаты бизнес -процессов являются фактами, которые характеризуются параметрами -мерами. Например, факт продажи характеризуется мерами: полученная от продажи сумма, объем проданного товара. Факты зависят от измерений: квартала, артикула товара, города (рис. 28). Расположение информации в такой структуре напоминает расположение в электронной таблице (например, Excel), если сделать, например, такие таблицы для каждого города (рис. 28) и собрать их вместе. Тогда каждая такая таблица будет показывать динамику продаж в отдельно взятом городе в зависимости от квартала и артикула товара. Можно сделать "срезы" куба по кварталам или артикулам товара. Измерения могут быть организованы в иерархическую структуру (рис. 29). Это позволяет реализовывать более сложные запросы к базе. Информация об иерархии измерений хранится в области метаданных (рис. 18) [70].

Типы запросов к базе

• Средства реализации запросов для многомерных баз данных позволяют делать "срезы" информации для менеджеров разных направлений. Можно выбрать "срез" только для одного города, для одного артикула товара, для одного квартала. Возможен и одновременный показ трех и более размерностей, но этот вариант мы проиллюстрируем позже (см. технологии OLAP).

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

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

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

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

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

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