实体关系模型和关系模型之间有什么区别？ [英] What is the difference between an entity relationship model and a relational model?
问题描述
我只能找到以下两个区别：
I was only able to find the following two differences:
- ER模型中的关系是明确定义的，在关系模型中。
- 关系模型需要一个中间表（通常称为连接表）来保存实现多对多关系的两个外键。
为什么我们使用关系模型，当我们有一个ER图？
And why do we use the relational model, when we have an E-R diagram ?
推荐答案
向后。
- ER模型中的关系是明确定义的，而
在关系模型中是隐含的。
否。每个关系模型（RM）数据库基表和查询结果表示应用程序关系。实体 - 关系建模（E-RM）模式只是一种组织（但使用不足和不足的）（但误解）关系表和约束的方法。
No. Each Relational Model (RM) database base table and query result represents an application relationship. Entity-Relationship Modeling (E-RM) schemas are just a way of organizing (but under-using and under-specifying) (but with misunderstanding) relational tables and constraints.
- 关系模型需要一个中间表（通常称为联结表）来保存两个实现
many- - 许多关系。
否。它是对象关系映射（ORM）方法，它掩盖了其底层的简单的关系应用程序关系，表和约束。 连接表的概念源于ORM对误解了RM的E-RM的混淆表示的误解。
No. It is Object-Relational Mapping (ORM) approaches that obscure their underlying straightforward relational application relationships, tables and constraints. The notion of "junction table" arose from ORM misunderstandings of confused presentations of the E-RM which itself misunderstands the RM.
由于CJ日期，它介绍数据库系统，第8版：
As C J Date put it An Introduction to Database Systems, 8th ed:
对[Chen的原文]的慈善阅读表明E / R模型确实是一个数据模型，一个基本上只是在基本关系模型之上的一个薄层 [p 426]
这是一个悲伤的评论，IT领域的状态，简单的解决方案
是流行的，即使他们也简单。 [p 427]
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]
关系模型
每个关系表表示一个应用程序关系。
Every relational table represents an application relationship.
-- employee EID has name NAME and ...
E(EID,NAME,...)
这样的东西的数学术语，表示一个的数学有序元组集合是关系。因此，关系模型（和实体 - 关系建模）。在数学中，关系通常由参数化语句模板描述，其中一个数学项是特征谓词。谓词的参数是表的列。在RM中，DBA为每个基表提供一个谓词，用户将从列值和谓词生成真实语句的行放入表中，并留下产生false语句的行。
The mathematical term for such a thing, and also for a mathematical ordered-tuple set representing one, is a "relation". Hence the "Relational Model" (and "Entity-Relationship Modeling"). In mathematics relations are frequently described by parameterized statement templates for which one mathematical term is "characteristic predicate". The parameters of the predicate are columns of the table. In the RM a DBA gives a predicate for each base table and users put the rows that make a true statement from column values and the predicate into the table and leave the rows that make a false statement out.
/* 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',...)
查询表达式也有一个从关系运算符和逻辑运算符（条件）构建的谓词。
A query expression also has a predicate built from the relation operators and logic operators (in conditions) in it. Its value also holds the rows that make its predicate true and leaves out the ones that make it 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'
当前行的表使得真的语句和缺少行做出假语句是我们如何记录数据库中的应用程序情况，以及我们如何解释数据库对应用程序情况说什么。
Present rows of tables making true statements and absent rows making false statements is how we record about the application situation in the database and how we interpret what the database is saying about the application situation. One can't use or interpret the database without having and understanding the predicates ie application relationships.
实体关系建模
E-RM（不真正理解RM）本质上是描述（有限形式的）关系数据库的（不必要的，受限制的和限制性的）图表符号。最初有实体（类）图标/关系，其中候选键（CK）值与应用实体加上其他列（实体的属性）为1：1，并且存在关系/表，其具有表示多个实体上的应用关系和其他事物（关联的属性）的实体表的外键（FK）。应用程序关系由带有参与到其中的各种实体图标的线的图标表示。 （即表示FK的行，它们不是关系，而是关于表约束的语句）。
E-RM (which does not really understand the RM) is essentially a(n unnecessary, restricted and restrictive) diagramming notation for describing (some parts of) (limited forms of) relational databases. Originally there were "entity (class)" icons/relations where the candidate key (CK) values were 1:1 with application entities plus other columns ("properties" of the "entity") and there were "relationship (class)" icons/tables which had foreign keys (FKs) to entity tables representing application relationships on multiple entities plus other things ("properties" of the "association"). An application relationship was represented by an icon with lines to the various entity icons that participated in it. (Ie the lines represented FKs. Which are not relationships but statements about constraints on tables.)
E-RM不理解关系模型。它在应用程序实体和关系之间进行无意义和误导性的区分。毕竟，每个基表或查询结果的每个超级键（唯一列集）与 应用程序实体的比例是1：1，而不仅仅是具有实体表。例如人们可以通过结婚关联;但是每个这样的关联与被称为婚姻的实体是1：1。这导致不适当的规范化和约束，因此冗余和完整性的损失。或者当这些步骤充分完成时，它导致E-R图不实际描述应用程序，这实际上由关系数据库谓词，表和约束描述。
E-RM doesn't understand the relational model. It makes a pointless and misleading distinction between application entities and relationships. After all, every superkey (unique column set) of every base table or query result is in 1:1 correspondence with some application entity, not just the ones that have entity tables. Eg people can be associated by being married; but each such association is 1:1 with an entity called a marriage. This leads to inadequate normalization and constraints, hence redundancy and loss of integrity. Or when those steps are adequately done it leads to the E-R diagram not actually describing the application, which is actually described by the relational database predicates, tables and constraints. Then the E-R diagram is both vague, redundant and wrong.
速记的E-RM和ORM
很多演讲和产品声称是E-RM扭曲了E-RM，更不用说RM。他们使用单词关系来表示FK约束。这发生如下。当E-RM关系是二进制时，它是具有到其FK的两条线的符号。所以这三个东西可以用FKs之间的一行代替。这种线表示特定的二进制关系及其FK，但是现在ER关系在图中不是显式的，尽管ER关系在长文版本中是显式的，并且由表中的表反映。 ，即它们描述的关系数据库。这被称为连接表。并且人们谈论该行/表格是/表示实体和/或关联之间的X：Y关系，而实际上没有注意到它是特定应用关系。并且在相同的两个实体和/或关联之间可以存在许多这样的应用关系。
A lot of presentations and products claiming to be E-RM warp the E-RM, let alone the RM. They use the word "relationship" to mean a FK constraint. This arises as follows. When an E-RM relationship is binary it is a symbol with two lines to its FKs. So those three things can be replaced by one line between FKs. This kind of line represents that particular binary relationship and its FKs but now the E-R relationship is not explicit in the diagram although the E-R relationship is explicit in the longhand version and it is reflected by a table in what the diagrams are pictures of, namely the relational database they are describing. This gets called a "junction table". And people talk about that line/table being/representing "an X:Y relationship" between entities and/or associations without actually ever noticing that it's a particular application relationship. And there can be many such application relationships between the same two entities and/or associations.
ORM也这样做，仅通过它们的FK来关联，使得相关联的应用关系和表被进一步模糊。通过同时定义几个速记关系及其表，等效于长形E-RM图中的一系列FK线和关联图标，活动记录更进一步。许多建模技术（包括E-RM和ORM的版本）加剧了这种情况，同时认为应用程序关系只能是二进制的。再次，这是历史上由于缺乏对RM的理解。
ORMs do this too but also replace n-ary associations by just their FKs so that the associated application relationship and table are further obscured. Active Records goes even further by defining several shorthand relationships and their tables at once, equivalent to a chain of FK lines and association icons in the longhand E-RM diagram. This is exacerbated by many modeling techniques, including versions of E-RM and ORMs, also thinking that application relationships can only be binary. Again, this arose historically from lack of understanding of the RM.
这篇关于实体关系模型和关系模型之间有什么区别？的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！
