数据库设计范式

概念

• 实体：现实世界中客观存在并可以被区别的事物，如“用户”。
• 属性：实体所具有的某一特性，如用户的用户名。
• 元组：表中的一行记录就是一个元组。
• 分量：元组的某个属性值。在一个关系数据库中，它是一个操作原子，即关系数据库在做任何操作的时候，属性是“不可分的”。否则就不是关系数据库了。
• 码：表中可以唯一确定一个元组的某个属性（或者属性组），如果这样的码有不止一个，称这些码为候选码，候选码中可以挑选一个码作为主码，如果一个码包含了所有的属性，称这个码为全码
• 主属性：一个属性只要在任何一个候选码中出现过，称这个属性为主属性。
• 非主属性：与主属性相反，没有在任何候选码中出现过，这个属性就是非主属性。
• 外码：一个属性（或属性组），它不是码，但是它别的表的码，它就是外码。

1NF

第一范式（1NF）即满足原子性：数据库表中每一列都是不可分割的数据项，集合、数组等属于非原子项，此类属性必须拆分为不同的属性。

例子：学生联系方式包括手机号和邮箱，

学生可能只有手机号或邮箱，如果学生既有手机号又有邮箱，这种情况应该使用“手机号”和“邮箱”两个属性而不能采用“联系方式”一个属性来存储。

2NF

第二范式（2NF）即在1NF基础上，所有非主属性完全依赖于主属性。

完全依赖：设一函数依赖x→y，若存在z，使得z→y成立。称x→y为局部依赖，否则称x→y为完全依赖

例子：学生的班级与班主任，若学生表设计为

学号→班主任与班级→班主任同时成立，如果班集更换班主任，需要修改该班级所有学生的记录。设计违反第二范式。正确的设计方式为

3NF

第三范式（3NF）即在2NF基础上，任何非主属性不依赖于其它非主属性，要求一个关系中不包含已在其它关系已包含的非主关键字信息，即不存在依赖的传递。

设存在函数依赖x→y→z，称z传递依赖与x

例子：课程信息

如果教师并没有代课，那么教师的职称无法存储，即存在课程→教师→职称，对于教师的职称属性构成传递依赖。设计违反第三范式，正确的设计方式为

BCNF

巴斯-科德范式（BCNF）即在3NF基础上，主属性不依赖于主属性，若满足第三范式且只有一个候选码，即达成BC范式。

例子：学生的选课信息，设计为关联表：

学生表：

教师表：

课程表

选课表

“小明”，“李老师”和“高数”分别是“学生”，“教师”和“课程”的主属性，如果没有学生选李老师的高数课，那么李老师代有没有代高数？合理的设计为：

增加教师代课表

修改选课表