43526

Многомерная модель базы данных и ее реализация на основе Microsoft SQL Server

Курсовая

Информатика, кибернетика и программирование

Поэтому не удивительно то внимание которое сегодня уделяется средствам реализации и концепциям построения информационных систем ориентированных на аналитическую обработку данных. И в первую очередь это касается систем управления базами данных основанными на многомерном подходе МСУБД. Требования к средствам реализации систем оперативной и аналитической обработки данных.

Русский

2013-11-05

479.5 KB

27 чел.

Факультет: АВТ

Кафедра: ЭВА

Пояснительная записка к курсовому проекту
по дисциплине
«Базы Данных» на тему

«Многомерная модель базы данных и ее реализация  на основе Microsoft SQL Server»

Выполнил:

Д. А. Болдырев

Группа:

С-55

Руководитель:.

д.т.н. профессор

Д. И. Зарудный

Отметка о зачете:


Аннотация

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


Оглавление

[1]
Аннотация

[2]
Оглавление

[3]
Глава 1. Требования к средствам реализации систем оперативной и аналитической обработки данных.

[3.1] Агрегированные данные.

[3.2] Исторические данные.

[3.3] Прогнозируемые данные

[4]
Глава 2. Многомерная модель данных

[4.1] Многомерная модель данных

[4.1.1] Двухмерное представление данных конечному пользователю

[4.1.2] Многомерное представление при описании структур данных

[4.2] Гиперкубические и поликубические модели данных

[4.3] Операции манипулирования Измерениями

[4.4] Формирование "Среза"

[4.4.1] Операция "Вращение"

[4.4.2] Отношения и Иерархические Отношения

[4.4.3] Операция Агрегации

[4.4.3.1] Операция Детализации

[5] Глава 3. Проектирование многомерной БД

[5.1] Определение требований

[5.2] Анализ вопросов

[5.3] Определение структуры многомерной БД

[6] Глава 4. Реализация многомерной БД в MS SQL Server

[6.1] Архитектура SQL Server OLAP Services

[6.2] Создание базы данных

[6.3] Создание источника данных

[6.4] Создание кубов

[7] Заключение


Техническое задание

Требуется описать принципы организации и вопросы проектирования аналитических систем на основе многомерных систем управления базами данных. Практическая часть должна быть выполнена с помощью пакета Microsoft SQL Server в среде Microsoft Windows 2000 на примере БД состояния подписки издательского предприятия.
Введение

Следует заметить, что МСУБД не являются изобретением девяностых годов, а сам многомерный подход возник практически одновременно и параллельно с реляционным. Еще в начале семидесятых годов консалтинговой фирмой Management Decision System (позже преобразованной в IRI Software) были реализованы первые версии многомерных инструментальных средств. Позднее эти средства стали известны как IRI Multidimensional DBMS, IRI Express Server и с 1995 г. - Oracle Express Server. И хотя к 1995 г. у фирмы IRI Software было уже более тысячи корпоративных пользователей, и она имела более двадцати представительств в Европе, Азии и Латинской Америке, все же МСУБД долгое время оставались в тени своего "старшего" собрата РСУБД. И только начиная с середины девяностых годов, а точнее с 1993 г., интерес к МСУБД начал приобретать всеобщий характер.

Именно в этом году появилась новая программная статья одного из основоположников реляционного подхода Э. Кодда [1], в которой он сформулировал 12 основных требований к средствам реализации OLAP ( Online Analytical Processing: оперативный анализ данных, онлайновая аналитическая обработка данных, тоесть оперативный анализ данных для поддержки принятия важных решений) (табл. 1). Кодд произвел анализ некоторых как субъективных, так и вполне объективных недостатков реляционного подхода, затрудняющих его использование в задачах, требующих сложной аналитической обработки данных.

1

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

Средства должны поддерживать многомерный на концептуальном уровне взгляд на данные.

2

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

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

3

Доступность

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

4

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

Производительность практически не должна зависеть от количества Измерений в запросе.

5

Поддержка архитектуры клиент-сервер

Средства должны работать в архитектуре клиент-сервер.

6

Равноправность всех измерений

Ни одно из измерений не должно быть базовым, все они должны быть равноправными (симметричными).

