函数依赖关系
完全函数依赖:
A和B能够推断出来C,但是单独的A或B无法推断出来C,那么称C完全依赖于A,B
部分函数依赖:
A和B能够推断出C,通过A能够推断出C,或者通过B也能推断出C,那么称C部分依赖于A,B
传递函数依赖:
A能够推断出B,通过B能够得到C,但是通过C得不到A,那么说C传递依赖于A
了解了上面的函数依赖之后,然后再来了解数据库设计三范式就比较清楚明了
第一范式
第一范式比较好理解,即列满足原子性,即列是不可分割的.
错误示范
image.png
正确示范:
image.png
第一范式是所有数据库的最基本要求.
第二范式:
第二范式是在第一范式的基础上建立起来的
不能存在非主键字段部分函数依赖与主键字段
image.png
上图主键为学号+姓名联合主键,主键是要能够唯一标识一行数据,当一个列不能唯一标识一行数据,可以采用联合主键
但是上图中,姓名并不完全依赖于学号+课程,他可以通过学号推断出来,所以出现了非主键字段部分依赖于主键字段,所以不满足
可以拆分成如下,去掉了部分函数依赖:
第三范式:
第三范式是在满足第二范式基础上出现的第三范式
不能存在 非主键字段传递函数依赖于主键字段
image.png
上图中,存在传递函数依赖,即
学号-->系名-->系主任,但是系主任推断不出学号,所以存在传递函数依赖,需要继续拆分
image.png
image.png
三范式小结:
数据库范式越高,数据冗余越低,但是伴随着需要join连接,必然导致性能下降,所以一味地追求范式并不是很好的决定,数据库范式是时间换空间.牺牲查询时间,节省了空间
因为你想想,就比如第二范式那块,拆分成的两个表一个,一个表就不带系名了,然后两个表通过关联能够得到最初的那个大表,这样就节省了存储空间.节省了存储系名的那个空间.
因为在早期互联网刚起步阶段,磁盘很贵,不像现在这么便宜,所以大家追求的是时间换空间,但是现在不一样了,磁盘很便宜,而且分布式技术的成熟,使得大家更看重,典型的比如数据仓库的事实表和维度表,就是空间换时间,允许一定的数据冗余,换来查询性能的提升,所以在数仓中并不是很看中三范式,甚至有些反三范式.
