Технология OLAP. Категории информационных систем Olap инструменты

Механизм OLAP является на сегодня одним из популярных методов анализа данных. Есть два основных подхода к решению этой задачи. Первый из них называется Multidimensional OLAP (MOLAP) – реализация механизма при помощи многомерной базы данных на стороне сервера, а второй Relational OLAP (ROLAP) – построение кубов "на лету" на основе SQL запросов к реляционной СУБД. Каждый из этих подходов имеет свои плюсы и минусы. Их сравнительный анализ выходит за рамки этой статьи. Мы же опишем нашу реализацию ядра настольного ROLAP модуля.

Такая задача возникла после применения ROLAP системы, построенной на основе компонентов Decision Cube, входящих в состав Borland Delphi. К сожалению, использование этого набора компонент показало низкую производительность на больших объемах данных. Остроту этой проблемы можно снизить, стараясь отсечь как можно больше данных перед подачей их для построения кубов. Но этого не всегда бывает достаточно.

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

Схема работы

Общую схему работы настольной OLAP системы можно представить следующим образом:

Алгоритм работы следующий:

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

Рассмотрим как подобная система может быть устроена внутри. Начнем мы это с той стороны, которую можно посмотреть и пощупать, то есть с отображений.

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

Кросс-таблица

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

Таким образом, таблицу можно разделить на следующие элементы, с которыми мы и будем работать в дальнейшем:

Заполняя матрицу с фактами, мы должны действовать следующим образом:

На основании данных об измерениях определить координаты добавляемого элемента в матрице.
Определить координаты столбцов и строк итогов, на которые влияет добавляемый элемент.
Добавить элемент в матрицу и соответствующие столбцы и строки итогов.

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

Кол-во элементов = 250 х 500 х 365 = 45 625 000

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

Поэтому, для работы с этой матрицей нужно применить специальные механизмы работы с разреженными матрицами. Возможны различные варианты организации разреженной матрицы. Они довольно хорошо описаны в литературе по программированию, например, в первом томе классической книги "Искусство программирования" Дональда Кнута.

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

При этом можно легко найти способ определения номеров соответствующей ячейки и итогов, в которые она попадает. Здесь можно предложить несколько подходов. Один из них – это использование дерева для поиска соответствующих ячеек. Это дерево может быть построено при проходе по выборке. Кроме того, можно легко определить аналитическую рекуррентную формулу для вычисления требуемой координаты.

Подготовка данных

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

При использовании такой структуры мы значительно снижаем потребность в памяти. Что довольно актуально, т.к. для увеличения скорости работы желательно хранить данные в оперативной памяти. Кроме того, хранить можно только массив элементов, а их значения выгружать на диск, так как они будут нам требоваться только при выводе кросс-таблицы.

Библиотека компонентов CubeBase

Описанные выше идеи были положены в основу при создании библиотеки компонентов CubeBase.

TСubeSource осуществляет кэширование и преобразование данных во внутренний формат, а также предварительное агрегирование данных. Компонент TСubeEngine осуществляет вычисление гиперкуба и операции с ним. Фактически, он является OLAP-машиной, осуществляющей преобразование плоской таблицы в многомерный набор данных. Компонент TCubeGrid выполняет вывод на экран кросс-таблицы и управление отображением гиперкуба. TСubeChart позволяет увидеть гиперкуб в виде графиков, а компонент TСubePivote управляет работой ядра куба.

Сравнение производительности

Данный набор компонент показал намного более высокое быстродействие, чем Decision Cube. Так на наборе из 45 тыс. записей компоненты Decision Cube потребовали 8 мин. на построение сводной таблицы. CubeBase осуществил загрузку данных за 7сек. и построение сводной таблицы за 4 сек. При тестировании на 700 тыс. записей Decision Cube мы не дождались отклика в течение 30 минут, после чего сняли задачу. CubeBase осуществил загрузку данных за 45 сек. и построение куба за 15 сек.

На объемах данных в тысячи записей CubeBase отрабатывал в десятки раз быстрее Decision Cube. На таблицах в сотни тысяч записей – в сотни раз быстрее. А высокая производительность – один из самых важных показателей OLAP систем.

В цикле статей «Введение в базы данных», публиковавшемся в последнее время (см. КомпьютерПресс №3’2000 - 3’2001), мы обсуждали различные технологии и программные средства, применяемые при создании информационных систем - настольные и серверные СУБД, средства проектирования данных, средства разработки приложений, а также Business Intelligence - средства анализа и обработки данных масштаба предприятия, которые в настоящее время становятся все более популярными в мире, в том числе и в нашей стране. Отметим, однако, что вопросы применения средств Business Intelligence и технологии, используемые при создании приложений такого класса, в отечественной литературе пока еще освещены недостаточно. В новом цикле статей мы попробуем восполнить этот пробел и рассказать о том, что представляют собой технологии, лежащие в основе подобных приложений. В качестве примеров реализации мы будем использовать в основном OLAP-технологии фирмы Microsoft (главным образом Analysis Services в Microsoft SQL Server 2000), но надеемся, что основная часть материала будет полезна и пользователям других средств.

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

Что такое хранилище данных

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

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

Ральф Кимбалл (Ralph Kimball), один из авторов концепции хранилищ данных, описывал хранилище данных как «место, где люди могут получить доступ к своим данным» (см., например, Ralph Kimball, «The Data Warehouse Toolkit: Practical Techniques for Building Dimensional Data Warehouses», John Wiley & Sons, 1996 и «The Data Webhouse Toolkit: Building the Web-Enabled Data Warehouse», John Wiley & Sons, 2000). Он же сформулировал и основные требования к хранилищам данных:

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

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

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

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

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

Что такое OLAP

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

Технология комплексного многомерного анализа данных получила название OLAP (On-Line Analytical Processing). OLAP - это ключевой компонент организации хранилищ данных. Концепция OLAP была описана в 1993 году Эдгаром Коддом, известным исследователем баз данных и автором реляционной модели данных (см. E.F. Codd, S.B. Codd, and C.T.Salley, Providing OLAP (on-line analytical processing) to user-analysts: An IT mandate. Technical report, 1993). В 1995 году на основе требований, изложенных Коддом, был сформулирован так называемый тест FASMI (Fast Analysis of Shared Multidimensional Information - быстрый анализ разделяемой многомерной информации), включающий следующие требования к приложениям для многомерного анализа:

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

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

Многомерные кубы

В данном разделе мы более подробно рассмотрим концепцию OLAP и многомерных кубов. В качестве примера реляционной базы данных, который мы будем использовать для иллюстрации принципов OLAP, воспользуемся базой данных Northwind, входящей в комплекты поставки Microsoft SQL Server или Microsoft Access и представляющей собой типичную базу данных, хранящую сведения о торговых операциях компании, занимающейся оптовыми поставками продовольствия. К таким данным относятся сведения о поставщиках, клиентах, компаниях, осуществляющих доставку, список поставляемых товаров и их категорий, данные о заказах и заказанных товарах, список сотрудников компании. Подробное описание базы данных Northwind можно найти в справочных системах Microsoft SQL Server или Microsoft Access - здесь за недостатком места мы его не приводим.

Для рассмотрения концепции OLAP воспользуемся представлением Invoices и таблицами Products и Categories из базы данных Northwind, создав запрос, в результате которого получим подробные сведения о всех заказанных товарах и выписанных счетах:

