Оглавление

Оглавление
Глоссарий .............................................................................................................. 2
Введение ............................................................................................................... 3
Постановка задачи ............................................................................................... 6
1. OLAP – средство оперативного анализа данных............................................. 7
1.1 Введение в OLAP .......................................................................................... 7
1.2 Хранилища данных .................................................................................... 13
1.3 Многомерная модель данных .................................................................. 18
1.5 Технические аспекты многомерного хранения данных .......................... 24
Глоссарий
OLTP (Online Transaction —
Processing)
обработка транзакций в реальном времени.
Способ организации БД, при котором система
работает
с
небольшими
по
размерам
транзакциями, но идущими большим потоком, и
при
этом
клиенту
требуется
от
системы
максимально быстрое время ответа. OLTP-системы
оптимизированы
для
небольших
дискретных
транзакций.
Хранилище
(ХД)
(англ.
Warehouse)
данных — очень большая предметно-ориентированная
Data информационная корпоративная база данных,
специально разработанная и предназначенная для
подготовки отчётов, анализа бизнес-процессов с
целью
поддержки
принятия
решений
в
организации. Строится на базе клиент-серверной
архитектуры,
реляционной
поддержки
принятия
СУБД
решений.
и
утилит
Данные,
поступающие в хранилище данных, становятся
доступны только для чтения.
Введение
Современные
условия
ведения
бизнеса,
характеризующиеся
возрастающей жесткой конкуренцией и нестабильностью экономических
условий, предъявляют повышенные требования к оперативности и качеству
принимаемых решений на всех уровнях управления предприятием или
организацией. Поддержка принятия решений предполагает владение
актуальной всеобъемлющей информацией о состоянии и тенденциях
развития бизнеса методами и средствами Business Intelligence (BI). При этом
объем информации, которую необходимо учитывать для формирования
оптимальных обоснованных решений, неуклонно растет.
Это приводит к ситуации, когда становится невозможно эффективно
управлять
компанией
без
использования
современных
средств
информационного обеспечения, а именно, методов и средств бизнесаналитики. Бизнес-аналитика - это такие технологии, дающие возможность
организациям превращать накапливаемые данные в информацию о бизнесе,
а затем информацию - в знания для управления бизнесом, объединяются
под термином Business Intelligence или BI решения.
За последние 20 лет информационно-аналитические системы меняли
свои названия и содержание, пройдя путь от информационных систем
руководителя (executive information systems, EIS) до систем поддержки
принятия решений (decision support systems, DSS).
Во времена больших ЭВМ и миникомпьютеров, когда у большинства
пользователей не было прямого доступа к компьютерам, организации
зависели
от
своих
подразделений
ИТ,
которые
обеспечивали
их
стандартными и параметрическими отчетами. Но чтобы получить отчеты,
отличные от стандартных, пользователям нужно было заказывать их
разработку и ждать в течение нескольких дней или недель.
Приложения EIS были настроены на нужды руководителей и
менеджеров и давали возможность получать основную агрегированную
информацию о состоянии их бизнеса в виде таблиц или диаграмм. Обычно
они включали регламентные запросы с набором параметров. Такие пакеты
обычно разрабатывались силами своих подразделений ИТ. Для получения
дополнительной
информации
и
проведения
дальнейшего
анализа
применялись другие приложения или создавались по заказу запросы или
отчеты на языке SQL.
Приложения DSS первого поколения были пакетами прикладных
программ с динамической генерацией SQL-скриптов по типу запрашиваемой
пользователем
информации.
Они
позволяли
аналитикам
получать
информацию из реляционных БД, не требуя знания языка SQL. В отличие от
EIS приложения DSS могут отвечать на широкий спектр вопросов бизнеса,
имеют несколько вариантов представления отчетов и определенные
возможности форматирования. Однако гибкость таких пакетов все же была
ограничена из-за ориентации на конкретный набор задач.
С приходом ПК и локальных сетей следующее поколение приложений
DSS строится уже на основе BI и позволяет пользователю-непрограммисту
легко и оперативно извлекать информацию из различных источников,
формировать
собственные
настраиваемые
отчеты
или
графические
представления, проводить многомерный анализ данных. Развитие систем
бизнес-аналитики прошло путь от «толстых» клиентов до Web-приложений, в
которых пользователь ведет исследование с помощью браузера и может
работать удаленно.
Сам термин «Business Intelligence» и его идея были предложены в 1989
году Говардом Дреснером – сотрудником исследовательской группы
GartnerGroup. Он использовал термин BI для того, чтобы описать «процесс,
который включает доступ и исследование информации, ее анализ, выработку
интуиции и понимания, которые ведут к улучшенному и неформальному
принятию решений».
В основе технологий BI лежит организация доступа конечных
пользователей и анализ структурированных количественных по своей
природе данных и информации о бизнесе. BI порождает итерационный
процесс бизнес-пользователя, включающий доступ к данным и их анализ, и
тем самым проявление интуиции, формирование заключений, нахождение
взаимосвязей, чтобы эффективно изменять предприятие в положительную
сторону. BI имеет широкий спектр пользователей на предприятии, включая
руководителей и аналитиков.
Цель технологий BI - своевременно принимать решения, основываясь
на корректных данных. Сегодня создание и внедрение BI технологий
сформировалось
в
самостоятельное
динамично
развивающееся
направление индустрии информационных технологий (ИТ).
Из всех категорий BI-продуктов можно выделить следующие:
 Средства генерации отчётов и диаграмм (Reporting)
 Средства оперативной аналитической обработки данных (OLAP)
 Средства интеллектуального анализа данных (Data Mining)
 Средства переноса и интеграции данных (ETL)
