1.5.2. Понятие о хранилищах данных

Хранилище данных (по определению автора концепции хранилища данных Б. Инмона [9]) – это “предметно-ориентированные, интегрированные, неизменчивые, поддерживающие хронологию наборы данных, организованные для целей поддержки принятия решений” В этом определении под интеграцией данных понимается объединение и согласованное представление данных из различных источников. “Поддержка хронологии” означает наличие “исторических” данных, т.е. данных, соответствующих интервалу времени, предшествующему текущему моменту. Неизменчивость данных означает, что изменение данных в хранилище осуществляется путем добавления новых данных, соответствующих определенному временному интервалу без изменения информации, уже находящейся в хранилище. К основным требованиям, предъявляемым к хранилищам данных относятся:

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

• поддержка внутренней непротиворечивости данных;

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

• наличие удобных средств для просмотра данных в хранилище;

• полнота и достоверность хранимых данных.

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

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

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

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

• данные не дублируются (т.е. в базе данных отсутствует избыточность).

Такое представление данных не всегда соответствует целям поддержки принятия решений, когда возникает необходимость быстрого получения ответов на сложные аналитические запросы. Более адекватной здесь является логическая модель данных в виде многомерного куба [10]. Куб – это геометрическая фигура с тремя измерениями. Кубы данных на практике имеют от 4 до 12 измерений. Измерение в кубе – это одна из характеристик данных. Например, в кубе, показанном на рис. 1.2, измерениями являются “время” (2001 г., 2002 г.), “пункт назначения” (Москва, Санкт-Петербург), “груз” (бензин, уголь). В ячейках куба хранятся данные об объёмах перевозок. Эти данные агрегированы по другим измерениям. Например, для куба на рис.1.2, если существуют измерение “пункт отправки”, то приведенные на рис.1.2 данные следует рассматривать как агрегированные по этому измерению (т.е. “1000” это есть общая масса угля, завезенного в Москву в 2001 году от всех поставщиков). На многомерном кубе легко определить множество операций, которые типичны при аналитической работе: сокращение числа измерений (проекции), слияние (объединение кубов, имеющих общие измерения) и т.д. Например, при агрегировании по измерению “груз” куб рис.1.2 превращается в квадрат, показанный на рис.1.3.

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

Надо отметить, что измерения многомерного куба могут иметь иерархическую структуру. Например, измерение “пункт отправки” может быть представлено трехуровневой иерархической схемой (см. рис.1.4).

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

Мы рассмотрели логическую модель хранилища, представляющую данные в виде совокупности многомерных кубов. Физическая реализация хранилища обычно осуществляется одним из следующих способов [10]:

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

• с использованием для хранения данных реляционных баз данных;

• гибридное решение: детальные данные хранятся в базах реляционного типа, а агрегатированные – в специальных многомерных структурах.