数据库设计：解释此模式

Question

完全披露......在这里狂热地尝试了解有关数据库的更多信息，以便我投入时间并尝试从源头获得此答案无济于事。

来自databaseanswers的Barry Williams已发布此架构。

客户和费用架构

我试图了解此架构中地址表的拆分。 我清楚地知道Addresses表包含给定地址的详细信息。 Client_Addresses和Staff_Addresses表是我的最佳选择。

1）我理解如所示的主外键的使用，但我假设当使用这些主外键时，在同一个表中没有常驻主键（在这种情况下为date_address_from）。 有人可以解释两者的推理，并说出这实际上是如何工作的吗？

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

3）沿着规范化的行...由于date_address_from和date_address_to在Client_Addresses和Staff_Addresses表中是相同的，那么这些字段是否应该不包含在主地址表中？

Answer 1

1）在每个表中，主键是由三个属性组成的复合键：（staff_id，address_id，date_address_from）和（client_id，address_id，date_address_from）。 这可能意味着客户/员工到地址的映射预计会随着时间的推移而改变，并且这些变化的历史将得以保留。

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

3）否。明显的目的是将地址映射到客户/工作人员的适用日期 - 而不仅仅是适用于地址的日期。

Answer 2

3）沿着规范化的行...由于date_address_from和date_address_to在Client_Addresses和Staff_Addresses表中是相同的，那么这些字段是否应该不包含在主地址表中？

不，但你确实发现了一个问题。

设计师决定客户和员工是完全不同的两件事。 “完全不同”，我的意思是他们没有共同的属性。

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

想象一下，工作人员也是客户。 这个人的名字存放了多少个？ 那个人的地址？ 你能否听到罗杰斯先生在背景中说：“你能拼写'更新异常'吗？......我知道你可以。”

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

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

Answer 3

评估

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

1. 这不是数据模型。 这不是数据库。 它是一桶鱼，每条鱼画成一个长方形，一条鱼的鳍被另一条鱼的鳍捕获，有一条线。 有大量的重复，以及大量的缺失元素。 作为一个例子来学习数据库设计是完全不值得的。

2. 根本没有标准化; 这些文件非常不完整（参见迈克的答案，还有一百多个这样的问题）。 other_details和eg.s破解了我。 需要识别和存储每个元素： StreetNo, ApartmentNo, StreetName, StreetType等，而不是line_1_number_street ，这是一个组。

   • 应将客户和员工标准化为人员表，并标识所有要素。

   • 是的，如果客户可以是个人或组织，那么需要超类型 - 子类型结构来正确支持。

3. 实际上，技术上准确的术语是一堆平面文件，包含对字段组的描述。 远离数据库或关系数据库的光年。 没有准备好进行评估或检查，更不用说用什么来构建。 在关系数据模型中，这将是大约35个规范化表，没有重复列。

4. 巴里在网上有500多个“模式”（等待它）。 当您尝试使用第二个“模式”时，您会发现（a）它们在使用和目的方面完全不同（b）它们之间没有共性（c）假设两者都有客户文件; 它们将是不同形式的客户文件。

   • 他需要首先规范化整个单一“模式”，

   • 然后在500个部分或主题区域中呈现单个规范化数据模型。

   • 我已经写过他了。 没有反应。

5. 值得注意的是，他已经使用了一些无法识别的图表惯例。 这些有趣的图片的问题在于它们传达了一些东西，但它们并没有传达有关数据库或设计的重要信息。 学习者感到困惑并不奇怪; 经验丰富的数据库专业人士并不清楚。 有一个原因可以建立关系数据库建模的标准，以及数据模型中的符号：它们传达了设计的所有细节和细微之处。

6. Barry还有很多内容尚未解读：命名约定; 关系; 基数; 等等，列出太多了。

网络上到处都是垃圾，任何人都可以“发布”。 那里有数以百万计的好看和坏看的“设计”，这些都不值得关注。 或者更糟糕的是，如果你看，你会学到完全错误的“设计”方法。 在学习数据库和数据库设计方面，最好建议找到合格的，具有已证明能力的人，并从中学习。

回答

1. 他正在使用复合键而不拼写出来。 client_addresses的PK是client_id ， address_id, date_address_from) 。 这不是一个坏关键，显然他希望永远记录地址。

   • 将地址保存在单独的文件中的概念很好，但他没有提供存储规范化地址所需的任何字段 ，因此“模式”最终将完全复制地址 ; 在这种情况下，他可以删除地址，并将行返回到客户端和人员文件中，以及他们的other_details ，并删除除占用磁盘空间之外绝对没有用处的三个文件。

   您正在考虑关联表，它可以解决数据库中的多对多关系。 是的，那里的列只是两个父表的PK。 这些不是关联表或文件; 它们包含数据字段。

2. 它不是PK，它是PK的第三个元素。

   一个人在一天内在多个地址登记的概念是不合理的; 只计算他们睡得最多的一个地址。

3. 其他人已经回答了。

不要期望在此图中识别出任何数据库或设计或标准化的证据。

Answer 4

这2张额外的桌子可让您拥有每个人的地址历史记录。

您可以将它们放在一个表中，但由于员工和客户端是分开的，因此最好将它们分开（b / c client id = 1且staff id = 1不能在同一个地址表中使用） 。

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

大约2 - 组合了pk，clientID，AddressID和from。 因此，如果某人在州内居住6个月，然后在以色列居住6个月，然后返回州，则返回同一地址 - 地址表中只需要2个地址，而client_address中只需要3个地址。

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

大约3 - 不（看2）。

Answer 5

查看数据模型，我认为：

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

2）以同样的方式，Staff_Addresses的主键是{staff_id，address_id，date_adderess_from}，而不仅仅是date_adderess_from

3）与2）相同

Answer 6

在引用Staff_Addresses表时，date_address_from上的主键基本上可以防止具有相同staff_id / address_id的记录多次输入。 现在，我不是DBA，但我喜欢我的PK因为性能原因/更快的索引而成为整数或指针。 如果我这样做，我会创建一个新列，比如，Staff_Address_Id并将其作为PK列，并在staff_id / address_id / date_address_from上放置一个唯一约束。

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

希望这有所帮助。