
- •Сикха Багуи и Ричард Ирп
- •Контрольные вопросы 1.1
- •Модели данных
- •Иерархическая Модель
- •Сетевая модель
- •Реляционная модель
- •Контрольные вопросы 1.2
- •Функциональные зависимости
- •Правило декомпозиции (разложения)
- •Правило объединения
- •Контрольные вопросы 1.3
- •Краткий обзор метода нормальных форм
- •Примеры 1нф, 2нф и 3нф
- •Упражнение 1.3
- •Глава 2: Базовая er-диаграмма – схема
- •Некоторые определения баз данных: Сущность, Связь, Атрибут
- •Начальная Методология
- •Еще об атрибутах
- •Простые или атомарные атрибуты
- •Многозначные атрибуты
- •Производный атрибуты
- •Описание Сущности на структурном английском языке
- •Сущность
- •Атрибуты
- •Методология er-проектирования
- •Примеры
- •Сущность
- •Атрибуты
- •Методология er проектирования
- •Итоги главы
- •Упражнения Главы
- •Упражнение 2.1
- •Упражнение 2.2
- •Проработка примера
- •Сущность
- •Глава 3: После первой диаграммы сущности
- •Проверка Сущности — замена атрибута сущностью
- •Методология er-проектирования
- •Определение вторичной сущности
- •Существует ли связь?
- •Атрибут или Связь?
- •Глава 4: Расширение связей/ Структурные
- •1(Полное участие):1:
- •Глава 5: Слабая Сущность
- •Грамматика Слабой Сущности
- •Контрольные вопросы 5.3
- •Упражнения Главы 5. Упражнение 5.1
- •Список литературы
- •Сущность
- •Атрибуты для отдела
- •Сущность
- •Атрибуты для служащего
- •Глава 6: Дальнейшее Расширение
- •Сущность
- •Атрибуты
- •Более двух Сущностей
- •С указанием всех атрибутов
- •Развитие базы данных
- •Глава 7: Троичные и er-диаграммы более высокого порядка
- •Глава 8: Обобщения и специализации.
- •Глава 9: Реляционные преобразования и
- •Глава 10: Краткий обзор модели Баркера
- •Глава 10. Упражнения.
Глава 9: Реляционные преобразования и
обратное проектирование ER-диаграмм
На протяжении всей книги мы определяли правила преобразования ER-диаграмм в реляционную базу данных. В этой главе мы объединим все правила преобразования, а также обсудим обратное проектирование.
Бывают случаи, когда база данных существует и без соответствующей ER-диаграммы.ER-диаграмма является документацией, и База данных требует документального описания также, как и компьютерная программа. Поэтому мы включили раздел обратного проектированияER-диаграмм; т.е.когда мы проектируемER-диаграмму из разработанной базы данных. Для обратного проектирования мы предлагаем набор шагов построения диаграммы из набора данных.
Правила преобразования ER-диаграммы в реляционную
базу данных
Ниже представлен окончательный набор шагов, необходимых для преобразования ER- диаграммы в реляционную базу данных. Если следовать этим правилам, то в результате должны получиться таблицы, близкие к 3НФ (3-ей нормальной форме). Однако, эти правила не препятствуют дополнительной проверке получившейся базы данных для четкой уверенности в том, что она действительно нормализована. И даже если эти правила были применены неверно, остается шанс, что полученная база данных будет находится в 3НФ.
Шаг 1: Преобразование сильных сущностей в ER-диаграмме.
M1 —Для сильных сущностей: необходимо создать новую таблицу (отношение) для каждой сильной сущности и выбрать потенциальный ключ сильной сущности в качестве первичного ключа таблицы. Если в ER диаграмме указано более одного потенциального ключа, следует выбрать один из них первичным.
Затем, мы должны преобразовать атрибуты в сильной сущности. Правила преобразования разные для атомарных атрибутов, составных атрибутов и многозначных атрибутов. Сначала, мы определим правила преобразования для атомарных атрибутов:
M1a — Преобразование атомарных атрибутов сущности — для сущностей с атомарными атрибутами: преобразовать сущности в таблицы, формируя столбцы из атомарных атрибутов сущности.
А как насчет смешанных и многозначных атрибутов? Как было упомянуто выше, аксиома реляционных баз данных состоит в том, что все столбцы должны быть атомарными. Если в диаграмме имеется неатомарный атрибут, то необходимо сделать его атомарным для преобразования в реляционную базу данных. Для составных атрибутов, можно достичь атомарности, записывая по отдельности составные части (компоненты) атрибута.
Следующее правило преобразования касается составных атрибутов:
M1b – Для сущностей с составными атрибутами: преобразовать сущности в таблицы, формируя столбцы из элементарных (атомарных) частей составных атрибутов.
Правило преобразования для многозначных атрибутов гласит:
M1c - для многозначных атрибутов: сформировать отдельную таблицу для многозначных атрибутов. Включить первичный ключ из первоначальной таблицы. Ключом новой таблицы будет совокупность многозначного атрибута и первичного ключа родительской сущности. После этого удалить многозначный атрибут из первоначальной таблицы.
Шаг 2: Преобразование слабых сущностей в ER-диаграмме.
M4 — Для слабых сущностей — Создать новую таблицу (отношение) для каждой слабой сущности. Как и в случае с сильной сущностью, включить в таблицу все атрибуты слабой сущности, используя правила М1а, М1b и M1с. Для того, чтобы связать слабую сущность с родительской, включить первичный ключ родительской сущности в слабое отношение в качестве внешнего ключа. Первичным ключом для слабого отношения будет совокупность частичного ключа слабой сущности и ключа родительской сущности.
Если слабые сущности являются родительскими для других слабых сущностей, то сначала должна преобразовываться слабая сущность, которая связана с сильной сущностью. Ключ слабой родительской сущности должен быть определен до того, как будет преобразована «более слабая» сущность.
Шаг 3: Преобразование двоичных связей типа M:N
M3a - Для двоичных M:N связей: Для каждой связи типа M:N создать новую таблицу (отношение) с первичными ключами каждой из двух сущностей (родительских сущностей), которые участвуют в связи M:N. Ключом для новой таблицы будет являться совокупность ключей родительских сущностей. Включить в новую таблицу все атрибуты, которые могут участвовать в связи M:N.
Шаг 4: Преобразование двоичных связей типа 1:1 — Метод первичного/внешнего ключа.
Есть два пути преобразовать любую связь. Можно создать новую таблицу, применив правило M3a, или, для связей не-M:N, связь может быть преобразована с помощью первичного/внешнего ключа (ПК/ВК). Техника использования ключей ПК/ВК:
M3b - Для двоичных связей 1:1: Включить первичный ключ сущности А в сущность B в качестве внешнего ключа.
Для ответа на вопрос, какая сущность является сущностью А, а какая В, существуют следующие три правила преобразования: M3b_1, M3b_2, и M3b_3.
M3b_1 – Для двоичной связи 1:1, если одна из сторон имеет полное участие в связи, а другая – частичное участие, следует сохранить первичный ключ сущности с частичным участием в сущности с полным участием. После этого перенести все атрибуты связи на ту сторону, которая получила первичный ключ (первичный ключ теперь становится внешним в новом отношении). Заметим, что это правило не приводит к появлению null-значений для внешнего ключа.
M3b_2 - Для двоичных связей 1:1, если обе стороны имеют частичное участие в связи, существуют три альтернативных способа создать реляционную базу данных:
M3b_2a - Первая альтернатива – Можно выбрать одно из двух отношений для записи ключа другого отношения (для получения внешнего ключа – Прим. ред.), чтобы хранить ключ другого (даже если некоторые значения ключа станут нулевыми).
M3b_2b - Вторая альтернатива – в зависимости от семантики ситуации, можно создать новое отношение для размещения связи, которое содержало бы ключи двух связанных сущностей (как сделано в M3a).
M3b_2c – Третья альтернатива – создать новую таблицу и включить в нее только ключи из двух соответствующих таблиц. В таком случае можно преобразовать отношение как это делалось для двоичной связи M:N. Даже если бы имелись некоторые null-значения, они были бы удалены в результате объединения двух таблиц.
M3b_3 - Для двоичной связи 1:1, если обе стороны имеют полное участие в связи. Следует использовать семантику связи, чтобы определить, какое из отношений будет содержать в себе ключ другого. Было бы неверно включить внешние ключи в обе таблицы, поскольку создалась бы избыточность в базе данных. После этого переносим все атрибуты связи в таблицу, которая получила внешний ключ. Хотя в данной ситуации может быть лучшим решением стало бы создание новой таблицы в соответствием с правилом М3а.
Шаг 5: Преобразование двоичной связи типа 1:N.
M3c – Хотя большинство двоичных связей типа 1:N преобразуются с помощью метода ПК/ВК, должна использоваться отдельная таблица согласно правилу М3а. Для применения метода ПК/ВК для двоичной связи 1:N мы должны проверить, какой вид ограничений участия (полное/частичное – Прим. ред.) накладывается на связь со стороны N.
M3c_1 - Для двочиной связи 1:N, если N-сторона принимает полное участие в связи, включите ключ сущности со стороны 1 в отношение со стороны N в качестве внешнего ключа. Если сущность со стороны N является слабой и не имеет первичного ключа, необходимо включить ключ со стороны 1 в таблицу со стороны N и объединить его с частичным ключом слабой сущности. Ключом такой таблицы будет являться совокупность частичного и внешнего ключей. Далее следует включить все атрибуты, участвующие в связи, в таблицу, получившую внешний ключ.
M3c_2 - Для двоичной связи 1:N, если N-сторона принимает частичное участие в связи, то такая связь 1:N может быть преобразована подобно двоичной связи N:M с созданием отдельной таблицы для связи во избежание null-значений. Ключ нового отношения является совокупностью ключей связанных сущностей. Необходимо включить в эту таблицу все атрибуты, участвующие в связи.
Частичное участие является проблемой, так как оно приводит к нулевым значениям. Если мы переносим ключ со стороны 1 на сторону Nпри частичном участии (то есть не каждый кортеж со стороныNбудет связан со стороной 1), в базе данных могут возникнуть нулевые значения. Следовательно, лучше создать отдельную таблицу для связи 1:Nво избежание нулей.
Наконец, рассматривая связь 1:N, вернемся крисунку 6.2, где связьM:Nбыла преобразована в две связи 1:N. Заметим, что результатом такого преобразования будет набор таблиц, полученных при преобразовании связей 1:N.
Шаг 6: Преобразование рекурсивных связей.
M5 – Для рекурсивных сущностей могут применяться два типа правил преобразования:
M5a – Для рекурсивной связи 1:N первичный ключ таблицы повторно включается в эту же таблицу, но под другим названием.
M5b - Для рекурсивной связи М:N, создается отдельная таблица связи (как и в правиле M3a).
Шаг 7: Преобразование n-ых связей (выше второго порядка)
M6 – Для n-ых связей – Для каждой n-ой связи, создается новое отношение (таблица). В это отношение включаются все атрибуты связи. Затем включаются все ключи связанных сущностей в качестве внешних ключей. Первичным ключом нового отношения становится совокупность внешних ключей.
Шаг 8: Преобразование обобщений/специализаций.
Это наиболее часто встречается ситуация, когда имеется сущность с вариантами – атрибутами, которые применяются для некоторых случаев, но не для всех. Понятие наследования употребляется тогда, когда предполагается, что каждый образованный подкласс наследует свойстванадклассаили "родителя".
M7 — Для каждой сущности в связи обобщение/специализация создать одна таблицу для сущности-обобщения (если это еще не сделано в предыдущих шагах) и по одной таблице для каждой сущности-специализации. Добавить атрибуты для каждой сущности в соответствующие таблицы. Добавляется ключ сущности-обобщения в сущность-специализацию. Первичным ключом специализации будет являться первичный ключ обобщения.
Контрольные вопросы 9.1
1. Какое первое правило преобразования?
2. Как бы вы преобразовали слабую сущность слабой сущности?
3. Почему при преобразовании двоичной связи 1:N, с полным участие со стороныNмы включаем ключ отношения со стороны 1 в отношение со стороныN? Что было бы не правильно, если бы мы включали ключ отношения со стороныNв отношения со стороны 1?
4. Почему разумно преобразовывать двоичную связь 1:N, с частичным участием со стороныN, как связьM:N?
Если следовать вышеописанным правилам, полученная база данных будет находится в 3НФ или близки к ней. Следующая стадия преобразования – «проверка вашей работы» - подразумевает пересмотр всех таблиц чтобы гарантировать их нахождение в 3НФ (обращаясь к Главе1). Проверка 3НФ состоит из следующих шагов:
1. 1НФ — Проверка всех таблиц на наличие неатомарных атрибутов. Неатомарные атрибуты были рассмотрены в шагахM1bдля сложных атрибутов иM1cдля многозначных атрибутов.
2. 2НФ — Проверить зависимость всех атрибутов таблицы от первичного ключа. Ответьте на вопрос: «Буду ли я всегда иметь одно и тоже значение атрибутаY, когда атрибут X является первичным ключом?»
3. 3НФ — Выяснить, имеются ли ситуации, когда атрибут находится в таблице, но лучше определяется другим атрибутом, который не является первичным ключом. Вспомните, что еслиXявляется первичным ключом таблицы иX→YZW, то еслиZ→Wлучше чемX→W, вы вероятно имеете операционную зависимость, и необходимо сделать нормализацию.
Обратное проектирование
Разработав методологию проектирования ER-диаграмм и преобразования их в реляционную базу данных, рассмотрим теперь обратный процесс, когда исходными данными является база данных, и необходимо представить ее в видеER-диаграмм. На практике часто встречаются ситуации, когда имеется база данных, но отсутствуетER-диаграмма, показывающая, как она была разработана. Существует несколько причин, в которых обратное проектирование диаграмм (RED) является необходимым.
Во-первых, REDобеспечивает нас грамматическим и схематическим описанием базы данных. Люди часто используют базы данных не понимая их. С помощью обратного проектирования от данных и таблиц к диаграмме, мы можем проще описать назначение базы данных. ИмеяER-диаграмму для реляционной базы данных и грамматическое описание диаграммы, мы можем расширять базу данных при этом сохраняя смысл.
Хотя выражение "обратное проектирование" могло бы подразумевать, что мы выполняем шаги преобразования начиная с конца, проще будет повторять их с начала, чтобы выяснить, какая диаграмма использовалась для создания реляционной базы данных. Однако использование данных шагов предполагает, что выполняется следующее ограничение: база данных находится в 3НФ. Если это не так, обратное проектирование может помочь обнаружении причины возникновения избыточности в базе данных и следовательно предложить некоторые изменения. Мы предлагаем следующие правила:
Правило R1: Построение сильных сущностей
Для таблиц с одним ключевым атрибутом, изображается сильная сущность Rдля данной таблицы и все ее атрибуты наER-диаграмме.
Например, пусть имеется таблица R(a,b,c,d,e), иaявляется ключом. Создадим сильную сущностьRи покажемa,b,c,d, иeкак атрибуты с ключомa. Смотритерисунок 9.1.
Рисунок 9.1. Обратное преобразование сильных сущностей.
Правило R2: Выявление связей 1:1 и 1:N (1:x)
После того как будут выявлены вторая, третья… сильные сущности, отметьте внешние ключи в найденных ранее таблицах, а затем исключите их из этих таблиц и создайте связь между двумя сущностями. Такая ситуация будет указывать на отношение 1:x.
Предположим, что помимо R, имеется еще одна таблицаS(d,f,g).dявляется ключомSи оно находится вR, следовательно,dявляется внешним ключомR. ИсключивdизR(рисунок 9.2), получаем:
R(a,b,c,e)
S(d,f,g)
Рисунок 9.2. Обратное проектирование для связи 1:N.
Во всех случаях связи мы можем определить коэффициент связи и ограничения участи (полное/частичное) исходя из семантики базы данных. Иногда способ формирования таблиц может указать нам на ключ. Примеры данных также могут помочь при разъяснении. Например, в рассмотренных выше таблицах наиболее вероятной была связь N:1, потому что сущность со стороныNсодержалаdв качестве внешнего ключа. Также следует проверить данные на наличие нулевых значений, которые укажут нам на частичное участие некоторой сущности в связи.
Правило R2a: Проверка атрибутов на наличие связи 1:x
Если внешний ключ был исключен из отношения R, так как он является ключомS, то следует проверить имеются ли еще какие-нибудь атрибутыR, которые должны либо остаться в отношенииRлибо их следует перенести в связьRSлибо вообще в отношениеS. Так как шаг 2 является обратным преобразованием связи 1:x, вполне возможно, что атрибут из связи 1:xбыл перенесён вместе с внешним ключом, когда была построена исходнаяERдиаграмма, или же этот атрибут остался в связи.
Необходимо установить, чему может наиболее вероятно принадлежать оставшийся атрибут. Если есть вероятность, атрибут идентифицировался ключом сущности, поместите его в сущность, содержащую ключ. Если для идентификации атрибута требуются оба ключа, атрибут точно следует поместить в связь RS.
Например, как было рассмотрено выше, мы удалили dизR, потому чтоdявляется ключомS. Допустим, чтоeлучше идентифицируетсяd(ключомS), чемa(ключомR). Если это так, тоeследует переместить вSи удалить изR. В результате получим:
R(a,b,c)
S(d,f,g,e)
Пример R2a2: В рассмотренном выше примере, мы удалилиdизR, потому чтоdявляется ключомS. Предположим, что после того, как мы создалиS, мы определили, чтоeимеет смысл только он определяется иa, иd, ключамиRиS. Это означало бы, чтоeявляется пересекающим атрибутом в связи между R и S, и, следовательно, будет изображен следующим образом (см. рисунок 9.3).
R (a,b,c)
S (d,f,g,e)
RS (a,d,e).
Рисунок 9.3. ER диаграмма, изображающая связь между R и S.
На этом закончим обратное проектирование для сильных связей и перейдем к рассмотрению слабых связей и многозначных атрибутов.
Правило R3: Нахождение слабых сущностей или многозначных
атрибутов.
Исследуем связи на наличие связанных ключей, чтобы определить, содержат ли они какие-либо ключи сильных сущностей. Если да, то можно определить слабую сущность (правило R3a), многозначный атрибут (правилоR3b) или таблицу указывающую на связьM:N. Какой из них будет зависеть от не ключевого атрибута. Что же это будет на самом деле, будет зависеть от неключевых атрибутов.
Правило R3a: Слабые сущности
Если существует таблица, в которой есть атрибуты помимо ключевого (который является совокупностью внешнего ключа сильной сущностиичастичного ключа), тогда вероятно мы имеем дело со слабой сущностью. Например, если у нас есть таблица:
КВАЛИФИКАЦИЯ (номер служащего, тип работы, дата сертификации)
Здесь номер служащего является внешним ключом, а тип не является и, следовательно, может вероятно быть частичным ключом слабой сущности. Почему слабая сущность? Потому что имеется еще один атрибут, дата сертификации, и это означает что мы храним информацию о КВАЛИФИКАЦИИ. Расположим слабую сущность на ERдиаграмме рядом со связью с родительской сущностью. Связь скорее всего будет 1:N::сильная (родительская) сущность):слабая(дочерняя)сущность::частичное участие:полное участие. Исследуем атрибуты слабой сущности чтобы определить, появились ли они из слабой сущности либо из связи слабой сущности с родительской сущностью. Так, КВАЛИФИКАЦИЯ является слабой сущностью, тип работы – частичным ключом, а дата сертификации – атрибутом сущности КВАЛИФИКАЦИЯ (см.рисунок 9.4).
Рисунок 9.4. Обратное проектирование слабых сущностей.
Правило R3b: Многозначные атрибуты
Если в отношении больше нет атрибутов помимо ключевого, и часть ключа является внешним ключом сильной сущности, то вероятно это многозначный атрибут, который соединён с сильной сущностью посредством внешнего ключа. Поместим многозначный атрибут в сущности, которой он принадлежал изначально в качестве многозначного.
Например, если имеется отношение:
ПРЕПОДАВАТЕЛЬ (номер, степень)
Здесь у нас есть сцепленный ключ и больше никаких атрибутов. Поэтому номер вероятно является ключом другой сущности (например, СУБЪЕКТ), тогда степень должна быть многозначным атрибутом. Почему это не слабая сущность? Потому что, если это слабая сущность, то должно быть больше атрибутов — например, необходимо записать информацию о степенях, но в том случаем мы так не делаем. Рисунок 9.5 изображает обратное проектирование многозначного атрибута на рассмотренном выше примере.
Рисунок 9.5. Обратное проектирование многозначных атрибутов.
Правило R4: связи M:N и n-ые связи
Исследуйте отношения на наличие многократных появлений первичного ключа в производных сущностях. Запомните, что слабая сущность имеет сцеплённый ключ, поэтому связь M:Nвида Сильная сущность:Слабая Сущность предполагает наличие более двух атрибутов–частей составного ключа.
Правило R4a: Двоичная связь
Если в таблице имеются внешних ключа (и ничего больше), то вероятно эта таблица была преобразована из связи. Если два внешних ключа существуют с некоторыми атрибутами, то вероятнее всего существует связь M:Nмежду атрибутами отношения. Разместите связьM:Nмежду двумя сущностями с внешними ключами и добавьте другие атрибуты как атрибуты связи.
Например, если вы обнаружили отношение ПОКУПКА следующего вида (см. рисунок 9.6):
ПОКУПКА (номер продавца, номер серии, цена)
Рисунок 9.6. Обратное проектирование связи M:N.
Допустим, что номер продавца – ключ сущности ПРОДАВЕЦ, а номер серии – ключ сущности СЕРИЯ. Эти два внешних ключа явно сообщают о том, что таблица была сформирована из связи M:N(или возможно связи 1:N, или даже связи 1:1).
Связь M:Nявляется наиболее вероятной связью, которую можно определить из набора данных. Если, например, имеются многократные повторения серий для продавцов и наоборот, то это связьM:N. Если, для каждой серии существует список продавцов, но каждый продавец поставляет только одну серию, то связь ПРОДАВЕЦ:СЕРИЯ будетN:1.
Правило R4b: n-ые связи
Если в отношении в качестве ключа выступают более двух внешних ключей, то вероятно связь является n-ой связью. В отношении с двумя или более внешними ключами могут быть и другие атрибуты. Разместитеn-ую связь (n – число внешних ключей) междуn сущностями с внешними ключами и включите другие атрибуты как атрибуты связи.
Например, рассмотрим следующее отношение:
ПОКУПКА (номер продавца, номер серии, номер покупателя, цена)
Три внешних ключа предполагают троичную связь. Атрибут цена вероятно является пересекающим атрибутом отношения. В этом случае, мы могли бы говорить о необходимости идентификации цены всеми тремя ключами, как показано на рисунке9.7.
Рисунок 9.7. Обратное проектирование n-ых связей.
Контрольные вопросы 9.2
1. Какие признаки вы бы искали, чтобы определить, что связь является троичной?
2. Какие признаки вы бы искали, чтобы определить связи, в которых участвовали бы слабые сущности и многозначные атрибуты?
Итоги главы
В этой главе были объединены правила преобразования (правила, применяющиеся для преобразования ER-диаграммы в реляционную базу данных), которые рассматривались на протяжении всей книги, и обсудили и разработали набор правил обратного проектированияER-диаграмм из реляционной базы данных.
Упражнения Главы 9
Упражнение 9.1
С помощью метода обратного проектирования разработайте и нарисуйте ER-диаграмму для следующей реляционной базы данных:
Список литературы
Elmasri, R. and Navathe, S.B., Fundamentals of Database Systems, 3rd ed., Benjamin Cummings, Redwood City, CA, 2000.