 |
MOLAP ( Multidimensional OLAP )
|
|
|
|
В MOLAP-модели многомерное представление данных реализуется физически. В специализированных СУБД, основанных на многомерном представлении данных, данные организованы не в форме реляционных таблиц, а в виде упорядоченных многомерных массивов:
1. гиперкубов (все хранимые в базе данных ячейки должны иметь одинаковую размерность, то есть находиться в максимально полном базисе измерений) и
2. поликубов (каждая переменная хранится с собственным набором измерений, и все связанные с этим cложности обработки перекладываются на внутренние механизмы системы).
Использование многомерных баз данных в системах оперативной аналитической обработки имеет следующие достоинства:
· Высокая производительность. В случае использования многомерных СУБД поиск и выборка данных осуществляется значительно быстрее, чем при многомерном концептуальном взгляде на реляционную базу данных, так как многомерная база данных денормализована, содержит заранее агрегированные показатели и обеспечивает оптимизированный доступ к запрашиваемым ячейкам.
· Многомерные СУБД легко справляются с задачами включения в информационную модель разнообразных встроенных функций, тогда как объективно существующие ограничения языка SQL делают выполнение этих задач на основе реляционных СУБД достаточно сложным, а иногда и невозможным.
Недостатки MOLAP-модели:
· Многомерные СУБД не позволяют работать с большими базами данных.
· Многомерные СУБД по сравнению с реляционными очень неэффективно используют внешнюю память. В подавляющем большинстве случаев информационный гиперкуб является сильно разреженным, а поскольку данные хранятся в упорядоченном виде, неопределенные значения удаётся удалить только за счет выбора оптимального порядка сортировки, позволяющего организовать данные в максимально большие непрерывные группы. Но даже в этом случае проблема решается только частично. Кроме того, оптимальный с точки зрения хранения разреженных данных порядок сортировки скорее всего не будет совпадать с порядком, который чаще всего используется в запросах.
|
|
|
Следовательно, использование многомерных СУБД оправдано только при следующих условиях:
1. Объем исходных данных для анализа не слишком велик (не более нескольких гигабайт), то есть уровень агрегации данных достаточно высок.
2. Набор информационных измерений стабилен (поскольку любое изменение в их структуре почти всегда требует полной перестройки гиперкуба).
3. Время ответа системы на нерегламентированные запросы является наиболее критичным параметром.
ПримерыOLAP-серверов, использующих MOLAP-архитектуру: Oracle Express Server фирмы Oracle, IBM Informix MetaCube, IBM DB2 OLAP, Arbor Essbase.
ROLAP (Relational OLAP)
Системы оперативной аналитической обработки реляционных данных (ROLAP) позволяют представлять данные, хранимые в реляционной базе, в многомерной форме, обеспечивая преобразование информации в многомерную модель через промежуточный слой метаданных. В этом случае гиперкуб эмулируется СУБД на логическом уровне.
Для большинства хранилищ данных наиболее эффективным способом моделирования N-мерного куба фактов является схема "звезда" (star schema).
Основными составляющими структуры хранилищ данных являются таблица фактов (fact table) и таблицы измерений (dimension tables).
Таблица фактов является основной таблицей хранилища данных. Как правило, она содержит сведения об объектах или событиях, совокупность которых будет в дальнейшем анализироваться. Если проводить аналогию с многомерной моделью, то строка таблицы фактов соответствует ячейке гиперкуба. Обычно говорят о четырех наиболее часто встречающихся типах фактов. К ним относятся:
|
|
|
· факты, связанные с транзакциями (Transaction facts). Они основаны на отдельных событиях (типичными примерами которых являются телефонный звонок или снятие денег со счета с помощью банкомата);
· факты, связанные с "моментальными снимками" (Snapshot facts). Основаны на состоянии объекта (например, банковского счета) в определенные моменты времени, например на конец дня или месяца. Типичными примерами таких фактов являются объем продаж за день или дневная выручка;
· факты, связанные с элементами документа (Line-item facts). Основаны на том или ином документе (например, счете за товар или услуги) и содержат подробную информацию об элементах этого документа (например, количестве, цене, проценте скидки);
· факты, связанные с событиями или состоянием объекта (Event or state facts). Представляют возникновение события без подробностей о нем (например, просто факт продажи или факт отсутствия таковой без иных подробностей).
Таблица фактов индексируется по сложному ключу, составленному из ключей отдельных изменений. При этом как ключевые, так и некоторые неключевые поля таблицы фактов должны соответствовать будущим измерениям OLAP-куба. Помимо этого таблица фактов содержит одно или несколько числовых полей, на основании которых в дальнейшем будут получены агрегатные данные.
Замечания.
1. Для многомерного анализа пригодны таблицы фактов, содержащие как можно более подробные данные, то есть соответствующие членам нижних уровней иерархии соответствующих измерений.
2. В таблице фактов отсутствуют какие-либо сведения о том, как группировать записи при вычислении агрегатных данных.
Таблица измерений содержит неизменяемые или редко изменяемые данные. В каждой таблице измерений перечислены возможные значения одного из измерений гиперкуба. В подавляющем большинстве случаев эти данные представляют собой по одной записи для каждого члена нижнего уровня иерархии в измерении. Таблицы измерений также содержат как минимум одно описательное поле (обычно с именем члена измерения) и, как правило, целочисленное ключевое поле (обычно это суррогатный ключ) для однозначной идентификации члена измерения. Каждая таблица измерений должна находиться в отношении "один ко многим" с таблицей фактов.
|
|
|
Причина, по которой данная схема названа "звездой" достаточно очевидна. Концы звезды образуются таблицами измерений, а их с таблицей фактов, расположенной в центре, образуют лучи. В терминологии Кодда, каждый луч схемы звезды задает направление консолидации данных по соответствующему измерению.
В схеме "звезда" каждое измерение куба содержится в одной таблице, в том числе и при наличии нескольких уровней иерархии (государство - регион - нас.пункт в таблице "Покупатель", год - месяц - день в таблице "Период").
В сложных задачах с многоуровневыми измерениями используются различные расширения схемы "звезда" - схема "снежинка" (snowflake schema). Это расширение может проявляться в двух разновидностях.
1. В случае большого числа сложных атрибутов в таблице измерений, некоторые атрибуты могут быть детализированы в отдельных таблицах измерений. Иными словами отдельные измерения содержатся не в одной, а в нескольких связанных между собой таблицах. Дополнительные таблицы измерений в такой схеме, обычно соответствующие верхним уровням иерархии измерения и находящиеся в соотношении "один ко многим" в главной таблице измерений, соответствующей нижнему уровню иерархии, иногда называют консольными таблицами (outrigger table).
Например, из таблицы "Покупатель" можно изъять описания региона, населенного пункта (оставив лишь их ключи) и хранить их в отдельных дополнительных таблицах. Это уменьшит степень дублирования информации, но снижает скорость выполнения запросов, поскольку увеличивает степень нормализации. Поэтому даже при наличии иерархических измерений с целью повышения скорости выполнения запросов к хранилищу данных нередко предпочтение отдается схеме "звезда".
2. Другое расширение связано с созданием отдельных таблиц фактов для всех возможных сочетаний уровней обобщения различных измерений.
Увеличение числа таблиц фактов в базе данных может проистекать не только из множественности уровней различных измерений, но и из того обстоятельства, что в общем случае факты имеют разные множества измерений. При абстрагировании от отдельных измерений пользователь должен получать проекцию максимально полного гиперкуба, причем далеко не всегда значения показателей в ней должны являться результатом элементарного суммирования. Таким образом, при большом числе независимых измерений необходимо поддерживать множество таблиц фактов, соответствующих каждому возможному сочетанию выбранных в запросе измерений.
|
|
|
Это позволяет добиться лучшей производительности, но часто приводит к избыточности данных и к значительным усложнениям в структуре базы данных, в которой оказывается огромное количество таблиц фактов
При такой структуре базы данных большинство запросов из области делового анализа объединяют центральную таблицу фактов с одной или несколькими таблицами измерений.
Пример: получить средние объемы продаж товаров каждого поставщика с разбивкой по покупателям и по месяцам.
В любом случае, если многомерная модель реализуется в виде реляционной базы данных, следует создавать длинные и "узкие" таблицы фактов и сравнительно небольшие и "широкие" таблицы измерений. Таблицы фактов содержат численные значения ячеек гиперкуба, а остальные таблицы определяют содержащий их многомерный базис измерений. Часть информации можно получать с помощью динамической агрегации данных, распределенных по незвездообразным нормализованным структурам, хотя при этом следует помнить, что включающие агрегацию запросы при высоконормализованной структуре базы данных могут выполняться довольно медленно.
Достоинства использования реляционных баз данных в системах аналитической оперативной обработки:
1. При использовании ROLAP размер хранилища не является таким критичным параметром, как в случае MOLAP.
2. Внесение изменений в структуру измерений не требует физической реорганизации базы данных, как в случае MOLAP.
3. Реляционные СУБД обеспечивают значительно более высокий уровень защиты данных и хорошие возможности разграничения прав доступа.
Главный недостаток ROLAP по сравнению с многомерными СУБД - меньшая производительность.
Примеры OLAP-серверов, использующих ROLAP-архитектуру: IBM Informix Red Brick, HighGate Project фирмы Sybase, Microsoft SQL Server 2000 Analysis Services фирмы Microsoft.
|
|
|
