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

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

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

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

Спецификация требований

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

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

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

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

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

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

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

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

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

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

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

Спецификация требований 85

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

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

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

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

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

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

Спецификация требований должна быть документом, который поможет будущему программисту познакомиться с возможностями системы. Не удивляйтесь, если через полгода таким программистом окажетесь вы сами. И не допустите, чтобы данное качество спецификации вступило в конфликт с предыдущим качеством: простотой модификации. Спецификация требований - это визитная карточка системы, но не ее основная документация.

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

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

Ниже перечислены девять рекомендуемых разделов спецификации:

1) обзор целей и задач системы;

2) среда функционирования и разработки;

3) внешние интерфейсы и потоки данных;

4) функциональные требования;

5) требования к производительности;

6) обработка исключительных ситуаций;

7) приоритеты реализации;

8) возможные модификации;

9) проектные рекомендации.