database - 将模式规范化为第四范式

标签 database functional-dependencies multivalue

对于我的数据库类(class)的家庭作业,我正在努力理解如何将此模式规范化为第四范式。

这是我必须做的:

Normalize the following schema, with given constraints, to 4NF:

Books(accessionno, isbn, title, author, publisher)
Users(userID, name, deptID, deptname)

Accesssionno -> isbn
Isbn -> title
Userid -> name
Userid -> deptid
Deptid -> deptname

这是我的尝试:

Books(accessionno, isbn)
Books2(accessionno, title)
Books3(accessionno, author, publisher)

Users(userID, name)
Users2(userID, deptID)
Users3(userID, deptName)

我感到困惑的是 isbn -> title 和 Deptid -> deptname

我不确定如何处理这两个函数依赖关系,有人可以提供一些帮助吗?我已经在网上查找了示例,但正在努力将其与我的具体问题联系起来。感谢您的帮助,非常感谢!

编辑:在查看更多示例并阅读更多 Material 后,这是我第二次尝试解决方案。有什么建议吗?

Books(accessionno, isbn, title, author, publisher)
Accesssionno -> isbn
Isbn -> title

Normalized:
Books1(accessionno, isbn)
Books2(accessionno, isbn, title)
Books3(accessionno, author, publisher)

Users(userID, name, deptID, deptname)
Userid -> name
Userid -> deptid
Deptid -> deptname

Normalized:
Users1(userID, name)
Users2(userID, deptID)
Users3(userID, deptID, deptName)

最佳答案

首先,你有两个不同的关系模式,没有共同的属性,所以分别规范化它们是正确的。

所以,从第一个关系开始:

Books(AccessionNo, Isbn, Title, Author, Publisher)
AccessionNo → Isbn
Isbn → Title

问题是没有用属性 AuthorPublisher 指定的依赖关系,很明显我们可以将关系解释为描述书籍,在这种情况下应该也是其他两个依赖项:

Isbn → Author
Isbn → Publisher

或者,等价地,可以写出该关系具有两个依赖关系:

Books(AccessionNo, Isbn, Title, Author, Publisher)
AccessionNo → Isbn
Isbn → Title, Author, Publisher

通过这种“更正”,您可以通过生成以下子模式将关系引入 Boyce-Codd 范式:

R1 < (Isbn, Author, Publisher, Title),
{ Isbn → Author
  Isbn → Publisher
  Isbn → Title }>

R2 < (AccessionNo Isbn),
{ AccessionNo → Isbn } >

第一个有唯一的键Isbn,而第二个有唯一的键AccessionNo

另一方面,如果模式应该只有提到的两个函数依赖,则 BCNF 中的分解会更复杂并且不是很重要:

R1 < (Isbn, Title) ,
{ Isbn → Title } >

R2 < (AccessionNo, Isbn) ,
{ AccessionNo → Isbn } >

R3 < (AccessionNo, Author, Publisher) ,
{ } >

其中第一个关系有键Isbn,第二个有键AccessionNo,第三个有键(AccessionNo, Author, Publisher) .

对于第二个关系,

Users(UserID, Name, DeptID, DeptName)    
UserID → Name
UserID → DeptID
DeptID → DeptName

依赖关系是有道理的,因为模式描述了与用户及其部门的关系,其中每个用户都属于一个部门。在这种情况下,Boyce-Codd 范式由以下分解给出:

R1 < (UserID, Name, DeptID) ,
{ UserID → Name
  UserID → DeptID } >

R2 < (DeptID, DeptName) ,
{ DeptID → DeptName } >

其中第一个关系有键UserID(描述用户),第二个关系有键DeptID(描述部门)。

最后一点:所有产生的分解都是 Boyce-Codd 范式,因此它们自动已经是第三范式。它们也属于第四范式,因为没有多值依赖关系,需要特殊处理。

关于database - 将模式规范化为第四范式,我们在Stack Overflow上找到一个类似的问题: https://stackoverflow.com/questions/40099403/

相关文章:

database-design - 可以以相反的顺序应用函数依赖中的增强规则吗?

mysql - 数据库 : Lossless decomposition and natural join

sorting - 在 Solr 中,我可以对多值字段中的匹配值进行排序吗?

database - 使用关系数据库/ORM 或文档数据库/ODM 的动机

javascript - 动态 Accordion 菜单

sql - Mojolicious:来自现有数据库的结果集

在 Solr 中搜索多值字段为空或具有特定值的文档

database - 记录通用两人游戏结果的正确数据设计是什么?

scala - Scala 中可通过 FoldLeft 读取 FoldRight

arrays - Solr 查询过滤文档,数组中至少有一个值(指定值除外)