进行过了基础三层思想的熏陶，马上就进入了个人机房重构的阶段，感觉自己这只菜鸟中的菜鸟,任重而道远。要想建造高楼大厦，必须有水泥、砖瓦。数据库是管理数据资源的容器，下面是我自己建表的过程，如果有不妥的地方，还请大家指正！

一、“三范式”了然于胸

好处：关系数据库的规范，为了减少数据冗余。满足三范式，说明数据库比较健全，数据冗余少，后期维护方便。

详细内容：

第一范式（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建表“落到实处

　　个人感觉，这个地方的建表，建表语句并没有什么难的地方，重点要注意以下几点：

１．命名为什么要规范？

没有规矩不成方圆。命名是专业素质的一种体现，同时规范的命名也便于我们后期的修改、维护。

２．数据类型是char 还是 varchar？

char是定长的，当输入的字符小于指定的数目，char(8),输入的字符小于8，它会在后面补空值。如果大于8，会截取超出的字符。

varchar是长度为n个字节的可变长度且非Unicode的字符数据。n是介于1-8000之间的数值。相对节省存储空间。

因为char固定长度，所以在处理速度上要比varchar快很多，但是相对比较费存储空间，所以对存储不大，但在速度上有要求的可以使用char类型，反之可以用varchar.

其他字段的数据类型也要选择合适的，不能全部写成char类型了。

3.建表完成后不允许修改字段怎么办？

在SQL SERVER2008中，新建的表无法修改字段名和增加字段名。可以选择菜单里面  工具——选项——Designers——表设计器和数据库设计器，去掉勾即可。

四、总结

　　每次到最后都要扯上一点点自己的感受，以此记录我献身于计算机事业的心路历程（此处应该有掌声

Ｏ（∩＿∩）Ｏ～）。建表给我最大的感触是：１．不怕不知道，就怕不知道。三范式，Ｅ－Ｒ图开始并没有好好的钻研过，只是知道它对建表有很大用处。虽不知，但是用的时候知道，就马上能学，节省了很多走弯路的时间。

２．写东西是自己的看的，大不了恶心了别人～别人说的再好，自己照别人的操作一遍，也不如自己写一遍博客印象深刻。３．时间管理真是救苦救难的活菩萨啊！自从被老师逼着，认真的学了几天时间管理，发现头不疼了，眼不花了，干事有重点了，每天活的都很有成就感，很快乐。还没几天，自我感觉就不错了，坚持下去，小菜鸟有一天一定会成大鸟的，吼吼～

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