Концептуальные модели позволяют более точно представить предметную область, чем реляционные и другие более ранние модели, но в настоящее время существует немного СУБД, поддерживающих эти модели. На практике наиболее распространены системы, реализующие реляционную модель, поэтому необходим метод перевода концептуальной модели в реляционную. Такой метод основывается на формировании набора предварительных таблиц из ER-диаграмм.
Для каждой сущности создается таблица, причем каждому атрибуту сущности соответствует столбец таблицы. Правила генерации таблиц из ER-диаграмм опираются на два основных фактора — тип связи и класс принадлежности сущности.
Правило 1
Если связь типа 1:1 и класс принадлежности обеих сущностей является обязательным, то необходима только одна таблица. Первичным ключом этой таблицы может быть первичный ключ любой из двух сущностей.
На ER-диаграмме связи 1:1, представленной на рисунке 4.1, класс принадлежности сущностей МЕНЕДЖЕР, ФИЛИАЛ является обязательным. Тогда согласно правилу 1 должна быть сгенерирована одна таблица следующей структуры:
Первичным ключом этой таблицы может быть и первичный ключ сущности МЕНЕДЖЕР — НМ.
Правило 2
Если связь типа 1:1 и класс принадлежности одной сущности является обязательным, а другой — необязательным, то необходимо построить таблицу для каждой сущности. Первичный ключ сущности должен быть первичным ключом соответствующей таблицы. Первичный ключ сущности, для которой класс принадлежности является необязательным, добавляется как атрибут в таблицу для сущности с обязательным классом принадлежности.
Представим, что на ER-диаграмме связи 1:1, изображенной на рисунке 4.1, класс принадлежности сущности МЕНЕДЖЕР будет обязательный, а сущности ФИЛИАЛ — необязательный. Тогда согласно правилу 2 должны быть сгенерированы две таблицы следующей структуры:
Сущность с необязательным классом принадлежности (ФИЛИАЛ) именуется родительской, а с обязательным (МЕНЕДЖЕР) — дочерней. Первичный ключ родительской сущности (НФ), помещаемый в таблицу, представляющую дочернюю сущность, называется внешним ключом родительской сущности. Связь между указанными таблицами устанавливается путем связи первичного и внешнего ключа и имеет вид
Примечание. Если внешний ключ представляет связь 1:1, то должны быть запрещены его дублирующие значения.
Правило 3
Если связь типа 1:1 и класс принадлежности обеих сущностей является необязательным, то необходимо построить три таблицы — по одной для каждой сущности и одну для связи. Первичный ключ сущности должен быть первичным ключом соответствующей таблицы. Таблица для связи среди своих атрибутов должна иметь ключи обеих сущностей.
Представим, что на ER-диаграмме связи 1:1, изображенной на рис. 1.4, класс принадлежности сущностей МЕНЕДЖЕР, ФИЛИАЛ будет необязательный. Тогда согласно правилу 3 должны быть сгенерированы три таблицы следующей структуры:
При этом осуществляется декомпозиция связи 1:1 на две связи 1:1 следующим образом:
Итак, для связи типа 1:1 существуют три отдельных правила формирования предварительных таблиц из ER-диаграмм.
Для связи типа 1:М существуют только два правила. Выбор одного из них зависит от класса принадлежности сущности на стороне М. Класс принадлежности сущности на стороне 1 не влияет на выбор.
Правило 4
Если связь типа 1:М и класс принадлежности сущности на стороне М является обязательным, то необходимо построить таблицу для каждой сущности. Первичный ключ сущности должен быть первичным ключом соответствующей таблицы. Первичный ключ сущности на стороне 1 добавляется как атрибут в таблицу для сущности на стороне М.
На ER-диаграмме связи 1:М, представленной на рисунке 4.1, класс принадлежности сущности СЧЕТ является обязательным. Тогда согласно правилу 4 должны быть сгенерированы две таблицы следующей структуры:
Связь между указанными таблицами будет иметь вид
Примечание. Если внешний ключ представляет связь 1:М, то должны быть разрешены его дублирующие значения.
Правило 5
Если связь типа 1:М и класс принадлежности сущности на стороне М является необязательным, то необходимо построить три таблицы — по одной для каждой сущности и одну для связи. Первичный ключ сущности должен быть первичным ключом соответствующей таблицы. Таблица для связи среди своих атрибутов должна иметь ключи обеих сущностей.
Представим, что на ER-диаграмме связи 1:М, изображенной на рисунке 4.1, класс принадлежности сущности СЧЕТ является необязательным. Тогда согласно правилу 5 должны быть сгенерированы три таблицы следующей структуры:
При этом осуществляется декомпозиция связи 1:М на две связи — 1:М и 1:1 следующим образом:
Для связи типа M:N класс принадлежности сущности не имеет значения.
Правило 6
Если связь типа M:N, то необходимо построить три таблицы — по одной для каждой сущности и одну для связи. Первичный ключ сущности должен быть первичным ключом соответствующей таблицы. Таблица для связи среди своих атрибутов должна иметь ключи обеих сущностей.
ER-диаграмма связи M:N имеется на рисунке 4.1. Согласно правилу 6 на основании этой ER-диаграммы должны быть сгенерированы три таблицы следующей структуры:
При этом осуществляется декомпозиция связи M:N на две связи 1:М следующим образом:
В таблице КЛИЕНТ — СЧЕТ клиенту, имеющему, например, Три счета, будут соответствовать три строки с одним и тем же номером клиента. А счет, у которого, например, два владельца, представляется двумя строками с различными номерами клиентов, владеющих этим счетом.
К ER-модели предметной области БАНК,представленной на рис. 4.5, применимы правила 1, 4, 6. Связь МЕНЕДЖЕР — ФИЛИАЛ (согласно правилу 1) представляется одной таблицей
Связь ФИЛИАЛ — СЧЕТ (согласно правилу 4) представляется связью
Связь КЛИЕНТ — СЧЕТ (согласно правилу 6) представляется связью
Анализ состава атрибутов полученных таблиц А, В, С, D, Е, F показывает, что таблица В является составной частью таблицы А, таблица Е — составной частью таблицы С. Поэтому таблицы В, Е можно исключить из рассмотрения. Оставшиеся таблицы А, С, D, F можно связать посредством связи первичных и внешних ключей (рисунок 4.2).
Рисунок 4.2 – Реляционная модель предметной области БАНК
В результате получим реляционную модель для ER-модели предметной области БАНК.