SELECT dbo.Invoices.Country, dbo.Invoices.City, dbo.Invoices.CustomerName, dbo.Invoices.Salesperson, dbo.Invoices.OrderDate, dbo.Categories.CategoryName, dbo.Invoices.ProductName, dbo.Invoices.ShipperName, dbo.Invoices.ExtendedPrice FROM dbo.Products INNER JOIN dbo.Categories ON dbo.Products.CategoryID = dbo.Categories.CategoryID INNER JOIN dbo.Invoices ON dbo.Products.ProductID = dbo.Invoices.ProductID

В Access 2000 аналогичный запрос имеет вид:

SELECT Invoices.Country, Invoices.City, Invoices.Customers.CompanyName AS CustomerName, Invoices.Salesperson, Invoices.OrderDate, Categories.CategoryName, Invoices.ProductName, Invoices.Shippers.CompanyName AS ShipperName, Invoices.ExtendedPrice FROM Categories INNER JOIN (Invoices INNER JOIN Products ON Invoices.ProductID = Products.ProductID) ON Categories.CategoryID = Products.CategoryID;

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

Для удобства сохраним этот запрос в виде представления, назвав его Invoices1. Результат обращения к этому представлению приведен на рис. 1 .

Какие агрегатные данные мы можем получить на основе этого представления? Обычно это ответы на вопросы типа:

Какова суммарная стоимость заказов, сделанных клиентами из Франции?
Какова суммарная стоимость заказов, сделанных клиентами из Франции и доставленных компанией Speedy Express?
Какова суммарная стоимость заказов, сделанных клиентами из Франции в 1997 году и доставленных компанией Speedy Express?

Переведем эти вопросы в запросы на языке SQL (табл. 1).

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

Country	SUM (ExtendedPrice)
Argentina	7327.3
Austria	110788.4
Belgium	28491.65
Brazil	97407.74
Canada	46190.1
Denmark	28392.32
Finland	15296.35
France	69185.48
Germany	209373.6
…	…

Полученный набор агрегатных значений (в данном случае - сумм) может быть интерпретирован как одномерный набор данных. Этот же набор данных можно получить и в результате запроса с предложением GROUP BY следующего вида:

SELECT Country, SUM (ExtendedPrice) FROM invoices1 GROUP BY Country

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

	ShipperName
Country	Federal Shipping	Speedy Express	United Package
Argentina	1 210.30	1 816.20	5 092.60
Austria	40 870.77	41 004.13	46 128.93
Belgium	11 393.30	4 717.56	17 713.99
Brazil	16 514.56	35 398.14	55 013.08
Canada	19 598.78	5 440.42	25 157.08
Denmark	18 295.30	6 573.97	7 791.74
Finland	4 889.84	5 966.21	7 954.00
France	28 737.23	21 140.18	31 480.90
Germany	53 474.88	94 847.12	81 962.58
…	…	…	…

Такой набор данных называется сводной таблицей (pivot table) или кросс-таблицей (cross table, crosstab). Создавать подобные таблицы позволяют многие электронные таблицы и настольные СУБД - от Paradox для DOS до Microsoft Excel 2000. Вот так, например, выглядит подобный запрос в Microsoft Access 2000:

TRANSFORM Sum(Invoices1.ExtendedPrice) AS SumOfExtendedPrice SELECT Invoices1.Country FROM Invoices1 GROUP BY Invoices1.Country PIVOT Invoices1.ShipperName;

Агрегатные данные для подобной сводной таблицы можно получить и с помощью обычного запроса GROUP BY:

SELECT Country,ShipperName, SUM (ExtendedPrice) FROM invoices1 GROUP BY COUNTRY,ShipperName Отметим, однако, что результатом этого запроса будет не сама сводная таблица, а лишь набор агрегатных данных для ее построения (ниже показан фрагмент):

Country	ShipperName	SUM (ExtendedPrice)
Argentina	Federal Shipping	845.5
Austria	Federal Shipping	35696.78
Belgium	Federal Shipping	8747.3
Brazil	Federal Shipping	13998.26
…	…	…

Третий из рассмотренных выше запросов имеет уже три параметра в условии WHERE. Варьируя их, мы получим трехмерный набор данных (рис. 2).

Ячейки куба, показанного на рис. 2 , содержат агрегатные данные, соответствующие находящимся на осях куба значениям параметров запроса в предложении WHERE.

Можно получить набор двухмерных таблиц с помощью сечения куба плоскостями, параллельными его граням (для их обозначения используют термины cross-sections и slices).

Очевидно, что данные, содержащиеся в ячейках куба, можно получить и с помощью соответствующего запроса с предложением GROUP BY. Кроме того, некоторые электронные таблицы (в частности, Microsoft Excel 2000) также позволяют построить трехмерный набор данных и просматривать различные сечения куба, параллельные его грани, изображенной на листе рабочей книги (workbook).

Если в предложении WHERE содержится четыре или более параметров, результирующий набор значений (также называемый OLAP-кубом) может быть 4-мерным, 5-мерным и т.д.

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

Некоторые термины и понятия

Наряду с суммами в ячейках OLAP-куба могут содержаться результаты выполнения иных агрегатных функций языка SQL, таких как MIN, MAX, AVG, COUNT, а в некоторых случаях - и других (дисперсии, среднеквадратичного отклонения и т.д.). Для описания значений данных в ячейках используется термин summary (в общем случае в одном кубе их может быть несколько), для обозначения исходных данных, на основе которых они вычисляются, - термин measure, а для обозначения параметров запросов - термин dimension (переводимый на русский язык обычно как «измерение», когда речь идет об OLAP-кубах, и как «размерность», когда речь идет о хранилищах данных). Значения, откладываемые на осях, называются членами измерений (members).

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

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

Отметим, что иерархии могут быть сбалансированными (balanced), как, например, иерархия, представленная на рис. 3 , а также иерархии, основанные на данных типа «дата-время», и несбалансированными (unbalanced). Типичный пример несбалансированной иерархии - иерархия типа «начальник-подчиненный» (ее можно построить, например, используя значения поля Salesperson исходного набора данных из рассмотренного выше примера), представлен на рис. 4 .

Иногда для таких иерархий используется термин Parent-child hierarchy.

Существуют также иерархии, занимающие промежуточное положение между сбалансированными и несбалансированными (они обозначаются термином ragged - «неровный»). Обычно они содержат такие члены, логические «родители» которых находятся не на непосредственно вышестоящем уровне (например, в географической иерархии есть уровни Country, City и State, но при этом в наборе данных имеются страны, не имеющие штатов или регионов между уровнями Country и City; рис. 5).

Отметим, что несбалансированные и «неровные» иерархии поддерживаются далеко не всеми OLAP-средствами. Например, в Microsoft Analysis Services 2000 поддерживаются оба типа иерархии, а в Microsoft OLAP Services 7.0 - только сбалансированные. Различным в разных OLAP-средствах может быть и число уровней иерархии, и максимально допустимое число членов одного уровня, и максимально возможное число самих измерений.

Заключение

В данной статье мы ознакомились с основами OLAP. Мы узнали следующее:

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

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

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

КомпьютерПресс 4"2001

ведение

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

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

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

Технология комплексного многомерного анализа данных получила название OLAP (On-Line Analytical Processing).

OLAP – это ключевой компонент организации хранилищ данных.

Концепция OLAP была описана в 1993 году Эдгаром Коддом, известным исследователем баз данных и автором реляционной модели данных (см. E.F. Codd, S.B. Codd, and C.T.Salley, Providing OLAP (on-line analytical processing) to user-analysts: An IT mandate. Technical report, 1993).

