数据库表设计的三范式（三大范式及反范式冗余字段）

1.第一范式 要求消除拆分字段至原子字段，即不可再拆分；

2.第二范式 要求消除部分函数依赖，实现完全函数依赖;

3.第三范式 要求消除传递函数依赖;

函数依赖: A列属性跟主键有关系

部分函数依赖: A列属性只跟主键的部分属性有关系

完全函数依赖: A列属性跟主键的全部属性有关系

传递函数依赖: A列属性跟B列属性有关系,B列属性跟主键有关系

举个栗子

栗子

人渣系统1.0-我叫栗子

除开道德问题,图上数据库表设计存在多少种设计缺陷

Q1:

’人物特色(渣男)'列还可以再拆分,解耦,能更适合变化(违背第一范式原则)

其实渣男类型还可以有很多的组合

Q2:

严重的传递依赖,(违背第三范式原则)

‘女友姓名’,‘学历信息(女友)’,'年龄’等等 都跟渣男没有关系,不是渣男的本身属性

如: 年龄→女友名→男友姓名

---

这会衍生出二个问题

Q2-1:

如果这系统突然进入了一个’萌新妹子’,她的数据录入不合法,(她需要先遇到一个渣男)

这也太不公平,太扯了…也许她只是想认识博主这种 母胎单身,风度翩翩,才华横溢的好人

Q2-2:

如果’赵六’这人,突然分手了,不渣了,删除这条记录,那么’小紫’这个人,也被删除了,该系统查不到她信息了

这也太扯了,其实她还可以…

---

改进2.0版

人渣系统2.0--第一范式后

人渣系统2.0--第三范式后

经过了第一范式,第三范式后,依然存在着问题

Q3:

在’渣男渣女关系表’中 —‘渣男编号’'渣女编号’组成复合主键

’年龄’属性只与’渣女编号’有关(违背了第二范式),同理’医院到访次数’的设计正确

第二范式知识点

实体表中一般不会出现违反第二范式的情况，因为都是“一个”主键列，而关系表是两个以上列的“复合”主键，故而关系表容易出现违反 第二范式 的情况。

主要是该关系表非主键外的属性，本该属于相关的某个实体表的，却放到了该关系表中，这使得该属性不能通过该关系表的复合主键唯一确定，DML操作会发生错误；

改进3.0

人渣系统3.0--第二范式后

---

一条华丽的分割线,三大范式讲完,现在难度升级

---

难度升级

现在我们添加了一些表,

上面的图表都满足三大范式,都已经不可拆分,都跟主键完全依赖,也没有传递依赖

但在使用体验上还是有设计问题

Q4:

’宝宝表’中 名字为AA的宝宝他妈妈是谁?

查询顺序是: 宝宝表→接生记录表→住院记录表→渣女表

这也太难受了,就像物理学的’功’一样,万事万物皆在做’功’,需要消耗能量;

在IT界也一样,这太消耗资源跟性能,太慢了.

反范式冗余字段

我们为什么不冗余呢,让宝宝编号或姓名(看需求),冗余到渣女表

人渣系统4.0--反范式冗余

衡量的度

当SQL关连查询涉及到4张表时可考虑采用冗余字段一般的，每间隔一级增加一个冗余外键

衍生一个问题

如何保证冗余字段数据的正确性（一致性）是反范式化的关键

• 如果在程序开发前设计的冗余字段，可以在正常的业务逻辑程序中一并处理
• 如果是程序完成之后增加的冗余字段，可以使用触发器维护
• 对于OLAP中大量存在冗余字段，可能需要使用单独的处理任务进行维护

OLTP/OLAP科普

OLTP—On-Line Transaction Processing联机事务处理过程（OLTP），也称为面向交易的处理过程。

OLAP—软件技术,使分析人员能够从多方面角度观察信息，深入理解数据。

OLTP/OLAP

OLTP系统的模型，需满足第二范式（2NF）要求，设计上不追求满足第三范式（3NF）OLTP系统中在完成范式化工作之后，对某些表，可以适当反范式化增加冗余字段以提高数据访问性能；在OLAP中采用的是面向问题的设计思想，应该大量使用反范式化冗余信息

声明

本文仅娱乐,不涉及任何种族歧视,性别歧视;

不代表博主价值观,爱情观

把我录入该系统也只能填 编号,姓名,迷惑点

作业

4.0版本依然不完美,你们知道如果想知道孩子的父亲是谁,应该怎么改吗?

原文出处:https://www.chrisyoung777.com/blog/index.php/archives/16/原创不易,未经博主允许，禁止转载

,