3. Разработка физической модели
Физический уровень представления модели зависит от выбранного сервера. Для выбора СУБД служит редактор Target Server (меню Server/Target Server доступно только на физическом уровне) (рисунок 22). Вызвать данный редактор можно нажав кнопку Select target server (рисунок 21).
Рисунок 21
Рисунок 22
В качестве целевой СУБД необходимо выбрать Oracle.
После выбора целевой СУБД необходимо в каждой таблице для всех полей определить соответствующие типы данных, поддерживаемые заданной СУБД.
Для задания типов данных в выбранной таблице необходимо щелкнуть по ней правой кнопкой мыши и выбрать пункт контекстного меню Colums. В закладке Oracle открывшегося редактора Colums (рисунок 23) необходимо выбрать нужное поле и требуемый тип данных.
b. На той же вкладке имеет возможность задать Null-опции (Null option) выбранного поля. Выбор опции NULL означает, что значение поля может быть не задано. Опция NOT NULL означает, что поле должно обязательно иметь значение.
Рисунок 23
4. Проверка полученной информационной модели
Полученную информационную модель необходимо проверить на наличие ошибок. Для этого необходимо выполнить следующую последовательность шагов:
Сохранить проект ERwin Data Modeler;
Запустить приложение ERwin Data Model Validator. Откроется окно, представленное на рисунке 24;
Создать новый проект тестирования (File->New или кнопка New на панели инструментов). При этом откроется окно выбора типа проекта (рисунок 25). Необходимо выбрать тип проекта Data Model from Erwin. Далее откроется диалог выбора файла, в котором необходимо выбрать сохраненный проект ERwin Data Modeler;
Выбрать тестируемые таблицы в открывшемся окне (рисунок 26). Далее откроется окно проекта тестирования (рисунок 27);
Рисунок 24
Рисунок 25
Рисунок 26
Рисунок 27
Для вывода отчета о результатах тестирования необходимо выбрать следующий пункт главного меню: Reports -> Diagnostics -> ALL;
В окне отчета (рисунок 28) будут представлены результаты тестирования.
Рисунок 28
Необходимо проанализировать найденные ошибки и, по возможности, исправить их. После этого провести тестирование заново.
Ошибки объединены в четыре категории.
В первую категорию (Columns) входят ошибки проектирования колонок. Ниже приведен фрагмент списка ошибок этой категории:
Inconsistent Definition. Название колонки встречается в различных таблицах, но при этом колонки (или их синонимы) имеют разные определения. Это может привести к сохранению неверных данных.
Groups with Inconsistent Definition. Группа колонок, нарушающих первую нормальную форму имеет противоречивое взаимное определение.
Duplicate Table. Имя таблицы неуникально в модели.
Table with No Columns. Таблица не имеет колонок.
Data Names Conflict with SQL Keywords. Имя является резервированным словом.
Вторая категория объединяет ошибки проектирования индексов и ограничений(Indexes and Constraints). В эту группу входят следующие ошибки:
Incorrectly Defined Foreign Keys. Некорректное определение внешнего ключа, не обеспечивающее правила ссылочной целостности.
Candidate Keys with All Nullable Columns. Уникальные индексы или/и первичные ключи содержат колонки null, что может привести к дублированию строк.
Improperly Defined Indexes. По меньшей мере один индекс имеет аномалии.
Undefined Alternate Keys. Таблица имеет суррогатный первичный ключ и не имеет альтернативного ключа.
Different CHECK Constraints. Несколько колонок определены в разных таблицах, но имеют разные ограничения CHECK.
Tables without a Candidate Key. Таблица не имеет ограничений, гарантирующих уникальность записи (PK, Unique Constraint или Unique Index).
Disabled Constraints. Неверное ограничение.
Tables with No Clustered Index. Таблица должна иметь кластеризованный индекс.
Primary Key with Columns Allowing Decimals. Колонка первичного ключа содержит числовую колонку с десятичными знаками, например, типа REAL.
Unnecessary CHECK Constraints. Ненужные ограничения, например, ограничения на внешнем ключе дочерней таблицы вместо ограничения на первичном ключе родительской.
Unnecessary Indexes. Ненужные индексы.
Unnecessary Foreign Keys. Ненужные внешние ключи, например, если целостность уже поддерживается другими внешними ключами.
Missing Indexes. Отсутствие индексов, например на внешнем ключе.
Tables with Too Many Indexes. Таблица содержит слишком много индексов.
Indexes with Too Many Columns. Индекс содержит слишком много колонок.
Primary Keys with Too Many Columns. Первичный ключ содержит слишком много колонок.
Indexes with Variable Length Columns. Индекс содержит колонки переменной длины VARCHAR (только для DB2).
Conflicting Indexes. Конфликтующие индексы.
Tables with No Relationships. Таблица не имеет связей.
Delete Cascade/Restrict Conflicts. Ограничение ссылочной целостности для внешнего ключа определено как ON DELETE CASCADE, а дочерняя таблица имеет по крайней мере один внешний ключ без этой опции, поэтому автоматическая ссылочная целостность не может поддерживаться для “внучатой” таблицы.
Третья категория объединяет ошибки нормализации (Normalization). Находятся некорректно определенные функциональные зависимости и ошибки первой, второй и третьей нормальной формы.
В четвертую категорию входят ошибки связей (Relationships):
Incorrect Recursive Relationships. Некорректно определенная рекурсивная связь. Внешний ключ рекурсивной связи должен включать по крайней мере одну колонку NULL, в противном случае возникает коллизия при вставке.
Disabled Relationships. Недоступная связь – ссылочный ключ связи недоступен.
Non-Enforceable Relationships. Связи, не имеющие определения внешнего ключа.
Mismatched Foreign Keys. Имеются аномалии во внешних ключах.
Infinite Loops. Бесконечные циклы. Существует цикл между таблицами и внешние ключи не имеют свойства NULL. При этом вставка данных невозможна.
Tables with Too Many Relationships. Таблица имеет слишком много связей, это может привести к потере производительности.
Cross Linked Relationships. Между таблицами существует цикл и внешние ключи не имеют свойства NULL. Вставка данных невозможна.
Incompatible Relationships. Связь, основанная на колонке с разными типами или определениями.