Как
правило,
вышеперечисленные
средства
объединяются
в
корпоративные BI-наборы (enterprise BI suites, EBIS).
В
данной
ВКР
рассматриваются
технологии
оперативной
аналитической обработки данных (OLAP), а именно, исследуются подходы и
инструменты к построению хранилищ данных, многомерных кубов и
визуализации аналитической обработки данных.
На
основе
многомерного
результатов
анализа
управленческих
исследований
данных
решений
с
в
разрабатывается
системе
учётом
поддержки
модуль
принятия
финансово-экономических
и
производственно-технологических рисков предприятий. Данная система
позволяет оценивать риски выполнения предприятиями радиоэлектронной
промышленности государственных заказов и выдавать советы для принятия
управленческих решений.
ВКР разрабатывается в рамках НИР «Разработка методологии оценки
финансово-экономических
и
технологических
рисков
выполнения
предприятиями радиоэлектронной промышленности федеральных целевых
программ и государственных оборонных заказов».
Постановка задачи
Перед автором данной работы была поставлена цель: разработать
модуль многомерного оперативного анализа данных в системе поддержки
принятия решений. В качестве системы поддержки принятия решений было
предложено использовать систему поддержки принятия управленческих
решений
с
учётом
технологических
финансово-экономических
рисков
для
предприятий
и
производственнорадиоэлектронной
промышленности.
Для достижения этой цели перед автором были поставлены
следующие задачи:
1. Провести исследование современных возможностей OLAPсерверов.
2. Провести исследование подходов к построению хранилищ
данных.
3. Разработать хранилище данных и на его основе сформировать
необходимые для анализа многомерные кубы.
4. Разработать модуль многомерного анализа данных в системе
поддержки принятия решений.
1. OLAP – средство оперативного анализа данных
1.1 Введение в OLAP
Трудно найти в компьютерном мире человека, который хотя бы на
интуитивном уровне не понимал, что такое базы данных и зачем они нужны.
В отличие от традиционных реляционных СУБД, концепция OLAP не так
широко известна, хотя загадочный термин "кубы OLAP" слышали, наверное,
почти все. Что же такое Online Analytical Processing?
OLAP — это не отдельно взятый программный продукт, не язык
программирования и даже не конкретная технология. Если постараться
охватить OLAP во всех его проявлениях, то это совокупность концепций,
принципов и требований, лежащих в основе программных продуктов,
облегчающих аналитикам доступ к данным. Аналитики — это особые
потребители
корпоративной
информации,
задача
которых
находить
закономерности в больших массивах данных и делать выводы о текущем
состоянии бизнеса. Аналитик не будет обращать внимания на отдельно
взятый факт — ему нужна информация о сотнях и тысячах событий. Данные,
которые требуются аналитику для работы, обязательно содержат числовые
значения — это обусловлено самой сущностью его деятельности.
Централизация и удобное структурирование хранимых данных
предприятия — это далеко не все, что нужно аналитику. Ему также
потребуется
инструмент
для
просмотра
и
визуализации
хранимой
информации. Традиционные отчеты, даже построенные на основе единого
хранилища,
лишены
одного
—
гибкости.
Их
нельзя
«покрутить»,
«развернуть» или «свернуть», к ним нельзя применить фильтрацию, чтобы
получить желаемое представление данных. Конечно, можно вызвать
программиста, и он сделает новый отчет достаточно быстро - скажем, в
течение часа. Но в современных условиях ведения бизнеса этого
недостаточно. Оперативность в данном случае — один из факторов успеха.
Аналитику нужен такой инструмент, который позволил бы визуализировать
данные быстро, просто и удобно. В качестве такого инструмента и выступает
OLAP. TODO вставить картинку с отчётом
Термин OLAP (On-Line Analytical Processing) был предложен доктором
Е.Ф. Коддом, его супругой С.Б. Кодд и их коллегой С.Т. Солли в
исследовательской
статье
"OLAP
для
пользователей-аналитиков:
информационно-технологический мандат". Эта статья была опубликована в
начале 1993 года и спонсировалась корпорацией Arbor Software, создателем
и распространителем первого OLAP-продукта ESSBASE. Статья определяет
OLAP как «имя, данное динамическому анализу предприятия, необходимому
для создания, манипулирования, оживления и синтезирования информации
на базе "моделей информации о предприятии" ("Enterprise Data Models")».
В 1993 году Кодд сформулировал «12 принципов аналитической
обработки в реальном времени» (см. таблицу 1):
Таблица 1
№
Принцип
Описание
п/п
1
Многомерное
данных
представление Средства
должны
поддерживать
многомерный на концептуальном
уровне взгляд на данные.
2
Прозрачность
Пользователь не должен знать о
том, какие конкретные средства
используются
обработки
для
хранения
данных,
как
и
данные
организованы и откуда они берутся.
3
Доступность
Средства должны сами выбирать и
связываться
с
наилучшим
для
формирования ответа на данный
запрос
источником
Средства
должны
автоматическое
данных.
обеспечивать
отображение
их
собственной логической схемы в
различные гетерогенные источники
данных.
4
Согласованная
Производительность практически не
производительность
должна
зависеть
от
количества
Измерений в запросе.
5
Поддержка
архитектуры Средства
клиент-сервер
6
Равноправность
измерений
должны
работать
в
архитектуре клиент-сервер.
всех Ни одно из измерений не должно
быть базовым, все они должны быть
равноправными (симметричными).
7
Динамическая
разреженных матриц
обработка Неопределенные значения должны
храниться
и
обрабатываться
наиболее эффективным способом.
8
Поддержка
Средства
должны
обеспечивать
9
многопользовательского
возможность работать более чем
режима работы с данными
одному пользователю.
Поддержка операций на основе Все
различных измерений
многомерные
(например,
операции
агрегация)
единообразно
и
должны
согласованно
применяться к любому числу любых
измерений.
10
Простота
манипулирования Средства
данными
должны
иметь
максимально
естественный
удобный,
и
комфортный
пользовательский интерфейс.
11
Развитые
средства Средства
представления данных
должны
поддерживать
различные способы визуализации
(представления) данных.
12
Неограниченное
измерений
число Не должно быть ограничений на
и
уровней число поддерживаемых измерений.
агрегации данных
В 1995 году на основе принципов, изложенных Коддом, был
сформулирован так называемый тест FASMI (Fast Analysis of Shared
Multidimensional Information — быстрый анализ разделяемой многомерной
информации),
включающий
следующие
требования
к
приложениям
оперативного анализа данных:
 предоставление
