Иерархическая и сетевая модели данных

Первой СУБД, построенной на базе иерархической модели стала система IMS, выпущенная компанией IBM в 1968 г. В этой системе начали утверждаться принципы управления базами данных.

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

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

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

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

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

Почти одновременно с иерархической моделью была сформирована сетевая модель данных. Сетевой подход является расширением иерархического. В сетевой модели происходит объединение нескольких различных иерархий. В примере на рис. 7.22 объединены две иерархии: Заказ и Покупатель.

Рис. 7.22. Сетевая модель

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

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

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

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

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

Реляционная модель данных для систем управления базами данных была разработана сотрудником исследовательской лаборатории компании IBM Э. Ф. Коддом. Э. Ф. Кодд, будучи математиком, разработал теорию реляционных баз данных, свободную от недостатков прежних моделей. В 1970 г. он опубликовал статью, посвященную краткому описанию новой модели.

В отличие от предшествующих моделей реляционная модель имеет строгое математическое обоснование в виде теории множеств (реляционная алгебра) и исчислении предикатов (реляционное исчисление).

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

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

В Табл.7.2 показан пример отношения ПОКУПАТЕЛЬ, содержащий несколько кортежей (строк, описывающих покупателей). Отметим, что здесь указаны не все атрибуты для сущности ПОКУПАТЕЛЬ из нашего примера.

Таблица 7.2. Пример отношения ПОКУПАТЕЛЬ
Код покупателя	Фамилия	Телефон	Адрес электронной почты	Почтовый адрес
	Петрова	125-15-97	[email protected]	Москва, ул. Зеленая, 2-4
	Краснов	447-85-96	[email protected]	Мытищи, ул. Новая, 11-5

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

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

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

· В таблице не может быть повторяющихся строк.

· Порядок строк и столбцов в таблице произвольный.

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

Рассмотрим подробнее фундаментальные свойства отношений, построенных на этих правилах.

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

Первичный ключ – это атрибут или минимальный набор атрибутов, однозначно определяющих каждую строку. В примере (табл. 7.2) первичным ключом является Код покупателя.

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

Первичные ключи используются в следующих целях:

· идентификации строк в таблице;

· ускорения работы со строками таблицы;

· связывания таблиц.

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

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

Отсутствие многозначных атрибутов. Если атрибут имеет несколько значений в одной строке, то такие значения называются повторяющимися группами. Например, покупатель может указать несколько телефонов для связи. Наличие нескольких телефонов в одной строке для столбца Телефон недопустимо. В этом случае надо создавать новое отношение ТЕЛЕФОН ПОКУПАТЕЛЯ с атрибутами Код покупателя, Телефон.

Связи.Связи между сущностями представляются в реляционной модели связями между таблицами по значениям ключевых атрибутов. В Табл. 7.3. показана связь «один-ко-многим» между таблицами ПОКУПАТЕЛЬ и ЗАКАЗ по столбцу Код покупателя. Первичные ключи таблиц здесь выделены жирным шрифтом. Каждой строке таблицы ПОКУПАТЕЛЬ должны соответствовать одна или несколько строк таблицы ЗАКАЗ с тем же значением атрибута Код покупателя. Во взаимоотношении этих таблиц первую таблицу можно назвать главной, а вторую – подчиненной. Атрибут подчиненной таблицы, по которомуосуществляется связь, называется внешним ключомглавной таблицы.

Таблица 7.3. Связь таблиц ПОКУПАТЕЛЬ – ЗАКАЗ
ПОКУПАТЕЛЬ			ЗАКАЗ
1					m
Код покупателя	Фамилия	Телефон		Код заказа	Код покупателя	Дата доставки
	Петрова	125-15-97				08/06/2001
	Краснов	447-85-96				09/06/2001
…				…
	Иванова	345-67-89				21/07/2001

В данном случае внешним ключом таблицы ПОКУПАТЕЛЬ во взаимосвязи ПОКУПАТЕЛЬ - ЗАКАЗ является атрибут Код покупателя таблицы ЗАКАЗ.

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

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

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

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

Требование целостности по ссылкам означает, что для связанных отношений каждому значению внешнего ключа должна найтись запись в главной таблице с таким же значением первичного ключа. В нашем примере каждому значению кода покупателя в таблице ЗАКАЗ должна соответствовать строка с данным кодом покупателя в таблице ПОКУПАТЕЛЬ. Требование целостности по ссылкам также называют требованием внешнего ключа.

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

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

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

Выбор варианта зависит от требований предметной области и существующих бизнес-правил. Так, при отмене заказа очевидно следует произвести удаление записи об этом заказе из таблицы ЗАКАЗЫ и всех соответствующих записей из таблицы КОРЗИНА ЗАКАЗА, то есть применить каскадное удаление. Для связи между таблицами ПОКУПАТЕЛЬ и ЗАКАЗ (по коду покупателя) нельзя удалять запись о покупателе, который оформил хотя бы один заказ.

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

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