Основные принципы оперативной аналитической обработки (OLAP)

Основные понятия OLAP

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

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

Модель данных хранилища для OLAP – системдолжна обеспечивать эффективную обработку любых запросов и иметь возможность хранения и работы с агрегированными значениями.

В основе OLAP лежит понятие гиперкуба, или многомерного куба данных, в ячейках которого хранятся анализируемые (числовые) данные.

По Кодду, многомерное концептуальное представление (multi-dimensional conceptual view) является наиболее естественным взглядом управляющего персонала на объект управления. Оно представляет собой множественную перспективу, состоящую из нескольких независимых измерений, вдоль которых могут быть проанализированы определенные совокупности данных. Одновременный анализ по нескольким измерениям данных определяется как многомерный анализ.

В многомерной модели данные представляются в виде одного или нескольких многомерных гиперкубов, где из­мерения (dimensions) соответствуют осям куба, а анализируемые переменные (measures) или показатели – индивидуаль­ным ячейкам куба. Используя многомерную модель, аналитик может легко получить представление данных в соответствии с собственными интересами.

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

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

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

Так, измерение Исполнитель может определяться направлением консолидации, состоящим из уровней обобщения «предприятие – подразделение – отдел – служащий».

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

Операция спуска (drilling down) соответствует движению от высших ступеней консолидации к низшим; напротив, операция подъема (rolling up) означает движение от низших уровней к высшим.

Рассмотрим определения и основные понятия OLAP на относительно простом примере.

Гипотетическая компания "Best Foot Forward" строит базу данных, с помощью которой она могла бы отслеживать продажи обуви по категориям и месяцам (таблицу продаж Sales).

Таблица 1.2.

Для анализа данных мы могли бы, например, соотнести месяцы строкам, а типы столбцам и сформировать таким образом две таблицы: количества продаж Quantity и общей стоимости без учета налогов Total Value Tax Exclusive. Эти таблицы позволят нам проводить моделирование и строить графики так, как мы пожелаем. Итак, у нас два простых отчета: один, показывающий число пар обуви, проданных за месяц, и второй - общая стоимость.

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

Таблица 1.3.

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

Теперь мы имеем уже шесть разных возможных отчетов:

· Для каждого магазина или для всех магазинов каждый из двух ранее приведенных отчетов

· Для каждого типа или по всем типам два отчета, где строка - это месяц и столбец - магазин,

· Для каждого месяца или для года отчеты с соответствием "строка - магазин" и "столбец - тип".

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

Еще нужно анализировать продажи и по другим критериям, таким как "род" Gender (мужская, женская, детская обувь), "размер" Size, а может быть и "цвет" Colour.

Таблица продаж стала очень большой, как по числу строк, так и столбцов.

Анализировать данные по продажам требуется, предположим, по месяцам, роду обуви и по магазинам. В терминологии OLAP эти критерии анализа носят название измерений. В нашем примере можно говорить об измерении Магазин. Оно может содержать несколько значений, наподобие "Paris Bastille". Эти значения являются значениями на шкале измерения Магазин.

В нашем примере объектом для анализа используются два показателя: количества проданной обуви и стоимость без учета налогов. Эти показатели носят также название мер или, иногда, переменных. Теперь можно сказать, что показатель Количество имеет измерения Месяц, Род ("род" Gender - мужская, женская, детская обувь) и Магазин. Каждый показатель может характеризоваться числом от одного до нескольких миллионов. Все значения показателя имеют одинаковый тип, например, целое или десятичное.

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

Рис 1.4.

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

Если мы добавим показатель «общую стоимость без учета налогов Total Value TE», то получим уже другой куб, построенный на тех же измерениях: Месяц, Род, Магазин, на которых задают существующие значения мер (показателей). Такие кубы в общем виде называются гиперкубом.