пользователю
результатов
анализа
за
приемлемое время (обычно не более 5 с), пусть даже ценой
менее детального анализа;
 возможность
осуществления
любого
логического
и
статистического анализа, характерного для данного приложения,
и его сохранения в доступном для конечного пользователя виде;
 многопользовательский
соответствующих
доступ
к
механизмов
данным
с
блокировок
поддержкой
и
средств
авторизованного доступа;
 многомерное концептуальное представление данных, включая
полную поддержку для иерархий и множественных иерархий
(это — ключевое требование OLAP);
 возможность
обращаться
к
любой
нужной
информации
независимо от ее объема и места хранения.
Большинство из существующих OLAP-средств удовлетворяют всем этим
требованиям. Однако в реализации подобных приложений возникает ряд
проблем, прежде всего связанных с увеличением объёма данных, которые
необходимо хранить.
В настоящее время встречаются следующие применения OLAP:
 Анализ данных. Задача, для которой изначально использовались
и до сих пор остаются самыми популярными OLAP-средства.
Многомерная модель данных, возможность анализировать
значительные объёмы данных и быстрый отклик на запросы
делают подобные системы незаменимыми для анализа продаж,
маркетинговых мероприятий, дистрибуции и других задач с
большим объёмом исходных данных. Примеры продуктов:
Microsoft Excel Pivot Tables, Microsoft Analysis Services, SAP BW,
Oracle Essbase, Oracle OLAP, Cognos PowerPlay, MicroStrategy,
Business Objects.
 Финансовое
