实体-关系模型(或ER模型)描述特定知识领域中相关的事物。基本的ER模型由实体类型(对感兴趣的事物进行分类)和指定实体之间可能存在的关系(那些实体类型的实例)组成。

在软件工程中，为了执行业务流程，ER模型通常用于表示业务需要记住的内容。因此，ER模型变成了一个抽象的数据模型，它定义了一个可以在数据库(通常是关系数据库)中实现的数据或信息结构。

实体-关系建模是由Peter Chen开发的数据库和设计，并在1976年发表了一篇论文。然而，这个想法的变体之前就已经存在了。一些ER模型显示由一般化-专门化关系连接的超实体和子类型实体，[3]和ER模型也可用于特定领域本体的规范

使用Chen符号的MMORPG的实体关系图。

介绍

E-R模型通常是系统分析的结果，用于定义和描述业务领域中哪些流程是重要的。它没有定义业务流程;它只以图形形式表示业务数据模式。它通常以图形形式绘制为方框(实体)，这些方框由表示实体之间的关联和依赖关系的线(关系)连接。ER模型也可以用口头形式表达，例如:一栋建筑可以分为零个或多个公寓，但一个公寓只能位于一栋建筑内。

实体不仅可以由关系来描述，还可以由附加的属性(属性)来描述，这些属性包括称为“主键”的标识符。为表示属性以及实体和关系而创建的图可以称为实体-属性-关系图，而不是实体-关系模型。

ER模型通常作为数据库实现。在简单关系数据库实现中，表的每一行表示实体类型的一个实例，表中的每个字段表示属性类型。在关系数据库中，实体之间的关系是通过将一个实体的主键作为指针或“外键”存储在另一个实体的表中来实现的

传统上，ER/数据模型是在两个或三个抽象级别上构建的。注意，下面的概念-逻辑-物理层次结构用于其他类型的规范，并且与软件工程的三种模式方法不同。

概念数据模型

这是最高级别的ER模型，因为它包含了最少的粒度细节，但是建立了模型集中所包含内容的总体范围。概念ER模型通常定义了组织通常使用的主引用数据实体。开发企业范围的概念ER模型对于支持组织的数据架构文档化非常有用。

一个概念性的ER模型可以用作一个或多个逻辑数据模型的基础(参见下面)。概念ER模型的目的是在一组逻辑ER模型之间建立主数据实体的结构元数据共性。概念数据模型可用于在ER模型之间形成共性关系，作为数据模型集成的基础。

逻辑数据模型

逻辑ER模型不需要概念ER模型，特别是当逻辑ER模型的范围仅包括开发不同的信息系统时。逻辑ER模型比概念ER模型包含更多的细节。除了主数据实体之外，现在还定义了操作和事务数据实体。开发每个数据实体的详细信息，并建立这些数据实体之间的关系。然而，逻辑ER模型是独立于特定的数据库管理系统开发的，它可以在该系统中实现。

物理数据模型

可以从每个逻辑ER模型开发一个或多个物理ER模型。物理ER模型通常被开发为实例化为数据库。因此，每个物理ER模型必须包含足够的细节来生成数据库，而且每个物理ER模型都依赖于技术，因为每个数据库管理系统有所不同。

物理模型通常在数据库管理系统的结构元数据中实例化，如关系数据库对象(如数据库表)、数据库索引(如惟一键索引)和数据库约束(如外键约束或共性约束)。ER模型通常还用于设计对关系数据库对象的修改和维护数据库的结构元数据。

信息系统设计的第一阶段在需求分析期间使用这些模型来描述信息需求或将存储在数据库中的信息类型。数据建模技术可以用来描述某个兴趣领域的任何本体(即使用术语及其关系的概述和分类)。在设计基于数据库的信息系统时，概念数据模型在后期(通常称为逻辑设计)被映射到逻辑数据模型，例如关系模型;这反过来又在物理设计期间映射到物理模型。注意，有时这两个阶段都被称为“物理设计”。

