范式
第一范式
字段不可分
定义:如果关系R中所有属性的值域都是单纯域,那么关系模式R是第一范式的。
那么符合第一模式的特点就有
- 有主关键字
- 主键不能为空
- 主键不能重复
- 字段不可以再分
例如:
![faffd8135dc2f14fd123ba3e5b55d207.png](https://i-blog.csdnimg.cn/blog_migrate/e4ae744320dbe247af98892a6545d7ec.jpeg)
以上的表就不符合第一范式:主键重复(实际中数据库不允许重复的),而且Contact字段可以再分
所以变更为正确的是
![8cec08b573f8a8e2194f0299c26f4d81.png](https://i-blog.csdnimg.cn/blog_migrate/08ba0abe8f2af5ce75809b848162a135.jpeg)
第二范式
不能有(一个或多个)非主键列部分依赖于主键的情况
定义:如果关系模式R是第一范式的,而且关系中每一个非主属性不部分依赖于主键,称R是第二范式的。
所以第二范式的主要任务就是:满足第一范式的前提下,消除部分函数依赖。
![5806a0c9a96d68b5f77d8d3c3ea0aba7.png](https://i-blog.csdnimg.cn/blog_migrate/962361d193f8d4fa55266196ce2586af.jpeg)
这个表完全满足于第一范式,主键由StudyNo和ClassNo组成,这样才能定位到指定行。但是,ClassAddress部分依赖于关键字( ClassNo → ClassAddress ),所以要变为两个表。
表一
![83227e4930fc76b046691b9a4801fae1.png](https://i-blog.csdnimg.cn/blog_migrate/58b9e8615fbfc074a33908aa5b1b8ab4.jpeg)
表二
![51822e0199fcfc405d3b91cdee9d37dd.png](https://i-blog.csdnimg.cn/blog_migrate/2fa3b8e50567e45a263abd32579c193f.jpeg)
第三范式
不能有(一个或多个)非主键列传递依赖于主键的情况
定义:不存在非主属性对码的传递性依赖以及部分性依赖。
![0e2cc885a01449402d9f00e2e10d5934.png](https://i-blog.csdnimg.cn/blog_migrate/01226a1640293e978384a869f39c1e43.jpeg)
现在,主键是StudyNo,主键只有单个字段,显然符合第二范式,但是bounsLevel和bouns存在传递依赖。
更改为:
![237f0274d34a2a5fc800a4a2854dcff5.png](https://i-blog.csdnimg.cn/blog_migrate/5f69c4f1a398702ac9cc88eb5021d222.jpeg)
![9502af1bbc84daedc78dc8ea145fc243.png](https://i-blog.csdnimg.cn/blog_migrate/70cc8078eaebcf9adf9d8d3f3ee038f4.jpeg)
这里我比较喜欢用bounsNo作为主键,基于两个原因
- 不要用字符作为主键。可能有人说:如果我的等级一开始就用数值就代替呢?
- 但是如果等级名称更改了,不叫 1,2 ,3或优、良,这样就可以方便更改,所以我一般优先使用与业务无关的字段作为关键字。
一般满足前三个范式就可以避免数据冗余。