Этапы проектирования БД

физической реализации:

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

основе выбранной модели структурной организации данных при их хранении и обработке.

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

готовой БД.

Эта модель, если ее постоянно поддерживать в актуальном состоянии, позволяет точно и наглядно представить любые изменения в структуре БД, а также оценить их влияние на прикладное ПО.
3. Физическое проектирование – это процесс принятия решений по реализации проекта разрабатываемой БД.

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

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

следующие факторы:

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

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

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

одну промежуточную сущность и две связи 1:М.

модель добавляется новая сущность;
вводятся бинарные связи типа 1:М для связи этой сущности с исходными сущностями.

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

Номер_телефона.
Если некоторые отделы имеют несколько контактных телефонов, то этот атрибут относится к типу многозначного.
Для исключения из модели такого атрибута вводится дополнительная сущность ТЕЛЕФОН:

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

участие в связи полное (т.е. связь обязательная)
Такие сущности целесообразно объединить.

Пример 1:

В этом случае целесообразно паспортные данные включить в таблицу КЛИЕНТЫ.

таблицы КЛИЕНТЫ передается в таблицу ПОЖЕЛАНИЯ и становится там внешним ключом.

Для одной из сторон участие в связи неполное (т.е. связь необязательная)

Сущность, для которой имеет место неполное участие в связи, объявляется родительской.
После этого можно применять схему «первичный ключ/внешний ключ».