目录
设计数据库时，遵从不同的规范要求，设计出合理的关系型数据库，这些不同的规范要求被称为不同的范式。常用的有第一范式，第二范式，第三范式，越高的范式数据库冗余越小。
基础知识：
是不是感觉看不懂：下面介绍一下基础知识
1.函数依赖：A-->B，如果通过A属性(属性组)的值，可以唯一确定B属性的值，则称B依赖于A。[属性即数据表的列字段]
如：学号--->姓名，(学号，课程名称)--->分数
2.完全函数依赖：A--->B，如果A是一个属性组，则B属性值的确定需要依赖于A属性组中所有的属性值。
如：(学号，课程名称)--->分数
3.部分函数依赖：A--->B，如果A是一个属性组，则B属性的确定只需依赖于A属性组中的某一些值即可。
4.传递依赖：A-->B，B-->C，如果通过A属性(属性组)的值，可以确认唯一B属性的值，再通过B属性(属性值)可以唯一确认C属性的值，那么C传递依赖于A。
5.码：如果在一张表中，一个属性或属性组，被其他所有属性所完全依赖，则这个属性(属性组)为该表的码。
主属性：码属性组中的所有属性
一、第一范式：每一列都是不可分割的原子数据项
由下表说明：
举例说明：
在上面的表中，“家庭信息”和“学校信息”列均不满足原子性的要求，故不满足第一范式，调整如下：
可见，调整后的每一列都是不可再分的，因此满足第一范式（1NF）；
存在问题：
但是存在一个问题就是，只满足第一范式的表很可能会存在数据冗余，例如：
例如李白后来又读了个博士，或者李白从研二升到研三，然后表里就会有不止一条李白的数据，这其实并不是也别好的设计。
二、第二范式：在第一范式的基础上，非码属性必须完全依赖于码
即在第一范式的基础上，消除非主属性对主码的部分函数依赖。
第二范式需要确保数据库表中的每一列都和主键相关，而不能只与主键的某一部分相关（主要针对联合主键而言）。
==============
严格来说
主属性：指主键列，即主键由一列构成
主键定义:能够唯一标识一个元组的属性或属性集，即可以由多列组成。
在教学中，大多实例都是主键由一列构成，所以也可以简单地说主属性与主键没有什么区别。
==============
举例说明：
在上图所示的情况中，同一个订单中可能包含不同的产品，因此主键必须是“订单号”和“产品号”联合组成，
但可以发现，产品数量、产品折扣、产品价格与“订单号”和“产品号”都相关，但是订单金额和订单时间仅与“订单号”相关，与“产品号”无关，
这样就不满足第二范式的要求，调整如下，需分成两个表：
三、第三范式：在第二范式的基础上，消除传递依赖
第三范式需要确保数据表中的每一列数据都和主键直接相关，而不能间接相关。
举例说明：
上表中，所有属性都完全依赖于学号，所以满足第二范式，但是“班主任性别”和“班主任年龄”直接依赖的是“班主任姓名”，
而不是主键“学号”，所以需做如下调整：
这样以来，就满足了第三范式的要求。
四、表与表之间的对应关系
上面说了三大范式，有些范式会给表分成两个表或者多个表，那多表之间又是怎么联系呢？
1. 多对一
例如下述表，多个员工可以对应同一个部门：
表与表之间通过外键连接，在多的一方建立外键，指向一的一方的主键。
2. 多对多
例如学生表和课程表：
多对多的情况就需要创建第三张表作为中间表，然后表中的字段作为外键，分别指向两张表的主键
例子：
286
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
