Концепция централизованного управления данными

Централизованные системы БД с сетевым доступом строятся на основе наиболее перспективной архитектуры - архитектуры клиент-сервер, которая предполагает наличие

· компьютерной сети и

· распределенной БД, включающей

- корпоративную базу данных (КБД, размещается на компьютере-сервере) и

- персональные базы данных (ПБД, размещаются на компьютерах сотрудников подразделений, являющихся клиентами КБД).

Сервером определенного ресурса в компьютерной сети называется компьютер (программа), управляющий этим ресурсом.

Клиентом называется компьютер (программа), использующий этот ресурс сервера.

В качестве ресурса компьютерной сети могут выступать:

- базы данных,

- файловые системы,

- службы печати,

- почтовые службы.

Тип сервера определяется видом ресурса, которым он управляет (если управляемым ресурсом является БД, то соответствующий сервер называется сервером базы данных).

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

Архитектура клиент-сервер допускает различные варианты реализации:

1. распределенная ИС с применением файл-сервера (рисунок 10) - исторически появились первыми. Называется архитектура файл-сервер.

 

 

 

Рисунок 10 - Распределенные ИС с применением файл-сервера

 

Архитектура предполагает использование выделенного компьютера в качестве сервера файлов для хранения файлов БД, которые по запросу пользователей копируются на их локальные компьютеры, где и производится их обработка. После завершения обработки измененные файлы данных копируются обратно на файл-сервер, Другие пользователи, в свою очередь, могут снова использовать эти данные. Кроме того, каждый пользователь может создавать на локальном компьютере свои собственные БД, используемые им монопольно.

Недостатки такого варианта архитектуры:

- высокая интенсивность передачи обрабатываемых данных, при которой зачастую передаются избыточные данные: вне зависимости от того, сколько записей из БД требуется пользователю, файлы БД передаются целиком;

- производительность системы резко падает с ростом числа пользователей.

 

2. распределенная ИС с использованием сервера БД (рисунок 11).

 

 

Рисунок 11 - Распределенная ИС с использованием сервера БД

 

При такой архитектуре сервер БД обеспечивает не только хранение данных, но и выполнение основного объема действий по их обработки. Формируемые пользователем или приложением запросы поступают к серверу БД в виде инструкций структурированного языка запросов SQL (Structured Query Language), который был специально разработан для этих целей. Сервер БД выполняет поиск, извлечение и обработку нужных данных и затем передает результат на компьютер пользователя.

Достоинством такого подхода в сравнении предыдущим является заметно меньший объем передаваемых данных.

Создаются и управляются ПБД и приложения, работающие с ними, с помощью различных СУБД (например, Access или Visual FoxPro фирмы Microsoft, Paradox фирмы Borland и др.).

Корпоративная БД создается, поддерживается и функционирует под управлением сервера БД (например, Microsoft SQL Server или Oracle Server).

В зависимости от размеров организации и особенностей решаемых задач ИС может иметь одну из следующих конфигураций:

· компьютер-сервер, содержащий КБД и ПБД;

· компьютер-сервер и персональные компьютеры с ПБД;

· несколько компьютеров-серверов и персональных компьютеров с ПБД.

Преимущества архитектуры клиент-сервер:

1. использование этой архитектуры дает возможность постепенного наращивания ИС предприятия, во-первых, по мере развития предприятия; во-вторых, по мере развития самой ИС;

2. разделение общей БД на корпоративную БД и персональные БД позволяет уменьшить сложность проектирования БД по сравнению с централизованным вариантом, а значит снизить вероятность ошибок при проектировании и стоимость проектирования;

3. важнейшим достоинством применения БД в ИС является обеспечение независимости данных от прикладных программ. Это дает возможность пользователям не заниматься проблемами представления данных на физическом уровне: размещения данных в памяти, методов доступа к ним и т. д. Такая независимость достигается поддерживаемым СУБД многоуровневым представлением данных в БД (на логическом – пользовательском, и физическом уровнях. Благодаря СУБД и наличию логического уровня представления данных обеспечивается отделение концептуальной (понятийной) модели БД от ее физического представления в памяти ЭВМ).

 

