论文翻译- 实体关系模型——企业数据视图的基础
本文最后更新于：2024年12月10日 下午
实体关系模型——企业数据视图的基础
The entity-relationship model— A basis for the enterprise view of data
PETER PIN-SHAN CHEN Massachusetts Institute of Technology Cambridge, Massachusetts
摘要
企业数据视图的概念在数据库设计过程和概念模式构建中非常有用。本文讨论了实体关系方法在描述和维护企业数据视图中的应用。介绍了更改企业模式的基本操作。最后，通过一个示例展示了实体关系方法和数据结构方法在企业数据视图建模方面的差异。
引入
在过去十年中，数据的逻辑视图这一主题引起了相当大的关注。然而，大多数研究人员都专注于数据的用户视图。直到最近，研究数据的企业视图的必要性才被认识到。数据库的不同用户可能对数据库有不同的看法，但企业应该对数据库有一个独特且一致的视图。
这对于设计具有逻辑意义和一致性的数据库尤为重要。数据的企业视图概念在数据库设计过程和概念模式设计中非常有用。
企业视图和数据库设计
数据库设计是将数据组织成与数据库管理系统的底层数据模型相匹配的形式的过程。数据库管理系统主要有三种类型：网络、层次和关系。在网络数据库管理系统（包括 Honeywell 的 IDS 和 UNIVAC DMS-1100）中，数据将被组织成不同类型的记录，并可以用数据结构图 1 表示（见图 1）。在层次数据库管理系统（包括 IBM 的 IMS）中，数据将被组织成与数据结构图类似但更受限制的形式。在关系数据库管理系统中，数据将被组织成一组表（或“关系”）。
通常，设计数据库就是决定如何将数据组织成特定形式（记录类型、表）以及如何访问它们。到目前为止，很少有工具可用于辅助数据库设计过程。通常，数据库设计者依靠自己的直觉和经验。因此，得到的数据库可能无法满足公司的目标，并可能导致公司运营出现问题。
数据库设计中的另一个相关问题是，数据库设计过程的输出——用户模式（对数据的用户视图的描述）——不是现实世界的“纯粹”表示。原因之一是数据库设计者受到数据库管理系统有限功能的限制。例如，在某些数据库系统中，实体之间的多对多关系很难直接表示。另一个原因是用户模式可能包含一些与数据库的存储表示相关的特性。例如，它可能描述哪些记录类型可以直接访问以及如何访问其他记录类型。此外，用户模式通常设计为对某种类型的数据处理操作有效。例如，关于员工的数据可能被分组为两种记录类型，即员工主记录和员工详细信息，以提高检索性能。因此，用户模式通常不是现实世界的直接表示。这使得更改非常困难。
解决上述问题的一个可能方法是在数据库设计过程中引入一个中间阶段：定义企业模式，它是现实世界的“纯粹”表示，与存储和效率考虑无关。然后，企业模式将被转换为不同类型的模式，用于不同的数据库管理系统（见图 2）。它还可以被转换为同一数据库管理系统的多个模式，以优化不同类型的数据处理操作。这种方法有几个优点：
- 企业模式比用户模式更容易理解，因为前者不受底层数据库管理/系统的限制；
- 企业模式比用户模式更稳定，因为用户模式中的某些类型的更改可能不需要企业模式进行任何更改。如果需要更改企业模式以反映企业环境的变化，则可以轻松执行更改，因为无需考虑效率和存储问题。
企业视图和概念模式
企业模式与 ANSI/X3/SPARC 小组提出的概念模式有何区别？基本上，它们非常相似，因为两者都是对企业数据视图的描述。在 SPARC 的方法中，概念模式充当外部模式（数据的用户视图）和存储模式（数据的物理视图）之间的接口（见图 3）。充当其他两个模式之间的接口的要求可能会给概念模式带来一些不良特性。如果忽略对概念模式的这一限制，概念模式和企业模式之间几乎没有区别。因此，本文讨论的技术也适用于描述和维护 SPARC 架构中的概念模式
本文采用的方法
为了描述企业数据视图，需要一个对现实世界进行建模的思维框架。不同的人可能习惯于不同的思维框架。本文使用的思维框架是实体关系 (E-R) 模型。E-R 模型和类似方法在对现实世界进行建模时已被发现很有用。本文将使用一种称为实体关系 (E-R) 图的图表技术来表示企业数据视图。
本文分为三个部分。第一部分讨论如何使用 E-R 模型和图表技术来描述企业数据视图。这是参考文献 5 中报告的工作的扩展。第二部分描述了更改企业数据视图的基本操作。这是一个工作很少的领域。本文提出的操作将有助于维护企业模式。第三部分使用 E-R 方法分析 Bachman给出的有关概念模式变化的示例。
使用实体关系模型和图表技术对现实世界进行建模
在本节中，我们将使用示例来展示如何使用实体关系 (E-R) 模型和图表技术来描述数据的企业视图。该模型的更正式定义可以在参考文献 5 中找到。
假设定义和维护企业模式的责任属于企业管理员。以下是建议企业管理员定义企业模式的程序：
（1）确定企业感兴趣的实体集 实体是可以明确识别的“事物”。
根据企业的需要，实体可以分为不同的实体类型，如员工、股东等。实体集是一组相同类型的实体。在 E-R 图中，实体集用矩形框表示（见图 4）。术语“集合”和“类型”在 E-R 图中可以互换。读者可以使用其中任意一种来解释 E-R 图。
现实世界中有很多“事物”，而且不同的企业对同一事物的看法也不同，选择最适合自己企业的实体类型是企业管理员的职责。
（2）识别企业感兴趣的关系集
实体之间是相互关联的，不同类型的实体之间可能存在不同类型的关系。关系集是一组相同类型的关系。例如，描述员工分配到项目的PROJLEMP是定义在两个实体集EMP和PROJ上的关系集。关系集也可以定义在两个以上的实体集上。例如，PROJ_SUPP_PART是定义在三个实体集PROJ、SUPP和PART上的关系集。在实体关系图中，关系集用菱形框表示，其中有线条连接到相关的实体集（见图5）。E-R图中PROJLEMP关系对应的“m”和“n”表示该关系是m:n映射。也就是说，每个员工可能与几个项目相关联，每个项目也可能有多个员工。在某些公司中，每个员工最多属于一个项目，PROJLEMP关系是1:n映射。
实体之间存在多种类型的关系。企业管理员的职责是选择企业感兴趣的关系集（或类型）。他还必须指定关系的映射类型（1:1、1:n、m:1 或 m:n）。
（3）识别实体和关系的相关属性（即定义值集和属性）
实体和关系具有属性，可以用属性-值对来表示。
“蓝色”和“4”是值的示例。值可以分为不同类型，例如 COLOR 或 QUANTITY。值集是一组相同类型的值。属性是从实体集（或关系集）到值集（或一组值集）的映射。例如，“地址”是将实体集 EMP 中的实体映射到值集 NAMES_OF_LOC 中的值的属性。请注意，我们放宽了参考文献 5 中施加的约束，即从实体集到值集的映射必须是函数（即 m: 1 映射）。换句话说，我们现在允许一个属性（例如地址）可以对同一实体（员工）具有多个值（例如位置）。属性定义的这种放宽将使企业视图中的更改更简单。这一点将在下一节中变得清晰
在 E-R 图中，值集用圆圈表示，属性用从实体集（或关系集）指向所需值集的箭头表示（见图 6）。在选择实体集和关系集后，企业管理员确定与公司运营相关的属性和值集。
以上三个步骤涵盖了企业模式的主要部分。为了简单起见，我们在本文中不再讨论与企业模式相关的其他问题，例如完整性约束。
要设计数据库，企业管理员首先要绘制一个 E-R 图，如图 7 所示。
然后，他绘制每个实体集和关系集的属性和值集。然后，将 E-R 图转换为数据结构图或一组表（“关系”）（参见图 2）。参考文献 5 讨论了转换过程中使用的规则和程序。在这里，我们将研究如何更改企业模式（E-R 图）本身。
修改企业视图
尽管企业模式比用户模式更稳定，但它仍然需要不时地进行更改以反映企业环境的变化。除了 Bachman 的一篇论文 10 外，很少有人在这方面做过什么工作。在本文中，我们使用 E-R 模型作为分析企业数据视图中不同类型的变化的基础。我们不仅提出了一组操作，还分析了这些操作的后果。
有五种基本类型的操作：添加、删除、拆分、合并和移动。前四种操作适用于实体集、关系集、属性和值集。当企业管理员希望将旧企业模式中的值集视为新模式中的实体集或反之亦然时，使用移动操作。认为 E-R 图由两个概念域组成是有用的：（1）上层概念域，由实体集和关系集组成；（2）下层概念域，由属性和值集组成。我们将在上层和下层概念域中讨论前四种操作。
最后，我们将讨论将实体集从上层概念域移动到下层概念域以及将值集向相反方向移动。
上层概念域中的操作
以下是适用于实体集和联系集的基本操作：
（1）将一个实体拆分成几个子集
例如，图 8a 中的实体集 EMP 可以拆分为两个实体集：图 8b 中的 MALE_EMP 和 FEMALE_EMP。此操作的结果是与实体集相关的关系集也必须拆分。例如，PROLEMP 拆分为 PROJ_M_EMP 和 PROJLF_EMP（参见图 8b）。
（2）将多个实体集合并为一个实体集
这是 (1) 的逆操作。其结果是相关关系集可能必须合并。
（3）将一个关系集拆分成几个子集
此操作的一个示例是：图 8a 中的关系集 PROJLEMP 可以拆分为两个关系集，即图 8c 中的 PROJLMANAGER 和 PROJ_WORKER。请注意，新关系中的映射类型可能与原始关系中的映射类型不同。例如，PROJLMANAGER 中的映射为 1: n，而 PROJ_EMP 中的映射为 m:n。
（4）将多个联系集合并为一个集合
这是（3）的逆操作。注意这些联系集必须定义在同一组实体集上。
（5）添加新实体集
例如，可以在图 8a 中的 E-R 图中增加一个名为 SUPPLIER 的新实体集。结果如图 9a 所示。请注意，企业模式中可以有独立的实体集，尽管在许多情况下，新实体集和现有实体集之间的关系是立即建立的（参见下一个操作）。
（6）添加新的关系集
我们可以为新的实体集添加新的关系集，如图9b中的关系集PROJLSUPP。我们也可以为现有的实体集添加新的关系集，如图9b中的关系集PROJLMANAGER
（7）删除实体集
例如，删除图9b中的实体集EMP后，得到图9c。其后果是：（i）与该实体集相关的关系集也被删除；（ii）与被删除实体集相关的属性和相关关系集也被删除
（8）删除关系集
一个例子是：删除图9b中的关系集PROJLEMP，结果如图9d所示。该操作的后果是关系的属性被删除（图9d中未显示）。
较低概念域中的操作
假设实体集 EMP 中的实体具有两个属性，即 LEOAl^MAME 和 PHONE，它们将实体映射到值集 NAME 和 PHONE_#（参见图 10a）。我们将使用这些属性和值集作为讨论以下操作的基础：
（1）添加值集
例如，可以在图10a中添加一个名为DOLLARS的新值集。结果如图10b所示。通常，此操作后跟“添加属性”操作。
（2）删除值集
删除图10a中的值集PHONE_#后，得到图10c。其结果是，与该值集相关的所有属性都将被删除
（3）将一个值集拆分成几个子集
图 10a 中的值集 NAMES 可以拆分成图 10d 中的两个值集 FIRST_NAMES 和 LAST_NAMES。其结果是，与该值集相关的属性可能必须进行调整。虽然图 10d 中没有拆分属性 LEGAL_NAME，但可以将其拆分成两个属性：LEGAL_FIRST_NAME 和 LEGAL. LAST_NAME。企业管理员有责任做出此决定。
（4）将多个值集合并为一个值集
这是（3）的逆操作。
（5）添加属性
例如，图11a中添加属性OTHER_NAME，即可得到图11b。
（6）删除属性
从图 11a 中删除属性 LEGAL_NAME，得到图 11e。如果需要，与该属性关联的值集将通过另一个操作（“删除值集”）删除。在某些情况下，该值集可能仍与其他属性相关联（参见图 11e）。
（7）将一个属性拆分为多个属性
例如图11a中，将图11d中的属性PHONE拆分为OFFICE_PHONE和HOME_PHONE两个属性。
（8）将多个属性合并为一个属性
这是（7）的逆操作。属性必须定义在同一个实体集（或联系集）上。
两个概念域之间的操作
假设有两个实体集（EMP 和 PROJ）、一个关系集（PROJLEMP）、四个值集（NAMES_OF_PLACES、SOG_SEC_#、PHONE_# 和 PROJLNAMES）和四个属性（ADDRESS、SOC_SEC_NO、PHONE 和 NAME），如图 12a 所示。我们将以它们为基础讨论以下操作：
(1) 将值集从下层概念域移到上层概念域
当企业环境发生变化时，将 PLACE 视为实体集而不是值集可能变得很自然。因此，在图 12b 中，“ADDRESS”变成了一个关系集，“PLACE”有一个属性“NAME”，它指向值集 NAMES_OF_PLACES。由于 PLACE 是一个实体集，我们可以将它与其他实体集（如 PROJ）建立新的关系，或者添加更多属性和值集来描述“地点”的属性。
（2）将实体集从上层概念域移到下层概念域
当企业环境再次发生变化时，将PROJ视为值集而不是实体集可能变得很自然。在图12c中，PROJ从上层概念域中删除，联系集PROJLEMP变为属性INVOLVED_PROJ。图12b中的实体集PROJ可能与多个值集相关联，但只有用于标识实体PR.OJ的值集PROJ_NAMES仍保留在下层概念域中。
实例分析
在最近的一篇论文中，Bachman 使用数据结构图来说明概念模式的变化。在本节中，我们将首先陈述他的例子，然后使用 ER 图来解释他的例子
使用数据结构图描述示例
以下是 Bachman 示例的简化版本：
(a) 一开始，企业管理员声明了一个概念模式，如图 13a 所示。假设读者对数据结构图有一定的了解。1 简单来说，一个矩形框代表一种记录类型，一个箭头代表一个数据结构集（即记录类型之间的 l:n 关系）。在图 13a 中，有两种类型的概念记录，即 COMPANY 和 PERSON，以及一个数据结构集“a”，表示每个人只与一家公司相关联，并且每家公司都有一组人员。
(b) 后来，企业管理员认识到公司的人员本身就是人。在几家公司合并时可能会发现这一事实，其中一些人身兼两职，是合并后两家公司的人员。图 13b 说明了新概念模式的数据结构图。基本上，旧的人员类型记录已分为两种记录类型，即 PERSONNEL 和 PERSON。“PERSON”具有属性 NAME 和 ADDRESS（图中未显示）
（c）过了一会儿，企业管理员决定将居住地址从个人记录中分离出来。图 13c 说明了“PLACE”概念记录类型和数据结构集类型 c 的添加。还假设每个人都有一个唯一的地址（地点）。
(d) 现在人们认识到人们会从一个地方搬到另一个地方，因此了解当前地址和过去地址是必要的。另一个原因可能是：人们发现一个人可能有多个地址。无论哪种情况，都会将新的概念记录类型 ADDRESS 添加到概念模式中（参见图 13d）。
使用实体关系图进行分析
下面我们用E-R图来解释上面的例子：
（a）图 14a 中的 E-R 图对应于图 13a 中的数据结构图。在企业视图中，有两种类型的实体，即 PERSON 和 COMPANY。由于 COMPANY 和 PERSON 之间的映射为 1：n，因此关系集 PERSONNEL 在图 13a 中用数据结构集“a”表示
（b）图 14b 是图 13b 对应的 E-R 图。由于关系集 PERSONNEL 是 m:n 映射，因此在图 13b 中它由关系记录类型 PERSONNEL 和两个数据结构集“a”和“b”表示。请注意，图 14a 和 14b 在上层概念域中具有相同的实体集和关系集，不同之处在于实体集之间的映射类型
(c) 现在，企业管理员更愿意将“PLACE”视为实体集，而不是值集。
因此，我们有图 14c。图 14b 中的属性 ADDRESS 成为图 14c 中的关系集。由于 PLACE 和 PERSON 之间的映射为 1:n，因此关系集 ADDRESS 由图 13c 中的数据结构集“c”表示。
（d）企业管理员发现 PLACE 和 PERSON 之间的映射是 m:n 映射，而不是 l:n 映射。新的企业视图由图 14d 表示。由于映射是 m:n，关系集 ADDRESS 由记录类型 ADDRESS 和两个数据结构集“d”和“e”表示。请注意，图 14c 和 14d 几乎相同，只是 PLACE 和 PERSON 之间的映射类型不同。
总体而言，E-R 图比数据结构图更易于分析企业视图的变化。Bachman 还提出了图 13d 中的歧义问题：如果要修改某人的地址，他是否必须创建新的“地址”记录或更改此人居住地的名称？使用 E-R 方法可以轻松回答这个问题。考虑图 14d。由于 PLACE 是一个实体集，因此更改某人的地址就是更改此人与“他的住所”之间的关系。我们不应该更改此人居住地的名称，因为“NAME”和“NAMES_OF_PLACES”用于描述 PLACE 实体的属性（参见图 14d）。
总结
企业模式是数据库设计中的一个有用的中间步骤。在本文中，我们展示了如何使用实体关系模型和图表技术来描述企业模式。由于企业环境时常发生变化，企业模式也必须随之改变以反映这些变化。本文介绍了可用于修改企业模式的五种基本操作（添加、删除、拆分、合并和移位），并讨论了这些操作的后果。最后，我们用一个例子来分析实体关系方法和网络方法在对数据的企业视图进行建模方面的差异。
参考文献
Bachman, C. W., “Data Structure Diagrams,” Data Base 1, 2, Summer 1969, pp. 4-10.
Codd, E. F., “A Relational Model of Data for Large Shared Data Banks,” Comm. ACM 13, 6, June 1970, pp. 377-387.
ANSI, Interim Report ofANSI/X3/SPARC Group on Database Management Systems, ANSI, February 1975.
Chen, P. P., “The Entity-Relationship Model,” (abstract), Proc. 1st Very Large Database Conf., Framingham, Mass., Sept. 1975, ACM.
Chen, P. P., “The Entity-Relationship Model: Toward a Unified View of Data,” ACM Tran. on Database Systems 1, 1, March 1976, pp. 9-36.
Moulin, P., J. Randon, M. Teboul, et al, “Conceptual Model as a Database Design Tool,” Proc. IFIP TC-2 Working Conf., Jan. 1976, Black Forest, Germany, pp. 459-479.
Hall, P., Todd S. Owlett, “Relations and Entities,” Proc. IFIP TC-2 Working Conf., Jan. 1976, Black Forest, Germany, pp. 430-458.
Deheneffe C. and H. Hennebert, “NUL: a Navigational User’s Language for a Network Structured Data Base,” Proc. ACM 1976 SIGMOD Conf, Washington, D.C., June 1976, pp. 135-142.
Tozer, E. E., “Database Systems Analysis and Design,” Technical report, Software Sciences Limited, England, April 1976.
Bachman, C. W., “Trends in Database Management—1975,” Proc. AFIPS 1975 NCC, Vol. 44, AFIPS Press, Montvale, N. J., pp. 569-576.