планирование\бюджетирование.
Многомерная
модель позволяет одновременно вводить данные и легко
анализировать их (например, план-факт анализ). Поэтому ряд
современных продуктов класса CPM (Corporate Performance
Management) используют OLAP-модели. Важная задача –
многомерный обратный расчёт (back-solve, breakback, writeback),
позволяющий рассчитать требуемые изменения детальных ячеек
при изменении агрегированного значения. Это инструмент для
анализа «что-если» (what-if), т.е. для проигрывания различных
вариантов событий при планировании. Примеры продуктов:
Microsoft PerformancePint, Oracle EPB, Oracle OFA, Oracle Hyperion
Planning, SAP SEM, Cognos Enterprise Planning, Geac.
 Финансовая консолидация. Консолидация данных согласно
международным стандартам учёта, принимая во внимание доли
владения, различные валюты и внутренние обороты – актуальная
задача в связи с ужесточающимися требованиями проверяющих
органов (SOX, Basel II) и выходом компаний на IPO (Initial Public
Offering — первая публичная продажа акций частной компании).
OLAP-технологии позволяют ускорить расчёт консолидированных
отчётов и повысить прозрачность всего процесса. Примеры
продуктов: Oracle FCH, Oracle Hyperion FM, Cognos Controller.
Таким
образом,
OLAP
–
актуальная
и
востребованная
тема
исследований, её практические результаты имеют широкое применение.
Несмотря на достаточно долгую историю исследований, до сих не существует
единых терминологических стандартов, стандартов передачи данных, языка
запросов и формирования кубов. Растущие объёмы корпоративных данных
повышают значимость средств анализа, большая часть которых построена на
OLAP-принципах, в связи с чем, актуальны проблемы выбора оптимальных
схем
хранения
требующие
и
обработки
совмещения
OLAP-кубов.
скорости
ввода
Задачи
бюджетирования,
транзакционных
систем
и
аналитических возможностей OLAP, представляют собой особый класс
систем, алгоритмическая база которых только создается.
1.2 Хранилища данных
Причина использования OLAP — это скорость. Реляционные БД хранят
сущности в отдельных таблицах, которые обычно хорошо нормализованы.
Эта структура удобна для операционных БД (системы OLTP), но сложные
многотабличные запросы в ней выполняются относительно медленно. Более
хорошей
моделью
для
запросов,
а
не
для
изменения,
является
пространственная (часто называемая многомерной) БД.
Представим себе ситуацию, что в какой-то момент времени с OLTPсистемой работают 1000 пользователей и один из них захотел построить
сводный отчёт за относительно большой временной период. Запрос на
построение такого рода отчётов, содержащий множество соединений
таблиц, выполняется долго и во время выполнения блокирует остальных
пользователей. Поэтому проектные решения современных информационноаналитических систем основываются не на одной базе данных, а на
нескольких: в одной из них хранятся неизменяемые данные - такая БД
называется хранилищем данных (ХД), а в остальных – данные, которые со
временем могут измениться (оперативные данные) (рис. 1). Неизменяемые
данные
обычно
используются
для
долговременного
хранения
статистической информации. Поэтому когда пользователь захочет построить
сводный отчёт за большой временной период, то данные для этого отчёта
будут приходить именно из хранилища данных и, соответственно,
выполняющийся запрос не будет блокировать остальных пользователей.
Рис.1 Источники информации для хранилищ данных
Данные в хранилище данных могут поступать не только из
операционных баз данных, но и из других источников, таких как XMLдокументы, Excel-таблицы и прочих текстовых документов. Данные
загружаются в хранилище с определённой периодичностью (например,
еженедельно, ежедневно или ежечасно — в зависимости от потребностей),
поэтому актуальность данных несколько отстает от OLTP-систем.
Таким образом, OLAP используется данные, находящиеся не в
операционных БД, а в хранилищах данных.
Задача хранилища - предоставить "сырье" для анализа в одном месте и
в простой, понятной структуре.
Автором концепции хранилищ данных является Б. Инмон, который
определил
хранилища
данных
как:
"предметно-ориентированные,
интегрированные, неизменчивые, поддерживающие хронологию наборы
данных, организованные для целей поддержки управления", призванные
выступать
в
роли
"единого
и
единственного
источника
истины",
обеспечивающего менеджеров и аналитиков достоверной информацией,
необходимой для оперативного анализа и принятия решений.
В основе концепции хранилищ данных лежат две основополагающие
идеи:
 Интеграция ранее разъединенных детализированных данных в