Модели данных

Хранимые в базе данные имеют определенную логическую структуру - иными словами, описываются некоторой моделью представления данных (моделью данных), поддерживаемой СУБД. М одель данных является ядром любой БД, с помощью которой могут быть представлены объекты, предметные области и взаимосвязи между ними.

Модель данных – совокупность структур данных и операции их обработки.

К числу классических относятся следующие модели данных:

· иерархическая,

· сетевая,

· реляционная.

Кроме того, в последние годы появились и стали более активно внедряться на практике следующие модели данных:

· постреляционная,

· объектно-ориентированная,

· многомерная.

Разрабатываются также всевозможные системы, основанные на других моделях данных, расширяющих известные модели. В их числе можно назвать

- объектно-реляционные,

- дедуктивно-объектно-ориентированные,

- семантические,

- концептуальные и

- ориентированные модели.

Некоторые из этих моделей служат для интеграции баз данных, баз знаний и языков программирования.

В некоторых СУБД поддерживается одновременно несколько моделей данных. Например, в системе ИНТЕРБАЗА для приложений применяется сетевой язык манипулирования данными, а в пользовательском интерфейсе реализованы языки SQL и QBE.

Иерархическая и сетевая модели данных стали применяться в системах управления БД в начале 60–х годов. В начале 70–х годов была предложена реляционная модель данных (Эдгар Кодд), которая является на сегодняшний момент самой распространенной.

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

1. Иерархическая модель данных. Представляет собой совокупность элементов, связанных между собой по определенным правилам. Иерархическая модель данных строится по принципу иерархии типов объектов, то есть один тип объекта является главным, а остальные, находящиеся на низших уровнях иерархии, – подчиненными. Между главным и подчиненными объектами устанавливается взаимосвязь «один ко многим». Упрощенно представление связей между данными в иерархической модели показано на рисунке 12.

 

 

Рисунок 12 - Представление связей в иерархической модели

 

Основные понятия иерархической структуры:

- узел (элемент) – совокупность атрибутов данных, описывающих некоторый объект (на схеме это вершины графа). Каждый узел, находящийся на более низком уровне, связан только с одним узлом, находящимся на более высоком уровне. Узел может иметь только одного родителя. Иерархическое дерево имеет только одну вершину (корень), не подчиненную никакой другой вершине и находящуюся на самом верхнем (первом) уровне.

- уровень;

- связь.

Узлы и ветви образуют иерархическую древовидную структуру.

Наивысший в иерархии узел называется корневым. (это главный тип объекта).

Корневым называется тип, который имеет подчиненные типы и сам не является подтипом.

Подчиненный тип (подтип) является потомком по отношению к типу, который выступает для него в роли предка (родителя).

Потомки одного и того же типа являются близнецами по отношению друг к другу.

Корневой узел находится на первом уровне. Зависимые узлы (подчиненные типы объектов) находятся на втором, третьем и др. уровнях.

Объекты, связанные иерархическими отношениями, образуют ориентированный граф.

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

Тип "дерево" является составным. Он включает в себя подтипы ("поддеревья"), каждый из которых, в свою очередь, является типом "дерево". Каждый из типов "дерево" состоит из одного "корневого" типа и упорядоченного набора (возможно пустого) подчиненных типов. Каждый из элементарных типов, включенных в тип "дерево", является простым или составным типом "запись". Простая "запись" состоит из одного типа, например, числового, а составная "запись" объединяет некоторую совокупность типов, например, целое, строку символов и указатель (ссылку).

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

Иерархическая БД представляет собой упорядоченную совокупность экземпляров данных типа "дерево" (деревьев), содержащих экземпляры типа "запись" (записи). Часто отношения родства между типами переносят на отношения между самими записями. Поля записей хранят собственно числовые или символьные значения, составляющие основное содержание БД. Обход всех элементов иерархической БД обычно производится сверху вниз и слева направо.

Для организации физического размещения иерархических данных в памяти ЭВМ могут использоваться следующие группы методов:

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

