数据库三范式——举例说明

范式一：
所有条目不可再分，所谓的原子性。
这条最好理解，举例说明。

这就是错的，电话又分了两类。改成1范式是这样：

看，这样就是原子性，每一条都不能再分。

范式二：
范式二消除了数据库中的部份依赖关系，所有实体属性必须完全依赖主关键字，这个主关键字必须对每一个条目都是唯一的，例如学号、身份证这类。

看这个表，如果一个叫张的人来了，你得问它年龄和语言两个属性才能确定他对应的是哪一个条目，也就是说张这个人要依赖于年龄和语言两个属性，既然是两个属性那就肯定不是完全依赖。如果这个表是这样的：

这时候把员工编号作为主关键字(主键),根据定义属性完全依赖于主键，即主键可以推出属性，那给个编号1，你一看表必能认出编号1对应哪一条数据。
还有一个名词，候选键，意为可以被当成主键用的属性。有的时候一个表里可能有好几个候选键也不是不可能。

范式三：
范式三消除了传递依赖。
所谓传递依赖，举个小例子，学校组织老师集体旅行，要记录房间号、教师名称、职称。

很明显，一个房间号只会对应一个教师名，一个教师名只会对应一个职称，即房间号→教师名→职称。
这就叫传递依赖。
怎么消除呢？拆成两个表就行了：

————————————————————————————————————————————
大概就是这样。关系型数据库就遵循这几个范式，其他还有456范式就不多说了，这里只提供一点直观理解。

ps:既然有关系型数据库，就有非关系型数据库，称为NoSQL，就不解释了，因为我不会。
ps:为什么非要把一个表拆成俩表？总的来说就是为了不出现异常，异常包括
删除异常：某一属性的值删光了就再也找不回来了
插入异常：想新插入一个属性的值没地方插，因为它不是主键，而想插入的条目必须有主键，这就尴尬了。
数据冗余：一个老师改名了而且还改职称了，选他课的学生有10000个，就得改20000个值。用了范式三，工作量降一半。