如何建模 2x2 实体（关系表），其中 2 个描述“模型”，2 个是“具体化”？答案

【问题标题】：How to model 2x2 entities (relational tables), in which 2 describe the 'model' and 2 are 'concretizations'?如何建模 2x2 实体（关系表），其中 2 个描述“模型”，2 个是“具体化”？
【发布时间】：2020-03-12 14:26:43
【问题描述】：

我正在寻找一种方法来对 4 个表进行建模，以保持它们的一致性。其中 2 个表是一种“枚举 ++”类型：它们描述了可能的情况。另外两个都是“类型”表的具体化。一个简单的例子:)：

ActionType：描述可能的“动作”类型，例如切蔬菜，做饭，...

name

ActionTypeResult：描述每个Type的动作结果

name
type (Type.name)

因此，例如，cutting vegables 的结果将是有机废物和可烹饪的蔬菜块（所以 2 个结果）。 boiling 也会有 2 个结果：熟食和沸水（你通常会摆脱沸水，但这是该步骤的结果）。

现在，我要描述一个配方，这意味着它有多个ActionTypes，但ActionType 的Result 是下一个的输入。所以：

我可能有一个Recipe 实体，它包含

CookingSteps，链接到ActionType - 知道它是哪种步骤，以及该步骤具有哪种Results。 CookingFlows，这是Results（产品），可以作为下一个CookingStep的输入。

所以，可以这样做：

Recipe:

name

CookingStep:

recipe (Recipe.name)
title（嗯，你可以给这些步骤命名，取决于配方:)）

CookingFlow:

step（CookingStep.title，这是流量的来源）
recipe（Recipe.name，不确定我们是否真的需要它，因为我们知道它是因为它已经由 step 链接，我没有包括在下图中）
result（ActionTypeResult.name，所以知道我们在谈论哪些不同的流程）
flows to（CookingStep.title，所以我们知道它的流向）。

现在，这样做，我在 recipe 关系中看到了冗余，但也有可能“作弊”：cut vegables 类型的 CookingStep 可以与具有 @ 的 CookingFlow 建立关系987654363@boiling water 或boiled food。我希望禁止这种作弊行为。

问题是：如何正确建模？

问题在于它可能导致数据不一致（作弊）。我遇到的主要问题是：有一定的 CookingStep，我既有 ActionType 又有 CookingFlow。这可以。但是，在这种情况下，我在 CookingFlow 中的 ActionTypeResult 必须是 CookingStep 定义的 ActionType 允许的。我希望在同一 CookingStep 的 CookingFlow 上强制执行正确的 ActionType。我可以使用数据库上的触发器来检查这是否正确；我主要想知道是否可以在没有触发器的情况下对其进行建模。

【问题讨论】：

您的问题到底是什么？--正确建模什么？问题是什么？什么是“配方关系中的冗余”？为什么不好？什么“看起来不对”？什么是正确的”？使用足够多的单词、句子和对部分示例的引用来清楚完整地表达你的意思。 PS 将单词放在吓人的引号中并不能阐明您没有通过实际说出您的意思来阐明的特殊含义。（对于“作弊”，你举了一个例子，但不要说它是什么例子。）
请通过编辑而非 cmets 进行澄清。 PS你还是不清楚。术语“'enum++'类型”来自哪里？为什么引号？究竟是什么“种类”？您仍然在给出示例而没有明确说明它们是什么示例。什么是“具体化”——不清楚。引号中的“作弊”——未定义——后跟一个例子——究竟是什么？ “基本上”或“基本上”或“换句话说”等没有引入或总结您也给出的清晰、准确和完整的描述，只是意味着“不清楚”。 “所以，例如”——一个什么例子？什么是“
通过编写简明的用户手册来清楚地使用这个数据库。在给出业务关系（船舶）/关联或表（基础或查询结果）时，说明其中的一行根据其列值说明了业务情况。 PS有很多图表样式。给出一个图例或参考。但是：use text, not images/links, for text--including tables & ERDs。将图像用于无法表达为文本或增强文本的内容。 PS重新询问：询问您在教科书/参考资料之后的第一个问题，并给出需要询问的内容。
感谢您的回答，但似乎我无法清楚地表达它，也无法用图像或文字表达。它不仅仅是关于子类型/继承/多态性。我知道这些是如何工作的。这是可以在教科书中找到的东西，所以我不需要回答这个问题:)。我不是在谈论这里的表，或者 SQL，或者......它是关于一个信息模型。我还不关心 FK 和 PK。那是实现细节。在决定要使用的技术之前，我首先希望得到正确的模型。但又一次，我似乎无法很好地表达自己。不过，感谢您的尝试。

标签： database-design relational-database relationship erd

【解决方案1】：

您似乎希望导致烹饪步骤的操作类型具有其烹饪流程的结果类型作为结果类型。您似乎正在寻求一种声明性方式来表达该约束，可能是在此设计的变体中。

添加到烹饪步骤并生成步骤的类型 - 将它们替换为它们与 oftype 的连接/连接。现在参与/FK 由关联实体（步骤、类型）组成。添加到cookingflow 和resultsin 流的类型——将它们替换为与ofresulttype 的连接/连接。现在参与/FK 由关联实体（流、类型）组成。 Add 在结果中具有关联参与/FK。

我们已经与/连接类型关系/表的新版本的关系/表具有“冗余”类型的数据——它已经在类型表中。但这允许通过其（可怜的选择）声明性约束而不是通过触发器在 SQL 中进行约束。这些声明不仅适当地限制了赋予旧设计的新设计的投影，而且控制了冗余。但是我们现在必须更新多个表，而过去我们只能更新一个。

How can I enforce second-degree relationships without composite keys?
How do you ensure values from a logging table match objects in other tables ?
Storing “redundant” foreign keys to avoid joins
Group dependency SQL design

PS 您的设计没有键入步骤输入--“ActionType 的结果是下一个的输入”。

PS 在 RM（关系模型）和 ERM（实体-关系模型）下，人们可以根据表格或它们所代表的关系（船舶）/关联来讨论。 DB 表 FK 对应于关系中的 ER 组参与。当子行唯一地出现在其他地方时，FK 约束成立，即当/iff 一起参与的实体在其他地方一起参与一次时。

PS 每个 FK/参与都表征了一种子类型关系——引用/参与值/实体与所有可能的超类型；我们只是不总是将这种子类型称为“子类型”。你显然有明确的子类型——你甚至有充当“类型”标签的值/实体。您只需要用它们的标签来标记实体，这样类型数据就会与实体一起显式呈现，以便通过 FK 约束进行类型检查。

How can you represent inheritance[/subtyping] in a database?
How do you effectively model inheritance[/subtyping] in a database?

【讨论】：