使用对象角色建模 (ORM) 的关系模型中的动态类型

Posted 2023-04-12

【中文标题】使用对象角色建模 (ORM) 的关系模型中的动态类型

【英文标题】：Dynamic Types within a Relational Model using Object-Role-Modeling (ORM)

【发布时间】：2009-06-06 21:37:06

【问题描述】：

在对象角色建模 (ORM) 中，给定一个 thing 实体，该实体与 type 实体有关系，并且类型实体可以指定为存在和事物实体可以具有出生日期值，如果与事物关联的类型实例未设置为活动，我将如何指定一个约束，该约束将排除事物实例具有出生日期值。见下图...

ORM Diagram of Model to be constrained http://img197.imageshack.us/img197/6551/dynamictypeorm.jpg

我的问题背后的目的是在不清楚类型是什么但类型的特征已知时允许对系统内的类型进行建模。如果您认为有更适用的方法，则您的答案不需要使用 ORM。感谢您的阅读，希望您能帮到我。

【问题讨论】：

我认为答案可能与涉及连接的集合比较约束有关，Terry Halpin orm.net/pdf/JoinConstraints.pdf在这篇论文中介绍了这一点

那篇论文中的材料以更新的形式出现在“The Book”中。请参阅下面的我的编辑。

【参考方案1】：

约翰·桑德斯推荐的这本书是我读过的最好的书之一。此外，您的所有 ORM 问题很可能都可以通过阅读来回答。

不过，为了直接回答您的问题（并回避有关模型有效性的任何问题），我认为有两种明显的方法可以按原样约束它。

我们可以使用子集约束或等式约束，具体取决于您实际想要捕获的内容。

在角色之间分配一个相等约束（Right），我们可以生成一个约束，从概念上讲，任何有生命类型的事物都有一个出生日期，并且任何有出生日期的事物都是有生命的类型。

在角色之间分配子集约束（左），我们可以约束模型，使得任何具有 DateOfBirth 的类型的事物都必须是活的类型。与等式约束不同，这将允许事物具有生命类型，但没有出生日期。

补充： 要创建这些类型的子集和等式约束，我们需要使用称为'Join Path' 的东西。使用连接路径，我们可以创建一个 Join-Subset Constraint 和 Join-Equality 约束，它将跨越约束两侧的多个角色。 Examples 的连接路径有时很明显且易于遵循。但有时也会有点overwhelming 和复杂。另外值得注意的是，尽管 NORMA 确实支持创建连接路径，但在相等、子集和排除约束中，它们的详细说明并不是 100% 完成的，正如 here 所解释的那样。这也是目前使用子集更容易的原因之一，因为从概念上更容易验证模型的正确性。

在为子集、相等或排除约束分配角色时，要在 NORMA 中创建连接路径，首先通过单击分配属于路径的所有角色，然后双击以移动到下一个路径。当约束能够连接路径时，该约束中涉及的角色将被标记为 [#.#] 而不仅仅是 [#]。因此，当我们创建约束时，我们可以在这里说角色 [1.1]&[1.2] 是角色 [2.1]/[2.1] 的子集/等于。请注意，在每个角色中发挥作用的事实也必须匹配。所以他我们从 NORMA 得到了一个口头表达： 如果某些事物有一些 DateOfBirth；某些事物属于某种类型，那么该事物属于某种类型；那个Type是活的。 更好的说法是：如果某种类型的某些事物具有某个 DateOfBirth；那么那个 Type 是活的。

但是，我们可以通过第三种（也是更可取的）方法来限制这一点，那就是子类型化。因为活着的东西和不活着的东西有很大的不同，我们可能不希望将它们映射到同一个表。在这里，我们将 Type fact 拆分为两个子类型，OrganicTypes 和 NonOrganicTypes。两个子类型之间的 Exclusive Or 约束告诉我们，每种类型要么是有机的，要么是非有机的。 Note 告诉我们用于确定类型属于哪个组的派生规则。 从那里，我们将我们的 [Thing is of Type] 角色重新定义为 [LivingThing is of OrganicType]。并且由于定义上的 OrganicThings 能够生命，我们对 DOB/is living 的约束现在已内置到模型中。

【讨论】：

我无法让 NORMA 喜欢您的前两个模型中的任何一个。您能否编辑答案以包括子集和等式约束的语言化？此外，更重要的是，你能发布你是如何让它如此完美地对齐的吗？ ;-)

