Про Oracle Business Intelligence

Когда Дмитрий Волков предложил мне выступить на семинаре Database Options Details с рассказом про OLAP опцию в 11g, я сначала подумал – да о чем тут рассказывать? Между девятой и десятой версией было много различий. А между 10 и 11 вроде ничего особо не было. Ну, кроме Cube-Organized Materialized Views. Потом решил, что на семинаре будет масса людей, которые вообще с OLAP не работали, ни с какой версией, поэтому им, возможно, будет интересно узнать об OLAP вообще. Заодно при подготовке и посмотрю внимательнее, что там изменилось. Но оказалось, что изменений неожиданно много.

Для экспериментов я использовал Oracle 11.1.0.6 c OLAP Patch A (#6459753) на VMware, для который был выделен 1Gb RAM.

В этой статье я ориентируюсь на людей, которые уже знакомы с Oracle Express или Oracle OLAP, ну или хотя бы в общих чертах представляет, что это. Для начального ознакомления предлагаю почитать мои статьи \”Что такое OLAP\” (Часть 1 Часть 2)

Интеграция метаданных с Oracle Database

Первое, что бросилось в глаза, это то, что действительно через любой SQL инструмент теперь стало очень удобно смотреть на данные, лежащие в OLAP кубах. Причем, как только вы создаете какой-то объект с помощью Analytic Workspace Manager (AWM) (показатель, измерение и т.д.) он тут же становится виден из SQL. Для этого автоматически создается обвязка из VIEW, каждый из которых содержит вызов CUBE_TABLE. Выглядит это примерно так:

CREATE OR REPLACE VIEW UNITS_CUBE_VIEW AS
SELECT 
    \"UNITS\", 
    \"SALES\", 
    \"COST\", 
    \"TIME\", 
    \"CHANNEL\", 
    \"CUSTOMER\", 
    \"PRODUCT\"
FROM TABLE(CUBE_TABLE(\'GLOBAL.UNITS_CUBE\') );

GLOBAL.UNITS_CUBE – это указание на то, что данные лежат в кубе UNITS_CUBE, который создавался в AWM. А CUBE_TABLE – табличная функция, такой универсальный вызов данных из объектов, лежащих в аналитическом прострастве.

В 10й версии тоже была возможность увидеть данные через SQL. Для этого была табличная функция OLAP_TABLE. (Собственно, она и сейчас есть, но смысла ее использовать, наверное, не очень много) Но чтобы заставить ее работать, нужно было предварительно создать кучу разных абстрактных типов данных, описания LIMITMAP и проч. Причем можно было ошибиться на любом шаге. В общем, для начинающих совершенно не подходило. Даже был такой плагин к AWM, который эти типы мог создать сам, что, в общем, частично проблему решало. Сейчас ничего делать не надо. Для каждого измерения и куба есть соответствующая вьюшка. Вы можете легко делать запросы к этим VIEW для того, чтобы например, фильтровать измерения по атрибутам. То есть, в вашем SQL запросе будут объединяться вьюшки измерений и куба, а оптимизатор сам знает как весь этот запрос протолкнуть через CUBE_TABLE внутрь OLAP движка, где он и будет отработан. Более того, никто не запрещает объединять данные из OLAP с данными из реляционки в любом запросе. Например, для того чтобы соединить агрегированные данные с детальными.

Кроме того, в 10g вызовы OLAP_TABLE работали довольно медленно. В 11g разница в скорости заметна невооруженным глазом. Причем, встроенная смотрелка AWM работает достаточно медленно, но если такой же запрос выполнить из SQL, он работает гораздо быстрее. Что говорит скорее всего о том, что смотрелка AWM генерирует запросы не так, или медленно обрабатывает результаты. Вообще, при желании это можно оттрассировать, но мне пока не хватило времени.

Увеличение скорости работы SQL связано с тем, что теперь обработка запросов оптимизатором сделана более умно и фильтрация значений по измерениям происходит внутри аналитического пространства, то есть в движке OLAP, а не в самом Oracle, как это было в 10g. Если сравнить запрос SQL и аналогичный ему DML запрос выполнять из OLAP Worksheet, то разница в скорости не заметна. То есть, SQL отрабатыват примерно также как и запрос непосредственно к движку.

Можно сделать вывод, что связка SQL – CUBE_TABLE – стала вполне пригодной для того, чтобы пользоваться ей для доступа к OLAP.

Как следствие, к данным OLAP можно обращаться любым ROLAP инструментом, например Oracle Business Intelligence Enterprise Edition, который работает с базой Oracle через SQL. Другие API не обязательны.

При этом, любые манипуляции с движком OLAP, если это необходимо, можно делать используя пакет DBMS_AW.

Упрощение стандартной формы

Когда я запустил новый AWM, оказалось, что в нем исчезла возможность смотреть структуру AW в режиме Object View.

Тут надо сделать небольшое отступление.

В Oracle Express были пользовательские объекты. Были и внутренние объекты, хранящие метаданные, которые физически были реализованы объектами Express, такими как измерения, отношения, переменные и и.д. Но внутренние были в основном скрыты от конечного пользователя. Да и большой небходимости в них залезать не было. В 9й версии, когда OLAP стал частью СУБД Oracle, сначала все оставалось, как было в Express, но потом, в районе 9.2.0.4 (точно не помню) была придумана так называемая стандартная форма (Standard Form, SF)

Это специальная обвязка метаданных, нужная для интеграции с СУБД Oracle. Но проблема в том, что те объекты, которые создавались в AWM и которые пользователь считал измерениями, показателями и т.д., на самом деле физически лежат совершенно в других объектах, а добраться до них можно было лишь расшифорвав сложный слой метаданных SF. А SF сама по себе менялась с каждым патчсетом. Express всегда славился своим очень гибким языком, который сейчас называется OLAP DML. На нем можно было написать очень сложные расчетные формулы и программы, для работы с многомерными объектами. Но сложность SF по сути убивала эту возможность, так как было довольно сложно расшифровывать метаданные, к тому же, велика вероятность, что в следующем релизе что-то поменяется и ваша программа перестанет работать. А SF считается объектом внутренним и поддержка прошлых версий SF не гарантируется.

Поэтому, в AWM прошлых версий было два вида представления объектов OLAP – Model View и Object View. Model View показывал как объекты выглядят через призму SF, Object View – как они хранятся на самом деле. Что и говорить, найти соответствия между двумя предствлениями было очень сложно.

В 11 версии все стало гораздо проще. Создаем мы из AWM куб UNITS_CUBE, а в нем показатель SALES. Теперь в OLAP DML мы можем увидеть объект UNITS_CUBE_SALES, название которого составлено из названия куба и названия показателя. Это же распространяется и на вычисляемые показатели. У нас теперь опять есть простой путь использования наших показателей в формулах и программах. И не важно, что на самом деле, это не куб, а формула, которая смотрит на другой объект. Для нас уже не важно знать, как именно он хранится.
Хотя, если кому интересно, можно и посмотреть:

->dsc UNITS_CUBE_SALES

DEFINE UNITS_CUBE_SALES FORMULA LOCKDFN NUMBER WITH NULLTRACKING 
<TIME CHANNEL CUSTOMER PRODUCT>
EQ this_aw!UNITS_CUBE_STORED(this_aw!UNITS_CUBE_MEASURE_DIM \'SALES\')

->dsc units_cube_stored

DEFINE UNITS_CUBE_STORED VARIABLE READONLY LOCKDFN NUMBER 
WITH NULLTRACKING WITH AGGCOUNT CHANGETRACKING 
<UNITS_CUBE_MEASURE_DIM TIME UNITS_CUBE_COMPOSITE 
<CHANNEL CUSTOMER PRODUCT>>

->dsc units_cube_composite

DEFINE UNITS_CUBE_COMPOSITE COMPOSITE READONLY LOCKDFN 
<CHANNEL CUSTOMER PRODUCT> COMPRESSED

Напомню, что через SQL тот же куб можно увидеть через вьюшку UNITS_CUBE_VIEW, а показатель SALES соответственно будет UNITS_CUBE_VIEW.SALES

SELECT time,
  product,
  customer,
  channel,
  sales
FROM units_cube_view
WHERE rownum < 15;

TIME      PRODUCT CUSTOMER CHANNEL      SALES
--------- ------- -------- ------- ----------
TOTAL     TOTAL   TOTAL    TOTAL      4000968
CY1999    TOTAL   TOTAL    TOTAL       330425
CY2003    TOTAL   TOTAL    TOTAL       534069
CY1998    TOTAL   TOTAL    TOTAL       253816
CY2005    TOTAL   TOTAL    TOTAL       565718
CY2006    TOTAL   TOTAL    TOTAL       584929
CY2004    TOTAL   TOTAL    TOTAL       587419
CY2000    TOTAL   TOTAL    TOTAL       364233
CY2002    TOTAL   TOTAL    TOTAL       364965
CY2001    TOTAL   TOTAL    TOTAL       415394
CY2000.Q1 TOTAL   TOTAL    TOTAL        88484
CY2001.Q2 TOTAL   TOTAL    TOTAL        97346
CY2001.Q3 TOTAL   TOTAL    TOTAL       105704
CY2005.Q3 TOTAL   TOTAL    TOTAL       138953

И вот тут видно основное отличие данных, которые достаются из OLAP от данных, которые берутся из обычных таблиц Oracle. Обратите внимание на первую строчку, где четыре слова \’TOTAL\’. В этой строке – агрегат (сумма) по продажам по всем измерениям. Если бы мы хотели достать сумму по всем измерениям из обычной таблицы, нам нужно было написать что-то вроде

select sum(sales) from units_fact

А OLAP уже выдает все возможные агрегаты, поэтому вместо суммирования, нам нужно в условиях SQL запроса WHERE описать фильтр этой строки. Само суммирование делать не надо. Сумму уже посчитал OLAP сервер.

Это естественно накладывает некоторые условия на программирование SQL над OLAP. Например, в том же BI EE нужно специальным образом описать правила обсчета уровней иерархий, что бы не пошло суммирование по уже агрегированным данным.

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

Продолжение тут.

__________________________________

Читайте также:

• На OTN появился BI EE плагин для AWM
• Впечатления от Oracle OLAP 11g. Часть 2.
• Что такое OLAP? Часть 2. Oracle Express и Oracle OLAP
• OLAP View Generator для AWM
• Семинар и тренинг по Oracle OLAP 11g в Москве

А еще можно почитать мой твиттер @apivovarov

Trackback This Post | Subscribe to the comments through RSS Feed