Л. Партыка, И. И. Попов системы управления базами данных



бет73/215
Дата29.01.2022
өлшемі4,64 Mb.
#115817
1   ...   69   70   71   72   73   74   75   76   ...   215
Байланысты:
Голицына О Л Партыка Т Л Попов И И Системы

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

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

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

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

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

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



Рис. 2.27. Пример схемы «звезда»

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

Рис. 2.28. Пример схемы «снежинка» (фрагмент для одного измерения)

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

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

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

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





Достарыңызбен бөлісу:
1   ...   69   70   71   72   73   74   75   76   ...   215




©engime.org 2024
әкімшілігінің қараңыз

    Басты бет