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

Question

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

databaseanswers 的 Barry Williams 已发布此架构。

Clients and Fees Schema

我正在尝试了解此架构中地址表的拆分。我很清楚，地址表包含给定地址的详细信息。 Client_Addresses 和 Staff_Addresses 表让我着迷。

1) 我理解主外键的使用，如图所示，但我假设当使用这些外键时，您在同一张表中没有常驻主键（在本例中为 date_address_from）。有人可以解释这两者的原因并用语言表达这实际上是如何工作的吗？

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

3) 沿着规范化路线...由于 Client_Addresses 和 Staff_Addresses 表中的 date_address_from 和 date_address_to 都相同，因此这些字段是否应该不包含在主地址表中？

Answer 1

这 2 个额外的表格使您可以拥有每个人的地址历史记录。

您可以将它们放在一张桌子上，但是由于员工和客户是分开的，因此最好也将它们分开（b/c 客户 id =1 和员工 id =1 不能在同一张桌子上使用地址）。

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

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

将 from_Date 作为键的一部分的想法是正确的，尽管它不能保证数据完整性 - 因为您还需要手动检查同一个人的记录之间没有重叠的日期。

大约 3 - 没有（看 2）。

Answer 2

查看数据模型，我认为：

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

2) 同样的，Staff_Addresses 的主键是 {staff_id,address_id,date_adderess_from} 而不仅仅是 date_adderess_from

3) 同 2)

Answer 3

1) 在每个表中，主键是由三个属性组成的复合键：(staff_id, address_id, date_address_from) 和 (client_id, address_id, date_address_from)。这大概意味着客户/员工到地址的映射预计会随着时间而改变，并且这些改变的历史会被保留。

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

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

Answer 4

参考 Staff_Addresses 表，date_address_from 上的主键基本上可以防止多次输入相同的 staff_id/address_id 的记录。现在，我不是 DBA，但出于性能原因/更快的索引，我喜欢我的 PK 是整数或 guid。如果我要这样做，我会创建一个新列，例如 Staff_Address_Id，并将其设为 PK 列，并对 staff_id/address_id/date_address_from 设置唯一约束。

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

希望这会有所帮助。

Answer 5

3) 沿着 归一化......因为两者 date_address_from 和 date_address_to 在 Client_Addresses 中是相同的 和 Staff_Addresses 表应该那些 字段只是不包含在 主地址表？

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

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

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

想象一下，员工中的某个人也是客户。那个人的名字存储了多少个地方？那个人的地址？你能听到 Rogers 先生在后台说：“你能拼出 'update anomaly' 吗？……我知道你会的。”

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

你知道如何解决这个问题吗？

Answer 6

评估

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

1. 这不是数据模型。这不是数据库。这是一桶鱼，每条鱼都画成一个长方形，一条鱼的鳍被另一条鱼的鳃夹住，有一条线。有大量的重复，也有大量的缺失元素。完全不值得拿它作为例子来学习任何关于数据库设计的东西。

2. 根本没有标准化；文件非常不完整（见迈克的回答，还有一百个这样的问题）。 other_details 和 eg.s 让我大开眼界。每个元素都需要被识别和存储：StreetNo, ApartmentNo, StreetName, StreetType等，而不是line_1_number_street，它是一个组。

   • 应将客户和员工规范化为 Person 表，并标识所有元素。

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

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

4. Barry 在网络上有（等待它）超过 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. 其他人已经回答了。

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