Процесс проектирования БД представляет
собой последовательность переходов от неформального словесного описания
информационной структуры предметной области к формализованному описанию
объектов предметной области в терминах некоторой модели. В общем случае
можно выделить следующие этапы проектирования:
1) Системный анализ и словесное описание информационных объектов предметной области.
2)
Проектирование инфологической модели предметной области — частично
формализованное описание объектов предметной области в терминах
некоторой семантической модели, например, в терминах Е-модели.
3) Даталогическое или логическое проектирование БД, то есть описание БД в терминах принятой диалогической модели данных.
С точки зрения проектирования БД в
рамках системного анализа, необходимо осуществить первый этап, то есть
провести подробное словесное описание объектов предметной области и
реальных связей, которые присутствуют между описываемыми объектами.
Желательно, чтобы данное описание позволяло корректно определить все
взаимосвязи между объектами предметной области.
В общем случае существуют два подхода к выбору состава и структуры предметной области:
Функциональный
подход — он реализует принцип движения «от задач» и применяется тогда,
когда заранее известны функции некоторой группы лиц и комплексов задач,
для обслуживания информационных потребностей которых создается
рассматриваемая БД. В этом случае мы можем четко выделить минимальный
необходимый набор объектов предметной области, которые должны быть
описаны.
Предметный подход — когда информационные потребности будущих пользователей БД жестко не фиксируются. Они могут быть многоаспектными и весьма динамичными. Мы не можем точно выделить минимальный набор объектов предметной области, которые необходимо описывать. В описание предметной области в этом случае включаются такие объекты и взаимосвязи, которые наиболее характерны и наиболее существенны для нее. БД, конструируемая при этом, называется предметной, то есть она может быть использована при решении множества разнообразных, заранее не определенных задач. Конструирование предметной БД в некотором смысле кажется гораздо более заманчивым, однако трудность всеобщего охвата предметной области с невозможностью конкретизации потребностей пользователей может привести к избыточно сложной схеме БД, которая для конкретных задач будет неэффективной.
Чаще всего па практике рекомендуется использовать некоторый компромиссный вариант, который, с одной стороны, ориентирован на конкретные задачи или функциональные потребности пользователей, а с другой стороны, учитывает возможность наращивания новых приложений.
Системный анализ должен заканчиваться подробным описанием информации об объектах предметной области, которая требуется для решения конкретных задач и которая должна храниться в БД, формулировкой конкретных задач, которые будут решаться с использованием данной БД с кратким описанием алгоритмов их решения, описанием выходных документов, которые должны генерироваться в системе, описанием входных документов, которые служат основанием для заполнения данными БД.
