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