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