设计无损连接、保持依赖、3NF数据库

Question

我需要设计能够跟踪以下属性的数据库：

stdnum       // student number
postcode     // postal code
phone_number // student phone number
city         // student address: city

还列出了功能依赖关系：

stdnum -> postcode
stdnum -> phone_number
postcode -> city
phone_number -> city

我需要找到一个无损连接，保持依赖，第三范式分解。

我尝试过不同的分解，但没有人遵守所有的要求(它们是:无损连接，保持依赖，第三范式)。

例如，如果我不改变原始关系(表将拥有所有4个属性)，我将得到无损连接和依赖关系保持，而不是3NF，只有2NF。

分解(stdnum, postcode, phone_number) JOIN (postcode, city) JOIN (phone_number, city)是在3NF和依赖保持，但不是无损连接。

Answer 1

原始关系的分解假定这些依赖关系指向同一个城市。

postcode -> city
phone_number -> city

在现实生活中，情况并不总是如此。例如，在我自己的地方，有一个带有伦敦区号的电话号码，但在萨里的金斯敦邮编中。还有移动电话，它不符合任何地理位置。

所以我会通过改变数据模型来解决你的问题。

“属性是抽象的。您不需要理解Attributes的含义。有关它们的所有信息都在任务中列出的函数依赖项中。”

用具体的例子来思考是更好的方法来理解我们抽象的缺陷。在这种情况下，您可能真的有五个属性，而不是四个属性。或者可能存在函数依赖，postcode -> city是有效的，但phone_number -> city是假的。或者你需要模拟这样一个事实:一个学生可以有一个以上的电话号码，例如挖掘固定电话(共享)、移动电话(人员)。

Answer 2

也许作业的目的是让你发现你的问题的否定答案：“我的问题有什么解决办法吗？”

将您的数据库作为一个单一的4属性事物，必然意味着每个A (stud)只能有一个D(城市)。对于B->D和C->D FDs，按通常的方式分解，必然会引入两个不同的D与每个A相关联的可能性。

解决这一问题需要在设计中引入数据库约束，但数据库约束超出了规范化理论的范围。

而不分解必然意味着你不会得到3NF。

因此:也许分配的目的是让您发现规范化不是数据库设计的圣杯。我想你已经在那条轨道上了。

Answer 3

作为在本幻灯片中解释，始终存在一个保持依赖关系的、无损的连接3NF。所描述的算法是在此prolog脚本中实现 (解释和来源)。

这样的分解总是存在的，在这种情况下，它就是您所接触到的：

(stdnum, postcode, phone_number) JOIN
(postcode, city) JOIN
(phone_number, city)

您可以运行Tableau算法来检查它实际上是否是无损连接。