问ER图缺陷

EN

我不确定AccountSet实体是做什么的。

您与客户和客户之间存在多对多的关系。因此，您需要一个将客户绑定到一个或多个帐户，并将一个帐户绑定到一个或多个客户的CustomerAccount实体。

CustomerAccount
---------------
CustomerAccountKey
CustomerKey
AccountKey

这个实体将由CustomerKey或AccountKey访问，前者用于获取客户的帐户，后者用于获取帐户的客户。CustomerAccountKey仅用于对数据库上的数据进行集群。

CustomerAccount实体中的CustomerKey - AccountKey组合是唯一的。

如果您希望一个客户有多个地址，那么customer实体和address实体之间就成了一对多关系。这允许客户拥有夏季地址和冬季地址，这是一个真实的例子。

您还没有说明使用抽象Account Sets的原因。您需要在Customer和Account之间建立一个交集，因为您的业务规则是多对多的，但是为什么要有一个中间的抽象呢？

即使假设您保留了它，属性owner address也不属于Account和Customer之间的抽象/交集实体(即Account Set)。这根本就说不通。在您陈述的规则或共同的经验中，没有任何内容表明客户地址对帐户和客户之间的关系具有任何功能依赖性。如果说有什么不同的话，那就是它在功能上只依赖于客户。现在，您正在将此依赖项建模为多值，因此地址甚至在功能上都不完全依赖于客户。唯一可以放置它的3NF位置是Addresses实体类型。

你应该考虑一个比Addresses更好的名字。首先，您的实体应该根据它们所代表的对象来命名。克制住使用复数名词的冲动。实体类型不是集合。实现实体类型的表将是实体实例的集合，但这是不言而喻的，当您考虑关系的基数时，复数名词命名只会将您引向混乱。我建议使用address作为属性，将Location作为实体类型名称。当你超越概念层面时，address几乎肯定会被分解。

除此之外，根据您所引用的业务规则，您正处于一个非常好的轨道上。