Добавил:
Upload Опубликованный материал нарушает ваши авторские права? Сообщите нам.
Вуз: Предмет: Файл:

2. ERWin

.pdf
Скачиваний:
86
Добавлен:
20.03.2016
Размер:
7.04 Mб
Скачать

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

данному в поле Name Inherited by Attribute диалога Domain Dictionary.

Например, если в правило состоит из макроса %AttDomain, то имя атрибута будет совпадать с именем домена-родителя, а если правило имеет вид %AttDomain %OwnerEntity, то имя порождаемого из домена атрибута будет составлено из имени домена и имени сущности, в которую «перемещен» домен, разделенных пробелом. Так на рис. 12 домен с именем ИД «перетащили» в сущность Тест, в результате чего автоматически создался атрибут с именем ИД тест.

На физическом уровне диалог Domain Dictionary позволяет редактировать физические свойства домена. Для переключения на физический уровень следует в верхней части диалога в списке Edit Mode (рис. 68) выбрать Physical. На физическом уровне диалог содержит другой набор закладок: General, SQL Server (или другое имя в зависимости от выбранного сервера базы данных), Constraint, Comment, UDP, - но по смыслу они похожи на соответствующие закладки логического уровня.

Нормализация и денормализация

Нормализация – процесс проверки и реорганизации сущностей и атрибутов с целью удовлетворения требований к реляционной модели данных. В результате нормализации должна быть создана структура данных, в которой информация о каждом факте хранится только в одном месте. Нормализация позволяет значительно сократить объем памяти для хранения информации и устранить аномалии в организации хранения данных. Процесс нормализации сводится к последовательному приведению структуры данных к нормальным формам – формализованным требованиям к организации данных. Известно 6 нормальных форм (Для углубленного изучения нормализации следуют обратиться к книге К. Дж. Дейта «Введение в системы баз данных»). На практике ограничиваются приведением данных к третьей нормальной форме (полная атрибутивная модель). На рис. 70 приведен пример ненормализованной сущности, а на рис. 71 – соответствующая структура данных, приведенная к третьей нормальной форме.

ERwin DM не может проводить автоматическую нормализацию, но некоторые из его функциональных возможностей облегчают создание нормализованной модели данных. Запрет на присвоение неуникальных имен в рамках модели (при соответствующей установке опции Unique Name) облегчает соблюдение правила «один факт – в одном месте». Имена ролей атрибутов внешних ключей и унификация атрибутов также облегчают построение нормализованной модели.

71

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

Рис. 71. Результат нормализации сущности «Сотрудник» (3НФ).

Часто нормализация не ведет к повышению производительности информационной системы в целом. Например, информация о сотрудниках (рис. 70) в результате приведения к третьей нормальной норме была рассредоточена в четырех связанных таблицах (рис. 71). Хотя общее число строк в этих таблицах может быть меньше, чем в исходной (до нормализации), теперь для получения полной информации о сотруднике серверу базы данных необходимо обращаться одновременно к четырем таблицам (объединение таблиц, join). Время выполнения запроса с объединением может во много раз превосходить время выполнения запроса к одной таблице. В приведенном примере общая производительность информационной системы в результате нормализации скорее всего упадет. В целях повышения производительности при переходе на физический уровень приходится сознательно отходить от нормальных форм, чтобы использовать возможности конкретного сервера или информационной системы в целом, т.е. проводить денормализацию. В каждом конкретном случае приходится искать конкретные решения по денормализации, учитывающие специфику информационной системы и бизнес-правила предметной области.

ERwin DM позволяет сохранить на логическом уровне нормализованную структуру, при этом построить на физическом уровне структуру (возможно, денормализованную), которая обеспечит лучшую производитель-

72

ность. Для поддержки денормализации ERwin DM позволяет создавать сущности, атрибуты, ключи и домены только на уровне логической модели, включив в соответствующих диалогах опцию Logical Only. (см. рис. 32, 38, 68). Такие объекты не будут отображаться на уровне физической модели и не будут созданы при генерации базы данных. С другой стороны, таблицы, колонки, домены и индексы можно создавать только на уровне физической модели (опция Physical Only в соответствующих диалогах). Кроме того, ERwin DM имеет набор инструментов, сведенных в панель трансформаций (см. табл. 5), который может быть использован для денормализации модели. (О поддержке трансформаций в ERwin DM будет рассказано в. разделе «Трансформации».)

Создание физического уровня модели

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

Базовыми компонентами диаграммы физического уровня модели в ERwin DM являются (рис. 72):

таблицы,

колонки,

ограничения,

представления,

а также индексы, хранимые процедуры, триггеры, скрипты.

На физическом уровне

Таблицы Колонки

Ограничения (отношения) Представления

Привязка к СУБД

Рис. 72. Базовые объекты модели физического уровня.

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

Для выбора СУБД следует, находясь на физическом уровне модели, в меню DataBase выбрать пункт Choose DataBase. В открывшемся диалоге (рис. 73) можно выбрать целевую СУБД и ее версию, установить для коло-

73

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

Рис. 73. Диалог выбора целевой СУБД.

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

Если необходимо разработать модель для СУБД, отсутствующей в списке целевых СУБД (рис. 73), укажите пункт ODBC/Generic. Однако при работе с нецелевой СУБД ERwin DM автоматизирует меньшее количество функций. В этом случае, возможно, более эффективным будет использовать другое средство моделирования вместо или совместно с ERwin DM.

