Логическое проектирование и реализация реляционных баз данных. Основы Transact-SQL (Лабораторная работа № 2), страница 2

Рисунок 4 - Отображение связи (1, 1):(0, 1) на реляционную схему

3. Похожим образом происходит отображение двух сущностей и связи (0,1):(0,1), но ограничение NOT NULL на внешний ключ не устанавливается; в таком ограничении нет нужды, так как класс принадлежности обеих сущностей к связи – необязательный (рис. 5).

Рисунок 5 - Отображение связи (0,1):(0,1) на реляционную схему

4. Похожим образом происходит отображение двух сущностей и связи (1,1):(0,N), но на внешний ключ накладывается дополнительное ограничение целостности NOT NULL, а UNIQUE – не накладывается (рис. 6). Действительно, поскольку связь имеет тип 1:N, значения внешнего ключа во второй таблице не обязаны быть уникальными. Ограничение NOT NULL накладывается потому, что сущность E₁ имеет обязательный класс принадлежности к связи R₁.

Рисунок 6 - Отображение связи (1,1):(0,N) на реляционную схему

5. Отображение двух сущностей и связи (0,1):(0,N) происходит по аналогичной схеме, но внешний ключ во второй таблице не связывается дополнительными ограничениями целостности (рис. 7).

Рисунок 7 - Отображение связи (0,1):(0,N) на реляционную схему

6. Для преобразования связи M:N (независимо от класса принадлежности) используются три таблицы: по одной для каждой сущности (первичными ключами становятся ключевые атрибуты сущностей) и одна – для связи. Последняя имеет два атрибута – внешних ключа, ссылающихся на первичные ключи первых двух базовых таблиц, в нее же включаются атрибуты связи (рис. 8).

Рисунок 8 – Отображение связи M:N на реляционную схему

Замечание. На практике первичными ключами таблиц становятся дополнительные атрибуты (которых не было у сущностей на ER-диаграмме) – уникальные идентификаторы, позволяющие однозначно определить каждую строку в таблице. Именно такие атрибуты таблиц часто используются в качестве первичных ключей – вместо других атрибутов, образующих ключ сущности. Использование числовых идентификаторов в качестве первичных ключей позволяет решить, по крайней мере, две проблемы. Первая проблема связана с размером используемой памяти. Составной первичный ключ «фамилия-имя-отчество-адрес-телефон» займёт в памяти не один десяток байт, а номер – только 4 или 8 байт. Вторая проблема – изменение значения первичного ключа. Предположим, в качестве первичного ключа используется номер паспорта. Такой атрибут несет на себе определенную смысловую нагрузку: номер паспорта в базе данных соответствует некоторому реально существующему номеру реального паспорта. В какой-то момент времени может выясниться, что один из номеров был введен в БД неверно, и требуется его коррекция. Но тогда потребуется коррекция соответствующих ссылок по внешнему ключу в других таблицах, что может оказаться трудоемким делом. По этой причине использование номера паспорта в качестве первичного ключа нежелательно. Что касается уникального идентификатора, то он не несет на себе дополнительной смысловой нагрузки, будучи «безликим» номером записи, и на практике не бывает необходимости в его модификации. Вывод: использование уникальных идентификаторов в качестве первичных ключей существенно повышает эффективность обработки данных.

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

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

Требование ссылочной целостности касается внешних ключей. Оно запрещает появление ссылок, ведущих на несуществующие значения первичных ключей. Применительно к примеру на рис. 2 это можно пояснить следующим образом: если в таблице trains отсутствует первичный ключ со значением 8, то он не может появиться и в столбце id_train таблицы coaches. Другой стороной ссылочной целостности является запрет на модификацию и удаление первичного ключа, если не скорректированы либо не удалены ссылки, на него ведущие. Так, нельзя удалить из таблицы trains поезд «Автора» с идентификатором 2, пока из таблицы coaches не будут удалены записи о вагонах этого поезда.