当前位置:网站首页>【数据库 三大范式】一看就懂
【数据库 三大范式】一看就懂
2022-07-06 09:22:00 【不许秃】
三大范式
第一范式 (1NF)
确保数据库字段的原子性(即不可分性);
*例:判断下表是否符合第一范式?
编号 | 姓名 | 电话 |
1 | 薛宝钗 | 10076 |
2 | 贾宝玉 | 10086 |
3 | 林黛玉 | 10096 |
首先我们要根据业务需求来判断字段的原子属性,上表唯一可拆分的是姓名,如果业务认为姓名为一个字段,则该表满足第一范式;但如果业务要求我们姓名要写成两个字段(姓氏和名字),则不满足第一范式,将姓名拆分开后即可满足(如下图)。
编号 | 姓氏 | 名字 | 电话 |
1 | 薛 | 宝钗 | 10076 |
2 | 贾 | 宝玉 | 10086 |
3 | 林 | 黛玉 | 10096 |
第二范式 (2NF)
在满足1NF的基础上,还包含两个内容:
(1)表必须要有一个主键
(2)非主键列必须完全依赖主键,不能只依赖主键的一部分(不可部分依赖);
*例:判断下表是否符合第二范式?(设定:此表的业务需求满足第一范式)
姓名 | 性别 | 电话 | 部门名称 | 部门楼层 |
薛宝钗 | 女 | 10076 | 公关部 | 5层 |
贾宝玉 | 男 | 10086 | 宣传部 | 3层 |
林黛玉 | 女 | 10096 | 公关部 | 5层 |
首先在第一范式的基础上,我们可以看出该表的主键为复合主键.(姓名+部门名称),满足内容(1)表必须要有一个主键
其次,我们发现非主键列是部分依赖主键 而非完全依赖主键: 非主键列性别、电话依赖于姓名,非主键列部门楼层依赖于部门名称
不满足内容(2)非主键列必须完全依赖主键,不能只依赖主键的一部分
为符合第二范式,我们将表进行拆分并优化
工号 | 姓名 | 性别 | 电话 |
101 | 薛宝钗 | 女 | 10076 |
102 | 贾宝玉 | 男 | 10086 |
103 | 林黛玉 | 女 | 10096 |
部门编号 | 部门名称 | 部门楼层 |
1 | 公关部 | 5层 |
2 | 宣传部 | 3层 |
1 | 公关部 | 5层 |
部门编号 | 工号 | 姓名 | 性别 | 电话 |
1 | 101 | 薛宝钗 | 女 | 10076 |
2 | 102 | 贾宝玉 | 男 | 10086 |
1 | 103 | 林黛玉 | 女 | 10096 |
我们把 部门编号设为部门表的主键(总表的外键)、工号设为总表的主键,是因为它们没有实际上的业务意义,这样我们在修改数据的时候(比如说更改姓名、部门名称),就不用一行一行那么麻烦去改。
第三范式 (3NF)
在满足2NF的基础上,另外非主键列必须直接依赖主键(不能依赖非主键),不能存在传递依赖,
即不能存在A依赖于B,B依赖于C;
(其中A、B为非主键列,C为主键)
*例:判断下表是否符合第三范式?(此表的业务已需求满足第二范式)
部门编号 | 工号 | 姓名 | 性别 | 电话 | 职位 | 工资 |
1 | 101 | 薛宝钗 | 女 | 10076 | 正式 | 8000 |
2 | 102 | 贾宝玉 | 男 | 10086 | 实习 | 4000 |
1 | 103 | 林黛玉 | 女 | 10096 | 正式 | 8000 |
为符合第三范式,我们将表进行拆分并优化
首先在第一范式的基础上,我们可以看出该表的非主键列工资依赖于非主键列职位,存在传递依赖,即不符合第三范式的要求
工号 | 姓名 | 性别 | 电话 |
101 | 薛宝钗 | 女 | 10076 |
102 | 贾宝玉 | 男 | 10086 |
103 | 林黛玉 | 女 | 10096 |
部门编号 | 部门名称 | 部门楼层 |
1 | 公关部 | 5层 |
2 | 宣传部 | 3层 |
1 | 公关部 | 5层 |
职位编号 | 职位 | 工资 |
01 | 正式 | 8000 |
02 | 实习 | 4000 |
01 | 正式 | 8000 |
部门编号 | 工号 | 姓名 | 性别 | 电话 | 职位编号 |
1 | 101 | 薛宝钗 | 女 | 10076 | 01 |
2 | 102 | 贾宝玉 | 男 | 10086 | 02 |
1 | 103 | 林黛玉 | 女 | 10096 | 01 |
解释可以参考第二范式的结尾内容
ps:一定要从业务需求(也就是场景)出发去判断是否符合第几范式
为什么要学范式?
当我们和客户沟通业务需求 或者是 去完成一个项目的时候,需要我们去设计合适的数据模型。此时,规范化设计的重要性就凸显出来了。
范式是什么?
范式是符合某一种级别的关系模式的集合。构造数据库必须遵循一定的规则(在关系数据库中,这种规则指的就是范式))。关系数据库中的关系必须满足一定的要求,即满足不同的范式。
学习范式能够解决什么问题?
学会规范化设计能解决以下问题:
1.数据冗余
2.异常问题:
更新异常
插入异常
删除异常
边栏推荐
- [the Nine Yang Manual] 2016 Fudan University Applied Statistics real problem + analysis
- 3.猜数字游戏
- 3. C language uses algebraic cofactor to calculate determinant
- Inaki Ading
- 7-8 7104 约瑟夫问题(PTA程序设计)
- Implementation principle of automatic capacity expansion mechanism of ArrayList
- [the Nine Yang Manual] 2020 Fudan University Applied Statistics real problem + analysis
- Custom RPC project - frequently asked questions and explanations (Registration Center)
- Principles, advantages and disadvantages of two persistence mechanisms RDB and AOF of redis
- 3.C语言用代数余子式计算行列式
猜你喜欢
透彻理解LRU算法——详解力扣146题及Redis中LRU缓存淘汰
Mortal immortal cultivation pointer-1
6.函数的递归
一段用蜂鸣器编的音乐(成都)
Wei Pai: the product is applauded, but why is the sales volume still frustrated
关于双亲委派机制和类加载的过程
FAQs and answers to the imitation Niuke technology blog project (III)
撲克牌遊戲程序——人機對抗
C language Getting Started Guide
3.猜数字游戏
随机推荐
甲、乙机之间采用方式 1 双向串行通信,具体要求如下: (1)甲机的 k1 按键可通过串行口控制乙机的 LEDI 点亮、LED2 灭,甲机的 k2 按键控制 乙机的 LED1
4.二分查找
优先队列PriorityQueue (大根堆/小根堆/TopK问题)
2.C语言矩阵乘法
2022泰迪杯数据挖掘挑战赛C题思路及赛后总结
7-5 走楼梯升级版(PTA程序设计)
自定义RPC项目——常见问题及详解(注册中心)
[hand tearing code] single case mode and producer / consumer mode
7-11 机工士姆斯塔迪奥(PTA程序设计)
记一次猫舍由外到内的渗透撞库操作提取-flag
MySQL lock summary (comprehensive and concise + graphic explanation)
The latest tank battle 2022 - full development notes-3
MySQL中count(*)的实现方式
MySQL锁总结(全面简洁 + 图文详解)
【九阳神功】2022复旦大学应用统计真题+解析
[the Nine Yang Manual] 2018 Fudan University Applied Statistics real problem + analysis
Caching mechanism of leveldb
C语言入门指南
Aurora system model of learning database
[modern Chinese history] Chapter V test