【个人机房重构】——创建数据库三部曲

　　进行过了基础三层思想的熏陶，立即就进入了个人机房重构的阶段，感觉自己这仅仅菜鸟中的菜鸟,任重而道远。要想建造高楼大厦。必须有水泥、砖瓦。

数据库是管理数据资源的容器。以下是我自己建表的过程，假设有不妥的地方。还请大家指正！

一、“三范式”了然于胸

优点：关系数据库的规范。为了降低数据冗余。满足三范式。说明数据库比較健全，数据冗余少。后期维护方便。

具体内容：

第一范式（1NF）：数据库表中的字段都是单一属性，不可再分，确保了每列的原子性。

比如：住址就要拆成 省份城市，直到不能拆了为止。

第二范式（2NF）：第一范式的升级版~目标是确保表中的每列都和主键相关。

比如：比方要设计一个学生考试成绩表（表1），联合主键是学号和课程。
学号作为主键，学分只跟课程相关。
这样就违背了第二范式的设计原则。

所以，遇到这种情况。我们就应该把这个表进行拆分，把学生信息分离到一个表（表2.0），课程信息分离到还有一个表（2.2）.

假设不拆分。会出现什么问题？

数据冗余：假设1个同学选修n门课程。那么学生信息就会被反复n-1次（表3的1区是数据冗余的地方），n个同学选修1门课程。课程和学分也会被反复n-1次。

更新异常：假设须要更新一门课程的学分，表中全部的学分都要更新，否则会出现同课不同学分的情况。

假设添加课程。临时没有学生选修，没有主键：学号，就不能再数据库中存入课程信息。

删除异常：假设一批学生毕业，要删除成绩记录，课程名称、学分都会被删除，难不成还要等开学了，进来一批新的学生再填进去？？？

第三范式（3NF) ：在第二范式的基础上更进一层。确保每列都和主键列直接相关，而不是间接相关。

比如：一个学生信息的表（表4）。存在决定关系：学号——>姓名、年龄、性别。还存在以下的决定关系

学号——>卡号——>剩余金额、状态，存着剩余金额、状态对学号的传递依赖，是间接相关的。违反了第三范式的原则。

因此把它拆分成表5和表6就非常完美啦！