聚合-关系数据库映射：特定多重性的表表示及方案问询

首先得先把咱们要建模的关系掰扯清楚：你说的「B是整体类，B端多重性为0..*，A端为5」，应该是指每个A实例必须恰好绑定5个不同的B实例，而每个B实例可以绑定0个或者多个A实例对吧？下面分情况给你解答：

1. 原场景能用关系表准确表示吗？ #

可以，但单纯的多对多（m:n）关联表搞不定「每个A必须绑5个B」的硬约束，得加额外的规则或者数据库层面的限制。

为啥单纯的m:n表不行？ #

标准的m:n关联表（比如叫AB_association，存A_id和B_id两个外键）只能记录谁和谁绑了，但没法自动保证每个A_id在表里刚好出现5次。如果只靠查询时过滤掉不符合的，那脏数据其实已经留在库里了——比如有人误删了一条关联，某个A只剩4个B绑定，数据库不会拦着，只能靠应用层或者查询筛掉，这根本算不上「准确表示」，只是自欺欺人罢了。

靠谱的解决方案有两种： #

方案一：数据库层面加硬约束

• 先给AB_association加个唯一约束，确保(A_id, B_id)是唯一的，避免同一个A重复绑同一个B；
• 写个触发器（Trigger），不管是插入、删除还是更新关联记录，都自动检查对应的A_id的关联数是不是刚好5个。要是不符合，直接回滚操作；
• 要是用的是PostgreSQL这种支持自定义函数的数据库，也可以用CHECK约束调用统计函数，实时验证每个A的关联数。

方案二：调整表结构，直接固化关联数

既然每个A必须绑5个B，那干脆在A表直接加5个外键字段：B_id_1、B_id_2、B_id_3、B_id_4、B_id_5，每个都关联B表的主键。这种方式的好处是天生就强制了每个A有5个B绑定，不用额外加约束，但缺点就是不够灵活——哪天规则改成每个A绑6个B，就得改表结构了。

2. 只靠m:n表+查询过滤合理吗？ #

说实话，这种方式只能解决「用户看到的是有效数据」的表面问题，但从数据完整性的角度来说，非常不合理：

• 脏数据留在库里，后续做统计、报表的时候很容易出错；
• 应用层得额外写一堆校验逻辑，开发负担大，还容易漏——比如多个客户端同时操作的时候，并发问题根本防不住；
• 数据一致性没法保证，比如某个A的关联数变成4了，数据库不会报错，等你查询的时候才发现，排查问题都头疼。

3. 当B端多重性改成1..*（每个A至少绑1个B）时怎么建模？ #

这个场景就常见多了，解决方案也成熟：

• 还是用标准的m:n关联表AB_association，存A_id和B_id，加唯一约束(A_id, B_id)，外键分别指向A和B的主键；
• 要强制「每个A至少绑1个B」，有几种方式：
  1. 数据库触发器兜底：删除关联记录的时候，检查对应的A_id是不是还有其他关联；要是删完之后该A的关联数变成0，直接回滚操作。另外，插入A记录的时候，要么同时插至少一条关联记录，要么用触发器阻止空A的插入；
  2. 应用层逻辑控制：创建A实例的时候，必须同时绑定至少一个B；删除关联的时候，确保A还有其他绑定。但这种方式不如数据库约束靠谱，毕竟有人可能绕过应用直接操作数据库；
  3. 混合表结构：如果业务允许，可以在A表加一个primary_B_id外键（保证每个A至少有一个主绑定），然后用m:n表记录额外的绑定。这种方式既能保证每个A至少有一个B，又支持多个绑定，但业务逻辑里要区分主绑定和其他绑定。

内容的提问来源于stack exchange，提问作者newthau