Задачи и структура процесса проектирования
Проектирование базы данных - одна из наиболее сложных и ответственных задач, связанных с созданием информационной системы. В результате ее решения должны быть определены содержание БД, эффективный для всех ее будущих пользователей способ организации данных и инструментальные средства управления данными. Основная цель процесса проектирования БД состоит в получении такого проекта, который удовлетворяет следующим требованиям:
Корректность схемы БД, а именно:
- каждому объекту ПО соответствуют данные в памяти ЭВМ,
- каждому процессу ПО соответствуют адекватные процедуры обработки данных.
Обеспечение целостности:
- формулировка ограничений,
- описание правил применения ограничений,
- описание правил обработки данных при нарушении ограничений целостности.
Защита данных:
защита от разрушений при сбоях оборудования (восстанавливаемость данных),
от некорректных обновлений (согласованность методов модификации данных),
от несанкционированного доступа (безопасность данных).
Обеспечение ограничений на аппаратные и программные ресурсы вычислительной системы.
Эффективность функционирования;
- эффективность использования ресурсов,
- обеспечение требований ко времени реакции системы на запросы и обновление БД.
Простота и удобство в эксплуатации.
Гибкость – возможность развития и последующей адаптации системы к изменениям в ПО и к новым потребностям пользователей.
Удовлетворение первых 4-х требований обязательно для принятия проекта.
В структуре процесса проектирования выделим следующие этапы:
Этап 1. Формулировка и анализ требований, включающий:
Шаг 1. Сбор и анализ априорной информации о ПО,
Шаг 2. Анализ и синтез инфологической модели ПО.
Этап 2. Проектирование концептуальной схемы.
Этап 3. Физическое проектирование.
На каждом из этапов решаются следующие основные задачи.
Этап 1.
Шаг 1. Устанавливаются цели организации, определяются специфические требования к БД, вытекающие из этих целей или сформулированные непосредственно управляющим персоналом организации. Эти требования документируются в форме, доступной как конечному пользователю, так и проектировщику БД.
Специфические цели и требования к БД необходимо определить на самом высоком уровне организации-заказчика (уровень АПО). Собранные и документированные требования должны включать ограничения, обусловливающие:
- безопасность,
- надежность,
- уровень достигнутой технологии,
Должна быть также оценена политика организации в отношении персонала, управленческой деятельности и перспектив роста организации.
Шаг 2. Описываются и анализируются разнообразные информационные требования пользователей и производится синтез первоначального проекта базы данных. Результатом этого этапа является «бумажное» высокоуровневое представление требований в виде, например, ER-модели (модели сущность-связь»). На этом этапе осуществляется:
- определение сущностей,
- определение атрибутов сущностей,
- идентификация ключевых атрибутов сущностей,
- определение связей между сущностями.
Требования каждого пользователя анализируются и представляются в некоторой общей форме. Объекты и события, ассоциированные с представлениями каждого пользователя, моделируются множеством сущностей, атрибутов и связей между сущностями. Эти требования, представленные, например, набором локальных ER-моделей, анализируются и сливаются в единое глобальное представление. Очевидно, что в процессе анализа должны быть выявлены и ликвидированы противоречивые и избыточные данные (более подробно этот этап рассмотрен в 4.2.3.).
Этап 2. После построения первоначальной информационной структуры следует ее уточнение и совершенствование. Главная цель – создание СУБД-ориентированной концептуальной схемы с использованием в качестве исходных данных результатов инфологического проектирования и требований обработки данных.
На данном этапе проектируются также многочисленные приложения. Результатом проектирования программного обеспечения являются:
интерфейсы приложений,
функциональные характеристики приложений,
наборы возможных запросов к БД,
Построенная схема может быть оценена количественно с помощью таких характеристик, как:
число обращений к логическим записям каждого приложения,
объем обрабатываемых в каждом приложении данных,
общий объем хранимых данных.
Эти оценки помогают приблизительно определить эффективность функционирования физической БД в терминах затрачиваемого на обработку времени и требуемой физической памяти.
Этап 3. Рассмотрению вопросов физического проектирования базы данных посвящена отдельная глава данного пособия. Здесь лишь отметим, что параметры внутренней (физической) модели БД принципиальным образом влияют на эксплуатационные характеристики информационной системы.
Процесс проектирования хорошо структурирован, так как каждый его этап завершается четко определенным результатом, и допускает итеративное повторение в случае, если полученный результат не соответствует требованиям заказчиков или сформулированным ограничениям, либо если возникают дополнительные требования. В общем случае это позволяет проектировщику пересматривать проектные решения с любого предыдущего этапа. Схема метода нисходящего (каскадного) проектирования с последовательными итерациями представлена на рис. 8.
Рис. 8. Прямой и итеративный варианты в каскадной методологии