将具有 2 个实体之间的 2 个关系的 ER 图转换为 RM 模式答案

【问题标题】：Converting an ER diagram with 2 relationships between 2 entities to a RM Schema将具有 2 个实体之间的 2 个关系的 ER 图转换为 RM 模式
【发布时间】：2019-10-31 15:43:59
【问题描述】：

我想将 ER 图转换为 RM Schema，但我遇到了问题。我有 2 个实体，它们之间有 2 个关系（团队和玩家实体）。我该怎么办？ ER图是这样的：

我应该为每个关系创建一个单独的表吗？

我试图以一种方式来解决这个问题，即一名球员可以是球队的一员，或者球队可以有一个队长或队长。

考虑到上面所说的，我这样做了：

创建表团队（
    团队名称 varchar(30)
        首要的关键，
    船长姓名 varchar(50)
        外键引用播放器（名称）
    );

创建桌面播放器（
    名称 varchar(50)
        首要的关键，
    团队名称 varchar(30)
        外键引用团队（team_name）
    );

这种方法是正确的还是我必须创建两个以上的表？

【问题讨论】：

请不要要求我们重写您的教科书。此外，很多人都有，所以这是一个常见问题解答。请询问 1 个明确的特定非重复研究问题。请参阅How to Ask，点击谷歌搜索“stackexchange 作业”和投票箭头鼠标悬停文本。 PS 基本思想是每个盒子和每颗钻石都有一张桌子。但是您的教科书可能需要针对特殊情况进行某些重新排列。 PS给你一个程序要遵循。跟着它。不要担心你碰巧注意到的事情。该过程是根据您需要解决的问题进行组织的。

标签： relational-database entity-relationship

【解决方案1】：

这种方法是正确的还是我必须创建两个以上的表？

对于您提出的具体问题，该方法是正确的，但它不是关系型（注意标签），因此它缺乏适当或预期的约束。

我想将 ER 图转换为 RM Schema

简短的回答是，你不能。当然会有问题。

在早期阶段的实体-关系级别建模时，可以做的事情是有限的。最终，您必须在 Table-Key-Attribute 级别进行建模，其中可以确定和定义每个项目的更多属性。尽管第一步可能被称为“转换”，但它还不足以实现（由“模式”暗示）。
ER 建模真的很原始，它不用于现实世界中的关系建模。
- 关系建模的正确方法是IDEF1X，自 1984 年起可用，自 1993 年起作为标准。可以通过表的相同阶段进行；表键；表键属性。 Relational Modeling 拥有全套的 Relational 文章，例如 Independent vs Dependent 表；正确处理复合键；识别与非识别关系；等等，ER建模完全不知道。
- 很遗憾，没有教授关系建模，而是教授原始的关系前方法 ER 建模。
- 不能从 ER 级别转到已解决的关系建模级别（由“RM Schema”暗示），因为它没有关系表具有的属性，可以在关系建模中定义。
- 一个人必须从最终的 ER 级别到早期的关系建模级别，然后进展到完全解决，才能达到关系架构级别。
- 如果从一开始就使用关系建模，则消除了从一种建模方法到另一种建模方法的“转换”步骤，并且不会遇到 ER 建模的限制。最终结果，即完全解析的模型，是一个关系模式。

实体关系 • 不受约束

首先让我说，您使用有意义的键非常好，它们是合乎逻辑的，因此是关系的。

这超越了 1960 年代的记录归档系统，这些系统被“理论家”推广和推销为“关系”。此类原始系统以每个文件上的 Record ID 为代表，声明为“密钥”，这让任何人都感到困惑，因为它没有任何密钥的属性，更不用说关系密钥了。

但是，您还没有完整的关系上下文，您没有使用复合键，因此您的模型缺乏关系完整性；关系力量；以及符合 E F Codd 博士的关系模型的模型所具有的关系速度。换句话说，您可能不知道关系数据库中的可能性，或者关系数据库的基本要求是什么。

你有这个：

这有各种问题，这是您所学的原始 RFS 的典型特征。如：

