Лекции - хранение многомерных данных

Структуры хранения данных.
5.1 OLTP и OLAP системы
Для адекватного представления предметной области, простоты разработки и
поддержания базы данных отношения должны быть приведены к третьей
нормальной форме (существуют формы нормализации и более высоких порядков,
но на практике они используются достаточно редко), то есть быть сильно
нормализованными. Однако слабо нормализованные отношения также имеют
свои достоинства, основным из которых является то, что если к базе данных
обращаться в основном только с запросами, а модификации и добавление данных
проводить очень редко, то их выборка производится значительно быстрее. Это
объясняется тем, что в слабо нормализованных отношениях уже как бы
произведено их соединение и на это не тратится процессорное время. Выделяют
два класса систем, для которых в большей степени подходят сильно и слабо
нормализованные отношения.
5.1.1 Определение и основные понятия OLТP - систем
Сильно нормализованные модели данных хорошо подходят для OLTPприложений – On-Line Transaction Processing (OLTP) – приложений оперативной
обработки транзакций. Типичными примерами OLTP-приложений являются
системы складского учета, заказов билетов, операционные банковские системы и
другие. Основная функция подобных систем заключается в выполнении большого
количества коротких транзакций. Сами транзакции являются достаточно
простыми, но проблемы состоят в том, что таких транзакций очень много,
выполняются они одновременно и при возникновении ошибок транзакция должна
откатиться и вернуть систему в состояние, в котором та была до начала
транзакции. Практически все запросы к базе данных в OLTP-приложениях
состоят из команд вставки, обновления и удаления. Запросы на выборку, в
основном, предназначены для предоставления пользователям выборки данных из
различного рода справочников. Таким образом, большая часть запросов известна
заранее ещё на этапе проектирования системы. Критическим для OLTPприложений является скорость и надежность выполнения коротких операций
обновления данных. Чем выше уровень нормализации данных в OLTPприложениях, тем оно быстрее и надежней. Отступления от этого правила могут
происходить тогда, когда уже на этапе разработки известны некоторые часто
возникающие запросы, требующие соединения отношений и от скорости
выполнения которых существенно зависит работа приложений.
5.1.2 Определение и основные понятия OLAP - систем
OLAP - это On-Line Analitical Processing (оперативный анализ данных).
OLAP-приложения – приложения оперативной аналитической обработки данных.
Это обобщенный термин, характеризующий принципы построения систем
поддержки принятия решений – Decision Support System (DSS), хранилищ данных
– Data Warehouse, систем интеллектуального анализа данных – Data Mining. Такие
системы предназначены для нахождения зависимостей между данными, для
проведения динамического анализа по принципу «что если…» и тому подобных
задач. OLAP-приложения оперируют с большими массивами данных,
накопленными на предприятии или взятыми из других источников. Такие системы
характеризуются следующими признаками:
- добавление в систему новых данных происходит относительно редко
крупными блоками, например, один раз в месяц или квартал;
- данные, добавленные в систему, как правило, никогда не удаляются;
- перед загрузкой данные проходят различные подготовительные
процедуры, связанные с приведением их к определенным форматам и тому
подобное;
- запросы к системе являются нерегламентированными и достаточно
сложными;
- скорость выполнения запросов важна, но не критична.
В 1993 г. Е. Ф. Кодд ("изобретатель" реляционных БД) сформулировал 12
определяющих принципов OLAP. Позже его определение было переработано в так
называемый тест FASMI, требующий, чтобы OLAP-приложение предоставляло
возможности быстрого анализа разделяемой многомерной информации.
В Тесте FASMI определены следующие составляющие:
Fast (Быстрый) - анализ должен производиться одинаково быстро по всем
аспектам информации. Приемлемое время отклика - 5 с или менее.
Analysis (Анализ) - должна быть возможность осуществлять основные типы
числового и статистического анализа, предопределенного разработчиком
приложения или произвольно определяемого пользователем.
Shared (Разделяемой) - множество пользователей должно иметь доступ к
данным, при этом необходимо контролировать доступ к конфиденциальной
информации.
Multidimensional (Многомерной) - это основная, наиболее существенная
характеристика OLAP.
Information (Информации) - приложение должно иметь возможность
обращаться к любой нужной информации, независимо от ее объема и места
хранения.
5.1.1 Характеристики OLAP:
Основные характеристики OLAP включают:
2
1. Многомерность модели данных. является основной характеристикой
OLAP. Частью этого требования считается возможность построения различных
проекций и разрезов модели.
2. Интуитивные механизмы манипулирования данными. Кодд считает, что
манипулирование данными должно производится с помощью действий
непосредственно в ячейке таблиц, без применения меню или сложных. Можно
предположить, что это подразумевает использование операций с мышью, но Кодд
этого не утверждает. Многие продукты не выполняют этого правила. С нашей
точки зрения, эта характеристика незначительно влияет на качество процесса
анализа данных. Мы считаем, что программа должна предлагать возможность
выбора модели работы, т.к. не всем пользователям нравится одно и то же.
3. Доступность. OLAP это Посредник. Кодд особенно подчеркивает, что
ядро OLAP является программой промежуточного уровня между гетерогенными
источниками данных и пользовательским интерфейсом. Большинство продуктов
обеспечивают эти функции, но удобство доступа к данным часто оказывается
ниже чем это хотелось бы другим поставщикам программ.
4. Пакетное извлечение данных. Это правило требует, чтобы продукты
предлагали как собственные базы для хранения анализируемых данных, так и
динамический (live) доступ к внешним данным. Мы согласны с Коддом в этом
пункте и сожалеем, что лишь немногие OLAP продукты соответствуют ему. Даже
те программы, которые предлагают такие функции, редко делают их легкими и
достаточно автоматизированными. В результате, Кодд поддерживает
многомерное представление данных плюс частичный предварительный обсчет
больших многомерных баз данных с прозрачным сквозным доступом к детальной
информации. Сегодня это рассматривается как определение гибридного OLAP,
которая становится наиболее популярной архитектурой, так что Кодд очень точно
увидел основные тенденции в этой области.
5. Архитектура "клиент-сервер". Кодд считает, что не только каждый
продукт должен быть клиент-серверным, но и что каждая серверная компонента
OLAP продуктов должна быть достаточно интеллектуальной для того, чтобы
разные клиенты могли быть подключены с минимальными усилиями и
программированием. Это намного более сложный тест, чем простая клиентсерверная архитектура и относительно мало продуктов проходит его. Мы могли
бы возразить, что этот тест, возможно, сложнее, чем надо и не стоит диктовать
разработчикам архитектуру системы.
6. Прозрачность. Этот тест также сложен, но необходим. Полное
соответствие означает, что пользователь, скажем, электронной таблицы может
получить полный доступ к средствам, предоставляемым ядром OLAP и может при
этом даже не знать о том, откуда получены эти данные. Для того чтобы достичь
этого, продукты должны предоставлять динамический доступ к гетерогенным
источникам данных и полнофункциональный модуль, встраиваемый в
электронную таблицу. Между электронной таблицей и хранилищем данных при
этом размещается OLAP сервер.
3
7. Многопользовательская работа. Кодд определяет, что для того, чтобы
считаться стратегическим OLAP инструментом, приложения должны работать не
только на чтение и интерпретацию данных, и, соответственно, они должны
обеспечивать одновременный доступ (включая и извлечение, и обновление
данных), целостность и безопасность.
Специальные характеристики:
8. Обработка ненормализованных данных. Это означает возможность
интеграции между ядром OLAP и ненормализованным источником данных. Кодд
выделяет то, что при обновлении данных, выполненном в среде OLAP, должна
быть возможность изменять ненормализованные данные во внешних системах.
9. Хранение OLAP результатов отдельно от исходных данных. В
действительности, это имеет отношение к реализации продукта, а не к его
возможностям, но мало кто будет спорить с этим утверждением. По сути, Кобб
поддерживает широко принятую систему, в соответствии с которой OLAP
приложения должны строить анализ непосредственно на основе данных
транзакции и изменения в данных OLAP должны храниться отдельно от данных
транзакции.
10. Выделение отсутствующих данных. Это означает, что отсутствующие
данные должны отличаться от нулевого значения. Как правило, все современные
OLAP системы поддерживают эту характеристику.
11. Обработка отсутствующих значений. Все отсутствующие значения
должны быть проигнорированы при анализе, вне зависимости от их источника.
Характеристики построения отчетов:
12. Гибкое построение отчетов. Различные измерения должны
выстраиваться любым способом в соответствии с потребностями пользователя.
Большинство продуктов соответствует этому требованию в рамках специальных
редакторов отчетов. Хотелось бы, чтобы такие же возможности были доступны и
в интерактивных средствах просмотра, но это встречается значительно реже. Это одна из причин, по которой мы предпочитаем, чтобы функционал анализа и
построения отчетов был объединен в одном модуле.
13. Стабильная производительность при построении отчетов. Это
означает, что производительность системы при построении отчетов не должна
существенно падать при увеличении размерности или величины базы данных.
14. Автоматическое регулирование физического уровня. OLAP система
должна автоматически регулировать физическую структуру для адаптации ее к
типу и структуре модели.
Управление размерностью
15. Общая функциональность. Все измерения должны иметь одинаковые
возможности в структуре и функциональности.
4
16. Неограниченное число измерений и уровней агрегирования. Фактически,
под неограниченным числом Кодд подразумевает 15-20, т.е. число, заведомо
превышающее максимальные потребности аналитика.
17. Неограниченные операции между данными различных измерений. Кодд
полагает, что для того, чтобы приложение называлось многомерным, оно должно
поддерживать любые вычисления с использованием данных всех измерений.
5.2 Хранилища данных
Термин "OLAP" неразрывно связан с термином "хранилище данных" (Data
Warehouse). Приведем определение, сформулированное "отцом-основателем"
хранилищ данных Биллом Инмоном:
"Хранилище данных - это предметно-ориентированное, привязанное ко
времени и неизменяемое собрание данных для поддержки процесса принятия
управляющих решений".
Чтобы обеспечить анализ накопленной информации, организации создают
хранилища данных - интегрированные коллекции сведений из различных
оперативных систем. Эти хранилища - основа построения систем принятия
решений. Хранилищам данных свойственны следующие черты.
Предметная ориентированность. Информация в хранилище организована
в соответствии с основными аспектами деятельности предприятия (заказчики,
продажи, склад и т. п.); это отличает хранилище данных от оперативной БД, где
данные организованы в соответствии с процессами (выписка счетов, отгрузка
товара и т. п.). Предметная организация данных способствует как упрощению
анализа, так и повышению скорости выполнения аналитических запросов.
Интегрированность. Обычно оперативные БД хранят неинтегрированные
данные. Семантически одни и те же данные в разных базах могут быть выражены
в разных единицах измерения. Кроме того, данные могут быть закодированы поразному (например, логическое значение «Истина» может храниться как 1, -1, .Т,
или как-то еще). Такие данные практически непригодны для анализа конечным
пользователем. При загрузке в хранилище данные должны быть проверены,
очищены и приведены к единому виду. Анализировать такие интегрированные
данные намного проще.
Привязка ко времени. Данные, выбранные их оперативных БД,
накапливаются в хранилище в виде «исторических слоев», каждый из которых
относится к конкретному периоду времени. Это позволяет анализировать
тенденции в развитии бизнеса. С технической точки зрения привязка ко времени
означает, что таблицы в явном виде имеют в своем составе «временной ключ»
либо данные распределены по нескольким таблицам, каждая из которых
относится к определенному времен ному периоду (году, кварталу и т. п.).
Неизменяемость. Попав в хранилище, данные «залегают» в свой
«исторический слой» и уже никогда не меняются. Это еще одно отличие
хранилища от оперативной БД, в которой данные постоянно меняются, «дышат»,
5
и один и тот же запрос, выполненный дважды с интервалом в 10 минут, может
дать разные результаты. Стабильность данных облегчает их анализ.
Эти свойства сформулировал «отец-основатель» хранилищ данных Билл
Инмон (Bill Inmon) в книге «Building the Data Warehouse» в 1992 году.
Зачем строить хранилища данных - ведь они содержат заведомо
избыточную информацию, которая и так "живет" в базах или файлах оперативных
систем? Ответить можно кратко: анализировать данные оперативных систем
напрямую невозможно или очень затруднительно. Это объясняется различными
причинами, в том числе разрозненностью данных, хранением их в форматах
различных СУБД и в разных "уголках" корпоративной сети. Но даже если на
предприятии все данные хранятся на центральном сервере БД (что бывает крайне
редко), аналитик почти наверняка не разберется в их сложных, подчас запутанных
структурах. Автор имеет достаточно печальный опыт попыток "накормить"
голодных аналитиков "сырыми" данными из оперативных систем - им это
оказалось "не по зубам".
Таким образом, задача хранилища - предоставить "сырье" для анализа в
одном месте и в простой, понятной структуре. Ральф Кимбалл в предисловии к
своей книге "The Data Warehouse Toolkit" пишет, что если по прочтении всей
книги читатель поймет только одну вещь, а именно: структура хранилища должна
быть простой, - автор будет считать свою задачу выполненной.
Есть и еще одна причина, оправдывающая появление отдельного хранилища
- сложные аналитические запросы к оперативной информации тормозят текущую
работу компании, надолго блокируя таблицы и захватывая ресурсы сервера.
На мой взгляд, под хранилищем можно понимать не обязательно гигантское
скопление данных - главное, чтобы оно было удобно для анализа. Вообще говоря,
для маленьких хранилищ предназначается отдельный термин - Data Marts (киоски
данных), но в нашей российской практике его не часто услышишь.
Основные компоненты
- Основные компоненты хранилища данных таковы (рис. 9-4):
- оперативные источники данных;
- средства переноса и трансформации данных;
- метаданные;
- реляционное хранилище;
- OLAP-хранилище;
- средства доступа и анализа данных.
6
Рис. 9-4. Структура хранилища данных.
Рассмотрим основные потоки данных в хранилище. Оперативные данные
собираются из различных источников, очищаются, интегрируются и
складываются в реляционное хранилище. При этом они уже доступны для
анализа при помощи средств построения отчетов. Затем данные (полностью
или частично) подготавливаются для OLAP-анализа. При этом они могут быть
загружены в специальную БД OLAP или оставаться в реляционном хранилище.
Важнейшим элементом хранилища являются метаданные, т. е. данные о
структуре, размещении, трансформации данных. Чтобы эффективно
взаимодействовать, различные компоненты хранилища должны уметь
использовать общие метаданные.
Microsoft Data Warehousing Framework
Процессы создания, поддержки и использования хранилищ данных
всегда требовали больших затрат, что в первую очередь было вызвано высокой
стоимостью доступных на рынке специализированных инструментов. Эти
инструменты практически не интегрировались между собой, так как были
основаны не на открытых и стандартных, а на частных и закрытых протоколах,
интерфейсах и т. д. Сложность и дороговизна делали практически
невозможным построение хранилищ данных в небольших и средних фирмах.
Microsoft давно осознала необходимость создания инструментальной и
технологической среды, позволяющей минимизировать затраты на создание
хранилищ данных, что сделало бы этот процесс доступным для массового
пользователя. Это привело к появлению Microsoft Data Warehousing Framework
(рис. 9-5) - спецификации среды создания и использования хранилищ данных.
Эта спецификация определяет развитие не только новой линии продуктов
Microsoft (например, SQL Server 7.0), но и технологий, обеспечивающих
интеграцию продуктов различных производителей. Открытость среды Microsoft
Data Warehousing Framework обеспечила ее поддержку многими
производителями ПО, благодаря чему конечные пользователи могут выбирать
инструменты для построения своих решений.
7
Цель Microsoft Data Warehousing Framework — упростить разработку,
внедрение и управление решений на основе хранилищ данных.
Microsoft Data Warehousing Framework предусматривает наличие всех
компонентов, необходимых для построения и использования хранилищ данных.
Как открытая структура Microsoft Data Warehousing Framework, так и политика
Microsoft направлены на открытую интеграцию с независимыми
разработчиками ПО. При этом большая часть компонентов уже поставляется
самой фирмой Microsoft.
OLE DB — стандарт обмена данными
Построение хранилищ данных требует, с одной стороны, взаимодействия
с оперативными БД для извлечения данных, а с другой - обмена данными и
метаданными между компонентами. При отсутствии единого интерфейса для
доступа к разнородным данным обе задачи решать крайне сложно. Но такой
интерфейс есть - это OLE DB. OLE DB целиком основан на открытой модели
COM (Component Object Model) и представляет собой набор интерфейсов,
которые могут быть использованы, например в приложениях на Visual C++.
Для упрощения применения OLE DB создан набор ActiveX-компонентов ActiveX Data Objects (ADO), которые могут вызываться из приложений на
Visual Basic, Access, Excel, встраиваться В активные WEB-страницы и т. п.
Практически все компоненты, которые мы будем обсуждать ниже,
используют OLE DB для доступа к данным. OLE DB обеспечивает доступ не
только к реляционным данным, но и к таким ресурсам, как почтовые
сообщения, файловые каталоги, полнотекстовые индексы и т. п. Одним из
расширений OLE DB является OLE DB for OLAP - спецификация интерфейсов
для работы с многомерными данными.
Метаданные
Одна из наиболее важных задач при построении хранилища данных интеграция различных компонентов и инструментов, используемых для
проектирования, хранения данных, переноса и трансформации, а также анализа
данных. Ключевым моментом при такой интеграции является возможность
использования разделяемых метаданных (т. е. данных о данных).
Центральный компонент Data Warehousing Framework - хранилище
метаданных Microsoft Repository - поставляется в составе Microsoft SQL Server
7.0. Microsoft Repository - это база данных, которая хранит описательную
информацию о компонентах программного обеспечения и об их отношениях.
Microsoft Repository состоит из набора открытых информационных моделей
(Open Information Model, OIM) и набора опубликованных СОМ-интерфейсов.
Открытые информационные модели - это объектные модели определенного
типа информации, при этом они достаточно гибки, чтобы обеспечить
поддержку новых типов информации. Microsoft, опираясь на сотрудничество с
представителями отрасли, уже разработала модели (OIMs) для схемы баз
данных (Database Schema), преобразования данных (Data Transformations) и
OLAP. Последующие модели будут поддерживать репликацию, планирование
8
задач, семантические модели и информационный справочник, обеспечивающий
метаданными конечного пользователя.
Коалиция метаданных (The Metadata Coalition), отраслевой консорциум
53 производителей, заявил о поддержке Microsoft Repository. Открытые
информационные модели получили широкую поддержку у независимых
разработчиков ПО.
Кто хранит данные
Важнейшим компонентом хранилища данных является, безусловно,
СУБД, обеспечивающая надежное и производительное хранение и обработку
данных. Как правило, данные из оперативных БД перемешаются в реляционное
хранилище, где они уже доступны для анализа. В дальнейшем, при
использовании OLAP-средств, они могут быть перемещены в многомерную
СУБД, либо будут выбираться процессором многомерных запросов прямо из
реляционных таблиц. И реляционный, и многомерный вид хранения
обеспечивает Microsoft SQL Server 7.0.
5.3 Многомерное представление данных: куб
OLAP предоставляет удобные быстродействующие средства доступа,
просмотра и анализа деловой информации. Пользователь получает естественную,
интуитивно понятную модель данных, организуя их в виде многомерных кубов
(Cubes). Осями многомерной системы координат служат основные атрибуты
анализируемого бизнес-процесса. Например, для продаж это могут быть товар,
регион, тип покупателя. В качестве одного из измерений используется время. На
пересечениях осей - измерений (Dimensions) - находятся данные, количественно
характеризующие процесс - меры (Measures). Это могут быть объемы продаж в
штуках или в денежном выражении, остатки на складе, издержки и т. п.
Пользователь, анализирующий информацию, может "разрезать" куб по разным
направлениям, получать сводные (например, по годам) или, наоборот, детальные (по
неделям) сведения и осуществлять прочие манипуляции, которые ему придут в
голову в процессе анализа.
5.4 Структуры данных в хранилище
Структуры данных хранилища заметно отличаются от применяемых в
OLTP-системах. Это в первую очередь определяется предметной
ориентированностью хранилища: данные организованы вокруг того или иного
аспекта деятельности предприятия. Типичными структурами, применяемыми в
хранилищах данных, являются схемы звезды (Star schema) и снежинки (Snowflake
schema). Эти схемы для хранилищ данных являются такими же каноническими,
как 3-я нормальная форма для OLTP-систем.
2.4.1 Схема звезды
Забегая вперед, замечу, что схема звезды практически является
реляционным воплощением многомерного представления данных - основы OLAP.
Но даже в тех реализациях систем поддержки принятия решений, которые не
9
используют OLAP, многомерная (пространственная, dimensional) модель данных,
как правило, применяется. Дело в том, что такая модель наиболее адекватна
представлениям о предметной области, которыми оперирует пользователь DSSсистемы - аналитик или управленец. Пространственная модель описывает данные
о предметной области как n-мерный метакуб или n-мерную таблицу. В ячейках
метакуба находятся количественные показатели (меры). Каждая ячейка
описывается рядом атрибутов, образующих оси координат (измерения). Для
рассматриваемого выше (рис. 9-1) процесса продаж в качестве мер выступают
такие показатели, как Сумма продажи (Store Sales), Количество единиц (Units
Sold), а в качестве измерений — Покупатели, Товары, Регионы.
Схема звезды является проекцией метакуба на «реляционную плоскость».
Схема звезды довольно проста (рис. 9-2). Она состоит из одной таблицы фактов
(fact table) и нескольких таблиц измерений (dimension table). Таблица фактов
содержит по одной строке для каждого факта - минимально рассматриваемого
атома анализируемого процесса. Полями таблицы фактов, помимо ключей,
являются меры (measures). Для нашего процесса продаж фактами могут быть
продажи отдельных товаров (партий товаров, вагонов и т. п. - детальность
таблицы фактов выбирается в зависимости от разных факторов).
Таблицы измерений содержат собственно значения измерений, т.е.
информацию, характеризующую факты. Типичными измерениями процесса
продаж будут Покупатели, Товары, Регионы. Несколько особенным и
практически необходимым измерением любого хранилища данных является
Время (Time).
Ниже (рис. 9-2) представлена схема звезды для процесса продаж,
полученная из схемы нашей оперативной БД (рис. 9-1).
Рис. 9-2. Схема звезды.
Схема звезды не соответствует (да и не должна) требованиям нормальной
формы. С точки зрения нормализации таблицы измерений хранят избыточные
данные. Например, поля «store_state» и «store_country» таблицы «store» (магазин)
10
явно будут содержать повторяющиеся значения для всех магазинов в городах
штата Вашингтон. Но избыточность оправдывается двумя соображениями. Вопервых, такая схема понятнее конечному пользователю. Во-вторых, запросы по
БД будут выполняться быстрее за счет уменьшения количества таблиц,
объединяемых в одном запросе.
2.4.1 Схема снежинки
объединяемых Схема снежинки является модификацией схемы звезды, как
бы уступкой нормализации - здесь часть таблиц измерений разбита несколько
связанных таблиц. Ниже (рис. 9-3) приведена схема снежинки, взятая из базы
FoodMart, поставляемой в качестве примера с OLAP Services. Можно сказать, что
она получена из нашей схемы (рис. 9-2) путем выделения в отдельные таблицы
Класса Продукта (таблица product_class) и Региона (таблица region).
Рис. 9-3. Схема снежинки
Благодаря частичной нормализации, «снежинка» позволяет сэкономить
дисковое пространство, но она также дает еще одно преимущество увеличивается скорость просмотра измерений. Предположим, пользователь хочет
отфильтровать данные по категории продукта. Чтобы получить список категорий
продуктов, в схеме звезды (рис. 9-2) нужно выполнить запрос типа SELECT
DISTINCT product_category FROM product. Очевидно, что если продуктов много
(например, десятки тысяч наименований), такой запрос будет выполняться
намного дольше, чем такой же запрос по таблице product_class (содержащей сотни
строк) в схеме снежинки (рис. 9-3). Построение схемы снежинки особенно
оправданно, когда два или более измерений как бы включают в себя одно и то же
измерение. Например, измерения Покупатель (таблица customer) и Магазин
11
(таблица store) оба должны содержать адрес, - чтобы обеспечить анализ с точки
зрения географии. В этом случае имеет смысл выделить общее географическое
измерение, содержащее атрибуты «географических точек». Измерения
Покупатель и Магазин будут ссылаться на географическую точку, что не только
сэкономит дисковое пространство, но и избавит нас от поддержки избыточных
данных.
5.5 “Разрезание” многомерного куба
В качестве мер в трехмерном кубе, изображенном на рис. 2, использованы
суммы продаж, а в качестве измерений - время, товар и магазин. Измерения
представлены на определенных уровнях группировки: товары группируются по
категориям, магазины - по странам, а данные о времени совершения операций - по
месяцам. Чуть позже мы рассмотрим уровни группировки (иерархии) подробнее.
Рис. 2. Пример куба
Даже трехмерный куб сложно отобразить на экране компьютера так, чтобы
были видны значения интересующих мер. Что уж говорить о кубах с количеством
измерений, большим трех? Для визуализации данных, хранящихся в кубе,
применяются, как правило, привычные двумерные, т. е. табличные, представления,
имеющие сложные иерархические заголовки строк и столбцов.
Двумерное представление куба можно получить, "разрезав" его поперек одной
или нескольких осей (измерений): мы фиксируем значения всех измерений, кроме
двух, - и получаем обычную двумерную таблицу. В горизонтальной оси таблицы
(заголовки столбцов) представлено одно измерение, в вертикальной (заголовки
строк) - другое, а в ячейках таблицы - значения мер. При этом набор мер фактически
рассматривается как одно из измерений - мы либо выбираем для показа одну меру (и
тогда можем разместить в заголовках строк и столбцов два измерения), либо
показываем несколько мер (и тогда одну из осей таблицы займут названия мер, а
другую - значения единственного "неразрезанного" измерения).
Взгляните на рис. 3 - здесь изображен двумерный срез куба для одной меры Unit Sales (продано штук) и двух "неразрезанных" измерений - Store (Магазин) и
Время (Time).
12
Рис. 3. Двумерный срез куба для одной меры
На рис. 4 представлено лишь одно "неразрезанное" измерение - Store, но зато
здесь отображаются значения нескольких мер - Unit Sales (продано штук), Store Sales
(сумма продажи) и Store Cost (расходы магазина).
Рис. 4. Двумерный срез куба для нескольких мер
Двумерное представление куба возможно и тогда, когда "неразрезанными"
остаются и более двух измерений. При этом на осях среза (строках и столбцах) будут
размещены два или более измерений "разрезаемого" куба - см. рис. 5.
Рис. 5. Двумерный срез куба с несколькими измерениями на одной оси
Метки
Значения, "откладываемые" вдоль измерений, называются членами или
метками (members). Метки используются как для "разрезания" куба, так и для
ограничения (фильтрации) выбираемых данных - когда в измерении, остающемся
"неразрезанным", нас интересуют не все значения, а их подмножество, например три
города из нескольких десятков. Значения меток отображаются в двумерном
представлении куба как заголовки строк и столбцов.
13
Иерархии и уровни
Метки могут объединяться в иерархии, состоящие из одного или нескольких
уровней (levels). Например, метки измерения "Магазин" (Store) естественно
объединяются в иерархию с уровнями:
All (Мир)
Country (Страна)
State (Штат)
City (Город)
Store (Магазин).
В соответствии с уровнями иерархии вычисляются агрегатные значения,
например объем продаж для USA (уровень "Country") или для штата California
(уровень "State"). В одном измерении можно реализовать более одной иерархии скажем, для времени: {Год, Квартал, Месяц, День} и {Год, Неделя, День}.
5.6 Корпоративная фабрика информации
Архитектура OLAP-приложений
Все, что говорилось выше про OLAP, по сути, относилось к многомерному
представлению данных. То, как данные хранятся, грубо говоря, не волнует ни
конечного пользователя, ни разработчиков инструмента, которым клиент пользуется.
Многомерность в OLAP-приложениях может быть разделена на три уровня:
Многомерное представление данных - средства конечного пользователя,
обеспечивающие многомерную визуализацию и манипулирование данными; слой
многомерного представления абстрагирован от физической структуры данных и
воспринимает данные как многомерные.