实体关系模型

两个相关的实体

具有属性的实体

与属性的关系

主键

一个实体可以被定义为一个能够被唯一识别的独立存在的事物。实体是对领域复杂性的抽象。当我们谈到一个实体时，我们通常指的是现实世界的某些方面，这些方面与现实世界的其他方面是不同的

实体是物理上或逻辑上存在的事物。实体可以是一个物理对象，如房子或汽车(它们以物理形式存在)，一个事件，如房屋销售或汽车服务，或一个概念，如客户交易或订单(它们以概念的形式逻辑地存在)。虽然“实体”是最常用的一个术语，但在陈之后，我们应该真正区分实体和实体类型。实体类型是一个类别。严格地说，实体是给定实体类型的实例。实体类型通常有许多实例。因为术语实体类型有点麻烦，大多数人倾向于使用术语实体作为该术语的同义词

实体可以被认为是名词。例如:一台电脑，一个雇员，一首歌，一个数学定理，等等。

关系捕获实体之间的关系。关系可以被认为是动词，连接两个或多个名词。例如:a拥有公司和电脑之间的关系，a管理员工和部门之间的关系，a表演艺术家和一首歌之间的关系，a证明数学家和一个猜想之间的关系，等等。

上面描述的模型的语言方面在模仿自然语言构造的声明式数据库查询语言ERROL中得到了利用。ERROL的语义和实现基于重新构造的关系代数(RRA)， RRA是一种适应实体-关系模型并捕捉其语言方面的关系代数。

实体和关系都可以有属性。示例:雇员实体可能具有社会保险号(SSN)属性，而已证明的关系可能具有日期属性。

每个实体(除非它是弱实体)必须有一组最小的惟一标识属性，这称为实体的主键。

实体关系图不显示单个实体或单个关系实例。相反，它们显示实体集(同一实体类型的所有实体)和关系集(同一关系类型的所有关系)。例如:一首歌是一个实体;数据库中所有歌曲的集合是一个实体集;孩子和午餐之间被吃掉的关系是单一的关系;数据库中所有这些儿童-午餐关系的集合就是一个关系集合。换句话说，一个关系集合对应于数学上的一个关系，而一个关系对应于关系中的一个成员。

还可以指定关系集上的某些基数约束。

映射自然语言

陈提出了将自然语言描述映射到ER图的“经验法则”:Peter Chen的“英语、汉语和ER图”。

English grammar structureER structureCommon nounEntity typeProper nounEntityTransitive verbRelationship typeIntransitive verbAttribute typeAdjectiveAttribute for entityAdverbAttribute for relationship

物理视图显示数据的实际存储方式。

关系、角色和基数

在陈的原始论文中，他给出了一个关系及其作用的例子。他将一段关系描述为“婚姻”，并将其分为“丈夫”和“妻子”两个角色。

一个人在婚姻(关系)中扮演丈夫，另一个人在同一婚姻中扮演妻子。这些词是名词。这并不奇怪;给东西命名需要一个名词。

陈的术语也被用于早期的思想。一些图表的线条、箭头和鱼尾纹更多的是源于早期的巴赫曼图表，而不是陈的关系图表。

陈模型的另一个常见扩展是将关系和角色“命名”为动词或短语。

角色的命名

用is的所有者和is所属的短语来命名角色也变得很流行。这里正确的名词是owner和possession。因此，人扮演所有者的角色，汽车扮演占有的角色，而不是人扮演所有者的角色，等等。

当从语义模型生成物理实现时，名词的使用有直接的好处。当一个人与car有两种关系时，就有可能产生像owner_person和driver_person这样的名字，这是有意义的

基数

对原始规范的修改是有益的。陈描述了四处查看的基数。顺便说一句，在Oracle Designer中使用的Barker-Ellis符号使用同侧表示最小基数(类似于可选性)和角色，但是查找最大基数(乌鸦脚)。(需要澄清)

