实体关系模型和关系模型有什么区别? [英] What is the difference between an entity relationship model and a relational model?

问题描述

我只能找到以下两个不同点:

1. E-R 模型中的关系是明确定义的，而关系模型中的关系是隐含的.
2. 关系模型需要一个中间表(通常称为连接表")来保存实现多对多关系的两个外键.

当我们有 E-R 图时，为什么要使用关系模型?

解决方案

倒退了.

<块引用>

1. E-R 模型中的关系是明确定义的，而它们隐含在关系模型中.

没有.每个关系模型(RM)数据库基表和查询结果代表一个应用关系.实体关系建模 (E-RM) 模式只是一种组织(但未充分使用和未指定)(但存在误解)关系表和约束的方式.

<块引用>

2. 关系模型需要一个中间表(通常称为连接表")来保存两个实现多对多关系.

没有.对象-关系映射 (ORM) 方法掩盖了其底层直接的关系应用程序关系、表和约束.连接表"的概念源于 ORM 对 E-RM 的混淆表示的误解，而 E-RM 本身也误解了 RM.

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

<块引用>

对 [Chen 的原始论文] 的慈善阅读会表明 E/R 模型确实是一种数据模型，但本质上只是在基本关系模型之上的薄层 [第 426 页]

<块引用>

简单的解决方案是对 IT 领域现状的悲哀评论即使它们太很简单，也很受欢迎.[第 427 页]

关系模型

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

-- 员工 EID 具有名称 NAME 和 ...E(EID,NAME,...)

这种事物的数学术语，以及表示一个事物的数学有序元组集，是一种关系".因此，关系模型"(和实体-关系建模").在数学中，关系经常由参数化语句模板描述，其中一个数学术语是特征谓词".谓词的参数是表的列.在 RM 中，DBA 为每个基表提供一个谓词，用户将根据列值和谓词做出真语句的行放入表中，而将做出假语句的行排除在外.

/* 现在员工 717 也有名字 'Smith' 和 ...并且员工 202 的名字是Doodle"，并且...*/INSERT INTO E VALUES (EID,NAME,...)(717,'史密斯',...),(202,'涂鸦',...)

查询表达式也有一个由关系运算符和逻辑运算符(在条件中)构建的谓词.它的值还保存了使其谓词为真的行，而忽略了使谓词为假的行.

/* 行，其中对于某些 E.*、M.*、EID = E.EID AND ... AND MID = M.MID并且员工 E.EID 的名称为 E.NAME 并且...AND 经理 M.MID 有AND E.DEPT = M.DEPT AND E.NAME = '史密斯'/*选择 E.*, M.MID从 E 加入 M ON E.DEPT = M.DEPTWHERE E.NAME = '史密斯'

表的现行是真，缺行是假是我们在数据库中记录应用情况的方式，以及我们如何解释数据库对应用情况所说的内容.没有和理解谓词，即应用关系，就无法使用或解释数据库.

实体关系建模

E-RM(它并不真正理解 RM)本质上是一种(不必要的、受限制的和受限制的)图表符号，用于描述(某些部分)(有限形式的)关系数据库.最初有实体(类)"图标/关系，其中候选键(CK)值与应用程序实体和其他列(实体"的属性")是 1:1 的，并且有关系(类)"图标/tables 具有到实体表的外键 (FK)，表示多个实体上的应用程序关系以及其他事物(关联"的属性").应用程序关系由一个图标表示，该图标带有指向参与其中的各种实体图标的线条.(即，线条代表 FK.它们不是关系，而是关于表格约束的陈述.)

E-RM 不理解关系模型.它在应用程序实体和关系之间进行了毫无意义和误导性的区分.毕竟，每个基表或查询结果的每个超级键(唯一列集)与某些应用程序实体是一一对应的，而不仅仅是那些有实体表的应用程序实体.例如，人们可以通过结婚来联系；但每个这样的关联都是 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 缺乏了解所致.

I was only able to find the following two differences:

1. The relationships in an E-R model are explicitly defined, while they are implicit in a relational model.
2. Relational models require an intermediate table (often called a "junction table") to hold two foreign keys that implement the many-to-many relationship.

And why do we use the relational model, when we have an E-R diagram ?

解决方案

You have it backwards.

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

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.

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

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.

As C J Date put it An Introduction to Database Systems, 8th ed:

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]

The Relational Model

Every relational table represents an application relationship.

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

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.

Entity-Relationship Modeling

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 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.

Shorthand E-RM and ORMs

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.

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屋！