Возможность помесячного изучения продаж, конечно, полезна, но, в тоже время, имеет свои ограничения. Переименуем измерение Месяц и назовем его, к примеру, Time. Положениями на шкале измерений Time могут быть помимо месяцев - дни, периоды и годы. Таким образом, мы сможем анализировать результаты работы разных магазинов как по более общим, так и более детальным отрезкам времени.

Для этого требуется создать иерархию. В нашем случае иерархия образована четырьмя уровнями соответственно дню, месяцу, кварталу и году. Теперь мы имеем возможность вполне естественно соединить 18 мая 2000 года с маем 2000 года, и далее со вторым кварталом 2000 года и с самим 2000 годом. Для описания данных иерархии используются выражения типа «потомок», "родитель", "брат/сестра".

Точно таким же образом можно завести иерархию для шкалы измерений Магазин. К примеру, можно группировать магазины по району, области, стране. Для одного измерения можно организовывать несколько иерархий. Так, вторая иерархия для измерения времени могла бы иметь три уровня: день, неделя и год. В этом случае 18 мая 2000 года будет соединено с 19-й неделей 2000 года и с самим 2000 годом.

В любой иерархии каждая позиция на шкале должна иметь ровно одного родителя - отношение "один ко многим".

Предположим для примера, что мы хотим создать иерархию, чтобы показывать с ее помощью, какие категории обуви (спортивная, прогулочная, детская) как продаются. Новую иерархию можно расположить на шкале измерения стиля Style, так как стиль пары обуви принадлежит ровно одной категории.

Теперь показатели количества Quantity и стоимости Total Value Tax Exclusive охарактеризованы измерениями Time, Style и Outlet. Каждый магазин предоставляет данные за день, а база OLAP отслеживает консолидацию данных в соответствии с разными иерархиями. Пока вся консолидация заключается в вычислении сумм, встроенные в систему функции обеспечивают этот процесс просто и незаметно для глаз.

Результаты осуществления такого агрегирования в соответствии с иерархиями хранятся в базе данных на более высоких уровнях иерархии.

Итак, наша база данных типа OLAP состоит сейчас из двух "кубов" данных (или же "мер", "показателей") о числе проданных пар обуви и их стоимости без учета налогов. Обе наши меры (показатели) имеют в качестве шкал измерений время, род и магазин: Time, Style и Outlet.

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

Для пользователя разницы между хранимым показателем и формулой нет. И те, и другие определяются шкалами измерений и типом. Так, формула Average Price, вычисляющая среднюю цену пары ботинок, имеет шкалы измерений Time, Style и Outlet и имеет десятичный тип. Это простая формула

Средняя цена = Общая стоимость без учета налогов / Количество

или

Average Price = Total Value Tax Exclusive / Quantity.

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

Для формулы вовсе не обязательно, чтобы все ее элементы индексировались (определялись) одними измерениями. Мы бы могли, например, определить формулу для расчета налога:

Total Value tax Inclusive = Total Value Tax Exclusive x 1.206, где 1.206 – ставка налога.

Так как налог на добавленную стоимость (VAT) изменяется со временем, можно задать новую переменную VAT, шкалой измерения которой будет только время. Эта переменная будет указывать на рост налога VAT в любой точке шкалы времени Time. Получим (рисунок 1.5):

Total Value Tax Inclusive = Total Value Tax Exclusive x (100+VAT)/100

Рис. 1.5.

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

Далее, если налог VAT изменяется по-разному для разных товаров, то шкалами измерения для этой переменной должны стать Time и Product. Графически значения переменной в этом случае образуют не линию, а плоскость.

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

Таким образом, вопросы, приводимых ниже, реализуются достаточно просто:

· Какие изменения претерпела моя чистая прибыль по сравнению с тем же месяцем прошлого года.

· Какие изменения претерпели мои чистые показатели в сравнении с усредненным значением за последние три месяца.

· Какова будет тенденция рынка в ближайшие 12 месяцев.

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