В 1995 году на основе требований, изложенных Коддом, был сформулирован так называемый тест FASMI (Fast Analysis of Shared Multidimensional Information – быстрый анализ разделяемой многомерной информации), включающий следующие требования к приложениям для многомерного анализа:

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

· возможность осуществления любого логического и статистического анализа, характерного для данного приложения, и его сохранения в доступном для конечного пользователя виде;

· многопользовательский доступ к данным с поддержкой соответствующих механизмов блокировок и средств авторизованного доступа;

· многомерное концептуальное представление данных, включая полную поддержку для иерархий и множественных иерархий (это – ключевое требование OLAP);

· возможность обращаться к любой нужной информации независимо от ее объема и места хранения.

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

2. Что такое OLAP

OLAP – аббревиатура от английского On-Line Analytical Processing – это название не конкретного продукта, а целой технологии. По-русски удобнее всего называть OLAP оперативной аналитической обработкой. Хотя в некоторых изданиях аналитическую обработку называют и онлайновой, и интерактивной, однако прилагательное “оперативная” как нельзя более точно отражает смысл технологии OLAP.

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

Рассмотрим, как обычно происходит процесс разработки решений.

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

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

В действительности проблемы эти не являются следствием низкого качества оперативной системы или ее неудачной постройки. Корни проблем кроются в фундаментальном отличии той оперативной деятельности, которая автоматизируется оперативной системой, и деятельностью по разработке и принятию решений. Отличие это состоит в том, что данные оперативных систем являются просто записями о некоторых имевших место событиях, фактах, но никак не информацией в общем смысле этого слова. Информация – то, что снижает неопределенность в какой-либо области. И очень неплохо, если бы информация снижала неопределенность в области подготовки решений. По поводу непригодности для этой цели оперативных систем, построенных на РСУБД, в свое время высказался небезызвестный E.F. Codd, человек, стоявший в 70-е годы у истоков технологий систем управления реляционными БД: “Хотя системы управления реляционными БД доступны для пользователей, они никогда не считались средством, дающим мощные функции по синтезу, анализу и консолидации (функций, называемых многомерным анализом данных)”. Речь идет именно о синтезе информации, о том, чтобы превращать данные оперативных систем в информацию и даже в качественные оценки. OLAP позволяет выполнять такое превращение.

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

3. История создания OLAP-технологии

Идея обработки данных на многомерных массивах не является новой. Фактически она восходит к 1962 году, когда Ken Iverson опубликовал свою книгу “Язык программирования” (“A Programming Language”, APL). Первая практическая реализация APL состоялась в поздних шестидесятых компанией IBM. APL – это очень изящный, математически определённый язык с многомерными переменными и обрабатываемыми операциями. Он подразумевался как оригинальное мощное средство по работе с многомерными преобразованиями по сравнению с другими практическими языками программирования.

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

Однако досада от этих первоначальных ошибок не убила идею. Она использовалась во многих деловых приложениях 70-х, 80-х годов. Многие из этих приложений имели черты современных систем аналитической обработки. Так, IBM разработала операционную систему для APL, названную VSPC, и некоторые люди считали ее идеальной средой для персонального использования, пока электронные таблицы не стали повсеместно распространены.

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

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

В 1972 году несколько прикладных многомерных программных продуктов, ранее использовавшихся в учебных целях, нашли коммерческое применение: Express. Он в полностью переписанном виде остаётся и сейчас, однако оригинальные концепции 70-х годов перестали быть актуальными. Сегодня, в 90-х, Express является одной из наиболее популярных OLAP-технологий, и Oracle (r) будет продвигать его и дополнять новыми возможностями.

Больше многомерных продуктов появилось в 80-х годах. В начале десятилетия – продукт с названием Stratagem, позднее называемый Acumate (сегодня владельцем является Kenan Technologies), который еще продвигался до начала 90-х, но сегодня, в отличие от Express, практически не используется.

Comshare System W был многомерным продуктом другого стиля. Представленный в 1981 году, он был первым, где предполагалась большая ориентированность на конечного пользователя и на разработку финансовых приложений. Он привнёс много концепций, которые, правда, не были хорошо адаптированы, такие, как полностью непроцедурные правила, полноэкранный просмотр и редактирование многомерных данных, автоматическое перевычисление и пакетная интеграция с реляционными данными. Однако Comshare System W был достаточно тяжел для аппаратного обеспечения того времени по сравнению с другими продуктами и меньше использовался в будущем, продавался всё меньше, и в продукте не делалось никаких улучшений. Хотя он и сегодня доступен на UNIX, он не является клиент-серверным, что не способствует повышению его предложения на рынке аналитических продуктов. В поздних 80-х Comshare выпустил продукт для DOS, а позднее для Windows. Эти продукты назывались Commander Prism и использовали те же концепции, что и System W.

Другой творческий продукт поздних 80-х назывался Metaphor. Он предназначался для профессиональных маркетологов. Он также предложил много новых концепций, которые только сегодня начинают широко использоваться: клиент-серверные вычисления, использование многомерной модели на реляционных данных, объектно-ориентированная разработка приложений. Однако стандартное аппаратное обеспечение персональных машин тех дней не было способно работать с Metaphor и поставщики вынуждены были разрабатывать собственные стандарты на персональные машины и сети. Постепенно Metaphor стал работать удачно и на серийных персональных машинах, однако продукт был выполнен исключительно для OS/2 и имел свой собственный графический интерфейс пользователя.

Затем Metaphor заключил маркетинговый альянс с IBM, которой впоследствии и был поглощён. В середине 1994 года IBM решила интегрировать технологию Metaphor (переименованную в DIS) со своими будущими технологиями и тем самым прекратить финансирование отдельного направления, однако заказчики выразили своё неудовольствие и потребовали продолжить поддержку продукта. Поддержка была продолжена для оставшихся заказчиков, а IBM перевыпустила продукт под новым названием DIS, что, однако, не сделало его популярным. Но творческие, новаторские концепции Metaphor не были забыты и видны сегодня во многих продуктах.

В середине 80-х родился термин EIS (Executive Information System – информационная система руководителя). Первым продуктом, ясно продемонстрировавшим это направление, был Pilot’s Command Center. Это был продукт, который позволял выполнять совместные вычисления, то, что мы называем сегодня клиент-серверными вычислениями. Поскольку мощность персональных компьютеров 80-х годов была ограничена, продукт был очень “сервероцентричен”, однако этот принцип и сегодня очень популярен. Pilot недолго продавал Command Center, но предложил много концепций, которые можно узнать в сегодняшних OLAP-продуктах, включая автоматическую поддержку временных промежутков, многомерные клиент-серверные вычисления и упрощённое управление процессом анализа (мышь, чувствительные экраны и т.п.). Некоторые из этих концепций были повторно применены позднее в Pilot Analysis Server.

В конце 80-х электронные таблицы были доминирующими на рынке инструментов, предоставляющих анализ конечным пользователям. Первая многомерная электронная таблица была представлена продуктом Compete. Он продвигался на рынок как очень дорогой продукт для специалистов, но поставщики не обеспечили возможность захвата рынка этим продуктом, и компания Computer Associates приобрела права на него вместе с другими продуктами, включая Supercalc и 20/20. Основным эффектом от приобретения CA Compete было резкое снижение цены на него и снятие защиты от копирования, что, естественно, способствовало его распространению. Однако он не был удачным. Compete положен в основу Supercalc 5, но многомерный аспект его не продвигается. Старый Compete всё ещё иногда используют в связи с тем, что в свое время в него были вложены немалые средства.

