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

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

Многомерный OLAP (MOLAP). В специализированных СУБД, иных на многомерном представлении данных, данные организованы не в форме реляционных таблиц, а в виде упорядоченных многомерных массивов:

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

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

Использование многомерных БД в системах оперативной аналитической обработки имеет следующие достоинства.

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

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

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

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

Следовательно, использование многомерных СУБД оправдано только при следующих условиях:

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

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

• время ответа системы на нерегламентированные запроск является наиболее критичным параметром;

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

Реляционный OLAP (ROLAP). Непосредственное использова­ние реляционных БД в системах оперативной аналитической об­работки имеет следующие достоинства.

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

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

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

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

Идея схемы звезды (star schema) заключается в том, имеются таблицы для каждого измерения, а все факты помеодну таблицу, индексируемую множественным ключом, составленным из ключей отдельных измерений (рис. 5.19). Каждый луч схемы звезды задает (в терминологии Кодда) направление консолидации данных по соответствующему измерению.

В сложных задачах с многоуровневыми измерениями имеет мысл обратиться к расширениям схемы звезды — схеме созвездия (fact constellation schema) и схеме снежинки (snowflake schema). В этих случаях отдельные таблицы фактов создаются для возможных сочетаний уровней обобщения раз­личных измерений (рис. 5.20). Это позволяет добиться лучшей производительности, но часто приводит к избыточности данных и к значительным усложнениям в структуре базы данных, в которой оказывается огромное количество таблиц фактов.

В любом случае, если многомерная модель реализуете виде реляционной базы данных, следует создавать длинные В «узкие» таблицы фактов и сравнительно небольшие и «широки И таблицы измерений. Таблицы фактов содержат численные значения ячеек гиперкуба, а остальные таблицы определяют содержащий их многомерный базис измерений. Часть информации можно получать с помощью динамической агрегации данных распределенных по незвездообразным нормализованным струк­турам, хотя при этом следует помнить, что включающие агрега­цию запросы при высоконормализованной структуре БД могут выполняться довольно медленно.

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

Возможны гибридные системы (Hybrid OLAP — HOLAP), цель которых — совмещение достоинств и минимиза­ция недостатков, присущих предыдущим классам.