Задачи и структура процесса проектирования

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

· Корректность схемы БД, а именно:

- каждому объекту ПО соответствуют данные в памяти ЭВМ,

- каждому процессу ПО соответствуют адекватные процедуры обработки данных.

· Обеспечение целостности:

- формулировка ограничений,

- описание правил применения ограничений,

- описание правил обработки данных при нарушении ограничений целостности.

· Защита данных:

- защита от разрушений при сбоях оборудования (восстанавливаемость данных),

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

- от несанкционированного доступа (безопасность данных).

· Обеспечение ограничений на аппаратные и программные ресурсы вычислительной системы.

· Эффективность функционирования;

- эффективность использования ресурсов,

- обеспечение требований ко времени реакции системы на запросы и обновление БД.

· Простота и удобство в эксплуатации.

· Гибкость – возможность развития и последующей адаптации системы к изменениям в ПО и к новым потребностям пользователей.

Удовлетворение первых 4-х требований обязательно для принятия проекта.

В структуре процесса проектирования выделим следующие этапы:

Этап 1. Формулировка и анализ требований, включающий:

Шаг 1. Сбор и анализаприорной информации о ПО,

Шаг 2. Анализ и синтез инфологической модели ПО.

Этап 2. Проектирование концептуальной схемы.

Этап 3. Физическое проектирование.

На каждом из этапов решаются следующие основные задачи.

Этап 1.

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

Специфические цели и требования к БД необходимо определить на самом высоком уровне организации-заказчика (уровень АПО). Собранные и документированные требования должны включать ограничения, обусловливающие:

- безопасность,

- надежность,

- уровень достигнутой технологии,

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

Шаг 2. Описываются и анализируются разнообразные информационные требования пользователей и производится синтез первоначального проекта базы данных. Результатом этого этапа является «бумажное» высокоуровневое представление требований в виде, например, ER-модели (модели сущность-связь»). На этом этапе осуществляется:

- определение сущностей,

- определение атрибутов сущностей,

- идентификация ключевых атрибутов сущностей,

- определение связей между сущностями.

Требования каждого пользователя анализируются и представляются в некоторой общей форме. Объекты и события, ассоциированные с представлениями каждого пользователя, моделируются множеством сущностей, атрибутов и связей между сущностями. Эти требования, представленные, например, набором локальных ER-моделей, анализируются и сливаются в единое глобальное представление. Очевидно, что в процессе анализа должны быть выявлены и ликвидированы противоречивые и избыточные данные (более подробно этот этап рассмотрен в 4.2.3.).

Этап 2. После построения первоначальной информационной структуры следует ее уточнение и совершенствование. Главная цель – создание СУБД-ориентированной концептуальной схемы с использованием в качестве исходных данных результатов инфологического проектирования и требований обработки данных.

На данном этапе проектируются также многочисленные приложения. Результатом проектирования программного обеспечения являются:

· интерфейсы приложений,

· функциональные характеристики приложений,

· наборы возможных запросов к БД,

Построенная схема может быть оценена количественно с помощью таких характеристик, как:

· число обращений к логическим записям каждого приложения,

· объем обрабатываемых в каждом приложении данных,

· общий объем хранимых данных.

Эти оценки помогают приблизительно определить эффективность функционирования физической БД в терминах затрачиваемого на обработку времени и требуемой физической памяти.

Этап 3. Рассмотрению вопросов физического проектирования базы данных посвящена отдельная глава данного пособия. Здесь лишь отметим, что параметры внутренней (физической) модели БД принципиальным образом влияют на эксплуатационные характеристики информационной системы.

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

 

 

 

Рис. 8. Прямой и итеративный варианты в каскадной методологии

4.2.3. Формулирование и анализ требований. Инфологическое проектирование

Шаг 1. Сбор и анализаприорной информации о ПО

Проектирование базы данных – это процесс разработки ее структуры в соответствии с информационными требованиями пользователей, поэтому он включает в себя опрос будущих пользователей для того, чтобы понять и задокументировать их требования. АБД следует выяснить следующие вопросы:

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

· как требования пользователей могут быть преобразованы в эффективную структуру базы данных;

· какие данные используются разными приложениями; смогут ли приложения совместно использовать какие-либо из этих данных;

· сможет ли новая система объединить существующие приложения или их необходимо будет кардинально переделывать для совместной работы с новой системой;

· кто будет вводить данные в базу и в какой форме; как часто будут изменяться данные;

· достаточно ли будет для ПО одной базы или потребуется несколько баз данных с различными структурами;

· какая информация является наиболее чувствительной к скорости ее извлечения и изменения;

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

Согласно [3], на этом шаге осуществляется:

1. Определение сферы применения.

2. Сбор информации об использовании данных.

3. Преобразование инфомационных требований.

Рассмотрим каждый из этих пунктов подробнее.