Компания Lotus была следующей, кто попытался войти на рынок многомерных электронных таблиц с продуктом Improv, который запускается на NeXT машине. Это гарантировало, как минимум, что продажи 1-2-3 не снизятся, но когда тот со временем был выпущен под Windows, Excel уже имел большую долю рынка, что не позволило Lotus внести какие-либо изменения в распределение рынка. Lotus, подобно CA с Compete, переместила Improv в нижнюю часть рынка, однако и это не стало условием удачного продвижения на рынке, и новые разработки в этой области не получили продолжения. Оказалось, что пользователи персональных компьютеров предпочли электронные таблицы 1-2-3 и не интересуются новыми многомерными возможностями, если они не полностью совместимы с их старыми таблицами. Так же концепции маленьких, настольных электронных таблиц, предлагаемых как персональные приложения, в действительности не оказались удобными и не прижились в настоящем деловом мире. Microsoft (r) пошла по этому пути, добавив PivotTables (в русской редакции это называется “сводные таблицы”) к Excel. Хотя немногие пользователи Excel получили выгоду от использования этой возможности, это, вероятно, единственный факт широкого использования в мире возможностей многомерного анализа просто потому, что в мире очень много пользователей Excel.

4. OLAP, ROLAP, MOLAP…

Общеизвестно, что когда Кодд опубликовал в 1985 году свои правила построения реляционных СУБД, они вызвали бурную реакцию и впоследствии сильно отразились вообще на индустрии СУБД. Однако мало кто знает, что в 1993 году Кодд опубликовал труд под названием “OLAP для пользователей-аналитиков: каким он должен быть”. В нем он изложил основные концепции оперативной аналитической обработки и определил 12 правил, которым должны удовлетворять продукты, предоставляющие возможность выполнения оперативной аналитической обработки.

Вот эти правила (текст оригинала сохранен по возможности):

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

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

3. Доступность. Пользователь-аналитик OLAP должен иметь возможность выполнять анализ, базирующийся на общей концептуальной схеме, содержащей данные всего предприятия в реляционной БД, также как и данные из старых наследуемых БД, на общих методах доступа и на общей аналитической модели. Это значит, что OLAP должен предоставлять свою собственную логическую схему для доступа в гетерогенной среде БД и выполнять соответствующие преобразования для предоставления данных пользователю. Более того, необходимо заранее позаботиться о том, где и как, и какие типы физической организации данных действительно будут использоваться. OLAP-система должна выполнять доступ только к действительно требующимся данным, а не применять общий принцип “кухонной воронки”, который влечет ненужный ввод.

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

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

6. Общая многомерность. Каждое измерение должно применяться безотносительно своей структуры и операционных способностей. Дополнительные операционные способности могут предоставляться выбранным измерениям, и, поскольку измерения симметричны, отдельно взятая функция может быть предоставлена любому измерению. Базовые структуры данных, формулы и форматы отчетов не должны смещаться в сторону какого-либо измерения.

7. Динамическое управление разреженными матрицами. Физическая схема OLAP-инструмента должна полностью адаптироваться к специфической аналитической модели для оптимального управления разреженными матрицами. Для любой взятой разреженной матрицы существует одна и только одна оптимальная физическая схема. Эта схема предоставляет максимальную эффективность по памяти и операбельность матрицы, если, конечно, весь набор данных не помещается в памяти. Базовые физические данные OLAP-инструмента должны конфигурироваться к любому подмножеству измерений, в любом порядке, для практических операций с большими аналитическими моделями. Физические методы доступа также должны динамически меняться и содержать различные типы механизмов, таких как: непосредственные вычисления, B-деревья и производные, хеширование, возможность комбинировать эти механизмы при необходимости. Разреженность (измеряется в процентном отношении пустых ячеек ко всем возможным) – это одна из характеристик распространения данных. Невозможность регулировать разреженность может сделать эффективность операций недостижимой. Если OLAP-инструмент не может контролировать и регулировать распространение значений анализируемых данных, модель, претендующая на практичность, базирующаяся на многих путях консолидации и измерениях, в действительности может оказаться ненужной и безнадежной.

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

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

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

11. Гибкие возможности получения отчетов. Анализ и представление данных являются простыми, когда строки, столбцы и ячейки данных, которые будут визуально сравниваться между собой, будут находиться вблизи друг друга или по некоторой логической функции, имеющей место на предприятии. Средства формирования отчетов должны представлять синтезируемые данные или информацию, следующую из модели данных в ее любой возможной ориентации. Это означает, что строки, столбцы или страницы должны показывать одновременно от 0 до N измерений, где N – число измерений всей аналитической модели. В дополнение каждое измерение содержимого, показанное в одной записи, колонке или странице, должно также быть способно показать любое подмножество элементов (значений), содержащихся в измерении, в любом порядке.

12. Неограниченная размерность и число уровней агрегации. Исследование о возможном числе необходимых измерений, требующихся в аналитической модели, показало, что одновременно может использоваться до 19 измерений. Отсюда вытекает настоятельная рекомендация, чтобы аналитический инструмент был способен предоставить хотя бы 15 измерений одновременно и предпочтительно 20. Более того, каждое из общих измерений не должно быть ограничено по числу определяемых пользователем-аналитиком уровней агрегации и путей консолидации.

Фактически сегодня разработчики OLAP-продуктов следуют этим правилам или, по крайней мере, стремятся им следовать. Эти правила можно считать теоретическим базисом оперативной аналитической обработки, с ними трудно спорить. Впоследствии было выведено множество следствий из 12 правил, которые мы, однако, не будем приводить, дабы излишне не усложнять повествование.

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

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

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

ROLAP. Реляционная (relational) OLAP. Как и подразумевается названием, многомерная структура в таких инструментах реализуется реляционными таблицами. А данные в процессе анализа, соответственно, выбираются из реляционной базы данных аналитическим инструментом.

Недостатки и преимущества каждого подхода, в общем-то, очевидны. Многомерная OLAP обеспечивает лучшую производительность, но структуры нельзя использовать для обработки больших объемов данных, поскольку большая размерность потребует больших аппаратных ресурсов, а вместе с тем разреженность гиперкубов может быть очень высокой и, следовательно, использование аппаратных мощностей не будет оправданным. Наоборот, реляционная OLAP обеспечивает обработку на больших массивах хранимых данных, так как возможно обеспечение более экономичного хранения, но, вместе с тем, значительно проигрывает в скорости работы многомерной. Подобные рассуждения привели к выделению нового класса аналитических инструментов – HOLAP. Это гибридная (hybrid) оперативная аналитическая обработка. Инструменты этого класса позволяют сочетать оба подхода – реляционного и многомерного. Доступ может вестись как к данным многомерных баз, так и к данным реляционных.

Есть еще один достаточно экзотический вид оперативной аналитической обработки – DOLAP. Это “настольный” (desktop) OLAP. Речь идет о такой аналитической обработке, где гиперкубы малы, размерность их небольшая, потребности скромны, и для такой аналитической обработки достаточно персональной машины на рабочем столе.

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

Структурированные отчеты – это те рельсы, которые сдерживают свободу в подготовке решений. OLAP – автомобиль для эффективного движения по информационным магистралям.

Отправить свою хорошую работу в базу знаний просто. Используйте форму, расположенную ниже

Студенты, аспиранты, молодые ученые, использующие базу знаний в своей учебе и работе, будут вам очень благодарны.

Размещено на http://www.allbest.ru/

Курсовая работа

по дисциплине: Базы данных

Тема: Технология OLAP

