Принципы проектирования и использования многомерных баз данных
содержащее информацию об истории
продаж этой модели различными менеджерами в различные годы.
Операция "Вращение". Изменение порядка представления (визуализации)
Измерений (обычно применяется при двухмерном представлении данных)
называется Вращением (Rotate). Эта операция обеспечивает возможность
визуализации данных в форме, наиболее комфортной для их восприятия.
Например, если менеджер первоначально вывел отчет, в котором Модели
автомобилей были перечислены по оси X, а Менеджеры по оси Y, он может
решить, что такое представление мало наглядно, и поменять местами
координаты (выполнить Вращение на 90 градусов).
Отношения и Иерархические Отношения. В нашем примере значения Показателей
определяются только тремя измерениями. На самом деле их может быть гораздо
больше и между их значениями обычно существуют множество различных
Отношений (Relation) типа "один ко многим".
Например, каждый Менеджер может работать только в одном подразделении, а
каждой модели автомобиля однозначно соответствует фирма, которая ее
выпускает:
Менеджер ->Подразделение;
Модель Автомобиля ->Фирма-Производитель.
Заметим, что для Измерений, имеющих тип Время (таких как День, Месяц,
Квартал, Год), все Отношения устанавливаются автоматически, и их не
требуется описывать.
В свою очередь, множество Отношений может иметь иерархическую структуру -
Иерархические Отношения (Hierarchical Relationships). Вот только несколько
примеров таких Иерархических Отношений:
День -> Месяц -> Квартал -> Год;
Менеджер -> Подразделение -> Регион -> Фирма -> Страна;
Модель Автомобиля -> Завод-Производитель -> Страна.
И часто более удобно не объявлять новые Измерения и затем устанавливать
между ними множество Отношений, а использовать механизм Иерархических
Отношений. В этом случае все потенциально возможные значения из различных
Измерений объединяются в одно множество. Например, мы можем добавить к
множеству значений Измерения Менеджер ("Петров", "Сидоров", "Иванов",
"Смирнов"), значения Измерения Подразделение ("Филиал 1", "Филиал 2",
"Филиал 3") и Измерения Регион ("Восток", "Запад") и затем определить между
этими значениями Отношение Иерархии.
Операция Агрегации. С точки зрения пользователя, Подразделение, Регион,
Фирма, Страна являются точно такими же Измерениями, как и Менеджер. Но
каждое из них соответствует новому, более высокому уровню агрегации
значений Показателя Объем продаж. В процессе анализа пользователь не только
работает с различными Срезами данных и выполняет их Вращение, но и
переходит от детализированных данных к агрегированным, т.е. производит
операцию Агрегации (Drill Up). Например, посмотрев, насколько успешно в
1995 г. Петров продавал модели "Жигули" и "Волга", управляющий может
захотеть узнать, как выглядит соотношение продаж этих моделей на уровне
Подразделения, где Петров работает. А затем получить аналогичную справку по
Региону или Фирме.
Операция Детализации. Переход от более агрегированных к более
детализированным данным называется операцией Детализации (Drill Down).
Например, начав анализ на уровне Региона, пользователь может захотеть
получить более точную информацию о работе конкретного Подразделения или
Менеджера.
Проектирование многомерной БД
Данная работа ни в коем случае не посвящена рассмотрению методологии
проектирования МБД, и здесь излагаются только самые общие элементы подхода
к процессу и способам проектирования. Тем не менее излагаемый подход не
только позволит наиболее полно понять как достоинства, так и ограничения
многомерного подхода, но и послужит хорошей основой для быстрого построения
систем.
Определение вопросов
Основное назначение МСУБД - реализация систем, ориентированных на
динамический, многомерный анализ исторических и текущих данных, анализ
тенденций, моделирование и прогнозирование будущего. Причем такие системы в
большой степени ориентированы на обработку произвольных, заранее не
регламентированных запросов, и при их разработке фактически отсутствует
этап проектирования регламентированных пользовательских приложений
(наиболее ответственный и трудоемкий в традиционных оперативных системах).
Проектирование МБД обычно начинается с определения вопросов (табл. 4), с
которыми конечные пользователи хотели бы обратиться к системе. Причем на
этом этапе интерес представляют даже не сами тексты вопросов, а понимание
того, о каких личностях, местах, событиях и объектах в них спрашивается.
|Подразделение |Менеджер |Временной |Вопрос |
| | |интервал | |
|Отдел |Петров |3 года |На сколько процентов увеличились |
| | | |продажи "Жигулей" в Западном регионе |
| | | |после январской рекламной кампании в |
| | | |еженедельнике "Западный Вестник"? |
|Финансовый |Смирнов |5 лет |Какие региональные подразделения |
|отдел | | |превысили в третьем квартале |
| | | |запланированные расходы на командировки|
| | | |и как это соотносится с ростом их |
| | | |прибыли (в абсолютных и относительных |
| | | |величинах)? |
|Коммерческий |Левшин |10 лет |Какие два варианта скидок наиболее |
|отдел | | |эффективны в Западном регионе в летний |
| | | |период при продаже автомобилей |
| | | |"Жигули", на основе данных за последние|
| | | |10 лет? |
|Отдел развития |Васильева |5 лет |Как повлияло на объемы продаж открытие |
|бизнеса | | |двух новых отделений в Южном регионе и |
| | | |на какой процент могут увеличиться |
| | | |продажи в Северном регионе, если в этом|
| | | |году там будет открыто 3 новых офиса? |
Таблица 4. (Список потенциальных вопросов менеджеров фирмы).
Рассмотрим в качестве примера вопрос сотрудника коммерческого отдела
("Какие два варианта скидок наиболее эффективны в Западном регионе в летний
период при продаже автомобилей "Жигули", на основе данных за последние 10
лет?"). Как было сказано выше, на этом этапе мы не собираемся
программировать этот вопрос, тем более, что инструментальные средства
конечного пользователя позволят легко сформулировать его в интерактивном
режиме, без написания строк кода. Сейчас нам важнее понять, какие данные
должны быть в МБД, оценить временные интервалы, которые должны отражаться,
понять трудоемкость и реальность подготовки и загрузки этих данных.
После того как первичный анализ вопросов выполнен, и получено
представление о том, какие данные потенциально могут выступать в качестве
Показателей и Измерений (табл. 5), можно переходить к проектированию ее
структуры - определению конкретных Измерений, их взаимосвязей и уровней
агрегации хранимых данных.
|Наименование |Временной |Количество строк|Тип |Источник |
|информации |интервал | | | |
|Месяц |10 лет |12 * 10 |Измерение |Оперативная |
| | | | |система "Продажи",|
| | | | |архив |
|Регион |10 лет |5 |Измерение |- "" - |
|Модель |10 лет |200 |Измерение |- "" - |
|автомобиля | | | | |
|Типы скидок |10 лет |4 |Измерение |- "" - |
|Объем продаж |10 лет |200 * 12 * 10 * |Показатель |- "" - |
|в USD | |5 * 4 | | |
Таблица 5. (Данные, необходимые для ответа на вопрос аналитика
коммерческого отдела).
Критерии выбора уровня агрегации
Если спросить пользователя, какой уровень детализации ему желателен, он
не задумываясь ответит - максимально возможный. Однако стоит оценить,
сколько такое решение может стоить, и попытаться определить возможный
экономический эффект от наличия данных на каждом новом уровне детализации.
Например, выбрав в качестве уровня агрегации Год, вы получите возможность
проанализировать общие тенденции автомобильного рынка и спрогнозировать
динамику его развития. Выбрав же в качестве уровня агрегации Месяц или
Неделю, вы, кроме того, сможете спрогнозировать спрос на конкретные модели
в конкретные моменты времени. И хотя автомобили - товар не сезонный, скорее
всего, весной и летом их покупают больше, чем осенью и зимой. Это позволит
отследить возможные сезонные колебания, рациональнее формировать свой склад
и более эффективно проводить политику формирования сезонных скидок и
распродаж. А если в систему введена информация о затратах на маркетинг,
появится возможность
| |  скачать работу |
Принципы проектирования и использования многомерных баз данных |
