Р ис.39. Вид схемы в браузере Rational Rose (Data Modeler) р ис.40. Пакет со стереотипом «Schema» (Data Modeler)

Рис.41. Вид схемы в браузере Rational Rose (Oracle8)

Рис.42. Компонент со стереотипом «Schema» (Oracle8)

Домены

Описание прототипов для сходных атрибутов таблиц помещается в домены (Рисунки 43 и 44). В дальнейшем, при описании таблиц, указав для атрибута домен, автоматически осуществляется определение типа, индекса, ограничений.

Р ис.43. Отображение доменов в браузере Rational Rose

Рис.44. Отображение доменов на диаграмме классов

Таблица, просмотр, хранимые процедуры

Н а рисунке 45 показан пример диаграммы классов (Data Model Diagram), содержащий таблицы: EMP, DEPT; просмотр: V_0; хранимые процедуры: SP_0.

Рис.45. Пример диаграммы реляционной схемы БД

Объектный тип, реляционная таблица, объектная таблица, встраиваемая таблица, реляционный просмотр, объектный просмотр, коллекция

На рисунке 46 показан пример диаграммы классов (Oracle 8), содержащий:

- OT1 – объектный тип;

- V1 – коллекцию объектов (максимум 30) типа ОТ1;

- OTBL1 – объектную таблицу, содержащую объекты типа ОТ1;

- NT1 – встраиваемую таблицу, содержащую объекты типа ОТ1, являющуюся типом атрибута T1 таблицы RT4;

- OV1 – объектный просмотр, типа ОТ1, содержащий объекты, значения атрибутов которых инициализируются значениями атрибутов реляционной таблицы RT1

- RT1, RT2, RT4 – реляционные таблицы;

- RV1 – реляционный просмотр, в котором задействованы атрибуты таблиц RT2 и RT1.

Рис.46. Пример диаграммы объектно-реляционной схемы БД

2.8.3.2. Прямая и обратная генерация схем бд

2.8.3.2.1. Формирование схем на основе диаграмм классов

Процесс преобразование логической модели данных, представленной каноническими диаграммами классов, в схемы БД заключается в интерпретации существующих объектов модели в объекты схемы. Такая интерпретация может быть проведена вручную, путем использования мастеров создания и описания объектов схемной модели, а может быть выполнена автоматически. Rational Rose предоставляет возможности автоматического преобразования диаграммы классов в реляционную схему БД для выбранной СУБД, путем применения утилиты Rose Data Modeler.

Создание компоненты БД

На диаграмме компонентов, используя функцию «Data Modeler–>New–>Database», можно создать компонент БД (Рисунок 47). Для компонента определяется имя, целевая СУБД и текстовое описание. Вид целевой СУБД определяет специфику описания объектов БД и диалект SQL для генерации кода БД. Rose Data Modeler поддерживает следующие виды СУБД (DBMS):

- ANSI SQL 92 (по умолчанию),

- IBM DB2 5.x/6.x/7.x,

- IBM DB2 OS390 5.x/6.x,

- Microsoft SQL Server 6.x/7.x/2000.x,

- Oracle 7.x/8.x,

- Sybase Adaptive Server 12.x.

Рис.47. Компонент БД и клиентское приложение

Зависимости между БД и компонентами, являющимися частью ПО, должны быть отражены вручную.

Определение табличных пространств

Д ля созданной БД можно определить табличные пространства. Выбрав компонент БД, командой «Data Modeler–>New–>Tablespace», можно создать табличное пространство (Рисунок 48). Для табличного пространства определяется, помимо имени, файл БД, для его физического хранения. С ним связываются все объекты схем БД, которые создаются для данного табличного пространства.

Рис.48. Компонент табличное пространство, определенный для БД

Зависимость между БД и табличным пространством отображается на диаграммах автоматически.

Создание доменов

Командой «Data Modeler–>New–>Domain Package» создается пакет, группирующий определяемые домены. Для пакета определяется вид целевой СУБД. Он должен соответствовать СУБД, для которой проектируются схемы, с использованием создаваемых доменов. В пакете, командой «Data Modeler–>New–>Domain», создаются домены (Рисунки 43 и 49). При этом указывается:

- скалярный тип домена;

- значение по умолчанию;

- ограничения на уникальность (Unique Constraint) и на обязательность присутствия значения (Not Null);

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

Рис.49. Домен с ограничением на возможные значения

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

Схему можно создать вручную. Для этого командой «Data Modeler–>New–>Schema» создается схема. Для схемы можно создать диаграмму реляционной схемы БД (Data Model Diagram) на которой могут быть отображены создаваемые таблицы, просмотры и хранимые процедуры. Для схемы указывается имя и БД, для которой она проектируется.

Автоматическое генерация схемы предполагает наличие пакета с «постоянными» (persistent) классами. Такие классы отображаются в таблицы. В таблицы также раскрываются связи-ассоциации многие ко многим. Автоматическое создание схемы выполняется при помощи команды «Data Modeler–>Transform To Data Model», применяемой к пакету с классами логической модели данных. Между пакетом с исходными классами и пакетом-схемой обычно указывается связь зависимость, существенная для модели ИС в целом (см. рис.50).

Рис.50. Пакет с классами и созданная на его основе схема

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

«Постоянные» (persistent) классы автоматически отображаются в таблицы, при этом не учитываются операции классов (см. рис.51). Для таблицы после её генерации можно указать табличное пространство, для реализации.

Рис.51. Класс «Item» c соответствующей таблицей

Атрибуты классов автоматически становятся атрибутами таблиц. Типы атрибутов таблиц формируются на основе соответствия между скалярными типами диаграмм классов и типами, принятыми в диалекте SQL целевой СУБД. Например, для Oracle 8.x: Long преобразуется в NUMBER (10), String – VARCHAR2, Double – NUMBER (20).

Для атрибутов могут быт указаны:

- домен;

- тип;

- значение по умолчанию;

- ограничения на уникальность (Unique Constraint) и на обязательность присутствия значения (Not Null);

- произвольное число ограничений на возможные значения атрибута.

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

В

<<PK>> PK_OTCustomer22()

<<FK>> FK_OTCustomer16()

<<Trigger>> TRIG_OTCustomer0()

<<Unique>> TC_OTCustomer271()

<<Check>> TC_OTCustomer272()

<<Index>> TC_OTCustomer274()

PK OTUser_ID:NUMBER(10,0)

money: NUMBER(5,0)

Any: NUMBER(5,0)

OTCustomer

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

Рис.52. Таблица с определенными ограничениями, индексным атрибутом и триггерами

Преобразования зависимостей

Связи-ассоциации 1:1 и 1:N автоматически преобразуются в не идентифицирующие связи. Пример преобразования показан на рисунке 53.