Как сделать связь многие ко многим в erwin

Обновлено: 03.07.2024

Извиняюсь конечно) но разъясните вот есть диаграмма и она приемлимо сделана ? тобишь верно ли , что все связи выходят из родительской сущности и не могу понять вот у таблицы переговоры ПЕРвичным ключом нужно сделать ещё какой то атрибут либо можно обойтись и FK либо атрибуты-ведутся и не ведутся надо добавить в первичный ключ .

Подключение erwin
Здравствуйте. Необходимо сгенерировать схему из erwin в sql server. При подключении или генерации.

ER - диаграммы в ERWIN и access
SOS. Помогите пжт, уже кучу инфы перечитала, не могу никак.

ERwin и SQL Server 7.0
Никак не соображу, как модель данных из ERwin экспортировать? Кто-нибудь подскажет?

Ошибка при генерации бд в ERwin
CREATE RULE DepId_more_than_0 AS DepId > 0 The name "DepId" is not permitted in this context.

у каждого вида работа имеется статус работ ! так вот таблицу Статус работ соединить через таблицу виды работ или так тоже будет верно .

Исходя того, что изобразил
1. Таблицы Переговоры, Связь, Вид работ не нужны - всю информацию из них можно поместить в Справочник фирм
2. Таблицы Расчет, Заказчик - первичные ключи не нормальные. Для каждой сделать не составной первичный ключ, остальные поля убрать из ключей
3. Таблица статус работ похоже тоже не нужна - даты начала и окончания вполне впишутся в таблицу Заказчик
По факту все может быть совершенно по другому, нет информации для анализа

Так задачу не описывают. Например Фирма - сколько может быть заказчиков 0, 1 или больше. Счет один или несколько. И так по каждой предполагаемой связи. Пока такого не будет получится гадание на кофейной гуще. Сделай сначала модель на бумаге, продумай все, только после этого эрвины

Вообщем, да ! Значит Фирма это и есть заказчик , просто от это фирмы выступает должностное лицо данные которого регистрируются в таблице ЗАКАЗЧИК ! А в таблице ФИРМа регистрируется Юр адрес итд.От каждой фирмы может быть несколько заказчиков. Для каждого заказчика может выполняться несколько видов работ(хостинг, реклама, разработка). По каждому виду работы выставляется свой счёт ! Так же для каждого вида работ фиксируется дата начала работы и дата окончания работы.
Вот вроде в схеме всё верно, но как соединить переговоры и расчёт . (

не приемлемо. все блоки должны быть 1го размера для начала.

вы совсем все в кучу свалили. выделите основные сущности и сущности-связи.

1. Таблица Заказчик. Зачем составной первичный ключ? Достаточно одного первичного ключа id_заказчика

2. Таблица Приоритет заказчика. Для чего вообще нужна? Если у заказчика может быть только один из приоритетов (высокий, средний или низкий), то достаточно в поле Приоритет заказчика хранить 1, 2 или 3

3. Таблица Виды работ. Зачем составной первичный ключ? Достаточно одного первичного ключа id_работы. Внешний ключ id_firm и само поле вообще не нужно. Вместо полей Хостинг, Реклама и Разработка достаточного одного поля с видом работы с возможным значением 1, 2 или 3. Для каждого вида работы по заказчику отдельная запись в этой таблице

4. Таблица статус работ. Достаточно одного первичного ключа id_статус. Внешнии ключи id_firm, id_заказчика и сами поля не нужны

FK это внешний ключ он мигрирует автоматически из родителя в потомка для сохранения целостности данных ! Не понял.

Вместо полей Хостинг, Реклама и Разработка достаточного одного поля с видом работы с возможным значением 1, 2 или 3. Для каждого вида работы по заказчику отдельная запись в этой таблице

эти пункты можно поподробней пожалуйста .
понял что можно сделать просто одно поле ПРИОРИТЕТ ЗАКАЗЧИКА в таблице ЗАКАЗЧИК ! Это действительно будет умней )

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

Tablica1: id1 - первичный
Tablica2: id2 - первичный, id1 - внешний
Tablica3: id3 - первичный, id2 - внешний

Спасибо ! вышло так вот ! правда не понятно в таблице Статус работы нужно хранить и примечания,и ведутся ли работы или нет ,и дату начала ,и дату окончания работы ! А как это всё будет реализовано в одном столбце что ли одной таблице Статус работ .
И пунктиром обозначаются НЕ ЗАВСИСИМЫЕ связи ведь . а почему все они должны быть не зависимыми ?