在Merise，[6] Elmasri & Navathe[7]和其他[8]中，对于角色以及最小和最大基数都有对同侧的偏好。最近的研究人员(Feinerer，[9] Dullea等人，[10])已经表明，当应用于n元关系大于2时，这是更连贯的。

在Dullea等人看来，“在UML中使用的‘查看’表示法并不能有效地表示施加在关系上的参与约束的语义，这些关系的程度高于二进制。”

Feinerer说:“如果我们像使用UML关联那样在查找语义下操作，就会出现问题。”Hartmann[11]调查了这种情况，并展示了不同的转换是如何以及为什么会失败。”(虽然上面提到的“简化”是虚假的，因为两个图3.4和3.5实际上是相同的)，而且“正如我们在接下来的几页中看到的，这种交叉解释引入了一些困难，这些困难阻止了简单机制从二元关联扩展到n元关联。”

陈的实体-关系建模表示法使用矩形表示实体集，用菱形表示适合于一级对象的关系:它们可以有自己的属性和关系。如果一个实体集参与了一个关系集，它们将被连接到一条线上。

属性被绘制为椭圆，并与一条线连接到一个实体或关系集。

基数约束表示如下:

双线表示参与约束、总体或满射:实体集合中的所有实体必须参与关系集合中的至少一个关系;
从实体集到关系集的箭头表示一个关键约束，即注入性:实体集的每个实体最多可以参与关系集中的一个关系;
粗线表示两者，即双射性:实体集合中的每个实体只涉及一个关系。
属性的带下划线名称表示它是键:与此属性相关的两个不同实体或关系总是具有此属性的不同值。
属性经常被省略，因为它们会使图表混乱;其他图表技术通常在为实体集绘制的矩形中列出实体属性。

乌鸦脚符号

鱼尾纹符号，其起源可追溯到戈登埃佛勒斯特(1976)的一篇文章，[12]用于巴克的符号，结构化系统分析与设计方法(SSADM)和信息技术工程。鱼尾纹图将实体表示为框，将关系表示为框之间的线。这些线两端的不同形状表示关系的相对基数。

在咨询公司CACI中使用了鱼尾纹符号。CACI的许多顾问(包括Richard Barker)后来都搬到了Oracle英国，在那里他们开发了Oracle CASE工具的早期版本，并将这种表示法介绍给更广泛的用户。

使用这种表示法，关系不能有属性。在必要时,关系提升为实体的:例如,如果需要捕捉艺术家表演歌曲,介绍了一个新的实体“性能”(属性反映了时间和地点),和艺术家,歌曲的关系成为一个间接的通过性能(artist-performs-performance performance-features-song)的关系。

三个符号用来表示基数:

这个环代表“0”
破折号代表“1”
鱼尾纹代表“许多”或“无限”

这些符号成对使用，表示一个实体在关系中可能具有的四种基数类型。符号的内部分量表示最小值，外部分量表示最大值。

环和破折号→最小零，最大一(可选)
破折号与破折号→最小一，最大一(强制)
环和鱼尾纹→最小零，最大多(可选)
破折号和鱼尾纹→最少一项，最多多项(强制)

模型可用性问题

在使用建模的数据库时，用户可能会遇到两个众所周知的问题，其中返回的结果与查询作者假定的结果不同。

第一个是“粉丝陷阱”。它与一个(主)表一起出现，该表以一对多的关系链接到多个表。这个问题的名称来自于模型在实体关系图中绘制时的样子:从主表“展开”的链接表。这种类型的模型与星型模式类似，星型模式是数据仓库中使用的一种模型。当试图使用主表上的标准SQL计算聚合的总和时，会出现意外(和不正确)的结果。解决方案是调整模型或SQL。此问题主要发生在决策支持系统的数据库中，查询此类系统的软件有时包括处理此问题的特定方法。

