entity-relationship - 在 ER 图中定义实体、属性和关系的基本规则是什么？

Question

我的问题是：为了存在以下哪些需要强制具有键和属性？

• 实体
• 实体类型
• 关系类型
• 关系（具有关系类型的元组）

我知道我的问题有点奇怪，但我不太确定构建 ER-Diagram 的规则是什么。换句话说，我的图表中应该强制出现什么，而不应该出现什么（例如属性）。提前致谢。

Answer 1

在原始的 Entity-Relationship 方法中，我们识别实体类型和关系/关联类型及其相关属性。在绘制 ER 图时，我们选择一组或多组属性，这些属性可以将类型的实例标识为键。如果没有这样一个可识别的属性组，那么我们必须引入一个属性作为代理。类型的值集（其实例集）将由关系/表表示。

来自 Chen 1976 年的实体-关系模型-迈向统一的数据视图：

基本上，实体键是一组属性，使得从实体集到相应的值集组的映射是一对一的。如果我们无法在可用数据上找到这样的一对一映射，或者如果需要简单地识别实体，我们可以定义一个人工属性和一个值集，以便这样的映射成为可能。

这些是我们必须具备的唯一属性。（代理属性源于这种必要性。）

如果您对实体类型或关系类型的任何非关键属性不感兴趣，那么您的设计/图表中将不会有任何其他属性。

ER 图显示实体类型和关系类型。它不显示实体实例或关系实例。

Answer 2

实体仅在具有属性/属性时才存在。您不能定义没有属性/属性的实体，即使它们具有主键。

分区关系中的实体类型（由三角形符号表示）在概念模型中没有主键。但它们只有在具有同等属性的情况下才存在。一旦分解了关系，在物理模型中，他们将把你的超级实体的主键作为外键，也作为主键。

1-1 和 1-N（或 N-1）关系没有属性/属性。另一方面，NN 关系可能有也可能没有属性/属性。如果您需要将属性/属性设置为 N-1（或 1-N）关系，它们应该在 N 侧。

概念模型可能有 NN 关系，但逻辑模型没有。分解后，逻辑模型最终应该只有 1-1 关系或/和 1-N（或 N-1）关系。

有任何问题，请评论，我会一一解答。

编辑

@reaanb 用户提出了一个有趣的问题。我认为添加内容作为答案本身是有效的。您（问题的作者）甚至可以消除对我所说的一些疑问。那么让我们看看...

当您分解具有属性的 1-1 或 1-N 关系时，在维护关系中的属性的同时（根据评论中提到的内容），您将不得不创建另一个至少需要具有外键的表关系的一方。

在功能方面，保留N端的属性可以省去你创建这个表的时间（以防你不必创建这个表）。最终模型中少一张表就是少一张连接操作，如果您需要执行多次，这可能会很昂贵。

在可读性方面，1-N 关系代表单边关系。在我看来，某些东西总是会产生对单边的依赖，而不是对双方的依赖。因此，对 N 侧的更改与 1 侧根本无关。至少在编程，程序和系统的开发中，它遵循减少各方之间耦合的概念，在这种情况下，这是一件好事（即使对于数据库的开发）。

正如我所说，在具有属性/属性的 1-N（或 N-1）关系中，属性放在 N 侧，因为/由于创建了单边关系，它们仅与 N 侧相关。

唯一会使情况复杂化的情况是 1-1 关系。在这种情况下，我们必须考虑两件事：

• 谁依赖？
• 将来谁能将其基数更改为 N？

1-1 关系可能会令人困惑，因为它们可能（乍一看）代表单边关系。但规则是，我们需要以各种方式定义外键，对吧？毕竟我们需要建立关系。对于这种情况，由数据建模者自行决定。所以我们一般把外键放在最终能变成N的那一边。但这不是强制性的。同样，你必须有自由裁量权。