7

Динамическая обработка разреженных матриц

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

8

Поддержка многопользовательского режима работы с данными

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

9

Поддержка операций на основе различных измерений

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

10

Простота манипулирования данными

Средства должны иметь максимально удобный, естественный и комфортный пользовательский интерфейс.

11

Развитые средства представления данных

Средства должны поддерживать различные способы визуализации (представления) данных.

12

Неограниченное число измерений и уровней агрегации данных

Не должно быть ограничений на число поддерживаемых Измерений.


Таблица 1. 12 правил оценки средств для OLAP.

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

· собственно требования, например п.п. 1, 2, 3, 6;

· не формализуемые пожелания, например п.п. 10, 11;

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

11 требованиям из 12, но реализованная на основе Unix-станции с терминалами, не является OLAP - п.п. 5. Тем более, что уже есть п. 2 (Прозрачность) и п. 3 (Доступность).

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


Глава 1. Требования к средствам реализации систем оперативной и аналитической обработки данных.

При первом знакомстве с многомерным подходом к организации данных достаточно часто возникают два противоречивых вопроса.

Для чего собственно нужны МСУБД и нужно ли тратить время и средства на их освоение и приобретение, если все те же задачи можно решить и средствами традиционных РСУБД?

И обратный:

Почему МСУБД ограничивают себя исключительно приложениями, ориентированными на анализ данных и почему бы на их основе не реализовывать традиционные системы оперативной обработки данных?

И несмотря на то, что эти вопросы выражают достаточно противоположные точки зрения, ответ на них звучит приблизительно одинаково: "Главное достоинство МСУБД состоит именно в том, что они узко специализированны и область их применения - интерактивная аналитическая обработка агрегированных исторических и прогнозируемых данных".

Агрегированные данные. 

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

Исторические данные. 

Важнейшим свойством данных в аналитических задачах является их Исторический характер. После того как зафиксировано, что Петров в июне 2005 г. продал 2 автомобиля "Волга" и 12 автомобилей "Жигули", данные об этом событии становятся историческим (свершившимся) фактом. И после того, как информация об этом факте получена, верифицирована и заведена в БД, она может быть сколько угодно раз считана оттуда, но уже не может и не должна быть изменена. Историчность данных предполагает не только высокий уровень статичности (неизменности) как собственно данных (например: Петров продал в 2004 г. 51 автомобиль "Жигули ВАЗ2105"), так и их взаимосвязей (например: в 2004 г. Петров работал в Восточном Регионе; в 2004 г. продавались автомобили модели ВАЗ2105). А это, в свою очередь, дает возможность использовать специализированные, основанные на предположении о статичности данных и их взаимосвязей методы загрузки, хранения, индексации и выборки.

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

· для уменьшения времени обработки запросов желательно, чтобы уже в БД данные хранились (были предварительно отсортированы) в том порядке, в котором они наиболее часто запрашиваются;

так и на языки описания и манипулирования данными, например:

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

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

Прогнозируемые данные

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

Например, если мы строим прогноз об объеме продаж на июнь 2006 г. для менеджера Петрова, то, по мере поступления фактических (Исторических) данных за 2005 г., эта цифра может и будет многократно изменяться и уточняться. Более того, достаточно часто прогнозирование и моделирование затрагивает не только будущие, еще не произошедшие, но и прошлые, уже свершившиеся события. Например, анализ: "а, что будет (было бы)... если (бы)..?", строится на предположении о том, что значения некоторых данных, в том числе и из прошлого, отличны от реальных. И для ответа на вопрос:

"Какой был бы Прогноз по объему продаж автомобилей "Волга" для менеджера Петрова на июнь 2006 г., если бы объем продаж "Волг" в июне 2005 г. у него возрос на тот же процент, что объем продаж "Жигулей"?"

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

На первый взгляд, мы сами противоречим себе, говоря о неизменности данных, как основополагающем свойстве аналитической системы. Но это не так. Это кажущееся противоречие наоборот подчеркивает и усиливает значимость требований к неизменности Исторических данных. Сколько бы мы не упражнялись (например, при анализе: "а что... если..?") со значением объема продаж за июнь 2005 г., значения Исторических (реальных) данных должны оставаться неизменными. Конечно, предположение о неизменности не означает невозможности исправления ошибок, если они были обнаружены в Исторических данных.

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

