实体关系模型和关系模型有什么区别？
我只能find以下两点区别：
- ER模型中的关系是明确定义的，而它们隐含在关系模型中。
- 关系模型需要一个中间表（通常称为“联结表”）来存放两个实现多对多关系的外键。
为什么我们使用关系模型，当我们有一个ER图？
你有它倒退。
- ER模型中的关系是明确定义的，而它们隐含在关系模型中。
不是。每个关系模型（RM）数据库基表和查询结果表示一个应用程序关系。 实体 – 关系build模（E-RM）模式只是一种组织（但使用不足和指定不足）（但带有误解）的关系表和约束。
- 关系模型需要一个中间表（通常称为“联结表”）来存放两个实现多对多关系的外键。
不是的。它是对象关系映射（ORM）方法，掩盖了它们的底层直接关系应用程序关系，表和约束。 “交接表”这个概念是由于ORM误解了电子RM的混淆，而误解了RM。
正如CJ Date所说的“数据库系统简介”第8版：
[陈的原始论文]的慈善读物会表明，E / R模型确实是一个数据模型，但实质上只是基本关系模型之上的一个薄层 [p 426]
简单的解决scheme即使过于简单也很stream行，这对于IT领域的状态是一个悲哀的评论。 [p 427]
关系模型
每个关系表都表示一个应用程序关系。
-- employee EID has name NAME and ... E(EID,NAME,...) 这样一个事物的math术语，也是一个代表一个math有序元组的集合，是一个“关系”。 因此，“ 关系模型”（和“实体 – 关系build模”）。 在math关系中经常用参数化语句模板来描述，其中一个math术语是“特征谓词”。 谓词的参数是表的列。 在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',...)
一个查询expression式也有一个从关系运算符和逻辑运算符（条件）中构build的谓词。 它的值也包含使它的谓词成为真的行，而忽略那些使它成为假的行。
/* 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'
目前的表格行做出真实的陈述和缺席的行使虚假的陈述是我们如何logging数据库中的应用情况以及如何解释数据库对应用情况所说的话。 如果没有和理解谓词，即应用程序关系，就不能使用或解释数据库。
实体 – 关系build模
E-RM（实际上并不了解RM）本质上是一种描述（某些部分）（有限forms的）关系数据库的（不必要的，受限制的和限制性的）图表符号。 最初有应用实体加上其他列（“实体”的“属性”）的候选键（CK）值为1：1的“实体（类）”图标/关系，并且存在“关系（类）”图标/表具有外键（FK）到表示多个实体上的应用关系以及其他事物（“关联”的“属性”）的实体表的外键。 应用程序关系由一个图标表示，其中包含参与其中的各种实体图标的行。 （即线条代表FK，这些不是关系，而是关于表格约束的陈述。）
E-RM不理解关系模型。 它在应用程序实体和关系之间做出了毫无意义和误导性的区分。 毕竟， 每个基表或查询结果的每个superkey （唯一的列集合）与某个应用实体1对应，而不仅仅是具有实体表的那个。 例如，人们可以结婚， 但是每个这样的组织与一个称为婚姻的实体是1：1。 这导致正常化和约束不足，从而导致冗余和完整性的损失。 或者当这些步骤被充分完成时，会导致ER图不实际描述应用程序，这实际上是由关系数据库谓词，表和约束来描述的。 那么ER图就是模糊的，多余的和错误的。
速记E-RM和ORM
很多自称为E-RM的演示和产品都会使E-RM变形，更不用说RM了。 他们使用“关系”一词来表示FK约束。 这产生如下。 当E-RM关系是二进制时，它是一个符号，它的FK有两行。 所以这三件事可以用FK之间的一条线代替。 这种线表示特定的二元关系及其FK，但是现在ER关系在图中是不明确的，尽pipe在长形版本中ER关系是明确的，并且在图的图中由表来反映，即关系数据库他们正在描述 。 这被称为“联结表”。 并且人们谈论那个行/表是/表示实体和/或关联之间的“X：Y关系”， 而实际上并没有注意到它是特定的应用关系 。 并且在相同的两个实体和/或关联之间可以有许多这样的应用关系。
ORM也是这样做的，但也可以用它们的FK替代n元关联，这样关联的应用程序关系和表格就会被进一步遮蔽。 活跃logging进一步通过定义几个速记关系和他们的表，相当于在E-RM图中的一连串FK线和关联图标。 许多build模技术加剧了这种情况，包括E-RM和ORM的版本，也认为应用程序关系只能是二进制的。 再一次，这是由于对RM的缺乏理解而产生的。
它们本身是两个不同的东西。 关系模型将信息表示为元组，直接映射到关系模式。 指导方针源于关系代数。
同时，ER图模拟使用实体的系统中的用户与其基础数据之间的关系。 ER图可以映射到关系模型，最后映射到工作模式。
