数据库设计：解释此模式

Question

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

来自databaseanswers的Barry Williams发布了这个架构。

Clients and Fees Schema

我试图了解此架构中地址表的拆分。我清楚地知道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表应该是那些   字段不包括在内   主要地址表？

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

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

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

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

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

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

Answer 3

<强>评价

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

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

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

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

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

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. 其他人已经回答了这个问题。

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

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表实际上是一个通用的地址存储结构。它不应该关心某人居住在那里的日期范围。最好留给地址的特定实现，例如客户端/员工地址。

希望这有点帮助。