Таблицы

На логическом уровне таблицам соответствуют сущности. Чтобы провести настройку таблицы следует в диаграмме щелкнуть по таблице правой кнопкой мышки и в появившемся контекстном меню выбрать требуемый элемент настройки или в меню Model выбрать пункт Tables. Наборы пунктов контекстного меню таблицы различаются в зависимости от выбранной СУБД. Так, на рис. 74 показаны наборы пунктов меню для таблиц

SQL Server 2000, SQL Server 2005 и Oracle 11. Например, для таблиц SQL

Server 2000 можно настроить:

Свойства таблицы (Table Properties),

Колонки (Columns),

Индексы (Indexes),

Триггеры (Triggers),

Хранимые процедуры (Stored Procedures),

Пре- и постскрипты (Pre & Post Scripts).

74

Рис. 74. Примеры опций контекстного меню таблицы.

Для редактирования свойств таблицы в ее контекстном меню (рис. 74) следует выбрать пункт Table Properties. В результате отобразится контекстное меню, каждый пункт в котором соответствует отдельной закладке в диалоге Table для редактирования свойств таблицы. Активизировать диалог Table можно также, выделив на диаграмме таблицу, затем в меню Model выбрав пункт Tables. Набор закладок диалога Table и, соответственно, свойств таблиц различается в зависимости от выбранной СУБД. В качестве примера на рис. 75 показаны наборы закладок Table для таблиц SQL

Server 2000, SQL Server 2005 и Oracle 11.

Рис. 75. Примеры закладок диалога Table.

Закладки Volumetrics, UDP, History диалога Table похожи на одноименные закладки диалога Entity, закладка Comment соответствует закладке Definition (см. раздел «Сущности»). В закладке Physical Properties диалога Table определяют физические свойства таблицы. В закладке Validation задают правила валидации.

Колонки

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

75

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

ны в диалогах Validation Rules и Default Values (меню Model). Закладка

Comment служит для внесения комментария к колонке. В закладке UDP задаются свойства, определенные пользователем. Закладка Index служит для включения колонки в состав индексов. Закладка History содержит историю создания и изменения свойств колонки.

Представления (View)

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

Материализованные представления (materialized view)

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

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

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

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

ERwin DM поддерживает правила валидации и значения по умолчанию как на логическом, так и на физическом уровне модели с помощью

76

диалогов Validation Rules и Default Values соответственно. Активировать эти диалоги можно через меню Model или через контекстные меню сущностей или таблиц (через закладку Constraint в диалогах Attributes и

Columns).

Индексы

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

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

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

При создании индекса на основе ключа ERwin DM вводит в его состав все колонки ключа. Следовательно, на уровне логической модели можно неявно создать индекс, включая колонки в состав альтернативных ключей и инверсных входов. ERwin DM автоматически генерирует имя индекса, созданного на основе ключа.

Изменить характеристики существующего индекса или создать новый можно в диалоге Indexes (меню Model/Indexes). Набор изменяемых параметров индекса зависит от выбранной СУБД.

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

ERwin DM поддерживает объекты физической памяти для некоторых СУБД. Для создания и редактирования этих объектов используются диалоги, вызвать которые можно из меню DataBase. В зависимости от СУБД и ее

77

версии набор объектов и соответственно набор пунктов меню различается.

Например, для Informix 7.x – это DBspace, для Oracle 8i – это Tablespace, Rollback Segment, Database и др., для SQL Server 2000 – это Filegroup.

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

Триггеры и хранимые процедуры – это именованные блоки кода

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

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

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

Создать хранимую процедуру в ERwin DM можно в диалоге Stored Procedures (меню Database/Stored Procedures). При создании текста храни-

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

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

Триггер ссылочной целостности – это особый вид триггера, исполь-

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

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

78

использует механизм шаблонов – специальных скриптов, использующих макрокоманды, что позволяет сократить число строк SQL, написанных проектировщиком, в десятки, сотни и даже тысячи раз. Шаблоны ссылочной целостности, генерируемые ERwin по умолчанию, можно изменять [2].

Скрипты «до и после генерации»

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

Скрипты уровня таблиц могут быть созданы в диалоге Pre & Post Scripts (контекстное меню таблицы). Скрипты уровня схемы можно со-

здать в диалоге Pre & Post Scripts (меню Database/Pre & Post Scripts/ModelLevel), Создание скриптов аналогично созданию хранимых процедур. При создании текста скрипта также как, при создании хранимых процедур, можно использовать макросы ERwin DM.

Прямая генерация

Процесс генерации физической схемы базы данных из модели данных называется прямым проектированием (Forward Engineering). При гене-

рации схемы кроме таблиц и представлений ERwin DM создает триггеры ссылочной целостности, хранимые процедуры, индексы, ограничения и другие объекты, доступные для выбранной СУБД.

Для генерации системного каталога базы данных следует перейти на физический уровень модели и выбрать пункт меню Tools/Forward Engi-

neer/Schema Generation или нажать кнопку на панели инструментов Database Toolbar (команда Forward Engineer в меню Tools доступна лишь на физическом уровне модели). Появляется диалог Forward Engineer Schema Generation, включающий закладки: Options, Summary, Comment. (рис. 76).

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

79

Рис. 76. Диалог Forward Engineer Schema Generation.

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

80