Моделирование систем баз данных

4. Сопровождение  и реинженерия. К таким средствам относятся докумен-таторы, анализаторы программ,(средства реструктурирования и обратной инженерии: Adpac Case Tools (Adpac), Superstructure (Computer Data Systems)...

5. Окружение. Средства поддерживающие платформы для интеграции, создания и придания товарного вида CASE-средствам: Multi/ Cum (ACiS Management Systems), Sylvia Foondey (Codinare).

6. Управление проектом. Средства  поддерживающие планирование, контроль. руководство, взаимодействие, то есть функции. необходимые в процессе разработки и сопровождения проектов: Projeki Workbench (App- lied Business Technology) 

 

II. Классификация  по категориям определяет уровень интегрированности по выполняемым функциям и включает:

1. Вспомогательные программы (Tools), решающие небольшую автономную задачу, принадлежащую проблеме более широкого масштаба.

2. Пакеты разработки (Toolkit), представляющие собой совокупность интегрированных средств, обеспечивающих помощь для одного из классов программных задач.

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

 

III. Классификация по уровням связана с областью действия CASE в пределах жизненного цикла ПО.

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

2. Средние (Middle) CASE считаются средствами поддержки этапов анализа требований и проектирования спецификаций и структуры АС. Основная выгода от использования среднего CASE состоит в значительном облегчении проектирования систем; проектирование превращается в итеративный процесс, включающий действия: пользователь обсуждает с аналитиком требования к информации: аналитик документирует эти требования, используя диаграммы и словари входных данных: пользователь проверяет эти диаграммы н словари, при необходимости модифицируя их; аналитик отвечает на эти модификации изменяя соответствующие спецификации.

Кроме того, средние CASE обеспечивают возможности быстрого документирования требований и прототипирования.

3. Нижние (Lower) CASE поддерживают системы разработки ПО АС (при этом может использоваться до 30% спецификаций, созданных средствами среднего CASE). Они содержат системные словари и графические средства, исключающие необходимость разработки физических спецификаций - имеются системные спецификации, которые непосредственно переводятся в программные коды разрабатываемой системы (при этом автоматически генерируется до 80% кодов). Главными преимуществами нижних CASE является: значительное уменьшение времени на разработку, облегчение модификаций, поддержка возможностей прототипирования (совместно со средними CASE).

В таблице 3 приведены наиболее популярные CASE-средства проектирования данных.

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

Таблица 3 - Наиболее популярные средства проектирования данных

CASE – средство	Производитель	Адрес сайта производителя
Designer 2000	Oracle	http://www.oracle.com/
ERwin	Computer Associates	http://www.cai.com/
PowerDesigner	Sybase	http://www.sybase.com/
ER/Studio	Embarcadero	http://www.embarcadero.com/
System Architect	Popkin Software	http://www.popkin.com/
Visible Analyst	Visible Systems	http://www.visible.com/
Visio Enterprise	Microsoft	http://www.microsoft.com/

 

 

Далее будут кратко рассмотрены  два очень распространенных и  доступных CASE-средства: PowerDesigner фирмы Powersoft и ERwin компании Computer Associates. При проектировании данных при помощи этих CASE-средств используются нотации IE (Information Engineering) и IDEF1X. Разница между этими двумя нотациями на уровне изображения связей показана в таблице 4. На диаграмме связь изображается отрезком (ломаной). Концы отрезка с помощью специальных обозначений указывают степень связи. Кроме того, характер линии - штриховая или сплошная, указывает обязательность связи  

Таблица 4

Нотация	Обозначение связи
IDEF1
IE
любая

 

 

назад | содержание | далее

4.2. CASE-средство PowerDesigner

 

 

Продукт PowerDesigner фирмы Powersoft адресован разработчикам информационных систем. Это графический инструмент для проектирования структуры реляционных баз данных. PowerDesigner реализует популярную методологию информационного моделирования, основанную на представлении информационных объектов и взаимосвязей между ними в виде ER-диаграммы ("сущность-связь"). Используемая в PowerDesigner нотация - IE (Information Engineering).

В S-Designer эффективно реализована связь как со множеством современных СУБД, так и со средствами разработки приложений. По завершении разработки модели данных PowerDesigner генерирует пакеты SQL-предложений для широкого набора СУБД, включая Oracle, Ingres, Informix, Sybase, RDB, SQL Server, DB2, AS/400, SQLBase, Access и Paradox. Имеется встроенный ISQL. Для поддерживаемых СУБД автоматически генерируются триггеры, обеспечивающие ссылочную целостность. Предусмотрена возможность редактировать хранимые процедуры непосредственно при подготовке физической модели. Для обеспечения сопровождения существующих систем PowerDesigner позволяет проводить восстановление модели по структуре базы данных (БД). В течение всего цикла разработки модели данных (рисунок 21) с помощью PowerDesignor могут быть получены разнообразные отчеты по модели.

На  этапе проектирования модели данных PowerDesigner дает возможность определить элементы пользовательского интерфейса будущих приложений, работающих с проектируемой базой данных. Это достигается редактированием репозиториев систем 4GL. В качестве средств разработки поддерживается PowerBuilder, TeamWindows, Progress, Uniface и другие.

PowerDesigner работает в среде Microsoft Windows и Windows NT. В PowerDesigner присутствуют элементы, характерные для программ редактирования - линейка инструментов, интерфейс "drag-and-drop", импорт/экспорт графических файлов, инструменты для создания стандартных графических элементов, управление цветом и шрифтовым выделением.

При работе с PowerDesigner сразу заметны очень высокая скорость отрисовки диаграммы и эффективная реализация интерфейса к СУБД.

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

Цикл разработки в PowerDesigner

При проектировании в PowerDesigner используется двухуровневый подход [5,6]. Первый уровень - концептуальная модель данных (ER-диаграмма). Второй уровень - физическая модель данных. При переходе на второй уровень PowerDesigner автоматически генерирует соответствующую физическую модель данных для заданной СУБД, учитывая специфику последней.

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

Рисунок 21 - Цикл разработки в PowerDesigner 

Особенность реализации цикла разработки в PowerDesigner заключается в том, что он позволяет выполнять "сквозное проектирование". Это значит, что разработав концептуальная модель можно автоматически сгенерировать физическую и после этого выполнить генерацию структуры БД. При обратном проектировании последовательность действий прямо противоположная. Можно получить физическую модель на основе структуры БД и после этого автоматически сгенерировать концептуальную модель. Разумеется на каждом этапе можно вносить изменения в модели концептуального и физического уровней.

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

Последовательность  проектирования модели данных в PowerDesigner

Процесс построения информационной модели данных состоит из следующих шагов:

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

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

- задание первичных и альтернативных ключей;

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

- переход к физическому описанию модели (выполняется автоматически);

- редактирование имен таблиц и их атрибутов на физическом уровне (если в модели имеются, например, связи "многие ко многим" или иерархические рекурсивные связи и их надо уточнить);

- проектирование триггеров, процедур  и ограничений;

- генерация базы данных.

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

Графические элементы диаграммы концептуальной модели

На диаграмме сущность изображается прямоугольником. Атрибуты располагаются  внутри прямоугольника, обозначающего  сущность. Атрибуты, составляющие идентификатор сущности, выделяются подчеркиванием

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

Рисунок 22 - Элементы диаграммы  концептуальной модели 

 

Создание физической модели данных

Физическая модель данных строится после окончания работы над КМД. Необходимость построения ФМД как отдельного шага проектирования объясняется требованием приведения описания сущностей и связей, определенных на стадии построения КМД, к структурам физической СУБД с учетом специфики последней. При генерации физической модели из КМД сущности становятся таблицами, атрибуты - колонками, для альтернативных ключей генерируется уникальный индекс, а идентификаторы становятся первичными ключами. Уникальный индекс автоматически назначается для каждого первичного ключа. Связь "один ко многим" приводит к генерации внешнего ключа и автоматической миграции атрибутов. На рисунке 23 показан фрагмент диаграммы ФМД для сущностей "отдел" и "сотрудник".

Рисунок 23 - Связь один ко многим на диаграмме физической модели

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

Рисунок 24 - Исходная концептуальная модель 

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

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

Рисунок 25 - Результат  автоматического преобразования в  физическую модель 

 

Описание ссылочной  целостности 

В PowerDesigner существует несколько вариантов правил, которые могут применяться для обеспечения ссылочной целостности.

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

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

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

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