Отображение модели ER в реляционную модель

Чтобы понять это, вы должны иметь представление о:

ER модель

Модель отношений

После разработки диаграммы ER системы нам необходимо преобразовать ее в реляционные модели, которые могут быть напрямую реализованы любой СУБД, такой как Oracle, MySQL и т. Д. В этой статье мы обсудим, как преобразовать диаграмму ER в реляционную модель для различных сценариев.

Случай 1: Бинарные отношения с мощностью 1: 1 при полном участии объекта

У человека есть 0 или 1 номер паспорта, и паспорт всегда принадлежит 1 человеку. Таким образом, мощность 1: 1 с ограничением полного участия от Passport.

Сначала преобразуйте каждую сущность и связь в таблицы. Таблица Person соответствует объекту Person с ключом Per-Id. Точно так же таблица паспортов соответствует паспортному объекту с ключом в качестве номера доступа. Таблица имеет отношение между человеком и паспортом (у какого человека какой паспорт). Таким образом, он будет принимать атрибут Per-Id от Person и Pass-No от Passport.

Таблица 1

Как видно из таблицы 1, каждый Per-Id и Pass-No имеет только одну запись в таблице Has. Таким образом, мы можем объединить все три таблицы в 1 с атрибутами, показанными в таблице 2. Каждый Per-Id будет уникальным и не будет нулевым. Так что это будет ключ. Pass-No не может быть ключевым, потому что для некоторых людей он может быть NULL.

Таблица 2

Случай 2: Бинарные отношения с мощностью 1: 1 и частичным участием обоих объектов

Мужчина женится на 0 или 1 женщине, и наоборот. Таким образом, мощность 1: 1 с ограничением частичного участия от обоих. Сначала преобразуйте каждую сущность и связь в таблицы. Таблица Male соответствует объекту Male Entity с ключом M-Id. Точно так же женская таблица соответствует женской сущности с ключом F-Id. Таблица женитьбы представляет отношения между мужчиной и женщиной (какой мужчина женится на какой женщине). Таким образом, он будет принимать атрибут M-Id от Male и F-Id от Female.

Таблица 3

Как видно из таблицы 3, некоторые мужчины и некоторые женщины не вступают в брак. Если мы объединим 3 таблицы в 1, для некоторого M-Id F-Id будет NULL. Таким образом, нет атрибута, который всегда отличался бы от NULL. Таким образом, мы не можем объединить все три таблицы в 1. Мы можем преобразовать в 2 таблицы. В таблице 4 M-Id, состоящие в браке, будут иметь связанный F-Id. Для других это будет NULL. В таблице 5 будет информация обо всех женщинах. Первичные ключи подчеркнуты.

Таблица 4

Таблица 5                                                                 

Примечание. Бинарная связь с мощностью 1: 1 будет иметь 2 таблицы при частичном участии обеих сущностей в отношении. Если хотя бы 1 организация имеет полное участие, количество необходимых столов будет равно 1.

Случай 3: Бинарные отношения с числом элементов n: 1

В этом сценарии каждый студент может записаться только на один факультативный курс, но на факультативный курс может быть более одного студента. Сначала преобразуйте каждую сущность и связь в таблицы. Таблица Student соответствует объекту Student с ключом S-Id. Точно так же таблица Elective_Course соответствует объекту Elective_Course с ключом в качестве E-Id. Таблица Enrolls представляет взаимосвязь между Student и Elective_Course (какой студент зачисляется на какой курс). Таким образом, он будет принимать атрибут S-Id от и Student E-Id от Elective_Course.

Таблица 6

Как видно из таблицы 6, S-Id не повторяется в таблице Enrolls. Таким образом, его можно рассматривать как ключ таблицы Enrolls. Ключи учащихся и таблиц регистрации одинаковые; мы можем объединить его как одну таблицу. Полученные таблицы показаны в Таблице 7 и Таблице 8. Первичные ключи подчеркнуты.

Таблица 7

Таблица 8

Случай 4: Бинарная связь с мощностью m: n

В этом сценарии каждый студент может записаться на более чем 1 обязательный курс, а на обязательный курс может быть более 1 студента. Сначала преобразуйте каждую сущность и связь в таблицы. Таблица Student соответствует объекту Student с ключом S-Id. Точно так же таблица Compulsory_Courses соответствует объекту обязательных курсов с ключом C-Id. Таблица Enrolls представляет взаимосвязь между студентом и обязательными_курсами (какой студент зачисляется на какой курс). Таким образом, он будет принимать атрибут S-Id от Person и C-Id от Compulsory_Courses.

Таблица 9

Как видно из таблицы 9, S-Id и C-Id повторяются в таблице Enrolls. Но его сочетание уникально; поэтому его можно рассматривать как ключ таблицы Enrolls. Ключи всех таблиц разные, их нельзя объединить. Первичные ключи всех таблиц подчеркнуты.

Случай 5: Бинарные отношения со слабой сущностью

В этом сценарии у сотрудника может быть много иждивенцев, и один иждивенец может зависеть от одного сотрудника. Иждивенец не может существовать без работника (например, вы в детстве можете находиться на иждивении своего отца в его компании). Таким образом, это будет слабая организация, и ее участие всегда будет полным. У слабой сущности нет собственного ключа. Таким образом, его ключ будет представлять собой комбинацию ключа его идентифицирующего объекта (в данном случае E-Id сотрудника) и его частичного ключа (D-Name).

Сначала преобразуйте каждую сущность и связь в таблицы. Таблица сотрудников соответствует сущности сотрудников с ключом E-Id. Точно так же таблица зависимых соответствует зависимой сущности с ключом как D-Name и E-Id. Таблица имеет отношение между сотрудником и иждивенцами (у какого сотрудника какие иждивенцы). Таким образом, он будет принимать атрибут E-Id от сотрудника и D-Name от иждивенцев.

 Таблица 10

 Как видно из таблицы 10, E-Id, D-Name являются ключевыми как для таблицы Has, так и для таблицы зависимостей. Итак, мы можем объединить эти две в 1. Итоговые таблицы показаны в таблицах 11 и 12. Первичные ключи всех таблиц подчеркнуты.

Таблица 11

Таблица 12

Статья предоставлена Sonal Tuteja . Пожалуйста, напишите комментарии, если вы обнаружите что-то неправильное, или вы хотите поделиться дополнительной информацией по теме, обсужденной выше.