Рабочее (физическое) проектирование

Если при даталогическом проектировании разработчик сосредотачивается на том, что надо сделать, то при физическом проектировании он ищет способ, как это сделать. Речь идет о реализации проекта в среде конкретной СУБД. Это требует от разработчика специальных знаний относительно функциональных возможностей целевой СУБД, а также навыков работы в ее среде.

Основной целью физического проектирования базы данных является описание способа физической реализации логического проекта базы данных. Физическому уровню представления базы данных в компьютере соответствует внутренняя модель данных [1,6,7], которая определяет структуры хранимых данных и методы доступа к ним. В отличие от ранних СУБД, современные реляционные системы предоставляют разработчику небогатый выбор на этапе физического проектирования [6]. Способ хранения базы данных определяется механизмами СУБД автоматически «по умолчанию» на основе спецификаций концептуальной схемы базы данных, а внутренняя схема в явном виде в таких системах не используется.

Основными видами работ на данном этапе проектирования являются:

1. 1)  генерация схем данных всех уровней (концептуальной схемы и подсхем приложений);

2. 2)  разработка комплекса программ для реализации алгоритмов обработки данных;

3. 3)  разработка интерфейса конечного пользователя, в том числе пользовательских меню, экранных форм, шаблонов печатных документов;

4. 4)  создание прототипа базы данных;

5. 5)  разработка контрольных примеров, обеспечивающих многоцелевое тестирование базы данных и прикладных программ;

6. 6)  разработка инструкций для всех категорий пользователей.

Содержание проекта

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

1. 1.   Предпроектный анализ предметной области и инфологическое проектирование.

2. 2.   Даталогическое проектирование.

3. 3.   Рабочее проектирование.

Предпроектный анализ предметной области и инфологическое проектирование

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

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

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

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

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

Функциональный аспект. На этапе анализа предметной области должно быть выполнено функциональное моделирование и разработана функциональная модель предметной области. Должны быть построены (например, в среде BPwin) контекстная диаграмма предметной области, а также диаграммы декомпозиции с детализацией, достаточной для адекватного представления функционирования предметной области. Должна быть построена диаграмма иерархии функций (Node Tree-диаграмма) [10]. Диаграммы декомпозиции должны сопровождаться спецификациями функций (работ) и данных (стрелок), сопутствующих их выполнению.

Информационный аспект. На этапе анализа предметной области должна быть разработана также информационная модель предметной области в терминах сущностей и связей. Моделируемая предметная область должна быть «в меру» сложной, т.е. представленной не менее чем 5-6 сущностями, имеющими самостоятельное значение. ER-диаграмма должна сопровождаться спецификациями сущностей, атрибутов, связей и ограничений ссылочной целостности.

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