Сущность
База данных содержит информацию о комбинациях СТУДЕНТ-КУРС. Для каждой сущности СТУДЕНТ+КУРС будем записывать оценку.
Атрибуты
Каждой комбинации СТУДЕНТ-КУРС всегда будет соответствовать одна и только одна оценка. Значение оценки будет неделимо.
Ключи
(d) Потенциальные ключи отсутствуют (пересекающая сущность):
Сущность СТУДЕНТ+КУРС не имеет собственного потенциального ключа, но каждая сущность СТУДЕНТ+КУРС будет идентифицироваться ключами, принадлежащими сущностям СТУДЕНТ и КУРС.
Последнее утверждение очень похоже (а для пользователя эта разница вообще незаметна) на определение ключа в приведенной выше грамматике для атрибутов связи.
Для связи между СТУДЕНТОМ и КУРСОМ мы вводим атрибут оценка. Оценка идентифицируется обеими сущностями – и СТУДЕНТОМ, и КУРСОМ.
Больше Сущностей и Связей
Разрабатывая базу данных, мы должны создать модель представления информации. И вполне вероятны ситуации, когда необходимо будет работать более чем с двумя сущностями и одной двоичной связью. Двоичная связь есть связью между двумя сущностями. (Глава 7рассматривает троичные и связи более высокого порядка). В данном разделе рассмотрим ситуации, когда полученная о базе данных информация указывает на то, что следует должны расширить наши диаграммы, добавив новые сущности, но все связи будут двоичными.
Более двух Сущностей
Вернемся к диаграмме СТУДЕНТ-КУРС, изображенной на рисунке 6.1Если эта база данных ориентирована на колледж, то курсы должны иметь преподавателей и преподаватели должны быть связаны с курсами. Предположим, что следует добавить сущность ПРЕПОДАВАТЕЛЬ к нашей базе данных, следуя шагам 4, 5 методологии:
Шаг 4: Если можно выделить еще одну сущность, изобразить диаграмму для этой сущности и ее атрибутов. Повторить шаг 2 чтобы выяснить, возможно ли дальнейшее выделение сущностей.
Шаг 5: Определить связи между сущностями, если таковые существуют.
Рис. 6.3. ER-диаграмма (только с первичными ключами) для БД СТДЕНТ/КУРС/ПРЕПОДАВАТЕЛЬ
При добавлении преподавателей к ER-диаграммерисунок 6.1преобразуется врисунок 6.3. Неключевые атрибуты намеренно не показаны, чтобы не усложнять диаграмму. Назовем связь между ПРЕПОДАВАТЕЛЕМ и КУРСОМ «читать» - ПРЕПОДАВАТЕЛЬ читает несколько курсов, и курс читается одним преподавателем. Участие в связи будет определяться ситуацией, здесь мы выберем какой-нибудь из шаблонов.
Более точно ситуация описывается так:
Шаблон 4 — x:y::1:M, частичное участие со стороны 1
В короткой форме: преподаватель может читать лекции по многим курсах:
В полной форме: преподаватель, но не обязательно все преподаватели (которые записаны в базе данных), может читать лекции по многим (одному и более) курсам. Некоторые преподаватели могут не читать ни одного курса.
Шаблон 1 — x:y::M:1, полное участие со стороны М
В короткой форме: Курсы должны читаться преподавателями:
В полной форме: Курсы, записанные в базе данных, должны читаться одним и только одним преподавателем. Никакой курс не читается более, чем одним преподавателем.
В диаграмме на рисунке 6.3. сущность ПРЕПОДАВАТЕЛЬ связана с сущностью КУРС. Тут могла бы иметь место связь между сущностями СТУДЕНТ и ПРЕПОДАВАТЕЛЬ, но связи нарисунке 6.3отображают только то, что существует в действительности. Можно утверждать, что существуют и другие связи – консультант, наставник, советник, тренер,…, но следует помнить, что мы моделируем только то, что существует, а не что могло бы быть. Предполагается, что диаграмма отображает только данную (известную) информацию.
Добавление нескольких атрибутов, которые
преобразуются в сущности
Как видно, ER-диаграммы развиваются в процессе проектирования БД. Одним из способов расширения ER-диаграммы может быть добавление атрибутов в различным сущностям. Некоторые атрибуты могут быть простыми, функционально зависимыми дополнениями. Функциональная зависимость означает, что нечто идентифицируется чем-то, от чего зависит. Например, номер социального страхования функционально идентифицирует имя, и имя функционально зависит от номера социального страхования. Эта функциональная зависимость означает, что в любом месте базы данных для номера социального страхования существует соответствующее имя. Предположим, что требуется добавить атрибут имя преподавателя. Дополнение расширяет диаграмму, и имя преподавателя функционально зависит от атрибута номер_преподавателя.
Теперь добавим "здание" к каждой сущности. Студенты живут в "здании" (общежитие), курсы читаются в "здании" (аудитории и лаборатории), преподаватели имеют офисы в "здании". "Здание" может быть добавлено в качестве атрибута к каждой из трех сущностей и не будет считаться самостоятельной сущностью. Почему? Поскольку на этом этапе, мы не выразили желание, записать информацию о "здании". Если здания (общежитие, аудитории, офисные комнаты) рассматривались как атрибуты соответствующих сущностей, то ER-диаграмма выглядела бы следующим образом (рисунок 6.4)
Рис. 6.4.ER-диаграмма (только с первичными ключами) для БД СТДЕНТ/КУРС/ПРЕПОДАВАТЕЛЬ с добавлением атрибута здание
Теперь, когда мы добавили "здание" в нашу базу данных (Рисунок 6.4), решаем что мы хотим сделать, то есть хотим ли мы записывать больше информации о зданиях, или другими словами, хотим ли мы сделать ЗДАНИЕ сущностью. После этого необходимо установить связи ЗДАНИЕ с соответствующими сущностями. Соответствующая диаграмма изображена на рисунке 6.5. Выделяя новые сущности, мы должны все время задаваться вопросом: «Является ли некоторый объект на ER-диаграмме тем, о чем мы хотим хранить информацию? Должен ли он быть самостоятельной сущностью?» Добавим атрибуты к сущности ЗДАНИЕ. Затем изобразим расширенную ER-диаграмму с указанием всех атрибутов и коэффициентов связи (рисунок 6.5)
Рисунок 6.5 ER-диаграмма (только с первичными ключами) для БД СТДЕНТ/КУРС/ПРЕПОДАВАТЕЛЬ/ЗДАНИЕ
Рисунок 6.6 ER-диаграмма для БД СТДЕНТ/КУРС/ПРЕПОДАВАТЕЛЬ/ЗДАНИЕ