Здесь дается краткое описание этапа проектирования. Более подробно о том, что происходит на этом этапе, мы расскажем в разделах Планирование этапа проектирования и Задачи проектирования.

Примечание

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

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

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

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

Проектировщики должны обеспечить согласованность схемы базы данных и модулей не только с результатами анализа, но и между собой. Например, таблица RENTAL CARS, полученная из сущности Rental Саг ( Автомобиль напрокат ), должна где-то иметь модуль, позволяющий вставлять в нее новые автомобили. Одна из ключевых целей проектирования - обеспечение хорошей работы системы после реализации с учетом ограничений, наложенных архитектурой целевой системы. По этой причине проектировщикам нужно тщательно изучить саму архитектуру. Например, требование к пропускной способности сервера базы данных может привести к рассмотрению возможности использования параллельной обработки. Можно выбрать и другие методы распределения обработки между клиентом и сервером. Мы подробно рассмотрим эти варианты в главе 14 и главе 11.

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

г----,

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

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

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

На этапе проектирования получают много результатов, и в каждом проекте они разные. Однако для каждого Oracle-проекта должна быть составлена схема базы данных (или схемы, если данные будут распределены), и почти для каждого - некоторые формальные спецификации модулей. Примеры приведены в табл. 1.1 и на рис. 1.5. Результаты анализа и проектирования показаны на рис. 1.6.

Таблица 1.1. Пример спецификации модуля

20 Пг..г,1

CATEGORIES

CODE

DESCRIPTION

CREATE TABLE CATl DESGRIPTIOHVARC! CONSTRAINT GAT Pl

lES (CODE VARCHAR(6) NOT NULL, (2000)

MARY KEY CODE)..,

Puc. 1.5. Пример схемы базы данных и определения данных

Анализ

Результаты

Результаты Реализация

Модели сущность-отношение Диаграммы потока данных Жизненные циклы сущностей

Определения сущностей Уникальные идентификаторы Функциональные определения Функциональная декомпозиция

Определения таблиц Определения столбцов Ограничения таблиц Триггеры Физическая база данных Спецификации модулей План тестирования системы

Рис. 1.6. Результаты этапов анализа и проектирования

Реализация

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

Гг,.г.--.