Выполнил:

Чижиков Александр Александрович

Введение

1. Классификация OLAP-продуктов

2. OLAP-клиент - OLAP-сервер: "за" и "против"

3. Ядро OLAP системы

3.1 Принципы построения

Заключение

Список использованных источников

Приложения

В ведение

Трудно найти в компьютерном мире человека, который хотя бы на интуитивном уровне не понимал, что такое базы данных и зачем они нужны. В отличие от традиционных реляционных СУБД, концепция OLAP не так широко известна, хотя загадочный термин "кубы OLAP" слышали, наверное, почти все. Что же такое OnLine Analytical Processing?

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

Дело в том, что аналитики - это особые потребители корпоративной информации. Задача аналитика - находить закономерности в больших массивах данных. Поэтому аналитик не будет обращать внимания на отдельно взятый факт, ему нужна информация о сотнях и тысячах событий. Кстати, один из существенных моментов, который привел к появлению OLAP - производительность и эффективность. Представим себе, что происходит, когда аналитику необходимо получить информацию, а средства OLAP на предприятии отсутствуют. Аналитик самостоятельно (что маловероятно) или с помощью программиста делает соответствующий SQL-запрос и получает интересующие данные в виде отчета или экспортирует их в электронную таблицу. Проблем при этом возникает великое множество. Во-первых, аналитик вынужден заниматься не своей работой (SQL-программированием) либо ждать, когда за него задачу выполнят программисты - все этоотрицательно сказывается на производительности труда, повышается инфарктно-инсультный уровень и так далее. Во-вторых, один-единственный отчет или таблица, как правило, не спасает гигантов мысли и отцов русского анализа - и всю процедуру придется повторять снова и снова. В-третьих, как мы уже выяснили, аналитики по мелочам не спрашивают - им нужно все и сразу. Это означает (хотя техника и идет вперед семимильными шагами), что сервер корпоративной реляционной СУБД, к которому обращается аналитик, может задуматься глубоко и надолго, заблокировав остальные транзакции.

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

Конечно, за повышение таким способом производительности надо платить. Иногда говорят, что структура данных просто "взрывается" - куб OLAP может занимать в десятки и даже сотни раз больше места, чем исходные данные.

Теперь, когда мы немного разобрались в том, как работает и для чего служит OLAP, стоит, все же, несколько формализовать наши знания и дать критерии OLAP уже без синхронного перевода на обычный человеческий язык. Эти критерии (всего числом 12) были сформулированы в 1993 году Е.Ф. Коддом - создателем концепции реляционных СУБД и, по совместительству, OLAP. Непосредственно их мы рассматривать не будем, поскольку позднее они были переработаны в так называемый тест FASMI, который определяет требования к продуктам OLAP. FASMI - это аббревиатура от названия каждого пункта теста:

Fast (быстрый). Это свойство означает, что система должна обеспечивать ответ на запрос пользователя в среднем за пять секунд; при этом большинство запросов обрабатываются в пределах одной секунды, а самые сложные запросы должны обрабатываться в пределах двадцати секунд. Недавние исследования показали, что пользователь начинает сомневаться в успешности запроса, если он занимает более тридцати секунд.

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

Shared (разделяемый). Система должна предоставлять широкие возможности разграничения доступа к данным и одновременной работы многих пользователей.

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

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

1. Классификация OLAP-продуктов

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

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

Начну я с классификации по способу хранения данных. Напомню, что многомерные кубы строятся на основе исходных и агрегатных данных. И исходные и агрегатные данные для кубов могут храниться как в реляционных, так и многомерных базах данных. Поэтому в настоящее время применяются три способа хранения данных: MOLAP (Multidimensional OLAP), ROLAP (Relational OLAP) и HOLAP (Hybrid OLAP). Соответственно, OLAP-продукты по способу хранения данных делятся на три аналогичные категории:

1.В случае MOLAP, исходные и агрегатные данные хранятся в многомерной БД или в многомерном локальном кубе.

2.В ROLAP-продуктах исходные данные хранятся в реляционных БД или в плоских локальных таблицах на файл-сервере. Агрегатные данные могут помещаться в служебные таблицы в той же БД. Преобразование данных из реляционной БД в многомерные кубы происходит по запросу OLAP-средства.

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

Следующая классификация - по месту размещения OLAP-машины. По этому признаку OLAP-продукты делятся на OLAP-серверы и OLAP-клиенты:

В серверных OLAP-средствах вычисления и хранение агрегатных данных выполняются отдельным процессом - сервером. Клиентское приложение получает только результаты запросов к многомерным кубам, которые хранятся на сервере. Некоторые OLAP-серверы поддерживают хранение данных только в реляционных базах, некоторые - только в многомерных. Многие современные OLAP-серверы поддерживают все три способа хранения данных: MOLAP, ROLAP и HOLAP.

OLAP-клиент устроен по-другому. Построение многомерного куба и OLAP-вычисления выполняются в памяти клиентского компьютера. OLAP-клиенты также делятся на ROLAP и MOLAP. А некоторые могут поддерживать оба варианта доступа к данным.

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

2. OLAP-клиент - OLAP-сервер: "за" и "против"

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

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

Клиентские программы в момент выполнения OLAP-операций выполняют к ней запросы на SQL-подобном языке, получая не весь куб, а его отображаемые фрагменты. OLAP-клиент в момент работы должен иметь в оперативной памяти весь куб. В случае ROLAP-архитектуры, необходимо предварительно загрузить в память весь используемый для вычисления куба массив данных. Кроме того, при увеличении числа измерений, фактов или элементов измерений количество агрегатов растет в геометрической прогрессии. Таким образом, объем данных, обрабатываемых OLAP-клиентом, находится в прямой зависимости от объема оперативной памяти ПК пользователя.

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

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

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

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

Схема 1. Зависимость производительности клиентских и серверных OLAP-средств от увеличения объема данных

Скоростные характеристики OLAP-сервера менее чувствительны к росту объема данных. Это объясняется различными технологиями обработки запросов пользователей OLAP-сервером и OLAP-клиентом. Например, при операции детализации OLAP-сервер обращается к хранимым данным и "вытягивает" данные этой "ветки". OLAP-клиент же вычисляет весь набор агрегатов в момент загрузки. Однако до определенного объема данных производительность серверных и клиентских средств является сопоставимой. Для OLAP-клиентов, поддерживающих распределенные вычисления, область сопоставимости производительности может распространяться на объемы данных, покрывающие потребности в OLAP-анализе огромного количества пользователей. Это подтверждают результаты внутреннего тестирования MS OLAP Server и OLAP-клиента "Контур Стандарт". Тест выполнен на ПК IBM PC Pentium Celeron 400 МГц, 256 Mb для выборки в 1 миллион уникальных (т.е. агрегированных) записей с 7 измерениями, содержащими от 10 до 70 членов. Время загрузки куба в обоих случаях не превышает 1 секунды, а выполнение различных OLAP-операций (drill up, drill down, move, filter и др.) выполняется за сотые доли секунды.

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

Следует помнить, что точка "перелома" определяет границу резкого удорожания OLAP-решения. Для задач каждого конкретного пользователя эта точка легко определяется по тестам производительности OLAP-клиента. Такие тесты можно получить у компании-разработчика.

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

Использование OLAP-сервера в "классической" идеологии предусматривает выгрузку данных реляционных СУБД в многомерную БД. Выгрузка выполняется за определенный период, поэтому данные OLAP-сервера не отражают состояние на текущий момент. Этого недостатка лишены только те OLAP-серверы, которые поддерживают ROLAP-режим работы.

