Кафедра "КСУ"
Реферат
"Принципы проектирования и использования многомерных баз данных"
Введение
Сегодня все большее число организаций приходит к пониманию того, что без наличия своевременной и объективной информации о состоянии рынка, прогнозирования его перспектив, постоянной оценки эффективности функционирования собственных структур и анализа взаимоотношений с бизнес-партнерами и конкурентами их дальнейшее развитие становится практически невозможным. Поэтому не удивительно то внимание, которое сегодня уделяется средствам реализации и концепциям построения информационных систем, ориентированных на аналитическую обработку данных. И в первую очередь это касается систем управления базами данных, основанными на многомерном подходе - МСУБД.
Следует заметить, что МСУБД не являются изобретением девяностых годов, а сам многомерный подход возник практически одновременно и параллельно с реляционным. Однако, только начиная с середины девяностых годов, а точнее с 1993 г., интерес к МСУБД начал приобретать всеобщий характер. Именно в этом году появилась новая программная статья одного из основоположников реляционного подхода Э. Кодда [1], в которой он сформулировал 12 основных требований к средствам реализации OLAP (табл. 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 уже стали сегодня одними из наиболее широко распространенных концепций построения аналитических систем.
Требования к средствам реализации систем оперативной и аналитической обработки данных
При первом знакомстве с многомерным подходом к организации данных достаточно часто возникают два противоречивых вопроса.
Для чего собственно нужны МСУБД и нужно ли тратить время и средства на их освоение и приобретение, если все те же задачи можно решить и средствами традиционных РСУБД?
И обратный:
Почему МСУБД ограничивают себя исключительно приложениями, ориентированными на анализ данных и почему бы на их основе не реализовывать традиционные системы оперативной обработки данных?
И несмотря на то, что эти вопросы выражают достаточно противоположные точки зрения, ответ на них звучит приблизительно одинаково: "Главное достоинство МСУБД состоит именно в том, что они узко специализированны и область их применения - интерактивная аналитическая обработка агрегированных исторических и прогнозируемых данных".
Агрегированные данные. Пользователя, занимающегося анализом, редко интересуют детализированные данные. Более того, чем выше уровень пользователя (руководителя, управляющего, аналитика), тем выше уровень агрегации данных, используемых им для принятия решения. Рассмотрим в качестве примера фирму по продаже автомобилей. Коммерческого директора такой фирмы мало интересует вопрос: "Какого цвета "Жигули" успешнее всего продает один из ее менеджеров - Петров: белого или красного?" Для него важно, какие модели и какие цвета предпочитают в данном регионе. Его также мало интересует детализация на уровне контракта, часа или даже дня. Например, если выяснится, что "ВАЗ2108 Красного цвета" чаще покупают в утренние часы, этот факт скорее заинтересует психиатра, а не коммерческого аналитика. Для правильного формирования склада ему важна и необходима информация на уровне декады, месяца или даже квартала.
Исторические данные. Важнейшим свойством данных в аналитических задачах является их Исторический характер. После того как зафиксировано, что Петров в июне 1996 г. продал 2 автомобиля "Волга" и 12 автомобилей "Жигули", данные об этом событии становятся историческим (свершившимся) фактом. И после того, как информация об этом факте получена, верифицирована и заведена в БД, она может быть сколько угодно раз считана оттуда, но уже не может и не должна быть изменена. Историчность данных предполагает не только высокий уровень статичности (неизменности) как собственно данных (например: Петров продал в 1995 г. 51 автомобиль "Жигули ВАЗ2105"), так и их взаимосвязей (например: в 1995 г. Петров работал в Восточном Регионе; в 1995 г. продавались автомобили модели ВАЗ2105). А это, в свою очередь, дает возможность использовать специализированные, основанные на предположении о статичности данных и их взаимосвязей методы загрузки, хранения, индексации и выборки.
Другим неотъемлемым свойством Исторических данных является обязательная спецификация Времени, которому эти данные соответствуют. Причем Время является не только наиболее часто используемым критерием выборки, но и одним из основных критериев, по которому данные упорядочиваются в процессе обработки и представления пользователю. А это накладывает соответствующие требования как на используемые механизмы хранения и доступа:
для уменьшения времени обработки запросов желательно, чтобы уже в БД данные хранились (были предварительно отсортированы) в том порядке, в котором они наиболее часто запрашиваются;
так и на языки описания и манипулирования данными, например:
во многих организациях используются как общепринятые, так и собственные календарные циклы (финансовый год может начинаться не в январе как календарный, а, например, в июне);
время является стандартным параметром практически любой аналитической, статистической или финансовой функции (прогноз, нарастающий итог, переходящий запас, скользящее среднее и т.д.).
Прогнозируемые данные. Когда говорится о неизменности и статичности данных в аналитических системах, имеется в виду неизменность исключительно Исторических данных (данных, описывающих уже произошедшие события). Такое предположение ни в коем случае не распространяется на Прогнозируемые данные (данные о событии, которое еще не происходило). И этот момент является весьма существенным.
Например, если мы строим прогноз об объеме продаж на июнь 1997 г. для менеджера Петрова, то, по мере поступления фактических (Исторических) данных за 1996 г., эта цифра может и будет многократно изменяться и уточняться. Более того, достаточно часто прогнозирование и моделирование затрагивает не только будущие, еще не произошедшие, но и прошлые, уже свершившиеся события. Например, анализ: "а, что будет (было бы)... если (бы)..?", строится на предположении о том, что значения некоторых данных, в том числе и из прошлого, отличны от реальных. И для ответа на вопрос:
"Какой был бы Прогноз по объему продаж автомобилей "Волга" для менеджера Петрова на июнь 1997 г., если бы объем продаж "Волг" в июне 1996 г. у него возрос на тот же процент, что объем продаж "Жигулей"?"
потребуется не только вычислить новое, еще не существующее значение Объема Продаж, для еще не наступившего июня 1997 г., но и предварительно вычислить гипотетическое значение Объема продаж, за уже прошедший июнь 1996 г.