【个人机房重构】——创建数据库三部曲
进行过了基础三层思想的熏陶,立即就进入了个人机房重构的阶段,感觉自己这仅仅菜鸟中的菜鸟,任重而道远。要想建造高楼大厦。必须有水泥、砖瓦。
数据库是管理数据资源的容器。以下是我自己建表的过程,假设有不妥的地方。还请大家指正!
一、“三范式”了然于胸
优点:关系数据库的规范。为了降低数据冗余。满足三范式。说明数据库比較健全,数据冗余少。后期维护方便。
具体内容:
第一范式(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图。绘图的过程是理清思路的过程。当初对充值、退卡等表仅仅是会用,知道确定一个表里面有卡号、操作者的ID等信息。当时还认为ID挺多余的。只是如今发现它和卡号组成了联合主键。起的作用还不小~
三、”SQL建表“落到实处
命名是专业素养的一种体现,同一时候规范的命名也便于我们后期的改动、维护。
能够选择菜单里面 工具——选项——Designers——表设计器和数据库设计器,去掉勾就可以。
四、总结
三范式。E-R图開始并没有好好的钻研过,仅仅是知道它对建表有非常大用处。虽不知。可是用的时候知道,就立即能学,节省了非常多走弯路的时间。
自从被老师逼着,认真的学了几天时间管理,发现头不疼了,眼不花了,干事有重点了,每天活的都非常有成就感。非常快乐。还没几天,自我感觉就不错了。坚持下去,小菜鸟有一天一定会成大鸟的,吼吼~