现在，1-1 关系何时具有属性？这是很多，如果不是不可能的话（如果有人不同意对真实案例的合理解释，我会问一个上下文示例，如果存在，请确保我会收回我所说的话）。如果发生这种情况，最好查看您的图表。立即问自己：

• 这些属性存在的原因是什么？
• 它们对双方都有关系吗？

关系中的属性很好地表明我们正在发生 NN 或 1-N（或 N-1）个关系，或者您将属性放在错误的位置。在这种情况下，只需遵循上述规则即可。

---

举个简单的例子来展示练习（关于 1-1 关系）怎么样？让我们想象以下情况（上下文）：

想象一下，我们有一家公司，我们有员工担任他们的职位/角色。想象一下，我们公司有办公室。每个办公室和员工都有一个专有名称。现在想象一下，一个办公室只有一名员工，一名员工在一个办公室工作。

这将为我们提供以下概念模型：

到目前为止一切顺利，对吧？现在让我们添加更多细节：

每个办公室的每个员工每天必须工作大约 X 小时。您需要知道员工工作了多少小时，以及他/她在哪几天工作。

您将在哪里添加此信息？还没有看到答案。停下来想一想。停下来想想，真的。看一下上下文。这些信息与谁有关？对双方？让我们一起发展思路……

假设我们要添加一个名为“工作时间”的多值属性，对吧？此属性分解后将成为一个新实体，其中至少包含两个新属性/字段：员工在办公室工作的天数和小时数。

注意：理想情况下，我们直接将该属性转换为一个实体，但为了便于理解，我们将其保留为一个属性。

这些信息需要持久化，那么我们应该把它放在哪里呢？在关系？在员工实体中？在办公室实体中？在哪里？

如果我们使用关系，那么我们是说当我们对概念模型进行分解时，关系将成为一个新表。该表将至少包含三个字段：

• 员工（FK）
• 办公室 (FK)
• 工作时间（FK）

前两个字段是显而易见的。最后一个字段将表示新表的外键，该表由多值属性的分解产生。

这种关系可以准确地告诉我们谁，在哪个办公室，在哪几天工作了多长时间。但这里有一些警告：

• 您又创建了一张表，这意味着在查询中又多了一张联接。
• 如果您不小心创建了中间/链接/连接表，许多员工可能会在一个或多个不同的办公室工作。
• 如果您感到困惑，最终可能会给两个实体之间建立的关系带来错误的工作量。除了员工之外，您还需要了解办公室。

让我们暂时不考虑这个想法，来研究另一个案例。假设我们没有把属性放在关系中，我们仍然必须把它放在某个地方。如果我们将属性放在 Offices 实体中会发生什么？将这些信息存储在这里有意义吗？如果将来一个办公室可以有几个员工在里面工作怎么办？这是存储这些信息的最佳位置吗？

如果发生这种情况，在此处保留此信息将无济于事。此属性仅保留一名员工的工作量。如果有几名员工在一个办公室工作，即使使用 SQL 连接，您也不会知道谁在哪个办公室工作了多长时间。无论如何，您必须在三者之间创建关系：员工、办公室和工作时间，然后我们将再次回到所建立的关系（1-1 与属性，直到它变成一个新表）。

如果将来一个办公室可以有几个员工在工作，也许我们应该把这个属性/属性放在Employees实体（N端）中，对吧？看一看：

看看它有多美。当这一切都被分解后，我们将为每个员工建立一个工作量关系，并且我们将知道哪个员工在哪个办公室工作。所有这些都是通过一个简单的 SQL 连接完成的。无论如何，我们在这里定义了关系中的属性（请记住，在 1-1 关系期间，我们应该将属性放在将来可能变为 N 的一侧）。

不再有一张新表，也不再有一张表参与 SQL 连接。您不可能不小心为一名员工分配多个办公室。您不需要为此创建更多规则（约束）。这给我们带来了开发/建模数据库中的一个非常重要的问题：

• 数据一致性

