Оглавление Назад Далее

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

2.3.1. Уровни физической модели *

2.3.2. Выбор сервера *

2.3.3. Таблицы, колонки и представления (view) *

2.3.4. Правила валидации и значения по умолчанию *

2.3.5. Индексы *

ORACLE *

2.3.6. Задание объектов физической памяти *

2.3.7. Триггеры и хранимые процедуры *

2.3.8. Проектирование хранилищ данных *

2.3.9. Вычисление размера БД *

2.3.10. Прямое и обратное проектирование *

 

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

2.3.1. Уровни физической модели

 

Различают два уровня физической модели:

Физическая модель содержит всю информацию, необходимую для реализации конкретной БД. Трансформационная модель содержит информацию для реализации отдельного проекта, который может быть частью общей ИС и описывать подмножество предметной области. ERwin поддерживает ведение отдельных проектов, позволяя проектировщику выделять подмножество модели в виде предметных областей (Subject Area). Трансформационная модель позволяет проектировщикам и администраторам БД лучше представлять, какие объекты БД хранятся в словаре данных, и проверить, насколько физическая модель данных удовлетворяет требованиям к ИС.

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

 

2.3.2. Выбор сервера

 

Физический уровень представления модели зависит от выбранного сервера. Для выбора СУБД служит редактор Target Server (меню Server/Target Server... доступно только на физическом уровне) (рис. 2.60).

ERwin поддерживает практически все распространенные СУБД, всего более 20 реляционных и нереляционных БД. Для выбора СУБД нужно щелкнуть по соответствующей кнопке рядом с именем СУБД.

Диалог Target Server позволяет задать тип данных и опцию NULL для новых колонок, а также правила ссылочной целостности, принимаемые по умолчанию. Тип данных можно выбрать в раскрывающемся списке Default Datatype, который автоматически заполняется типами данных, поддерживаемых выбранным сервером. Установка правил ссылочной целостности по умолчанию была рассмотрена в 2.2.3.

Группа кнопок Default Non-Key Null Option позволяет разрешить или запретить значения NULL для неключевых колонок.

Окно выбора Allow special chars in names позволяет разрешить или запретить использование специальных символов и пробелов в именах таблиц. Эта опция действует только для тех СУБД, которые поддерживают использование специальных символов.

Рис. 2.60. Диалог Target Server

 

По умолчанию ERwin генерирует имена таблиц и индексов по шаблону на основе имен соответствующих сущностей и ключей логической модели. Окна Table Name Macro и Index Name Macro позволяют изменить шаблон генерации имен, заданный по умолчанию. В дальнейшем имена таблиц и индексов можно изменить вручную.

Кнопка Reset Names вызывает диалог Globally Reset DBMS Property (рис. 2.61), который позволяет заменить все имена таблиц, связей, индексов, колонок и соответствующих свойств, заданных вручную, на значения по умолчанию.

Имена таблиц и колонок по умолчанию будут сгенерированы на основе имен сущностей и атрибутов логической модели. Если в имени сущности или атрибута встречается пробел, он будет заменен на символ "_".

При смене СУБД ERwin предлагает автоматически преобразовать тип данных, связанный с каждым атрибутом, на ближайший, доступный для новой СУБД. Для автоматического преобразования следует в ответ на запрос нажать Yes.

Рис. 2.61. Диалог Globally Reset DBMS Property

 

2.3.3. Таблицы, колонки и представления (view)

 

Для внесения новой таблицы в модель на физическом уровне служит кнопка на палитре инструментов. Связи между таблицами создаются так же, как на логическом уровне. Щелкнув правой клавишей мыши по таблице и выбрав во всплывающем меню пункты Table Editor или Column Editor, можно вызвать редакторы для задания свойств таблиц и колонок.

ERwin автоматически создает имена таблиц и колонок на основе имен соответствующих сущностей и атрибутов, учитывая максимальную длину имени и другие синтаксические ограничения, накладываемые СУБД. При генерации имени таблицы или колонки по умолчанию все пробелы автоматически преобразуются в символы подчеркивания, а длина имени обрезается до максимальной длины, допустимой для выбранной СУБД. Все изменения, сделанные в Table Editor или Column Editor, не отражаются на именах сущностей и атрибутов, поскольку информация на логическом и физическом уровнях в ERwin хранится отдельно.

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

Рис. 2.62. Диалог Table Editor

 

Окно Name служит для задания имени текущей таблицы. Окно Owner позволяет внести имя владельца таблицы, отличное от имени пользователя, производящего генерацию схемы БД. Окно выбора Physical Only служит для создания объектов только на физическом уровне. Если выбрана опция Generate, при генерации схемы БД будет выполняться команда CREATE TABLE. Кнопка DB Sync служит для немедленной синхронизации модели с системным каталогом БД.

Диалог Table Editor содержит следующие закладки:

Dimensional. Доступна только на уровне моделирования хранилищ данных (Dimensional Modeling) и будет рассмотрена ниже.

Comment. Внесение комментария к таблице.

Volumetrics. Служит для оценки размера БД.

Physical Props. Позволяет задать физические свойства таблицы.

Partitions. Служит для задания значений разделения. Доступна только для Oracle 8.x.

UDP. Задание свойств, определяемых пользователем.

Validation. Задание правил валидации.

Synonym. Задание синонимов таблицы (если сервер таковые поддерживает).

Stored Procedure. Связывание с таблицей хранимых процедур.

Pre & Post Script. Создание скриптов (наборов команд), которые будут выполняться до и после создания таблицы при генерации схемы БД.

PowerBuilder. Задание расширенных атрибутов для генерации кода клиентского приложения на PowerBuilder.

Для задания свойств колонок, отличных от значения по умолчанию, служит редактор Column Editor (рис. 2.63). Чтобы вызвать его, нужно щелкнуть правой клавишей мыши по таблице и выбрать во всплывающем меню пункт Column Editor.

По умолчанию ERwin присваивает режимы нулевых значений всем неключевым колонкам, исходя из значений по умолчанию, устанавливаемых в редакторе Target Server. Для колонок первичного ключа и альтернативных ключей .устанавливается режим NOT NULL. Режим NOT NULL не присваивается автоматически инверсионным входам (Inversion Entry).

Рис. 2.63. Диалог Column Editor

 

Внешне диалог Column Editor напоминает диалог Attribute Editor (см. рис. 2.14). В правой части диалога находятся закладки:

General. Позволяет присвоить колонку определенному домену, создать колонку только на физическом уровне и включить ее в состав первичного ключа.

Закладка, соответствующая выбранной СУБД (на рис. 2.63 и 2.64 -ORACLE). Имя закладки устанавливается автоматически соответствующей выбранной СУБД. Позволяет задать тип данных, опцию NULL, правила валидации и значение по умолчанию. Правила валидации и значение по умолчанию должны быть описаны и именованы предварительно соответственно в диалогах Validation Rule Editor и Default/Initial Eritor. Для вызова этих диалогов служат кнопки !!! справа от соответствующих раскрывающихся списков. Для СУБД Access, AS/400, PROGRESS и Teradata создаются дополнительные закладки для задания свойств.

Рис. 2.64. Закладка СУБД диалога Column Editor

 

Comment. Служит для внесения комментария к каждой колонке.

UDP. Задание свойств, определяемых пользователем.

Data Source. Доступна только при моделировании хранилищ данных (см. ниже).

Index. Служит для включения колонки в состав индексов.

Visual Basic и PowerBuilder. Задание расширенных атрибутов для генерации кода клиентского приложения.

В левой части диалога содержится упорядоченный список колонок таблицы. Кнопки U ”, “U предназначены для перемещения колонки в списке на позицию вверх и вниз. Кнопки New, Rename и Delete служат соответственно для создания, переименования и удаления колонки. При помощи кнопки Reset можно переустановить свойства колонки, заданные вручную, на значения по умолчанию. Кнопка DB Sync позволяет запустить процесс синхронизации модели с системным каталогом БД.

При создании связи колонки первичного ключа родительской таблицы мигрируют в состав колонок дочерней таблицы в качестве внешнего ключа. Кнопка Migrate вызывает диалог Migrate Column Property (рис. 2.65), который позволяет определять, какие характеристики мигрировавшей колонки будут сохранены в дочерней таблице.

Рис. 2.65. Диалог Migrate Column Property

 

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

