Широко известные методы проектирования баз данных (БД) появились в процессе разработки все более сложных информационных технических систем (ИТС), которые должны были рассматривать потребности не одного пользователя, а больших групп и коллективов. Одна такая интегрированная БД создавалась для решения многих задач, каждая из которых использовала только «свою» часть данных, обычно, пересекающуюся с частями, используемыми в других задачах.
Другой важной проблемой проектирования БД явилось обеспечение нужных эксплуатационных параметров, таких как объем внешней памяти или время выполнения различных операций. Известны и другие требования. Например, информация не должна потеряться не только из-за отказов оборудования, но и вследствие ошибки пользователя.
Существуют два основных подхода к проектированию систем БД: нисходящий и восходящий. При восходящем подходе работа начинается с самого нижнего уровня атрибутов (т.е. свойств сущностей и связей), которые на основе анализа существующих между ними связей группируются в отношения, представляющие типы сущностей и связи между ними.
Наиболее подходящей стратегией проектирования сложных БД является использование нисходящего подхода. Начинается этот подход с разработки моделей данных, которые содержат несколько высокоуровневых сущностей и связей, затем работа продолжается в виде серии нисходящих уточнений низкоуровневых сущностей, связей и относящихся к ним атрибутов. Нисходящий подход используется в концепции метода проектирования «сущность-связь». В этом случае работа начинается с выявления сущностей и связей между ними, интересующих данную организацию в наибольшей степени.
Процесс проектирования БД методом «сущность-связь» состоит из трех основных этапов: концептуальное, логическое и физическое проектирование.
Концептуальное проектирование БД - это процесс создания модели используемой информации, не зависящей от любых физических аспектов ее представления. Эта модель данных создается на основе информации, записанной в спецификациях требований пользователей. Концептуальное проектирование БД абсолютно не зависит от таких подробностей ее реализации, как тип выбранной целевой СУБД, набор создаваемых прикладных программ, используемые языки программирования, тип выбранной вычислительной платформы, а также от любых других особенностей физической реализации.
Логическое проектирование БД. Процесс создания модели используемой информации на основе выбранной модели организации данных, но без учета типа целевой СУБД и других физических аспектов реализации. Концептуальная модель данных, созданная на предыдущем этапе, уточняется и преобразуется в логическую модель данных, которая учитывает особенности выбранной модели организации данных в целевой СУБД (например, реляционная модель).
Логическая модель данных создается на основе выбранной модели организации данных целевой СУБД. Иначе говоря, на этом этапе уже должно быть известно, какая СУБД будет использоваться в качестве целевой ‒ реляционная, сетевая, иерархическая или объектно-ориентированная. Для проверки правильности логической модели данных используется метод нормализации. Нормализация гарантирует, что отношения, выведенные из существующей модели данных, не будут обладать избыточностью данных, способной вызвать нарушения в процессе обновления данных после их физической реализации. Помимо всего прочего, логическая модель данных должна обеспечивать поддержку всех необходимых пользователям транзакций.
Физическое проектирование БД - это процесс подготовки описания реализации БД на вторичных запоминающих устройствах; на этом этапе рассматриваются основные отношения, организация файлов и индексов, предназначенных для обеспечения эффективного доступа к данным, а также все связанные с этим ограничения целостности и средства защиты.