2

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

    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 中，依赖保留，但不是无损连接。
我的问题有什么解决办法吗？

感谢。

4

4 回答 4

1

正如本幻灯片中所解释的，始终存在一个保留依赖关系的无损连接 3NF。所描述的计算它的算法在这个 prolog 脚本（解释和源代码）中实现。

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

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

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

于 2013-02-09T03:52:40.600 回答
1

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

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

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

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

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

于 2011-11-03T15:28:56.477 回答
1

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

postcode -> city
phone_number -> city

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

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

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

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

于 2011-11-03T13:12:44.123 回答
0

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

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

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

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

于 2014-04-22T11:29:20.193 回答