 |
Оперативная аналитическая обработка данных (OLAP)
|
|
|
|
Структура базы данных хранилища обычно разрабатывается таким образом, чтобы максимально облегчить анализ информации. Данные должно быть удобно «раскладывать» по разным направлениям (называемым измерениями). Например, сегодня пользователь хочет посмотреть сводку поставок деталей по поставщикам, чтобы сравнить их деятельность. Завтра этому же пользователю понадобится картина изменения объема поставок деталей по месяцам, чтобы проследить динамику поставок. Структура базы данных должна обеспечивать проведение подобных типов анализа, позволяя выделять данные, соответствующие заданному набору измерений.
В основе оперативной аналитической обработки данных лежит принцип организации информации в гиперкубическую модель. Простейший трехмерный куб данных по поставкам деталей для ранее рассмотренной тестовой базы данных приведен на рис. 3.11. Каждая его ячейка соответствует «факту» – например, объему поставки детали. Вдоль одной грани куба (одного измерения) располагаются месяцы, в течение которых выполнялись отражаемые кубом поставки. Второе измерение составляют виды деталей, а третье – соответствует поставщикам. В каждой ячейке содержится объем поставки для соответствующей комбинации значений по всем трем измерениям. Следует отметить, что при заполнении куба выполнена агрегация значений по поставкам каждого месяца из тестовой базы данных.
Рис.
 |
3.11. Вариант упрощенного гиперкуба для анализа поставок деталей
Системы класса OLAP различаются по способу представления данных.
Многомерный OLAP (MOLAP) – в основу этих систем положена многомерная, основанная на динамических массивах структура данных с соответствующими методами доступа. MOLAP реализуется на патентованных технологиях организации многомерных СУБД. Преимуществом этого подхода является удобство выполнения вычислений над ячейками гиперкуба, т.к. под все сочетания измерений заведены соответствующие ячейки (как в электронной таблице). К классическим представителям таких систем можно отнести Oracle Express, SAS Institute MDDB.
|
|
|
Реляционный OLAP (ROLAP) – поддерживает многомерные аналитические модели над реляционными БД. К данному классу систем можно отнести Meta Cube Informix, Microsoft OLAP Services,Hyperion Solutions, SAS Institute Relational OLAP.
Настольный OLAP (Desktop OLAP) – средства генерации многомерных запросов и отчетов для локальных информационных систем (электронные таблицы, плоские файлы). Можно выделить следующие системы – Business Objects, Cognos Power Play.
Э.Ф. Кодд определил двенадцать правил, которым должен удовлетворять продукт класса OLAP, включая многомерное концептуальное представление данных, прозрачность, доступность, устойчивую производительность, клиент-серверную архитектуру, равноправие измерений, динамическую обработку разреженных матриц, поддержку многопользовательского режима, неограниченную поддержку кроссмерных операций, интуитивное манипулирование данными, гибкий механизм генерации отчетов, неограниченное количество измерений и уровней агрегации.
 |
Наиболее распространены системы класса ROLAP. Они позволяют организовать информационную модель над реляционно-полным хранилищем любой структуры либо над специальной витриной данных.
Рис. 3.12. Схема типа «звезда» аналитической витрины по поставкам деталей
Для большинства хранилищ данных самым эффективным способом моделирования N-мерного куба является «звезда». На рис. 3.11 приведена модель гиперкуба для анализа поставок деталей, в котором информация консолидирована по четырем измерениям (поставщик, деталь, месяц, год). В основе схемы «звезда» лежит таблица фактов. Таблица фактов содержит столбец, где указан объем поставки, а также столбцы с указанием внешних ключей для всех таблиц измерений. Каждое измерение куба представлено таблицей значений, являющейся справочником по отношению к таблице фактов. Для организации уровней обобщения информации над справочниками измерений организованы категорные входы (например, «материал-деталь», «город-поставщик»).
|
|
|
Причина, по которой схема на рис. 3.12 названа «звездой», достаточно очевидна. Концы «звезды» образуются таблицами измерений, а их связи с таблицей фактов, расположенной в центре, образуют лучи. При такой структуре базы данных большинство запросов из области делового анализа объединяют центральную таблицу фактов с одной или несколькими таблицами измерений. Например, запрос для получения объемов поставок всех деталей в 2004 году по месяцам с разбивкой по поставщикам выглядит следующим образом:
SELECT SUM(VALUE), SUPPLIER.SUPPLIER_NAME, FACT.MONTH_ID
FROM FACT, SUPPLIER
WHERE FACT.YEAR_ID=2004
AND FACT.SUPPLIER_CODE=SUPPLIER.SUPPLIER_CODE
GROUP_BY SUPPLIER_CODE, MONTH_ID
ORDER_BY SUPPLIER_CODE, MONTH_ID.
На рис. 3.13 приведен фрагмент отчета, сформированного в результате заданного запроса.
|
|
|
