Добавил:
Upload Опубликованный материал нарушает ваши авторские права? Сообщите нам.
Вуз: Предмет: Файл:
6сем ПБЗ шпоры.doc
Скачиваний:
87
Добавлен:
27.10.2018
Размер:
2.74 Mб
Скачать

26. Правила преобразования er-диаграмм в реляционные таблицы в случае связи 1:м, м:n.

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

Для каждой сущности создается таблица. Причем каждому атрибуту сущности соответствует столбец таблицы.

Правила генерации таблиц из ER-диаграмм опираются на два основных фактора – тип связи и класс принадлежности сущности

Для связи типа 1:М существуют только два правила. Выбор одного из них зависит от класса принадлежности сущности на стороне M. Класс принадлежности сущности на стороне 1 не влияет на выбор.

Правило 1:

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

На ER-диаграмме связи 1:М, представленной на рис. 1.5, класс принадлежности сущности СЧЕТ является обязательным. Тогда согласно правилу 1 должны быть сгенерированы две таблицы следующей структуры:

Связь между указанными таблицами будет иметь вид

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

Правило 2:

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

Представим, что на ER-диаграмме связи 1:М, изображенной на рис. 1.5, класс принадлежности сущности СЧЕТ является необязательным. Тогда согласно правилу 2 должны быть сгенерированы три таблицы следующей структуры:

При этом осуществляется декомпозиция связи 1:М на две связи – 1:М и 1:1 – следующим образом:

Для связи типа М:N класс принадлежности сущности не имеет значения.

Правило 3:

Если связь типа М:N, то необходимо построить три таблицы – по одной для каждой сущности и одну для связи. Первичный ключ сущности должен быть первичным ключом соответствующей таблицы. Таблица для связи среди своих атрибутов должна иметь ключи обеих сущностей.

ER-диаграмма связи М:N имеется на рис. 1.5. Согласно правилу 3 на основе этой ER-диаграммы должны быть сгенерированы три таблицы следующей структуры:

При этом осуществляется декомпозиция связи М:N на две связи 1:М следующим образом:

27. Проблемы er-моделирования (ловушка разветвления, ловушка разрыва, ловушка соединения)

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

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

Дефект типа "разветвление" возникает в том случае, когда две или несколько связей типа 1:М исходят из одной сущности. Потенциальный дефект типа "разветвление" показан на рисунке, на котором две связи типа 1:М (Has и Operates) исходят из одной и той же сущности Division.

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

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

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

Рассмотрев эту модель, можно сделать вывод, что одно отделение компании имеет много сотрудников, которые работают со сдаваемыми в аренду объектами. Однако не все сотрудники непосредственно работают с объектами и не все сдаваемые в аренду объекты недвижимости в каждый конкретный момент находятся в ведении кого-либо из сотрудников компании. В данном случае проблема возникает, когда необходимо выяснить, какие объекты недвижимости приписаны к тому или иному отделению компании.

Ловушки разветвления – Модель отображает связь между типами сущностей, но путь между отдельными сущностями определён неоднозначно. Появляется, когда несколько связей One-To-Many выходят из одной сущности.

Пример дефекта:

Устранение дефекта:

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

Пример дефекта:

Устранение дефекта:

Соседние файлы в предмете [НЕСОРТИРОВАННОЕ]