Кафедра «КСУ»
Реферат
«Принципыпроектирования и использования многомерных баз данных»
Введение
Сегодня все большее число организаций приходит к пониманиютого, что без наличия своевременной и объективной информации о состоянии рынка,прогнозирования его перспектив, постоянной оценки эффективностифункционирования собственных структур и анализа взаимоотношений с бизнес-партнерами и конкурентами их дальнейшее развитиестановится практически невозможным. Поэтому не удивительно то внимание, котороесегодня уделяется средствам реализации и концепциям построения информационныхсистем, ориентированных на аналитическую обработку данных. И в первую очередьэто касается систем управления базами данных, основанными на многомерномподходе — МСУБД.
Следует заметить, что МСУБД не являются изобретениемдевяностых годов, а сам многомерный подход возник практически одновременно ипараллельно с реляционным. Однако, только начиная с середины девяностых годов,а точнее с 1993 г., интерес к МСУБД начал приобретать всеобщий характер. Именнов этом году появилась новая программная статья одного из основоположниковреляционного подхода Э. Кодда [1], в которой он сформулировал 12 основныхтребований к средствам реализации OLAP (табл. 1) и произвел анализ некоторыхкак субъективных, так и вполне объективных недостатков реляционного подхода,затрудняющих его использование в задачах, требующих сложной аналитическойобработки данных.
1
Многомерное представление данных
Средства должны поддерживать многомерный на концептуальном уровне взгляд на данные.
2
Прозрачность
Пользователь не должен знать о том, какие конкретные средства используются для хранения и обработки данных, как данные организованы и откуда они берутся.
3
Доступность
Средства должны сами выбирать и связываться с наилучшим для формирования ответа на данный запрос источником данных. Средства должны обеспечивать автоматическое отображение их собственной логической схемы в различные гетерогенные источники данных.
4
Согласованная производительность
Производительность практически не должна зависеть от количества Измерений в запросе.
5
Поддержка архитектуры клиент-сервер
Средства должны работать в архитектуре клиент-сервер.
6
Равноправность всех измерений
Ни одно из измерений не должно быть базовым, все они должны быть равноправными (симметричными).
7
Динамическая обработка разреженных матриц
Неопределенные значения должны храниться и обрабатываться наиболее эффективным способом.
8
Поддержка многопользовательского режима работы с данными
Средства должны обеспечивать возможность работать более чем одному пользователю.
9
Поддержка операций на основе различных измерений
Все многомерные операции (например Агрегация) должны единообразно и согласованно применяться к любому числу любых измерений.
10
Простота манипулирования данными
Средства должны иметь максимально удобный, естественный и комфортный пользовательский интерфейс.
11
Развитые средства представления данных
Средства должны поддерживать различные способы визуализации (представления) данных.
12
Неограниченное число измерений и уровней агрегации данных
Не должно быть ограничений на число поддерживаемых Измерений.
Таблица1. (12 правил оценки средств для OLAP).
Набор этих требований, послуживших де-факто определениемOLAP, достаточно часто вызывает различные нарекания, так как здесь смешаны:
·
·
·
Многомерное представление данных и OLAP уже стали сегодняодними из наиболее широко распространенных концепций построения аналитическихсистем.
Требования к средствамреализации систем оперативной и аналитической обработки данных
При первом знакомстве с многомерным подходом к организацииданных достаточно часто возникают два противоречивых вопроса.
Для чего собственнонужны МСУБД и нужно ли тратить время и средства на их освоение и приобретение,если все те же задачи можно решить и средствами традиционных РСУБД?
И обратный:
Почему МСУБДограничивают себя исключительно приложениями, ориентированными на анализ данныхи почему бы на их основе не реализовывать традиционные системы оперативнойобработки данных?
И несмотря на то, что эти вопросы выражают достаточнопротивоположные точки зрения, ответ на них звучит приблизительно одинаково:«Главное достоинство МСУБД состоит именно в том, что они узкоспециализированны и область их применения — интерактивная аналитическаяобработка агрегированных исторических и прогнозируемых данных».
Агрегированные данные.Пользователя, занимающегося анализом, редко интересуют детализированные данные.Более того, чем выше уровень пользователя (руководителя, управляющего,аналитика), тем выше уровень агрегации данных, используемых им для принятиярешения. Рассмотрим в качестве примера фирму по продаже автомобилей.Коммерческого директора такой фирмы мало интересует вопрос: «Какого цвета»Жигули" успешнее всего продает один из ее менеджеров — Петров:белого или красного?" Для него важно, какие модели и какие цветапредпочитают в данном регионе. Его также мало интересует детализация на уровнеконтракта, часа или даже дня. Например, если выяснится, что «ВАЗ2108Красного цвета» чаще покупают в утренние часы, этот факт скореезаинтересует психиатра, а не коммерческого аналитика. Для правильногоформирования склада ему важна и необходима информация на уровне декады, месяцаили даже квартала.
Исторические данные.Важнейшим свойством данных в аналитических задачах является их Историческийхарактер. После того как зафиксировано, что Петров в июне 1996 г. продал 2автомобиля «Волга» и 12 автомобилей «Жигули», данные обэтом событии становятся историческим (свершившимся) фактом. И после того, какинформация об этом факте получена, верифицирована и заведена в БД, она можетбыть сколько угодно раз считана оттуда, но уже не может и не должна бытьизменена. Историчность данных предполагает не только высокий уровеньстатичности (неизменности) как собственно данных (например: Петров продал в1995 г. 51 автомобиль «Жигули ВАЗ2105»), так и их взаимосвязей(например: в 1995 г. Петров работал в Восточном Регионе; в 1995 г. продавалисьавтомобили модели ВАЗ2105). А это, в свою очередь, дает возможностьиспользовать специализированные, основанные на предположении о статичностиданных и их взаимосвязей методы загрузки, хранения, индексации и выборки.
Другим неотъемлемым свойством Исторических данных являетсяобязательная спецификация Времени, которому эти данные соответствуют. ПричемВремя является не только наиболее часто используемым критерием выборки, но иодним из основных критериев, по которому данные упорядочиваются в процессеобработки и представления пользователю. А это накладывает соответствующиетребования как на используемые механизмы хранения и доступа:
для уменьшения времени обработки запросов желательно, чтобыуже в БД данные хранились (были предварительно отсортированы) в том порядке, вкотором они наиболее часто запрашиваются;
так и на языки описания и манипулирования данными, например:
во многих организациях используются как общепринятые, так исобственные календарные циклы (финансовый год может начинаться не в январе каккалендарный, а, например, в июне);
время является стандартным параметром практически любойаналитической, статистической или финансовой функции (прогноз, нарастающийитог, переходящий запас, скользящее среднее и т.д.).
Прогнозируемые данные.Когда говорится о неизменности и статичности данных в аналитических системах,имеется в виду неизменность исключительно Исторических данных (данных,описывающих уже произошедшие события). Такое предположение ни в коем случае нераспространяется на Прогнозируемые данные (данные о событии, которое еще непроисходило). И этот момент является весьма существенным.
Например, если мы строим прогноз об объеме продаж на июнь1997 г. для менеджера Петрова, то, по мере поступления фактических(Исторических) данных за 1996 г., эта цифра может и будет многократноизменяться и уточняться. Более того, достаточно часто прогнозирование имоделирование затрагивает не только будущие, еще не произошедшие, но и прошлые,уже свершившиеся события. Например, анализ: «а, что будет (было бы)…если (бы)..?», строится на предположении о том, что значения некоторыхданных, в том числе и из прошлого, отличны от реальных. И для ответа на вопрос:
«Какой был быПрогноз по объему продаж автомобилей „Волга“ для менеджера Петрова наиюнь 1997 г., если бы объем продаж „Волг“ в июне 1996 г. у неговозрос на тот же процент, что объем продаж „Жигулей“?»
потребуется не только вычислить новое, еще не существующеезначение Объема Продаж, для еще не наступившего июня 1997 г., но и предварительновычислить гипотетическое значение Объема продаж, за уже прошедший июнь 1996 г.
На первый взгляд, мы сами противоречим себе, говоря онеизменности данных, как основополагающем свойстве аналитической системы. Ноэто не так. Это кажущееся противоречие наоборот подчеркивает и усиливаетзначимость требований к неизменности Исторических данных. Сколько бы мы неупражнялись (например, при анализе: «а что… если..?») со значениемобъема продаж за июнь 1996 г., значения Исторических (реальных) данных должныоставаться неизменными. Конечно, предположение о неизменности не означаетневозможности исправления ошибок, если они были обнаружены в Историческихданных.
В свою очередь, к оперативным данным, отражающим состояниенекоторой предметной области в данный текущий момент времени, не применимытакие понятия, как прошлое или будущее. Для них существует единственное понятие- сейчас, а их основное назначение — адекватное детализированное отображениетекущих событий (изменений), происходящих в реальном мире. Например:
менеджер Петров продалеще одни «Жигули ВАЗ2106»;
менеджера Петроваперевели из Восточного филиала фирмы в Западный.
Вместе с тем изменчивость Оперативных данных ни в коемслучае не подразумевает их близость по свойствам к Прогнозируемым данным. Междуними существует коренное различие. Оперативным данным, в отличие отПрогнозируемых, присуще свойство общезначимости, иобычно все пользователи работают с одним и тем же экземпляром данных. Послетого как в оперативную систему заведены данные о том, что Петров продал ещеодин автомобиль, эта информация сразу же должна стать доступной всемзаинтересованным в ней пользователям. Причем до тех пор, пока это изменение незафиксировано, ни какой другой пользователь не имеет права изменять строку синформацией о продажах Петрова.
Существенно иная ситуация с Прогнозируемыми данными. Ониносят, скорее, личностный (индивидуальный) характер. Вполне реальна ситуация,когда коммерческий директор фирмы и управляющий региональным отделениемодновременно решили получить прогноз возможного объема продаж на 1997 г. дляПетрова. Однако каждый из них делает собственный прогноз. Каждый из них можетиспользовать свои функции прогнозирования, и, даже если применяется один и тотже метод (или функция), прогноз может основываться на различных историческихинтервалах, и результаты, по всей вероятности, будут различны. Поэтому каждыйиз них работает с собственным экземпляром Прогнозируемых данных (хотя этиданные и относятся формально к одной и той же личности, виду деятельности ивремени), и эти данные не должны смешиваться. Конечно, вполне вероятно, чтоодин из этих вариантов будет принят в качестве плановых показателей дляПетрова. Но после того, как Прогноз утвержден в качестве Плана, данные простоперейдут в другую категорию и станут Историческими.
Следует заметить, что в области информационных технологийвсегда существовало два взаимодополняющих друг друга направления развития:
· транзакционную или операционную) обработку данных;
· DSS).
И практически до настоящего времени, когда говорилось остремительном росте числа реализаций информационных систем, прежде всегоимелись в виду системы, предназначенные исключительно для оперативной обработкиданных. Именно для этого изначально и создавались и на это были ориентированыРСУБД, которые сегодня стали основным средством построения информационныхсистем самого различного масштаба и назначения. Но, являясь высокоэффективнымсредством реализации систем оперативной обработки данных, РСУБД оказались менееэффективными в задачах аналитической обработки.
Конечно, средствами традиционных РСУБД и на основанииданных, хранящихся в реляционной БД, можно построить заранее регламентированныйаналитический отчет (табл. 2) и даже Прогноз об ожидаемом объеме продажавтомобилей на следующий год.
Характеристика
Статический анализ
Динамический анализ
Типы вопросов
Сколько? Как? Когда?
Почему? Что будет если?
Время отклика
Не регламентируется
Секунды
Типичные операции
Регламентированный отчет, диаграмма
Последовательность интерактивных отчетов, диаграмм, экранных форм; динамическое изменение уровней агрегации и срезов данных
Уровень аналитических требований
Средний
Высокий
Тип экранных форм
В основном определенный заранее, регламентированный
Определяемый пользователем
Уровень агрегации данных
Детализированные и суммарные
В основном суммарные
Возраст данных
Исторические и текущие
Исторические, текущие и прогнозируемые
Типы запросов
В основном предсказуемые
Непредсказуемые, от случаю к случаю
Назначение
Работа с историческими и текущими данными, регламентированная аналитическая обработка и построение прогнозов
Работа с историческими, текущими и прогнозируемыми данными. Многопроходный анализ, моделирование
Таблица2. (Сравнение характеристик статического (регламентированного) идинамического анализа).
Но, как правило, после просмотра такого отчета упользователя (аналитика) появится не готовый ответ, а новая серия вопросов.Однако, если бы ему захотелось получить ответ на новый вопрос, он может ждатьего часы, а иногда и дни. Обычно каждый новый непредусмотренный заранее запросдолжен быть сначала формально описан, передан программисту, запрограммирован и,наконец, выполнен. Но после того, как аналитик получит долгожданный ответ,достаточно часто оказывается, что решение не могло ждать и оно уже принято, иличто случается еще чаще, произошло взаимное непонимание и получен ответ на несовсем тот вопрос. Впрочем, не намного меньшее время затрачивается и наполучение ответа и на заранее описанный и запрограммированный запрос.
Более того, для решения большинства аналитических задач,скорее всего, потребуется использование внешних по отношению к РСУБД,специализированных инструментальных средств. Выполнение большинствааналитических функций (например построение прогноза) невозможно безпредположения об упорядоченности данных. Но в РСУБД предполагается, что данныев БД не упорядочены (или, более точно, упорядочены случайным образом).Естественно, здесь имеется возможность после выборки данных из БД выполнить ихсортировку и затем аналитическую функцию. Но это потребует дополнительныхзатрат времени на сортировку. Сортировка должна будет проводиться каждый разпри обращении к этой функции, и, самое главное, такая функция может бытьопределена и использована только во внешнем по отношению к РСУБДпользовательском приложении и не может быть встроенной функцией языка SQL.
Не менее важно и то, что многие критически необходимые дляоперативных систем функциональные возможности, реализуемые в РСУБД, являютсяизбыточными для аналитических задач. Например, в аналитических системах (табл.3) данные обычно загружаются достаточно большими порциями из различных внешнихисточников (оперативных БД, заранее подготовленных плоских файлов, электронныхтаблиц). И, как правило, время и последовательность работ по загрузке,резервированию и обновлению данных могут быть спланированы заранее. Поэтому втаких системах обычно не требуются и, соответственно, не предусматриваются,например, развитые средства обеспечения целостности, восстановления иустранения взаимных блокировок и т.д. А это не только существенно облегчает иупрощает сами средства реализации, но и значительно снижает внутренниенакладные расходы и, следовательно, повышает производительность при выполненииих основной целевой функции — поиске и выборке данных.
Характеристика
Оперативные
Аналитические
Частота обновления
Высокая частота, маленькими порциями
Малая частота, большими порциями
Источники данных
В основном внутренние
В основном внешние (по отношению к аналитической системе)
Возраст данных
Текущие (за период от нескольких месяцев до одного года)
В основном исторические (за период в несколько лет, десятки лет) и прогнозируемые
Уровень агрегации данных
Детализированные данные
В основном агрегированные данные
Назначение
Фиксация, оперативный поиск и обработка данных
Работа с историческими данными, аналитическая обработка, прогнозирование и моделирование
Таблица3. (Характеристики данных в системах, ориентированных на оперативную ианалитическую обработку данных).
Многомерная модель данных
«Многомерный взгляд на данные наиболее характерен дляпользователя, занимающегося анализом данных» — это утверждение сегоднястало уже почти аксиомой. Однако, что такое многомерное представление, откудапоявляется многомерность в трехмерном мире, чем оноотличается и чем оно лучше ставшего уже привычным реляционного представления? Инаконец, откуда среди нас появились люди, мыслящие в четырех и болееизмерениях, и как это им удается — именно эти вопросы возникают практически улюбого, впервые прочитавшего это утверждение.
На самом деле все сказанное в этом утверждении — чистаяправда, и пользователю, занимающемуся анализом, действительно присуща многомерность мышления. Весь вопрос в том, что понимать подИзмерением.
Двухмерноепредставление данных конечному пользователю
Достаточно очевидно, что даже при небольших объемах данныхотчет, представленный в виде двухмерной таблицы (Модели автомобиля по оси Y иВремя по оси X), нагляднее и информативнее отчета с реляционной построчнойформой организации (рис. 1).
Реляционная модель
Модель
Месяц
Объем
«Жигули»
Июнь
12
«Жигули»
Июль
24
«Жигули»
Август
5
«Москвич»
Июнь
2
«Москвич»
Июль
18
«Волга»
Июль
19
Многомерная модель
Июнь
Июль
Август
«Жигули»
12
24
5
«Москвич»
2
18
No
«Волга»
No
19
No
Рисунок1. (Реляционная и многомерная модели представления данных).
А теперь представим, что у нас не три модели, а 30 и не три,а 12 различных месяцев. В случае построчного (реляционного) представления мыполучим отчет в 360 строк (30х12), который займет не менее 5-6 страниц. Вслучае же многомерного (в нашем случае двухмерного) представления мы получимдостаточно компактную таблицу 12 на 30, которая вполне уместится на однойстранице и которую, даже при таком объеме данных, можно реально оценивать ианализировать.
И когда говорится о многомерной организации данных, вовсе неподразумевается то, что данные представляются конечному пользователю (визуализируются)в виде четырех или пятимерных гиперкубов. Это невозможно, да и пользователюболее привычно и комфортно иметь дело с двухмерным табличным представлением идвухмерной бизнес-графикой.
Закономерен вопрос: «Где же здесь многомерность,откуда она берется и куда исчезает?» Ответ прост. Когда говорится о многомерности, имеется в виду не многомерностьвизуализации, а многомерное представление при описании структур данных иподдержка многомерности в языках манипулированияданными.
Многомерное представлениепри описании структур данных
Основными понятиями, с которыми оперирует пользователь ипроектировщик в многомерной модели данных, являются:
· Dimension);
· Cell).
Иногда вместо термина «Ячейка» используется термин«Показатель» (Measure).
Измерение — это множество однотипных данных, образующих однуиз граней гиперкуба. Например — Дни, Месяцы, Кварталы, Годы — это наиболеечасто используемые в анализе временные Измерения. Примерами географическихизмерений являются: Города, Районы, Регионы, Страны и т.д.
В многомерной модели данных Измерения играют роль индексов,используемых для идентификации конкретных значений (Показателей), находящихся вЯчейках гиперкуба.
В свою очередь, Показатель — это поле (обычно цифровое),значения которого однозначно определяются фиксированным набором Измерений.В зависимости от того, как формируютсяего значения, Показатель может быть определен, как:
· Variable)- значения таких Показателей один раз вводятся из какого-либо внешнегоисточника или формируются программно и затем в явном виде хранятся вмногомерной базе данных (МБД);
· Formula) — значения таких Показателей вычисляются по некоторой заранее специфицированнойформуле. То есть для Показателя, имеющего тип Формула, в БД хранится не егозначения, а формула, по которой эти значения могут быть вычислены.
Заметим, что это различие существует только на этапепроектирования и полностью скрыто от конечных пользователей.
В примере на рис. 1 каждое значение поля Объем продажоднозначно определяется комбинацией полей:
Модель автомобиля;
Месяц продаж.
Но в реальной ситуации для однозначной идентификациизначения Показателя, скорее всего, потребуется большее число измерений,например:
Модель автомобиля;
Менеджер;
Время (например Год).
Измерения:
Время (Год) — 1994, 1995, 1995
Менеджер — Петров, Смирнов, Яковлев
Показатель:
Объем Продаж
И в терминах многомерной модели речь будет идти уже не одвухмерной таблице, а о трехмерном гиперкубе:
первое Измерение — Модель автомобиля;
второе Измерение — Менеджер, продавший автомобиль;
третье Измерение — Время (Год);
на пересечении граней которого находятся значения ПоказателяОбъем продаж.
Заметим, что, в отличие от Измерений, не все значенияПоказателей должны иметь и имеют реальные значения. Например, Менеджер Петров в1994 г. мог еще не работать в фирме, и в этом случае все значения ПоказателяОбъем продаж за этот год будут иметь неопределенные значения.
Гиперкубические и поликубическиемодели данных
В различных МСУБД используются два основных вариантаорганизации данных:
· Гиперкубическаямодель;
· Поликубическая модель.
В чем состоит разница? Системы, поддерживающие Поликубическую модель (примером является Oracle Express Server), предполагают, что в МБД может быть определенонесколько гиперкубов с различной размерностью и с различными Измерениями вкачестве их граней. Например, значение Показателя Рабочее Время Менеджера,скорее всего, не зависит от Измерения Модель Автомобиля и однозначноопределяется двумя Измерениями: День и Менеджер. В Поликубическоймодели в этом случае может быть объявлено два различных гиперкуба:
Двухмерный — для Показателя Рабочее Время Менеджера;
Трехмерный — для Показателя Объем Продаж.
В случае же Гиперкубической моделипредполагается, что все Показатели должны определяться одним и тем же наборомИзмерений. То есть только из-за того, что Объем Продаж определяется тремяИзмерениями, при описании Показателя Рабочее Время Менеджера придется такжеиспользовать три Измерения и вводить избыточное для этого Показателя ИзмерениеМодель Автомобиля.
Операцииманипулирования Измерениями
Формирование«Среза». Пользователя редко интересуют все потенциально возможныекомбинации значений Измерений. Более того, он практически никогда не работаетодновременно сразу со всем гиперкубом данных. Подмножество гиперкуба,получившееся в результате фиксации значения одного или более Измерений,называется Срезом (Slice). Например, если мыограничим значение Измерения Модель Автомобиля = «ВАЗ2108», тополучим подмножество гиперкуба (в нашем случае — двухмерную таблицу),содержащее информацию об истории продаж этой модели различными менеджерами вразличные годы.
Операция«Вращение». Изменение порядка представления (визуализации)Измерений (обычно применяется при двухмерном представлении данных) называетсяВращением (Rotate). Эта операция обеспечиваетвозможность визуализации данных в форме, наиболее комфортной для их восприятия.Например, если менеджер первоначально вывел отчет, в котором Модели автомобилейбыли перечислены по оси X, а Менеджеры по оси Y, он может решить, что такоепредставление мало наглядно, и поменять местами координаты (выполнить Вращениена 90 градусов).
Отношения иИерархические Отношения. В нашем примере значения Показателей определяютсятолько тремя измерениями. На самом деле их может быть гораздо больше и между ихзначениями обычно существуют множество различных Отношений (Relation)типа «один ко многим».
Например, каждый Менеджер может работать только в одномподразделении, а каждой модели автомобиля однозначно соответствует фирма,которая ее выпускает:
Менеджер->Подразделение;
Модель Автомобиля->Фирма-Производитель.
Заметим, что для Измерений, имеющих тип Время (таких какДень, Месяц, Квартал, Год), все Отношения устанавливаются автоматически, и ихне требуется описывать.
В свою очередь, множество Отношений может иметьиерархическую структуру — Иерархические Отношения (HierarchicalRelationships). Вот только несколько примеров такихИерархических Отношений:
День -> Месяц ->Квартал -> Год;
Менеджер ->Подразделение -> Регион -> Фирма -> Страна;
Модель Автомобиля-> Завод-Производитель -> Страна.
И часто более удобно не объявлять новые Измерения и затемустанавливать между ними множество Отношений, а использовать механизмИерархических Отношений. В этом случае все потенциально возможные значения изразличных Измерений объединяются в одно множество. Например, мы можем добавитьк множеству значений Измерения Менеджер («Петров»,«Сидоров», «Иванов», «Смирнов»), значенияИзмерения Подразделение («Филиал 1», «Филиал 2»,«Филиал 3») и Измерения Регион («Восток»,«Запад») и затем определить между этими значениями ОтношениеИерархии.
Операция Агрегации.С точки зрения пользователя, Подразделение, Регион, Фирма, Страна являютсяточно такими же Измерениями, как и Менеджер. Но каждое из них соответствуетновому, более высокому уровню агрегации значений Показателя Объем продаж. Впроцессе анализа пользователь не только работает с различными Срезами данных ивыполняет их Вращение, но и переходит от детализированных данных кагрегированным, т.е. производит операцию Агрегации (DrillUp). Например, посмотрев, насколько успешно в 1995 г.Петров продавал модели «Жигули» и «Волга», управляющийможет захотеть узнать, как выглядит соотношение продаж этих моделей на уровнеПодразделения, где Петров работает. А затем получить аналогичную справку поРегиону или Фирме.
Операция Детализации.Переход от более агрегированных к более детализированным данным называетсяоперацией Детализации (Drill Down).Например, начав анализ на уровне Региона, пользователь может захотеть получитьболее точную информацию о работе конкретного Подразделения или Менеджера.
Проектирование многомернойБД
Данная работа ни в коем случае не посвящена рассмотрениюметодологии проектирования МБД, и здесь излагаются только самые общие элементыподхода к процессу и способам проектирования. Тем не менее излагаемый подход нетолько позволит наиболее полно понять как достоинства, так и ограничениямногомерного подхода, но и послужит хорошей основой для быстрого построениясистем.
Определение вопросов
Основное назначение МСУБД — реализация систем,ориентированных на динамический, многомерный анализ исторических и текущихданных, анализ тенденций, моделирование и прогнозирование будущего. Причемтакие системы в большой степени ориентированы на обработку произвольных,заранее не регламентированных запросов, и при их разработке фактическиотсутствует этап проектирования регламентированных пользовательских приложений(наиболее ответственный и трудоемкий в традиционных оперативных системах).
Проектирование МБД обычно начинается с определения вопросов(табл. 4), с которыми конечные пользователи хотели бы обратиться к системе.Причем на этом этапе интерес представляют даже не сами тексты вопросов, апонимание того, о каких личностях, местах, событиях и объектах в нихспрашивается.
Подразделение
Менеджер
Временной интервал
Вопрос
Отдел
Петров
3 года
На сколько процентов увеличились продажи «Жигулей» в Западном регионе после январской рекламной кампании в еженедельнике «Западный Вестник»?
Финансовый отдел
Смирнов
5 лет
Какие региональные подразделения превысили в третьем квартале запланированные расходы на командировки и как это соотносится с ростом их прибыли (в абсолютных и относительных величинах)?
Коммерческий отдел
Левшин
10 лет
Какие два варианта скидок наиболее эффективны в Западном регионе в летний период при продаже автомобилей «Жигули», на основе данных за последние 10 лет?
Отдел развития бизнеса
Васильева
5 лет
Как повлияло на объемы продаж открытие двух новых отделений в Южном регионе и на какой процент могут увеличиться продажи в Северном регионе, если в этом году там будет открыто 3 новых офиса?
Таблица 4. (Список потенциальных вопросов менеджеров фирмы).
Рассмотрим в качестве примера вопрос сотрудникакоммерческого отдела («Какие два варианта скидок наиболее эффективны вЗападном регионе в летний перио