自考数据库系统原理3范式例题汇总

【数据库系统原理】第三范式（3NF）是数据库设计中的一个重要概念，它是为了消除冗余数据和确保数据一致性而提出的。在3NF中，每个非主属性必须直接依赖于整个键，而不是键的一部分，同时避免传递依赖。以下是对题目中给出的几个例子的详细解释： 1. 关系模式 R（S#，C#，GRADE，TNAME，TADDR） - 基本FD：(S#, C#)→GRADE, C#→TNAME, TNAME→TADDR - 候选键：(S#, C#) - R不是2NF，因为(S#, C#)→(TNAME, TADDR)是局部依赖，存在冗余。分解为2NF：R1(S#, C#, GRADE), R2(C#, TNAME, TADDR)。 - 进一步分解为3NF：R1不变，R2分解为R21(C#, TNAME)和R22(TNAME, TADDR)，消除了传递依赖。 2. 关系模式 R（职工编号，日期，日营业额，部门名，部门经理） - 基本FD：(职工编号，日期)→日营业额, 职工编号→部门名, 部门名→部门经理 - 候选键：(职工编号，日期) - R不是2NF，因为(S#, D#)→(部门名, 部门经理)，存在局部依赖。分解为2NF：R1(职工编号，日期，日营业额), R2(职工编号，部门名), R3(部门名，部门经理)。 - R1已经是3NF，R2和R3也是3NF，因为非主属性不依赖于键的非主属性。 3. 关系模式 R（运动员编号，比赛项目，成绩，比赛类别，比赛主管） - 基本FD：(运动员编号，比赛项目)→成绩, 比赛项目→比赛主管, 比赛项目→比赛类别 - 候选键：(运动员编号，比赛项目) - R不是2NF，因为(P#, A#)→(比赛主管)，存在部分依赖。分解为2NF：R1(运动员编号，比赛项目，成绩), R2(比赛项目，比赛主管，比赛类别)。 - R1和R2已经是3NF，因为非主属性只依赖于整个键。 4. 关系模式 R（司机编号，汽车牌照，行驶公里，车队编号，车队主管） - 基本FD：(司机编号，汽车牌照)→行驶公里, 司机编号→车队编号, 车队编号→车队主管 - 候选键：(司机编号，汽车牌照) - R不是2NF，因为(S#, P#)→(车队编号)，存在局部依赖。分解为2NF：R1(司机编号，汽车牌照，行驶公里), R2(司机编号，车队编号，车队主管)。 - R2不是3NF，因为(D#)→(车队主管)，存在传递依赖。分解为3NF：R1保持不变，R2分解为R21(司机编号，车队编号)和R22(车队编号，车队主管)。 5. 未给出完整的问题，但从前面的例子可以看出，3NF的判断和分解通常涉及识别基本函数依赖，找出候选键，并确保非主属性既不局部依赖于候选键的一部分，也不通过其他非主属性传递依赖于候选键。 理解3NF对于数据库设计至关重要，因为它有助于创建更高效、更稳定的数据库结构，减少数据冗余，提高数据一致性。在实际应用中，我们通常需要通过规范化过程将关系模式分解为满足3NF的形式，以优化数据库性能和维护数据的一致性。