Классический подход к проектированию баз данных

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

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

области базы данных в виде диаграмм, спецификаций и требований;
контроль качества

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

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

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

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

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

отношений на соответствие нормальной форме Бойса-Кодда;
проверка отношений на свойства соединения

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

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

построенной логической модели реляционной базы данных;
принятие решения о разработке физической модели реляционной базы данных.

данных и выводятся из сущностей логической модели данных. При создании

каждой таблицы проектировщик должен рассмотреть и учесть ряд факторов:
определить список колонок в таблице. Колонки выводятся из атрибутов сущности логической модели данных;
определить типы данных для каждой колонки. Типы данных колонок либо заданы спецификацией домена атрибута логической модели, либо определяются проектировщиком самостоятельно;
определить имя таблицы. Оно может быть выведено из имени сущности логической модели базы данных или задано проектировщиком самостоятельно. Желательно в этот момент определить собственника таблицы - пользователя, который будет иметь все права доступа на таблицу, а также потенциальных пользователей таблицы;
определить ряд параметров, связанных с характером хранения таблицы в физической базе данных;
определить ограничения на значения колонок, исходя из ряда бизнес-правил.

если они имеют место в логической модели базы данных. В

рамках ER-диаграмм это отношение может быть уже разрешено. Тогда речь пойдет только о его реализации в командах SQL.

базе данных. Если будет решено поддерживать ссылочную целостность на уровне

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

тип приложения базы данных;
по имеющимся требованиям и описаниям выполняет

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

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

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

создание функций;
принятие решения и создание пакетов;
принятие решения и создание триггеров.

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

с помощью создания специальных объектов базы данных;
создание инсталляционного скрипта;
документирование базы данных.