МОДЕЛИ ДАННЫХ

 

 

2. МОДЕЛИ ДАННЫХ

 

2.1.  Иерархическая модель

 

Иерархическая структура представляет совокупность элементов, связанных между собой по определенным правилам. Графическим способом представления иерархической структуры является дерево (рис. 2.1).

 

Дерево представляет

 

  

Рис. 2.1. Графическое изображение

 

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

описывающих объекты. В модели имеется корневой узел (корень дерева), который находится на самом верхнем уровне и не имеет узлов, стоящих выше него. У одного

 

 

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

любое число (один, два или более, либо ни одного) подчиненных узлов на следующем уровне.

 

Примером простого иерархического представления может служить административная структура высшего учебного заведения: институт – отделение – факультет – студенческая группа

 

 

 

 

Рис. 2.2-1. Пример иерархической структуры

 

 

 

 

 

 

 

К достоинствам иерархической модели данных относятся эффективное использование памяти ЭВМ и неплохие показатели времени выполнения операций над данными.

 

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

 

 

2.1.  Сетевая модель данных

 

 

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

 

 

 

 

Теперь предлагаю вам изменить иерархическую модель БД, приведенную ниже, на сетевую.

 

 

 

 

 

 

Достоинством сетевой модели данных является возможность эффективной реализации по показателям затрат памяти и оперативности.

 

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

 

Наиболее известными сетевыми СУБД являются IDMS, db_VistaIII, СЕТЬ, СЕТОР и КОМПАС.

 

2.2.  Реляционная модель данных

 

Реляционная модель данных была предложена Е.Ф. Коддом, известным исследователем в области баз данных, в 1969 году, когда он был

 

 

сотрудником фирмы IBM. Впервые основные концепции этой модели были опубликованы в 1970.

 

Реляционная база данных представляет собой хранилище данных, организованных в виде двумерных таблиц (рис. 2.5). Любая таблица реляционной базы данных состоит из строк (называемых также записями) и столбцов (называемых также полями).

 

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

 

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

 

1)  Каждое значение, содержащееся на пересечении строки и столбца, должно быть атомарным1.

 

2)  Значения данных в одном и том же столбце должны принадлежать к одному и тому же типу, доступному для использования в данной СУБД.

 

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

 

4)  Каждое поле имеет уникальное имя.

 

5)  Последовательность полей в таблице несущественна.

 

6)  Последовательность записей в таблице несущественна.

 

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

 

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

 

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

 

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

 

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

 

 

 

 

1 Т.е. неделимым значением, с точки зрения конкретной СУБД.

 

 

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

 

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

 

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

 

 

 

 

 

 

Рис. 2.5. Схема реляционной модели данных

 

 

 

 

 

	Клиенты
Код клиента	ФИО	Телефон
11	Иванов	123-456
23	Петров	124-456
34	Краснов	321-456
45	Прыгунов	456-123

 

 

 

 

 

 

Авто
Код авт о	марка	мод ель	цвет	VIN	Цена
788	BMW	11	белый	12131114	900000
699	Lexsus	124	беж	45444465	1000000
333	Ford	125	белый	78778955	870000
334	Ford	125	белый	31544464	870000

 

Заказы

 

№	№	Код	Дата	Цена
заказа	клиента	авто
1	11	788	15.09.2014	900000
2	23	699	16.09.2014	1000000
3	45	333	16.09.2014	870000

 

 

 

Рис.2.5-1. Пример схемы реляционной модели данных. Здесь первичный ключ выделен жирным курсивом.

 

 

 

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

 

Примерами зарубежных реляционных СУБД для ПЭВМ являются: DB2, Paradox, FoxPro, Access, Clarion, Ingres, Oracle.

 

К отечественным СУБД реляционного типа относятся системы ПАЛЬМА и HyTech.

 

 

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

 

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

 

 

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

 

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

 

 

 

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

 

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

 

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

 

Рассмотренная постреляционная модель данных поддерживается СУБД uniVers. К числу других СУБД, основанных на постреляционной модели данных, относятся также системы Bubba и Dasdb.

 

 

 

