Корпоративные базы данных - статьи

       

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



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

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


информации.

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

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

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


  • утилита автоматической генерации спецификаций базы данных по ER-
    модели;
  • процедура генерации спецификаций модулей по иерархии функций и
    потокам данных.

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

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

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


общего модуля. Разработчику предоставляется возможность регулировать уровень "объединения"
функций путем выбора одного из имеющегося набора критериев.

Для работы со всевозможными спецификациями уровня проектирования в DESIGNER/2000
предусмотрен целый набор графических редакторов, каждый из которых ориентирован на
спецификации определенного типа.

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

В DESIGNER/2000 для этой цели предусмотрены:


  • редактор схем баз данных
  • редактор диаграмм взаимосвязей между модулями
  • редактор схем использования данных в модуле (или схем модуля)

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

На диаграмме схемы базы данных в виде прямоугольников изображаются таблицы и
представления (view), а соединяющие их линии соответствуют взаимосвязям между таблицами,
задаваемые внешними ключами (рис. 14).



Содержание раздела