1. Интерактивная аналитическая обработка данных (olap)

В этом разделе рассматривается природа многомерных данных, а также то, как эти данные могут быть наилучшим образом представлены в базе данных, предназначенной для оперативной аналитической обработки данных (Online Analytical Processing — OLAP). Кро­ме того, описываются требования, которым должны удовлетворять ОLAP-инструменты, и описываются основные характеристики трех категорий ОLAP-инструментов; MOLAP, RGLAP и MQE. В конце данного раздела дается краткий обзор расширений языка SQL, предназначенных для выполнения более сложных функций анализа данных.

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

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

Термин "OLAP" был предложен Коддом в 1993 году и определяет архитектуру, которая поддерживает сложные аналитические приложения. Большинство OLAP-приложений создается на основе специализированных многомерных СУБД (или ММ СУБД (mult-dimensional DBMS)) c ограниченным набором данных и настраиваемым пользовательским интерфейсом приложений. QLAP-архитектура предусматривает определенные уровни с четким разделением функций между приложением и СУБД. На основе этого разделения появилось новое поколение OLAP-инструментов, предос­тавляющих такие возможности, которые позволяют обычным СУБД конкурировать со специализированными технологиями ММ СУБД.

1.1. Многомерная olap-технология

Мы начнем нашу работу с рассмотрения нескольких альтернативных вариантов представления многомерных данных. Например, рассмотрим, как лучше всего представить запрос типа следующего: "Каким был общий доход от продаж объектов недвижимости в каждом городе в каждом квартале 1997 года?". Соответствующие дан­ные можно разместить в реляционной таблице с тремя столбцами, представленной на рисунке 1 А, однако они более естественно укладываются н двумерной матрице с размерностями City (Город) и Time ((время) (в данном случае поквартально)) — как показано на рисунке 1 Б. Основаниями для выбора одного из этик представлений могут быть только типы запросов со стороны пользователей. Если пользователь будет составлять простые запросы типа: "Каким был доход, полученный в городе Глазго в первом квартале?" или другие подобные этому запросы, предназначенные для извле­чения единственного значения, то никакой потребности в создании и использовании многомерной базы данных нет. Однако если пользователь попробует составить запрос типа: "Каким был суммарный годовой доход для каждого города?" или "Каким был средний доход для каждого города?", то для получения ответа потребуется извлечь большое количество значений и выполнить их обобщение. Если речь идет о большой базе данных, содержащей сведения об операциях продажи в тысячах городов, то для выполнения необходимых расчетов реляционной СУБД потребуется очень много вре­мени. Типичная РСУБД способна сканировать всего несколько сотен строк в секунду, тогда как типичная ММ СУБД способна выполнять обобщающие операции со скоро­стью до 10 000 строк в секунду и даже выше.

Рассмотрим теперь те же данные о доходах, но с учетом дополнительной размерно­сти — а именно, типа недвижимости. В этом случае имеющиеся данные представляют общий доход, но в зависимости от типа объектов недвижимости (т.е. от размерности Prop­erty_Туре, причем для простоты предположим, что это может быть только квартира (Flat) или дом (House))» города и времени (поквартально). В этом случае данные также могут быть размещены в таблице с четырьмя полями, как показано на рисунке 1 В. Но более ес­тественно было бы разместить их в трехмерном кубе — так, как показано на рисунке 1 Г. В нем данные представлены в виде ячеек некоторого массива, где каждое значение дохода связано с размерностями Property Type, City и Time. Отметим, что таблица в реляционной СУБД может представлять многомерные данные только в двух измерениях.

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

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

средний_доход_на_сотрудника = общий_доход / количества_сотрудников.

Рисунок1. Представление многомерных данных: а) в виде таблицы с тремя поля­ми; б) двумерной матрицы; в) таблицы с четырьмя полями; г) трехмерного куба

