14.OLAP - кубы

1. место в общей структуре проекта (после накопления первичных данных), простейший пример

2. Разные схемы хранения ROLAP, MOLAP, HOLAP

3. простейшая схема куба прямо средствами обычной СУБД

4. организационная работа (связь с первичными данными по времени)

5. связь с генерацией документов

6. детализация и упрощение

7. корреляционный анализ

8. связь с репликацией

9. специальный синтаксис запросов

10. связь с агрегатными функциями SQL

OLAP (On-Line Analytical Processing)-Технология комплексного многомерного анализа данных. OLAP — это ключевой компонент организации хранилищ данных. Концепция OLAP была описана в 1993 году Эдгаром Коддом, известным исследователем баз данных и автором реляционной модели данных.

OLAP (англ. online analytical processing, аналитическая обработка в реальном времени) — технология обработки информации, включающая составление и динамическую публикацию отчётов и документов. Используется аналитиками для быстрой обработки сложных запросов к базе данных. Служит для подготовки бизнес-отчетов по продажам, маркетингу, в целях управления, т.е. поддержка аналитической деятельности, произвольных запросов пользователей.

Olap неразрывно связано с понятием хранилище данных.

Хранилище данных.

Принять любое управленческое решение невозможно не обладая необходимой для этого информацией, обычно количественной. Для этого необходимо создание хранилищ данных (Data warehouses), то есть процесс сбора, отсеивания и предварительной обработки данных с целью предоставления результирующей информации пользователям для статистического анализа (а нередко и создания аналитических отчетов). Основные требования к хранилищам данных:

• поддержка высокой скорости получения данных из хранилища;

• поддержка внутренней непротиворечивости данных;

• возможность получения и сравнения так называемых срезов данных (slice and dice);

• наличие удобных утилит просмотра данных в хранилище;

• полнота и достоверность хранимых данных;

• поддержка качественного процесса пополнения данных.

Отличия от обычной БД:

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

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

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

Таблица фактов

Таблица фактов является основной таблицей хранилища данных. Как правило, она содержит сведения об объектах или событиях, совокупность которых будет в дальнейшем анализироваться.

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

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

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

OLAP-Dimension (OLAP-Измерение) - это последовательность значений одного из анализируемых параметров. Например, для параметра "Город" это список городов.

Одновременный анализ по нескольким OLAP-измерениям определяется как многомерный анализ.

Каждое OLAP-измерение может быть представлено в виде иерархической структуры. Например, OLAP-измерение "Клиент" может иметь следующие иерархические уровни: "Страна - Регион - Город - Клиент". Более того, OLAP-измерения могут несколько видов иерархического представления. Например, OLAP-измерение "Время" может включать две иерархии со следующими уровнями: "Год - Квартал - Месяц - День" и "Неделя - День".

Действие OLAP

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

OLAP делает мгновенный снимок реляционной БД и структурирует её в пространственную модель для запросов. Заявленное время обработки запросов в OLAP составляет около 0.1 % от аналогичных запросов в реляционную БД.

Куб данных.

OLAP предоставляет удобные быстродействующие средства доступа, просмотра и анализа деловой информации. Пользователь получает естественную, интуитивно понятную модель данных, организуя их в виде многомерных кубов (Cubes). Осями многомерной системы координат служат основные атрибуты анализируемого бизнес-процесса. Например, для продаж это могут быть товар, регион, тип покупателя. В качестве одного из измерений используется время. На пересечениях осей - измерений (Dimensions) - находятся данные, количественно характеризующие процесс - меры (Measures). Это могут быть объемы продаж в штуках или в денежном выражении, остатки на складе, издержки и т. п. Пользователь, анализирующий информацию, может “разрезать” куб по разным направлениям, получать сводные (например, по годам) или, наоборот, детальные (по неделям) сведения и осуществлять прочие манипуляции, которые ему придут в голову в процессе анализа.

OLAP-структура, созданная из рабочих данных, называется OLAP-куб. Куб создаётся из соединения таблиц с применением схемы звезды. В центре «звезды» находится таблица фактов, которая содержит ключевые факты, по которым делаются запросы. Множественные таблицы с измерениями присоединены к таблице фактов. Эти таблицы показывают, как могут анализироваться агрегированые реляционные данные. Количество возможных агрегирований определяется количеством способов, которыми первоначальные данные могут быть иерархически отображены.

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