对于一个形状良好、准备充分且管理良好的数据库，客户端应用程序几乎不可能将其置于不一致的状态，这可能会完全危及整个系统（尤其是为了安全或敏感数据的盗窃）。客户端应用程序可以验证数据（如果操作不当，维护成本很高），但数据库是这方面的最后一道防线（我在社区中了解到）。

无论如何，如果我们永远不必改变实体之间的基数，我们需要有自由裁量权。在之前创建的 1-1 关系中，我/我作为专业人士会咨询我的客户并询问他/她认为他/她的公司未来会如何发展。

---

最后一点（好像我还没有谈过很多……哈哈），我想说的是，我在这里使用的关于数据建模的符号和知识与许多国家的许多人的看法有些不同。

例如，当我谈到 1-N（或 N-1）个关系时，我并没有考虑到 1 方的基数可能为零。许多人使用其他符号，例如 0...N 或 (0,3) 等。这些符号不是废话，它们是官方的，用于以相同的方式对数据进行建模。

我希望我已经向某人花费了一些经验，我对此感到满意。我们都是专业人士，但我们都是同事，我们在这里的目的是相同的：交流知识。如果有人有任何问题，请发表评论，我会回答。谢谢收听。

编辑 2

评论中提出了更多有趣的问题。我不得不同意，在我的第一篇文章中，我的表达方式在某些人看来可能毫无意义。但他们不是。我提出的是我在多年课程中学到的规则。

我在我的国家学到的方法是，在 ER 图中，我们有 3 个建模数据的发展阶段。这些阶段由其原作者 Peter Chen 正式确定。尽管如此，多年来人们仍然看到需要存在第四种模型，称为描述性模型。该模型通过说明需要解决的现实世界的情况/案例来揭示问题/背景。在这种情况下，您的客户/客户需要什么。

存在的需求出现了，因为通常更多的专业人士可以工作或开始从事一个项目，他/她必须知道他/她在做什么，通常，只看最终的图表是不够的。总之，这个模板作为一个起点，既可以用于开发，也可以用于理解问题。

一旦你掌握了描述所有客户需求的模型，你就会忠于它，并进入下一个开发阶段，从而启动概念模型。

对于概念模型，许多专业人士（如我所见）使用不同的技术和设备进行开发。在学习过程中，我从老师那里了解到，从一种情况/问题/上下文到概念模型的转换必须遵循规则。这些是我在原帖中提到的规则。

为什么我们必须遵守这些规则？

因为我们不会开始猜测，也不会胡说八道。

为概念模型识别实体的规则是什么？

当我们在现实世界中拥有具有属性/属性的东西时，就会识别出实体，并且我们必须保留这些属性。简单实体通常用名词来表示。但并非在所有情况下我们都有名词名称的实体。

出于什么原因，实体必须具有要添加到模型的属性？

因为我们通常可以通过这种方式识别没有属性的实体，但是当我们分解它时，我们最终会得到没有列的表，没有持久化的数据，这些表通常只有外主键。

请注意，这通常可用于创建事物的子类型，例如个人、法人实体、车辆、汽车、摩托车等。但根据情况，这可能是有害的，因为添加新类型意味着模型、数据库、银行规则、使用它的系统等方面的变化。

这就是我提到划分实体的原因，因为这是一种创建事物类型和子类型的技术。

不过，我可以设置实体吗？

是的。该模型是您的，如果您应该或不应该以另一张桌子结束，这取决于您的观点。

你能举一个识别实体的例子吗？

假设我们有一家汽车租赁公司。我们的客户与车辆一起在系统中注册。每个客户/客户都有姓名、联系方式、地址等。每辆车都有型号、卡/牌/牌（我真的不知道这里给你翻译的）、年份等。

我们可以在这里轻松找到两个实体：

• 车辆
• 顾客

为什么？

• 他们有属性。
• 上下文/情况/问题/客户端要求将它们持久化在数据库中。

你能告诉我一个我们可以以错误方式定义实体的上下文吗？以防万一，您能否向我展示一个仅设置无属性实体很危险的上下文？

