Способы реализации olap.

Два подхода к организации хранилищ:

1. Relational OLAP (ROLAP) – схема “звезды”, реализуемая в рамках РСУБД

2. Multidimensional OLAP (MOLAP) – многомерный OLAP, специализированная СУБД, в основе которой лежит модель “многомерного куба”.

Пример: для разработанной ранее “торговой” базы данных таблица фактов, содержащая сведения о поставках имеет следующие атрибуты:

SUPPLIES (Дата поставки, код товара, код поставщика,

количество товара, цена за единицу)

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

GOODS (Код товара, Название, Класс товара, НДС)

PROVIDERS (Код поставщика, Название, Город, Страна)

Типичный OLAP-запрос можно выразить так:

SELECT SUPPLIES.Дата поставки, SUPPLIES. количество товара,

SUPPLIES.цена за единицу,

GOODS.Название, GOODS.НДС, PROVIDERS.Название,

PROVIDERS.Город, PROVIDERS.Страна

FROM SUPPLIES

LEFT JOIN GOODS ON SUPPLIES.код товара = GOODS.Код товара

LEFT JOIN PROVIDERS ON SUPPLIES.код поставщика = PROVIDERS.Код поставщика

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

CREATE VIEW VSUPPLIES(Дата поставки, количество товара,

цена за единицу, Товар, НДС, Поставщик, Город, Страна) AS

SELECT SUPPLIES.Дата поставки, SUPPLIES. количество товара,

SUPPLIES.цена за единицу,

GOODS.Название, GOODS.НДС, PROVIDERS.Название,

PROVIDERS.Город, PROVIDERS.Страна

FROM SUPPLIES

LEFT JOIN GOODS ON SUPPLIES.код товара = GOODS.Код товара

LEFT JOIN PROVIDERS ON SUPPLIES.код поставщика = PROVIDERS.Код поставщика

Тогда запрос можно формулировать так:

SELECT Дата поставки, Количество товара,

Цена за единицу, Товар, Класс товара, НДС, Поставщик, Город, Страна

FROM VSUPPLIES

Отсутствие необходимости соединения таблицы фактов и таблиц измерений резко сокращает время ответа.

Требования к средствам реализации систем оперативной и аналитической обработки данных

Главное достоинство аналитических СУБД состоит именно в том, что они узко специализированны и область их применения - интерактивная аналитическая обработка агрегированных исторических и прогнозируемых данных.

Агрегированные данные.

Пользователя, занимающегося анализом, редко интересуют детализированные данные. Более того, чем выше уровень пользователя (руководителя, управляющего, аналитика), тем выше уровень агрегации данных, используемых им для принятия решения. Рассмотрим в качестве примера фирму по продаже овощей и фруктов. Коммерческого директора такой фирмы мало интересует вопрос: "Бананы какой партии уже проданы в магазине N?" Для него важно, какие фрукты предпочитают покупатели в определенное время года. Его также мало интересует детализация на уровне контракта, дня или часа. Для правильного формирования склада ему важна и необходима информация на уровне декады, месяца или даже квартала.

Исторические данные.

Важнейшим свойством данных в аналитических задачах является их исторический характер. После того как зафиксировано, что с главного склада в июне 2002 г. продано 200 ящиков бананов и 150 ящиков яблок, данные об этом событии становятся историческим (свершившимся) фактом. И после того, как информация об этом факте получена, верифицирована и заведена в БД, она может быть сколько угодно раз считана оттуда, но уже не может и не должна быть изменена. Историчность данных предполагает не только высокий уровень статичности (неизменности) как собственно данных (например: с главного склада в июне продано 200 ящиков бананов 1 категории), так и их взаимосвязей (например: в июне бананы продавались по цене 300 р. за ящик). А это, в свою очередь, дает возможность использовать специализированные, основанные на предположении о статичности данных и их взаимосвязей, методы загрузки, хранения, индексации и выборки.

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

• для уменьшения времени обработки запросов желательно, чтобы уже в БД данные хранились (были предварительно отсортированы) в том порядке, в котором они наиболее часто запрашиваются;

так и на языки описания и манипулирования данными, например:

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

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