Реализации olap
Исторически первой многомерной системой управления базами данных, по существу являющейся OLAP-реализацией, считается система Express, разработанная в 1970 году компанией IRI (позднее права на продукт были приобретены корпорацией Oracle и превращён в OLAP-опцию для Oracle Database)[3]. Термин OLAP ввёл Эдгар Кодд в публикации в журнале Computerworld в 1993 году[4], в которой он предложил 12 принципов аналитической обработки, по аналогии с 12 правилами для реляционных баз данных, сформулированными им же десятилетием ранее, в качестве референтного продукта, удовлетворяющего предложенным принципам, Кодд указал систему Essbase компании Arbor (поглощённой в 1997 году компанией Hyperion, которую, в свою очередь, в 2007 году купила Oracle). Примечательно, что впоследствии публикация была изъята из архивовComputerworld из-за возможного конфликта интересов, так как Кодд позднее оказывал консультационные услуги для Arbor[5].
С точки зрения реализации делятся на «физическую OLAP» и «виртуальную» (реляционную, англ. Relational OLAP, ROLAP). «Физическая», в свою очередь, в зависимости от реализации подразделяется на многомерную (англ. Multidimensional OLAP, MOLAP) и гибридную — (англ. Hybrid OLAP,HOLAP).
№3 Модели данных
Иерархическая модель данных
Иерархическая модель данных строится по принципу иерархии типов объектов, то есть один тип объекта является главным, а остальные находятся на низших уровнях иерархии - подчиненными.
В повседневной жизни мы часто имеем дело с иерархическими структурами. Например, структура предприятия, генеалогическое дерево. Иерархическая древовидная структура строится из узлов и ветвей (дерево перевернутое).
Узел - это совокупность атрибутов данных, описывающих некоторый объект.
Корень - это наивысший узел.
Иерархическая модель данных организует данные в виде иерархической древовидной структуры. Каждый экземпляр корневого узла образует начало записи логической базы данных, то есть иерархическая база данных состоит из нескольких деревьев.
Узел является совокупностью атрибутов, описывающих объект. Корневой узел - это главный тип объекта. Корневой узел находится на первом уровне. Зависимые узлы (подчиненные виды объектов) находятся на 2-ом, 3-ем и т.д. уровнях (рис. 3.4).
Рисунок 3.4. Иерархическая модель данных
Иерархическая древовидная структура удовлетворяет следующим условиям:
- иерархия неизменно начинается с корневого узла;
- каждый узел состоит из одного или нескольких атрибутов, которые описывают объект в данном узле;
- на низших уровнях могут находиться зависимые узлы. Узел, находящийся на предшествующем уровне, является исходным для новых зависимых узлов. Зависимые узлы могут добавляться как в вертикальном, так и в горизонтальном направлениях без всяких ограничений. Исключение - 1-ый узел-корень.
- каждый узел, находящийся на уровне 2, соединен с одним и только одним узлом на уровне 1. Каждый узел, находящийся на уровне 3, соединен с одним и только одним узлом, находящемся на уровне 2 и т.д.
Вариант иерархической модели данных "Госпиталь" (рис. 3.5).
Уровень 1 Пациент (корневой(исходный) тип узла)
Номер пациента |
Имя пациента |
Адрес памяти |
Уровень 2 Хирург+Операция+Препарат
Номер патента |
Имя хирурга |
Дата операции |
Операция |
Препарат |
Побочный эффект |
Рисунок 3.5. Иерархическая модель «Пациент сделал операцию»
Объекты "хирург", "операция", "препарат" объединены в порожденный узел. Для каждого пациента может быть две операции, тогда на втором уровне будут 2 экземпляра.
Может быть другая версия иерархической модели.
Рисунок 3.6. Рисунок 3.5. Иерархическая модель «Хирург и пациент»
Достоинства модели:
- простота понимания и использования;
- обеспечение определенного уровня независимости данных. С помощью данной модели можно реализовать различные представления пользователей.
- Простота оценки операционных характеристик благодаря заранее заданным взаимосвязям.
Недостатки:
- практически невозможно реализовать взаимосвязь «многие ко многим», т.к. структура становится слишком громоздкой;
- сложности с операциями включения и исключения данных из-за строгой иерархичности;
- доступ к любому узлу происходит только через исходный узел.
Сетевая модель данных
В сетевой модели данных понятие главного и подчиненного объектов несколько расширены. Любой объект может быть главным и подчиненным. Один и тот же объект может выступать и в роли "владельца" и в роли "члена набора" (рис. 3.7).
Рисунок 3.7. Сетевая модель данных
В сетевой модели данных объекты предметной области объединяются в "сеть". Графически сеть представляется в виде прямоугольников и стрелок. Направленные стрелки соединяют два или более типов записей и служат для изображения типов наборов. Каждый тип записей может содержать нуль, один или несколько атрибутов (элемент данных, поле). В базе данных может иметься один или несколько экземпляров записи некоторого типа.
Владелец набора - тип записи, из которой исходит стрелка.
Член набора - тип записи, к которой направлена стрелка.
Набор - это поименованная совокупность связанных записей. Экземпляр набора существует после запоминания записи-владельца.
Тип набора представляет логическую взаимосвязь "один ко многим". Стрелка, направленная от владельца набора к его члену обозначает тип набора.
Набор может быть реализован несколькими способами. В данной работе будут рассмотрены некоторые из них. Это организация набора в виде кольцевой структуры и сингулярные наборы.
Реализация набора в виде кольцевой структуры (рис.3.8):
Рисунок 3.8. Сетевая модель в виде кольцевой структуры
Экземпляр набора ПАЦИЕНТ-ПЕРЕНЕС-ОПЕРАЦИЮ содержит один экземпляр записи-владельца и два экземпляра записи-члена.
Организация набора в виде иерархической структуры, следовательно, иерархическая модель является частным случаем сетевой модели.
Между ПАЦИЕНТОМ и ХИРУРГОМ существует взаимосвязь «многие ко многим». Для преобразования этой взаимосвязи в две взаимосвязи «один ко многим», воспользуемся в качестве связки записью ОПЕРАЦИЯ, которая характеризуется датой операции, описанием операции, препаратом, назначенным после операции и побочным эффектом.
ПАЦИЕНТ-ПЕРЕНЕС-ОПЕРАЦИЮ - запись-владелец ПАЦИЕНТ, запись-член- ОПЕРАЦИЯ.
ХИРУРГ-ОПРЕАЦИЯ - запись-владелец ХИРУРГ, запись-член ОПЕРАЦИЯ (рис. 3.9).
Рисунок 3.9. Сетевая модель в виде сингулярного набора
При использовании сингулярного набора необходимо учитывать следующее:
- в базе данных может содержаться только один экземпляр сингулярного набора;
- с помощью сингулярного набора можно объединить записи, у которых нет естественного владельца;
- в сингулярный набор можно включать записи, которые при вводе в базу данных не имеют владельца, но могут его приобрести впоследствии. Тогда определенная запись исключается из сингулярного набора и включается в экземпляр набора с новым владельцем.
Для сетевых моделей характерно то, что программист, который будет работать с логической моделью данных этого типа должен хорошо знать "навигацию" среди различных данных.
Основным недостатком сетевой модели данных является сложность ее реализации и большое количество терминов.