Логическое проектирование БД

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

Хотя логическое проектирование оперирует не физическими записями, а логическими понятиями, связанными со структурой базы данных, особенности представления данных, правила и языки агрегирования и манипулирования данными имеют определяющее влияние. Не все виды связей, например «многие ко многим», могут быть непосредственно отображены в логической модели.

Рассмотрим по шагам общий подход к построению реляционной базы данных на основе модели, представленной ER-диаграммой.

1. 
   Каждая простая сущность превращается в таблицу (отношение). Имя сущности становится именем таблицы;
   
2. 
   Каждый атрибут становится возможным столбцом с тем же именем. Столбцы, соответствующие необязательным атрибутам, могут содержать неопределенные значения; столбцы, соответствующие обязательным атрибутам, не могут. Если атрибут является множественным, для него строится отдельное отношение;
   
3. 
   Компоненты уникального идентификатора сущности превращаются в первичный ключ. Если имеется несколько возможных уникальных  идентификаторов,   выбирается  наиболее используемый. Если в состав уникального идентификатора входят связи, к числу столбцов первичного ключа добавляется копия уникального идентификатора сущности, находящейся на дальнем конце связи (этот процесс может продолжаться рекурсивно). Для именования этих столбцов используются имена концов связей и/или имена сущностей;
   
4. 
   Связи «многие к одному» и «один к одному» становятся внешними ключами, т. е. создается копия уникального идентификатора с конца связи «один», и соответствующие столбцы составляют внешний ключ;
   
5. 
   Индексы создаются для первичного ключа (уникальный индекс), а также внешних ключей и тех атрибутов, которые будут часто использоваться в запросах.
   

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

Во-втором случае для каждого подтипа создается отдельная таблица и для каждого подтипа первого уровня (для более нижних — представления) супертип воссоздается с помощью представления union (из всех таблиц подтипов выбираются общие столбцы — столбцы супертипа).

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

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