· менеджер Петров продал еще одни "Жигули ВАЗ2106";

· менеджера Петрова перевели из Восточного филиала фирмы в Западный.

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

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

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

· системы, ориентированные на оперативную (транзакционную или операционную) обработку данных;

· системы, ориентированные на анализ данных - системы поддержки принятия решений.

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

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

Характеристика

Статический анализ

Динамический анализ

Типы вопросов

Сколько? Как? Когда?

Почему? Что будет если?

Время отклика

Не регламентируется

Секунды

Типичные операции

Регламентированный отчет, диаграмма

Последовательность интерактивных отчетов, диаграмм, экранных форм; динамическое изменение уровней агрегации и срезов данных

Уровень аналитических требований

Средний

Высокий

Тип экранных форм

В основном определенный заранее, регламентированный

Определяемый пользователем

Уровень агрегации данных

Детализированные и суммарные

В основном суммарные

Возраст данных

Исторические и текущие

Исторические, текущие и прогнозируемые

Типы запросов

В основном предсказуемые

Непредсказуемые, от случаю к случаю

Назначение

Работа с историческими и текущими данными, регламентированная аналитическая обработка и построение прогнозов

Работа с историческими, текущими и прогнозируемыми данными. Многопроходный анализ, моделирование


Таблица 2. Сравнение характеристик статического (регламентированного) и динамического анализа.

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

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

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

Характеристика

Оперативные

Аналитические

Частота обновления

Высокая частота, маленькими порциями

Малая частота, большими порциями

Источники данных

В основном внутренние

В основном внешние (по отношению к аналитической системе)

Возраст данных

Текущие (за период от нескольких месяцев до одного года)

В основном исторические (за период в несколько лет, десятки лет) и прогнозируемые

Уровень агрегации данных

Детализированные данные

В основном агрегированные данные

Назначение

Фиксация, оперативный поиск и обработка данных

Работа с историческими данными, аналитическая обработка, прогнозирование и моделирование


Таблица 3. Характеристики данных в системах, ориентированных на оперативную и аналитическую обработку данных.

 


Глава 2. Многомерная модель данных

Многомерная модель данных

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

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

Двухмерное представление данных конечному пользователю

Достаточно очевидно, что даже при небольших объемах данных отчет, представленный в виде двухмерной таблицы (Модели автомобиля по оси Y и Время по оси X), нагляднее и информативнее отчета с реляционной построчной формой организации (рис. 1).

Реляционная модель

Модель
"Жигули"
"Жигули"
"Жигули"
"Москвич"
"Москвич"
"Волга"

Месяц
Июнь
Июль
Август
Июнь
Июль
Июль

Объем
12
24
5
2
18
19

Многомерная модель


"Жигули"
"Москвич"
"Волга"

Июнь
12
2
No

Июль
24
18
19

Август
5
No
No

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

А теперь представим, что у нас не три модели, а 30 и не три, а 12 различных месяцев. В случае построчного (реляционного) представления мы получим отчет в 360 строк (30х12), который займет не менее 5-6 страниц. В случае же многомерного (в нашем случае двухмерного) представления мы получим достаточно компактную таблицу 12 на 30, которая вполне уместится на одной странице и которую, даже при таком объеме данных, можно реально оценивать и анализировать.

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

Закономерен вопрос: "Где же здесь многомерность, откуда она берется и куда исчезает?" Ответ прост. Когда говорится о многомерности, имеется в виду не многомерность визуализации, а многомерное представление при описании структур данных и поддержка многомерности в языках манипулирования данными.

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

Основными понятиями, с которыми оперирует пользователь и проектировщик в многомерной модели данных, являются:

· измерение (Dimension);

· ячейка (Cell).

Иногда вместо термина "Ячейка" используется термин "Показатель" (Measure).

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

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

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

· Переменная (Variable) - значения таких Показателей один раз вводятся из какого-либо внешнего источника или формируются программно и затем в явном виде хранятся в многомерной базе данных (МБД);

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