Представления (view), или, как их иногда называют, временные или производные таблицы, представляют собой объекты БД, данные в которых не хранятся постоянно, как в таблице, а формируются динамически при обращении к представлению. Представление не может существовать само по себе, а определяется только в терминах одной или нескольких таблиц. Применение представлений позволяет разработчику БД обеспечить каждому пользователю или группе пользователей свой взгляд на данные, что решает проблемы простоты использования и безопасности данных. ERwin имеет специальные инструменты для создания и редактирования представлений. Палитра инструментов на физическом уровне (см. рис. 2.3) содержит кнопки внесения представлений и установления связей между таблицами и представлениями. Для внесения представления нужно щелкнуть по кнопке в палитре инструментов, затем по свободному месту диаграммы. По умолчанию представление получает номер V_n, где n - уникальный порядковый номер представления. Для установления связи нужно щелкнуть по кнопке затем по родительской таблице и, наконец, по представлению (рис. 2.66). Связи с представлениями и прямоугольники представлений показываются на диаграмме пунктирными линиями.

Рис. 2.66. Создание представления

 

Для редактирования представления служит диалог View Editor (рис. 2.67). Для его вызова следует щелкнуть правой кнопкой мыши по представлению и выбрать в меню пункт View Editor.

Рис. 2.67. Диалог View Editor

 

Раскрывающийся список View позволяет выбрать для редактирования любое представление модели. Окно Name служит для редактирования имени, а Owner-владельца представления.

Диалог View Editor имеет следующие закладки:

Select (рис. 2.67). Имеет два списка: в правом отображаются колонки представления, в левом - колонки доступные для включения в представление. Кнопка New Expression позволяет задать выражение в качестве выходного столбца. Например, для представления V_43 на рис. 2.66 в качестве колонок созданы City и выражение с именем "Количество_клиен-тов_в_городе", которое представляет собой агрегативную функцию, подсчитывающую количество строк, Count(*). По умолчанию при создании связи ERwin включает в представление все колонки родительских таблиц.

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

Where. Закладка содержит три поля - Where, Group By и Having. На основе этой информации Erwin генерирует SQL-команду создания представления, причем на основе содержания этих полей генерируются предложения SQL-запроса. Для представления V_43 в поле Where содержатся значения "Соип1гу='Россия"', Group By - "City", Having - "Count(*)>2". В результате представление будет содержать информацию о количестве клиентов в российских городах, при условии, что количество клиентов в этих городах больше двух.

SQL. Закладка содержит поле, в котором отображается SQL-запрос создания представления и окно выбора User-Defined SQL. По умолчанию опция User-Defined SQL выключена, и SQL-запрос генерируется автоматически на основе информации, занесенной в закладках Select, From и Where. Запрос можно задать вручную, включив эту опцию, но в этом случае список полей и связи представления на диаграмме отображаться не будут. Для представления V_42 на рис. 2.66 SQL-запрос будет выглядеть так:

"CREATE VIEW V_42 (CustomerName, CustomerAddress, City, OrderAmount, OrderDate,

OrderShipDate)AS

SELECT DISTINCT CUSTOMER.CustomerName, CUSTOMER.CustomerAddress, CUSTOMER.City,

ORDER.OrderAmount, ORDER.OrderDate, ORDER.OrderShipDate

FROM CUSTOMER, ORDER",

а для V_43 - так:

"CREATE VIEW V_43 (City, CustomerCount) AS

SELECT CUSTOMER.City, Countf)

FROM CUSTOMER

WHERE Country= Россия'

GROUP BY City

HAVING Count(*)>2"

В закладке Comment можно внести комментарий для представления.

Stored Procedure позволяет связать с представлением хранимые процедуры.

Pre and Post Script позволяет связать с представлением команды, выполняемые до и после генерации представления.

PowerBuflder служит для внесения расширенных атрибутов для генерации кода клиентского приложения на PowerBuilder.

UDP позволяет связать с представлением свойства, определяемые пользователем.

Для редактирования свойств колонок представления служит редактор View Column Editor (рис. 2.68). Для его вызова следует щелкнуть правой кнопкой мыши по представлению и выбрать в меню пункт View Column Editor.

Рис. 2.68. Диалог View Column Editor

 

Редактор содержит следующие закладки:

General. Позволяет ассоциировать колонку с доменом. По умолчанию колонка представления принадлежит тому же домену, что и колонка родительской таблицы.

Select. Так же как в диалоге View Editor (закладка Select, кнопка New Expression), здесь можно создать выражение (в том числе включающее аг-регативные функции) для колонки.

AS/400 или Access. Используются для задания специфических свойств колонок представлений в AS/400 или Access.

Comment содержит комментарий для каждой колонки.

UDP позволяет связать с колонкой свойства, определяемые пользователем.

Data Source. Позволяет связать источник данных с колонкой при проектировании хранилищ данных.

PowerBuilder или Visual Basic. Служит для внесения расширенных атрибутов для генерации кода клиентского приложения на PowerBuilder или Visual Basic.

 

2.3.4. Правила валидации и значения по умолчанию

 

ERwin поддерживает правила валидации для колонок, а также значение, присваеваемое колонкам по умолчанию. Правило валидации задает список допустимых значений для конкретной колонки и/или правила проверки допустимых значений. Значение по умолчанию - значение, которое нужно ввести в колонку, если никакое другое значение не задано явным образом во время ввода данных. С каждой колонкой или доменом можно связать значение по умолчанию (если выбранная СУБД поддерживает домены).

Если щелкнуть по кнопке “…”, расположенной справа от раскрывающегося списка Valid (см. рис. 2.64), появляется диалог Validation Rule Editor (рис. 2.69), который служит для задания правил валидации. В нем можно задать максимальное и минимальное значение и тип валидации (где проверять - на сервере или в клиентском приложении).

Например, в таблице CUSTOMER значение, вводимое в колонку. Age, должно быть больше 18, но меньше 180. Для описания этого правила можно создать правило валидации с именем "Проверка_возраста", которое содержит выражение: Age BETWEEN 18 AND 180. Использование этого правила валидации гарантирует, что диапазон вводимых значений будет от 18 до 180. СУБД выдаст сообщение об ошибке, если вводимый возраст находится вне границ заданного диапазона.

В верхней части редактора Validation Rule содержится список всех существующих правил валидации. Для создания нового правила валидации следует щелкнуть по кнопке New, ввести имя правила в поле Name диалога New Validation и щелкнуть по кнопке ОК. После этого можно ввести выражение для правила валидации. Поля Min и Мах служат для задания нижней и верхней границы диапазона значения.

Рис. 2.69. Диалог Validation Rule Editor

 

Кнопка Valid Value вызывает редактор Valid Value (рис. 2.70). Редактор Valid Value позволяет создавать список всех допустимых значений, которые можно хранить в колонке, и связать его с правилом валидации. Например если в таблице CUSTOMER имеется колонка Category, то можно задать список допустимых значений для соответствующей колонки, который может содержать значения "Местный", "Иногородний" и "Иностранный".

Раскрывающийся список в верхней части редактора Valid Value содержит все правила, валидации. Чтобы ввести новое значение в список допустимых значений, нужно щелкнуть по кнопке New и ввести значение. Если включить опцию Copy (окно выбора в верхней части редактора), новому правилу будет присвоен список допустимых значений или диапазон, связанный с имеющимся правилом валидации. В нижнем окне диалога Valid Value можно ввести определение для каждого значения. Чтобы изменить имеющееся значение, нужно щелкнуть по кнопке Update. Для удаления значения служит кнопка Delete. Изменить порядок значений в списке можно либо пользуясь методом drag&drop, либо при помощи кнопки Sort. В последнем случае значения будут отсортированы по возрастанию.

При выходе из редактора Valid Value (кнопка OK) ERwin автоматически изменяет правило валидации, используя введенные допустимые значения, например "%AttFieldName IN ('Местный', 'Иногородний', 'Иностранный')".'

Кнопка Set Expr диалога Validation Rule Editor позволяет сгенерировать правила валидации соответственно синтаксису выбранной СУБД с учетом границ диапазона или списка значений.

По умолчанию ERwin создает выражение - команду языка СУБД, используя значения, связанные с правилом валидации, и разделяя значения запятыми (например, С, D, М). В некоторых случаях правила синтаксиса СУБД требуют, чтобы каждое значение в команде заключалось в одинарные кавычки ('С', 'D', 'М'). Чтобы автоматически заключить каждое значение в одинарные кавычки, нужно включить опцию Quote.

Рис. 2.70. Диалог Valid Value Editor

 

Диалог Validation Rule Editor содержит также две закладки, в которых отображается текст правил валидации, генерируемый ERwin на сервере и для клиентского приложения (рис. 2.71).

