数据库 – 实体关系模型和关系模型之间有什么区别？

我只能找到以下两个不同之处：

> E-R模型中的关系是明确定义的,而它们隐含在关系模型中.
>关系模型需要一个中间表(通常称为“联结表”)来保存两个实现多对多关系的外键.

当我们有E-R图时,为什么我们使用关系模型？

解决方法

你倒退了.

1. The relationships in an E-R model are explicitly defined,while they
   are implicit in a relational model.

不可以.每个关系模型(RM)数据库基表和查询结果表示应用程序关系.实体 – 关系建模(E-RM)模式只是组织(但使用不足和指定不足)(但有误解)关系表和约束的一种方式.

2. Relational models require an intermediate table (often called a “junction table”) to hold two foreign keys that implement the
   many-to-many relationship.

不是.对象关系映射(ORM)方法模糊了它们潜在的直接关系应用程序关系,表和约束. “联汇表”的概念源于ORM对E-RM的混乱陈述的误解,E-RM本身误解了RM.

正如C J Date所说,数据库系统简介,第8版：

a charitable reading of [Chen’s original paper] would suggest that the E/R model is indeed a data model,but one that is essentially just a thin layer on top of the basic relational model [p 426]

It is a sad comment on the state of the IT field that simple solutions
are popular even when they are too simple. [p 427]

关系模型

每个关系表都代表一个应用程序关系.

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

这种事物的数学术语,以及代表一个数学有序元组的数学术语,是一种“关系”.因此,“关系模型”(和“实体 – 关系建模”).在数学中,关系经常由参数化语句模板描述,其中一个数学术语是“特征谓词”.谓词的参数是表的列.在RM中,DBA为每个基表提供谓词,并且用户将从列值和谓词生成真实语句的行放入表中,并保留用于生成false语句的行.

/* Now also employee 717 has name 'Smith' and ...
    AND employee 202 has name 'Doodle' and ...
*/
INSERT INTO E VALUES (EID,...)
    (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)本质上是一种(不必要的,限制性的和限制性的)图表符号,用于描述(某些部分)(有限形式的)关系数据库.最初有“实体(类)”图标/关系,其中候选键(CK)值为1：1,应用程序实体加上其他列(“实体”的“属性”),并且存在“关系(类)”图标/表具有外键(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也这样做,但也只用它们的FK替换n元关联,以便进一步模糊相关的应用程序关系和表. Active Records通过一次定义几个简写关系及其表格来进一步发展,相当于简写E-RM图中的一系列FK线和关联图标.许多建模技术加剧了这种情况,包括E-RM和ORM的版本,也认为应用程序关系只能是二进制的.同样,这在历史上源于对RM的缺乏了解.