【数据库】范式

来源:互联网 发布:db2查看数据库列表 编辑:程序博客网 时间:2024/06/07 06:21

 假设员工关系EMP(员工号,姓名,部门,部门电话,部门负责人,家庭住址,家庭成员,成员关系)如下表所示。如果一个部门可以有多名员工,一个员工可以有多个家庭成员,那么关系EMP属于 (52) ,且 (53) 问题;为了解决这一问题,应该将员工关系EMP分解为 (54) 。

(52)

A. 1NF

B. 2NF

C. 3NF

D. BCNF

(53)

A. 无冗余、无插入异常和删除异常

B. 无冗余,但存在插入异常和删除异常

C. 存在冗余,但不存在修改操作的不一致

D. 存在冗余、修改操作的不一致,以及插入异常和删除异常

(54)

A. EMP1(员工号,姓名,家庭住址)

EMP2(部门,部门电话,部门负责人)

EMP3(员工号,家庭成员,成员关系)

B. EMP1(员工号,姓名,部门,家庭住址)

EMP2(部门,部门电话,部门负责人)

EMP3(员工号,家庭成员,成员关系)

C. EMP1(员工号,姓名,家庭住址)

EMP2(部门,部门电话,部门负责人,家庭成员,成员关系)

D. EMP1(员工号,姓名,部门,部门电话,部门负责人,家庭住址)

EMP2(员工号,家庭住址,家庭成员,成员关系)


解析:

[分析] 本题考查对范式、模式分解知识的掌握程度。
试题(31)考查范式的基础知识。员工关系EMP属于第一范式的原因是因为其主键是(员工号,家庭成员),非主属性部门名,负责人,电话存在对主键的部分函数依赖。所以正确的答案是A。


答案:

A D B


关于范式:

摘录自http://blog.csdn.net/famousdt/article/details/6921622

范式:英文名称是 Normal Form,它是英国人 E.F.Codd(关系数据库的老祖宗)在上个世纪70年代提出关系数据库模型后总结出来的,范式是关系数据库理论的基础,也是我们在设计数据库结构过程中所要遵循的规则和指导方法。目前有迹可寻的共有8种范式,依次是:1NF,2NF,3NF,BCNF,4NF,5NF,DKNF,6NF。通常所用到的只是前三个范式,即:第一范式(1NF),第二范式(2NF),第三范式(3NF)。下面就简单介绍下这三个范式。 
◆ 第一范式(1NF):强调的是列的原子性,即列不能够再分成其他几列。 
考虑这样一个表:【联系人】(姓名,性别,电话) 
如果在实际场景中,一个联系人有家庭电话和公司电话,那么这种表结构设计就没有达到 1NF。要符合 1NF 我们只需把列(电话)拆分,即:【联系人】(姓名,性别,家庭电话,公司电话)。1NF 很好辨别,但是 2NF 和 3NF 就容易搞混淆。 
◆ 第二范式(2NF):首先是 1NF,另外包含两部分内容,一是表必须有一个主键;二是没有包含在主键中的列必须完全依赖于主键,而不能只依赖于主键的一部分。 
考虑一个订单明细表:【OrderDetail】(OrderID,ProductID,UnitPrice,Discount,Quantity,ProductName)。 
因为我们知道在一个订单中可以订购多种产品,所以单单一个 OrderID 是不足以成为主键的,主键应该是(OrderID,ProductID)。显而易见 Discount(折扣),Quantity(数量)完全依赖(取决)于主键(OderID,ProductID),而 UnitPrice,ProductName 只依赖于 ProductID。所以 OrderDetail 表不符合 2NF。不符合 2NF 的设计容易产生冗余数据。 
可以把【OrderDetail】表拆分为【OrderDetail】(OrderID,ProductID,Discount,Quantity)和【Product】(ProductID,UnitPrice,ProductName)来消除原订单表中UnitPrice,ProductName多次重复的情况。 
◆ 第三范式(3NF):首先是 2NF,另外非主键列必须直接依赖于主键,不能存在传递依赖。即不能存在:非主键列 A 依赖于非主键列 B,非主键列 B 依赖于主键的情况。 
考虑一个订单表【Order】(OrderID,OrderDate,CustomerID,CustomerName,CustomerAddr,CustomerCity)主键是(OrderID)。 
其中 OrderDate,CustomerID,CustomerName,CustomerAddr,CustomerCity 等非主键列都完全依赖于主键(OrderID),所以符合 2NF。不过问题是 CustomerName,CustomerAddr,CustomerCity 直接依赖的是 CustomerID(非主键列),而不是直接依赖于主键,它是通过传递才依赖于主键,所以不符合 3NF。 
通过拆分【Order】为【Order】(OrderID,OrderDate,CustomerID)和【Customer】(CustomerID,CustomerName,CustomerAddr,CustomerCity)从而达到 3NF。 
第二范式(2NF)和第三范式(3NF)的概念很容易混淆,区分它们的关键点在于,2NF:非主键列是否完全依赖于主键,还是依赖于主键的一部分;3NF:非主键列是直接依赖于主键,还是直接依赖于非主键列。


0 0