超级码农(45***938) 16:05:32
有一个问题，请教下大伙：受限关联 在数据库层面怎么实现？
超级码农(45***938) 16:11:41
我现在的方法是只能是在触发器上动做手脚，保证实体间的关系符合规定的业务规则
潘加宇(3504847) 8:39:15
触发器可以。也可以把限定符字段和外键一起做一个唯一索引。人员-账户，人员有多个账户，但每人每种账户类型只能有一个账户。账户（账户ID，人员ID，账户名，密码，账户类型），把人员ID和账户类型一起做成唯一索引。
实际工作中很少使用这个元素，在类图中加约束说明即可，否则业务规则变为"每人每种账户类型最多有三个账户"就麻烦了。
超级码农(45***938) 10:10:45
嗯，潘老师的做法可行的，现在就是业务规则多变，导致实体之间的关系的限制也随着规则在改变，我想要的就受限关联是可以配置，我觉得 "人员" 和 "账户" 这个例子还不具有代表性，因为这个功能可以在RABC模型中得到很好的解决。
超级码农(45***938) 10:22:36
拿"炒菜"打个比喻：现在有5个锅，有10种菜要炒，如果 锅与菜之间的关联没限制，那么菜可以分配到任意一个锅中去炒，现在有个业务规则，鱼这种菜只能放到A锅去炒，其他菜任意；过几天业务规则改掉了，说A锅现在来不及炒，鱼这种菜可以放大A锅和B锅中去炒，其他菜任意；又过了几天业务规则又发生变化，为了防止串味，规定鱼这种菜只能放在A锅来炒，其他菜可以放在除A锅以外的任意一个锅来炒。
潘加宇(3504847) 10:25:09
这个要加另外的类，不能在原来的那几个类解决
潘加宇(3504847) 10:25:55
需要添加描述层的类：锅类型--（适用于）--菜类型
超级码农(45***938) 10:26:35
其实，实际项目中有很多受限关联，例如，几种奖学金的兼得规定，仓库物流存放规定等待都是由于关联受限造成的
超级码农(45***938) 10:29:41
嗯，是的，在数据库层面，菜与锅之间的外键联系，就要满足类型匹配上的限制了
四爷(47***93) 13:05:47
在你这个例子里面，根本就不存在 菜和锅 之间的主外键关系。
超级码农(45***938) 18:21:34
实体之间存不存的关系，不是单看两个实体就能决定的，从哲学角度看万物之间的联系是普遍存在的，而且任意两个物体之间的联系还不止一种，关键是这些联系是否是我们需要考虑的联系，而是有业务需求决定。就那刚才"炒菜"的例子，如果需求是这样：由计算机分配那些菜分配到那些锅里面去炒，并以电子工单的形式通知厨房炒菜，那么菜与锅之间就存在关联关系了。
超级码农(45***938) 18:26:34
同样的，系统中的管理员与系统用户之间，在大部分系统中两个对象在功能上会存在依赖关系，在数据上不存在关联关系，如果需求变成：由计算机随机分配，管理员可以管理那些用户，那么管理员对象和系统用户对象在数据上就存在关联。