Целью разработки любой БД является хранение и использование информации о какой-либо предметной области. Для реализации этой цели имеются следующие инструменты:

Но очевидно, что для одной и той же ПО отношения можно спроектировать различными способами. Например, можно спроектировать несколько отношений с большим количеством атрибутов, или разнести все атрибуты по большому количеству мелких отношений. Как определить, по каким признакам нужно помещать атрибуты в те или иные отношения?

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

При разработке БД обычно выделяется несколько уровней моделирования, при помощи которых происходит переход от ПО к конкретной реализации БД средствами конкретной СУБД. Итак, уровни:

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

Модель ПО (концептуальная модель) – это наши знания о ПО. Знания могут быть как в виде формальных знаний в мозгу эксперта, так и выражены формально при помощи каких-либо средств. В качестве таких средств могут выступать текстовые описания ПО, наборы должностных инструкций. Наиболее эффективным является описание ПО с помощью графических средств. Наиболее известны – методология IDEF0, диаграммы потоков данных Гейна-Сарсона (DFD), методика объектно-ориетированного анализа UML. Модель предметной области описывает процессы происходящие в ПО и данные, используемые этими процессами.

Логическая модель данных ПО – она описывает понятия ПО, их взаимосвязи, а также ограничения на данные, налагаемые ПО. Примеры понятий – сотрудник, отдел, проект. Примеры взаимосвязей между понятиями – сотрудник числится ровно в одном отделе, сотрудник может выполнять несколько проектов. Примеры ограничений – возраст сотрудника не менее 18 и не более 65 лет.

Логическая модель данных является начальным прототипом будущей БД.

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

Основным средством разработки логической модели данных в настоящий момент являются различные варианты диаграммы сущность-связь (ERD).

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

При разработке логической модели возникают вопросы: хорошо ли спроектированы отношения, правильно ли они отражают модель ПО и саму ПО?

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

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

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

БД и приложения. И наконец как результат предыдущих этапов появляется сама БД. БД реализована на конкретной программно-аппаратной основе, и выбор этой основы позволяет существенно повысить скорость работы с БД.

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