едином хранилище данных, их согласование и, возможно,
агрегация:
o исторических архивов;
o данных из традиционных систем обработки данных;
o данных из внешних источников.
 Разделение наборов данных, используемых для операционной
обработки, и наборов данных, применяемых для решения задач
анализа.
Цель концепции хранилищ данных - выяснить требования к данным,
помещаемым в целевую БД хранилища данных (см. таблицу 2), определить
общие принципы и этапы ее построения, основные источники данных, дать
рекомендации по решению потенциальных проблем, возникающих при их
выгрузке, очистке, согласовании, транспортировке и загрузке в целевую БД.
Таблица 2. Основные требования к данным в хранилище данных.
Требование
Комментарий
Предметная
Все данные о некотором предмете (бизнес-
ориентированность
объекте) собираются (обычно из множества
различных
источников),
очищаются,
согласовываются, дополняются, агрегируются и
представляются в единой, удобной для их
использования в бизнес-анализе форме.
Интегрированность
Все данные о разных бизнес-объектах взаимно
согласованы
и
хранятся
в
едином
общекорпоративном хранилище.
Неизменчивость
Исходные (исторические) данные, после того как
они были согласованы, верифицированы и
внесены
в
остаются
общекорпоративное
неизменными
и
хранилище,
используются
исключительно в режиме чтения.
Поддержка хронологии
Данные
хронологически
отражают
выполнения
историю,
задач
за
структурированы
и
достаточный
для
бизнес-анализа
и
прогнозирования период времени.
Без поддержки хронологии (наличия исторических данных) нельзя
говорить о решении задач прогнозирования и анализа тенденций. Но
наиболее критичными и болезненными оказываются вопросы, связанные с
согласованием данных.
Основным требованием аналитика является даже не столько
оперативность, сколько достоверность ответа. Но достоверность, в конечном
счете, определяется согласованностью данных. Пока не проведена работа по
взаимному согласованию значений данных из различных источников,
сложно говорить об их достоверности.
Хранилища данных бывают двух типов: корпоративные хранилища
данных (enterprise data warehouses) и витрины данных (data marts). Первые
содержат информацию, относящуюся ко всей корпорации и собранную из
множества оперативных источников для консолидированного анализа.
Обычно такие хранилища охватывают целый ряд аспектов деятельности
корпорации и используются для принятия тактических и стратегических
решений. Корпоративное хранилище содержит как детальную, так и
суммарную информацию и в объеме может достигать от (условно) 50 Гб до
одного или нескольких терабайт.
Стоимость создания и поддержки корпоративных хранилищ может
быть очень высокой. Обычно их созданием занимаются централизованные
отделы информационных технологий, причем создаются они сверху вниз,
т.е. сначала проектируется общая схема и лишь затем заполняется данными.
Построение такого хранилища может длиться несколько лет.
Витрины данных содержат подмножества корпоративных данных и
строятся для отделов или подразделений внутри организации. Витрины
часто строятся силами самого отдела и охватывают конкретный аспект,
интересующий сотрудников данного отдела. Витрина может получать
данные из корпоративного хранилища (зависимая витрина данных,
dependent data mart) или, что вероятнее, данные могут поступать прямо из
оперативных источников (независимая витрина данных, independent data
mart).
Витрины и хранилища данных строятся по сходным принципам и
используют
практически
одинаковые
технологии.
Структуры
данных
хранилища заметно отличаются от применяемых в OLTP-системах. Это в
первую очередь определяется предметной ориентированностью хранилища:
данные организованы вокруг того или иного аспекта деятельности
предприятия. В следующей главе речь пойдёт о многомерной модели
данных, на которой основаны хранилища данных.
1.3 Многомерная модель данных
Многомерная модель данных — это расширение реляционной модели.
В отличие от реляционной модели, где основным понятием является
«отношение», в многомерной модели основным понятием является «куб»,
который является обобщением реляционных таблиц на любое число
измерений. Набор соответствующих кубов составляет многомерную базу
данных.
Некоторые преимущества многомерной модели по сравнению с
реляционной:
 Возможность анализа больших объемов данных с приемлемой