Заметим, что это различие существует только на этапе проектирования и полностью скрыто от конечных пользователей.

В примере на рис. 1 каждое значение поля Объем продаж однозначно определяется комбинацией полей:

· Модель автомобиля;

· Месяц продаж.

Но в реальной ситуации для однозначной идентификации значения Показателя, скорее всего, потребуется большее число измерений, например:

· Модель автомобиля;

· Менеджер;

· Время (например Год).

Измерения:

Время (Год) - 2003, 2004, 2005

Менеджер - Петров, Смирнов, Яковлев

Показатель:

Объем Продаж


Рисунок 2. Измерения и Показатели (Ячейки).

И в терминах многомерной модели речь будет идти уже не о двухмерной таблице, а о трехмерном гиперкубе:

· первое Измерение - Модель автомобиля;

· второе Измерение - Менеджер, продавший автомобиль;

· третье Измерение - Время (Год);

на пересечении граней которого находятся значения Показателя Объем продаж.

Заметим, что, в отличие от Измерений, не все значения Показателей (рис. 3) должны иметь и имеют реальные значения. Например, Менеджер Петров в 2003 г. мог еще не работать в фирме, и в этом случае все значения Показателя Объем продаж за этот год будут иметь неопределенные значения.

Рисунок 3. Неопределенные значения показателей.

Гиперкубические и поликубические модели данных

В различных МСУБД используются два основных варианта организации данных:

· Гиперкубическая модель;

· Поликубическая модель.

В чем состоит разница? Системы, поддерживающие Поликубическую модель, предполагают, что в МБД может быть определено несколько гиперкубов с различной размерностью и с различными Измерениями в качестве их граней. Например, значение Показателя Рабочее Время Менеджера, скорее всего, не зависит от Измерения Модель Автомобиля и однозначно определяется двумя Измерениями: День и Менеджер. В Поликубической модели в этом случае может быть объявлено два различных гиперкуба:

Двухмерный - для Показателя Рабочее Время Менеджера;

Трехмерный - для Показателя Объем Продаж.

В случае же Гиперкубической модели предполагается, что все Показатели должны определяться одним и тем же набором Измерений. То есть только из-за того, что Объем Продаж определяется тремя Измерениями, при описании Показателя Рабочее Время Менеджера придется также использовать три Измерения и вводить избыточное для этого Показателя Измерение Модель Автомобиля.

Операции манипулирования Измерениями

Формирование "Среза" 

Пользователя редко интересуют все потенциально возможные комбинации значений Измерений. Более того, он практически никогда не работает одновременно сразу со всем гиперкубом данных. Подмножество гиперкуба, получившееся в результате фиксации значения одного или более Измерений, называется Срезом (Slice). Например, если мы ограничим значение Измерения Модель Автомобиля = "ВАЗ2108", то получим подмножество гиперкуба (в нашем случае - двухмерную таблицу), содержащее информацию об истории продаж этой модели различными менеджерами в различные годы.

Операция "Вращение"

Изменение порядка представления (визуализации) Измерений (обычно применяется при двухмерном представлении данных) называется Вращением (Rotate). Эта операция обеспечивает возможность визуализации данных в форме, наиболее комфортной для их восприятия. Например, если менеджер первоначально вывел отчет, в котором Модели автомобилей были перечислены по оси X, а Менеджеры по оси Y, он может решить, что такое представление мало наглядно, и поменять местами координаты (выполнить Вращение на 90 градусов).

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

Отношения и Иерархические Отношения

В нашем примере значения Показателей определяются только тремя измерениями. На самом деле их может быть гораздо больше и между их значениями обычно существуют множество различных Отношений (Relation) типа "один ко многим".

Например, каждый Менеджер может работать только в одном подразделении, а каждой модели автомобиля однозначно соответствует фирма, которая ее выпускает:

Менеджер ->Подразделение;

Модель Автомобиля ->Фирма-Производитель.

Заметим, что для Измерений, имеющих тип Время (таких как День, Месяц, Квартал, Год), все Отношения устанавливаются автоматически, и их не требуется описывать.

В свою очередь, множество Отношений может иметь иерархическую структуру - Иерархические Отношения (Hierarchical Relationships). Вот только несколько примеров таких Иерархических Отношений:

