【个人机房重构】——创建数据库三部曲
进行过了基础三层思想的熏陶，马上就进入了个人机房重构的阶段，感觉自己这只菜鸟中的菜鸟,任重而道远。要想建造高楼大厦，必须有水泥、砖瓦。数据库是管理数据资源的容器，下面是我自己建表的过程，如果有不妥的地方，还请大家指正！
一、“三范式”了然于胸
好处：关系数据库的规范，为了减少数据冗余。满足三范式，说明数据库比较健全，数据冗余少，后期维护方便。
详细内容：
第一范式（1NF）：数据库表中的字段都是单一属性，不可再分，确保了每列的原子性。
例如：住址 就要拆成 省份 城市，直到不能拆了为止。
第二范式（2NF）：第一范式的升级版~目标是确保表中的每列都和主键相关。
例如：比如要设计一个学生考试成绩表（表1），联合主键是学号和课程。学号作为主键，学分仅仅跟课程相关。这样就违背了第二范式的设计原则。
所以，遇到这样的情况，我们就应该把这个表进行拆分，把学生信息分离到一个表（表2.0），课程信息分离到另一个表（2.2）.
如果不拆分，会出现什么问题？
数据冗余：如果1个同学选修n门课程，那么学生信息就会被重复n-1次（表3的1区是数据冗余的地方），n个同学选修1门课程，课程和学分也会被重复n-1次。
更新异常：如果需要更新一门课程的学分，表中所有的学分都要更新，否则会出现同课不同学分的情况。
如果增加课程，暂时没有学生选修，没有主键：学号，就不能再数据库中存入课程信息。
删除异常：如果一批学生毕业，要删除成绩记录，课程名称、学分都会被删除，难不成还要等开学了，进来一批新的学生再填进去？？？
第三范式（3NF) ：在第二范式的基础上更进一层。确保每列都和主键列直接相关，而不是间接相关。
例如：一个学生信息的表（表4），存在决定关系：学号——>姓名、年龄、性别，还存在下面的决定关系
学号——>卡号——>余额、状态，存着余额、状态对学号的传递依赖，是间接相关的。违反了第三范式的原则。
因此把它拆分成表5和表6就很完美啦！
当然第三范式也会出现数据冗余、更新异常、删除异常，详情与第二范式的类似。
二、“E-R图”分析利器
E-R（Enitity Relationship diagram） :提供了表示实体、联系、属性的方法，用来描述宏观世界的概念模型。
下图这是我画的E-R图。画图的过程是理清思路的过程。当初对充值、退卡等表只是会用，知道确定一个表里面有卡号、操作者的ＩＤ等信息。当时还觉得ＩＤ挺多余的，不过现在发现它和卡号组成了联合主键，起的作用还不小～
三、”SQL建表“落到实处