скоростью;
 Возможность осуществления любых «срезов» и «углублений» в
определённой структуре БД;
 Быстрая локализация трендов и проблемных областей.
Куб представлен набором мер и измерений, а именно, куб — это
декартово
произведение
измерений,
где
для
каждого
элемента
произведения проставлен набор мер.
Измерения куба – набор доменов, по которым создаётся многомерное
пространство. Другими словами, измерение – это упорядоченный набор
значений, соответствующий грани куба. Многомерное моделирование
предусматривает
использование
измерений
для
предоставления
максимальной информативности. В отличие от реляционных баз данных,
контролируемая избыточность в многомерных базах данных, в общем,
считается оправданной, если она увеличивает информационную ценность.
Измерения используются для выбора и агрегирования данных на
требуемом уровне детализации. Измерения организуются в иерархию,
состоящую из нескольких уровней, каждый из которых представляет уровень
детализации, требуемый для соответствующего анализа.
Иногда
бывает
полезно
определять
несколько
иерархий
для
измерения. Например, модель может определять время, как в финансовых
годах, так и в календарных. Несколько иерархий совместно используют один
или несколько общих, самых низких уровней, например, день и месяц, и
модель группирует их в несколько более высоких уровней — финансовый
квартал
и
календарный
квартал.
Чтобы
избежать
дублирования
определений, метаданные многомерной базы данных определяют иерархию
измерений.
В отличие от линейных пространств, с которыми имеет дело алгебра
матриц, многомерные модели, как правило, не предусматривают функций
упорядочивания или расстояния для значений измерения. Единственное
«упорядочивание» состоит в том, что значения более высокого уровня
содержат значения более низких уровней. Однако для некоторых
измерений, таких как время, упорядоченность значений размерности может
использоваться для вычисления совокупной информации, такой как общий
объем продаж за определенный период.
В примере, изображенном на рис.?, 3 измерения – «Доставка»,
«Отправка» и «Время».
Рис.? Пример многомерного куба
Мера – это
значение,
которое
однозначно
определяется
фиксированным набором измерений.
Многомерная база данных естественным образом предназначена для
определенных типов запросов:
 Запросы вида slice-and-dice осуществляют выбор, сокращающий куб. К
