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

Рассмотрим вопросы создания и реализации БД, которые приведены в гл. 14 и 15, словесное описание дано в гл. 1 (примеры 1.1 и 1.2).

Речь пойдет о наиболее распространенных реляционных операционных базах данных [27−37]. Создание объектно-ориентированных баз данных имеет свою специфику [38] и в настоящей работе не рассматривается.

Напомним, что эти примеры характеризуют соответственно традиционный и современный подходы к созданию БД.

В данной главе детально обсуждается пример 1.1 гл. 1 с его реализацией в двух вариантах: в СУБД Access и в СУБД InterBase с использованием программного продукта Delphi.

Первый, локальный, вариант предназначен для начинающих пользователей, второй, сетевой, — для «продвинутых» пользователей, знающих основы программирования хотя бы в рамках языка Pascal.

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

Процедура проектирования баз данных

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

Последовательность этапов проектирования показана на рис. 2.6. Рассмотрим этапы более подробно.

Анализ требований

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

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

Первый этап получил более точные названия [1−6], наиболее удачным из которых, по мнению авторов, является [2] «планирование базы данных» .

При этом выявились [4] два подхода к проектированию БД:

• 1) традиционный (классический), сформировавшийся в 80-е годы XX века и применяемый до сих пор в информационно-поисковом режиме АСУ;
• 2) современный, формирование которого началось в 90-е годы и продолжается до настоящего времени с использованием в информационно-советующем режиме систем поддержки принятия решений.

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

Второй подход исходит из решения задачи [44], т. е. от алгоритма приложения, на основе которого и создается база данных. Под приложением понимается программа или группа программ, предназначенных для выполнения определенных однотипных работ.

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

Во втором подходе сформировалась следующая технология.

• 1. Определение цели проектирования.
• 2. Выявление логики приложения.
• 3. Планирование схемы связей приложения (системы таблиц), иногда называемой DLL-сценарием.

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