для Oracle?, где бизнес-правила могут создаваться как ограничения и другие резидентные объекты базы данных, например, как хранимые процедуры.

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

Выявить нереализуемые и необьиные конструкции данных в модели сущность-отнощение и в определениях сущностей (глава 3).

Разрешить все дуги, супертипы и подтипы (глава 3).

Изучить все первичные и внешние ключи (главы 3 и 6).

Спроектировать и реализовать денормализацию базы данных с целью ускорения обработки запросов во всех критичных по времени приложениях (глава 4).

Определить, какие прикладные процессы необходимо реализовать в схеме базы данных как хранимые процедуры (глава 16).

Выявить и реализовать ограничения, предназначенные для обеспечения целостности данных и реализации правил для данных (главы 15 и 16).

Спроектировать и сгенерировать триггеры для реализации всех централизованно определенных правил для данных и правил целостности данных, которые не могут быть заданы как ограничения (глава 15).

Разработать стратегию индексирования и кластеризации (глава 6).

Выполнить оценку размеров всех таблиц, кластеров и индексов (глава 9).

Определить уровни доступа пользователей, разработать и внедрить правила обеспечения безопасности и аудита. Создать роли и синонимы для обеспечения многопользовательского доступа с согласованными уровнями полномочий доступа (глава 10).

Разработать сетевую топологию базы данных и механизм бесшовного доступа к удаленным данным (реплицированная или распределенная база данных) (глава 12).

Создание базы данных для разработки

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

Для нашей системы проката автомобилей мы создаем экземпляры DEVI, IEV2 и DEV3. Они будут циклически использоваться для обозначения версий разрабатываемой базы данных. Такой карусельный подход гарантирует, что разработчики, находящиеся на полпути в разработке модуля, не

будут сбиты с толку новой редакцией базы данных. Мы создаем еще один экземпляр, SYSTEST.

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

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

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

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

Выбор инструментов для реализации

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

Отображение функции в модули

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

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

В нащей системе проката автомобилей имеется функция для составления счета для отдельного клиента и функция для ежемесячного составления счетов. Эти задачи имеют много общего, поэтому мы создадим модуль под именем Calculate bill for Customer (составить счет для клиента), который будет непосредственно вызываться из экранной формы или программы ежемесячного создания счетов. В этот модуль передается идентификатор клиента и пара дат, а возвращает он сумму, которую клиент должен уплатить заданный период.

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

Обеспечение перелгеиения по программам

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

В нащей системе проката автомобилей мы строим гибкий механизм перемещения. Например, мы позволяем пользователю искать в одном окне запись клиента, а в другом - свободный автомобиль; оба эти элемента можно копировать в контекстную область . Когда пользователь открывает экранную форму Rent Car, данные об автомобиле и клиенте автоматически переносятся туда из контекстной области. Альтернативный метод: пользователь может сразу перейти к экранной форме Rent Car без контекста и выполнить поиск, в результате которого данные будут втянуты в эту форму.

Создание определений или спецификации модулей

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

преобразовать функциональные определения анализа в реализуемые модули;

написать спецификацию, выражающую функциональные возможности в физических категориях;

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