и в таблице -Вид работы- поле я на картинке не вставил просто. будет один столбец с названием вид работы, а что именно это за вид работ как узнать то. ты говоришь 1 2 3 значения хранить и типа просто условиться, что 1 - реклама 2 - хостинг 3 - разработка. так получается ?

Поле определяющее вид работы в в 3-ей таблице зря убрал. Но одно поле вместо трех. И в 4-ой кроме ключей информация куда делась?
А связи нормальные, отношение один к многим и внешний ключ не является частью первичного ключа. Хотя иногда и удобно делать его частью первичного ключа при реализации отношения многие к многим через таблицу связи

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

• идентифицирующая связь — связь, определяющая однозначное соответствие экземпляра одной сущности единственному экземпляру связанной сущности и, как правило, описывает связь 1:1, но при реализации сцепленного первичного ключа может реализовывать связь один — ко — многим (1:JV);
• неидентифицирующая связь — связь, реализующая тип связи один — ко — многим (1 :N), представляя внешний ключ в связанной сущности в качестве простого атрибута, на который могут быть наложены определенные дополнительные ограничения по сравнению с обычными информационными атрибутами;
• множественная связь — связь, реализующая тип связи многие — ко — многим (Л Г :М), представляется только на уровне логической модели, иллюстрируя соединение между сущностями, но не создавая внешних ключей в связанных сущностей;
• категоризационная — связь, обеспечивающая связывание сущности- общности с сущностями-категориями типом связи один — к — одному (1:1) и одновременно создающая внешний первичный ключ в сущностях-категориях, связанный с первичным ключом сущности-общности.

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

Инструментальное средство ERWin, при установлении связей между сущностями, определяет два вида сущностей:

• родительская (Parent) — является базовой сущностью, первичный ключ которой может мигрировать в связанную сущность;
• дочерняя (Child) — определяется сущностью, которая при установлении связи получает внешний ключ, формируемый из мигрирующего первичного ключа родительской сущности.

Такое разделение выглядит вполне логичным, поскольку, исходя из особенностей выстраивания связей и логики предметной области, сведения, описываемые родительской сущностью, являются агрегирующими в отношении к данным, описываемым дочерней сущностью. Например, рассматривая связь между сущностями "Клиент" и "Заказ", конкретный клиент, представляемый экземпляром сущности "Клиент", объединяет (агрегирует) множество заказов, которые он создал в электронном мага-

зине. В результате, сущность "Заказ" по отношению к сущности "Клиент" можно рассматривать в качестве дочерней, а сущность "Клиент" — родительской.

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

Рис. 3.15. Базовое описание связи в ERWin

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

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

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

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

Рис. 3.16. Основные характеристики связи в РЖ Win

Обычно, при установлении не идентифицирующей связи параметр "Null Option" устанавливается в значение "Nulls Not Allowed" (NULL недопустим). Это определяется особенностями работы с данными, в соответствии с которыми дочерний экземпляр данных должен быть связан с родительским экземпляром. Но иногда бывают случаи, когда это не соблюдается. Как правило, такая ситуация возникает, когда объекты предметной области, объединяемые этой связью, являются равнозначными и невозможно однозначно определить первоочередность появления экземпляра той или иной сущности. Тогда устанавливается значение "Null Allowed" (NULL допускается), как это показано в примере (см. рис. 3.17).

Рис. 3.17. Определение типа связи в ERWin

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

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

Другой характеристикой, которая дает возможность переходить от связи один — к — одному к связи один — ко — многим и наоборот, является кардинальность. Установление кардинальности (мощности) связи в рамках свойств "Cardinality" и "Cardinality Value" задает правила наполнения экземплярами дочерней сущности (рис. 3.18). Предусматривается четыре варианта кардинальности, определяемые средством ERWin:

• Zero, One or More (ноль, один или много) — для дочерней сущности возможно любое количество экземпляров, связанных с одним экземпляром родительской сущности, включая вариант отсутствия экземпляров;
• (Р) One or More (один или много) — количество экземпляров дочерней сущности, связанных с одним экземпляром родительской сущности, может быть любым, но при создании экземпляра в родительской сущности в дочерней сущности экземпляры уже должны существовать, что требует установления параметра "Null Option" в значение "Nulls Allowed", разрешая хранение пустого значения "NULL" во внешнем ключе, полученном при установлении связи;
• (Z) Zero or One (ноль или один) — определяется связь один — к - одному, разрешая существование не более одного экземпляра данных в дочерней сущности;
• Cardinality Value (значение кардинальности) — указывает точное количество связанных экземпляров в дочерней сущности, что может быть реализовано только при варианте параметра "Null Option" в значении "Nulls Allowed", первичном создании экземпляров в дочерней сущности и последующим их увязыванием с экземпляром в родительской сущности.

