ER图缺陷

Question

我有一个银行数据库的ER图 - 客户可能有多个账户，账户可能由多个客户共同持有，每个客户与一个账户集相关联，账户是一个或多个账户集的成员。违反了哪些设计规则？应该做出哪些修改以及为什么？

到目前为止，我不确定的一些缺陷是：

1）AcctSets Entity中的冗余所有者地址属性。

2）此ER不包含具有不同地址的多个所有者的帐户。

我的问题是：我如何解决这些缺陷和/或我可能在分析中遗漏的其他缺陷？谢谢！

Answer 1

我不确定AccountSet实体的作用。

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

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

CustomerKey可以访问此实体，以获取客户的帐户，或访问AccountKey，以获取客户的帐户。 CustomerAccountKey仅用于集群数据库上的数据。

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

如果您想为客户提供多个地址，那么这将成为客户实体与地址实体之间的一对多关系。这允许客户拥有夏季地址和冬季地址，作为一个真实的例子。

Answer 2

您尚未说明抽象Account Sets的原因。您需要Customer和Account之间的交集，因为您的业务规则说多对多，但为什么要进行干预抽象？

即使假设您保留它，属性owner address也不属于Account和Customer之间的抽象/交集实体（即Account Set）。这没有意义。您声明的规则或相关经验中没有任何内容表明客户地址对帐户与客户之间的关系有任何功能依赖性。如果有的话，它将在功能上仅依赖于客户。就目前而言，您将此依赖关系建模为多值，因此地址甚至在功能上完全不依赖于客户。放置它的唯一3NF位置是Addresses实体类型。

你应该考虑一个比Addresses更好的名字。首先，应该为它们所代表的对象命名您的实体。抵制使用复数名词的冲动。实体类型不是集合。实现实体类型的表将是您的实体实例的集合，但不言而喻，当您考虑关系的基数时，复数名词命名只会让您感到困惑。我建议将Location作为实体类型名称，并将address作为属性。当你超越概念水平时address几乎肯定会被分解。

除此之外，根据您引用的业务规则，您处于相当不错的轨道上。