Этапы проектирования реляционной базы данных

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

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

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

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

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

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

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

1. должно быть описано только внешнее поведение системы;

2. должны быть определены ограничения реализации;

3. спецификация должна легко модифицироваться;

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

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

6. должна быть предусмотрена приемлемая реакция на нежелательные события.

Каждое требование спецификации должно быть выражено в виде ответа на вопрос «Что», а не «Как». Вопрос «Как» рассматривается в спецификации проекта.

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

При составлении спецификации лучше избегать многословия и повествовательного стиля. Это существенно упростит возможную последующую модификацию.

6.1. Разработка технического задания

Техническое задание (ТЗ) на проектирование БД должен представить заказчик. Однако для этого он должен владеть соответствующей терминологией и знать хотя бы примерно технические возможности основных СУБД. Увы, такое бывает не всегда. Поэтому обычно используются следующие подходы:

• на основе демонстрации аналогичной БД и согласования спецификации отличий или

• если аналога нет, на основе выявления круга задач и потребностей заказчика и последующего составления ТЗ (исполнитель помогает заказчику подготовить техническое задание).

При разработке ТЗ составляют:

• список исходных данных, с которыми работает заказчик,

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

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

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