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

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

Процедура разработки для реляционной модели (создание и проверка локальной логической модели данных для отдельных пользовательских представлений) включает следующие этапы:

1. устранение особенностей локальной логической модели, несовместимых с реляционной моделью (необязательный этап). Назначение этого этапа состоит в следующем:

а) удаление двухсторонних связей «многие ко многим»;

б) удаление рекурсивных связей «многие ко многим»;

в) удаление сложных связей;

г) удаление многозначных атрибутов;

2. определение набора отношений исходя из структуры локальной логической модели данных. Сведения о способах преобразования сущностей и связей в отношения представлены в таблице 3.8.

Таблица 3.8 – Способы преобразования сущностей и связей в отношения

Сущность/связь	Способ преобразования
Сильная сущность	Создание отношений, которые включают все простые атрибуты
Слабая сущность	Создание отношений, которые включают все простые атрибуты (после преобразования связи с каждой сущностью- владельцем необходимо также определить первичный ключ)
Двухсторонняя связь типа 1:*	Передача первичного ключа сущности на сторону «один» для использования в качестве внешнего ключа в отношении, соответствующем сущности на стороне «многие». На сторону «многие» передаются также все атрибуты связи
Двухсторонняя связь: а) обязательное участие обеих сторон б) обязательное участие одной стороны в) необязатель- ное участие обеих сторон	Объединение сущности в одно отношение Передача первичного ключа сущности на «необязательную» сторону для использования в качестве внешнего ключа в отношении, представляющем сущность на «обязательной» стороне связи Если отсутствует дополнительная информация, то выбор становится произвольным
Продолжение таблицы 3.8
Сущность/связь	Способ преобразования
Связь «суперкласс / подкласс»	Ограничение степени участия Ограничение непересечения Необходимые отношения Обязательное Необязательное Обязательное Необязательное Пересечение допускается Пересечение допускается Пересечение не допускается Пересечение не допускается Одно отношение (с одним или несколькими определителями, позволяющими указать тип каждой записи) Два отношения: одно – для суперкласса, а второе – для всех подклассов (с одним или несколькими определителями, позволяющими указать тип каждой записи) Несколько отношений: по одному отношению для каждого сочетания суперкласс/подкласс Несколько отношений: одно – для суперкласса, а другие – по одному для каждого подкласса
Двухсторонняя связь типа *:*, сложная связь	Создание отношения, представляющегосвязь, ивключение всех атрибутов связи. Передача в новое отношение копии первичного ключа изкаждой сущности-владельца для использования в качестве внешних ключей
Многозначный атрибут	Создание отношения, представляющего многозначный атрибут, и передача копии первичного ключа сущности-владельца в новое отношение для использования в качестве внешнего ключа

По завершении этапа необходимо формально описать состав отношений, полученных на основе логической модели данных (документирование сведений об отношениях и атрибутах первичных, потенциальных и внешних ключах);

3. проверка отношений с помощью правил нормализации. Целью выполнения этого этапа является обеспечение того, что каждое из отношений, созданных на основании логической модели данных, соответствует, по крайней мере, требованиям НФБК;

4. проверка соответствия отношений требованиям пользовательских транзакций.Проверка того, поддерживают ли отношения локальной логической модели данных транзакции, которые требуются в рассматриваемом представлении, для получения гарантий того, что в процессе создания отношений не были допущены ошибки. Для этого все необходимые операции доступа к данным должны быть выполнены вручную с помощью отношений, линий связи первичного ключа/внешнего ключа, соединяющих отношения, ER-диаграммы и словаря данных;

5. определение требований поддержки целостности данных. Ограничения целостности данных вводятся с целью предотвратить появление в базе противоречивых данных. Типы ограничений целостности данных:

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

б) ограничения для доменов атрибутов;

в) целостность сущностей (первичный ключ не может содержать пустого значения);

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

д) ограничения предметной области (или бизнес-правила).

Документирование сведений обо всех ограничениях целостности;

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