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

Реляционная модель данных для систем управления БД была разработана сотрудником исследовательской лаборатории компании IBM Э. Ф. Коддом. Будучи математиком, он разработал теорию реляционных баз данных, свободную от недостатков прежних моделей. В 1970 г. Э. Ф. Кодд опубликовал статью, посвященную краткому описанию новой модели. В отличие от предшествующих моделей реляционная модель имеет строгое математическое обоснование в виде теории множеств (реляционная алгебра) и исчисления предикатов (реляционное исчисление). Основой реляционной модели является отношение (rela-tion). Отношение содержит информацию об одной сущности (об одном классе объектов предметной области) и представляет собой множество элементов, называемых кортежами.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Т а б л и ц а 3

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

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

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

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

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

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

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

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

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

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

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

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

– при проектировании реляционных БД применяются строгие правила, базирующиеся на математическом аппарате;

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

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

Недостатки реляционной модели:

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

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

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

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