Многомерная обработка - средство (язык) формулирования многомерных
запросов (традиционный реляционный язык SQL здесь оказывается непригодным) и
процессор, умеющий обработать и выполнить такой запрос.

Многомерное хранение - средства физической организации данных,
обеспечивающие эффективное выполнение многомерных запросов.

Первые два уровня в обязательном порядке присутствуют во всех OLAPсредствах. Третий уровень, хотя и является широко распространенным, не
обязателен, так как данные для многомерного представления могут извлекаться и из
обычных реляционных структур; процессор многомерных запросов в этом случае
14
транслирует многомерные запросы в SQL-запросы, которые выполняются
реляционной СУБД.
Конкретные OLAP-продукты, как правило, представляют собой либо средство
многомерного представления данных, OLAP-клиент (например, Pivot Tables в Excel
2000 фирмы Microsoft или ProClarity фирмы Knosys), либо многомерную серверную
СУБД, OLAP-сервер (например, Oracle Express Server или Microsoft OLAP Services).
Слой многомерной обработки обычно бывает встроен в OLAP-клиент и/или в
OLAP-сервер, но может быть выделен в чистом виде, как, например, компонент Pivot
Table Service фирмы Microsoft.
5.7 Технические аспекты многомерного хранения данных
Как уже говорилось выше, средства OLAP-анализа могут извлекать данные и
непосредственно из реляционных систем. Такой подход был более привлекательным
в те времена, когда OLAP-серверы отсутствовали в прайс-листах ведущих
производителей СУБД. Но сегодня и Oracle, и Informix, и Microsoft предлагают
полноценные OLAP-серверы, и даже те IT-менеджеры, которые не любят разводить
в своих сетях "зоопарк" из ПО разных производителей, могут купить (точнее,
обратиться с соответствующей просьбой к руководству компании) OLAP-сервер той
же марки, что и основной сервер баз данных.
OLAP-серверы, или серверы многомерных БД, могут хранить свои
многомерные данные по-разному. Прежде чем рассмотреть эти способы, нам нужно
поговорить о таком важном аспекте, как хранение агрегатов. Дело в том, что в
любом хранилище данных - и в обычном, и в многомерном - наряду с детальными
данными, извлекаемыми из оперативных систем, хранятся и суммарные показатели
(агрегированные показатели, агрегаты), такие, как суммы объемов продаж по
месяцам, по категориям товаров и т. п. Агрегаты хранятся в явном виде с
единственной целью - ускорить выполнение запросов. Ведь, с одной стороны, в
хранилище накапливается, как правило, очень большой объем данных, а с другой аналитиков в большинстве случаев интересуют не детальные, а обобщенные
показатели. И если каждый раз для вычисления суммы продаж за год пришлось бы
суммировать миллионы индивидуальных продаж, скорость, скорее всего, была бы
неприемлемой. Поэтому при загрузке данных в многомерную БД вычисляются и
сохраняются все суммарные показатели или их часть.
Но за скорость обработки запросов к суммарным данным приходится платить
увеличением объемов данных и времени на их загрузку. Причем увеличение объема
может стать буквально катастрофическим – объем данных может вырастать и в
сотни раз! Степень "разбухания" данных при вычислении агрегатов зависит от
количества измерений куба и структуры этих измерений, т. е. соотношения
количества "отцов" и "детей" на разных уровнях измерения. Для решения проблемы
хранения агрегатов применяются подчас сложные схемы, позволяющие при
15
вычислении далеко не всех возможных агрегатов достигать значительного
повышения производительности выполнения запросов.
Теперь о различных вариантах хранения информации. Как детальные данные,
так и агрегаты могут храниться либо в реляционных, либо в многомерных
структурах. Многомерное хранение позволяет обращаться с данными как с
многомерным массивом, благодаря чему обеспечиваются одинаково быстрые
вычисления суммарных показателей и различные многомерные преобразования по
любому из измерений. Некоторое время назад OLAP-продукты поддерживали либо
реляционное, либо многомерное хранение. Сегодня, как правило, один и тот же
продукт обеспечивает оба этих вида хранения, а также третий вид - смешанный.
Применяются следующие термины:
MOLAP (Multidimensional OLAP) - и детальные данные, и агрегаты
хранятся в многомерной БД. В этом случае получается наибольшая избыточность,
так как многомерные данные полностью содержат реляционные.

ROLAP (Relational OLAP) - детальные данные остаются там, где они
"жили" изначально - в реляционной БД; агрегаты хранятся в той же БД в специально
созданных служебных таблицах.

HOLAP (Hybrid OLAP) - детальные данные остаются на месте (в
реляционной БД), а агрегаты хранятся в многомерной БД.

Каждый из этих способов имеет свои преимущества и недостатки и должен
применяться в зависимости от условий - объема данных, мощности реляционной
СУБД и т. д.
При хранении данных в многомерных структурах возникает потенциальная
проблема "разбухания" за счет хранения пустых значений. Ведь если в многомерном
массиве зарезервировано место под все возможные комбинации меток измерений, а
реально заполнена лишь малая часть (например, ряд продуктов продается только в
небольшом числе регионов), то бо/льшая часть куба будет пустовать, хотя место
будет занято. Современные OLAP-продукты умеют справляться с этой проблемой.
16