Добавил:
Upload Опубликованный материал нарушает ваши авторские права? Сообщите нам.
Вуз: Предмет: Файл:
Базы данных Шехтман.doc
Скачиваний:
2
Добавлен:
01.04.2025
Размер:
3 Мб
Скачать
☆

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

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

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

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

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

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

Товар

Месяц

Объем

Бананы

Июнь

150

Бананы

Июль

130

Бананы

Август

120

Яблоки

Июнь

100

Яблоки

Июль

155

Яблоки

Июль

110

Таблица 1. Реляционное представление данных.

Так называемая сводная таблица (характерная форма представления при использовании многомерной модели) представлена на табл. 2.

Июнь

Июль

Август

Бананы

150

130

120

Яблоки

100

155

110

Таблица 2. Сводная таблица.

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

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

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

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

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

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

  • показатель или мера (Measure)

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

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

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

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

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

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

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

  • Товар;

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

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

  • Товар;

  • Магазин;

  • Время.

Измерения:

Время (Год) – явнварь, февраль, март, …

Магазин - N, M, …

Показатель:

Объем Продаж

Измерения и показатели (ячейки).

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

  • первое Измерение - Товар;

  • второе Измерение - Магазин;

  • третье Измерение - Время;

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

Заметим, что, в отличие от измерений, не все значения Показателей должны иметь и имеют реальные значения. Например, магазин N мог не торговать лимонами в определенный период, и в этом случае все значения показателя Объем продаж за этот период по лимонам будут иметь неопределенные значения.

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

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

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

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

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

Магазин -> Район города

Товар -> Класс товара

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

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

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

Партия товара ->Товар -> Подгруппа товара -> Класс товара

И часто более удобно не объявлять новые Измерения и затем устанавливать между ними множество отношений, а использовать механизм иерархических отношений. В этом случае все потенциально возможные значения из различных измерений объединяются в одно множество. Например, мы можем добавить к множеству значений измерения Товар ("Бананы", "Апельсины", "Яблоки", "Арбузы", “Капуста”, “Лосось”), значения Измерения Группа товара ("Фрукты", "Овощи", "Ягоды") и измерения Класс товара ("Фрукты-овощи", "Рыба") и затем определить между этими значениями отношение иерархии. Например:

Фрукты и овощи

Рыба

Фрукты

Фрукты и овощи

Овощи

Фрукты и овощи

Ягода

Фрукты и овощи

Бананы

Фрукты

Апельсины

Фрукты

Арбузы

Ягода

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

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