Базы данных. Краморенко Н.В. - 39 стр.

4. Отделы,           не       имеющие        по       штату         должность          “Мастер”
   R3 \ R3[Должность = “Мастер”]
5. ФИО           сотрудников,        занимающих         больше         одной          должности
   (R1[R1.ФИО = R1’.ФИО ∧ R1.Должность ≠ R1’.Должность]R1’)[ФИО]
       Обратите внимание, что для поиска строк, удовлетворяющих условию больше одного,
применяется операция соединения отношения с самим собой. Поэтому мы взяли копию отношения
R1 и назвали ее R1’.
6. ФИО            сотрудников,        занимающие         только         одну          должность
   найдем       сначала      сотрудников,    занимающих       больше       одной      должности
   R4 = (R1[R1.ФИО = R1’.ФИО ∧ R1.Должность ≠ R1’.Должность]R1’)[ФИО]
   вычтем       из      проекции     R1     по     ФИО       полученное       отношение      R4
   (R1[ФИО]) \ R4
7. Отделы, имеющие в штате, по крайней мере, все те должности, что и в отделе “Цех 1”
   найдем       все     должности     положенные     по     штату      в      отделе     “Цех1”
   R4           =          (R3[Отдел         =         “Цех           1”])          [Должность]
   ответ                       на                   поставленный                         вопрос
   R3[Должность ÷ Должность]R4

2.2.4. Алгоритм перехода от модели «сущность-связь» к реляционной модели
       Модель «сущность-связь» используется на ранних стадиях проектирования БД. Как уже
говорилось модель «сущность-связь» является концептуальной моделью и не учитывает
особенности конкретной СУБД (допустимые типы и наименования полей и таблиц, ограничения
целостности и т.п.). Существует алгоритм однозначного преобразования модели «сущность-связь» в
реляционную модель данных (т.е. осуществляется переход от инфологического моделирования к
логическому проектированию схемы реляционной БД). Рассмотрим этот алгоритм.
1. Каждой сущности модели «сущность-связь» ставится в соответствие отношение реляционной
   модели. При этом на имена отношений накладываются ограничения, присущие конкретной
   СУБД.
2. Каждый атрибут сущности становится атрибутом соответствующего отношения. На имена
   атрибутов отношения также накладываются ограничения выбранной СУБД. Для каждого
   атрибута задается конкретный допустимый в СУБД тип данных и обязательность или
   необязательность данного атрибута (т.е. допустимость или недопустимость Null-значений)
3. Первичный ключ сущности становится первичным ключом соответствующего отношения.
   Атрибуты, входящие в первичный ключ отношения, автоматически получают свойство
   отсутствия неопределенных значений (Not Null).
4. В каждое отношение, соответствующее сущности со стороны «многие» (связь 1:N), добавляется
   набор атрибутов сущности со стороны «один», являющихся первичным ключом сущности со
   стороны «один». В отношении, соответствующим сущности со стороны «многие», этот набор
   атрибутов становится внешним ключом.




5. Для моделирования необязательного класса принадлежности у атрибутов, соответствующих
   внешнему ключу, устанавливается свойство допустимости неопределенных значений. При
   обязательном классе принадлежности атрибуты получают свойство отсутствия неопределенных
   значений.
6. Разрешение связей типа M:N. Связи становится в соответствие отношение, имеющего атрибуты,
   которые в сущностях являются первичными ключами, а в новом отношении будут внешними
   ключами. Первичным ключом нового отношения будет совокупность внешних ключей.




                                              40