На рис. 2.70 в качестве клиента выбран PowerBuilder. На закладке отображается текст правила валидации Client expression, текст ошибки РВ Error Msg, тип значения РВ Type и кнопка генерации кода клиентской части РВ Sync.

Рис. 2.71. Закладка PowerBuilder диалога Validation Rule Editor

 

Редактор Default/Initial Editor (рис. 2.72) позволяет создать значение, которое автоматически, по умолчанию, присваивается колонке. Для вызова редактора служит кнопка “…” справа от раскрывающегося списка Default диалога Column Editor (см. рис. 2.64). Например, дате приема сотрудника может быть присвоено значение по умолчанию "сегодняшнее число", т. е. автоматически задается, что все новые сотрудники зачисляются в день ввода информации о них в БД.

Рис. 2.72. Диалог Default/Initial Editor

 

Для создания нового значения по умолчанию следует щелкнуть по кнопке New, ввести имя правила в поле Name диалога New Default и щелкнуть по кнопке ОК. В окне Default Name показывается список всех имен значений по умолчанию. Колонка Type в этом списке отображает тип значения - присваивать его на клиентской части и/или на сервере. Для удаления и переименования значения служат соответственно кнопки Delete и Rename.

Поля Client и Server служат для внесения значения для клиентской части и сервера.

После создания правила валидации и значения по умолчанию их можно присвоить одной или нескольким колонкам или доменам.

 

2.3.5. Индексы

 

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

Чтобы решить проблему поиска данных, СУБД использует особый объект, называемый индексом. Он подобен содержанию книги, которое указывает на все номера страниц, посвященных конкретной теме. Индекс содержит отсортированную по колонке или нескольким колонкам информацию и указывает на строки, в которых хранится конкретное значение колонки.

Например, если необходимо найти клиента по имени (рис. 2.73), можно создать индекс по колонке CustomerName таблицы CUSTOMER. В индексе имена клиентов будут отсортированы в алфавитном порядке. Для имени индекс будет содержать ссылку, указывающую, в каком месте таблицы хранится эта строка.

Рис. 2.73

Для поиска клиента серверу направляется запрос с критерием поиска (CusfomerName ="Иванов"). При выполнении запроса СУБД просматривает индекс, вместо того чтобы просматривать по порядку все строки таблицы CUSTOMER, Поскольку значения в индексе хранятся в определенном порядке, просматривать нужно гораздо меньший объем данных, что значительно уменьшает время выполнения запроса. Индекс можно создать для всех колонок таблицы, по которым часто производится поиск.

При генерации схемы физической БД ERwin автоматически создает отдельный индекс на основе первичного ключа каждой таблицы, а также на основе всех альтернативных ключей, внешних ключей и инверсионных входов, поскольку эти колонки наиболее часто используются для поиска данных. Можно отказаться от генерации индексов по умолчанию и для повышения производительности создать собственные индексы. Администратор СУБД должен анализировать наиболее часто выполняемые запросы и создавать индексы с различными колонками и порядком сортировки для увеличения эффективности поиска при работе конкретных приложений.

При создании индекса на основе ключа ERwin вводит в его состав все колонки ключа. Например, если в сущности CUSTOMER (рис. 2.73) три атрибута назначены как АК1, ERwin автоматически создает индекс и включает в него все три атрибута (CustomerName, Region, City}. Следовательно, на уровне логической модели можно неявно создать индекс, включая колонки в состав альтернативных ключей и инверсионных входов.

ERwin автоматически генерирует имя индекса, созданного на основе ключа по принципу "X" + имя ключа + имя таблицы (физическое имя таблицы, а не логическое имя сущности!), где имя ключа "РК" для первичного ключа, "IFn" - для внешнего, "AKn" - для альтернативного, "IEn" -для инверсионного входа. Например, по умолчанию при создании таблицы CUSTOMER (см. рис. 2.70) будут созданы индексы XPKCUSTOMER (первичный ключ, в состав войдет колонка CustomerID), XAK1CUSTOMER (альтернативный ключ, колонки CusfomerName, Region, City), XIE1CUSTOMER (инверсионный вход 1, колонка Region) и XIE2CUSTOMER (инверсионный вход 2, колонка CustomerAddress).

Изменить характеристики существующего индекса или создать новый можно в редакторе Index Editor (рис. 2.74). Для его вызова следует щелкнуть правой кнопкой мыши по таблице и выбрать во -всплывающем меню пункт Index.

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

Рис. 2.74. Диалог Index Editor

 

ERwin создает индексы, которые могут содержать либо повторяющиеся, либо только уникальные значения. При создании нового уникального индекса (кнопка NewH, диалог New Index, рис. 2.75) следует включить опцию Unique, для создания индекса с неповторяющимися значениями опцию следует выключить. Если на основе колонки создается уникальный индекс, то при попытке вставить запись с неуникальным (повторяющимся) значением сервер выдаст ошибку и значение не будет вставлено. Например, уникальный индекс в таблице CUSTOMER, построенный на колонке QistomerName, предотвратит от внесения двух строк с информацией об одном и том же клиенте.

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

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

Рис. 2.75. Диалог New Index

 

По умолчанию ERwin автоматически сохраняет значена . в порядке возрастания (значения сортируются по алфавиту от A до Z, а числа от 0 до 9). Если нужно изменить порядок сортировки для колонки и выбранная СУБД поддерживает режим сортировки по убыванию, следует выбрать колонку и включить опцию DESC (см. рис. 2.74).

Редактор Index Editor содержит следующие закладки:

Members - позволяет включить колонки в состав индекса;

Comment - содержит комментарий для каждого индекса;

UDP - позволяет связать с индексом свойства, определяемые пользователем

закладка, соответствующая выбранной СУБД (на рис 2.76 ORACLE) задает свойства индекса, специфические для выбранной СУБД.

Рис. 2.76. Закладка ORACLE диалога Index Editor

 

При создании индекса для СУБД ORACLE, SYBASE или SQL Server можно выбирать, в каком объекте физической памяти (создание и редактирование объектов физической памяти рассмотрено в 2.2.6) будет храниться индекс, и изменять параметры хранения. В табл. 2.5 представлены некоторые параметры объектов физической памяти, доступные в закладке, соответствующей выбранной СУБД диалога Index Editor для ORACLE, SYBASE и SQL.

 

Таблица 2.5. Параметры объектов физической памяти

Параметр

Назначение

ORACLE

PCTFREE

Задает размер пространства, которое нужно оставить свободным для обновлений и вставок в каждом блоке данных

NO SORT

Ускоряет создание индекса, если данные расположены физически по порядку. Если опция установлена, то значения индекса не сортируются; если нет, то значения индекса сортируются

INITTRANS

Задает параметры для команды CREATE TABLE

MAXTRANS

Задает параметры для команды CREATE TABLE

SQL И SYBASE

IGNORE DUPKEY

Разрешает или запрещает использование повторяющихся значений ключа в таблице с уникальным индексом (кластеризованным или некластеризованным). Если опция установлена, то повторяющиеся значения не допускаются; если нет, то повторяющиеся значения разрешаются

SORTED DATA

Ускоряет создание индекса, если данные расположены физически по порядку. Если опция установлена, то значения индекса не сортируются; если нет, то значения индекса сортируются

DUP ROW

Разрешает или запрещает использование повторяющихся значений ключа в таблице с кластеризованным индексом. Если опция установлена, то повторяющиеся значения не допускаются; если нет, то повторяющиеся значения разрешаются

FILLFACTOR

Задает, сколько данных можно добавить к странице данных при создании индекса

 

Некоторые СУБД поддерживают кластеризованные и кластеризованные хешированные индексы. ERwin позволяет создать такие индексы для DB2/MVS, DB2/390, HiRDB, INFORMIX, MS Access, MS SQL Server, SYBASE и SQLBase. Для того чтобы сделать индекс кластеризованным, нужно включить опцию CLUSTER в закладке, соответствующей выбранной СУБД. Кластеризованный индекс - это специальная техника индексирования, при которой данные в таблице физически располагаются в индексированном порядке. Использование кластеризованного индекса значительно ускоряет выполнение запросов по индексированной колонке. Например, можно создать кластеризованный индекс в таблице CUSTOMER по колонке City. Информация о всех клиентах из одного города будет физически располагаться на диске рядом, что значительно повысит скорость выполнения запроса, который делает выборку всех клиентов из какого-то определенного города.

