database - 正常化;如何明智地确定一个字段是否依赖于其存在的主要属性？

Question

主要是关于部分依赖(第二范式)

比如说，您正在为火车服务设计一个数据库，并希望跟踪与预定和实际出发和到达时间相关的数据。现在，假设预定出发时间是特定表的复合键的一部分，请考虑以下内容:

你会说即使对于预定到达时间属性，该属性实际上是否依赖于预定出发时间而存在？可以说，鉴于在确定两个火车站之间的旅行持续时间方面进行了大量研究和工作，因此，可以确定一个非常接近的近似到达时间，给定它的预定出发时间(关键/主要属性)，确实这意味着预定的到达时间取决于预定的出发时间？

同样，对于实际出发时间和到达时间，您会说这两个属性中的任何一个都取决于预定的出发时间吗？作为数据库设计者，您如何明智地看待这一点？

Answer 1

函数依赖 A->B 只是意味着对于 A 的任何给定值，B 都有一个可能的值。

在实践中，数据库设计者通常对表示用户/客户期望或需要执行的业务规则的 FD 感兴趣。执行这些规则的原因是为了帮助确保准确和可用的数据表示。

除了从乘客的角度，我对铁路时刻表知之甚少。我在时刻表中看到了这样的例子，不同的火车沿着相同的路线和站点实际上需要不同的时间才能到达目的地。我预计这是因为在高峰期由于拥堵等原因需要允许额外的时间。所以我猜测出发时间本身不会决定到达时间。除非你真的打算强制执行 departure->arrival 依赖，否则没有必要将其视为规范化的一部分。如果有疑问，那么作为数据库设计者，您应该能够询问主题专家或业务发起人，以确定该 FD 在数据库中是否重要。

假设火车时刻表表示为如下所示的关系:

Timetable {service, origin, destination, departure, arrival}

在这种设计中，出发时间本身并不能决定到达时间，因为不同车站的火车可以同时出发，并在到达时间大相径庭的情况下进行不同的旅程。即使对于给定的始发站和给定的出发时间，也可能存在具有不同到达时间的不同服务(周日 0830 服务可能与同一路线上的周一 0830 服务到达时间不同)。

让我们假设候选键为{service, origin, destination, departure}，在这种情况下，到达的明显键依赖性将被强制执行:{service, origin, destination, departure}->{arrival}。因此，出发将是一个主要属性，但其本身并不是到达的决定因素。也许一个有趣的问题是 {service, origin, destination, arrival} 是否也是候选键。我怀疑这对一些繁忙的铁路网络来说可能是一个不合理的限制。甚至我对 {service, origin, destination, department} 候选键的假设对于我认为的某些 senarios 来说可能是不现实的——但这只是我假设的例子。正确回答这些问题的唯一方法是在实际业务领域中进行分析并与领域专家交谈。