数据库表设计
良好的表结构设计是高性能的基石，应该根据系统将要执行的业务查询来设计。
糟糕的表结构设计会浪费大量的开发时间，严重延误项目开发周 期，让人痛苦万分，而且直接影响到数据库的性能。
所以数据库表设计就变得非常的重要了。
数据库设计三大范式
在数据库表设计上有个很重要的设计准则，在关系数据库中这种规则 就是范式，范式来自英文Normal Form，简称NF。
在实际开发中最为常见的设计范式有三个：三大范式。
1.第一范式：确保每列保持原子性，所有字段值都是不可分解的原子值；
2.第二范式：确保表中的每列都和主键相关，一个表中只能保存一种数据，不可以把多种数据保存在同一张数据库表中；
3.第三范式：确保每列都和主键列直接相关，而不是间接相关；
满足最 低要求的范式是第一范式（1NF），在第一范式的基础上进一步满足更多规范要求的称为 第二范式（2NF），其余范式以此类推。
一般来说，数据库只需满足第三范式(3NF）就行 了。
数据库设计的第一范式
定义： 属于第一范式关系的所有属性都不可再分，即数据项不可分。
理解： 第一范式强调数据表的原子性，是其他范式的基础。
举一个例子，如下图所示：
上图的地址列就不是原子性的，还可以细分，细分后，如下图所示(绿色部分)：
地址列，被拆解为国家和城市两个列，这样的改造就符合了第一范式。
一句话总结：第一范式强调的是列的原子性，即列不能够再分成其他几列，比如：上图的国家Country，城市 City，已经不可再分割，则满足第一范式1NF。
数据库设计的第二范式
第二范式（2NF）是在第一范式（1NF）的基础上建立起来的，即满足第二范式（2NF）必 须先满足第一范式（1NF）。
第二范式（2NF）要求数据库表中的每个实例或行必须可以被惟一地区分。，也就是说要求表中只具有一个业务主键，而且第二范式（2NF）要求实体的属性完全依赖于主关键字。
还是举例说明，这样更加容易理解第二范式，如下图所示：
上图的订单表就不满足第二范式，因为第二范式要求每个表必须有主关键字Primary key，而且每个非主属性完全依赖于主键，上图红色标识出现了2个主关键字。
所以上图订单表，还可以拆分为两张独立的表：订单表和商品表，拆分后如下图所示：
订单表：
商品表：
简要总结：第二范式就是每张表只描述一件事情，先满足第一范式，另外包含两部分内容，一是表必须有一个主键，二是每个表都强依赖于其主关键字，而不能只依赖于主键的一部分。
数据库设计的第三范式
再满足第二范式的基础上，保证每一列数据都要跟主键直接关联，不能出现传递依赖。
第三范式具有如下特征：
- 每一列只有一个值每一行都能区分；
- 每一个表都不包含其他表已经包含的非主关键字信息。
如下图所示:
上图的订单表中的顾客名称，就不符合第三范式，因为它存在了对非主键顾客编号的依赖，每一个表都不包含其他表已经包含的非主关键字信息。
改进后，去掉顾客名称，就符合第三范式了，如下图所示：
简要总结：第三范式满足第二范式，并且表中的列不存在对非主键列的传递依赖。
数据库表设计总结
第一，二，三范式解决的是非主属性的关系。
第一范式：就是原子性，字段不可再分割，列属性不能在细分为子列；
第二范式：就是完全依赖，没有部分依赖；
第三范式：没有传递函数依赖。
作者简介
陈睿|mikechen，10年+大厂架构经验，BAT资深面试官，就职于阿里巴巴、淘宝、百度等一线互联网大厂。
👇阅读更多mikechen架构文章👇
阿里架构 |双11秒杀 |分布式架构 |负载均衡 |单点登录 |微服务 |云原生 |高并发 |架构师
以上
关注作者「mikechen」公众号，获取更多技术干货！
后台回复【架构】，即可获取《阿里架构师进阶专题全部合集》，后台回复【面试】即可获取《史上最全阿里Java面试题总结》