5. Варианты для самостоятельной работы.

Задание№1.

Определите ограничения ссылочной целостности для следующих отношений:

1. Работник(Табельный_номер,Фамилия, Имя, Отчество, Адрес, Телефон, Пол, Дата_Рождения,Должность, Скорость_Печати, Номер_Филиала)

Первичный ключ Табельный_номер

Внешний ключ Номер_Филиала для таблицы Филиал(Номер_Филиала)

2. Объект_для_аренды (Номер_объекта,Улица,Город, Почтовый_индекс,Тип, Количество_комнат,Арендная_плата, Номер_Владельца, Табельный_номер , Номер_Филиала)

Первичный ключ Номер_объекта

Внешний ключ Номер_Владельца для таблицы

Владелец (Номер_ Владельца)

Внешний ключ Табельный_номер для таблицы

Работник (Табельный_номер)

Внешний ключ Номер_Филиала для таблицы Филиал(Номер_Филиала)

3. Инспекция (Номер_объекта, Табельный_номер, Дата_инспектирования, Комментарии)

Первичный ключ (Номер_объекта, Табельный_номер, Дата_инспектирования)

Внешний ключ (Номер_объекта)для таблицы Объект_для_аренды (Номер_объекта)

Внешний ключ Табельный_номер для таблицы Работник (Табельный_номер)

4. Осмотр (Номер_объекта, Номер_клиента, Дата_осмотра, Комментарии)

Первичный ключ (Номер_объекта, Номер_клиента, Дата_осмотра)

Внешний ключ (Номер_объекта)для таблицы Объект_для_аренды (Номер_объекта)

Внешний ключ Номер_клиента для таблицы Клиент (Номер_клиента)

Практическая работа №4. Разработка физического проекта бд.

Цель занятия: Преобразовать логическую модель в реляционные таблицы.

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

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

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

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

Алгоритм преобразования er-модели в реляционную модель данных.

Рассмотрим, каким образом необходимо доработать логическую модель под функциональные возможности СУБД Access:

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

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

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

Например, атрибут Номер договора описан в логической модели как строка символов переменной длины, которая равна максимум 5 символам. Однако в среде MS Access не делается различий между символьными строками фиксированной и переменной длины, поэтому определяем тип данного атрибута просто как текст с длиной 5.

3. Первичный ключ сущности становится PRIMARY KEY соответствующего отношения.

4. В каждое отношение, соответствующее подчиненной сущности, добавляется набор атрибутов основной сущности, являющийся первичным ключом основной сущности. Этот набор становится внешним ключом (FOREING KEY).

5. Для моделирования необязательного типа связи на физическом уровне у атрибутов, соответствующих внешнему ключу, устанавливается свойство допустимости неопределенных значений (признак NULL). При обязательном типе связи атрибуты получают свойство отсутствия неопределенных значений (признак NOT NULL).

6. В логической модели указаны требования поддержки ссылочной целостности между связанными таблицами. Например, правило обновления внешнего ключа Номер_Филиала отношения Объект_для_аренды задается ключевым словом CASCADE, а правило удаления - ключевым словом SET DEFAULT. Однако СУБД MS Access в правилах обновления и удаления допускает использование лишь ключевых слов CASCADE и NO ACTION, причем последнее в обоих случаях принимается по умолчанию.

При преобразовании в физический проект требуется избавиться от ограничений SET DEFAULT и SET NULL, воспользовавшихся вместо них теми, которые разрешены СУБД MS Access.

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