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

Converting an ER diagram with 2 relationships between 2 entities to a RM Schema

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

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

我试图以玩家可以是团队成员或团队可以有 只有一个 领导或队长的方式来解决这个问题。

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

create table team (
    team_name varchar(30) 
        primary key, 
    captain_name varchar(50) 
        foreign key references player(name)
    );

create table player (
    name varchar(50) 
        primary key, 
    team_name varchar(30) 
        foreign key references team(team_name)
    );

这种方法是否正确，或者我必须创建两个以上的 table？

Is this approach a correct one or I had to create more than two tables?

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

I want to convert an ER diagram to RM Schema

简而言之，你不能。当然会有问题。

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

实体关系 • 不受约束

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

这超越了 "theoreticians" 作为 "relational" 推广和营销的 1960 年代的记录归档系统。这种原始系统以每个文件上的 Record ID 为代表，声明为 "key"，这让任何人都感到困惑，因为它具有 Key 的 none 属性，更不用说一个关系键。

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

你有这个：

这有各种问题，这是您正在学习的原始 RFS 的典型问题。如：

分配给球队的队长不受限于那个球队（它允许任何球员成为任意队的队长)
Player 绝对是 Dependent，一个 Player 除了他参与一个 Team 之外是不存在的（它允许 Independent Players）。
所有关系都是 非识别（虚线），典型的碎片化系统，其中每个 table 都被错误地声明为 "independent".

实体关系 • 关系

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

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

DDL

同样，现在创建 table 还为时过早，但由于您正在考虑：

CREATE TABLE team (
    team     CHAR(30)  NOT NULL, 
    captain  CHAR(50)  NOT NULL, 
    CONSTRAINT pk
        PRIMARY KEY ( name ),
    CONSTRAINT  captains 
        FOREIGN KEY     ( team, captain )
        REFERENCES team ( team, player )
    )

CREATE TABLE player (
    team    CHAR(30)  NOT NULL,
    player  CHAR(50)  NOT NULL,
    CONSTRAINT pk 
        PRIMARY KEY ( team, player ),
    CONSTRAINT consists_of 
        FOREIGN KEY     ( team )
        REFERENCES team ( team )
    )

虽然像 name 这样的列名对于属性来说是正确的，但对于 标识符 来说是不正确的，它应该根据它所标识的事物来命名，例如team、player等。
- 如果table team有一个属性name，与短标识符team分开，当然会被命名为name.

符号

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

_{The basic idea is that ... each diamond gets a table.}

废话。

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

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

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

首先，每颗钻石需要确定并命名（未命名的钻石证明它没有解析）。这将是一个很好的开始，重新审视它到底是什么。
- 未解决的关系可以确认为关系，已解决。该名称将是一个 VerbPhrase，从父项 (1) 读到子项 (n)。
- 未解决的关系可能会变成 table。名字会是一个名词，因为它已经变成了一个事物，而事物是用名词命名的。
- 这是你的 ERD 的样子，当它停留在那个阶段并进行时（只是命名的钻石，尚未解决），自己检查一下 Progressed ERD。
每个多对多关系，例如：
a Fan 跟随 0 到 n Players，并且
a Player 后跟 0 到 n Fans
仍然是 n 对 n 的关系
- 它是实施的（意思是稍后，在模型坚如磐石并准备实施的时候）作为关联Table PlayerFan。
- 在建模时，它仍然是 n 对 n 的关系，钻石被移除，表示分辨率。
每个一对多关系，例如：
每支球队由 0 到 n 名球员组成
始终保持关系，而不是table。钻石被移除。
当然，一对多关系可能会发展为table ...但这是进一步建模的结果，几次迭代后，将模型中的其他项目考虑在内，此时不是自动 "conversion"。

_{这就是为什么我们不在现实世界中使用 ER 建模，我们使用专为关系建模而设计的东西，它可以轻松处理诸如键之类的关系特征，消除 "conversion"以及随之而来的废话。}

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

Converting an ER diagram with 2 relationships between 2 entities to a RM Schema

entity-relationship

relational-database

实体关系 • 不受约束

实体关系 • 关系

DDL

符号

评论