Database 数据库设计：解释这个模式

充分披露…我在这里狂热地试图了解更多关于数据库的信息，所以我投入了时间，也试图从消息来源得到这个答案，但没有结果

databaseanswers的Barry Williams发布了此模式

我试图理解此模式中地址表的拆分。很明显，Addresses表包含给定地址的详细信息。客户地址和员工地址表是我最感兴趣的

1） 我理解主外键的使用，如图所示，但我假设使用这些外键时，同一个表中没有常驻主键（本例中为date\u address\u from）。有人能解释这两者的原因，并用语言表达出这是如何实现的吗

2） 为什么要使用date_address_from作为主键，而不是像client_address_id这样的主键？如果有人在一天内输入两个地址，他的设计会有冲突吗？如果是或不是，什么

---

3） 按照规范化的思路……由于“客户地址”和“员工地址”表中的“日期地址”和“起始地址”是相同的，如果这些字段不包括在主地址表中，那么这两个额外的表可以让您拥有每个人的地址历史记录

您可以将它们都放在一个表中，但由于员工和客户是分开的，所以最好也将它们分开（b/c客户id=1和员工id=1不能在同一个地址表上使用）

对于设计问题没有“单一”的解决方案，您可以使用一个人表，然后在员工和客户之间添加一列。但主要的想法是数据库应该清晰、可读且高效，而不是保存表

大约2-pk是组合的，包括clientID、AddressID和from。 因此，如果有人在美国生活6个月，然后在以色列生活6个月，然后回到美国，回到同一个地址——地址表中只需要2个地址，客户地址中只需要3个地址

将from_日期作为密钥的一部分的想法是正确的，尽管它不能保证数据的完整性——因为您还需要手动检查同一个人的记录之间是否存在重叠日期

---

大约3-不（看2）。

查看数据模型，我认为：

1） PF表示该字段既是表主键的一部分，也是其他表的外键

2） 同样，Staff_address的主键是{Staff_id，address_id，date_address_from}，而不仅仅是date_address_from

3） 与2相同）在这些表中，主键是一个复合键，由三个属性组成：（员工id、地址id、日期地址地址来源）和（客户id、地址id、日期地址来源）。这可能意味着客户/员工到地址的映射将随着时间的推移而变化，并且这些变化的历史记录将被保留

2） 没有明显的理由在这些表中创建新的“id”属性。复合键可以充分发挥作用。为什么要在同一日期为同一客户机创建两次相同的地址？如果您这样做了，那么这可能是修改设计的一个原因，但这似乎是一个不太可能的要求

---

3） 不可以。显然，它们是地址映射到客户/员工的适用日期，而不是仅适用于该地址的日期。

关于staff\u Addresses表，date\u address\u from上的主键基本上防止了具有相同员工id/地址id的记录被多次输入。现在，我不是DBA，但出于性能原因/更快的索引，我希望我的PK是整数或GUID。如果我要这样做，我会创建一个新列，比如说，Staff\u Address\u Id，并将其设置为PK列，并对Staff\u Id/Address\u Id/date\u Address\u from设置唯一约束

至于最后一个问题，Addresses表实际上是一个通用的地址存储结构。它不应该关心有人居住在那里的日期范围。最好留给特定的地址实现，比如客户机/员工地址

希望这有点帮助

3） 沿着 正常化…因为 日期\地址\从和日期\地址\到 在客户端地址中是相同的 工作人员的地址表应该是 字段不能包含在 主地址表

没有，但你确实发现了一个问题

设计师认为客户和员工是完全不同的两件事。我所说的“完全不同”，是指它们没有共同的属性

那不是真的，是吗？客户和员工都有地址。我相信他们大多数人也有电话

假设员工中的某个人也是客户。那个人的名字存储了多少个地方？那个人的地址？你能听到罗杰斯先生在后台说，“你能拼写‘更新异常’吗？……我就知道你能。”

问题是，设计师将客户和员工视为不同类型的人。他们不是。“客户”描述服务提供商（通常不是零售商）和客户（可能是个人或公司）之间的业务关系。“员工”描述公司和个人之间的雇佣关系。不是不同类型的人——不同类型的关系

---

你能看到如何解决这个问题吗？

评估

首先是审计，然后是具体答案

这不是一个数据模型。这不是一个数据库。这是一桶鱼，每条鱼都画成一个长方形，当一条鱼的鳍被另一条鱼的鳃抓住时，就有一条线。有大量重复，也有大量缺失的元素。它完全不值得作为学习数据库设计的例子

根本没有正常化；这些文件非常不完整（se