Главная
страница 1 ... страница 2страница 3страница 4страница 5 ... страница 11страница 12

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


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

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

Некоторые преимущества многомерной модели по сравнению с реляционной [7]:


  • Возможность анализа больших объемов данных с приемлемой скоростью;

  • Возможность осуществления любых «срезов» и «углублений» в определённой структуре БД;

  • Быстрая локализация трендов и проблемных областей.

Многомерные модели данных имеют три важных области применения, связанных с проблематикой анализа данных [3]:

  1. Хранилища данных интегрируют для анализа информации из нескольких источников.

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

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

Многомерный куб представлен набором мер и измерений, а именно, куб — это декартовое произведение измерений, где для каждого элемента произведения проставлен набор мер.

Измерения куба – набор доменов, по которым создаётся многомерное пространство. Другими словами, измерение – это упорядоченный набор значений, соответствующий грани куба. Многомерное моделирование предусматривает использование измерений для предоставления максимальной информативности [3]. В отличие от реляционных баз данных, контролируемая избыточность в многомерных базах данных, в общем, считается оправданной, если она увеличивает информационную ценность.

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

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

Отметим, что иерархии могут быть сбалансированными (balanced, т.е. иерархии имеют одинаковую высоту по всем ветвям, а каждое значение не корневого уровня — только одного родителя), как, например, иерархия, представленная на рис. 1.2 и несбалансированными (unbalanced) [9]. Типичный пример несбалансированной иерархии — иерархия типа "начальник—подчиненный", представлен на рис. 1.3

Рис. 1.2 Сбалансированная иерархия измерений



Рис. .3 Несбалансированная иерархия измерений

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

Существуют также иерархии, занимающие промежуточное положение между сбалансированными и несбалансированными (они обозначаются термином ragged — "неровный") [3]. Обычно они содержат такие члены, логические "родители" которых находятся не на непосредственно вышестоящем уровне (см. рис. 1.4).



Рис. 1.4 "Неровная" иерархия измерений

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

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

В кубе, изображенном на рис.1.5, содержится 3 измерения – «Доставка» (характеризует вид доставки), «Отправка» (географическое местонахождение получателя посылки) и «Время» (время совершения факта отправки посылки). Каждое измерение содержит иерархию измерений, например, измерение «Отправка» состоит из отправки в восточное полушарие и в западное. В свою очередь, восточное полушарие состоит из Африки, Азии, Австралии и Европы, а западное – из Северной и Южной Америк.

Рис.1.5 Пример многомерного куба

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

Обычно говорят о четырех наиболее часто встречающихся типах фактов. К ним относятся:



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

  • факты, связанные с «моментальными снимками» (англ. Snapshot facts). Основаны на состоянии объекта (например, банковского счета) в определенные моменты времени, например на конец дня или месяца. Типичными примерами таких фактов являются объем продаж за день или дневная выручка;

  • факты, связанные с элементами документа (англ. Line-item facts). Основаны на том или ином документе (например, счете за товар или услуги) и содержат подробную информацию об элементах этого документа (например, количестве, цене, проценте скидки);

  • факты, связанные с событиями или состоянием объекта (англ. Event or state facts). Представляют возникновение события без подробностей о нем (например, просто факт продажи или факт отсутствия таковой без иных подробностей).

Мера (или показатель) – это значение, которое однозначно определяется фиксированным набором измерений и количественно характеризует анализируемые факты. В вышеприведенном примере мерами являются количество отправленных посылок и время отправки последней посылки. Так можно сказать, что в Европу в четвертом квартале 1999 года было отправлено 696 посылок, и последняя была отправлена 15.12.99.

Меры бывают трёх типов:



  • Аддитивные (additive) меры – допускающие агрегирование относительно любого измерения куба данных;

  • Неаддитивные (nonadditive) меры – которые не могут агрегироваться ни по какому измерению куба данных;

  • Полуаддитивные (semiadditive) меры – которые допускают агрегирование относительно одних измерений и не допускают относительно других.

Многомерная база данных естественным образом предназначена для определенных типов запросов:

  • Запросы вида slice и dice (срезы куба) — формирование подмножества многомерного массива данных, соответствующего единственному значению одного или нескольких элементов измерений, не входящих в это подмножество. Если рассматривать термин slice с позиции конечного пользователя, то наиболее часто его роль играет двумерная проекция куба (рис. 1.6). Срез dice отличается от slice тем, что это трёх- и более-мерная проекция куба.

pic3-02

Рис. 1.6 Операция среза (slice)



  • Запросы вида drill-down (детализация) и roll-up (обобщение) — взаимообратные операции, которые используют иерархию измерений и меры для агрегирования. Направление детализации/обобщения может быть задано как по иерархии отдельных измерений, так и согласно прочим отношениям, установленным в рамках измерений или между измерениями. Например, если при анализе данных об объемах продаж в Северной Америке выполнить операцию drill-down для измерения "Регион", то на экране будут отображены такие его элементы как "Канада", "Восточные Штаты Америки" и "Западные Штаты Америки". В результате дальнейшей детализации элемента "Канада" будут отображены элементы "Торонто", "Ванкувер", "Монреаль" и т. д

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

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

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

pic3-03

Рис. 1.7 Операция вращения

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

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

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

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

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

1.3.1 Реализация многомерной модели данных


Многомерная структура хранения данных может быть реализована с помощью многомерных БД или в системе управления реляционными БД с использованием схемы звезды (star schema) или схемы снежинки (snowflake schema) [7].

Схема звезды (рис. 1.8) является практически реляционным воплощением многомерной представления данных. Она является проекцией куба на «реляционную плоскость» и состоит из одной таблицы фактов (fact table) и нескольких таблиц измерений (dimension table). Таблица фактов содержит по одной строке для каждого факта — минимально рассматриваемого атома анализируемого процесса.



c:\documents and settings\администратор\мои документы\схема звезда.png

Рис.1.8 Схема звезды

Например, для оптового склада фактом может служить факт продажи изделий.

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

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

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



c:\documents and settings\администратор\мои документы\схема снежинки.png

Рис.1.9 Схема снежинки

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

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



<< предыдущая страница   следующая страница >>
Смотрите также:
2. Исследование предметной области разрабатываемого модуля многомерного анализа данных 35
572.04kb.
9 стр.
2. Исследование предметной области разрабатываемого модуля многомерного анализа данных 35
816.08kb.
12 стр.
Особенности анализа многомерных данных
170.74kb.
1 стр.
Отчет о лаботарорной работе методы и средства анализа данных по теме: «Система анализа данных weka»
383.87kb.
2 стр.
Диссертация посвящена вопросу оперативного многомерного анализа данных (olap) в системах поддержки принятия решений (сппр). Рассматривается класс систем, учитывающих для формирования оптимальных решений изменяемые с течением времени факторы
945.67kb.
7 стр.
12 Пример применения: оптимизация зоны обслуживания на основе векторных данных
52.42kb.
1 стр.
Формула специальности: Содержанием специальности 22. 00. 04 – «Социальная структура, социальные институты и процессы»
36.75kb.
1 стр.
Дипломная работа студента Коробкина А. А
588.33kb.
4 стр.
Отчет о лаботарорной работе по дисциплине Методы и средства анализа данных по теме: «Система анализа данных weka»
229.16kb.
1 стр.
Лабораторные работы по дисциплине "Теория экономических информационных систем"
95.98kb.
1 стр.
Исследование предметной области 11 2 Проектирование системы 24 3 Разработка системы 38
421.31kb.
1 стр.
Место теории измерений в методах анализа данных
266.06kb.
1 стр.