如何设计数据库表？
背景
最近在准备软件设计师的资格考试。首先表达一下我为什么会去考这个证，主要有以下两点：
- 薪资待遇，求职。虽然很多人说该证书没有用。但是有一些大厂会直接给你加薪的。我记得HK中级资格证书，每个月1000的补贴。高级资格证书是1500的补贴。并且在简历中，你有这个证书，HR对你的认可也会深刻。在福利面前，我建议大家尽量去考一下。
- 扩展知识面。这对我而言尤为重要。因为我本身并不是计算机专业的。只是在大三的时候为了找工作，突击编程，才进入这个领域的。虽然目前掌握的技能能够应付工作中的大部分任务。但是一但遇到一些难题就很难攻克。比如：系统CPU很高，如何降下来？如何管理项目？如何设计系统？也许，你可能会说，这些怎么可能是我负责的。我只是一个菜鸡啊。不想当将军士兵不是好士兵。为什么别人可以你不行呢？有的人可能会说，我只是一个才工作两年的新手，不会是可以理解的。等我工作时间长了，自然会了。
工作经验，我觉的往往被大家过于的夸大其词。我承认，工作经验是很重要，但是不是所有的东西都能靠经验弥补的。我就经历过（不是自夸）：有段时间，因为我的任务完成的比较快，组长就让我看看一个遗留下来的bug（涉及到CPU性能优化）。其实，我知道他只是让我找点事情做，并没有对我报太大希望。因为我的导师和几个老员工之前也看过，都没有解决。但是，由于我比较喜欢看一些书，了解操作系统的皮毛。这个问题，被我解决了（摄像头优化）。经过这件事，我深刻认识到，不是任何问题都可以用经验来衡量的，知识体系其实更加重要。
于是，我就准备通过考证，来建立我的技能体系。有一句话，我很喜欢：不要为了考证而去考证。所以，在学习每一章节的时候，我会尽量联系到我已有的工作上来或尝试用到某些方面。加深理解，也能提高工作上的效率。遇到感受很深刻的内容，我会记录下来，和大家分享一下。
如何评价数据库的优劣
本章的经验之谈，我觉得比较适合没有接触设计数据库的朋友，并且不会很深入，高手可以忽略啦。
工作中，我们根据需求进行数据库的设计，其实就是对表的字段设计，表中该有哪些字段是比较合理的。一般能够满足需求即可，很少会考虑到一些其他问题。其实对于数据库表的格式，是有评判优劣标准的（我也是看书知道的，以往评判一个表的好坏全由自己的经验而来）。
数据库的设计就是设计满足适当范式的模式。范式有1NF，2NF，3NF，BCNF，4NF和5NF。它们的关系是：5NF>4NF>BCNF>3NF>2NF>1NF。这里的范式，你可以认为是表中各个属性（字段）要满足对应范式的定义。实际工作中，我们一般满足3NF即可。
第一范式
定义：若关系模式R的每一个分量是不可再分的数据项，则关系模式R属于第一范式。
我的理解：就是表中的字段都是不可再分的数据项。如下表：
该表的就不满足第一范式，因为高级职称人数不是一个原子属性。将其拆分为教授和副教授则满足1NF。
第二范式
定义：若关系模式R属于1NF，且每个非主属性完全依赖于码，则关系模式R属于2NF.
我们先看下表：
关系模式：F={Sno->Sname,Sno->Status,Status->City,(Sno,Pno)->Qty}
| Sno | Sname | Status | City | Pno | Qty |
|---|---|---|---|---|---|
| S1 | 精益 | 20 | 天津 | P1 | 200 |
| S1 | 精益 | 20 | 天津 | P2 | 300 |
| S1 | 精益 | 20 | 天津 | P3 | 480 |
| S2 | 盛锡 | 10 | 北京 | P2 | 168 |
| S2 | 盛锡 | 10 | 北京 | P3 | 500 |
| S3 | 东方红 | 30 | 北京 | P1 | 300 |
| S3 | 东方红 | 30 | 北京 | P2 | 280 |
| S4 | 泰达 | 40 | 上海 | P2 | 460 |
我们知道可以分辨出该表满足1NF。但是存在4个问题：
- 冗余度大。例如，每个供应者的Sno,Sname,Status,City要与其供应的零件的种类一样多。
- 引起修改操作的不一致性。例如，供应者S1从“天津”搬到“上海”，若稍不注意，就会使一些数据被修改，另外一些数据没有被修改，导致数据修改的不一致性。
- 插入异常。表中我们知道主码为Sno，Pno,按照关系模式实体完整规定，主码不能为空或部分为空。这样当某个供应者的某些信息未提供时（如Pno）,则不能进行插入操作，这就是所谓的插入异常。
- 删除异常。若供应商S4的P2零件销售完了，并且以后不再销售P2零件。那么应删除该元组。这样就找不到S4.而S4是客观存在的
从关系模式F中我们可以看出，Sno，Pno是主码。而Sno->Status。因此非主属性Status部分依赖于码。故非2NF。我们可以进行以下修改。将表分解为：
TABLE1(Sno,Sname,Status,City),主码为Sno
TABLE2(Sno,Pno,Qty),主码为Sno，Pno
即可避免1NF存在的问题。
第三范式
定义：若关系模式R(U,F)中不存在这样的码X，属性组Y及非主属性Z(Z不属于Y)使得X->Y,Y->Z成立，则关系模式R属于3NF。
我的理解：这个定义可能比较复杂。简单来说就是判断表中是否存在传递依赖，即X->Y,Y->Z的条件。若不存在，则是满足3NF。
例：我们刚在2NF中，将表分解为TABLE1(Sno,Sname,Status,City)。其中存在Sno->Status,Status->City。故上面的TABLE1和TABLE2花不满足3NF。需要再进行下面的分解：
TABLE1（Sno，Sname，Status）
TABLE2（Status，city）
TABLE3（Sno，Pno，Qty）
既满足3NF。
总结
本章的主要目的就是想让大家了解数据库设计时需要注意的点。想要设计出一个优秀的数据库还需要更多的努力，在后面的学习中，如有相关的经验或总结，我会继续补充。
即使我们现在还不是大牛，但是在工作中，如果让我们设计数据库，起码已经知道评判的方式，最起码要建立一个满足3NF的数据表。
若有朋友也想考软件设计师，我这边可以将我的资料发给你。（在咸鱼上买的，个人觉得还不错，有很多的习题以及历年的考题）在下方留下你的邮箱即可