· представление связными линейными списками (методы, использующие указатели и справочники).

К основным операциям манипулирования иерархически организованными данными относятся следующие:

· поиск указанного экземпляра (элемента) БД;

· переход от одного дерева к другому;

· переход от одной записи к другой внутри дерева (например, к следующей записи типа Сотрудники);

· вставка новой записи в указанную позицию;

· удаление текущей записи и т. д.

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

Достоинства:

- эффективное использование памяти;

- неплохие показатели временных затрат на выполнение операций;

- модель удобна для работы с иерархически упорядоченной информацией, т.е. с теми данными, которые сами по себе имеют иерархическую структуру.

Недостатки:

- громоздкость для обработки информации с достаточно сложными логическими связями;

- сложность понимания для обычного пользователя,

- сложность физической реализации для больших древовидных структур.

На иерархической модели данных основано сравнительно ограниченное количество СУБД, в числе которых можно назвать зарубежные системы IMS, PC/Focus, Team-Up и Data Edge, а также отечественные системы Ока, ИНЭС и МИРИС.

IMS (Information Management System) фирмы IBM является типичным представителем иерархической системы. Первая версия появилась в 1968 г.

2. Сетевая модель данных. Данные в сетевой модели представлены в виде коллекции записей, а связи – в виде наборов. Сетевая модель данных позволяет отображать разнообразные взаимосвязи элементов данных в виде произвольного графа, обобщая тем самым иерархическую модель данных (рисунок 13). Наиболее полно концепция сетевых БД впервые была изложена в Предложениях группы КОДАСИЛ (KODASYL).

 

 

Рисунок 13 - Представление связей в сетевой модели

 

Сетевая модель – это граф с записями в виде узлов графа и наборами в виде его ребер. Графы произвольной структуры отражают взаимосвязи между данными в этой модели.

Для описания схемы сетевой БД используется две группы типов: "запись" и "связь". Тип "связь" определяется для двух типов "запись": предка и потомка. Переменные типа "связь" являются экземплярами связей.

Сетевая БД состоит из набора записей и набора соответствующих связей. На формирование связи особых ограничений не накладывается. Если в иерархических структурах запись-потомок могла иметь только одну запись-предка, то в сетевой модели данных запись-потомок может иметь произвольное число записей-предков (сводных родителей).

Пример схемы простейшей сетевой БД показан на рисунке 14. Типы связей здесь обозначены надписями на соединяющих типы записей линиях.

 

Рисунок 14 - Пример схемы сетевой БД

 

В различных СУБД сетевого типа для обозначения одинаковых по сути понятий зачастую используются различные термины. Например, такие, как элементы и агрегаты данных, записи, наборы, области и т. д.

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

К числу важнейших операций манипулирования данными баз сетевого типа можно отнести следующие:

· поиск записи в БД;

· переход от предка к первому потомку;

· переход от потомка к предку;

· создание новой записи;

· удаление текущей записи;

· обновление текущей записи;

· включение записи в связь;

· исключение записи из связи;

· изменение связей и т. д.

Достоинства сетевой модели данных:

- эффективное использование затрат памяти (ресурсы) при манипулировании данными;

- возможность эффективной реализации по оперативности;

- большие возможности в смысле допустимости образования произвольных связей.

Недостатки:

- высокая сложность и жесткость схемы БД, построенной на ее основе,

- сложность для понимания и выполнения обработки информации в БД обычным пользователем,

- сложность физической реализации;

- жесткость связи между элементами данных накладывает ряд ограничений на удобство манипуляции данными;

- ослаблен контроль целостности связей вследствие допустимости установления произвольных связей между записями.

Системы на основе сетевой модели не получили широкого распространения на практике. Наиболее известными сетевыми СУБД являются следующие: IDMS, db VistaIII, СЕТЬ, СЕТОР и КОМПАС.

3. Реляционная модель данных. Реляционная модель данных предложена сотрудником фирмы IBM Эдгаром Коддом и основывается на понятии отношение (relation).

Наглядной формой представления отношения является привычная для человеческого восприятия двумерная таблица.

