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

проектирование;
логическое проектирование;
физическое проектирование.
1. Концептуальное проектирование БД – это процесс создания

высокоуровневой семантической модели для данных, которые присутствуют в определенной предметной области.

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

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

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

и обработке.

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

уже готовой БД.
Эта модель, если ее постоянно поддерживать в актуальном

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

создания таблиц на жестком диске;
определение методов доступа к данным, чтобы

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

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

сущностями
Построение ER-диаграммы

являются следующие факторы:
min набор атрибутов (наилучший вариант – простой ключ

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

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

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

часто содержит конструкции, для которых нет поддержки в реляционных СУБД.
На

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

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

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

связи этой сущности с исходными сущностями.

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

новой и исходной сущностями организуется связь типа 1:М.

атрибутом Номер_телефона.
Если некоторые отделы имеют несколько контактных телефонов, то этот

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

сущности создается таблица и в нее включают все простые атрибуты

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

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

целесообразно объединить.

Пример 1:

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

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

внешним ключом.

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

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

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