Рис. 3.18. Определение кардинальности (мощности) связи в ERWin

В результате указания кардинальности (мощности) связи на модели в диаграмме будет отображено ее буквенно-цифровое обозначение. Если выбирается вариант кардинальности (мощности) в варианте "Один или много", то будет отображена литера "Р", в случае кардинальности "Ноль или один" — литера "Z", в случае указания точного числового значения — указанное значение, в других вариантах не будет отображаться никаких обозначений на модели.

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

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

Рис. 3.19. Описание смыслового наполнения связи в ERWin

При установлении связей один — к — одному и один — ко — многим, как рассматривалось выше, первичный ключ родительской сущности мигрирует в дочернюю сущность, создавая соответствующий внешний ключ (рис. 3.20). Зачастую, особенно при использовании соглашения наименований элементов моделей, в разных сущностях идентичные первичные ключи могут иметь одинаковые наименования, что вызывает некоторые сложности при установлении связей, выражаясь в необходимости отражения внешних ключей с наименованиями, которые уже присутствуют в сущности. Другим вариантом, когда необходимо воспользоваться механизмом именования правила миграции ключа, может быть необходимость в более точной формулировке атрибута, описывающего соответствующий внешний ключ.

Рис. 3.20. Описание правил миграции ключей в ERWin

Решение этих задач реализуется через механизм "Role Name", где разработчик указывает имя атрибута для внешнего ключа, как оно должно быть представлено в модели базы данных и, в итоге трансформации, в базе данных. Область "Role Name Info" содержит две колонки:

• Migrated Attribute (мигрирующий атрибут) — показывает атрибут родительской сущности, который представляется внешним ключом в связанной дочерней сущности (изменению не подлежит);
• Role Name (имя роли) — обозначает новое значение названия атрибута внешнего ключа, которое должно использоваться вместо имени мигрирующего атрибута.

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

Определение правил ссылочной целостности (рис. 3.21) является этапом физического моделирования базы данных. Связано это с тем, что отдельные правила для некоторых СУБД могут быть недоступны. Тем не менее, ERWin на этапе логического моделирования предоставляет возможность указать правила ссылочной целостности для формируемых связей. На этом этапе разработчику предлагается максимальный набор правил [1] :

• None (отсутствует) — правило, предполагающее любые действия пользователя без влияния на другие элементы базы данных;
• No Action (без действия) — правило, предполагающее определенные разработчиком действия;
• Restrict (запретить) правило, запрещающее выполнение операции над данными, если проверочное условие выполняется;
• Cascade (каскадно) — правило, выполняющее последовательные действия над связанными данными в соответствии с действием, выполняемым над данными, к которым определено данное правило;
• Set Null (установить NULL) — правило, устанавливающее значение NULL внешнему ключу для связанных экземпляров;
• Set Default (установить умолчание) — правило, устанавливающее значение по умолчанию, определенное для внешнего ключа связанного экземпляра.

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

Рис. 3.21. Определение правил ссылочной целостности в ЕКШіп

При формировании связи многие — ко — многим разработчику предоставляет возможность указания минимального набора характеристик связи, включающих в себя определение смысловой нагрузки. Никакие другие правила и характеристики для данного типа связи не устанавливаются, поскольку при переходе к физической модели такая связь должна быть нормализована и представлена связями один — ко — многим (рис. 3.22).

Рис. 3.22. Пример реализации связи категоризации в ERWin

Связь категоризации организуется в форме множества связей один к — одному, объединенных специализированным графическим элементом. Для ее реализации в ЕИЛУт необходимо:

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

В результате выполнения этих действий в модели базы данных будет представление связи аналогично указанному выше примеру (см. рис. 3.22).

Связь категоризации бывает двух типов, один из которых необходимо определить при установлении этого типа связи (рис. 3.23). Для обозначения различий в типе связи категоризации обозначение графического элемента будет представляться с двумя чертами или одной чертой (табл. 3.1).

Рис. 3.23. Определение типа связи категоризации в ERWin

Тины связи категоризации и обозначения в ERWin

Complete (полная связь категоризации) — во всех сущностях- категориях будут содержаться экземпляры из сущности-общности, показывая необходимость полного описания (по всем сущностям-категориям) каждого экземпляра из сущности- общности

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

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

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

Первым шагом при создании логической модели БД является построение диаграммы ERD (Entity Relationship Diagram). ERD-диаграммы состоят из трех частей: сущностей, атрибутов и взаимосвязей. Сущностями являются существительные, атрибуты - прилагательными или модификаторами, взаимосвязи - глаголами.

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

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