Реляционная модель ориентирована на организацию данных в виде двумерных таблиц. Таблица имеет строки (записи) и столбцы (колонки). Каждая строка таблицы имеет одинаковую структуру и состоит из полей. На рисунке 15 приведен пример представления отношения СОТРУДНИК.

 

ФИО	Отдел	Должность	Д_Рождения
Петров		начальник отдела	12.07.1972
Алексеева		инженер	19.01.1984
Соловьев		лаборант	22.09.1991

 

Рисунок 15 – Представление отношения СОТРУДНИК

 

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

Сущность есть объект любой природы, данные о котором хранятся в БД. Данные о сущности хранятся в отношении.

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

Строкам таблицы соответствуют кортежи, а столбцам - атрибуты отношения, домены, поля.

Домен – общая совокупность значений, из которой берется реальное значение атрибутов.

К отношениям можно применять систему операций, позволяющую получать одни отношения из других. Например, результатом запроса к реляционной БД может быть новое отношение, вычисленное на основе имеющихся отношений. Поэтому можно разделить обрабатываемые данные на хранимую и вычисляемую части.

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

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

Реляционные модели характеризуются

- простотой структуры данных,

- удобным для пользователя табличным представлением и

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

Каждая реляционная таблица представляет собой двумерный массив и обладает следующими свойствами:

- все столбцы в таблице – однородные (имеют одинаковый тип);

- каждый столбец имеет уникальное имя;

- одинаковые строки (записи) в таблице отсутствуют;

- порядок следования строк и столбцов может быть произвольным.

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

Чтобы связать две реляционные таблицы, необходимо ключ первой таблицы ввести в состав ключа второй таблицы (возможно совпадение ключей), в противном случае нужно ввести в структуру первой таблицы внешний ключ – ключ второй таблицы.

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

Достоинства:

- простота, понятность для пользователя,

- удобство физической реализации на ЭВМ,

- высокая эффективность обработки данных.

Недостатки:

- отсутствие стандартных средств идентификации каждой отдельной записи,

- сложность описания иерархических и сетевых связей.

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

Примерами зарубежных реляционных СУБД для ПЭВМ являются следующие:

· dBaseIII Plus и dBase IY (фирма Ashton-Tate)

· DB2 (IBM)

· R:BASE (Microrim)

· FoxPro ранних версий и FoxBase (Fox Software)

· Paradox и dBASE for Windows (Borland)

· FoxPro более поздних версий

· Visual FoxPro и Access (Microsoft)

· Clarion (Clarion Software)

· Ingres (ASK Computer Systems)

· Oracle (Oracle).

К отечественным СУБД реляционного типа относятся системы: ПАЛЬМА (ИК АН УССР), а также система HyTech (МИФИ).

Надо отметить, что последние версии реляционных СУБД имеют некоторые свойства объектно-ориентированных систем. Такие СУБД часто называют объектно-реляционными. Примером такой системы можно считать продукты Oracle 8.x. Системы предыдущих версий вплоть до Oracle 7.x считаются "чисто" реляционными.

4. Постреляционная модель данных. Классическая реляционная модель предполагает неделимость данных, хранящихся в полях записей таблиц.

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

Постреляционная модель

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

На рисунке 16 на примере информации о накладных и товарах для сравнения приведено представление одних и тех же данных с помощью реляционной (а) и постреляционной (б) моделей.

Таблица НАКЛАДНЫЕ содержит данные о номерах накладных (НОИЕР НАКЛАДНОЙ) и номерах покупателей (НОМЕР ПОКУПАТЕЛЯ). В таблице НАКЛАДНЫЕ_ТОВАРЫ содержатся данные о каждой из накладных: НОМЕР НАКЛАДНОЙ, НАЗВАНИЕ ТОВАРА и КОЛИЧЕСТВО ТОВАРА. Таблица НАКЛАДНЫЕ связана с таблицей НАКЛАДНЫЕ_ТОВАРЫ по полю НОМЕР НАКЛАДНОЙ.

 

а) НАКЛАДНЫЕ

Номер накладной	Номер покупателя

 