Поскольку данные физически расположены в индексированном порядке, для каждой таблицы может существовать только один кластеризованный индекс. Если СУБД поддерживает использование кластеризованного индекса, то ERwin автоматически создает индекс первичного ключа кластеризованным. При создании кластеризованного индекса не по первичному ключу ERwin автоматически снимает кластеризацию с индекса по первичному ключу. Для СУБД SQLBase (CENTURA) ERwin позволяет создать кластеризованный хешированный индекс (clustered hashed index). Хеширование -альтернативный способ хранения данных в заранее заданном порядке с целью ускорения поиска, но физически это более сложно, чем простое сохранение строк в алфавитном порядке или в соответствии с числовыми значениями.

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

 

2.3.6. Задание объектов физической памяти

 

ERwin поддерживает объекты физической памяти для нескольких СУБД (табл. 2.6). Все объекты создаются в модели при обратном проектировании однако объекты INFORMIX, SQL Server и SYBASE не создаются при пря-' мом проектировании.

 

Таблица 2.6. Поддержка ERwin объектов сЬизчческой памяти

СУБД

Обратное проектирование (Reverse Engineer)

Прямое проектирование (Forward Engineer)

DB2/MVS и DB2/390

STOGROUP, DATABASE, TABLESPACE

STOGROUP, DATABASE, TABLESPACE

DB2/UDB

TABLESPACE

Nodegroup Bufferpool

TABLESPACE

Nodegroup Bufferpool

DB2/CS

TABLESPACE

TABLESPACE

ORACLE

TABLESPACE, ROLLBACK SEGMENT, DATABASE

TABLESPACE, ROLLBACK SEGMENT, DATABASE

Red Brick

Segment

Segment

Teradata

DATABASE

DATABASE

WATCOM/SQL Anywhere

DBSPACE

DBSPACE

INFORMIX

dbspace, blobsoace

Openlngres

location

location

SQL Server или SYBASE

Segment

 

Для создания и редактирования объектов физической памяти в ERwin используется редактор Physical Object (меню Server/Physical Object). Вид этого редактора зависит от выбранной СУБД. В качестве примера рассмотрим создание и редактирование объектов физической памяти для ORACLE (рис. 2.77).

Рис. 2.77. Диалог ORACLE Physical Object Editor

 

Диалог ORACLE Physical Object Editor имеет три закладки:

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

Список TABLESPACE в верхней части закладки показывает все табличные пространства в БД. Кнопки New, Rename и Delete служат соответственно для создания, переименования и удаления табличных пространств. При нажатии кнопки New возникает диалог New TABLESPACE, в котором следует задать имя табличного пространства. Свойства табличного пространства задаются в диалоге ORACLE Physical Object Editor. Данные в табличных пространствах доступны, когда области находятся в оперативном режиме (online), и недоступны, когда они находятся в автономном режиме (offline). Окно выбора OFFLINE показывает состояние доступности табличного пространства. Для перевода табличного пространства в offline следует включить опцию, в online - выключить.

Окно выбора TEMPORARY позволяет указать, что табличное пространство будет применяться только для хранения временных объектов, например сегментов, используемых при выполнении запросов с сортировкой (предложение ORDER BY). Эта опция доступна только для ORACLE 7.3.

Поля INITIAL и NEXT позволяют задать размер начального и следующего экстента в байтах.

Параметр PCTINCREASE указывает, на сколько процентов этот экстент может быть больше предыдущего по размеру.

MINEXTENTS - минимальное число экстентов, которое автоматически распределяется при создании таблицы, индекса или кластера табличного пространства.

MAXEXTENTS - максимальное число экстентов, которое можно связать с таблицей, индексом или кластером табличного пространства.

ROLLBACK SEGMENT (сегмент отката). Сегмент отката - это зарезервированный объем пространства, который используется для хранения "снимка" данных в том виде, в котором они находились до выполнения транзакции. Если транзакция не завершилась, все изменения данных откатываются и образ данных, хранящийся в сегменте отката, восстанавливается. Для создания или изменения сегмента отката у пользователя должна быть привилегия CREATE ROLLBACK SEGMENT.

Список ROLLBACK SEGMENT показывает все доступные для редактирования сегменты отката. Кнопки New, Rename и Delete служат соответственно для создания, переименования и удаления сегментов отката. При нажатии кнопки New возникает диалог New ROLLBACK SEBMENT, в котором задается имя сегмента отката.

Раскрывающийся список TABLESPACE позволяет связать сегмент отката с табличным пространством.

Окно выбора PUBLIC позволяет указать, каким будет сегмент отката -частным или общедоступным. Включенная опция PUBLIC делает сегмент отката общедоступным. Если не используется параллельная обработка, обычно создаются общедоступные сегменты отката.

Поля INITIAL и NEXT задают размер начального и следующего экстента в байтах.

OPTIMAL - оптимальное число управляемых экстентов для каждого сегмента отката. После успешного завершения транзакции Oracle автоматически восстанавливает размер сегментов отката до значения, указанного в поле OPTIMAL.

MINEXTENTS - минимальное число экстентов, которое можно связать с сегментом отката.

MAXEXTENTS - максимальное число экстентов, которое можно связать с сегментом отката.

DATABASE Database (база данных). База данных - это зарезервированный объем памяти для одного или более устройств хранения, которые используются для хранения данных и определений объектов БД, например таблиц и индексов. Для создания БД у пользователя должна быть привилегия DBA.

Список DATABASE в верхней части закладки показывает все БД сервера. Кнопки New, Rename и Delete служат соответственно для создания, переименования и удаления БД. При нажатии кнопки New возникает диалог New DATABASE, в котором следует задать имя БД. Свойства БД задаются в диалоге ORACLE Physical Object Editor.

Список LOGFILE показывает имена всех log-файлов (журналов регистрации) в БД. Справа от списка находятся поля для ввода параметров log-файлов:

MAXLOGFILES - максимальное число log-файлов, которые можно создать для БД (допустимый диапазон значений 2-56).

MAXLOGHIST - объем памяти, который должен быть зарезервирован в управляющем файле для имен групп архивных log-файлов транзакций (поддерживается Oracle? и более поздними версиями).

MAXLOGMEMS - максимальное число членов в каждой log-группе (поддерживается Oracle? и более поздними версиями).

Список DATAFILE показывает имена всех файлов данных в БД. Поле MAXDATAFILES позволяет задать максимальное количество файлов в БД.

Поле выбора CONTROL FILE REUSE служит для задания статуса повторного использования управляющего файла. Включенная опция позволяет Oracle переписать информацию в управляющих файлах, определенных в параметре INIT.ORA CONTROL_FILES. Выключенная опция запрещает Oracle повторно использовать управляющие файлы.

ARCHIVE LOG - состояние автоматического архивирования. Разрешает автоматическое архивирование информации log, используемой при восстановлении.

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

MAXINSTANCES - максимальное число экземпляров, для которых одновременно может быть установлена БД (допустимый диапазон значений 1-255).

CHARACTER SET - набор символов, используемый БД. Все данные в колонках типов CHAR, VARCHAR2, LONG хранятся в заданном наборе символов. После того как БД создана, набор символов не может быть изменен.

Кнопка DB Sync позволяет сгенерировать объекты физической памяти в системном каталоге СУБД сразу после их создания в диалоге Physical Object Editor.

 

2.3.7. Триггеры и хранимые процедуры

 

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

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

Хранимой процедурой называется именованный набор предварительно откомпилированных команд SQL, который может вызываться из клиентского приложения или из другой хранимой процедуры.

Триггером называется процедура, которая выполняется автоматически как реакция на событие. Таким событием может быть вставка, изменение или удаление строки в существующей таблице. Триггер сообщает СУБД, какие действия нужно выполнить при выполнении команд SQL INSERT, UPDATE или DELETE для обеспечения дополнительной функциональности, выполняемой на сервере.

Триггер ссылочной целостности - особый вид триггера, используемый для поддержания целостности между двумя таблицами, которые связаны между собой. Если строка в одной таблице вставляется, изменяется или удаляется, то триггер ссылочной целостности (RI-триггер) сообщает СУБД, что нужно делать с теми строками в других таблицах, у которых значение внешнего ключа совпадает со значением первичного ключа вставленной (измененной, удаленной) строки. По умолчанию ERwin генерирует триггеры, дублирующие декларативную ссылочную целостность (см. 2.2.3). Например, если удаляется клиент из таблицы CUSTOMER (см. рис. 2.73), то в зависимости от установленных правил ссылочной целостности могут быть сгенерированы RI-триггеры, которые будут воздействовать на соответствующие удаляемому клиенту заказы из таблицы ORDER. Команда DELETE может быть обработана следующими способами:

