Метаданные

Данные о данных

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

Плотная БД (Dense DB)

Хотя MOLAP обеспечивает лучшую производительность, но их структуры нельзя использовать для обработки больших объемов данных, поскольку большая размерность потребует больших аппаратных ресурсов, а вместе с тем плотность гиперкубов может быть очень низкой и, следовательно, использование аппаратных мощностей не будет оправданным. Наоборот, ROLAP обеспечивает обработку на больших массивах хранимых данных, так как возможно обеспечение более экономичного хранения, но, вместе с тем, значительно проигрывает в скорости работы многомерной. Плотная БД (Dense DB) – это многомерная база данных, если относительно высокий процент (по крайней мере, 10%) возможных комбинаций ее измерений содержит данные.

Агрегатные данные могут помещаться в служебные таблицы в той же БД. Преобразование данных из реляционной БД в многомерные кубы происходит по запросу OLAP-средства. При этом скорость построения куба будет сильно зависеть от типа источника данных и порой приводит к неприемлемому времени отклика системы. Для большинства ХД наиболее эффективным способом моделирования N-мерного куба фактов является схема "звезда" (star schema).

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

Основными составляющими структуры ХД являются таблица фактов (fact table) и таблицы измерений (dimension tables).

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

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

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

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

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

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

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

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

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

Таблица фактов (итогов) (Summary tables) является основной таблицей ХД. Это таблицы, которые содержат предварительно вычисленные на основе первичных данных, и для увеличения производительности запросов создаются по наиболее часто используемым измерениям. Как правило, она содержит сведения об объектах или событиях, совокупность которых будет в дальнейшем анализироваться. Если проводить аналогию с многомерной моделью, то строка таблицы фактов соответствует ячейке гиперкуба. Обычно говорят о четырех наиболее часто встречающихся типах фактов. К ним относятся факты, связанные с:

транзакциями (Transaction facts)

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

"моментальными снимками " (Snapshot facts)

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

элементами документа (Line-item facts)

Основаны на том или ином документе (например, счете за товар или услуги) и содержат подробную информацию об элементах этого документа (например, количестве, цене, проценте скидки);

событиями или состоянием объекта (Event or state facts)

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

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

Пример.

Таблица Product Dim в этом примере может быть разбита на две: собственно изделия и категории изделий. Однако это все равно будет одно продуктовое измерение.

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

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

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

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