Добавил:
Upload Опубликованный материал нарушает ваши авторские права? Сообщите нам.
Вуз: Предмет: Файл:
конспект - модели данных.doc
Скачиваний:
9
Добавлен:
27.10.2018
Размер:
851.46 Кб
Скачать

Объектно-реляционная модель. Многомерная модель.

Одновременно с реляционной моделью данных появилась многомерная модель. Однако хоть идеи многомерной модели возникли одновременно с реляционной, но в ту пору практической реализации таких моделей не было. И лишь в 90-х годах ХХ века к ним стал проявляться интерес. Это было вызвано появлением статьи Э. Кодда, в которой он сформулировал 12 требований к системам класса OLAP (Online Analytical Processing – оперативная аналитическая обработка), связанных с возможностью представления и обработки многомерных массивов.

Информация в многомерной модели представляется в виде многомерных массивов, называемых гиперкубами. В одной базе данных, построенной на многомерной модели, может храниться множество таких кубов, на основе которых можно проводить совместный анализ показателей. Конечный пользователь в качестве внешней модели данных получает для анализа определенные срезы или проекции кубов, представляемые в виде обычных двумерных таблиц или графиков.

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

Агрегируемость данных означает рассмотрение и возможность анализа данных на разных уровнях обобщения: для пользователя, аналитика, руководителя.

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

Прогнозируемость данных предполагает задание функций прогнозирования и применение их к различным временным интервалам.

Многомерность модели данных – это, прежде всего, многомерное логическое представление структуры данных при их описании и в операциях манипулирования ими, а не многомерность их визуализации. По сравнению с реляционной моделью многомерная организация данных обладает более высокой информативностью. Для того чтобы убедиться в этом, рассмотрим многомерное представление данных и сопоставим его с реляционным (рис. 13-14).

В современных многомерных системах используется обычно два варианта (схемы) организации данных: гиперкубическая и поликубическая. В гиперкубической схеме все показатели определяются одним и тем же набором измерений и даже при наличии нескольких гиперкубов в базе все они имеют одинаковую размерность и совпадающие измерения. При поликубической организации в базе может быть определено несколько гиперкубов с различной размерностью и с различными измерениями в качестве граней. Примером поликубической системы является сервер Oracle Express Server.

Для многомерной модели применяются специальные операции: Срез, Сечение, Вращение, Агрегация, Детализация.

Срез – это подмножество гиперкуба, полученное в результате фиксации одного или нескольких измерений. Так, в нашем примере можно ограничить значение наименования продукта продуктом Сыр. В этом случае получим срез в виде двумерной таблицы выпуска этого продукта по кварталам года цехами предприятия (рис. 15).

Вращение изменяет порядок измерений при визуальном представлении данных. Вращение применяется обычно при двумерном представлении данных. Так, в примере на рис. 13 вращение приведет к изменению вида таблицы, так, что по оси ОХ будет Наименование продукта, а по оси OY – Выпуск по кварталам (таблица 10).

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

Агрегация и Детализация означают соответственно переход к более общему и более детальному представлению данных. Для понимания сути операции агрегации положим, что имеется гиперкуб, в котором кроме измерений, приведенных на рис. 13, имеются еще подразделение Участок. В этом случае в гиперкубе будет иерархия Цех – Участок. Допустим, в гиперекубе определено, сколько произведено продукции каждым из участков цеха 1. Тогда, поднимаясь на более высокую ступень иерархии, с помощью операции Агрегация можно определить выпуск и для всего цеха 1.

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

Многомерные модели поддерживают следующие системы: Essbase (фирма Arbor Software), Media Multi-matrix (фирма Speedware), Oracle Express Server (фирма Oracle), Cache (фирма InterSystems). Некоторые системы поддерживают одновременно реляционную и многомерную модель, например, Media/MR (фирма Speedware).

В связи со значительным усложнением приложений появилась новая модель – расширенная реляционная модель (Extended Relation Data Model –ERDM). Эта модель включила в себя основные достоинства объектно-ориентированной модели и одновременно унаследовала простоту структуры реляционных моделей, и потому стала называться объектно-реляционной моделью данных. В отличие от объектно-ориентированной модели (OODM) объектно-реляционная модель (ERDM) основана на стратегии реляционной модели, в то время как OODM модель основана на объектной стратегии. Исходя из этого, модель ERDM наиболее приспособлена для бизнес-приложений, а модель OODM используется в специальных инженерных и научных приложениях. Некоторые специалисты полагают, что в будущем произойдет слияние OODM и ERDM моделей.

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

· отсутствие унифицированной теории, которая есть в реляционных моделях;

· отсутствие формальной методологии проектирования баз данных, как нормализация в реляционных базах;

· отсутствие специальных средств создания запросов;

· отсутствие общих правил определения целостности и др.