В чем разница между моделью отношений сущностей и реляционной моделью?

у вас все наоборот.

1. отношения в модели E-R явно определены, в то время как они неявны в реляционной модели.

нет. Каждая базовая таблица базы данных реляционной модели (RM) и результат запроса представляют отношение приложения. Схемы моделирования сущностных отношений (E-RM) - это просто способ организации (но недостаточного использования и недостаточного указания) (но с непониманием) реляционных таблиц и ограничения.

1. реляционные модели требуют промежуточной таблицы (часто называемой "таблицей соединений") для хранения двух внешних ключей, реализующих отношения "многие ко многим".

нет. Это объектно-реляционное отображение (ORM) подходы, которые затемняют их основные прямые отношения реляционных приложений, таблиц и ограничений. Понятие "соединительная таблица" возникло из-за непонимания Ормом путаницы презентации E-RM, которая сама неправильно понимает RM.

как дата C J поставила его введение в системы баз данных, 8-е изд:

благотворительное чтение [оригинальной статьи Чэня] предполагает, что модель E/R действительно является моделью данных, но по существу просто тонкий слой поверх базовой реляционной модели [p 426]

Это грустный комментарий о состоянии ИТ-поля, что простые решения популярны даже тогда, когда они слишком простой. [p 427]

Реляционная Модель

каждая реляционная таблица представляет собой приложение.

-- employee EID has name NAME and ...
E(EID,NAME,...)

математический термин для такой вещи, а также для математического упорядоченного кортежа, представляющего один, является "отношением". Отсюда и "реляционных Model "(и " Entity -отношения моделирование"). В математике отношения часто описываются параметризованными шаблонами операторов, для которых одним математическим термином является "характеристический предикат". Параметрами предиката являются столбцы таблицы. В RM DBA дает предикат для каждой базовой таблицы, и пользователи помещают строки, которые делают оператор true из значений столбцов и предиката в таблицу, и оставляют строки, которые делают оператор false.

/* now also employee 717 has name 'Smith' and ...
    AND employee 202 has name 'Doodle' and ...
*/
INSERT INTO E VALUES (EID,NAME,...)
    (717,'Smith',...),(202,'Doodle',...)

выражение запроса также имеет предикат, построенный из операторов отношений и логики операторы (в условиях) в нем. Его значение также содержит строки, которые делают его предикат true и оставляет те, которые делают его false.

/* rows where
   FOR SOME E.*, M.*,
        EID = E.EID AND ... AND MID = M.MID
   AND employee E.EID has name E.NAME and ...
   AND manager M.MID has 
   AND E.DEPT = M.DEPT AND E.NAME = 'Smith'
/*
SELECT E.*, M.MID
FROM E JOIN M ON E.DEPT = M.DEPT
WHERE E.NAME = 'Smith'

настоящие строки таблиц, делающих истинные утверждения и отсутствующие строки, делающие ложные утверждения, - это то, как мы записываем о ситуации приложения в базе данных и как мы интерпретируем то, что база данных говорит о ситуации приложения. Нельзя использовать или интерпретировать базу данных, не имея и не понимая приложения предикатов ie отношения.

Entity-Моделирование Отношений

E-RM(который на самом деле не понимает RM) по существу является (N ненужной, ограниченной и ограничительной) диаграммной нотацией для описания (некоторых частей) (ограниченных форм) реляционных баз данных. Первоначально были значки/отношения" сущность (класс)", где значения ключа-кандидата (CK) были 1: 1 с сущностями приложения плюс другие столбцы ("свойства ""сущности"), и были " отношения (class)" значки/таблицы, которые имели внешние ключи (FKs) к таблицам сущностей, представляющим отношения приложений на нескольких сущностях плюс другие вещи ("свойства" "ассоциации"). Связь приложения была представлена значком со строками различных значков сущности, которые участвовали в нем. (Т. е. строки, представленные FKs. Которые являются не отношениями, а утверждениями об ограничениях на таблицы.)

E-RM не понимает реляционную модель. Это делает бессмысленным и вводящее в заблуждение различие между сущностями приложения и отношениями. Ведь каждый суперключ (уникальный набор столбцов) каждой базовой таблицы или результата запроса в 1:1 переписка с некоторые сущность приложения, а не только те, которые имеют таблицы сущностей. Например, люди могут быть связаны браком; но каждая такая ассоциация 1: 1 с сущностью, называемой браком. Это приводит к неадекватной нормализации и ограничениям, что приводит к избыточности и потере целостности. Или когда эти шаги выполняются адекватно, это приводит к диаграмме E-R, фактически не описывающей приложение, которое фактически описывается предикатами, таблицами и ограничениями реляционной базы данных. Тогда диаграмма E-R является расплывчатой, избыточной и неправильной.

Стенография E-RM и ORMs

много презентаций и продуктов, претендующих на e-RM деформировать E-RM, не говоря уже о RM. Они используют слово "отношение" для обозначения ограничения FK. Это возникает следующим образом. Когда отношение E-RM является двоичным, это символ с двумя линиями к его FKs. Таким образом, эти три вещи могут быть заменены одной линией между FKs. Этот вид линии представляет это конкретное двоичное отношение и его FKs, но теперь отношение E-R не является явным на диаграмме, хотя отношение E-R является явным в версии longhand и отражается таблицей в что диаграммы цены, а именно реляционная база данных они с описанием. Это называется "таблица соединений". И люди говорят об этой строке / таблице, представляющей" отношения X:Y " между сущностями и/или ассоциациями , фактически не замечая что это конкретное приложение. И может быть много такие отношения приложений между теми же двумя сущностями и/или ассоциациями.

ORMs делают это тоже, но также заменяют N-арные ассоциации только их FKs, чтобы связанные отношения приложения и таблица были еще более затемнены. Активные записи идут еще дальше, определяя несколько сокращенных отношений и их таблицы одновременно, что эквивалентно цепочке линий FK и значков ассоциаций на диаграмме longhand E-RM. Это усугубляется многими методами моделирования, включая версии E-RM и ORMs, также полагая, что отношения приложений могут быть только двоичными. Опять же, это исторически возникло из-за отсутствия понимания КОМНАТА.