在 UML 建模中，我们经常遇到类模型，它声明给定类之间的 1 x 1 或 1 x 1..* 或 1..* x 1 或 1..* x 1..* 关联。
举个例子：玩家 1..11 x 1 队。
这会不会带来一个实际问题，即无法确定先发生的事情：球队还是球员？ 在这个例子中，一支球队至少需要一名球员才能存在，而一名球员要存在，就需要球队。 我误解了什么吗？
尝试实现它，您将无法实例化 Team，因为您至少需要一个 Player，如果您尝试实例化 Player，Team 将会丢失。
1 x 1 关联如何可能？
感谢您的宝贵时间！
【问题讨论】：
标签： class uml diagram multiplicity
当模型作为 1..11 关系 (Team - Player) 时，没有“先到先得”。需要有 11 个Players，这些可以连接到一个Team。只有当所有连接都完成时，您才有一个符合要求的模型。您可以指出玩家通过添加组合来组成团队。但通常从编程方面来看，这不会增加太多语义。无论如何，您都需要拥有这些实例才能创建连接。所以Team 可能会有一个由 11 个Players 组成的数组，并且为了工作，它们都不能是Null。
1..1 关系（插头/插座）也是如此。只有当它们连接时，您才有符合要求的模型。从建模的角度来看，如果您需要两个类之一的背包，则通常使用 1..1。然后你用单独的信息绑定另一个。然后可以将其与仅对此内容感兴趣而不对载体本身感兴趣的其他类一起使用。
【讨论】：
你是对的。您必须以某种方式满足所有约束。要么立即创建所有内容，要么放松约束。例如，一个团队仍然可以作为一个没有任何球员的球队存在，但一个球队必须存在才能有球员加入。
【讨论】：
您的问题“1 x 1 关联如何可能？”指的是强制相互反向引用，或者用 DBMS 术语来说，循环外键，这可能确实会在数据管理应用程序或其底层数据库 (DB) 中创建对象/行创建或更新问题。
有两种处理方法：1) 至少在一个方向上放宽强制引用约束，2) 允许不必满足约束的中间应用程序/数据库状态。
1) 虽然我们知道在现实中一个团队总是包含多于零个玩家，但出于务实的原因，我们可能会选择不实施此约束，这样我们就可以更轻松地创建团队数据对象（或数据库行），而无需立即将播放器对象/行分配给它。
2) 在我们的应用程序中，我们可以允许一个中间状态，其中一个团队已经创建而没有任何球员分配给它，并且相应地在底层数据库中，我们可以指示事务管理器仅在以下情况下检查外键约束整个事务（包括先创建一个空队，然后创建 11 名球员，每个球员都被分配到球队，球队被分配给他们作为他们的球队）完成。这可以通过 SQL 子句DEFERRABLE INITIALLY DEFERRED 来实现，请参阅文章“Deferrable SQL Constraints in Depth”的Cyclic Foreign Keys 部分。
【讨论】：
这取决于它是什么样的模型。 UML 模型可能是现实世界的模型，例如人的手与人的手臂具有 1:1 的关系。这种 1:1 的关联模拟了一个生物学事实（忽略了残疾）。
UML 模型也可能是应用程序功能的模型。如果应用程序强制每支球队有 11 名球员，并且每名球员都有一支球队（例如，他们都是通过填写带有“保存”按钮的表格一次性创建的），那么 1:11 关联正确地模拟了应用程序。
UML 模型也可能是某种编程语言中的类或数据库中的表的技术模型。在这种情况下，只有当您的编程语言或数据库系统允许在双方同时创建实例，或至少在同一个事务中创建实例时，1:1 关联才有可能。
旁注：在对团队和玩家进行建模时，您可能会考虑团队和个人之间的关联，多重性为 0..*，团队方面的角色名称为“玩家”。
【讨论】：