Сейчас на сайте
Сейчас на сайте 0 пользователей и 0 гостей.

Таблица измерений

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

В сложных задачах с многоуровневыми измерениями используется расширение схемы "звезда" - схема созвездие (fact constellation schema) и схема "снежинка" (snowflake schema).

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

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

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

Схема снежинки (Snowflake schema)

На рисунке приведен фрагмент для одного измерения в схеме "снежинка". Схема снежинки (Snowflake schema) то же, что и схема звезды, но с нормализованными таблицами измерений. При такой структуре БД большинство запросов из области делового анализа объединяют центральную таблицу фактов с одной или несколькими таблицами измерений.

схема снежинки

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

Переход от OLTP к звездной схеме позволяет получить выигрыш в аналитических запросах, несмотря на то, что с точки зрения реляционной модели OLAP противоречит всем правилами нормализации, ибо здесь имеется масса избыточности, вычисляемых полей и т.д. В частности, повышая степень денормализации, любую "снежинку" можно привести к канонической "звезде". Далее, куб вообще можно представить в виде одной плоской таблицы, выписывая построчно все комбинации членов всех измерений с соответствующими им величинами мер. Примерно так, с точностью до пустот хранятся данные в истинно многомерном MOLAP кубе. Куб не хранит пустоты с целью экономии места. Ключи (координаты по измерениям) кодируются и сжимаются до 4 - 8 байт. Для быстрого доступа к значениям в кубах используются битовые индексы. Все сказанное означает, что MOLAP намного эффективнее проявляет себя в хранении, чем ROLAP, и при одинаковых объемах данных потребляет меньше места на диске, чем ROLAP-хранилище. Меньше места - меньше операций ввода/вывода. Кроме того, MOLAP не нуждается в отработке многочисленных join'ов, не заботится о блокировках, так как все операции происходят на чтение, и работает только с численными данными (мерами не могут быть строки, BLOBы и т.п.). Следовательно, MOLAP намного быстрее, чем ROLAP. Аналитические запросы к многомерным кубам имеют простую и компактную форму.