примеру, можно рассмотреть сечение куба на рис. 1, приняв во
внимание только те ячейки, которые касаются хлеба, а затем еще
больше сократить его, оставив ячейки, относящиеся только к 2000 году.
Фиксация значения измерения сокращает размерность куба, но при
этом возможны и более общие операции выбора.
 Запросы вида drill-down и roll-up — взаимообратные операции,
которые
используют
иерархию
измерений
и
параметры
для
агрегирования. Обобщение до высших значений соответствует
исключению размерности. Например, свертка от уровня «Город» до
уровня «Страна» на рис. 2 агрегирует значения для Аалборга и
Копенгагена в одно значение — Дания.
 Запросы вида drill-across комбинируют кубы, которые имеют одно или
несколько общих измерений. С точки зрения реляционной алгебры
такая операция выполняет слияние (join).
 Запросы вида ranking [6] возвращает только те ячейки, которые
появляются
в
верхней
или
нижней
части
упорядоченного
определенным образом списка, например, 10 самых продаваемых
продуктов в Копенгагене в 2000 году.
 Поворот (rotating) куба дает пользователям возможность увидеть
данные, сгруппированные по другим измерениям.
Основным достоинством многомерной модели данных является удобство и
эффективность
аналитической
обработки
больших
объемов
данных,
связанных со временем. При организации обработки аналогичных данных на
основе реляционной модели происходит нелинейный рост трудоемкости
операций в зависимости от размерности БД и существенное увеличение
затрат оперативной памяти на индексацию.
Недостатком многомерной модели данных является ее громоздкость для
простейших задач обычной оперативной обработки информации.
Реализация
Многомерная структура хранения данных может быть реализована с
помощью многомерных БД или в системе управления реляционными БД с
использованием схемы звезды или схемы снежинки.
Схема звезды является практически реляционным воплощением
многомерного представления данных. Такая модель наиболее адекватна
представлениям о предметной области, которыми оперирует пользователь
системы многомерного анализа данных — аналитик или управленец.
Пространственная модель описывает данные о предметной области как nмерный
куб
или
n-мерную
таблицу.
В
ячейках
куба
находятся
количественные показатели (меры). Каждая ячейка описывается рядом
атрибутов, образующих оси координат (измерения).
Схема звезды является проекцией куба на «реляционную плоскость».
(Рис 5.1.) Она состоит из одной таблицы фактов (fact table) и нескольких
таблиц измерений (dimension table). Таблица фактов содержит по одной
строке для каждого факта — минимально рассматриваемого атома
анализируемого процесса. Обычно говорят о четырех наиболее часто
встречающихся типах фактов. К ним относятся:
 факты, связанные с транзакциями (англ. Transaction facts). Они
основаны на отдельных событиях (типичными примерами
которых являются телефонный звонок или снятие денег со счета с
помощью банкомата);
 факты, связанные с «моментальными снимками» (англ. Snapshot
facts). Основаны на состоянии объекта (например, банковского
счета) в определенные моменты времени, например на конец
дня или месяца. Типичными примерами таких фактов являются
объем продаж за день или дневная выручка;
 факты, связанные с элементами документа (англ. Line-item facts).