Время обработки многомерного запроса зависит от того количества ячеек, которые должны быть обработаны мгновенно. С ростом числа размерностей количество ячеек в кубе данных возрастает экспоненциально. Однако для большинства многомерных за­просов требуются только обобщенные данные высокого уровни. Следовательно, для соз­дания эффективной многомерной базы данных необходимо предварительно рассчитать (консолидировать) все логические промежуточные и основные итоговые значения, при­чем по всем размерностям. Такое предварительное обобщение может оказаться особен­но ценным, если типичные размерности имеют иерархическую структуру. Например, размерность времени может иерархически подразделяться на годы, кварталы, месяцы, недели и дни, а размерность географического расположения — на отделения компании, районы, города и страны. Наличие предопределенной иерархии внутри размерностей позволяет выполнять предварительное логическое обобщение и, наоборот, нисходящий ("drill-down") логический анализ с переходом от значений годовых доходов к значени­ям квартальных доходов и дальше к значениям месячных доходов.

Серверы многомерных баз данных на основе OLАР могут выполнять перечислен­ные ниже основные аналитические операции.

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

• Нисходящий анализ ("drill-down"). Операция, обратная консолидации, ко­торая включает отображение подробных сведений для рассматриваемых консолидированных данных.

• Разбиение с поворотом (slicing and difing). Эти операция (которая также называется созданием сводной таблицы) позволяет получить представление данных с разных точек зрения. Например, один срез данных о доходах может отображать все сведения о доходах от продаж объектов недвижимо­сти укачанного типа по каждому городу. Другой срез может представлять все данные о доходах отделений компании в каждом из городов. Разбиение с поворотом часто выполняется вдоль оси времени -- с целью анализа тен­денций и поиска закономерно г те п.

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

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

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

1.2. Правила для OLAP-систем

В 1993 году Э.Ф. Кодд сформулировал двенадцать основных правил, которым должны удовлетворять ОLAP-инструменты. Публикация этих правил была результатом исследо­вания, проведенного в интересах фирмы Arbor Software (создателей пакета Essbase), и привела к появлению формального определения требований, предъявляемых к OLAP-

инструментами. Ниже перечислены упомянутые правила Кодда (Codd el ah, 1993),

1. Многомерное концептуальное представление данных.

2.Прозрачность. 3.Доступность

4.Неизменная производительность подготовки отчетов.

5.Архитектура ''клиент/сервер".

6.Универсальность измерений.

7. Динамическое управление разреженностью матриц.

8.Многопользовательская поддержка

9.Неограниченные перекрестные операции между размерностями. 10. Поддержка интуитивно понятного манипулирования данными.

11.Гибкость средств формирования отчетов.

12.Неограниченное число намерений и уровней обобщения.

Многомерное концептуальное представление данных

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

Прозрачность

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

Доступность

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

Неизменная производительность подготовки отчетов

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

Архитектура „клиент/сервер"

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

Универсальность измерений

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

Динамическое управление разреженностью матриц

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

Многопользовательская поддержка

ОLАР-система должна быть в состоянии поддерживать параллельную работу группы пользователей с одной или несколькими моделями корпоративных данных.

Неограниченные перекрестные операции между размерностями

ОLАР-система должна уметь распознавать иерархии размерностей и автоматиче­ски выполнять перекрестные обобщающие вычисления внутри и среди размерностей.

Поддержка интуитивно понятного манипулирования данными

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

Гибкость средств формирования отчетов

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

Неограниченное число измерений и уровней обобщения

В зависимости от конкретных бизнес-требований аналитическая модель может иметь самое разное количество размерностей, причем каждая из размерностей бу­дет обладать собственной иерархической структурой. ОLАР-система не должна накладывать никаких искусственных ограничений на количество измерений или уровней обобщения данных.

Со времени публикации Коддом приведенных выше правил для ОLАР-инструментов было предложено множество вариантов их переопределения или рас­ширения. Например, в некоторых публикациях указанных двенадцать правил предлагалось дополнить требованием того, что коммерческие ОLАР-инструменты должны включать комплексные инструменты управления базами данных, обладать способно­стью выполнять нисходящий анализ — до уровня самых детальных сведений (вплоть до записей в источниках данных), осуществлять пошаговое обновление базы данных, а также иметь SQL-интерфейс, что позволит им найти свое место в существующей корпоративной среде.