Для генерации триггеров ERwin использует механизм шаблонов - специальных скриптов, использующих макрокоманды. При генерации кода триггера вместо макрокоманд подставляются имена таблиц, колонок, переменные и другие фрагменты кода, соответствующие синтаксису выбранной СУБД. Шаблоны триггеров ссылочной целостности, генерируемые Erwin, по умолчанию можно изменять, кроме того, можно переопределить как триггеры для конкретной связи, так и шаблоны во всей модели в целом.

Шаблоны триггеров ссылочной целостности связываются с сущностями в зависимости от типа связи и роли сущности в этой связи. Тип связи и роль сущности определяют, какое правило ссылочной целостности будет по умолчанию дополнено шаблоном триггера. Связи могут быть: идентифицирующими, неидентифицирующими (nulls allowed), неидентифицирующими (no nulls), связями подтипа.

Сущность в связи может быть родительская (Parent) или дочерняя (Child). Если сущность является родительской в данной связи, то ERwin присваивает ей шаблон триггера для родительской сущности. Если сущность является дочерней в данной связи, то ERwin присваивает ей шаблон триггера для дочерней сущности. Код триггера, который генерируется шаблоном триггера для родительской сущности, указывает СУБД, что нужно делать при вставке, изменении или удалении строки в родительской таблице связи. Код триггера, который генерируется шаблоном триггера для дочерней сущности, указывает СУБД, что нужно делать при вставке, изменении или удалении строки в дочерней таблице связи.

Ниже приведен текст шаблона триггера, соответствующего правилу ссылочной целостности ON PARENT DELETE RESTRICT.

/* ERwin Builtin %Datetime 7

/* %Parent %VerbPhrase %Child ON PARENT DELETE RESTRICT */ select count(*) into numrows

from %Child

where

/* %%JoinFKPK(%Child,:%%Old; ="," and") */

%JoinFKPK(%Child,:%Old," ="," and");

if (numrows > 0) then

raise_application_error(

-20001,

'Cannot DELETE %Parent because %Child exists.'

);

end if;

При генерации схемы СУБД для Oracle 7.2 будет сгенерирован триггер:

create trigger tD_CUSTOMER after DELETE on CUSTOMER for each row

- ERwin Builtin Tue Jan 26 21:55:13 1999

-DELETE trigger on CUSTOMER declare numrows INTEGER;

begin

/* ERwin Builtin Tue Jan 26 21:55:131999 7

/* CUSTOMER размещает ORDER ON PARENT DELETE RESTRICT */

select countf*) into numrows

from ORDER

where

/* %JoinFKPK(ORDER,:%Old," ="," and") */

ORDER.CustomerlD = :old.CustomerlD;

if (numrows > 0)

then

raise_application_error(

-20001,

'Cannot DELETE CUSTOMER because ORDER exists.'

):

end if;

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

ERwin позволяет переопределить триггер, устанавливаемый по умолчанию, тремя способами:

ERwin имеет специальные редакторы, облегчающие создание и редактирование триггеров и процедур.

Для редактирования триггера следует щелкнуть правой кнопкой мыши по таблице и выбрать во всплывающем меню пункт Trigger. Появляется диалог Table Trigger Viewer, в нижней части которого имеется две кнопки -Table Trigger и Trigger Template, которые вызывают диалоги, предназначенные для создания и редактирования пользовательских триггеров и шаблонов триггеров ссылочной целостности (рис. 2.78).

Рис. 2.78. Диалог Table Trigger Viewer

 

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

Рис. 2.79. Таблицы CUSTOMER и SECURITY

Для создания триггера служит редактор Table Trigger Editor (вызывается кнопкой Table Trigger диалога Table Trigger Viewer) (рис. 2.80).

Рис. 2.80. Диалог Table Trigger Editor

 

Раскрывающийся список Table позволяет выбрать таблицу, на которой будет создан триггер. На рис. 2.80 это таблица CUSTOMER.

В списке Trigger отображается имя триггера (SecurWrite). Если имя не задано, ERwin генерирует триггеры ссылочной целостности по умолчанию. Кнопки New, Rename и Delete служат соответственно для внесения нового триггера в список, переименования и удаления триггера из списка.

Группа окон выбора Trigger On позволяет задать тип триггера - при каком событии триггер будет запускаться - при удалении Delete, вставке Insert или обновлении Update-строки таблицы. При выборе любого события ERwin автоматически формирует текст шаблона соответствующего триггера ссылочной целостности. Опции Before и After позволяют задать время выполнения триггера - до или после SQL-команд INSERT, UPDATE или DELETE. В примере на рис. 2.80 создается триггер, выполняемый до команды обновления UPDATE для колонки CustomerName таблицы CUSTOMER.

Опции Table и Row (поддерживается ORACLE 7.x, SQLBase V6, Watcom V4 и AS/400 V3) показывают, каким образом будет выполняться триггер. При генерации в текст триггера будут соответственно включены предложения "FOR EACH TABLE" или "FOR EACH ROW".

Old - ссылка на прежнее значение при обновлении поля, New - ссылка на новое значение при обновлении таблицы. В тексте шаблона триггера используется макрос %RefClause, при генерации текста триггера по шаблону включается предложение REFERENCES. В примере для нового значения установлено имя "newl", для старого - "oldl".

В списке в нижней части диалога показываются имена родительской таблицы (Parent), дочерней таблицы (Child), имя связи (Verb Phrase) и правило ссылочной целостности (Integrity Rule) в случае, если редактируется триггер ссылочной целостности.

В окне Template Code можно ввести код шаблона триггера. Код шаблона триггера, соответствующий бизнес-правилу рассматриваемого примера (создан на основе шаблона триггера ссылочной целостности), приведен ниже:

create trigger %TriggerName

%Fire %Actions(" or")

on %TableName

%RefClause

%Scope

/* ERwin Builtin %Datetime */ /* default body for %TriggerName */ begin

Insert into Security (OldName.NewName, UserUpdate, UpdateDate) values (:old1.CustomerName,:new1,CustomerName, User, Sysdate);

end;

/

В окне Expanded Code отображается код триггера (на языке выбранного сервера, в примере - Oracle 7.2), автоматически генерируемого по шаблону:

create trigger SecurWrite BEFORE UPDATE OF

CustomerName

on CUSTOMER

REFERENCING OLD AS old1 NEW AS new1

for each row