ERD-диаграммы

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

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

Рис. 6.1. Пример ERD-диаграммы,

Определение сущностей и атрибутов

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

На рис. 6.2 показана ERD-диаграмма, включающая в себя атрибуты сущностей.

Рис. 6.2. ERD-диаграмма с атрибутами

Логические взаимосвязи

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

Некоторые примеры взаимосвязей:

команда включает много игроков,
самолет перевозит много пассажиров,
продавец продает много продуктов.

Проверка адекватности логической модели

Если взаимосвязи между сущностями были правильно установлены, то можно составить предложения, их описывающие. Например, по модели, показанной на рис. 6.3, можно составить следующие предложения:

Самолет перевозит пассажиров. Много пассажиров перевозятся одним самолетом.

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

Рис. 6.3. Пример логической модели со взаимосвязью

Модель данных, основанная на ключах

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

Выбор первичного ключа

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

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

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

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

Потенциальный ключ, не ставший первичным, называется альтернативным ключом (Alternate Key). ERWin позволяет выделить атрибуты альтернативных ключей, и по умолчанию в дальнейшем при генерации схемы БД по этим атрибутам будет генерироваться уникальный индекс. При создании альтернативного ключа на диаграмме рядом с атрибутом появляются символы (АК).

Атрибуты, участвующие в неуникальных индексах, называются инверсионными входами (Inversion Entries). Инверсионные входы - это атрибут или группа атрибутов, которые не определяют экземпляр уникальным образом, но часто используются для обращения к экземплярам сущности. ERWin генерирует неуникальный индекс для каждого инверсионного входа.

При проведении связи между двумя сущностями в дочерней сущности автоматически образуются внешние ключи (foreign key). Связь образует ссылку на атрибуты первичного ключа в дочерней сущности, и эти атрибуты образуют внешний ключ в дочерней сущности. Атрибуты внешнего ключа обозначаются символами (FK) после своего имени.

Пример

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

Атрибут

Описание

Рис. 6.4. ERD-диаграмма БД студентов

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

Следующим этапом при построении логической модели является определение ключевых атрибутов и типов атрибутов.

Есть схема БД "Проведения лабораторных работ".

Я в ERwin 4.0 нашёл только связи "один ко многим" и "многие ко многим"

Может схема неправельная у меня и её надо переделывать или как сделать эту связь?

Описание схемы:
1. Студент входит в систему введя: группу, шифр, фамилию, имя, если студент ввёл неправельно, то его просят заного войти в систему.
2. Студент может получить все данные из БД.

Цель работы : освоить методологию создания ER -моделей.

Теоретическая справка

ERwin имеет развитый инструмент для облегчения проектирования модели данных. Интерфейс выполнен в стиле Windows-приложений, достаточно прост и интуитивно понятен.

Кнопки панели инструментов описаны в таблице 2.

Создание, открытие, сохранение и печать модели.

Вызов диалога Report Browser для генерации отчетов.

Изменение уровня просмотра модели: уровень сущностей, уровень атрибутов и уровень определений.

Изменение масштаба просмотра модели.

Генерация схемы БД, выравнивание схемы с моделью и выбор сервера (доступны только на уровне физической модели)

Вызов дополнительной панели инструментов для работы с репозиторием Model Mart. (Работа с Model Mart будет рассмотрена в следующей статье).

Переключение между областями модели - Subject Area.

Для создания моделей данных в ERwin можно использовать две нотации: IDEF1X и IE (Information Engineering). В примерах будет использоваться нотация IDEF1X. Для внесения сущности в модель необходимо (убедившись предварительно, что Вы находитесь на уровне логической модели - переключателем между логической и физической моделью служит раскрывающийся список в правой части панели инструментов) кликнуть по кнопке сущности на панели инструментов (ERwin Toolbox) , затем кликнуть по тому месту на диаграмме, где Вы хотите расположить новую сущность. Кликнув правой кнопкой мыши по сущности и выбрав из всплывающего меню пункт Entity Editor. можно вызвать диалог Entity Editor, в котором определяются имя, описание и комментарии сущности.

Рисунок 5 - Диалог Entity Editor

Каждая сущность должна быть полностью определена с помощью текстового описания в закладке Definition. Закладки Note, Note2, Note3, UDP (User Defined Properties - Свойства, Определенные Пользователем) служат для внесения дополнительных комментариев и определений сущности. В закладке Icon каждой сущности можно поставить в соответствие изображение (файл bmp), которое будет отображатся в режиме просмотра модели на уровне иконок (см. ниже).

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