Аналогичным образом, целый ряд OLAP-клиентов позволяет реализовать ROLAP- и Desktop-архитектуру с прямым доступом к БД. Это обеспечивает анализ исходных данных в режиме on-line.

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

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

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

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

Поэтому там, где применяется OLAP-клиент, сетевой трафик будет выше.

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

Также необходимо отметить, что современное сетевое аппаратное обеспечение обеспечивает высокий уровень пропускной способности.

Поэтому в подавляющем большинстве случаев анализ БД "средних" размеров с помощью OLAP-клиента не будет тормозить работу пользователя.

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

Стоимость OLAP-клиента на порядок ниже стоимости OLAP-сервера. Администрирования и дополнительного технического оборудования под сервер не требуется. К квалификации персонала при внедрении OLAP-клиента высоких требований не предъявляется. OLAP-клиент может быть внедрен значительно быстрее OLAP-сервера.

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

Рассмотрим процесс создания OLAP-приложения с помощью клиентского инструментального средства.

Схема 2. Создание OLAP-приложения с помощью клиентского ROLAP-средства

Принцип работы ROLAP-клиентов - предварительное описание семантического слоя, за которым скрывается физическая структура исходных данных. При этом источниками данных могут быть: локальные таблицы, РСУБД. Список поддерживаемых источников данных определяется конкретным программным продуктом. После этого пользователь может самостоятельно манипулировать понятными ему объектами в терминах предметной области для создания кубов и аналитических интерфейсов.

Принцип работы клиента OLAP-сервера иной. В OLAP-сервере при создании кубов пользователь манипулирует физическими описаниями БД.

При этом в самом кубе создаются пользовательские описания. Клиент OLAP-сервера настраивается только на куб.

Поясним принцип работы ROLAP-клиента на примере создания динамического отчета о продажах (см. схему 2). Пусть исходные данные для анализа хранятся в двух таблицах: Sales и Deal.

При создании семантического слоя источники данных - таблицы Sales и Deal - описываются понятными конечному пользователю терминами и превращаются в "Продукты" и "Сделки". Поле "ID" из таблицы "Продукты" переименовывается в "Код", а "Name" - в "Товар" и т.д.

Затем создается бизнес-объект "Продажи". Бизнес-объект - это плоская таблица, на основе которой формируется многомерный куб. При создании бизнес-объекта таблицы "Продукты" и "Сделки" объединяются по полю "Код" товара. Поскольку для отображения в отчете не потребуются все поля таблиц - бизнес-объект использует только поля "Товар", "Дата" и "Сумма".

Далее на базе бизнес-объекта создается OLAP-отчет. Пользователь выбирает бизнес-объект и перетаскивает его атрибуты в области колонок или строк таблицы отчета. В нашем примере на базе бизнес-объекта "Продажи" создан отчет по продажам товаров по месяцам.

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

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

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

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

Мощные ПК аналитиков - еще один довод в пользу OLAP-клиентов. При применении OLAP-сервера эти мощности не используются. Среди преимуществ OLAP-клиентов можно также назвать следующее:

Затраты на внедрение и сопровождение OLAP-клиента существенно ниже, чем затраты на OLAP-сервер.

При использовании OLAP-клиента со встроенной машиной передача данных по сети производится один раз. При выполнении OLAP-операций новых потоков данных не порождается.

Настройка ROLAP-клиентов упрощена за счет исключения промежуточного звена - создания многомерной базы.

3. Ядро OLAP системы

3.1 Принципы построения

приложение клиентский ядро данные

Из уже сказанного, ясно, что механизм OLAP является на сегодня одним из популярных методов анализа данных. Есть два основных подхода к решению этой задачи. Первый из них называется Multidimensional OLAP (MOLAP) - реализация механизма при помощи многомерной базы данных на стороне сервера, а второй Relational OLAP (ROLAP) - построение кубов "на лету" на основе SQL запросов к реляционной СУБД. Каждый из этих подходов имеет свои плюсы и минусы. Их сравнительный анализ выходит за рамки этой работы. Здесь будет описана только реализация ядра настольного ROLAP модуля.

В Интернете и прессе можно найти много информации об OLAP системах, но практически нигде не сказано о том, как это устроено внутри.

Схема работы:

Общую схему работы настольной OLAP системы можно представить следующим образом:

Схема 3. Работа настольной OLAP системы

Алгоритм работы следующий:

1.Получение данных в виде плоской таблицы или результата выполнения SQL запроса.

2.Кэширование данных и преобразование их к многомерному кубу.

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

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

Таким образом, таблицу можно разделить на следующие элементы, с которыми мы и будем работать в дальнейшем:

Заполняя матрицу с фактами, мы должны действовать следующим образом:

На основании данных об измерениях определить координаты добавляемого элемента в матрице.

Определить координаты столбцов и строк итогов, на которые влияет добавляемый элемент.

Добавить элемент в матрицу и соответствующие столбцы и строки итогов.

При этом нужно отметить то, что полученная матрица будет сильно разреженной, почему ее организация в виде двумерного массива (вариант, лежащий на поверхности) не только нерациональна, но, скорее всего, и невозможна в связи с большой размерностью этой матрицы, для хранения которой не хватит никакого объема оперативной памяти. Например, если наш куб содержит информацию о продажах за один год, и если в нем будет всего 3 измерения - Клиенты (250), Продукты (500) и Дата (365), то мы получим матрицу фактов следующих размеров: кол-во элементов = 250 х 500 х 365 = 45 625 000. И это при том, что заполненных элементов в матрице может быть всего несколько тысяч. Причем, чем больше количество измерений, тем более разреженной будет матрица.

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

Схема 4. Структура хранения уникальных значений

Описанные выше идеи были положены в основу при создании библиотеки компонентов CubeBase.

Схема 5. Структура библиотеки компонентов CubeBase

TСubeSource осуществляет кэширование и преобразование данных во внутренний формат, а также предварительное агрегирование данных. Компонент TСubeEngine осуществляет вычисление гиперкуба и операции с ним. Фактически, он является OLAP-машиной, осуществляющей преобразование плоской таблицы в многомерный набор данных. Компонент TCubeGrid выполняет вывод на экран кросс-таблицы и управление отображением гиперкуба. TСubeChart позволяет увидеть гиперкуб в виде графиков, а компонент TСubePivote управляет работой ядра куба.

Итак, мной была рассмотрена архитектура и взаимодействие компонентов, которые могут быть использованы для построения OLAP машины. Теперь рассмотрим подробнее внутреннее устройство компонентов.

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

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

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

Схема 6. Преобразование базы данных внутреннего формата в нормализованную базу данных

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

Схема 7. Перенумерация нормализованной БД для определения координат значений измерений

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

Схема 8. Внутреннее представление гиперкуба

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

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

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

проверка наличия элемента в словаре;

добавление элемента в словарь;

поиск номеров записей, имеющих конкретное значение координаты;

поиск координаты по значению измерения;

поиск значения измерения по его координате.

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

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

добавление нового значения;

определение координаты по значению измерения;

определение значения по координате.

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

PFactLink = ^TFactLink;

TFactLink = record

FactNo: integer; // индекс факта в таблице

TDimensionRecord = record

Value: string; // значение измерения

Index: integer; // значение координаты

FactLink: PFactLink; // указатель на начало списка элементов таблицы фактов

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

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

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

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

Заголовки имеют четкую иерархическую структуру, поэтому естественно будет предположить для их хранения использовать дерево. При этом схематически структуру узла дерева можно изобразить следующим образом:

