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

Мне удалось найти только следующие два отличия:

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

И почему мы используем реляционную модель, когда у нас есть диаграмма E-R?

Ответ 1

У вас есть обратная сторона.

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

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

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

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

Как C J Дата ставить Введение в системы баз данных, 8-е изд:

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

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

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

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

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

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

/* 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',...)

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

/* 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'

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

Моделирование отношения сущностей

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

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

Сокращенные E-RM и ORM

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

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

Ответ 2

Это две разные вещи как таковые. Реляционная модель представляет информацию как кортежи, непосредственно сопоставленную с реляционной схемой. Рекомендации основаны на реляционной алгебре.

Между тем диаграмма ER моделирует отношения между пользователями и их базовыми данными в системе, использующей сущности. Диаграмма ER может быть сопоставлена с реляционной моделью и, наконец, с рабочей схемой.