sql - ER图缺陷

Question

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

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

1) AcctSets 实体中的冗余所有者地址属性。

2) 此 ER 不包括拥有多个不同地址的所有者的帐户。

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

Answer 1

我不确定 AccountSet 实体的作用。

您与客户和客户有多对多的关系。因此，您需要一个 CustomerAccount 实体，将客户与一个或多个帐户联系起来，并将一个帐户与一个或多个客户联系起来。

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

此实体将由 CustomerKey 访问，以获取客户的帐户，或由 AccountKey 访问，以获取客户的帐户。CustomerAccountKey 仅用于对数据库上的数据进行聚类。

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

如果您想要一个客户的多个地址，那将成为客户实体和地址实体之间的一对多关系。这允许客户有一个夏季地址和一个冬季地址，作为一个现实生活中的例子。

Answer 2

您没有说明使用 abstraction 的原因Account Sets。您需要 和 之间的交集Customer，Account因为您的业务规则说多对多，但是为什么要介入抽象呢？

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

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

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