|
Таблица 4. (Список потенциальных вопросов менеджеров фирмы).
Рассмотрим в качестве примера вопрос сотрудника коммерческого отдела ("Какие два варианта скидок наиболее эффективны в Западном регионе в летний период при продаже автомобилей "Жигули", на основе данных за последние 10 лет?"). Как было сказано выше, на этом этапе мы не собираемся программировать этот вопрос, тем более, что инструментальные средства конечного пользователя позволят легко сформулировать его в интерактивном режиме, без написания строк кода. Сейчас нам важнее понять, какие данные должны быть в МБД, оценить временные интервалы, которые должны отражаться, понять трудоемкость и реальность подготовки и загрузки этих данных.
После того как первичный анализ вопросов выполнен, и получено представление о том, какие данные потенциально могут выступать в качестве Показателей и Измерений (табл. 5), можно переходить к проектированию ее структуры - определению конкретных Измерений, их взаимосвязей и уровней агрегации хранимых данных.
Наименование информации
Временной интервал
Количество строк
Тип
Источник
Месяц
10 лет
12 * 10
Измерение
Оперативная система "Продажи", архив
Регион
10 лет
5
Измерение
- "" -
Модель автомобиля
10 лет
200
Измерение
- "" -
Типы скидок
10 лет
4
Измерение
- "" -
Объем продаж в USD
10 лет
200 * 12 * 10 * 5 * 4
Показатель
- "" -
Таблица 5. (Данные, необходимые для ответа на вопрос аналитика коммерческого отдела).
Критерии выбора уровня агрегации
Если спросить пользователя, какой уровень детализации ему желателен, он не задумываясь ответит - максимально возможный. Однако стоит оценить, сколько такое решение может стоить, и попытаться определить возможный экономический эффект от наличия данных на каждом новом уровне детализации.
Например, выбрав в качестве уровня агрегации Год, вы получите возможность проанализировать общие тенденции автомобильного рынка и спрогнозировать динамику его развития. Выбрав же в качестве уровня агрегации Месяц или Неделю, вы, кроме того, сможете спрогнозировать спрос на конкретные модели в конкретные моменты времени. И хотя автомобили - товар не сезонный, скорее всего, весной и летом их покупают больше, чем осенью и зимой. Это позволит отследить возможные сезонные колебания, рациональнее формировать свой склад и более эффективно проводить политику формирования сезонных скидок и распродаж. А если в систему введена информация о затратах на маркетинг, появится возможность проследить эффект от каждого конкретного маркетингового мероприятия.
Выбор в качестве уровня агрегации Номер Контракта/Счета позволит перейти на качественно новый уровень анализа. На этом уровне можно будет учитывать взаимосвязи между конкретным Автомобилем, Менеджером и Покупателем. А поскольку при покупке автомобиля заполняется множество документов, то доступна достаточно детальная информация о каждом конкретном Покупателе (Возраст, Пол, Место жительства, Вид оплаты и т.д.). Теперь вы сможете проанализировать не только рынок, но и заглянуть внутрь своей фирмы и всесторонне проанализировать эффективность работы каждого Менеджера и Подразделения. Но наиболее ценное, что вы получаете, - это информация о Регионах и Покупателях. Например, вы не только сможете оценить, какие Модели автомобилей пользуются наибольшим спросом в конкретном регионе сегодня, но на основе анализа истории и структуры автомобильного рынка в более развитых, с точки зрения автомобилизации, регионах попытаться оценить динамику спроса и перспективы различных Моделей в остальных регионах.
Однако переход на каждый следующий уровень детализации и добавление новых источников данных могут привести к увеличению, иногда более чем на порядок, размера целевой МБД и соответствующему удорожанию и усложнению аппаратного решения.
Рассмотрим в качестве примера Показатель Объем продаж. Анализ предметной области показывает, что он однозначно определяется комбинацией четырех Измерений:
1. Месяц
2. Регион
3. Завод-Производитель
4. {Тип скидки}
Выбрав уровень детализации:
1. День (365 * 10 = 3650 различных значений),
2. Менеджер (300 различных значений),
3. Модель Автомобиля (100 различных значений),
4. Тип Скидки (4 различных значения),
получим куб, состоящий из 438000000 ячеек. Но в основе используемого в МСУБД способа хранения данных лежит предположение о том, что внутри, в данном случае четырехмерного гиперкуба, нет пустот. Данные в МСУБД представлены в виде разреженных матриц с заранее фиксированной размерностью. При этом значения Показателей хранятся в виде множества логически упорядоченных блоков (массивов), имеющих фиксированную длину, причем именно блок является минимальной индексируемой единицей.
Таким образом, в нашей БД будет сразу же зарезервировано место для всех 438 млн. значений Показателя Объем Продаж. Причем цифры "300 менеджеров" и "100 моделей автомобилей" вовсе не означают того, что сегодняшняя номенклатура фирмы - 100 различных моделей, которые продают 300 человек. Цифра 300 говорит о том, что в фирме за 10 лет ее существования работало 300 различных менеджеров. Сегодня же их может быть, например, всего 30.
Попробуем оценить, какой процент ячеек в нашем случае будет содержать реальные значения. Предположим, что в среднем в фирме постоянно работает около 30 менеджеров, менеджер продает в день 10 различных моделей и при продаже каждого автомобиля может быть использован только один вариант скидки. Тогда 3650 * 30 * 10 * 1 = 1095000. То есть только 0,25% ячеек куба будет содержать реальные значения данных. И хотя в МСУБД обычно предполагается, что блоки, полностью заполненные неопределенными значениями, не хранятся, как правило, это не обеспечивает полного решения проблемы.
Загрузка данных
Как уже было сказано выше, основное назначение МСУБД - работа с достаточно стабильными во времени данными, и данные в таких системах достаточно редко вводятся в интерактивном режиме. Обычно загрузка выполняется из внешних источников: оперативных БД, электронных таблиц или из заранее подготовленных плоских файлов.
В OLAP системах загрузка данных может производиться практически из различных внешних источников данных, включая:
различные РСУБД;
плоские файлы с фиксированной структурой записей;
электронных таблиц (Lotus 1-2-3, Ecxell и т.д.);
в интерактивном режиме через специально написанные пользовательские приложения.
Следует заметить, что в данные могут храниться как на постоянной основе, так и загружаться динамически, в тот момент, когда к ним обратится пользователя. Таким образом, имеется возможность постоянно хранить в МБД только ту информацию, которая наиболее часто запрашивается пользователями. Для всех остальных данных хранятся только описания их структуры и программы их выгрузки из центральной (обычно реляционной) БД. И хотя при первичном обращении к таким виртуальным данным, время отклика может оказаться достаточно продолжительным, такое решение обеспечивает высокую гибкость и требует более дешевых аппаратных средств. А если впоследствии оказывается, что интенсивность обращения к данным, имеющим статус временных, высока, их статус может быть легко изменен.
Заключение
В заключение необходимо сказать, что было бы не совсем правильно противопоставлять или говорить о какой-либо серьезной взаимной конкуренции реляционного и многомерного подходов. Правильнее сказать, что эти два подхода взаимно дополняют друг друга. Как отметил Э. Кодд [1], реляционный подход никогда не предназначался для решения на его основе задач, требующих синтеза, анализа и консолидации данных. И изначально предполагалось, что такого рода функции должны реализовываться с помощью внешних по отношению к РСУБД, инструментальных средств.
Но именно на решение таких задач и ориентированы МСУБД. Область, где они наиболее эффективны, это хранение и обработка высоко агрегированных и стабильных во времени данных. И их применение оправдано только при выполнении двух требований.
Уровень агрегации данных в БД достаточно высок, и, соответственно, объем БД не очень велик (не более нескольких гигабайт).
В качестве граней гиперкуба выбраны достаточно стабильные во времени Измерения (с точки зрения неизменности их взаимосвязей), и, соответственно, число несуществующих значений в ячейках гипрекуба относительно невелико.
Поэтому уже сегодня МСУБД все чаще используются не только как самостоятельный программный продукт, но и как аналитические средства переднего плана, к системам Хранилищ Данных или традиционным оперативным системам, реализуемым средствами РСУБД.
Рисунок 1.(Многоуровневая архитектура).
Причем такое решение позволяет наиболее полно реализовать и использовать достоинства каждого из подходов: компактное хранение детализированных данных и поддержка очень больших БД, обеспечиваемые РСУБД и простота настройки и хорошие времена отклика, при работе с агрегированными данными, обеспечиваемые МСУБД.
Литература
1. Codd, S.B. Codd, C.T. Salley. Providing OLAP (On-Line Analytical Processing) to User-Analysts: An IT Mandate. - E.F.Codd & Associates, 1993.
2. Guide to OLAP Terminology. - Kenan Systems Corporation, 1995
При использовании материалов активная ссылка на источник обязательна.