М одели данных, используемые для построения хранилищ

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

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

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

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

С другой стороны, имеются существенные ограничения:

• 
  многомерные СУБД не позволяют работать с большими объемами данных. К тому же за счет денормализации и предварительно выполненной агрегации объем данных в многомерной базе, как правило, соответствует в 2,5—100 раз меньшему объему исходных детализированных данных;
  
• 
  м ногомерные СУБД по сравнению с реляционными очень неэффективно используютвнешнюю память. В подавляющем большинстве случаев информационный гиперкуб является сильно разреженным, а поскольку данные хранятся в упорядоченном виде, неопределенные значения удается удалить только за счет выбора оптимального порядка сортировки, позволяющего организовать данные  в  максимально  большие   непрерывные  группы.   Но даже  в этом  случае  проблема решается лишь частично. Кроме того, оптимальный с точки зрения хранения разреженных данных порядок сортировки, скорее всего, не будет совпадать с порядком, который чаще всего используется в запросах. Поэтому в реальных системах приходится
  искать компромисс между быстродействием и избыточностью дискового пространства, занятого базой данных.
  

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