分配给团队的队长不受那个团队的限制（它允许任何玩家成为任何的队长团队）
玩家绝对是独立的，玩家除了参与团队之外不存在（它允许独立玩家）。
所有关系都是非识别性（虚线），这是碎片系统的典型特征，其中每个表都被错误地声明为“独立”。

实体关系 • 关系

如果我们将其提升为关系：

团队是独立的
- 团队PK是（团队）
玩家依赖团队
- 玩家PK是（团队，玩家）
- 关系
  团队由 0 到 n 个玩家组成
  是识别（实线）
现在，队长在 Team 中的 FK 是 Player ( Team, Player ) 中引用的 PK
- 其中Team就是Team PK
关系
玩家队长 0 或 1 队（相对于不受约束的 0 到 n）
现在受到影响，因为付款人只属于一个团队

DDL

同样，现在创建表还为时过早，但既然您正在考虑这样做：

创建表团队（团队 CHAR(30) NOT NULL, 船长 CHAR(50) NOT NULL, 约束pk 主键（名称），约束队长 FOREIGN KEY（团队，队长）参考团队（团队，球员） ) 创建表播放器（团队 CHAR(30) NOT NULL, 播放器 CHAR(50) NOT NULL, 约束pk 主键（球队，球员），约束由_of 外键（团队）参考团队（团队） )

虽然name 之类的列名对于属性是正确的，但对于标识符 则不正确，标识符 应该以其所标识的事物命名，例如team、@ 987654330@等
- 如果表team有一个属性name，与短标识符team分开，那肯定会被命名为name。

符号

我所有的数据模型都在 IDEF1X 中呈现，这是自 1993 年以来为关系数据库建模的标准
我的IDEF1X Introduction是初学者的必备读物

_{基本思想是……每颗钻石都有一张桌子。}

废话。

在 ER 建模的那个阶段，每颗钻石代表一个未解决的关系，而不是一张表格。没有“转换”，它不是一个定义的步骤（这只是推动 ER 建模的人必须切换到真正的建模方法的点，正是因为 ER 建模受到严重限制）。建模的目的，不管是否使用ERD；或IDEF1X；或彩色珠子，是对文章的渐进理解，即。从未解决进展到已解决。

这是一个智力过程，而不是文书过程。

因此，在 ER 建模的那个阶段（您的图表），为了进入下一阶段，每个钻石都需要解析。也就是说，ER 图在 ER 建模上下文中甚至都不完整（同样，还远未准备好实施，或“转换”为关系建模方法）。

第一件事是，每颗钻石都需要被确定和命名（一颗未命名的钻石证明它没有被解析）。这将是一个很好的开始，因为它实际上是什么。
- 未解决的关系可以确认为已解决的关系。名称将是一个动词短语，从父级 (1) 读取到子级 (n)。
- 未解决的关系可能会变成一个表。这个名字会是一个名词，因为它已经变成了一个事物，事物是由名词命名的。
- 这是您的 ERD 的样子，当您停留在那个阶段并继续进行时（只是命名的钻石，尚未解决），请亲自检查一下 Progressed ERD。
每个多对多关系，例如：
Fan 跟随 0 到 n Players，并且
Player 后跟 0 到 n Fans
保持n对n的关系
- 它实现（意思是稍后，在模型坚如磐石并准备好实现的时候）作为关联表PlayerFan。
- 在建模时，它仍然是 n 对 n 关系，钻石被移除，表示分辨率。
每个 一对多 关系，例如：
每个团队由 0 对 n 玩家组成
始终保持关系，而不是表。钻石被移除。
当然，1 对多 关系可能会发展到表格...但这是进一步建模的结果，经过多次迭代，采用模型中的其他项目考虑到这一点，而不是自动“转换”。

_{这就是我们在现实世界中不使用 ER 建模的原因，我们使用专为关系建模而设计的东西，可以轻松处理键等关系特征，消除“转换”和随之而来的废话。}

【讨论】：

实体关系 • 不受约束

实体关系 • 关系

DDL

符号

评论