我们是否同意最初的假设？
UML文献经常提到有关聚合/组合的部分整体关系。但是，UML标准中的定义已经发展(请参阅UML 2.5.1)：
有时使用一个属性来建模环境，其中一个实例用于将一组实例组合在一起；这称为聚合。(...)
Shared:指示该属性具有共享聚合语义。共享聚合的精确语义因应用程序区域和建模者而异。
组合:表示属性是复合聚合的，即复合对象负责组合对象的存在和存储。
复合聚合是一种强大的聚合形式，它要求一个部件对象是，最多一次包含在一个复合对象中，。如果一个复合对象被删除，那么它所有作为对象的部件实例都会随之被删除。
换句话说，没有为“聚合”(即共享聚合)指定与简单关联不同的精确语义:共享聚合是一个modeling placebo。
因此，数据库约束与UML建模之间的关系并不像您想象的那样简单。
近距离匹配？
此外，在数据库模式和UML模型之间没有一般的一对一映射.可以使用多个数据库模式来实现相同的UML类图。相反，多个UML图可以表示由给定数据库模式实现的设计。所以我们能做的最好就是考虑近距离的比赛。
在数据库中，带有FOREIGN KEY约束的表对应于组合中的潜在组件、共享聚合的元素或简单关联中的关联实例：
a 可以帮助实现复合聚合:这是在SQL中实现组合中所期望的那种生命周期管理的唯一方法:组合时组件将被删除。如果某些业务规则/合同(例如UML post条件)需要这样一个相关的删除，那么它也可以实现一个普通的关联。
a 可以帮助实现共享聚合，如果它的意义被定义为您的意思:如果删除聚合，则不会删除其元素，因此可以共享。但是它也可以实现--任何普通的关联，因为删除关联实例也不会触发删除，并且约束将允许保持一个干净的引用完整性。