Этап 4. Перенос глобальной логической модели данных в среду целевой СУБД

Методология физического проектирования баз данных реляционного типа

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

Цель Создание базовой функциональной схемы реляционной базы данных на основе глобальной логической модели данных.

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

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

поддерживает ли система определение первичных ключей, внешних ключей и альтернативных ключей;

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

поддерживает ли система определение доменов;

поддерживает ли система определение бизнес-правил предприятия;

способ определения таблиц базы данных.

На этапе 4 процедуры разработки баз данных выполняются следующие действия.

Этап 4.1. Проектирование таблиц базы данных в среде целевой СУБД.

Этап4.2. Реализация бизнес-правил предприятия в среде целевой СУБД.

Этап 4.1. Проектирование таблиц базы данных в среде целевой СУБД

Цель Определение способа представления в целевой СУБД отношений, выделенных в глобальной логической модели данных.

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

· имя отношения;

· список простых атрибутов, заключенный в скобки;

· определение первичного ключа и (если таковые существуют) альтернативных (АК) и внешних (FK) ключей;

· определение требований ссылочной целостности для любых внешних ключей;

Для каждого атрибута в словаре данных должна присутствовать следующаяинформация:

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

· принимаемое по умолчанию значение атрибута (необязательно);

· допустимость значения NULL для данного атрибута;

· является ли данный атрибут производным, и если это так, способ вычисления его значения.

При записи проектов таблиц базы данных мы будем использовать язык DBDL для определения доменов, принимаемых по умолчанию значений и указания допустимости значения MULL. В качестве примера в листинге 9.1 приведено определение таблицы Property_for_Rent из приложения-примера DreamHome.

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

1. Описание на языке SQL стандарта ISO 1992 (SQL2).

2. Реализация с использованием триггеров.

3. Реализация в среде СУБД INGRES 6.4.

4. Реализация с использованием уникальных индексов.