Визуальное моделирование баз данных

Пример физической модели

Диаграмма, представленная на рис. 8.6, описывает физическую модель, соответствующую концептуальной и логической моделям с рис. 8.3 и рис. 8.5. Эта диаграмма создана в Microsoft Visual Studio 2005 и ориентирована на реализацию схемы базы данных на СУБД Microsoft SQL Server.

увеличить изображение
Рис. 8.6. Пример физической модели

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

Реализация отношения "один-ко-многим" для реляционных СУБД

Все отношения "один-ко-многим" в физической модели реализованы через вторичные ключи. В качестве примера рассмотрим сущности "Персона" и "Адрес", представленные на рис. 8.7.

Рис. 8.7. О реализации отношения "один-ко-многим"

Сущность "Персона" представляется таблицей Person, сущность "Адрес" - таблицей Address. Фрагмент на SQL/DDL, соответствующий реализации сущности "Персона", выглядит так:

CREATE TABLE [Person](
	[Id] [int] NOT NULL,
	[FirstName] [varchar](20) NULL,
	[SecondName] [varchar](50) NULL,
	[Patronymic] [varchar](20) NULL,
	[Phone] [varchar](15) NULL,
	[AddressId] [int] NOT NULL,
 CONSTRAINT [PK_Person] PRIMARY KEY([Id] ASC),
 CONSTRAINT [FK_Person_Address] FOREIGN KEY([AddressId]) 
   REFERENCES [Address] ([Id])
)

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

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

Так реализуется отношение 1:0..*. Если же нужно реализовать отношение 0..1:0..*, то нужно позволить вторичному ключу в таблице Person иметь значение NULL.

Реализация отношений 1:0..1 и наследования для реляционных СУБД

Рассмотрим следующий пример. Сущность "Персона" связана отношением 1:0..1 с сущностью "Преподаватель". Это означает, что преподаватель всегда должен быть связан с персоной, но персона не обязана быть преподавателем, а может быть, например, студентом. Сущность "Персона" представляется таблицей Person, сущность "Преподаватель" - таблицей Teacher. Отношение 1:0..1 можно реализовать так:

1. В обоих таблицах заводится первичный ключ с одинаковым именем (в данном примере - с именем ID). Так как первичный ключ уникален и не может иметь значение NULL, одна запись из таблицы Person может ссылаться не более чем на одну запись из таблицы Teacher. Если в таблице Teacher есть запись с таким же ID, то отношение имеет значение 1, а если нет - то 0. В обратном направлении все обстоит точно также. Можно сказать, что реализовано отношение 0..1: 0..1, теперь нужно его усилить, превратив в 1:0..1.
2. Нужно сделать так, чтобы каждая запись таблицы Teacher всегда ссылалась на некоторую запись таблицы Person. Для этого первичный ключ таблицы Teacher сделаем еще и вторичным ключом, ссылающимся на первичный ключ таблицы Person. Поскольку вторичный ключ любой записи таблицы Teacher совпадает с ее первичным ключом и, значит, не может быть NULL, то соответствующая запись в таблице Person должна быть всегда.

Соответствующая спецификация таблицы Teacher на SQL/DDL представлена ниже:

CREATE TABLE [Teacher](
	[Id] [int] NOT NULL,
	[Degree] [tinyint] NULL,
	[Rank] [tinyint] NULL,
 CONSTRAINT [PK_Teacher] PRIMARY KEY([Id] ASC),
 CONSTRAINT [FK_Teacher_Person] FOREIGN KEY([Id]) 
   REFERENCES [Person] ([Id])
)

Теперь о наследовании. Заменим его отношением 1:0..1, как это показано на рис. 8.8.

Рис. 8.8. Реализация наследования

Каждая запись-потомок обязательно имеет запись-предка. Однако такая реализация не ограничивает вхождения записи предка в две записи потомка из разных таблиц-потомков. Следовательно, на эту пару ассоциаций нужно наложить дополнительное ограничение - альтернативность, - которое означает, что если для одной записи таблицы Person реализуется одна из этих ассоциаций, то другая уже не может реализоваться. Кроме того, наша реализация наследования допускает, чтобы сущность "Персона" была абстрактной - в таблице Person могут быть записи, которые не входят в состав каких-либо записей таблиц Teacher и Student. Читателю предлагается самостоятельно подумать, как снять оба этих ограничения.