数据库的三范式

第一范式(1NF) 无重复的属性列

即实体中的某个属性值只有唯一的一列

学生表Student(stuNo,stuName,age,age,sex) Error
学生表Student(stuNo,stuName,age,sex) Right

第二范式(2NF)属性完全依赖于主关键字(消除部分子函数依赖)

第二范式建立在第一范式的基础上,要求数据库表中的每一个实例(行)能够被唯一的区分
(所以通常为表加上ID列,使每个实例可以被区分)
这里的主关键字可能不止一个,有些情况下是存在联合主键的(主键有多个属性)
[主关键字]{}

StuGrade(stuNo,stuName,age,sex,courseNo,courseName,credit,score)
主关键字是{stuNo,courseNo} 但是age、sex这样的属性知道stuNo就可以知晓,并不是完全依赖主关键字
所以不满足第二范式(属性要完全依赖于主关键字),被拆分成下表:
Studnet(stuNo,stuName,age,sex)
Course(courseNo,courseName,credit)
StuGrade(stuNo,courseNo,score)

第三范式(3NF)属性不依赖于其它非主属性 (消除传递依赖)

要求一个数据库表中不包含已在其它表中已包含的非主关键字信息

Employee(emp_id,emp_name,emp_age,dept_id,dept_name,dept_info)
如果存在上表,可以看到员工ID可以作为主键,但是部门名称,部门信息又都依赖于部门ID,部门ID又依赖于员工ID
(即 传递依赖)

Employee(emp_id,emp_name,emp_age,dept_id,dept_name,dept_info)
拆分成如下表:
Employee(emp_id,emp_name,emp_age,dept_id)

Dept(dept_id,dept_name,dept_info)

相关名词

超键:实体关系中唯一标识一实体的集合。

eg.
学生表Student(stuNo,stuName,age,sex)中{{stuNo},{stuNo,stuName},{age,sex}..}都可以是超键

候选键:除了唯一决定实例的属性(ID)这一个外,没有其他多余的非决定属性的超键

主键:指在几个候选键里面,随便选出一个就可以作为主键。主键又称为主关键字,主码等。可以是几个属性的集合。

主属性:只有一个属性的主键称为主属性。

非主属性:不包含在任何一个候选键中的属性称为非主属性。

完全依赖:指不存在部分依赖,对属性集合中的一个属性依赖。

(每个表中的所有字段,都完全依赖关键字,这也是3NF的核心定义:第三范式(3NF)属性不依赖于其它非主属性)

2020年12月09日add
1、one to one
每个人都有唯一的身份证号
实践上我们常常可以将其合并为一个实体,但是如果是业务上有实际含义的两实体
数据表的设计上是一个表建立外键指向另一张表,同时再该外键上建立唯一约束。

2、one to many
学生和班级的问题
设计表时只需要再学生表中添加一个班级实例的ID。(对应实践中对物料的分组管理也是一样,相关物料表新增GroupId)
即在many对应表的表中建立one表的外键
3、many to many
学生选课的情况
设计表时就需要搞一张关系表来存这些多对多的关系(建立两表外键的联合主键)
也可以扩展这张关系表让它变得有血有肉,变为一张有意义的实体表
模型中我们有上面三种关系,正式的关系数据库中,只有外键

参考:数据库表设计

你可能感兴趣的:(数据库的三范式)