Приложение С

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

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

Приложение D

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

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

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

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

Схема 9. Изображение сводной таблицы в виде двоичного дерева

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

В обобщенном виде последовательность действий для добавления элемента в матрицу можно описать следующим образом:

1.Определить номера строк, в которые добавляются элементы

2.Определить набор столбцов, в которые добавляются элементы

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

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

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

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

Первым продуктом, выполняющим OLAP-запросы, был Express (компания IRI). Однако, сам термин OLAP был предложен Эдгаром Коддом, «отцом реляционных БД». А работа Кодда финансировалась Arbor, компанией, выпустившей свой собственный OLAP-продукт - Essbase (позже купленный Hyperion, которая в 2007 г. была поглощена компанией Oracle) - годом ранее. Другие хорошо известные OLAP-продукты включают Microsoft Analysis Services (ранее называвшиеся OLAP Services, часть SQL Server), Oracle OLAP Option, DB2 OLAP Server от IBM (фактически, EssBase с дополнениями от IBM), SAP BW, продукты Brio, BusinessObjects, Cognos, MicroStrategy и других производителей.

C технической точки зрения, представленные на рынке продукты делятся на "физический OLAP" и "виртуальный". В первом случае наличествует программа, выполняющая предварительный расчет агрегатов, которые затем сохраняются в специальную многомерную БД, обеспечивающую быстрое извлечение. Примеры таких продуктов - Microsoft Analysis Services, Oracle OLAP Option, Oracle/Hyperion EssBase, Cognos PowerPlay. Во втором случае данные хранятся в реляционных СУБД, а агрегаты могут не существовать вообще или создаваться по первому запросу в СУБД или кэше аналитического ПО. Примеры таких продуктов - SAP BW, BusinessObjects, Microstrategy. Системы, имеющие в своей основе "физический OLAP" обеспечивают стабильно лучшее время отклика на запросы, чем системы "виртуальный OLAP". Поставщики систем "виртуальный OLAP" заявляют о большей масштабируемости их продуктов в плане поддержки очень больших объемов данных.

В настоящей работе мне хотелось бы подробнее рассмотреть продукт компании BaseGroup Labs - Deductor.

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

Состав системы:

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

Deductor Viewer является рабочим местом конечного пользователя. Программа позволяет минимизировать требования к персоналу, т.к. все требуемые операции выполняются автоматически при помощи подготовленных ранее сценариев обработки, нет необходимости задумываться о способе получения данных и механизмах их обработки. Пользователю Deduсtor Viewer необходимо только выбрать интересующий отчет.

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

4. Client-Server

Deductor Server предназначен для удаленной аналитической обработки. Он предоставляет возможность как автоматически "прогонять" данные через существующие сценарии на сервере, так и переобучать имеющиеся модели. Использование Deductor Server позволяет реализовать полноценную трехзвенную архитектуру, в которой он выполняет функцию сервера приложений. Доступ к серверу обсепечивается при помощи Deductor Client.

Принципы работы:

1. Импорт данных

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

2. Экспорт данных

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

3. Обработка данных

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

4. Визуализация

Визуализировать данные в Deductor Studio (Viewer) можно на любом этапе обработки. Система самостоятельно определяет, каким способом она может это сделать, например, если будет обучена нейронная сеть, то помимо таблиц и диаграмм, можно просмотреть граф нейросети. Пользователю необходимо выбрать нужный вариант из списка и настроить несколько параметров.

5. Механизмы интеграции

В Deductor не предусмотрено средств ввода данных - платформа ориентирована исключительно на аналитическую обработку. Для использования информации, хранящейся в разнородных системах, предусмотрены гибкие механизмы импорта-экспорта. Взаимодействие может быть организовано при помощи пакетного выполнения, работы в режиме OLE сервера и обращения к Deductor Server.

6.Тиражирование знаний

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

З аключение

В настоящей работе была рассмотрена такая область современных информационных технологий, как системы анализа данных. Проанализирован основной инструмент аналитической обработки информации - OLAP - технологии. Подробно раскрыта суть понятия OLAP и значение OLAP-систем в современном бизнес-процессе. Детально описана структура и процесс работы ROLAP-сервера. В качестве примера реализации данных OLAP - технологий приведена аналитическая платформа Deductor. Представляемая документация разработана и соответствует требованиям.

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

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

Подобные документы

Основа концепции OLAP (On-Line Analytical Processing) – оперативной аналитической обработки данных, особенности ее использования на клиенте и на сервере. Общие характеристика основных требования к OLAP-системам, а также способов хранения данных в них.

реферат , добавлен 12.10.2010

OLAP: общая характеристика, предназначение, цели, задачи. Классификация OLAP-продуктов. Принципы построения OLAP системы, библиотека компонентов CubeBase. Зависимость производительности клиентских и серверных OLAP-средств от увеличения объема данных.

курсовая работа , добавлен 25.12.2013

Вечное хранение данных. Сущность и значение средства OLAP (On-line Analytical Processing). Базы и хранилища данных, их характеристика. Структура, архитектура хранения данных, их поставщики. Несколько советов по повышению производительности OLAP-кубов.

контрольная работа , добавлен 23.10.2010

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

курсовая работа , добавлен 19.09.2008

Основные сведения об OLAP. Оперативная аналитическая обработка данных. Классификация продуктов OLAP. Требования к средствам оперативной аналитической обработки. Использование многомерных БД в системах оперативной аналитической обработки, их достоинства.

курсовая работа , добавлен 10.06.2011

Разработка подсистем анализа веб-сайта с помощью Microsoft Access и Olap-технологий. Теоретические аспекты разработки подсистемы анализа данных в информационной системе музыкального портала. Olap-технологии в подсистеме анализа объекта исследования.

курсовая работа , добавлен 06.11.2009

Рассмотрение OLAP-средств: классификация витрин и хранилищ информации, понятие куба данных. Архитектура системы поддержки принятия решений. Программная реализация системы "Abitura". Создание Web-отчета с использованием технологий Reporting Services.

курсовая работа , добавлен 05.12.2012

Хранилище данных, принципы организации. Процессы работы с данными. OLAP-структура, технические аспекты многомерного хранения данных. Integration Services, заполнение хранилищ и витрин данных. Возможности систем с использованием технологий Microsoft.

курсовая работа , добавлен 05.12.2012

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

контрольная работа , добавлен 19.12.2015

Назначение хранилищ данных. Архитектура SAP BW. Построение аналитической отчетности на основе OLAP-кубов в системе SAP BW. Основные различия между хранилищем данных и системой OLTP. Обзор функциональных сфер BEx. Создание запроса в BEx Query Designer.

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

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

История OLAP

OLAP не является новой концепцией и используется уже на протяжении десятилетий. По сути, происхождение технологии отслеживается еще с 1962 года. Но термин был придуман только в 1993 году автором базы данных Тедом Коддомом, который также установил 12 правил для продукта. Как и во многих других приложениях, концепция подвергалась нескольким этапам эволюции.

История самой OLAP-технологии восходит к 1970 году, когда были выпущены информационные ресурсы Express и первый Olap-сервер. Они были приобретены Oracle в 1995 году и впоследствии стали основой онлайн-аналитической обработки многомерного вычислительного механизма, который известный компьютерный бренд предоставлял в своей базе данных. В 1992 году еще один известный онлайн-аналитический продукт обработки Essbase был выпущен компанией Arbor Software (приобретенной Oracle в 2007 году).