НАКЛАДНЫЕ_ТОВАРЫ

 

Номер накладной	Название товара	Количество товара
	Сыр
	Рыба
	Лимонад
	Сок
	Печенье
	Йогурт

 

б) НАКЛАДНЫЕ

 

Номер накладной	Номер покупателя	Товар	Количество товара
		Сыр
		Рыба
		Лимонад
		Сок
		Печенье
		Йогурт

 

Рисунок 16 - Структуры данных реляционной и постреляционной моделей

 

 

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

2) поддерживает ассоциированные многозначные поля (множественные группы). Совокупность ассоциированных полей называется ассоциацией. При этом в строке первое значение одного столбца ассоциации соответствует первым значениям всех других столбцов ассоциации. Аналогичным образом связаны все вторые значения столбцов и т. д.;

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

Так как постреляционная модель допускает хранение в таблицах ненормализованных данных, возникает проблема обеспечения целостности и непротиворечивости данных. Эта проблема решается включением в СУБД механизмов, подобных хранимым процедурам в клиент-серверных системах.

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

Достоинства постреляционной модели:

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

- обеспечение высокой наглядности представления информации,

- обеспечение повышенной эффективности обработки информации.

Недостаток:

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

Постреляционная модель данных поддерживается СУБД uniVers, системами Bubba и Dasdb

5. Многомерная модель. Многомерный подход к представлению данных в базе появился практически одновременно с реляционным, но реально работающих многомерных СУБД (МСУБД) до настоящего времени было очень мало. С середины 90-х годов интерес к ним стал приобретать массовый характер.

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

В развитии концепций ИС можно выделить следующие два направления:

· системы оперативной (транзакционной) обработки. Транзакция - последовательность операций пользователя над БД, которая сохраняет ее логическую целостность;

· системы аналитической обработки (системы поддержки принятия решений).

Реляционные СУБД предназначались для информационных систем оперативной обработки информации и в этой области были весьма эффективны. В системах аналитической обработки они показали себя несколько неповоротливыми и недостаточно гибкими. Более эффективными здесь оказываются многомерные СУБД (МСУБД).

Многомерные СУБД являются узкоспециализированными СУБД, предназначенными для интерактивной аналитической обработки информации.

Основные понятия, используемые в этих СУБД:

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

- историчность данных предполагает:

o обеспечение высокого уровня статичности (неизменности) собственно данных и их взаимосвязей. Статичность данных позволяет использовать при их обработке специализированные методы загрузки, хранения, индексации и выборки;

o обязательность привязки данных ко времени. Временная привязка данных необходима для частого выполнения запросов, имеющих значения времени и даты в составе выборки. Необходимость упорядочения данных по времени в процессе обработки и представления данных пользователю накладывает требования на механизмы хранения и доступа к информации. Так, для уменьшения времени обработки запросов желательно, чтобы данные всегда были отсортированы в том порядке, в котором они наиболее часто запрашиваются;

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

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

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

Для иллюстрации на рисунке 17 приведены реляционное (а) и многомерное (б) представления одних и тех же данных об объемах продаж автомобилей.

а)

Модель	Месяц	Объем
"Жигули"	июнь
"Жигули"	июль
"Жигули"	август
"Москвич"	июнь
"Москвич"	июль
"Волга"	июль

 

 

б)

Модель	Июнь	Июль	Август
"Жигули"
"Москвич"			N
"Волга"	N		N

 

Рисунок 17 - Реляционное и многомерное представление данных

 

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

 

Рисунок 18 – Представление данных в виде гиперкуба

 

Основные понятия многомерных моделей данных:

· измерение (Dimension) - это множество однотипных данных, образующих одну из граней гиперкуба. Примерами наиболее часто используемых временных измерений являются Дни, Месяцы, Кварталы и Годы. В качестве географических измерений широко употребляются Города, Районы, Регионы и Страны. В многомерной модели данных измерения играют роль индексов, служащих для идентификации конкретных значений в ячейках гиперкуба;

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

