ЧАСТЬ

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

Процесс проектирования

ГЛАВА

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

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

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

Модели жизненного цикла

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

Процесс начинается с системного анализа, иногда называемого анализом требований, так как его цель - выяснить ко-

нечных пользователей к системе. По окончании системного анализа его результаты одобряют участники проекта. Затем производится детальное системы. Далее уточняются сроки и фи-

нансовый план, система создается, тестируется, и поставляется заказчику..

ГЛАВА 6 Процесс проектирования

Системный анализ

Проеклирование системы

Составление бкщжетд

Создание системы

Тбстирование

Сдача системы

Окончание проекта

Рис. 6-1. Модель водопада

Модель водопада эстетически привлекательна. Перед началом каждой новой стадии проекта предыдущая стадия должна быть обязательно закончена, и ее результаты - утверждены. Такой подход позволяет хорошо контролировать бюджет, персонал и рабочее время. Предоставьте результаты проекта в срок, уложитесь в бюджет - и ваш заказчик, по всей вероятности, будет вполне доволен.

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

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