第二个问题是“鸿沟陷阱”。当模型表明实体类型之间存在某种关系，但某些实体之间不存在路径时，就会出现鸿沟陷阱。例如，一个建筑物有一个或多个房间，这些房间可以容纳0或更多的计算机。人们希望能够查询该模型以查看大楼中的所有计算机。然而，目前没有分配到房间的电脑(因为它们正在修理或在其他地方)不在列表中。建筑和计算机之间的另一种关系是需要捕获建筑中所有的计算机。最后一个建模问题是由于未能在模型中捕获现实世界中存在的所有关系。详见实体-关系建模2。

实体关系和语义建模

语义模型

语义模型是概念的模型，有时被称为“平台无关模型”。这是一个内涵模式。自Carnap以来，最晚的是众所周知的:[13]

“…概念的全部意义由概念的内涵和外延两个方面构成。第一部分包括概念作为一个整体嵌入到概念的世界中，即所有与其他概念的关系的总和。第二部分确立了概念的指称意义，即它在现实世界或可能世界中的对应物。

扩展模型

扩展模型是映射到特定方法或技术元素的模型，因此是“特定于平台的模型”。UML规范明确地声明类模型中的关联是扩展的，通过考虑规范提供的比任何先前候选的“语义建模语言”提供的更多的“装饰”，这实际上是不言而喻的。UML作为数据建模符号，第2部分"

实体关系的起源

ER建模之父Peter Chen在他的开创性论文中说:

实体-关系模型采用更自然的观点，认为现实世界由实体和关系组成。它整合了一些关于现实世界的重要语义信息。”[1]

在他1976年的原始文章中，陈明确对比了实体关系图和记录建模技术:

数据结构图是记录组织的表示，而不是实体和关系的精确表示。

其他几位作者也支持陈的项目:[14][15][16][17][18]

哲学对齐

从古希腊哲学家苏格拉底、柏拉图和亚里士多德(公元前428年)到现代认识论、符号学和逻辑学的皮尔斯、弗雷格和罗素，陈都符合他们的哲学和理论传统。

柏拉图本人将知识与对不变形式的理解(根据苏格拉底的说法，这些形式大致上是许多类型的事物和属性的原型或抽象表示)及其相互之间的关系联系起来。

限制

ER假设可以在关系数据库中方便地表示信息内容。它们只描述了此信息的关系结构。
它们不适用于信息不能以关系形式(需要引用)表示的系统，例如半结构化数据。
对于许多系统来说，对所包含的信息进行可能的更改是非常重要的，足以保证明确的规范。
一些(谁?作者扩展了ER建模，用结构来表示变化，这种方法得到了最初作者的支持;[19]是锚建模的一个例子。另一种方法是使用流程建模技术分别对更改进行建模。其他技术可以用于系统的其他方面。例如，ER模型大致对应于UML提供的14种不同建模技术中的1种。
即使在原则上合适的地方，ER建模也很少作为单独的活动使用。原因之一是现在有大量的工具可以直接支持关系数据库管理系统上的图表绘制和其他设计支持。这些工具可以很容易地从现有数据库中提取与ER关系图非常接近的数据库关系图，并且它们提供了关于此类关系图中包含的信息的可选视图。
在一项调查中，Brodie和Liu[20]在十个财富100强公司的样本中找不到一个实体-关系建模的实例。Badia和Lemire[21]将这种缺乏使用归咎于缺乏指导，但也归咎于缺乏好处，比如缺乏对数据集成的支持。
增强实体-关系模型(EER建模)引入了一些与面向对象设计密切相关的概念，而不是ER建模，比如is-a关系。
为了对时态数据库建模，已经考虑了许多ER扩展。类似地，ER模型被发现不适合多维数据库(用于OLAP应用程序);在这一领域还没有出现主流的概念模型，尽管它们通常围绕OLAP cube(在该领域内也称为数据立方体)的概念