В примере на рисунке 17 (б) каждое значение ячейки Объем продаж однозначно определяется комбинацией временного измерения (Месяц продаж) и Модели автомобиля. На практике зачастую требуется большее количество измерений. Пример трехмерной модели данных приведен на рисунке 19.

 

 

Рисунок 19 - Трехмерная модель представления данных

 

В существующих МСУБД используются два основных варианта (схемы) организации данных:

· гиперкубическая. В случае гиперкубической схемы предполагается, что все показатели определяются одним и тем же набором измерений. Это означает, что при наличии нескольких гиперкубов БД все они имеют одинаковую размерность и совпадающие измерения. Очевидно, в некоторых случаях информация в БД может быть избыточной (если требовать обязательное заполнение ячеек);

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

В случае многомерной модели данных применяется ряд специальных операций, к которым относятся: формирование "среза", "вращение", агрегация и детализация:

· формирование "среза" (Slice). "Срез" представляет собой подмножество гиперкуба, полученное в результате фиксации одного или нескольких измерений. Формирование "срезов" выполняется для ограничения используемых пользователем значений, так как все значения гиперкуба практически никогда одновременно не используются. Например, если ограничить значения измерения Модель автомобиля в гиперкубе (рисунок 19) маркой "Жигули", то получится двухмерная таблица продаж этой марки автомобиля различными менеджерами по месяцам;

· операция "вращение" (Rotate) применяется при двухмерном представлении данных. Суть ее заключается в изменении порядка измерений при визуальном представлении данных. Так, "вращение" двумерной таблицы, показанной на рисунке 17(б), приведет к изменению ее вида таким образом, что по оси Х будет марка автомобиля, а по оси Y - время.

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

· операции "агрегация" (Drill Up) и " детализация" (Drill Down) означают соответственно переход к более общему и к более детальному представлению информации пользователю из гиперкуба.

Для иллюстрации смысла операции "агрегация" предположим, что у нас имеется гиперкуб, в котором помимо измерений гиперкуба, приведенного на рисунке 19, имеются еще измерения: Подразделение, Регион, Фирма, Страна. Заметим, что в этом случае в гиперкубе существует иерархия (снизу вверх) отношений между измерениями: Менеджер, Подразделение, Регион, Фирма, Страна.

Пусть в описанном гиперкубе определено, насколько успешно в 1995 году менеджер Петров продавал автомобили "Жигули" и "Волга". Тогда, поднимаясь на уровень выше по иерархии, с помощью операции "агрегация" можно выяснить, как выглядит соотношение продаж этих же моделей на уровне подразделения, где работает Петров.

Достоинство многомерной модели данных:

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

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

Примерами систем, поддерживающими многомерные модели данных, являются Essbase (Arbor Software), Media Multi-matrix (Speedware), Oracle Express Server (Oracle) и Cache (InterSystems). Некоторые программные продукты, например Media/ MR (Speedware), позволяют одновременно работать с многомерными и с реляционными БД. В СУБД Cache, в которой внутренней моделью данных является многомерная модель, реализованы три способа доступа к данным: прямой (на уровне узлов многомерных массивов), объектный и реляционный.

6. Объектно–ориентированная модель. Моделью данных, привлекающей нарастающее внимание с конца 80-х гг., является объектная, или объектно-ориентированная модель.

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

Стандартизированная объектно-ориентированная модель описана в рекомендациях стандарта ODMG -93 (Object Database Management Group – группа управления объектно-ориентированными базами данных).

Основные понятия, с которыми оперирует эта модель:

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

- экземпляр объекта - это конкретный определенный элемент множества. Например, в банковском деле объектом является некоторый лицевой счет, а экземпляром этого объекта — лицевой счет №123;

- классы, являющиеся, по сути, типами объектов. Класс- множество предметов реального мира, связанных общностью структуры и поведением. Элемент класса - это конкретный элемент данного множества. Например, в сфере банковской деятельности существует класс расчетно-денежных документов. Таким образом, объект - это типичный представитель класса, а термины экземпляр объекта и элемент класса равнозначны.

- операции над объектами одного или разных типов, называемые «методами».

Рассмотрим упрощенную модель объектно-ориентированной БД.