数据库三范式

一、建表时有主键，有些时候id算是一个主键，但还有其他几个字段组合在一起的时能够确定一条记录（此时也是这几个字段合在一起也算主键，例如mysql的唯一索引）

 

二、函数依赖

1、完全函数依赖

假设AB两个字段是主键，通过AB两个字段能够确定C字段的值，此时C完全依赖于AB。

2、部分函数依赖

假设AB两个字段是主键，通过字段A或者B中的一个，就可以确定C字段的值，那么此时C就是部分依赖与AB。

3、传递依赖

根据A能够确定B，根据B能够确定C，则此时C传递依赖与A。

 

三、三范式

1、第一范式

1

我的理解：正常我们的关系型数据库建表都符合第一范式的。。而NoSql则大多数不符合第一范式。

第一范式需要满足属性字段不可能切分原则。。

mysql表中，只要每个字段对应一个属性，那么就符合第一范式。。当然，也有不符合第一范式的例子。比如某个字段是json数据（json对象不是又可以分为多个key-value么，这多个key-value就相当于切割成多个属性了，所以不符合第一范式。。所以说为什么noSql大多不符合第一范式，因为redis或者mongodb存的基本是各种嵌套json）

 

2、第二范式

我的理解：

上面说了，姓名并不完全依赖于（学号，课名），因为通过学号就可以确定学生姓名了。所以姓名是部分依赖于（学号，课名）。

所以去除部分函数依赖就要把该部分函数依赖关系单独拆除一张表。。。姓名依赖于（学号，课名）中的学号，则可以把姓名与学号单独拆成一张表。

3、第三范式

我的理解：

消除上面的传递函数依赖，A->B>C,则把原表拆成A与B，和B与C两张表，此时就符合了

 

参考自尚硅谷大数据项目之电商数仓（3.系统业务数据仓库）