День -> Месяц -> Квартал -> Год;

Менеджер -> Подразделение -> Регион -> Фирма -> Страна;

Модель Автомобиля -> Завод-Производитель -> Страна.

И часто более удобно не объявлять новые Измерения и затем устанавливать между ними множество Отношений, а использовать механизм Иерархических Отношений. В этом случае все потенциально возможные значения из различных Измерений объединяются в одно множество. Например, мы можем добавить к множеству значений Измерения Менеджер ("Петров", "Сидоров", "Иванов", "Смирнов"), значения Измерения Подразделение ("Филиал 1", "Филиал 2", "Филиал 3") и Измерения Регион ("Восток", "Запад") и затем определить между этими значениями Отношение Иерархии. Например:

"Восток"
"Запад"
"Филиал 1"
"Филиал 2"
"Филиал 3"
"Петров"
"Сидоров"
"Иванов"
"Смирнов"

"NA"
"NA"
"Восток"
"Восток"
"Запад"
"Филиал 1"
"Филиал 1"
"Филиал 2"
"Филиал 3"

Операция Агрегации

С точки зрения пользователя, Подразделение, Регион, Фирма, Страна являются точно такими же Измерениями, как и Менеджер. Но каждое из них соответствует новому, более высокому уровню агрегации значений Показателя Объем продаж. В процессе анализа пользователь не только работает с различными Срезами данных и выполняет их Вращение, но и переходит от детализированных данных к агрегированным, т.е. производит операцию Агрегации (Drill Up). Например, посмотрев, насколько успешно в 2004 г. Петров продавал модели "Жигули" и "Волга", управляющий может захотеть узнать, как выглядит соотношение продаж этих моделей на уровне Подразделения, где Петров работает. А затем получить аналогичную справку по Региону или Фирме.

Операция Детализации

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

Глава 3. Проектирование многомерной БД

Определение требований 

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

Пример:

1.      На сколько процентов изменилось количество подписчиков на журнал Итоги по всем регионам на протяжении последних 6 месяцев?

2.      В каких регионах наибольшее увеличение числа подписчиков?

3.      В каких регионах уменьшилось число подписчиков?

4.      Какой из выпускаемых журналов принес больше прибыли за последний квартал?

5.      Какая средняя длительность подписки на журналы за прошлый год?

Анализ вопросов 

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

Пример:

1.      Количество подписчиков

2.      Общая сумма подписки

Определение структуры многомерной БД 

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

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

Показателем, представленным последовательным рядом значений (continuously valued), может быть любая из набора величин; обычно она часто изменяется. Показатели, представленные последовательно выбранными значениями, полезны, поскольку всегда содержат новую информацию. 

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

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

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

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

Пример:

Показатели многомерной БД для анализа состояния подписки издательского предприятия:

·        Количество подписчиков

·        Общая сумма подписки

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

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

Пример:

2. Измерения многомерной БД для анализа состояния подписки издательского предприятия:

·        Время

·        Подписчики

·        Продукты

3. Следующий шаг - определение структурной единицы (зерна). Зерно (grain) - нижний уровень детализации данных, хранящихся в киоске.

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

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

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

Таблица 1. Иерархия измерений многомерной БД для анализа состояния подписки издательского предприятия.

Время

Продукты

Подписчики

Год

Тип

Название

Квартал

Название

 

Месяц

Номер журнала

 

Неделя

 

 

В измерении Время я выбрал 4 уровня иерархии: Год, Квартал, Месяц, Неделя. Это обусловлено тем, что издательство выпускает еженедельные, ежемесячные и ежеквартальные издания и необходимо отслеживать изменения информации в данных временных отрезках. В измерении Продукты я выбрал 3 уровня иерархии чтобы можно было отбирать данные по Типу издания (бумажное, электронное), по Названию и по Номеру журнала. В измерении Подписчики я выбрал один уровень иерархии, т.к. в качестве подписчиков в данном случае выступают областные отделения РосПочты, и в каждой области находится только одно областное отделение.

Таблица 2. Общая структура измерений.

Время

Продукты

Подписчики

Неделя

Название

Название

Месяц

Тип

Почтовый индекс

Квартал