/* ERwin Builtin Tue Jan 26 21:24:371999 7

/* default body for SecurWrite 7

begin

Insert into Security (OldName.NewName, UserUpdate, UpdateDate)

values (:old1.CustomerName,:new1.CustomerName, User, Sysdate);

end;

/

Ниже приведен текст SQL-команд и результат их выполнения (выполнены при помощи Oracle SQVPlus), иллюстрирующих работу триггера.

SQL> insert into CUSTOMER (CustomerlD, CustomerName) values (20/lvanov');

1 row created.

SQL> update CUSTOMER set CuslomerName='Petrov' where CustomerlD=20;

1 row updated.

SQL> select* from SECURITY;

UPDATEDATE OLDNAME NEWNAME USERUPDATE

–––––––––––––––––––––––––––––––––––––––––––––––––––––––

27-JAN-99 Ivanov Petrov SCOTT

 

Любое изменение имени клиента в таблице CUSTOMER фиксируется в таблице SECURITY, причем регистрируется прежнее значение имени, новое значение, дата изменения и имя пользователя, производившего изменения.

Кнопка Toolbox диалога Table Trigger Editor вызывает редактор ERwin Trigger Toolbox, который значительно облегчает создание текста шаблона триггера (рис. 2.81).

Рис. 2.81. Диалог ERwin Template Toolbox

 

Template Toolbox содержит три секции: слева расположены списки, содержащие макросы для таблиц, связей, колонок, ограничений и макросы общего назначения. Все макросы начинаются с символа %. Список макросов приведен в приложении. Если выделить макрос в каком-либо списке, в окне Description отобразится синтаксис макроса и пример его использования для связи между таблицами, показанными в правой секции редактора. Таблицы и связи, показываемые в правой части редактора, взяты из примера, содержащегося в файле MOVIES. ER1, который находится в директории Models.

Для включения макроса в текст шаблона достаточно дважды щелкнуть левой клавишей мыши по соответствующему макросу в одном из списков. Макрос включается в текст шаблона в окне Template Code диалога Table Trigger Editor.

Для изменения шаблона триггера ссылочной целостности (переопределение типа ссылочной целостности) служит редактор Trigger Template Editor (рис. 2.82).

Рис. 2.82. Диалог Trigger Template Editor

 

Для изменения шаблона нужно выделить тип триггера в списке, который находится в верхней части редактора, после чего щелкнуть по кнопке Detach ->, чтобы отсоединить тот шаблон, который связан с выбранным триггером. В списке Built-in Template или User Override нужно выбрать шаблон, который следует связать с выбранным триггером. Выделив имя шаблона, нужно щелкнуть по кнопке Attach над списком. ERwin свяжет выбранный шаблон с триггером и покажет его текст в окне Template Code. Для отмены связывания следует щелкнуть по кнопке <- Rebind. Для создания нового собственного шаблона надо задать его имя в окне Template Name и с помощью Trigger Toolbox (кнопка Trigger Toolbox”) создать текст шаблона триггера. Кнопка Add добавит новый шаблон в список User Override.

Для переопределения шаблона триггера для связи следует правой кнопкой мыши щелкнуть по связи и во всплывающем меню выбрать пункт Relationship Template Editor. Появляется диалог Relationship Template Editor (рис. 2.83). Создание шаблона триггера и связывание его с определенным правилом ссылочной целостности аналогично созданию и связыванию шаблона в диалоге Trigger Template Editor.

Рис. 2.83. Диалог Relationship Template Editor

 

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

ERwin не имеет встроенных шаблонов хранимых процедур, которые можно было бы использовать как основу при создании новой хранимой процедуры. Для создания или редактирования хранимой процедуры следует щелкнуть правой кнопкой мыши по таблице и выбрать в каскадном меню пункт Table Editor/Stored Procedure. Появляется закладка Stored Procedure диалога Table Editor (рис. 2.84).

Рис. 2.84. Закладка Stored Procedure диалога Table Editor

 

Список Attached SP Template содержит имена процедур, связанных с редактируемой таблицей. Список Unattached SP Template содержит имена процедур, которые могут быть связаны с таблицей. Кнопки <-Attach и Detach-> служат для связывания и открепления процедуры от таблицы.

Кнопка SP Template вызывает диалог, в котором можно просмотреть и отредактировать код процедуры, включающий SQL-команды и макросы ERwin, Код процедуры показывается в окне SP Expansion, код шаблона - в окне SP Template. На рис. 2.84 в окне SP Template показан код шаблона процедуры с одним возвращаемым параметром, содержащим количество строк текущей таблицы (синтаксис Oracle 7.2).

В окне SP Template можно непосредственно вводить выражения SQL (при условии соблюдения синтаксиса выбранной СУБД). В редакторе SP Template для внесения в текст шаблона макросов можно воспользоваться редактором ERwin Template Toolbox.

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

Для создания хранимой процедуры на уровне схемы или для связывания хранимой процедуры с моделью нужно выбрать пункт меню Server/Schema Property. Вызывается редактор Schema Properties (рис. 2.85).

Рис. 2.85. Редактор Schema Properties

 

Редактор Schema Properties позволяет просматривать все хранимые процедуры, а также скрипты "до и после генерации схемы", которые связаны со схемой. Список Attached SP Template содержит имена процедур, связанных с моделью, список Unattached SP Template содержит имена процедур, которые могут быть связаны с моделью. Кнопки <-Attach и Detach-> служат для связывания и открепления процедуры от модели.

Для создания нового шаблона процедуры следует щелкнуть по кнопке Schema SP Template... и в редакторе Stored Procedure Template с помощью ERwin Template Toolbox создать текст процедуры.

Скрипты "до и после генерации". Скриптами "до и после генерации" (pre&post scripts schema-generation) называются скрипты SQL, которые ERwin выполняет до или сразу же после генерации таблиц или схемы в целом (pre&post schema-generation). Например, при прямом проектировании БД из модели ERwin может выполнить скрипт "до генерации схемы", который удаляет старую БД и создает новую до того, как начать генерацию таблиц и индексов.

Скрипты уровня таблиц могут быть созданы в закладке Pre&Post Script диалога Table Editor.

Скрипты уровня схемы связаны с моделью так же, как и хранимые процедуры. Скрипты уровня схемы определяются в закладке Pre&Post Script редактора Schema Properties (рис. 2.86). Создание скриптов аналогично созданию хранимых процедур.

Рис. 2.86. Закладка Pre&Post Script диалога Schema Properties

 

Для создания текста скриптов служат редакторы Table Template Editor и Schema Template Editor. Опция Generation Option позволяет задать тип скрипта - будет ли он выполнен до или после генерации таблицы или схемы. При создании текста скрипта так же, как и при создании текста хранимых процедур, может быть использован ERwin Template Toolbox.

 

2.3.8. Проектирование хранилищ данных

 

Хранилища данных (Data Warehouse) предназначены для хранения данных, которые редко меняются, но на основе которых часто требуется выполнение сложных запросов. Обычно они ориентированы на выполнение аналитических запросов, которые обеспечивают поддержку принятия решений для руководителей и менеджеров. Хранилища данных разгружают промышленные БД, и тем самым позволяют пользователям более эффективно и быстро извлекать необходимую информацию. К проектированию хранилищ данных предъявляются следующие требования:

Структура данных должна быть понятна пользователям;

Должны быть выделены статические данные, которые модифицируются по расписанию: ежедневно, еженедельно, ежеквартально;

Должны быть упрощены требования к запросам с целью исключения запросов, которые могли бы требовать множественных утверждений SQL в традиционных реляционных СУБД;

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

Для эффективного проектирования хранилищ данных ERwin использует размерную модель (Dimensional). Dimensional - методология проектирования, специально предназначенная для разработки хранилищ данных. Моделирование Dimensional сходно с моделированием связей и сущностей для реляционной модели, но отличается целями. Реляционная модель акцентируется на целостности и эффективности ввода данных. Размерная модель (Dimensional) ориентирована в первую очередь на выполнение сложных запросов к БД.

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

Схема "звезда" обычно содержит одну большую таблицу, называемую таблицей факта (fact table), помещенную в центр, и окружающие ее меньшие таблицы, называемые таблицами размерности (dimensional table), соединенные с таблицей факта в виде звезды радиальными связями. В этих связях таблицы размерности являются родительскими, таблица факта - дочерней. Схема "звезда" может иметь также консольные таблицы (outrigger table), присоединенные к таблице размерности. Консольные таблицы являются родительскими, таблицы размерности - дочерними.

В размерной модели иконка показывает роль таблицы в схеме "звезда":

Прежде чем создать БД со схемой типа звезды, необходимо проанализировать бизнес-правила предметной области с целью выяснения центрального вопроса, ответ на который наиболее важен. Все прочие вопросы должны быть объединены вокруг этого основного вопроса, и моделирование должно начинаться с этого основного вопроса. Данные, необходимые для ответа на этот вопрос, должны быть помещены в центральную таблицу модели - таблицу факта. Например, если необходимо создавать отчеты об общей сумме дохода от продаж за определенный период как по типу товара, так и по продавцам, следует разрабатывать модель так, чтобы каждая запись в таблице факта представляла сумму продаж, осуществленных тем или иным продавцом, с указанием доходов по каждому покупателю и типов проданных товаров (рис. 2.87). В примере таблица факта содержит суммарные данные о продажах (SALE), а таблицы размерности содержат данные о заказчике и заказах (CUSTOMER), продуктах (PRODUCT), продавцах (SALESPEOPLE) и периодах времени (TIME).

Рис. 2.87. Схема звезда

 

Таблица факта является центральной таблицей в схеме "звезда". Она может состоять из миллионов строк и содержать суммирующие или фактические данные, которые могут помочь ответить на требуемые вопросы. Она соединяет данные, которые хранились бы во многих таблицах традиционных реляционных БД. Таблица факта и таблицы размерности связаны идентифицирующими связями, при этом первичные ключи таблицы размерности мигрируют в таблицу факта в качестве внешних ключей. В размерной модели направления связей явно не показываются - они определяются типом таблиц. Первичный ключ таблицы факта целиком состоит из первичных ключей всех таблиц размерности. В примере (таблица факта SALE) первичный ключ составлен из четырех внешних ключей: Customer ID, SalespeopleID, TimeID и ProductID.

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

В примере на рис. 2.87 таблица SALE - таблица факта; CUSTOMER, TIME, SALESPEOPLE и PRODUCT - таблицы размерности, которые позволяют быстро извлекать информацию о том, кто и когда сделал покупку, какой продавец и на какую сумму продал и какие именно товары были проданы.

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

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

Если денормализованная таблица размерности получается слишком большой, при этом к части колонок запросы делаются чаще, чем к остальным, целесообразно для повышения эффективности разбить одиночную таблицу размерности на две отдельные таблицы размерности. Две полученные таблицы можно связать неидентифицирующей связью. В примере на рис. 2.87 таблица размерности PRODUCT'содержит как информацию о конкретном товаре, так и информацию о типах товаров. Если запросы, связанные с типами товаров, делаются чаще, чем по отдельным товарам, можно создать новую таблицу PRODUCT_TYPE и перенести в нее информацию о типах (рис. 2.89). В этом случае за счет того, что колонки, к которым наиболее часто обращаются запросы, переносятся в новую таблицу, уменьшается время выполнения запроса.

Рис. 2.89. Нормализация таблиц размерности

 

ERwin поддерживает методологию размерного моделирования благодаря использованию специальной нотации для физической модели -Dimensional. Наиболее простой способ перейти к нотации Dimensional -при создании новой модели (меню File/New) в диалоге ERwin Teamplate

Selection выбрать из списка предлагаемых шаблонов DIMENSION (рис. 2.90).

В шаблоне DIMENSION сделаны все необходимые для поддержки нотации размерного моделирования настройки, которые, впрочем, можно

установить вручную, преобразовав обычную диаграмму в размерную модель:

Рис. 2.90. Выбор шаблона DIMENSION

 

Для физического уровня выбрана методология DM (Dimensional Modeling). Эта опция устанавливается в закладке Methodology диалога Preferences (меню Option/Preferences), рис. 2.91. При этом показываются иконки размерности для таблиц. В списке выбора в левой части панели инструментов физический уровень показывается как Dimensional и изменяется вид палитры инструментов на физическом уровне (рис. 2.92).

Рис. 2.91. Выбор нотации DM

 

Установлена опция отображения связей диагональными линиями (Orthogonal). (Устанавливается в группе Relationship lines закладки General диалога Stored Display Editor, меню Edit/Stored Display.)

Отображаются типы данных для колонок и обозначения внешних ключей.

Рис. 2.92. Палитра инструментов размерной модели

 

ERwin автоматически проверяет корректность размерной модели и выдает диалог с предупреждающим сообщением в случае следующих нарушений синтаксиса:

Рис. 2.93. Предупреждение о нарушении синтаксиса

 

Для внесения новой таблицы в модель можно воспользоваться кнопкой в палитре инструментов. В диалоге описания свойств таблицы Table Editor появляется новая закладка Dimensional, в которой задаются специфические свойства таблицы в размерной модели (рис. 2.94):

Роль таблицы в схеме (Dimensional Modeling Role). По умолчанию Erwin автоматически определяет роль таблицы на основании созданных связей (таблица факта, размерности или консольная). Таблица без связей определяется как таблица размерности, таблица факта не может быть родительской в связи, таблица размерности может быть родительской по отношению к таблице факта, консольная таблица может быть родительской по отношению к таблице размерности. Для задания роли таблицы вручную необходимо выключить опцию Calculate Automatically.

Рис. 2.94. Закладка Dimensional диалога Table Editor

 

Тип таблицы размерности (Dimension Type). Каждая таблица размерности может содержать неизменяемые либо редко изменяемые данные (slowly changing dimensions). Поскольку хранилище данных имеет ненормализованную структуру, редактирование таблиц размерности может привести к коллизиям. Для того чтобы избежать противоречий при хранении данных, ERwin позволяет задать тип редко изменяемых данных, который отличается способом редактирования данных:

  1. Перезаписывание старых данных новыми. При этом старые данные теряются.

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

  3. Запись новых данных в дополнительном поле той же самой записи. В этом случае сохраняется первоначальное и последнее новое значение. Все промежуточные данные теряются.

Правила хранения данных (Data Warehouse Rules). Для каждой таблицы можно задать шесть типов правил манипулирования данными: обновление (Refresh), дополнение (Append), резервное копирование (Backup), восстановление (Recovery), архивирование (Archiving) и очистка (Purge). Для задания правила следуем выбрать имя правила из соответствующего списка выбора. Каждое правило должно быть предварительно описано в диалоге Data Warehouse Rule Editor (меню Edit/Data Warehouse Rule) (рис. 2.95).

Список в верхней части диалога показывает все описанные правила. Для каждого правила должно быть задано имя, тип, определение. Например, определение правила дополнения данных может включать частоту и время дополнения (ежедневно, в конце рабочего дня), продолжительность операции и т. д. Связать правила с определенной таблицей можно не только с помощью диалога Table Editor, но и непосредственно из Data Warehouse Rule Editor (закладка Attachment).

Рис. 2.95. Диалог Data Warehouse Rule Editor

 

При проектировании хранилища данных важно определить источник данных (для каждой колонки), метод, которым исходные данные извлекаются, преобразуются и фильтруются, прежде чем они импортируются в хранилище данных. Хранилище данных может объединять информацию из текстовых файлов и многих БД, как реляционных, так и нереляционных, в единую систему поддержки принятия решений. Чтобы поддерживать регулярные обновления и проверки качества данных, необходимо знать источник для каждой колонки в хранилище данных. Для документирования информации об источниках данных используется редактор Data Warehouse Source Editor (рис. 2.96).

Рис. 2.96. Диалог Data Warehouse Source Editor

 

Внести новый источник можно щелкнув по кнопке WS в списке источников. Имена таблиц и колонок источников данных могут быть импортированы как из БД, так и из других моделей ERwin (закладка Detail, кнопка Import). Каждому источнику может быть задано имя и определение.

В закладке Data Source редактора Column Editor (рис. 2.97) можно внести информацию об использовании источников данных для каждой колонки в таблице. В поле Transform Comment вносится дополнительная информация о переносе данных из источника в хранилище данных.

Рис. 2.97. Диалог Column Editor

 

Для выбора источника данных следует щелкнуть по кнопке Д| в правой верхней части закладки Data Source. Появляется диалог Data Warehouse Source Selector (рис. 2.98), в окне Available Sources которого показываются все предварительно описанные источники. Для выбора источника следует выбрать в списке необходимую колонку и щелкнуть по кнопке Select.

 

2.3.9. Вычисление размера БД

 

ERwin позволяет рассчитать приблизительный размер БД в целом, а также таблиц, индексов и других объектов через определенный период времени после начала эксплуатации ИС. Для расчета размеров физических объектов служит диалог Volumetrics Editor (рис. 2.99), который вызывается из меню Edit/Volumetrics...

Редактор Volumetrics Editor имеет три закладки - Settings, Report и Parameters:

Settings. Служит для задания основных параметров, на основе которых вычисляется размер БД:

В группе Table Row Counts для выделенной в левом списке Table таблицы задается начальное количество строк (Initial), максимальное количество строк (Мах) и прирост количества строк в месяц (Grow By). Если параметры Мах и Grow By используются одновременно, рост размера таблицы прекращается по достижении максимального размера.

Рис. 2.98. Диалог Data Warehouse Source Selector

 

Те же самые параметры можно задать для каждой таблицы в закладке Volumetrics редактора Table Editor. Сразу после задания параметров Initial, Мах и Grow By в группе Sizing Estimates, расположенной в левом нижнем углу диалога, показывается средний размер строки, начальный размер таблицы и индексов.

Таблица Column Properties позволяет задать свойства колонок таблицы. Имена колонок, их тип и размер (allocated) не редактируются. Можно изменять ширину поля Avg Width (для тех типов данных, для которых это допускается) и параметр Pet NULL (средний ожидаемый процент строк, в которых текущее поле принимает значение NULL). ERwin автоматически определяет в зависимости от выбранной СУБД, какие поля таблицы Column Properties могут изменяться.

Группа Include Indexes позволяет учесть или игнорировать индексы, создаваемые на внешних (FK, Foreign Key), первичных (РК, Primary Key), альтернативных (АК, Alternate Key) ключах или инверсионных входах (IE, Inverse Entry) при расчете размера БД.

Рис. 2.99. Диалог Volumetrics Editor

 

Группа Storage позволяет задать объект физической памяти, в котором будет храниться выбранная таблица. Если объект физической памяти не описан, его можно определить в редакторе Physical Object Editor (вызывается кнопкой “…”)

Report. В ней отображаются результаты расчета размера БД (рис. 2.100). Группа Options позволяет выбрать тип объектов, по которым проводится расчет, Time - временной диапазон (начальное состояние или определенное время после начала эксплуатации).

Результирующий отчет можно направить в диалог генерации отчетов -Report Browser.

Parameters. Служит для задания дополнительных параметров, используемых для расчета размера БД:

TableFactor. Этот фактор показывает накладные расходы на хранение таблицы в БД. Например, значение TableFactor = 2 увеличит размер таблиц вдвое.

IndexFactor показывает накладные расходы на хранение индекса в БД. Например, значение IndexFactor = 1 увеличит размер индекса с 1 М до 1,5М.

Рис. 2.100. Закладка Report диалога Volumetrics Editor

 

RowOverhead используется для дополнительного пересчета количества байт каждой строки. Например, если значение RowOverhead = 10, размер каждой строки таблицы будет увеличен на 10 байт.

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

BytesPerChar используется для задания количества байт, необходимых для хранения одного символа строкового типа. Для ASCII - это 1, для других кодировок значение может быть больше 1, например для UNICODE - 2.

LogPercent используется для вычисления размеров log-файлов БД. LogPercent = 100 увеличивает БД вдвое.

 

2.3.10. Прямое и обратное проектирование

 

Процесс генерации физической схемы БД из логической модели данных называется прямым проектированием (Forward Engineering). При генерации физической схемы ERwin включает триггеры ссылочной целостности, хранимые процедуры, индексы, ограничения и другие возможности, доступные при определении таблиц в выбранной СУБД. Процесс генерации логической модели из физической БД называется обратным проектированием (Reverse Engineering). ERwin позволяет создать модель данных путем обратного проектирования имеющейся БД. После того как модель создана, можно переключиться на другой сервер (модель будет конвертирована) и произвести прямое проектирование структуры БД для другой СУБД. Кроме режима прямого и обратного проектирования ERwin поддерживает синхронизацию между логической моделью и системным каталогом СУБД на протяжении всего жизненного цикла создания ИС.

Для генерации системного каталога БД следует выбрать пункт меню Tasks/Forward Engineer/Schema Generation или нажать кнопку на панели инструментов. Появляется диалог Schema Generation (рис. 2.101).

Рис. 2.101. Диалог Schema Generation

 

Диалог Schema Generation имеет три закладки:

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

В закладке Summary отображаются все опции, заданные в закладке Options. Список опций в Summary можно редактировать так же, как и в Options.

Comment. Позволяет внести комментарий для каждого набора опций. Каждый набор опций может быть именован (окно Option Set, кнопки New, Rename и Delete) и использован многократно.

Кнопка Preview вызывает диалог Schema Generation Preview (рис. 2.102), в котором отображается SQL-скрипт, создаваемый ERwin для генерации системного каталога СУБД. Нажатие на кнопку Generate приведет к запуску процесса генерации схемы.

Рис. 2.102. Диалог Schema Generation Preview

 

Кнопка Print предназначена для вывода на печать создаваемого ERwin SQL-скрипта.

Кнопка Report сохраняет тот же скрипт в ERS или SQL текстовом файле. Эти команды можно в дальнейшем редактировать любым текстовым редактором и выполнять при помощи соответствующей утилиты сервера.

Рис. 2.103. Диалог связи с БД

 

Кнопка Generate запускает процесс генерации схемы. Возникает диалог связи с БД (рис. 2.103), устанавливается сеанс связи с сервером и начинает выполняться SQL-скрипт. При этом возникает диалог Generate Database Schema (рис. 2.104).

Рис. 2.104. Диалог Generate Database Schema

 

По умолчанию в диалоге Generate Database Schema включена опция Stop If Failure. Это означает, что при первой же ошибке выполнение скрипта прекращается. Щелкнув по кнопке Continue можно продолжить выполнение. Кнопка Abort прерывает выполнение. При выключенной опции Stop It Failure скрипт будет выполняться, несмотря на встречающиеся ошибки.

Для выполнения обратного проектирования следует выбрать пункт меню Tasks/Reverse Engineer.

При этом возникает диалог ERwin Template Selection (рис. 2.105), в котором нужно выбрать шаблон диаграммы, затем диалог выбора СУБД и, наконец, диалог задания опций обратного проектирования Reverse Engineer - Set Options (рис. 2.106).

Рис. 2.105. Диалог ERwin Template Selection

 

В диалоге Reverse Engineer - Set Options можно задать следующие опции:

Группа Reverse Engineer From позволяет задать источник обратного проектирования - БД или SQL(DDL)-CKpHnT. При помощи кнопки Browse можно выбрать текстовый файл, содержащий SQL-скрипт.

Группа Items to Reverse Engineer позволяет задать объекты БД, на основе которых будет создана модель. При помощи списка выбора Option Set, a также кнопок New, Update и Delete можно создавать и редактировать именованные конфигурации объектов БД, которые могут быть использованы многократно при других сеансах обратного проектирования.

Группа Reverse Engineer (доступна только при обратном проектировании из БД) позволяет включить в модель системные объекты (окно выбора System Objects) и установить фильтр на извлекаемые таблицы по их владельцу.

Установка опции Primary Keys в группе Infer означает, что ERwin будет генерировать первичные ключи на основе анализа индексов. Если включена опция Relations, ERwin будет устанавливать связи на основе имен колонок первичного ключа или индексов. Эти опции имеют смысл, только если связи не прописаны явно.

Группа Case Conversion позволяет задать опции конвертации регистра при создании логических и физических имен модели.

Рис. 2.106. Диалог Reverse Engineer - Set Options

 

Опция Import View Base Tables указывает, что ERwin будет устанавливать связи между представлениями и таблицами. Если опция выключена или SQL-команда создания представления содержит сложные конструкции (например, агрегативные функции), колонки представления импортируются как определяемые пользователем.

После установки необходимых опций можно щелкнуть по кнопке Next, после чего появляется диалог связи с БД (см. рис. 2.103), устанавливается сеанс связи с сервером и начинается процесс обратного проектирования, во время которого показывается статус процесса в диалоге Reverse Engineer-Status. В результате процесса создается новая модель данных.

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

Для синхронизации системного каталога БД и текущей модели следует выбрать пункт меню Tasks/Complete Compare или нажать кнопку на панели инструментов. Возникает диалог Complete Compare - Set Options, который во многом похож на описанный выше диалог Reverse Engineer - Set Options. Разница заключается в том, что в отличие от обратного проектирования сравнивать текущую модель можно не только с БД или SQL-скриптом, но и с другой моделью ERwin, хранящейся в файле или репози-тории ModelMart.

После нажатия на кнопку Next диалога Complete Compare - Set Options возникает диалог связи с БД (см. рис. 2.103), устанавливается сеанс связи с сервером и в диалоге Complete Compare - Resolve Differences показывается текущее состояние модели (слева) и системного каталога СУБД (справа) (рис. 2.107).

Рис. 2.107. Диалог Complete Compare - Resolve Differences

 

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

экспорт объекта из модели в БД;

импорт объекта из БД в модель;

игнорирование различия между моделью и БД (по умолчанию принимается для всех объектов);

удаление объекта из БД.

Кнопки Match и UnMatch позволяют связать объекты модели и БД, имеющие разные имена. Например, в модели ERwin таблице CUSTOMER соответствует таблица CUST в БД. По умолчанию ERwin определяет, что это разные объекты, хотя по смыслу это одно и то же. Для того чтобы ERwin правильно провел синхронизацию, необходимо вручную связать эти две таблицы. Для связывания таблиц необходимо щелкнуть по кнопке Match, затем по таблице модели (левый список) и, наконец, по таблице БД (правый список). Кнопка UnMatch служит для отмены связывания таблиц.

Линейка индикаторов между списками показывает установленную опцию синхронизации объектов.

Кнопка Report, позволяет сгенерировать отчет о синхронизации, кнопка Preview вызывает диалог Preview SQL Commands, в котором показывается SQL-скрипт, выполняемый для проведения синхронизации.

После щелчка по кнопке Next возникает диалог Complete Compare -Import Changes, в котором можно задать дополнительные опции синхронизации, касающиеся модификации модели (рис. 2.108).

Группа Case Conversion of Logical Names позволяет задать регистр имен создаваемых в модели объектов.

Группа If Table to Import Exists in Model позволяет задать опции генерации схемы в случае, если таблица уже существует в модели. Может быть использована существующая таблица (Use Existing Table) либо создана дублирующая (Create Duplicate Table).

Опции Primary Keys, Relations и Import Base Tables имеют то же назначение, что и соответствующие опции диалога Reverse Engineer - Set Options (см. выше).

Рис. 2.108. Диалог Complete Compare - Import Changes

 

Кнопка Start Import служит для запуска процесса импорта объектов в модель из БД, SQL(DDL)-скрипт, диаграммы из репозитория ModelMart или файла ER1/ERX. В процессе импорта ERwin показывает сообщения об успешном или неуспешном завершении выполнения импорта для каждого объекта.

Оглавление Назад Далее

Hosted by uCoz