В 1998 году Microsoft выпустила онлайн-аналитический сервер обработки данных MS Analysis Services. Это способствовало популярности технологии и побудило разработку других продуктов. Сегодня функционируют несколько всемирно известных поставщиков, предлагающих Olap-приложения, в том числе IBM, SAS, SAP, Essbase, Microsoft, Oracle, IcCube.

Онлайн-аналитическая обработка

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

Существуют следующие основные характеристики OLAP:

Многомерные представления данных.
Поддержка сложных вычислений.
Временная разведка.

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

Поддержка сложных вычислений является основой программного обеспечения OLAP.

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

Многомерная структура данных

Одной из основных характеристик онлайн-аналитической обработки является многомерная структура данных. Куб может иметь несколько измерений. Благодаря такой модели весь процесс интеллектуального OLAP-анализа является простым для менеджеров и руководителей, поскольку объекты, представленные в ячейках, являются бизнес-объектами реального мира. Кроме того, эта модель данных позволяет пользователям обрабатывать не только структурированные массивы, но и неструктурированные и полуструктурированные. Все это делает их особенно популярными для анализа данных и приложений BI.

Основные характеристики OLAP-систем:

Используют многомерные методы анализа данных.
Обеспечивают расширенную поддержку базы данных.
Создают простые в использовании интерфейсы конечных пользователей.
Поддерживают архитектуру клиент/сервер.

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

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

Кубическая форма

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

Куб OLAP также называется «гиперкубом». Он описывается как состоящий из числовых фактов (мер), классифицированных по фасетам (измерениям). Размеры относятся к атрибутам, которые определяют бизнес-проблему. Проще говоря, измерение - это метка, описывающая меру. Например, в отчетах о продажах мерой будет объем продаж, а размеры будут включать период продаж, продавцов, продукт или услугу, а также регион продаж. В отчетности по производственным операциям мерой могут быть общие производственные затраты и единицы продукции. Габаритами будут дата или время производства, этап производства или фаза, даже работники, вовлеченные в производственный процесс.

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

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

Объединение данных

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

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

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

Принцип работы

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

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

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

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

Преимущества модели массива

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

Меньший размер данных на диске.
Автоматизированное вычисление агрегатов более высокого уровня данных.
Модели массива обеспечивают естественную индексацию.
Эффективное извлечение данных достигается за счет предварительной структуризации.
Компактность для наборов данных с низкой размерностью.

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

Основные аналитические операции

Свертка (roll-up/drill-up) также известна как «консолидация». Свертывание включает в себя сбор всех данных, которые могут быть получены, и вычисление всех в одном или нескольких измерениях. Чаще всего это может потребовать применения математической формулы. В качестве OLAP-примера можно рассмотреть розничную сеть с торговыми точками в разных городах. Чтобы определить модели и предвидеть будущие тенденции продаж, данные о них из всех точек «свернуты» в основной отдел продаж компании для консолидации и расчета.

Раскрытие (drill-down). Это противоположность свертыванию. Процесс начинается с большого набора данных, а затем разбивается на его меньшие части, тем самым позволяя пользователям просматривать детали. В примере с розничной сетью аналитик будет анализировать данные о продажах и просматривать отдельные бренды или продукты, которые считаются бестселлерами в каждой из торговых точек в разных городах.

Сечение (Slice and dice). Это процесс, когда аналитические операции включают в себя два действия: вывести определенный набор данных из OLAP-куба («разрезающий» аспект анализа) и просматривать его с разных точек зрения или углов. Это может произойти, когда все данные торговых точек получены и введены в гиперкуб. Аналитик вырезает из OLAP Cube набор данных, относящихся к продажам. Далее он будет просмотрен при анализе продаж отдельных единиц в каждом регионе. В это время другие пользователи могут сосредоточиться на оценке экономической эффективности продаж или оценке эффективности маркетинговой и рекламной кампании.

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

Разновидности баз данных

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

	Значение
Реляционная OLAP (ROLAP)	ROLAP - это расширенная СУБД вместе с многомерным отображением данных для выполнения стандартной реляционной операции
Многомерный OLAP (MOLAP)	MOLAP - реализует работу в многомерных данных
Гибридная онлайн-аналитическая обработка (HOLAP)	В подходе HOLAP агрегированные итоговые значения хранятся в многомерной базе данных, а подробная информация хранится в реляционной базе. Это обеспечивает как эффективность модели ROLAP, так и производительность модели MOLAP
Рабочий стол OLAP (DOLAP)	В Desktop OLAP пользователь загружает часть данных из базы данных локально или на свой рабочий стол и анализирует ее. DOLAP относительно дешевле для развертывания, поскольку он предлагает очень мало функциональных возможностей по сравнению с другими системами OLAP
Веб-OLAP (WOLAP)	Web OLAP является системой OLAP, доступной через веб-браузер. WOLAP - это трехуровневая архитектура. Он состоит из трех компонентов: клиент, промежуточное программное обеспечение и сервер базы данных
Мобильный OLAP	Мобильный OLAP помогает пользователям получать и анализировать данные OLAP с помощью своих мобильных устройств
Пространственный OLAP	SOLAP создается для облегчения управления как пространственными, так и непространственными данными в географической информационной системе (ГИС)

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

Инструменты OLAP

Инструменты для онлайн-аналитической обработки очень хорошо представлены в Интернете в виде как платных, так и бесплатных версий.

Наиболее популярные из них:

Dundas BI из Dundas Data Visualization представляет собой основанную на браузере платформу для бизнес-аналитиков и визуализации данных, которая включает интегрированные информационные панели, средства OLAP-отчетов и аналитику данных.
Yellowfin - платформа бизнес-аналитики, которая представляет собой единое интегрированное решение, разработанное для компаний разных отраслей и масштабов. Эта система настраивается для предприятий в области бухгалтерского учета, рекламы, сельского хозяйства.
ClicData - это решение для бизнес-аналитиков (BI), предназначенное для использования в основном предприятиями малого и среднего бизнеса. Инструмент позволяет конечным пользователям создавать отчеты и информационные панели. Board создан для объединения бизнес-аналитики, управления корпоративной эффективностью и представляет собой полнофункциональную систему, которая обслуживает компании среднего и корпоративного уровня.
Domo - это облачный пакет управления бизнесом, который объединяется с несколькими источниками данных, включая электронные таблицы, базы данных, социальные сети и любое существующее облачное или локальное программное решение.
InetSoft Style Intelligence - это программная платформа для бизнес-аналитиков, которая позволяет пользователям создавать информационные панели, визуальную технологию анализа OLAP и отчеты с помощью механизма mashup.
Birst от Infor Company представляет собой сетевое решение для бизнес-аналитиков и анализа, который объединяет идеи различных команд и помогает принимать обоснованные решения. Инструмент позволяет децентрализованным пользователям увеличить модель корпоративных команд.
Halo - это комплексная система управления цепочками поставок и бизнес-аналитики, которая помогает в планировании бизнеса и прогнозировании запасов для управления цепочками поставок. Система использует данные из всех источников - больших, малых и промежуточных.
Chartio - это облачное решение для бизнес-аналитиков, которое предоставляет учредителям, бизнес-группам, аналитикам данных и группам продуктов инструменты организации для повседневной работы.
Exago BI - это веб-решение, предназначенное для внедрения в веб-приложения. Внедрение Exago BI позволяет компаниям всех размеров предоставлять своим клиентам специальную, оперативную и интерактивную отчетность.

Воздействие на бизнес

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

Некоторые из его наиболее распространенных приложений включают в себя:

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

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