Частота выхода

Город

Год

Цена в месяц

Улица

Номер

Номер

Подписная стоимость

Телефон

Вес

Факс

Количество страниц

Код МТС

Объем

Адрес электронной почты

Для загрузки данных в хранилище данных, необходимо организовать реляционную базу данных в виде схемы звезда или снежинка. Как было сказано выше, схема снежинки позволяет уменьшить требования к объему данных, так как повторяющиеся данные выносятся в отдельную таблицу. Поэтому я выбрал именно схему снежинки. Реляционную базу данных я создал в MS Access 2003, так как это более удобное, по сравнению с MS SQL Server, средство для создания и заполнения данными таблиц небольшой реляционной базы данных. Повторяющиеся данные выделены мной в отдельную таблицу Prod_class, в которой хранятся данные о подписных изданиях: название, тип, частота выхода, цена подписки. Измерения Время, Подписчики и Продукты строятся на основании таблиц Time, subscribers, products. Структура этих таблиц представлена в Таблице 3.

Таблица 3. Структура таблиц промежуточной БД

Time

subscribers

products

Week

Name

Number

Month

Post_index

Weight

Quartal

City

Page_amount

Year

Street

Volume

 

Number

 

 

Tel

 

 

Fax

 

 

Tel_code

 

 

E-mail

 

Структура реляционной базы данных, построенной по схеме снежинки представлена на

После этого можно приступать к загрузке данных в БД, построенную по схеме снежинки. Сначала заполняется «справочная» таблица, в нашем примере – это Prod_class, далее заполняется данными таблица Products, таблиц subscribers и Time, а потом заполняется данными таблица Facts.

Глава 4. Реализация многомерной БД в MS SQL Server

Архитектура SQL Server OLAP Services 

Структура OLAP-сервера показана на Рис. 5.3. В SQL Server OLAP Services можно выделить два центральных компонента: процессор запросов и систему хранения данных. Процессор запросов получает, анализирует и выполняет запросы клиентов. Куда процессор запросов обращается за данными, зависит от используемого режима хранения данных. Microsoft OLAP Services поддерживает все три режима хранения: MOLAP, ROLAP, HOLAP. В режиме MOLAP все данные хранятся в собственных файлах OLAP Services. При использовании ROLAP данные выбираются из реляционной СУБД – это может быть SQL Server или любой другой OLE DB совместимый источник данных. А в случае HOLAP действуют оба типа хранения данных: измерения сохраняются в реляционной БД, а вычисленные агрегаты – в многомерной. 

Для администрирования OLAP Services применяется OLAP Manager, реализованный в виде компонента (Snap-in) Microsoft Management Console (MMC). OLAP Manager управляет OLAP Services при помощи набора объектов Decission Support Objects (DSO), представленных на Рис.5.4.

Создание базы данных 

В первую очередь необходимо создать базу данных. Для этого необходимо выбрать команду меню Action и далее выбрать пункт меню New Database. В открывшемся меню необходимо ввести имя базы данных и необязательное описание – база данных создана.

Создание источника данных 

Прежде чем создавать кубы необходимо выбрать источник данных. Для этого необходимо раскрыть папку с созданной базой данных, далее перейти в папку Library, и щелкнуть правой кнопкой мыши на папке Data Sources. В открывшемся контекстном меню следует выбрать пункт New Data Source. В появившемся окне нужно настроить подключение к OLE DB-источнику. Это напоминает настройку ODBC-источника данных. Необходимо выбрать провайдер, а затем настроить его специфические параметры. (Рис. 5.5.)

Создание кубов 

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

В нашем случае база данных уже создана (в MS Access) и заполнена данными. Нам требуется создать куб, хранящий информацию о процессе подписки на всю продукцию издательства. У нашего куба должно быть два показателя: Количество подписчиков, Общая сумма подписки (таблица «facts»). В качестве измерений выбираем Время (таблица «time»), Продукты (таблицы «Products» и «Prod_class»), Подписчики (таблица «Subscribers»).

Для создания куба нужно:

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

2. выбрать измерения куба

3. сохранить куб

4. отредактировать схему куба

5. указать режим хранения данных: ROLAP, HOLAP, MOLAP

