
- •Сикха Багуи и Ричард Ирп
- •Контрольные вопросы 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. Упражнения.
С указанием всех атрибутов
Контрольные вопросы 6.1
1. Почему на Рисунке 6.6здание является сущностью, а не атрибутом другой сущности?
2. Почему атрибут номер комнаты участвует в связи «живет_в» по-другому, нежели сущность СУТДЕНТ?
3. Что влияет на решение: должен ли атрибут быть связан с сущностью А или сущностью B, или же он должен быть связан с обеими сущностями.
4. Почему все линии, соединяющие ЗДАНИЕ (на Рисунке 6.6) – являются одинарными (то есть обозначают частичное участие)?
5. В соответствии с Рисунком 6.6, должен ли студент посещать некоторый курс?
6. Согласно Рисунку 6.6, сколько курсов может читать преподаватель?
Развитие базы данных
Давайте пересмотрим ER-диаграмму на Рисунке 6.6. Проанализировав диаграмму, пользователь может спросить: "Почему атрибут номера аудитории не включен в связь «проводится_в»?" Почему в связи «офис» отсутствует номер офиса? Этому может быть несколько объяснений: (1) данные не было упомянуты на этапе анализа; (2) данные не являются необходимыми (то есть, может быть только одна аудитория в здании или номера офисов не записываются для преподавателей) или (3) произошла ошибка и данные должны быть добавлены. Теперь мы решаем, что номер комнаты важен для всех связей или сущностей. Предположим что номер комнаты идентифицируется, будучи зависимым от сущностей преподаватели и здание, курс и здание, и студент и здание. Теперь мы можем расширить диаграмму, как показано наРисунке 6.7.
Рисунок 6.7 ER-диаграмма для БД СТДЕНТ/КУРС/ПРЕПОДАВАТЕЛЬ/ЗДАНИЕ с атрибутом связи «номер комнаты»
В этом случае мы располагаем информацией, относящейся к ЗДАНИЮ: срок аренды, инспектор по эксплуатации и площадь. Номер комнаты является атрибутом, идентифицируемым обеими сущностями.
Атрибуты, которые преобразовываются в Сущности
В данном разделе еще раз подтверждается идея о том, что нужно моделировать «что есть», а не то, что «могло бы быть». Также мы снова посмотрим, каким образом атрибут может стать сущностью. Предположим, что в базе данных должна храниться следующая информация: название курса, номер курса, баллы, имя преподавателя, и учебник. Пример данных:
'Database', 'COP4710', 3, 'Earp', 'Elmasri/Navathe'
Начальная ER-диаграмма могла бы выглядеть так (см. рис. 6.8), "ER-диаграмма сущности КУРС в базе данных." Почему могла бы выглядеть…"? Ответ зависит от правильного толкования требований, предъявляемых пользователем.
Рисунок 6.8. ER-диаграмма сущности КУРС в базе данных
Если эта вся информация, которую необходимо хранить в базе данных, то эта ER-диаграмма с одной сущностей будет описывать базу данных. Тем не менее, можно достоверно доказать, что объекты, которые мы описали как атрибуты, могут быть отдельными сущностями. Как преподаватель, так и книга могли бы изображаться на отдельных диаграммах как сущности, если это было предусмотрено нашей базой данных.
Рассмотрим ситуацию, в которой было принято решение расширить или подкорректировать базу данных, чтобы включить информацию о преподавателях. В таком случае нам потребуется записывать следующие сведения о преподавателях: имя преподавателя и такие атрибуты как кафедра, дата приема на работу, учебное заведение, где преподаватель получил ученую степень. После внесения дополнительной информации о ПРЕПОДАВАТЕЛЯХ ER-диаграмма будет иметь две сущности и будет выглядеть следующим образом:
Рисунок 6.9. ER-диаграмма базы данных КУРС/ПРЕПОДАВАТЕЛЬ
На Рисунке 6.9сущность ПРЕПОДАВАТЕЛЬ изображена как слабая, в силу того, что имя преподавателя не является уникальным и существует зависимость ПРЕПОДАВАТЕЛЬ от сущности КУРС. из-за предполагаемой не-единственности имени преподавателя и зависимости от КУРСА. Если бы преподаватель однозначно идентифицировался некоторым атрибутом, например, номером социального страхования, и если преподаватели могли существовать независимо от курсов, тогда сущность ПРЕПОДАВАТЕЛЬ стала бы сильной сущностью и выглядела бы так, как изображено нарисунке 6.10. сильной и должна будет выглядеть как показано наРисунке 6.10. Основная идея данного раздела заключается в том, чтобы прояснить окончательно – сущность не является сущностью только потому, что кто-то «когда-нибудь» захочет записать о ней информацию. Необходимо заранее спланировать, какие данные будут идентифицироваться сущностью. Будет ли сущность сильной или слабой, зависит от дополнительной информации, полученной от пользователя.
Наконец, если больше не потребуется никакой другой информации о преподавателях, тогда первая ER-диаграмма (Рисунок 6.10) будет достаточно полно описывать базу данных. Оставим в качестве упражнения случай, когда необходимо расширить диаграмму и включить в нее сущность КНИГА.
Рисунок 6.10. ER-диаграмма базы данных КУРС/ПРЕПОДАВАТЕЛЬ
Рекурсивные Связи
Рекурсивная связь появляется в том случае, когда одна и та же сущность выступает неоднократно в разных ролях. Рекурсивная связь также иногда называется одиночнойсвязью.
Рассмотрим, например, отношение персонала в компании. Персонал вероятно должен иметь номер служащего, имя, и т.п. Помимо связи всех служащих организации с чем-либо в составе сущности ПЕРСОНАЛ, существуют связи между отдельными служащими. Наиболее очевидной является связь служащий-инспектор и инспектор-служащий. Как изобразить связь персонал-инспектор, если имеется только одна сущность? Ответ представлен на Рисунке 6.11.
На рисунке 6.11изображена сущность ПЕРСОНАЛ с некоторыми простыми атрибутами. Затем, добавляется связь «контролирует» и соединяется с сущностью ПЕРСОНАЛ с обеих сторон. Коэффициент связи равен 1:N, и это означает, что один служащий может контролировать многих других служащих, но сам может контролироваться только одним служащим. Мы используем частичное участие стороны инспектора, поскольку не все служащие могут являться инспекторами — служащийможетконтролировать других служащих. Участие контролируемого служащего также является частичным. Хотя большинство служащих контролируются кем-либо, одним инспектором, некоторые служащие будут находится на вершине иерархии и не будут контролироваться. Установив рекурсивную связь, мы получаем иерархию. Все иерархии имеют вершину, которая «не контролируется». В иерархии все сущности частично участвуют в связи.
Поэтому когда возникает связь между представителями одной сущности, было бы неверно создавать две сущности, поскольку они содержали бы одну и ту же информацию.
Так, когда возникает связь между персоналом в пределах того же объекта, происходит ошибка, поскольку два объекта содержат в основном похожую информацию. То есть если мы создадим две сущности, в базе данных возникнет избыточность. Если бы в предыдущем примере мы предпочли бы рекурсивной связи создание двух разных сущностей, то служащего пришлось бы записывать в обе сущности.
Рисунок 6.11.Классическая рекурсивная связь ПЕРСОНАЛ/ИНСПЕКТОР
Рекурсивная Связь и Структурные Ограничения
Рекурсивная связь может иметь только частичное участие в связи, но числовой коэффициент связи может быть один-к-одному, один-ко-многим, или многие-ко-многим. Полное участие в рекурсивной связи должно означать, что каждый объект сущности участвует в связи сам с собой, но это не имеет смысла. Рассмотрим некоторые примеры коэффициентов связи в применении к рекурсивной связи.
Рекурсивная связь один-к-одному (Частичное участие с обеих сторон)
Рисунок 6Aпоказывает пример сущности ПЕРСОНАЛ, представители которой связаны между собой отношением «состоит в браке с». Это означает, что человек, информация о котором хранится в базе данных, может состоять в браке с другим человеком из этой же базы данных.
Рисунок 6А. Рекурсивная связь один-к-одному (Частичное участие с обеих сторон)
Некоторые примеры этой связи показаны на Рисунке 6B. Из Рисунка 6B мы можем увидеть, что Seema состоит в браке с Dev Anand, Sumon состоит в браке с Rekha, и т.п..
Рисунок 6В. Представители рекурсивной связи один-к-одному (Частичное участие с обеих сторон)
Рекурсивная связь один-ко-многим (Частичное участие с обеих сторон)
Такая связь встречается наиболее часто. Примером такой связи может служить то, что один служащий может контролировать несколько других служащих (как изображено на Рисунке 6C). Как было рассмотрено ранее, такая связь является иерархической с частичным участием с обеих сторон.
Рисунок 6С. Рекурсивная связь один-ко-многим (Частичное участие с обеих сторон)
Примеры такой связи показаны на Рисунке 6D. ИзРисунка 6Dмы можем увидеть что Том Smith контролирует Sudip Bagui и Tim Vaney, Rishi Kapoor контролирует Mala Sinha и Korak Gupta, Korak Gupta контролирует Roop Mukerjee, и т.д.
Рисунок 6D. Представители Рекурсивная связь один-ко-многим (Частичное участие с обеих сторон)
Рекурсивная связь многие-ко-многим (Частичное участие с обеих сторон)
В данном примере можно предположить, что курсы могут предшествовать один другому. Такая связь изображена на рисунке 6E. Здесь зависимость между курсами не иерархическая, а определяется такой ситуацией, при которой множество курсов взаимосвязаны между собой.
Рисунок 6Е. Рекурсивная связь многие-ко-многим (Частичное участие с обеих сторон
Множественные связи
До сих пор мы по большей части обсуждали примеры, когда две сущности имеют (одну) связь. Эта часть главы обсуждает, как две сущности могут иметь более одной связи (но связь остается двоичной).
Рассмотрим диаграмму, которая изображает две сущности: СТУДЕНТ и ПРЕПОДАВАТЕЛЬ. Предположим, что в базе данных нет других сущностей. Сущность СТУДЕНТ имеет следующие атрибуты: имя, номер_студента, дата рождения, и название института, в котором он учится. Объект ПРЕПОДАВАТЕЛЬ может иметь следующие атрибуты: имя, номер социального страхования (SS#), контактный телефон, номер офиса. Теперь рассмотрим две связи: «обучает» и «консультирует». Имеем две сущности и две связи между ними. Каждой связи дают соответствует свой "ромб" на диаграмме. ER-диаграмма представлена наРисунке 6.12
Рисунок 6.12. ER-диаграмма с двумя сущностями и двумя связями.
В этой диаграмме, все связи показаны как частичные, поскольку найдутся преподаватели, которые не консультируют студентов, и некоторые студенты, которые не будут обучаться преподавателем.
В этом примере, для пояснения можно включить пересекающие данные для связи «обучает» (например, оценка за курс). Пересекающиеся данные для связи «консультирует» могли быть таковы: обсуждаемые_вопросы, дата_последней_встречи, и т.д., как показано наРисунке 6.12A.
Рисунок 6.12А ER-диаграмма с двумя сущностями, двумя связями и некоторыми
пересекающими атрибутами.
Установление связей в ER-диаграммах осуществляется на шаге 5 методологииER-проектирования. Первоначально он звучал так:
Шаг 5: Определить связи между сущностями, если таковые существуют.
Мы могли бы добавить: если присутствуют множественные связи, их следует изобразить на диаграмме, но во избежание избыточности, просто добавим фразу «одну или несколько»:
Шаг 5: Определить связи между сущностями (одну или несколько), если таковые существуют.
Производная или избыточная связь
Многие авторы описывают избыточную связь (Martin, 1983) или производную (Hawryszkiewycz, 1984) связь, которая могла бы образоваться в результате возникновения «петли», как изображено на Рисунке 6.13. Понятие петли возникает вследствие того, что линии связи на диаграмме образуют замкнутый граф (который, скорее, является прямоугольником, но назовем будем называть его петлей). Идея избыточности заключается в том, что поскольку студенты посещают курсы и каждый курс читается преподавателем, нам не требуется еще одна связь, поскольку мы можем получить эту информацию без дополнительной связи. Если такая связь существует, тогда она должна быть удалена.
Рисунок 6.13. ER-диаграмма БД СТУДЕНТ/КУРС/ПРЕПОДАВАТЕЛЬ с «избыточной» связью.
Во-первых, мы должны убедиться, что связь действительно является излишней. Если бы была предложена другая связь вместо связи «обучается_у», тогда нам следовало бы ее оставить, поскольку она имеет совершенно другое значение.
Во-вторых, если на диаграмме присутствует петля связи, это может означать, что должна остаться только одна из двух излишних связей, и семантика должна указать, какая именно. На Рисунке 6.13ИНСПЕКТОР больше связан с КУРСОМ, чем со СТУДЕНТОМ. Затем, изучая диаграмму на наличие циклов, можно сделать выводы, что ученный (taught by) был излишний. Поэтому правильным выбором, какую из связей следует сохранить, был бы первоначальный вариант «читает». Вполне вероятно, что разработчик мог сначала установить связь «обучается_у», а затем уже связь «читает». Затем, после изучения петли связи, он мог бы сделать вывод, что связь «обучается_у» является лишней.
В третьих, одна или обе связи могут иметь пересекающий атрибут, который должен указать, какую связь (или обе) следует сохранить. На Рисунке 6.14, мы добавили атрибут время в связь «читает», который указывает, что преподаватель читает курс в такое-то время.
Рисунок 6.14. ER-диаграмма БД СТУДЕНТ/КУРС/ПРЕПОДАВАТЕЛЬ с «избыточной» связью.
Понятие производной или излишней связи заставляет нас вновь обратиться к методологии и добавить еще один шаг:
Шаг 6b. Изучить диаграмму на наличие петель, указывающих на избыточные связи. Если связь действительно является избыточной, ее следит удалить.
Контрольные вопросы 6.2
1. Что такое рекурсивная связь?
2. Что указывает на то, что связь является рекурсивной?
3. Какие типы структурных ограничений может иметь рекурсивная связь?
4. Может ли рекурсивная связь полное участие? Почему?
5. Как рекурсивная связь обозначается на диаграмме в ER-модели?
6. Могут ли две сущности иметь более одной связи?
7. Как определить, что связь является избыточной?
Дополнительная часть
Назовем следующий разделглавы"Альтернативная ER-модель для определения структурных ограничений на связи". Он является дополнительным, поскольку нет острой необходимости знать данный раздел для понимания методологииER-проектирования и достижения хороших результатов при разработке баз данных. Тем не менее, кто-то сочтет данный раздел более описательным.
Альтернативная ER модель для определения
структурных ограничений на связи
К настоящему моменту мы обсудили числовой коэффициент связи в терминах верхних границ (максимального количества элементов), обозначаемый как "M" или "N" на ER-диаграммах (представленных в этой и предыдущих главах). Вспомним (из Главы 4), что коэффициент связи является грубой мерой количества объектов некоторой сущности, которые могут быть связаны объектами другой сущности.
В данном разделе описывается альтернативная ER модель для определения структурных ограничений на связи. Эта модель ассоциирует пару чисел (min, max) с каждой сущностью, участвующей в связи. Значения min и max могут предоставить больше информации о сущностях и связях.
Min – минимальное число объектов сущности, которые могут быть связаны с объектом связи.Min может находиться в интервале от нуля до максимума. Значение min, равное 0 означает, что не каждый объект сущности должен быть связан с объектом связи. По сути, это означает частичное участие. Если min больше 0, это подразумевает полное участие. Рассмотрим ER-диаграмму связей с коэффициентами (min, max).
Сперва начнем с рекурсивной связи, изображенной на Рисунке 6.15. Коэффициенты (min, max) имеющие значение (0,1) показывают, что каждый сотрудник может состоять в браке или не состоять (определяется нулевым значением для min), и может состоять в браке только с одним сотрудником (определяется значением 1 для max). Теперь посмотрим на Рисунок 6.16. Судя по нему, мы можем сказать, что студент может не консультироваться ни одним преподавателем и может консультироваться максимум двумя преподавателями (определяется нулевым значением для min и значением 2 для max, то есть (0,2) ). Преподаватель может консультировать от нуля до 30 студентов и обучать от нуля до 40 студентов.
По этому рисунку мы можем сказать, что студент не может знать каждого на факультете, а может знать до двух сотрудников факультета (показано нулем в минимуме, и двумя значениями в максимуме [то есть, (0,2)]). Сотрудник факультета может информировать только от ноля (0) до 30 студентов и обучать от ноля (0) до 40 студентов. Студента должен обучать один преподаватель, но могут обучать и двое (то есть (0,2)).
Рис. 6.15. Рекурсивная связь с (min и max)
Рис. 6.16. ER-диаграмма альтернативной ER модели
Контрольные вопросы 6.3
1. Какова нижняя граница числового коэффициента связи подразумевает полное участие?
2.Что означает коэффициент связи равных (1,1) между двумя сущностями?
3. Какой вид участия (полное или частичное) определяет значение коэффициента, равное (0,1)?
Обзор методологии
Посмотрим, как развилась методология для проектирования ER диаграмм:
Методология ER-проектирования
Шаг 1: Выбрать из описания требований к базе данных одну первичную сущность и указать атрибуты, которые будут принадлежать данной сущности. При возможности выделить ключ и привести пример данных.
Шаг 2: Для описания базы данных использовать структурный английский язык для сущностей, атрибутов и ключей.
Шаг 3: Исследовать атрибуты в существующих сущностях (возможно с помощью пользователя), чтобы выявить нужно ли записывать информацию о каких-либо атрибутах. (Примечание: Мы заменили слово "первичная" на "существующие", поскольку мы повторяем шаг 3, добавляя новые сущности.)
Шаг 3a: Если необходима информация об атрибуте, сделать атрибут сущностью и затем
Шаг 3b: Определить ее связь с родительской сущностью.
Шаг 4: Если можно выделить еще одну сущность, изобразить диаграмму для этой сущности и ее атрибутов. Повторить шаги 2 и 3, чтобы выяснить, возможно ли дальнейшее выделение сущностей.
Шаг 5: Определить связи между сущностями (одну или несколько), если таковые существуют
Шаг 6: Определить на структурированном английском языке точный характер связей с обеих сторон. Например, связь A:B::1:M означает связь A с B вида один-ко-многим с одной стороны и связь B с A вида многие-к-одному с другой стороны.
Шаг 6a: Изучить список атрибутов и определить, есть ли среди них такие, которые идентифицируются двумя (или более) сущностями. Если таковые имеются, прикрепить их к соответствующей связи, соединяющей сущности.
Шаг 6b. Изучить диаграмму на наличие петель, указывающих на избыточные связи. Если связь действительно является избыточной, ее следует удалить.
Шаг 7: Представить «разработанную» базу данных пользователю, дополнив ее английским описанием всех сущностей, ключей, атрибутов и связей. Пересмотреть диаграмму в случае необходимости.
Шаг 8: Привести пример данных.
Грамматика для описания сущностей, атрибутов и ключей:
Сущность: Эта база данных содержит информацию о СУЩНОСТИ. Для каждой СУЩНОСТИ в базе данных, мы записываем атрибуты att(1), att(2), att(3), att(n).
Атрибуты:
Для атомарных атрибутов, att(j):
Каждой СУЩНОСТИ всегда будет соответствовать один и только один att(j). Величина att(j) является неделимой.
Для составных атрибутов, att(j):
Для каждой СУЩНОСТИ будем записывать att(j), который состоит из x, y, z, …
(x, y, z), - составные части att(j).
Для многозначных атрибутов, att(j):
Для каждой СУЩНОСТИ, будем записывать att(j). Для каждой СУЩНОСТИ можно записать несколько att(j).
Для атрибутов связей att(j):
Для связи между СУЩНОСТЬЮ1 и СУЩНОСТЬЮ2 будем записывать атрибут a(n) att(j). att(j) для идентификации зависит от обеих сущностей – СУЩНОСТИ1 и СУЩНОСТИ2.
Ключи:
Более одного потенциального ключа (сильная сущность):
Для каждой СУЩНОСТИ будем иметь следующие потенциальные ключи: att(j), att(k), (где j, k – потенциальные ключевые атрибуты).
Один потенциальный ключ (сильная сущность):
Для каждой СУЩНОСТИ, будем иметь следующий первичный ключ: att(j)
Отсутствие ключей (возможно слабая сущность):
Предполагаем, что для каждой СУЩНОСТИ не существует уникального атрибута, достаточного для ее идентификации.
Отсутствие ключей (возможно пересекающая сущность):
Предполагаем, что для каждой СУЩНОСТИ не существует уникального атрибута, достаточного для ее идентификации.
Правила преобразования для рекурсивных связей
Рекурсивные связи могут быть двоичными связями типа 1:1, 1:N, или M:N. Мы обсудили правила преобразования таких типов связей в Главе 4. В этой главе, были рассмотрены правили преобразования для двух сущностей. Если имеется только одна сущность, правила в основном остаются такими же стой лишь разницей, что первичный ключ одной сущности (СУЩНОСТЬ_A) включается не в другую сущность (СУЩНОСТЬ_В), а повторно включается в СУЩНОСТЬ_A.
M5 – Для рекурсивных сущностей могут применяться два типа правил преобразования:
M5a – Для рекурсивной связи 1:N первичный ключ таблицы повторно включается в эту же таблицу, но под другим названием.
Рисунок 6.11 иллюстрирует данную ситуацию.
M5b - Для рекурсивной связи М:N, создается отдельная таблица связи (как и в правиле M3a).
Так, например, предположим, что на Рисунке 6.11 представленоотношениеM:N, тогда он будет преобразован в следующую таблицу:
Контрольные вопросы 6.4
1. Преобразуйте рекурсивную связь, показанную наРис. 6C, в реляционную базу данных и приведите пример данных.
2. Если бы на Рис. 6C была изображена связь M:N, как бы вы преобразовали такую рекурсивную связь в реляционную реляционной базы данных? Преобразуйте и приведите пример данных.
Итоги главы
В данной главе были рассмотрены различные виды двоичной связи в ER-диаграммах и добавлены некоторые шаги в методологию ER-проектирования. Улучшение и расширение методологииER-проектирования означает непрерывную переоценкуER-диаграммы, которая составляется после обсуждения с пользователями. Были рассмотрены и проиллюстрированы случаи, в которых связи могут иметь атрибуты, когда атрибуты становятся сущностями, рекурсивные и избыточные связи. Была пересмотрена и скорректирована методологияER-проектирования, чтобы учесть все вышеназванные случаи. В конце главы была приведена альтернативная ER модель для определения структурных ограничений на связи.
После завершения этой главы, читатель или разработчик базы данных должен быть способен эффективно проектировать базу данных с двоичными связями. Глава 7рассматривает троичные связи и связи более высокого порядка.
Упражнения Главы 6
В каждом упражнении под выражение "изобразите ER диаграмму " подразумевается не только сама диаграмма, но также структурное грамматическое описание диаграммы.
Упражнение 6.1
Определите и укажите точные значения числового коэффициента связи и характер участия на Рисунке 6.5 базы данных СТУДЕНТ/КУРС/ПРЕПОДАВАТЕЛЬ/ЗДАНИЕ. Обсудите структурные ограничения Рисунка 6.5. При каких условиях структурные ограничения будут изображены правильно или неправильно?
Упражнение 6.2
Рассмотрите следующие данные, и изобразите ER диаграмму, применяя структурную грамматику для разъяснения накладываемых ограничений. Исходные данные: имя лошади, гонка, владелец, позиция на старте, позиция на финише, дата гонки, имя владельца и его адрес.
Упражнение 6.3
В этой главе мы описали базу данных, которая имеет две сущности: КУРС и ПРЕПОДАВАТЕЛЬ (Рисунок 6.10). Книга была атрибутом сущности КУРС. Расширьте базу данных, представив КНИГУ как сущность. Атрибутами КНИГИ могут быть: название книги, автор, цена, издание, издатель.
Упражнение 6.4
Измените Рисунок 6.7, чтобы включить следующую информацию: одно здание может вмещать максимум 99 студентов, живущих в нем. При этом студент должен быть записан, по крайней мере, на один курс и максимум на пять курсов. Аудитория может вмещать от 5 до 35 студентов. Преподаватель может не вести занятия в аудитории, или вести максимум в трех аудиториях. Курс должен иметь одного преподавателя, и только один преподаватель может вести конкретный курс. Преподаватель может иметь максимум два офиса или не иметь ни одного. В здании могут находится офисы, максимум 15 офисов, или не быть ни одного. Курс должен читаться в одной аудитории.
Список литературы
Bracchi, G., Paolini, P., and Pelagatti, G., "Binary Logical Associations in Data Modelling," Modelling in Data Base Management Systems, G.M. Nijssen, Ed., North-Holland, Amsterdam, 1976.
Earp, R. and Bagui, S., "Binary Relationships in Entity Relationships in Entity Relationship (ER) Diagrams," Data Base Management, Auerbach Publications, Boca Raton, FL, 22-10-43, 1–17, April 2000.
Hawryszkiewycz, I., Database Analysis and Design, SRA, Chicago, 1984.
Mark, L., "Defining Views in the Binary Relationship Model," Information System, 12, 3 (1987), p. 281–294.
Martin, J., Managing the Data-Base Environment, Prentice Hall, Englewood Cliffs, NJ, 1983.
Sanders, L., Data Modeling, Boyd & Fraser Publishing, Danvers, MA, 1995.
Teorey, T.J., Database Modeling and Design, Morgan Kaufman, San Francisco, 1999.
Учебный пример: Западно-Флоридский торговый комплекс (продолжение)
К настоящему времени в нашем учебном примере мы рассмотрели главные сущности и связи и отобразили их в реляционной базе данных (с некоторыми примерными данными). Мы остановились на седьмом шаге, который гласит:
Шаг 7: Представить «разработанную» базу данных пользователю, дополнив ее английским описанием всех сущностей, ключей, атрибутов и связей. Пересмотреть диаграмму в случае необходимости.
Предположим, что мы получили пользователя некоторые дополнительные данные:
Служащий может также быть менеджером отдела, и менеджер отдела может управлять только одним отделом. Нам необходимо хранить информацию о менеджере отдела: имя, номер социального страхования, магазин, в котором он/она работает, отдел, в котором он/она работает. Менеджер отдела контролирует, по крайней мере, одного служащего, и может управлять несколькими служащими.
После рассмотрения этих дополнительных требований, мы можем обнаружить рекурсивную связь, поскольку служащий может быть менеджером отдела, контролирующим других служащих.
Поэтому, применяя правило преобразования M5a, мы повторно включаем первичный ключ сущности СЛУЖАЩИЙ в эту же сущность, что дает нам следующее отношение СЛУЖАЩИЙ:
Эта рекурсивная связь также изображена на Рисунке 6.17.
Рисунок 6.17. ER диаграмма БД Западно-Флоридского Торгового Комплекса на данной стадии
В итоге, наша реляционная база данных выглядит следующим образом (без данных):
Мы продолжим рассмотрение этого примера в конце Главы 8.