想象一下，我们有一家超市。同样，我们在这家商店注册了客户。但是，我们的超市销售给个人和法人实体。

如果您无法正确识别此处的类型，您可能会遇到问题。

为什么？

如果我们只需要保留我们销售的客户类型，那么这种类型最终会成为一个属性，而不是一个实体。如果客户/客户类型的属性有些不同，有些相同，那么我们就有了分区。我们将有一个超级“客户”实体和两个依赖实体：

• 个人
• 法人实体

为什么？

• 您最终可能会得到额外的表，这些表没有要保留的相关属性。
• 以这种方式更容易查看关系和属性。
• 将来进行维护变得更加实用，花费的时间更少，成本更低。

对...我如何识别关系/关系？

这取决于上下文。您需要查看：

• 两个实体以某种方式相关？
• 我需要坚持这个吗？

如果这两个问题的答案都是肯定的，那么请确保我们在这里有关系，我们需要在图表中表示它。

你能举个例子吗？

同样，以汽车租赁公司为例，假设您必须保留/保存/持久/注册/记住由有车辆的客户进行的租赁事件。

如果我们现在有两个实体已经定义了我们的上下文，它表示它们之间发生了一个事件。提到的事件是租金。看一看，这是一种关系，我们要这样坚持下去。

这两个实体能否在它们之间创建其他类型的关系？

这将完全取决于上下文。而不是租车事件，还需要坚持谁舔了车？所以这是一个事件，一种关系（奇怪，但确实如此）。请注意，决定关系的是上下文。

那么属性呢，我怎样才能正确定义它们呢？

最初，属性属于实体。属性表示需要持久化的实体的特征。你不应该把属性：

• 如果它们不应该被持久化（它们没有出现在上下文中，也没有被客户端请求）。
• 如果它们在逻辑上不属于一个实体。例如，将属性价格放在客户实体中，而不是将其放在产品实体中。

您说“最初”属性属于实体的原因是什么？

因为属性也可以存在于关系中，但是当它们存在时，它们就存在于 NN 关系中。

为什么？

同样，这是一条规则，这已在我的第一版中进行了解释。

根据您的研究，Peter Chen 创建并正式发布的 3 种模型之间有什么区别？

• 在概念模型中：在这里我们必须定义实体、属性和关系。
• 在逻辑模型中：一旦前一个模型准备好，这个模型就会显示所有内容的分解版本。解决了关系（1-N、N-1 和 NN、聚合、分区、递归关系）以及特殊属性（功能冗余、多值属性）。一切都变成实体（实际上是表格），所有关系都以 1-N（或 N-1）结尾。
• 在物理模型中：在上一阶段已经设置好所有内容后，现在将实体的名称修改为它们在表中的版本以及它们的属性。除此之外，它的属性现在显示将使用的数据库中存在的原始数据类型。绘图图本身呈现另一种外观。更像这样的东西。

你能对任何数据库、任何真实世界的情况进行建模吗？

是的。

您是否考虑到数据不一致和不恰当地创建其他结构？

是的。所有这些都被考虑在内。只是您遵循这些类型的规则这一事实已经使数据库设计为不创建和启用/允许结构或失败的关系。

简而言之，你只创造你需要的东西，不允许人为错误，把东西放在错误的方式/地方。

如何？

所有这一切都在上面解释过，所有已经说过的。我不会在这里重复自己。你只需要阅读。

如果您需要更轻的东西，请问，告诉我您有疑问的地方，我会让它更清楚。

出于什么原因，您再次编辑了答案？

正如我所说，我认为在我的第一个原始回复中，我不是很清楚，正如评论的那样。这个版本应该：

• 澄清不清楚的地方。
• 给出实际情况和案例的例子。
• 表明我所说的一切都是有根据的。
• 更详细地显示数据建模的初始步骤。
• 展示我是如何在我的国家学到的。
• 分享更多的知识/信息，我相信这是这个社区的目的。