6. выбрать степень агрегированности куба

7. загрузить данные в куб

OLAP manager предлагает для администрирования OLAP Services набор мастеров и специальных инструментов. Мастера позволяют выполнить типовые действия самым простым способом и в нужной последовательности. Специальные инструменты имеют большую гибкость, но в свою очередь требуют от вас большей квалификации. Ряд административных действий можно выполнить минимум двумя путями: при помощи мастера или специального инструмента. Зачастую одно средство вызывается из другого — например, добавить измерение в куб можно непосредственно в Cube Editor либо вызвать Dimension Manager, который в свою очередь может вызвать Dimension Wizard.

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

Проще всего создать куб при помощи Cube Wizard, который вызывается правым щелчком папки Cubes или из меню Action.

1. Выбираем в источнике данных таблицу фактов. Сначала Cube Wizard предлагает выбрать таблицу фактов для куба (Рис.5.6).

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

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

2. Очередной шаг — включение измерений в куб. Мастер предлагается выбрать одно или несколько разделяемых измерений, которые уже созданы в БД и могут использоваться одновременно несколькими кубами.

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

По щелчку кнопки Next появится вопрос, что создается: измерение времени или иное. (Дело в том, что измерение времени обрабатывается особым образом: в частности, в нем автоматически строятся уровни иерархии на основании единственного поля, имеющего тип даты/времени.) Отвечаем отрицательно и попадаем в окно выбора таблицы измерения (Рис.5.8.). По нажатию Next попадаем в окно построения иерархии нового измерения. В качестве уровня иерархии выбираем только лишь поле Name, т.к. оно однозначно определяет отделение УкрПочты, а иные уровни иерархии не нужны.

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

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

3. Завершив добавление всех измерений, нажимаем кнопку Next и попадаем в окнозадания имени куба. В этом окне возможно просмотреть как будет выглядеть куб в средстве просмотра данных OLAP Manager (Рис 5.10). После нажатия кнопки Finish управление передается редактору кубов Cube Editor.

4.С помощью Cube Editor (Рис. 5.11) можно отредактировать созданную схему куба: добавить/убрать измерения или показатели, создать вычисляемые метки и выполнить много других действий. Нам необходимо спроектировать физическое хранилище.

5. Для этого в меню Tools необходимо выбрать пункт Design Storage. После этого начинает работать мастер Storage Design Wizard. Сначала он попросит нас выбрать режим хранения куба: MOLAP, ROLAP, HOLAP. Преимущества каждого из режимов рассмотрены ранее, но необходимо отметить, что при небольшом объеме исходных данных целесообразнее использовать режим хранения MOLAP, так как он дает наибольший выигрыш в скорости. Поэтому, в нашем случае мы выбираем режим MOLAP (Рис 5.12)

6. На следующем этапе необходимо определить степень «агрегированности» куба, т.е. количество агрегатов, которое будет предвычислено и сохранено в кубе при загрузке данных. Storage Design Wizard сам решает какие агрегаты строить. Это решение принимается на основании заданных критериев и с применением эвристических алгоритмов. Ведь если не хранить в кубе все возможные агрегаты, то возможно огромное множество комбинаций, в которых одни агрегаты хранятся, а в других – нет. При этом одни агрегаты могут быть вычислены через другие, без обращения к детальным данным. Например, имея суммы продаж за три месяца, мы легко подсчитываем сумму за квартал. Storage Design Wizard определяет самый эффективный вариант хранения агрегатов. В качестве граничных условий может быть задан предельный объем памяти для хранения агрегатов либо степень увеличения скорости выполнения запросов (Рис.5.13). При расчете увеличения скорости за базу принимается скорость в кубе, лишенном агрегатов. Стопроцентное увеличение скорости соответствует хранению всех возможных агрегатов. Можно не задавать никаких граничных условий, а остановить Storage Design Wizard в произвольный момент, ориентируясь по динамически изменяющемуся графику.

7. После щелчка кнопки Next мастер предлагает сохранить спроектированную схему физического хранилища и либо загрузить данные в куб сразу, либо отложить это на потом. Если не откладывать и выбрать Process Now, произойдет загрузка исходных данных и вычисление агрегатов.