Вместе с базовой концепцией существуют три типа OLAP — OLAP со многими измерениями (Multidimensional OLAP — MOLAP), реляционный OLAP (Relational OLAP — ROLAP) и гибридный OLAP (Hybrid OLAP — HOLAP). MOLAP — это классическая форма OLAP, так что её часто называют просто OLAP. Она использует суммирующую БД, специальный вариант процессора пространственных БД и создаёт требуемую пространственную схему данных с сохранением как базовых данных, так и агрегатов. ROLAP работает напрямую с реляционным хранилищем, факты и таблицы с измерениями хранятся в реляционных таблицах, и для хранения агрегатов создаются дополнительные реляционные таблицы. HOLAP использует реляционные таблицы для хранения базовых данных и многомерные таблицы для агрегатов. Особым случаем ROLAP является ROLAP реального времени (Real-time ROLAP — R-ROLAP). В отличие от ROLAP в R-ROLAP для хранения агрегатов не создаются дополнительные реляционные таблицы, а агрегаты расчитываются в момент запроса. При этом многомерный запрос к OLAP-системе автоматически преобразуется в SQL-запрос к реляционным данным.

МЕСТО В СТРУКТУРЕ ПРОЕКТА.

OLAP на клиенте и на сервере

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

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

Если исходные данные содержатся в настольной СУБД, вычисление агрегатных данных производится самим OLAP-средством. Если же источник исходных данных — серверная СУБД, многие из клиентских OLAP-средств посылают на сервер SQL-запросы, содержащие оператор GROUP BY, и в результате получают агрегатные данные, вычисленные на сервере.

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

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

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

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

Архитектура OLAP-системы состоит из следующих компонентов:

• OLAP-сервер - обеспечивает хранение данных, выполнение над ними необходимых операций и формирование многомерной модели на концептуальном уровне. В настоящее время OLAP-серверы объединяют с Хранилищами Данных;

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

Загрузка данных в куб.

Первым этапом работы системы будет загрузка данных и преобразование их во внутренний формат.

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

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

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

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

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

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

Операции над OLAP кубом.

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

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

Консолидация (Drill Up) и детализация (Drill Down) - операции, которые определяют переход вверх по направлению от детального (down) представления данных к агрегированному (up) и наоборот соответственно.

Пример создания куба.

Это предложение представляет собой расширение DDL, предназначенное для описания структуры будущего локального куба. Полный синтаксис этого предложения можно найти в SQL Server Books Online, мы же ограничимся наиболее часто встречающимся видом этого предложения:

CREATE CUBE <Cube Name>

(

DIMENSION <Dimension Name> [TYPE <Dimension Type>]

LEVEL <Level Name>[TYPE <Level Type>],

[LEVEL <Level Name> [TYPE <Level Type>]:],

[[DIMENSION <Dimension Name> [TYPE <Dimension Type>]

LEVEL <Level Name>[TYPE <Level Type>,

[LEVEL <Level Name> >[TYPE <Level Type>:],:],

MEASURE <Measure Name> FUNCTION <Function Name>,

[MEASURE <Measure Name> FUNCTION <Function Name>,:]

)

Например, создавая локальный куб на основе базы данных NorthWind, входящей в комплект поставки Microsoft SQL Server, мы можем написать следующее предложение CREATE CUBE:

CREATE CUBE Sales(

DIMENSION [Country], LEVEL [All] TYPE ALL, LEVEL [Country],

LEVEL [City], LEVEL [CustomerID],

DIMENSION [Salesperson], LEVEL [All] TYPE ALL, LEVEL [Salesperson],

DIMENSION [ShipperName], LEVEL [All] TYPE ALL, LEVEL [ShipperName],

DIMENSION [CategoryName],LEVEL [All] TYPE ALL, LEVEL [CategoryName],

LEVEL [ProductName],

DIMENSION [OrderDate] TYPE TIME, LEVEL [All] TYPE ALL,

LEVEL [Year] TYPE YEAR,

LEVEL [Quarter] TYPE QUARTER,

LEVEL [Month] TYPE MONTH,

LEVEL [Day] TYPE DAY,

MEASURE [Sum Of ExtendedPrice] FUNCTION SUM,

MEASURE [Sum Of Quantity] FUNCTION SUM

Корреляция. Корреляционный анализ.

Корреля́ция — статистическая взаимосвязь двух или нескольких случайных величин (либо величин, которые можно с некоторой допустимой степенью точности считать таковыми). При этом изменения одной или нескольких из этих величин приводят к систематическому изменению другой или других величин. Мерой корреляции двух случайных величин служит коэффициент корреляции.

Коэффицие́нт корреля́ции — это показатель характера изменения двух случайных величин.