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

Question

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

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

• name

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

• name
• [type（Type.name）

因此，例如，cutting vegables的结果将既是有机废物又是可烹制的蔬菜（因此有2个结果）。 boiling还会有2个结果：煮熟的食物和开水（通常可以除去开水，但这是该步骤的结果）。

[现在，我想描述一个配方，这意味着它有几个ActionType，但是Result的ActionType是下一个的输入。因此：

我可能有一个Recipe实体，它由]组成>

CookingStep s，它链接到ActionType-了解步骤是什么，以及该步骤是哪种Results。CookingFlow，可以是下一个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关系中看到了冗余，但是也有可能“欺骗”：类型为CookingStep的cut vegables可以与具有CookingFlow的result有关系] boiling water或boiled food。我希望禁止作弊。

问题是：如何正确建模？

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

我正在寻找一种对4个表进行建模的方法，以使其保持一致。表中的2种是“枚举++”类型：它们描述了可能的情况。其他2个都是'...] >>

您似乎希望结果导致烹饪步骤的操作类型具有其烹饪流程的结果类型作为结果类型。您似乎在寻求一种声明性的方式来表达这种约束，可能是对此设计进行了一些改动。

添加到烹饪步骤和结果中，成为步骤的类型-将其与oftype结合在一起/联接。现在，参与/ FK按关联实体（步骤，类型）进行。在烹饪流和结果中添加流的类型-通过其与ofresulttype的结合/联接来替换它们。现在，参与/ FK按关联实体（流程，类型）进行。 Add在结果中具有关联参与/ FK。

我们已经将类型关系/表进行AND /连接的关系/表的新版本具有“冗余”的类型数据，它已经在类型表中。但这允许通过SQL的（错误选择）声明性约束而不是通过触发器来约束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 joinsGroup dependency SQL design

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

PS在RM（关系模型）和ERM（实体关系模型）下，可以用表或它们所代表的关系（船）/协会进行交谈。 DB表FK对应于关系中的ER组参与。当子行唯一地出现在其他地方时，即当一起参与的iff实体在其他地方一起参与时，FK约束成立。

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

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

Answer 1

您似乎希望结果导致烹饪步骤的操作类型具有其烹饪流程的结果类型作为结果类型。您似乎在寻求一种声明性的方式来表达这种约束，可能是对此设计进行了一些改动。

添加到烹饪步骤和结果中，成为步骤的类型-将其与oftype结合在一起/联接。现在，参与/ FK按关联实体（步骤，类型）进行。在烹饪流和结果中添加流的类型-通过其与ofresulttype的结合/联接来替换它们。现在，参与/ FK按关联实体（流程，类型）进行。 Add在结果中具有关联参与/ FK。