设计无损连接、依赖保留、3NF 数据库答案

【问题标题】：Designing lossless-join, dependency preserving, 3NF database设计无损连接、依赖保留、3NF 数据库
【发布时间】：2011-12-21 03:30:30
【问题描述】：

我需要设计数据库来跟踪以下属性：

    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

我需要找到无损连接、依赖保留、属性的第三范式分解。
我尝试了不同的分解，但没有一个能满足所有要求（它们是：无损连接、依赖保留、第 3 范式）。
例如。如果我保留原始关系而不进行更改（表将具有所有 4 个属性），我将获得无损连接、依赖保留但不是 3NF，只有 2NF。
以下分解：

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

在 3NF 中，依赖保留，但不是无损连接。
我的问题有什么解决办法吗？

谢谢。

【问题讨论】：

标签： database-design database-normalization functional-dependencies

【解决方案1】：

也许这项作业的目的是让你发现你的问题“我的问题有什么解决方案吗？”的否定答案。

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

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

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

因此：也许这项作业的目的是让您发现规范化并不是数据库设计的圣杯。我想你已经走上了这条路。

【讨论】：

“以通常的方式分解 B->D 和 C->D FD，必然会引入与每个 A 相关联的两个不同 D 的可能性。”换句话说，规范化揭示了原始数据模型的错误。我认为这是对规范化练习的验证，而不是反对它。
嗯？我认为不会。如果您确实认为确实如此，那么您似乎可以准确地揭示错误是什么。 “知道邮编就知道城市”的概念有什么问题，“知道电话号码，就知道城市”的概念有什么问题，这些有什么问题两个概念同时应用 ? ...
...（我的意思是，当然，从理论的角度来看，例如，如果电话公司组织他们的电话号码分配，使得任何电话号码的前 n 位确实是一个决定性因素，允许人们从中确定城市。）（我的意思是：考虑到这在实践中并不碰巧，今天，这种考虑并不重要。）

【解决方案2】：

您对原始关系的分解假定这些依赖项指向同一个 CITY。

postcode -> city
phone_number -> city

在现实生活中并非总是如此。例如，在我所在的地区，有些地址的电话号码带有伦敦区号，但位于金斯顿，萨里的邮政编码中。还有手机，不映射到任何地理位置。

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

"属性是抽象的。你不需要理解它的含义属性。有关它们的所有信息都在功能中任务中列出的依赖项。”

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

【讨论】：

感谢回复，但我的任务具体是我无法确定依赖关系，它们已经在任务中定义了。您可以使用 A、B、C、D 等符号代替给定的属性。属性是抽象的。您无需了解属性的含义。有关它们的所有信息都在任务中列出的功能依赖项中。

【解决方案3】：

作为explained in this slides，总是有一个保留依赖的无损连接3NF。描述的计算它的算法是implemented in this prolog script (explanation and source)。

这样的分解总是存在的，在这种情况下，它就是你接近的那个：

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

您可以运行Tableau Algorithm 来检查它是否真的是无损连接。

【讨论】：

【解决方案4】：

在依赖理论中，连接依赖是对数据库方案上法律关系集的约束。如果 T 总是可以通过连接多个具有 T 属性的子集的表来重新创建，则表 T 受连接依赖关系的影响。如果连接中的一个表具有表 T 的所有属性，则连接依赖关系为叫琐碎。

连接依赖在第五范式中起着重要的作用，也称为project-join范式，因为可以证明，如果你在表R_1到R_n中分解一个方案R，分解将是一个无损的-如果您将 R 上的法律关系限制为对 R 的连接依赖项，称为 *(R_1,R_2,...R_n)，则连接分解。

描述连接依赖的另一种方式是说连接依赖中的关系集是相互独立的。

与函数依赖的情况不同，连接依赖没有健全和完整的公理化，尽管公理化存在于更具表现力的依赖语言，例如全类型依赖。但是，连接依赖的含义是可确定的。

【讨论】：