ERwin. Опыт использования.. Учебное пособие по дисциплинам информационные системы в экономике, проектирование информационных систем
 Скачать 3.87 Mb.
|
|
Фамилия, Имя, Отчество и Дата рождения входят в альтернативный ключ № 1 (АК1), Номер паспорта составляет альтернативный ключ № 2 (АК2). Инверсионные входы обозначаются как (IEn.m), где n - порядковый номер входа, m -порядковый номер атрибута. Инверсионный вход IE1 (атрибут Должность) позволяет выбрать всех со- трудников, занимающих одинаковую должность, IE2 (атрибут Номер офи- са) - всех сотрудников, работающих в одном офисе, IE3 (атрибуты Город и Улица) - всех сотрудников, живущих на одной улице. Если один атрибут входит в состав нескольких ключей, ключи перечисляются в скобках через запятую. По умолчанию номера альтернативных ключей и инверсионных вхо- дов рядом с именем атрибута на диаграмме не показываются. Для отобра- жения номера следует в контекстном меню, которое появляется, если щелкнуть правой кнопкой мыши по любому месту диаграммы, не занятому объектами модели, выбрать пункт Entity Display, затем включить опцию Alternate Key Designator (AK). 68 Внешние ключи (Foreign Key) создаются автоматически, когда связь соединяет сущности: связь образует ссылку на атрибуты первичного ключа родительской сущности и эти атрибуты образуют внешний ключ в дочер- ней сущности (миграция атрибутов ключа). Атрибуты внешнего ключа обозначаются символом (FK) после своего имени. Атрибут внешнего клю- ча Номер отдела в сущности Сотрудник является атрибутом первичного ключа в сущности Отдел (рис. 65). Зависимая сущность может иметь один и тот же внешний ключ из не- скольких родительских сущностей. Сущность может также получить один и тот же внешний ключ несколько раз от одного и того же родителя через несколько разных связей. Когда ERwin DM обнаруживает одно из этих со- бытий, он распознает, что два атрибута одинаковы, и помещает атрибут внешнего ключа в зависимую сущность только один раз. Хотя в закладке Key Group диалога Attribute этот атрибут будет входить в два внешних ключа, на диаграмме он показывается только один раз. Это комбини- рование или объединение идентичных атрибутов называется унификаци- ей. Унификация производится, поскольку правила нормализации запре- щают существование в одной сущности двух атрибутов с одинаковыми именами. Однако, есть случаи, когда унификация нежелательна. Напри- мер, когда два атрибута имеют одинаковые имена, но на самом деле они отличаются по смыслу и необходимо, чтобы это отличие отражалось в диаграмме. В этом случае необходимо использовать имена ролей атрибу- тов внешнего ключа. В некоторых случаях бывает целесообразно иметь в дочерней сущно- сти ссылку не на первичный, а на альтернативный ключ. ERwin DM позво- ляет создавать связи, при которых в дочернюю сущность мигрируют атри- буты одного из альтернативных ключей. Для создания такой связи не- обходимо создать идентифицирующую или неидентифицирующую связь, щелкнуть по связи правой кнопкой мыши, выбрать пункт меню Relation- ship Properties, в открывшемся диалоге Relationships перейти на закладку Rolename и в выпадающем списке Migrated Key выбрать ключ, атрибуты которого будут мигрировать в дочернюю сущность. В результате в дочер- ней сущности внешний ключ будет содержать атрибуты альтернативного ключа родительской сущности (рис. 67). Рис. 67. Пример миграции атрибутов альтернативного ключа. 69 Домены Домен можно определить как абстрактный атрибут, на основе которо- го можно создавать обычные атрибуты, при этом создаваемые атрибуты будут иметь все свойства домена-родителя. Каждый атрибут может насле- довать свойства только одного домена, но каждый домен может быть ро- дителем множества атрибутов. В понятие домена входит не только тип данных, но и область значений данных. Например, можно определить до- мен Возраст как положительное целое число и определить атрибут Воз- раст сотрудника как принадлежащий этому домену. В ERwin DM домен может быть определен только один раз, и исполь- зоваться как в логической, так и в физической модели. Домен может быть создан на основе другого домена, и наследовать все свойства домена- родителя. По умолчанию ERwin DM имеет четыре предопределенных до- мена: String, Number, Blob, Datetime. Создать домен можно в закладке Model навигатора модели Model Ex- plorer. Для этого следует выбрать родительский домен из списка Domains, щелкнуть по нему правой кнопкой мышки и выбрать пункт Properties. В появившемся диалоге Domain Dictionary в закладке General (рис. 68) щелкнуть по кнопке New. Рис. 68. Диалог Domain Dictionary. 70 В появившемся диалоге New Domain (рис. 69) требуется указать имя домена в поле Logical Name. Можно указать имя домена на физическом уровне в поле Physical Name, после чего нажать ОК. Если не указывать фи- зическое имя, то по умолчанию оно скопируется из логического имени. Рис. 69. Диалог New Domain. В диалоге Domain Dictionary в закладке General можно также связать домен с иконкой (список Domain Icon на рис. 68), с которой он будет отоб- ражаться в списке доменов, а также с иконкой, которая будет отображаться у атрибута, определенного на домене (список Icon Inherited by Attribute на рис. 68). В строке ввода Name Inherited by Attribute можно задать правило формирования имен атрибутов, порождаемых из домена. В правиле ис- пользуются макросы ERwin DM. В закладке Datatype можно указать абстрактный тип данных домена и обязательность значений (опция Not Nulls). Соответствие абстрактных ти- пов данных и типов данных конкретного сервера можно настроить в диа- логах Model Datatype Options и Datatype Standards Editor (меню Tools/Datatypes). В закладке Constraint определяют правила валидации – правила проверки допустимых значений (раздел Validation Constraint) и значение по умолчанию (раздел Default). Правила валидации и значения по умолчанию должны быть предварительно описаны и именованы. Каждому домену можно дать описание в закладке Definition, ввести комментарий в закладке Note, означить пользовательские свойства в закладке UDP. Для создания атрибута на основе домена следует выбрать домен в списке доменов окна навигатора Model Explorer и «перетащить» его в сущ- 71 ность на диаграмме (см. рис. 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) облегчает соблюдение правила «один факт – в одном месте». Имена ролей атрибутов внешних ключей и унификация атрибутов также облег- чают построение нормализованной модели. 72 Рис. 70. Пример ненормализованной сущности. Рис. 71. Результат нормализации сущности «Сотрудник» (3НФ). Часто нормализация не ведет к повышению производительности ин- формационной системы в целом. Например, информация о сотрудниках (рис. 70) в результате приведения к третьей нормальной норме была рас- средоточена в четырех связанных таблицах (рис. 71). Хотя общее число строк в этих таблицах может быть меньше, чем в исходной (до нормализа- ции), теперь для получения полной информации о сотруднике серверу ба- зы данных необходимо обращаться одновременно к четырем таблицам (объединение таблиц, join). Время выполнения запроса с объединением может во много раз превосходить время выполнения запроса к одной таб- лице. В приведенном примере общая производительность информацион- ной системы в результате нормализации скорее всего упадет. В целях по- вышения производительности при переходе на физический уровень прихо- дится сознательно отходить от нормальных форм, чтобы использовать возможности конкретного сервера или информационной системы в целом, т.е. проводить денормализацию. В каждом конкретном случае приходится искать конкретные решения по денормализации, учитывающие специфику информационной системы и бизнес-правила предметной области. ERwin DM позволяет сохранить на логическом уровне нормализован- ную структуру, при этом построить на физическом уровне структуру (воз- можно, денормализованную), которая обеспечит лучшую производитель- 73 ность. Для поддержки денормализации ERwin DM позволяет создавать сущности, атрибуты, ключи и домены только на уровне логической моде- ли, включив в соответствующих диалогах опцию Logical Only. (см. рис. 32, 38, 68). Такие объекты не будут отображаться на уровне физической моде- ли и не будут созданы при генерации базы данных. С другой стороны, таб- лицы, колонки, домены и индексы можно создавать только на уровне фи- зической модели (опция Physical Only в соответствующих диалогах). Кро- ме того, ERwin DM имеет набор инструментов, сведенных в панель транс- формаций (см. табл. 5), который может быть использован для денормали- зации модели. (О поддержке трансформаций в ERwin DM будет рассказано в. разделе «Трансформации».) Создание физического уровня модели Модель физического уровня «привязана» к конкретной СУБД. В связи с этим разработчики модели физического уровня должны иметь представ- ление о СУБД, для которой разрабатывается база данных. ERwin DM поз- воляет даже непрофессионалам сгенерировать каталог базы данных. Одна- ко производительность ИС в большой степени зависит от знания специфи- ки выбранной СУБД и учета этой специфики в физической модели данных. Базовыми компонентами диаграммы физического уровня модели в ERwin DM являются (рис. 72): таблицы, колонки, ограничения, представления, а также индексы, хранимые процедуры, триггеры, скрипты. Рис. 72. Базовые объекты модели физического уровня. Выбор сервера Для выбора СУБД следует, находясь на физическом уровне модели, в меню DataBase выбрать пункт Choose DataBase. В открывшемся диалоге (рис. 73) можно выбрать целевую СУБД и ее версию, установить для коло- На физическом уровне Таблицы Колонки Ограничения (отношения) Представления П П р р и и в в я я з з к к а а к к С С У У Б Б Д Д 74 нок нужный тип данных по умолчанию, а также назначить признак обяза- тельности значения для неключевых колонок (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). 75 Рис. 74. Примеры опций контекстного меню таблицы. Для редактирования свойств таблицы в ее контекстном меню (рис. 74) следует выбрать пункт Table Properties. В результате отобразится кон- текстное меню, каждый пункт в котором соответствует отдельной закладке в диалоге Table для редактирования свойств таблицы. Активизировать диалог Table можно также, выделив на диаграмме таблицу, затем в меню Model выбрав пункт Tables. Набор закладок диалога Table и, соответствен- но, свойств таблиц различается в зависимости от выбранной СУБД. В ка- честве примера на рис. 75 показаны наборы закладок Table для таблиц SQL Server 2000, SQL Server 2005 и Oracle 11. Рис. 75. Примеры закладок диалога Table. Закладки History'>Volumetrics, UDP, History диалога Table похожи на одно- именные закладки диалога Entity, закладка Comment соответствует за- кладке Definition (см. раздел «Сущности»). В закладке Physical Properties диалога Table определяют физические свойства таблицы. В закладке Vali- dation задают правила валидации. Колонки На логическом уровне колонкам соответствуют атрибуты. Изменить свойства колонки можно в диалоге Columns. Чтобы открыть этот диалог следует в диаграмме щелкнуть по таблице правой кнопкой мышки и в по- явившемся контекстном меню выбрать Columns или в меню Model выбрать пункт Columns. 76 Закладка 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 поддерживает правила валидации и значения по умолча- нию как на логическом, так и на физическом уровне модели с помощью |