数据库设计范式

概念

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

1NF

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

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

学号 联系方式
1 138****8888
2 123456@my.com

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

学号 手机 邮箱
1 138****8888
2 123456@my.com

2NF

第二范式(2NF)即在1NF基础上,所有非主属性完全依赖于主属性

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

例子:学生的班级与班主任,若学生表设计为

学号 班级 班主任
1 三年二班 李老师

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

学号 班级
1 三年二班
班级 班主任
三年二班 李老师

3NF

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

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

例子:课程信息

课程 教师 教师职称
高数 李老师 教授

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

课程 教师
高数 李老师
教师 教师职称
李老师 教授

BCNF

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

例子:学生的选课信息,设计为关联表:

学生表:

学号 姓名
1 小明

教师表:

教师工号 教师姓名
1 李老师

课程表

课程编号 课程名称
1 高数

选课表

选课记录ID 学号 教师工号 课程编号
1 1 1 1

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

增加教师代课表

代课记录ID 课程编号 教师工号
1 1 1

修改选课表

选课记录ID 学号 代课记录ID
1 1 1
Logo

助力广东及东莞地区开发者,代码托管、在线学习与竞赛、技术交流与分享、资源共享、职业发展,成为松山湖开发者首选的工作与学习平台

更多推荐