2.1.  Многомерная модель

 

 

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

 

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

 

1)  системы оперативной (транзакционной) обработки;

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

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

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

 

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

 

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

 

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

 

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

 

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

 

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

 

 

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

 

Модель Июнь Июл ь Август Жигули 12 24 5 Москвич 2 18 No Волга No 19 No

а)                                                б)

 

 

Модель	Месяц	Объе м
Жигули	июнь	12
Жигули	июль	24
Жигули	август	5
Москвич	июнь	2
Москвич	июль	18
Волга	июль	19

Рис. 2.7. Реляционное (а) и многомерное (б) представление данных

 

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

 

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

 

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

 

В примере на рис. 2.7, б каждое значение ячейки Объем продаж однозначно                          определяется комбинацией временного измерения Месяц продаж и модели автомобиля. На практике зачастую требуется большее количество измерений.

 

 

Пример трехмерной модели данных приведен на рис. 2.8.

 

 

  

Рис. 2.8. Пример трехмерной модели

 

 

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

 

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

 

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

 

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

 

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

 

Примерами систем, поддерживающими многомерные модели данных, является Essbase, Media Multi-matrix, Oracle Express Server, Cache. Существуют программные продукты, например Media/MR, позволяющие одновременно работать с многомерными и с реляционными БД.

 

 

2.2.  Объектно-ориентированная модель

 

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

 

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

 

Рассмотрим упрощенную модель объектно-ориентированной БД. Структура объектно-ориентированной БД графически представима в виде дерева, узлами которого являются объекты. Свойства объектов описываются некоторым стандартным типом или типом, конструируемым пользователем (определяется как class). Значение свойства типа class есть объект, являющийся экземпляром соответствующего класса. Каждый объект- экземпляр класса считается потомком объекта, в котором он определен как свойство. Объект-экземпляр класса принадлежит своему классу и имеет одного родителя. Родовые отношения в БД образуют связную иерархию объектов. Пример логической структуры объектно-ориентированной БД библиотечного дела приведен на рис. 2.9. Здесь объект типа Библиотека является родительским для объектов-экземпляров классов Абонент, Каталог и Выдача. Различные объекты типа Книга могут иметь одного или разных родителей. Объекты типа Книга, имеющие одного и того же родителя, должны различаться, по крайней мере, инвентарным номером (уникален для каждого экземпляра книги), но имеют одинаковые значения свойств isbn, удк, название и автор.

 

Логическая структура объектно-ориентированной БД внешне похожа на структуру иерархической БД. Основное различие между ними состоит в методах манипулирования данными.

 

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

 

Инкапсуляция ограничивает область видимости имени свойства пределами того объекта, в котором оно определено. Так, если в объект типа Каталог добавить свойство, задающее телефон автора книги и имеющее название телефон, то мы получим одноименные свойства у объектов Абонент и Каталог. Смысл такого свойства будет определяться тем объектом, в который оно инкапсулировано.

 

Наследование, наоборот, распространяет область видимости свойства на всех потомков объекта. Так, всем объектам типа Книга, являющимся потомками объекта типа Каталог, можно приписать свойства объекта- родителя: isbn, удк, название и автор. Если необходимо расширить действие

 

 

механизма наследования на объекты, не являющиеся непосредственными родственниками (например, между двумя потомками одного родителя), то в их общем предке определяется абстрактное свойство типа abs. Так, определение абстрактных свойств билет и номер в объекте Библиотека приводит к наследованию этих свойств всеми дочерними объектами Абонент, Книга и Выдача. Не случайно поэтому значения свойства билет классов Абонент и Выдача, показанных на рис. 2.9, являются одинаковыми – 00015.

 

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

 

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

 

 

  

 

Рис. 2.9. Логическая структура БД библиотечного дела

 

 

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

 

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

 

К объектно-ориентированным СУБД относятся POET, Jasmine, Versant, O2, ODB-Jupiter, Iris, Orion, Postgres.