当您在 NORMA 中选择了 ORM 模型的任何元素时，会出现“格式”菜单项。热键也很有用，ALT+O+A+C 垂直居中元素，ALT+O+A+M 水平居中元素。我还将编辑我的帖子以解释我在前半部分使用的连接路径。

另外，在拖动元素或角色时，按住 shift 键会强制元素沿当前 X/Y 轴移动。

啊哈，你成功了！向你致敬！我确实有这本书，我正在努力通过它。我的最爱之一。谢谢一百万！

【参考方案2】：

实际上，您的模型存在不止一个问题，即使它很简单。如果一个事物曾经活着，它可能有一个出生日期。它可能曾经是活的，但现在已经死了。

此外，您需要澄清“类型存在”这一事实的缺失是否意味着“类型不存在”（封闭世界假设），或者它是否仅意味着“类型不知道存在”（开放世界我认为是假设）。

我还有一个担忧是，您的问题似乎有些混乱，将“关系模型”和“ORM”结合在同一个“句子”中。对象角色建模是一种概念建模工具，用于创建概念模型，然后可以将其映射到关系模式。即使您正在对现有的关系模式进行逆向工程，最好只使用模式作为您将用于创建正确概念模型的信息的一部分。此外，使用有效输入和输出的示例，并与领域专家进行讨论。这通常会帮助您发现关系模式未捕获或捕获不正确的重要约束。

---

顺便说一句，有关出色的 ORM 工具，请参阅 NORMA。它是 Visual Studio 2005 或 2008（标准版或更高版本）的插件，并使用现代 ORM2 表示法。它可以为多个不同的数据库生成 SQL，以及 ER 图甚至代码。

---

另外，请参阅本书：

【讨论】：

这是我的担心，模型可以根据人们对用于描述它的词语的理解进行解释，而不是根据模型内的关系来定义这些词语。如果我能够指定我要问什么，那么解释模型的唯一方法就是只有具有生命类型的事物的实例才能具有 dob，这意味着生命是指事物活着而不是当前活着的事实。如果是这种情况，我可能希望根据生活状态需要它，这会产生另一个问题:(谢谢

关于概念模型的一件事是，它们在处理真实概念时会做得更好。您似乎已经抽象了一组情况，以便获得适用于所有情况的答案。我建议您使用更具体的模型，并为更具体的模型提出解决方案。概念建模工具将帮助您使具体模型正确。

我同意不那么抽象的类型是理想的，但在它们可能无法获得的情况下，我希望仍有办法完成适用的设计。我想了想，我建议唯一不能在概念上建模的领域是与自己冲突的领域。在这种情况下，我的目标无论多么懒惰，都应该是现实的。

我想我只是没有做概念模型的经验，其中概念无法澄清或相互冲突。如果模型不被理解，我认为不可能创建一个有效的模型。

2019 年更新：NORMA 现在可用于 Visual Studio 2019 社区版。ormfoundation.org

【参考方案3】：

在数据库上下文中，假设您有三个单独的表，我将创建一个函数来计算实体及其类型之间的连接中的行数。在持有 DOB 的表中使用此函数，以确保 DOB 为空或计数为 1。

伪代码：

 function fn_count_living(id)
     declare @count int
     select @count = count(*)
     from entities inner join types on entities.typeid = types.id
     where entities.id = id and types.living = 1
     return @count
 end

约束

 fn_count_living(entity_id) = 1 or dob is null

【参考方案4】：

据我了解，ORM（和domain model）都是conceptual model，用于分析业务领域，而不是设计解决方案。在这一层，引入“类型”或“动态类型”等概念为时过早，不适合模型的目的。

来自Object Role Modeling: An Overview

alt text http://i.msdn.microsoft.com/Aa290383.dv_vsea_ormoverview_06%28en-us,VS.71%29.gif

您可以在“活着”和“有出生日期”之间放置等式约束（带圆圈“=”符号的虚线）。类似于“被聘用”和“被承包到”。

【讨论】：

我的目的是帮助澄清业务领域。但是为了有效地这样做，ORM不应该让我说一个东西只有在它存在的情况下才能有一个dob？如果我要与业务用户验证我的问题中的图表，他们将不会意识到我的意图是只允许具有 DOB 类型的事物。

@eed3si9n：这不是一个紧密的类比，因为在您的示例中这两个角色都由同一个实体扮演，但在他的示例中却不是。