【数据库-通用知识系列-01】数据库规范化设计之范式,让数据库表看起来更专业

我们在设计数据库时考虑的因素包括读取性能,数据一致性,数据冗余度,可扩展性等,好好学习数据库规范化的知识,设计的数据库表看起来才专业。

范式一览

【数据库-通用知识系列-01】数据库规范化设计之范式,让数据库表看起来更专业_第1张图片

“键”理解:

  • 超键:在关系中能唯一标识元组的属性集称为关系模式的超键
  • 候选键:不含有多余属性的超键称为候选键。也就是在候选键中,若再删除属性,就不是键了。
  • 主键:用户选作元组标识的一个候选键称为主键。
  • 外键:如果关系模式R中属性K是其它模式的主键,那么K在模式R中称为外键。

主键为候选键的子集,候选键为超键的子集,而外键的确定是相对于主键的!

0NF(Not Normal Form)

一个员工有多个电话,用“,”分割,我们常常这样设计,的确这样设计没毛病,干嘛再设计一个写的电话表,还要关联,浪费时间。的确,我们有些情况下确实这样设计。但是他不符合数据库的规范,为什么呢:

  1. 首先看Phone,字段长度不明确,我们应该定义多长,长了浪费,短了业务不允许。
  2. 统一每个人有多少电话,没法统计。
  3. 可维护性差,我删除个电话,更换个电话不好弄。
  4. 扩展性差,哪个是主,哪个是次,哪个是家庭,哪个是工作电话怎么搞。

所以就有了1NF,设计上还是不要有分割,保持原子性。

EmployeeId Person Phone
1 John Jones 27716602, 26153215,
2 Peter Janes 47716602, 36153215, 52321262
3 Michael Juines 17716602

1NF(First Normal Form)

定义:第一范式是指数据库的每一列都是不可分割的基本数据项,强调列的原子性。

我们改造一下上边的表结构,这样就符合了第一范式:

EmployeeId Person Phone
1 John Jones 27716602
1 John Jones 26153215
2 Peter Janes 47716602
2 Peter Janes 36153215
2 Peter Janes 52321262
3 Michael Juines 17716602

上边第一范式的设计好吗?不太优雅吧,我们有太多的冗余,如果现在Peter有3个电话占了三行,若有Peter有100个电话呢,是不是要有100行一样的EmployeeId和Person。可能你会说,也占用不了太多的空间呀,那我要问你Peter还有100多个属性呢,所以说,第一范式是没有考虑数据冗余的。我们要消灭数据冗余,就要考虑2NF。

2NF(Second Normal Form )

定义:第二范式建立在第一范式的基础上,即满足第二范式一定满足第一范式,第二范式要求数据表每一个实例或者行必须被唯一标识。除满足第一范式外还有两个条件,一是表必须有一个主键;二是没有包含在主键中的列必须完全依赖于主键,而不能只依赖于主键的一部分。

上表的主键现在是什么,竟然是EmployeeId和Phone组成的联合主键,而Name只依赖于EmployeeId。这就不符合Employee的建表目的了,name只依赖于EmployeeId就好,Phone在这凑什么热闹,把Phone单独建张表吧:

EmployeeId Name
1 John
2 Peter
3 Michael
PhoneId Phone
1 27716602
2 26153215
3 47716602
4 36153215
5 52321262
6 17716602
EmployeeId PhoneId
1 1
1 2
2 3
2 4
2 5
3 6

3NF(Third Normal Form)

定义: 若某一范式是第二范式,且每一个非主属性都不传递依赖于该范式的候选键,则称为第三范式,即不能存在:非主键列 A 依赖于非主键列 B,非主键列 B 依赖于主键的情况。

第三范式其实也和第二范式一个目的,减少数据冗余。为了说明第3范式,我们增加个邮编地址,如下表所示。

EmployeeId Name ZIP City
1 John 8000 Aarhus C
2 Peter 8200 Aarhus N
3 Michael 8520 Lystrup

上表明显满足第二范式,但是是不是感觉City多余,明明非主属性ZIP知道了就知道非主属性EmployeeId在哪个城市了。好了,这里出来了一个传递依赖,消灭掉如下:

EmployeeId Name ZIP
1 John 8000
2 Peter 8200
3 Michael 8520
ZIP City
8000 Aarhus C
8200 Aarhus N
8520 Lystrup

BCNF(Boyce and Codd Normal Form)

下表满足:

  1. 1个学生可以选择多门课程,比如101选了java和C++。
  2. 一个教授教一门课程,可以有多个教授教一门课程,比如Java对应三个教授。
studentId subject professor
101 Java P.Java
101 C++ P.Cpp
102 Java P.Java2
103 C# P.Chash
104 Java P.Java

该设计满足3NF,因为主键为studentId和subject,满足1NF,所有值都是原子;满足2NF,不存在部分依赖。满足3NF,不存在传递依赖。但是不是BCNF,原因如下:

professor->subject

subject是一个主属性,而professor为非主属性,所以不满足BCNF。修改如下:

Student Table

student_id p_id
101 1
101 2

Professor Table

p_id professor subject
1 P.Java Java
2 P.Cpp C++

原文:[实践派]-数据库规范化

你可能感兴趣的:(数据库通用知识,数据库)