概述：
在设计和数据库有关的系统时,数据库表的设计至关重要,这些设计关系整个系统的架构,需要精心的仔细考虑。
·数据库的设计主要包含了设计表结构和表之间的联系,在设计的过程中,有一些规则应该遵守，也就是我们常说的数据库三范式。
第一范式：
第一范式是最基本的范式，如果数据库表中所有的字段都是不可分解的，就说明该数据库满足了第一范式。
第一范式的合理遵循需要根据系统的实际需求来定。比如某些数据库系统中需要用到"地址"这个属性,本来直接将“地址"属性设计成一个数据库表的字段就行。
但是如果系统经常会访问“地址"属性中的“城市“部分，那么就非要将“地址“这个属性重新拆分为省份、城市、详细地址等多个部分进行存储,这样在对地址中某
一部分操作的时候将非常方便。这样设计才算满足了数据库的第一范式,如下表所示，如果把省份，城市放到详细地址中，也可以说满足第一范式，但是如果我们
要省份或者城市做统计，这样显然就不合适。
第二范式：
第二范式在第一范式的基础上更近一层。第二范式需要确保数据库表中的每一列都和主键相关，而不是只与主键的某一部分相关（主要是针对联合主键而言）。
也就是说在一个数据库表中，一个表中只能保存一种数据，不可以把多种数据保存在同一个表中。并且二范式要求数据库表中每个实例或者行必须可以被唯一区分。
这样描述感觉比较抽象，下来举个例子，你就明白了。
如上图所示，我们在一张表存了学生以及这个学生的老师的信息。表面上看没什么问题，但是实际上这样会出现很多的冗余数据，比如张三这个学生，我们就存了两次，张老师我们存了三次。
并且很明显的这个表存了两种数据，学生信息和老师信息，所以我们需要对该表进行如下分解：
第三范式：
满足第三范式必须满足第二范式。简而言之，第三范式要求数据库表中不包含已在其他表中已包含的非主键列。不能出现传递依赖，即：除主键外，其他字段必须必须依赖主键。
比如在设计一个订单数据表的时候,可以将客户编号作为一个外键和订单表建立相应的关系。而不可以在订单表中添加关于客户其它信息（比如姓名、所属公司等)的字段。如下面这
两个表所示的设计就是一个满足第三范式的数据库表。
总结：
在关系型数据库中，特别是业务性比较强的场景下，必须要严格遵守数据库设计的三范式。当然，在某些特定的场景下，比如某个字段明确知道不会改变，
也可以作为冗余字段加到其他表，以此来提高查询效率。