核心思想
1.第一范式 要求消除拆分字段至原子字段，即不可再拆分；
2.第二范式 要求消除部分函数依赖，实现完全函数依赖;
3.第三范式 要求消除传递函数依赖;
函数依赖: A列属性跟主键有关系
部分函数依赖: A列属性只跟主键的部分属性有关系
完全函数依赖: A列属性跟主键的全部属性有关系
传递函数依赖: A列属性跟B列属性有关系,B列属性跟主键有关系
举个栗子
栗子
除开道德问题,图上数据库表设计存在多少中设计缺陷
Q1:
’人物特色(渣男)'列还可以再拆分,解耦,能更适合变化(违背第一范式原则)
其实渣男类型还可以有很多的组合
Q2:
严重的传递依赖,(违背第三范式原则)
-----‘女友姓名’,‘学历信息(女友)’,'年龄’等等 都跟渣男没有关系,不是渣男的本身属性
如: 年龄→女友名→男友姓名
这会衍生出二个问题
Q2-1:
如果这系统突然进入了一个’萌新妹子’,她的数据录入不合法,(她需要先遇到一个渣男)
这也太不公平,太扯了…也许她只是想认识博主这种 母胎单身,风度翩翩,才华横溢的好人
Q2-2:
如果’赵六’这人,突然分手了,不渣了,删除这条记录,那么’小紫’这个人,也被删除了,该系统查不到她信息了
这也太扯了,其实她还可以…
改进2.0版
经过了第一范式,第三范式后,依然存在着问题
Q3:
在’渣男渣女关系表’中 —‘渣男编号’'渣女编号’组成复合主键
’年龄’属性只与’渣女编号’有关(违背了第二范式),同理’医院到访次数’的设计正确
第二范式知识点
实体表中一般不会出现违反第二范式的情况，因为都是“一个”主键列，而关系表是两个以上列的“复合”主键，故而关系表容易出现违反 第二范式 的情况。
主要是该关系表非主键外的属性，本该属于相关的某个实体表的，却放到了该关系表中，这使得该属性不能通过该关系表的复合主键唯一确定，DML操作会发生错误；
改进3.0
一条华丽的分割线,三大范式讲完,现在难度升级
难度升级
现在我们添加了一些表,
上面的图表都满足三大范式,都已经不可拆分,都跟主键完全依赖,也没有传递依赖
但在使用体验上还是有设计问题
Q4:
’宝宝表’中 名字为AA的宝宝他妈妈是谁?
查询顺序是: 宝宝表→接生记录表→住院记录表→渣女表
这也太难受了,就像物理学的’功’一样,万事万物皆在做’功’,需要消耗能量;
在IT界也一样,这太消耗资源跟性能,太慢了.
反范式冗余字段
我们为什么不冗余呢,让宝宝编号或姓名(看需求),冗余到渣女表
衡量的度
- 当SQL关连查询涉及到4张表时可考虑采用冗余字段
- 一般的，每间隔一级增加一个冗余外键
衍生一个问题
如何保证冗余字段数据的正确性（一致性）是反范式化的关键
- 如果在程序开发前设计的冗余字段，可以在正常的业务逻辑程序中一并处理
- 如果是程序完成之后增加的冗余字段，可以使用触发器维护
- 对于OLAP中大量存在冗余字段，可能需要使用单独的处理任务进行维护
OLTP/OLAP科普
OLTP—On-Line Transaction Processing联机事务处理过程（OLTP），也称为面向交易的处理过程。
OLAP—软件技术,使分析人员能够从多方面角度观察信息，深入理解数据。
- OLTP系统的模型，需满足第二范式（2NF）要求，设计上不追求满足第三范式（3NF）
- OLTP系统中在完成范式化工作之后，对某些表，可以适当反范式化增加冗余字段以提高数据访问性能；在OLAP中采用的是面向问题的设计思想，应该大量使用反范式化冗余信息
声明
本文仅娱乐,不涉及任何种族歧视,性别歧视;
不代表博主价值观,爱情观
把我录入改系统也只能填 编号,姓名,迷惑点
作业
4.0版本依然不完美,你们知道如果想知道孩子的父亲是谁,应该怎么改吗?
原文出处:https://www.chrisyoung777.com/blog/index.php/archives/16/
原创不易,未经博主允许，禁止转载