我需要设计能够跟踪以下属性的数据库:
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范式)。
E. g。如果我保留原始关系而不做任何更改(表将具有所有4个属性),我将获得无损连接,依赖保留但不是3NF,只有2NF。
以下分解:
(stdnum, postcode, phone_number, city) =
=(stdnum, postcode, phone_number) JOIN (postcode, city) JOIN (phone_number, city)
是3NF,依赖保留,但不是无损连接 我的问题有解决办法吗?
感谢。
答案 0 :(得分:1)
您对原始关系的细分假定这些依赖关系指向同一个CITY。
postcode -> city
phone_number -> city
在现实生活中并非总是如此。例如,在我自己的地方,有一些地址有一个带有伦敦区号的电话号码,但它位于KINGSTON,SURREY邮政编码中。还有移动电话,它们不会映射到任何地理位置。
所以我会通过更改数据模型来解决您的问题。
“属性是抽象的。你不需要理解的含义 atributes。关于它们的所有信息都在功能上 任务中列出的依赖项。“
用具体的例子思考是理解我们抽象中的缺陷的更好方法。在这种情况下,也许你真的有五个属性而不是四个。或者可能存在功能依赖postcode -> city
有效,但phone_number -> city
是假的。或者,您可能需要模拟学生可以拥有多个电话号码的事实,例如:挖掘固定电话(共享),移动(人员)。
答案 1 :(得分:1)
也许作业的目的是让你发现你的问题的否定答案“我的问题有解决办法吗?”。
将您的数据库作为单个4属性的东西必然意味着每个A(螺柱)只能有一个D(城市)。以通常的方式分解B-> D-和C-> D FD,必然引入具有与每个A相关的两个不同D的可能性。
处理这个问题需要在设计中引入数据库约束,但数据库约束不在规范化理论范围之内。
不分解必然意味着你不会获得3NF。
因此:也许分配的目的是让你发现规范化不是数据库设计的圣杯。我想你已经走上了这条轨道。
答案 2 :(得分:1)
作为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来检查它实际上是无损连接。
答案 3 :(得分:0)
在依赖性理论中,连接依赖性是对数据库方案上的法律关系集的约束。如果可以通过连接多个表来重新创建T,则表T受到连接依赖性的约束,每个表具有T的属性的子集。如果连接中的一个表具有表T的所有属性,则连接依赖性是叫做琐碎。
连接依赖在第五范式中起重要作用,也称为项目连接范式,因为可以证明如果在表R_1至R_n中分解方案R,则分解将是无损的 - 如果将R上的法律关系限制为R上的连接依赖关系*(R_1,R_2,... R_n),则加入分解。
描述连接依赖关系的另一种方法是说连接依赖关系中的关系集是相互独立的。
与功能依赖的情况不同,虽然对于更具表现力的依赖语言(例如完全类型的依赖性)存在公理化,但是对于连接依赖性没有完整的公理化。但是,连接依赖的含义是可判定的。