После загрузки данных в многомерный куб их можно просмотреть средством OLAP Services Cube Browser. Над многомерными данными можно производить все возможные операции: создавать срезы многомерного куба, вращать двумерные данные, обобщать отображаемые данные и наоборот, углубляться в детали.

Заключение

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

Но именно на решение таких задач и ориентированы МСУБД. Область, где они наиболее эффективны, это хранение и обработка высоко агрегированных и стабильных во времени данных. И их применение оправдано только при выполнении двух требований.

· Уровень агрегации данных в БД достаточно высок, и, соответственно, объем БД не очень велик (не более нескольких гигабайт).

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

Поэтому уже сегодня МСУБД все чаще используются не только как самостоятельный программный продукт, но и как аналитические средства переднего плана (рис. 4), к системам Хранилищ Данных или традиционным оперативным системам, реализуемым средствами РСУБД.


Рисунок 4. Многоуровневая архитектура.

Причем такое решение позволяет наиболее полно реализовать и использовать достоинства каждого из подходов: компактное хранение детализированных данных и поддержка очень больших БД, обеспечиваемые РСУБД и простота настройки и хорошие времена отклика, при работе с агрегированными данными, обеспечиваемые МСУБД.


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

  1.  Введение в OLAP и многомерные базы данных – PC WEEK
  2.  Принципы проектирования и использования многомерных баз данных (на примере Oracle Express Server) - А. А. Сахаров (Системы управления базами данных, #03/1996)
  3.  Базы Данных, учебник, под ред. Хомоненко, 2003.
  4.  “Принятие решений с помощью системы многомерного экспресс-анализа данных” - Лукичева А.С.


 

А также другие работы, которые могут Вас заинтересовать

42130. Експертна система в області кооперації 43.5 KB
  Володіє гнучкістю 5 Рівень продажів для різних типів покупців та продавців можна оцінити за таблицею: ПР 1 и ПК 1 Результат продажів середній; висока взаємоповага та суперництво ПР 1 и ПК 2 Результат продажів нижче середнього; продавець з презирством ставиться до покупця и той відмовляється від покупки ПР 1 и ПК 3 Результат продажів вище середнього продавець домінує над покупцем покупець приймає пропозиції продавця ПР 1 и ПК 4 Результат продажів середній; продавець ставиться до покупця з повагою але той йому не довіряє ПР 2 и ПК 1...
42131. Типы паралеллилизма 80.5 KB
  Особенности построения вычислительных систем Конвейерные вычислительные системы Основной принцип построения заключается в том что ускорение вычислений в них достигается за счет разделения всей работы на последовательность более мелких узкоспециализированных операций. Необходимо наличие достаточно сложной операционной системы. Мультипроцессорные вычислительные системы В отличии от матричной системы в мультипроцессорной системы каждый из процессоров имеет свое устройство управления. Память может быть как общей так и не общей...
42132. Программа ввода-вывода для КР 580 ВВ 55 макет М1 71 KB
  Формирование управляющего слова Оно формируется в виде восьмиразрядного управляющего слова. Управляющее слово 92 Разряды порта С индицируются Программа 1 0800 3Е92 MVI92 запись в регистр А цифра 92 управляющее слово 0802 D383 OUT 83 Запись управляющего слова в регистр управляющего слова параллельного адаптера К580 ВВ55 0804 DB80 IN 80 Принять в А байт из порта А 0806 32000B ST0B00 Записать из А в ячейку памяти 0B00 0809 3E55 MVI55 Записать в А число 55 080B D382 OUT 82 Вывести число 55 в порт С 080D C30000 JMP0000 Возврат в монитор В...
42136. Особливості написання власних назв 55.5 KB
  З великої букви пишуться ремарки які вказуюсь на ставлення слухачів до якоїсь особи інші ремарки стоять після закінченого речення: Мова категорія Загальнонародна вона характеризує відмінності народів а не суспільних класів Сучасна українська літературна мова. З великої букви також пишеться перше слово рубрики тексту якщо кожна рубрика закінчується крапкою; перше слово прямої мови після двокрапок; початкове слово постанови резолюції протоколу; після двокрапки за словами Слухали Ухвалили в протоколі. З великої букви...