Домашнее задание
1. Ознакомится с теоретическими сведениями лекции №29.
2. Ответить на контрольные вопросы.
Контрольные вопросы
Реализация отношения "многие-ко-многим" для реляционных СУБД.
Отличия концептуальной и логической модели.
Лекция № 30 (2часа)
Тема: Построение физической модели.
Цель: Рассмотреть пример построения физической модели.
Литература:
Чен П.П. Модель “сущность-связь” – шаг к единому представлению данных. СУБД, N3, 1995 г.
Вендров А.М. CASE-технологии. Современные методы и средства проектирования информационных систем. М., Финансы и статистика, 1998.
Фаулер М., Скотт К. UML в кратком изложении. Применение стандартного языка объектного моделирования. М., Мир, 1999.
Буч Г. Объектно-ориентированный анализ и проектирование с примерами приложений на C++. 2-е изд. М., Издательство Бином, СПб., Невский диалект, 1999.
Буч Г., Рамбо Д., Джекобсон А. Язык UML: руководство пользователя. М., ДМК, 2000.
Содержание
Пример физической модели
Диаграмма, представленная на рис. 2.7.7, описывает физическую модель, соответствующую концептуальной и логической моделям (рассмотренных на предыдущей лекции).
Рисунок 2.7.7 - Пример физической модели
Сущности представлены таблицами, атрибуты - колонками, а их типы имеют типы платформы реализации. В схему всем сущностям добавлены ключи и индексы, а также другие реализационные детали.
Реализация отношения "один-ко-многим" для реляционных СУБД
Все отношения "один-ко-многим" в физической модели реализованы через вторичные ключи. В качестве примера рассмотрим сущности "Персона" и "Адрес".
Рисунок 2.7.8 - Реализация отношения "один-ко-многим"
Сущность "Персона" представляется таблицей 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 можно реализовать так:
В обоих таблицах заводится первичный ключ с одинаковым именем (в данном примере - с именем ID). Так как первичный ключ уникален и не может иметь значение NULL, одна запись из таблицы Person может ссылаться не более чем на одну запись из таблицы Teacher. Если в таблице Teacher есть запись с таким же ID, то отношение имеет значение 1, а если нет - то 0. В обратном направлении все обстоит точно также. Можно сказать, что реализовано отношение 0..1: 0..1, теперь нужно его усилить, превратив в 1:0..1.
Нужно сделать так, чтобы каждая запись таблицы Teacher всегда ссылалась на некоторую запись таблицы Person. Для этого первичный ключ таблицы Teacher сделаем еще и вторичным ключом, ссылающимся на первичный ключ таблицы Person. Поскольку вторичный ключ любой записи таблицы Teacher совпадает с ее первичным ключом и, значит, не может быть NULL, то соответствующая запись в таблице Person должна быть всегда.
Соответствующая спецификация таблицы Teracher на 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])
)
Наследование
Рисунок 2.7.9 - Реализация наследования
Каждая запись-потомок обязательно имеет запись-предка. Однако такая реализация не ограничивает вхождения записи предка в две записи потомка из разных таблиц-потомков. Следовательно, на эту пару ассоциаций нужно наложить дополнительное ограничение - альтернативность, - которое означает, что если для одной записи таблицы Person реализуется одна из этих ассоциаций, то другая уже не может реализоваться. Кроме того, наша реализация наследования допускает, чтобы сущность "Персона" была абстрактной - в таблице Person могут быть записи, которые не входят в состав каких-либо записей таблиц Teacher и Student.