Основаны на том или ином документе (например, счете за товар
или услуги) и содержат подробную информацию об элементах
этого документа (например, количестве, цене, проценте скидки);
 факты, связанные с событиями или состоянием объекта (англ.
Event or state facts). Представляют возникновение события без
подробностей о нем (например, просто факт продажи или факт
отсутствия таковой без иных подробностей).
Для издательского процесса фактами могут быть факт продажи
издания или факт подписки на издание.
Полями таблицы фактов, помимо ключей, являются меры (measures),
описывающие количественную характеристику факта, например, цена
издания или длительность подписки на издание.
Таблицы измерений содержат собственно значения измерений, то есть
информацию, характеризующую факты. Обычно это неизменяемые, либо
редко изменяемые данные. Каждая таблица измерений должна находиться
в отношении «один ко многим» с таблицей фактов. Типичными измерениями
издательского процесса будут «Подписчики», «Издания», «Время». Время
является несколько особенным и практически необходимым измерением
любого хранилища данных.
Схема звезды не соответствует требованиям нормальной формы. С
точки зрения нормализации таблицы измерений хранят избыточные данные.
Но избыточность оправдывается двумя соображениями. Во-первых, такая
схема понятнее конечному пользователю. Во-вторых, запросы по БД будут
выполняться быстрее за счет уменьшения количества таблиц, объединяемых
в одном запросе.
Схема снежинки является модификацией схемы звезды, как бы
уступкой нормализации — здесь часть таблиц измерений разбита на
несколько связанных таблиц. В случае если в нескольких измерениях
повторяются одни и те же данные (например, адрес может встречаться и в
измерении «Подписчики» и «Распространители») необходимо выделить
общее географическое измерение, содержащее атрибуты «географических
точек».
Благодаря
частичной
нормализации,
«снежинка»
позволяет
сэкономить дисковое пространство, но она также дает еще одно
преимущество — увеличивается скорость просмотра измерений.
TODO Иерархии
1.5 Технические аспекты многомерного хранения данных
Часто в многомерных хранилищах данных содержатся и агрегатные
данные различной степени подробности, например, объемы продаж по
дням, месяцам, годам, по категориям товаров и т.п. Цель хранения
агрегатных данных — сократить время выполнения запросов, поскольку в
большинстве случаев для анализа и прогнозов интересны не детальные, а
суммарные данные. Поэтому, обычно, при загрузке данных в многомерную
БД вычисляются и сохраняются некоторые агрегатные данные.
Отметим, что сохранение всех агрегатных данных не всегда оправданно.
Дело в том, что при добавлении новых измерений объем данных,
составляющих куб, растет экспоненциально (иногда говорят о «взрывном
росте» объема данных). Если говорить более точно, степень роста объема
агрегатных данных зависит от количества измерений куба и членов
измерений на различных уровнях иерархий этих измерений. Для решения
проблемы
«взрывного
роста»
применяются
разнообразные
схемы,
позволяющие при вычислении далеко не всех возможных агрегатных данных
достичь приемлемой скорости выполнения запросов.
Как исходные, так и агрегатные данные могут храниться либо в
реляционных, либо в многомерных структурах. Поэтому в настоящее время
применяются три способа хранения данных:
 MOLAP (Multidimensional OLAP) — исходные и агрегатные данные
хранятся в многомерной базе данных. Хранение данных в
многомерных структурах позволяет манипулировать данными как
многомерным массивом, благодаря чему скорость вычисления
агрегатных значений одинакова для любого из измерений. Однако в
этом случае многомерная база данных оказывается избыточной, так
как
многомерные
данные
полностью
содержат
исходные
реляционные данные.
 ROLAP (Relational OLAP) — исходные данные остаются в той же
реляционной базе данных, где они изначально и находились.
Агрегатные же данные помещают в специально созданные для их
хранения служебные таблицы в той же базе данных.
 HOLAP (Hybrid OLAP) — исходные данные остаются в той же
реляционной базе данных, где они изначально находились, а
агрегатные данные хранятся в многомерной базе данных.
Некоторые OLAP-средства поддерживают хранение данных только в
реляционных структурах, некоторые — только в многомерных. Однако
большинство современных серверных OLAP-средств поддерживают все три
способа хранения данных. Выбор способа хранения зависит от объема и
структуры исходных данных, требований к скорости выполнения запросов и
частоты обновления OLAP-кубов.
Отметим также, что подавляющее большинство современных OLAPсредств не хранит «пустых» значений (примером «пустого» значения может
быть отсутствие продаж сезонного товара вне сезона).