Рисунок 6 - Диалог Attribute Editor

- Имя, Фамилия, Отчество, Дата рождения

К первичным ключам предъявляются определенные требования. Первичный ключ должен однозначно идентифицировать экземпляр сущности (этому требованию не удовлетворяет четвертый ключ, поскольку он может идентифицировать группу сотрудников, работающих в определенном отделе, но не каждого сотрудника). Первичный ключ должен быть компактен, то есть удаление любого атрибута из состава первичного ключа должно приводить к потере уникальности экземпляра сущности (если удалить Дату рождения из первого ключа, то невозможно будет идентифицировать полных тезок). Каждый атрибут из состава первичного ключа не должен принимать NULL - значений (например, если принять в качестве первичного ключа номер паспорта, необходимо быть уверенным, что все сотрудники имеют паспорта). Каждый атрибут первичного ключа не должен менять свое значение в течение всего времени существования экземпляра сущности (сотрудник может сменить фамилию и паспорт, поэтому первый и второй потенциальные ключи не могут стать первичными). Потенциальные ключи, не ставшие первичными, называются альтернативными. Атрибуты, или наборы атрибутов, использующиеся для доступа к группе экземпляров сущности, называются инверсионными ключами. Для описания альтернативных и инверсионных ключей необходимо кликнуть по кнопке . (диалог Attribute Editor, закладка Key Group) и в появившемся диалоге закладка Key Group Editor создать новую ключевую группу (либо инверсионную, либо альтернативную) и указать, какие атрибуты входят в ту или иную группу.

Рисунок 7 - Диалог Key Group Editor

ERwin имеет несколько уровней отображения диаграммы. Преключиться между ними можно кликнув по любому месту диаграммы, не занятому объектами модели и выбрав в появившемся меню пункт Display Level. В таблице 3 показаны уровни отображения модели.

Первичный ключ

Primary Key

Определение Definition

Иконки Icon

На уровне атрибутов атрибуты альтернативного ключа помечаются номером (AKm.n), где m - номер ключа, n - номер атрибута в ключе. Инверсионные ключи помечаются номером (IEm.n). В дальнейшем при генерации БД на атрибутах альтернативных ключей могут быть сгенерированы уникальные индексы, на атрибутах инверсионного ключа - неуникальные. Имена индексов задаются в диалоге New Key Group (рис. 7). Атрибуты первичного ключа отображаются выше горизонтальной линии - прочие атрибуты - ниже.

Рисунок 8 - Иллюстрация второй нормальной формы

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

Для редактирования свойств связи следует кликнуть правой кнопкой мыши по связи и выбрать на контекстном меню пункт Relationship Editor. В появившемся диалоге можно задать:

- мощность (cardinality) связи - служит для обозначения отношения числа экземпляров родительской сущности к числу экземпляров дочерней.

- verb phrase - фраза, характеризующая отношение между родительской и дочерней сущностями.

- тип связи (идентифицирующая / не идентифицирующая).

- правила ссылочной целостности (будут сгенерированы при генерации схемы бд).

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

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

Рисунок 10 - Иллюстрация разрешения связи многие ко многим.

Рисунок 11 - Иерархия категорий

При создании реальных моделей данных количество сущностей и атрибутов может исчисляться сотнями. Для более удобной работы с большими моделями в ERwin'е предусмотрены предметные области (Subject Area), в которые можно включить тематически общие сущности. Для создания предметных областей нужно вызвать диалог Subject Area Editor (меню Edit/ Subject Area. ), в котором указывается имя предметной области и входящие в нее сущности. Все изменения, сделанные в предметной области, автоматически отображаются на общей модели

Рисунок 12 - Диалог Subject Area Editor

Физический уровень представления модели зависит от выбранного сервера (меню Server/ Target Server..). На физическом уровне модель данных необходимо дополнить такой информацией как учет ограничений ссылочной целостности, хранимые процедуры, триггеры, индексы. Триггеры и хранимые процедуры представляют собой программный код и хранятся на сервере. ERwin обеспечивает мощный инструментарий для создания триггеров: шаблоны и библиотеки макросов. Макросы содержат наиболее часто используемые данные и конструкции. Для редактирования шаблонов триггеров используется редактор Trigger Template Editor (для его вызова следует кликнуть правой кнопкой по таблице и выбрать пункт Trigger в появившемся меню).

Рисунок 13 - Диалоги Trigger Template Editor и ERwin Template Toolbox

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

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

Задание

Необходимо построить ER модель данных, содержащую не менее 5 сущностей, в каждой из которых не менее 4 атрибутов. Связать сущности по ключевым атрибутам.

Читайте также: