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

Основная причина сложности проектирования базы данных заключается

в том, что объекты реального мира и взаимосвязи между ними вовсе не обязаны

иметь и, как правило, не имеют структуры, согласованной с реляционной моде-

лью данных. Разработчик при проектировании должен придумать представле-

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

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

Поэтому в данном контексте термин «проектирование» можно понимать и как

процесс, результатом которого является проект, и как процесс, результатом ко-

торого является проекция.

Разработка эффективной базы данных состоит из нескольких этапов.

Процесс разработки БД начинается с анализа требований. Проектировщик на

этом этапе разработки должен найти ответы на следующие вопросы: какие эле-

менты данных должны храниться, кто и как будет к ним обращаться.

8

На втором этапе создается логическая структура БД. Для этого определя-

ют, как данные будут сгруппированы логически. Структура БД на этом этапе

выражается в терминах прикладных объектов и отношений между ними.

На заключительном (третьем) этапе логическая структура БД преобразу-

ется в физическую с учетом аспектов производительности. Элементы данных

на этом этапе получают атрибуты и определяются как столбцы в таблицах вы-

бранной для реализации БД СУБД.

Рассмотрим применение концепции реляционных баз данных на практи-

ке. Представим себе деятельность туристической фирмы. Очевидно, что для ее

работы необходимо хранить и отслеживать определенный набор информации о

клиентах данной турфирмы (туристах), о предлагаемых им турах, об оформле-

нии и оплате путевок. Это можно делать в обычной бумажной тетради, но со

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

собой довольно рутинную, длительную работу.

1.2.1. Определение требований

Требования к приложению с БД обычно составляются с помощью опро-

сов и бесед с конечными пользователями. Это – итерационный процесс, в ходе

которого разработчики определяют структуру пользовательских диалогов, кри-

терии поиска документов и возможные реакции пользователей.

Общая методика определения и документирования требований к БД за-

ключается в составлении словаря данных. Словарь данных перечисляет и опре-

деляет отдельные элементы данных, которые должны храниться в базе. На-

чальный проект словаря данных для менеджера турфирмы приведен в табли-

це 1.

Таблица 1

Словарь данных для приложения БД менеджера турфирмы

Элемент данных	Описание
Фамилия	Фамилия туриста
Имя	Имя туриста
Отчество	Отчество туриста
Паспорт	Серия и номер паспорта туриста
Телефон	Контактный телефон туриста
Город	Город проживания туриста
Страна	Страна проживания туриста
Индекс	Почтовый индекс адреса туриста
Тур	Название туристической поездки
Цена	Цена туристической поездки
Дата начала	Время начала туристической поездки
Дата конца	Время завершения туристической поездки
Информация	Дополнительная информация о туре
Дата оплаты	Дата оплаты путевки
Сумма	Сумма оплаты

9

Составление словаря – хороший способ, чтобы начать определять требо-

вания к базе данных. Но одного словаря не достаточно для определения струк-

туры БД, так как словарь данных не описывает, как связаны элементы, как дан-

ные создаются, обновляются и выбираются, кто и как будет использовать БД.

Необходима функциональная спецификация, отражающая информацию о

количестве одновременно работающих пользователей, о том, как часто записи

будут вставляться и обновляться, и каким образом информация будет выби-

раться из БД.

Функциональное описание для приложения БД менеджера турфирмы

могло бы включать, например, следующие требования:

 Приложением будут пользоваться руководитель турфирмы, 2 менеджера

по продажам, бухгалтер, кассир и 2 офисных сотрудника турфирмы – все-

го 7 пользователей. Предполагается, что одновременно с БД будут рабо-

тать не более 3 сотрудников. Персоналу бухгалтерии для работы доста-

точно иметь доступ только к данным по оплате путевок.

 Все пользователи в любое время могут добавлять информацию в БД. При

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

изменение, а также дата и время изменения, должны быть зарегистриро-

ваны.

 Один из офисных сотрудников будет назначен системным администрато-

ром. Только он должен вести учетные записи пользователей.

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

одновременно, так как эти документы информационно дополняют друг друга.

Важная часть анализа требований – предупредить потребности пользова-

телей, поскольку они не всегда способны полностью и четко объяснить их соб-

ственные требования к системе. Практически функциональное описание долж-

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