Class 关于UML类模型中的1对1关联

在UML建模中，我们经常遇到类模型，它们表示给定类之间的1 x 1或1 x 1..*或1..*x 1或1..*x 1..*关联

举个例子：玩家1..11x1队

这难道不会带来一个实际问题，在这个问题上，不可能确定什么是第一位的：球队还是球员？ 在这个例子中，一个团队至少需要一个玩家才能生存，而一个玩家要生存，就需要这个团队。 我是不是误解了什么

尝试实现它时，您将无法实例化一个团队，因为您至少需要一个玩家，如果您尝试实例化该玩家，团队将丢失

1 x 1关联如何可能

---

谢谢你抽出时间

当一个模型是1..11关系（

团队

-

玩家

）时，没有“先来的是什么”。需要有11名

玩家

s，他们可以连接到一个

团队

。只有当所有连接都完成时，您才具有符合要求的模型。你可以指出球员通过增加一个组合组成一个团队。但通常从编程的角度来看，这并没有增加多少语义。为了创建连接，您仍然需要有实例。因此，

团队

可能会有11个

玩家

的数组，为了工作，其中任何一个都不能为

Null

---

1..1关系（插头/插座）也是如此。只有当它们连接在一起时，您才有一个符合要求的模型。从建模的角度来看，如果您需要两个类之一的背包，通常会使用1..1。然后用单独的信息绑定另一个。然后，可以将其与只对该内容感兴趣而对载体本身不感兴趣的其他类一起使用。

您是正确的。您必须以某种方式满足所有约束。要么立即创建所有内容，要么放松约束。例如，一个团队仍然可以作为一个没有任何球员的团队存在，但是一个团队必须存在，才能有球员加入

您的问题“1 x 1关联如何可能？”指的是强制相互反向引用的问题，或者，用DBMS术语来说，循环外键的问题，这可能确实会在数据管理应用程序或其基础数据库（DB）中产生对象/行创建或更新问题

有两种方法可以解决此问题：1）至少在一个方向上放松强制引用约束，2）允许中间app/DB状态不必满足约束

1） 虽然我们知道在现实中，一个团队总是包含超过零个玩家，但出于实际原因，我们可能会选择不实现此约束，这样我们就可以更轻松地创建团队数据对象（或DB行），而无需立即为其分配玩家对象/行

---

2） 在我们的应用程序中，我们可能会允许一个中间状态，其中创建了一个团队，没有为其分配任何玩家，相应地，在底层数据库中，我们可能会指示事务管理器，只有在整个事务完成时才检查外键约束（包括首先创建一个空团队，然后创建11个参与者，这样每个人都被分配到团队，团队作为他们的团队被分配给他们）完成。这可以通过SQL子句

DEFERRABLE Initial DEFERRED

实现，请参阅文章“DEFERRABLE SQL Constraints in Depth”一节.

这取决于它是什么类型的模型。UML模型可能是真实世界的模型，例如，人的手与人的手臂有1:1的关系。这种1:1的关联建模了一个生物学事实（忽略残疾）

UML模型也可能是应用程序功能的模型。如果应用程序强制要求每个团队有11名参与者，每个参与者有一个团队（例如，通过填写带有“保存”按钮的表单一次创建所有参与者），则1:11关联正确地建模了应用程序的功能

UML模型也可能是某些编程语言中的类或数据库中的表的技术模型。在这种情况下，只有当您的编程语言或数据库系统允许同时或至少在同一事务中创建两侧的实例时，才可能使用1:1关联

边注：当建模团队和玩家时，你可以考虑团队和人之间的关联，在团队方面具有多重性0…*和角色名称“玩家”。