文档介绍：一、概述
    设计关系数据库时,遵从不同的规范要求,设计出合理的关系型数据库,这些不同的规范要求被称为不同的范式.
    各种范式呈递次规范,越高的范式数据库冗余越小。
    目前关系数据库有六种范式:
    第一范式(1NF)、第二范式(2NF)、第三范式(3NF)、巴斯-科德范式(BCNF)、第四范式(4NF)和第五范式(5NF,还又称完美范式)。   
    范式的严格程度按上面的位置依次递增,后面的范式必须在满足前面范式的基础上增加该范式独有规范才能称为该范式。
  
    各范式的关系如下图:
    
二、第一范式
   第一范式:确保每一列的值的原子性、不可分割性。或者说:每个属性仅包含一个单一值。
   (其实第一范式的概念是最复杂的)
   
    检查是否满足第一范式有下面几种方式:
属性的值是否超出定义的范畴
比如有个属性是“网站”,但却存储了类似这样的值“,唯心六艺,颜超敏”。
(这个值隐含三个内容:域名、网站名称和站长姓名。也即
即除了存储了姓名外,连邮箱也存储在该值中。
属性是否存在重复
如某个表存在工号、姓名和电话。如果某些职工拥有家庭电话、办公电话(或更多),那么这些
职工就需要有两条或者多条记录,以便保存这些电话,但是这样导致了在这些记录中工号和姓名
都重复出现了。
属性的定义是否范围过大
比如属性名为“配置”,数据类型是字符串,值格式是JSON。则实际操作中,可以往该属性中存放
随意的JSON格式字符串,这些字符串的含义只有在程序代码中才能解释,而无法通过sql查询匹配。
检查是否有重复属性组
   如电子商务的购物车表,设计成如下图:
   
   一个产品SKU ID + 数量就是一组,从表中可以看到,顾客最多只能选购3个产品,从数据模型的角度
限制了顾客购买产品的数量。
三、第二范式
   第二范式:所有非主码属性完全依赖候选码。
   (注:候选码就是唯一决定一条记录的1个字段或多个字段的组合,所以可以是主键、复合主键或唯一键等)
   检查是否满足第二范式有下面几种方式:
该表是否存在多种实体的数据
比如该表同时存储了产品和该产品所属供应商的信息,那么就应该将供应商独立出来作为一个新的实体,
然后为产品和供应商两个实体建立联系。
是否存在当前实体的主键或唯一键无法约束的属性
依然以产品表为例,对于产品表,产品名称、描述、市场价、销售价等信息是产品本身的,是依赖该产品存在的。
但如果该表中存在品牌名称、品牌网址等字段,这些字段不是产品主键能够约束,多个产品可以属于同一个品牌,
有同样的品牌名称、品牌网址等。
(有时为了查询效率考虑,会将品牌信息冗余到产品表中,这就是反范式的应用)
四、第三范式
     第三范式:所有非主码属性都是相互独立的,或者说非主码属性对主码的依赖是直接的,而不能间接的。
     
     比如 A、B 是非主码,C是主码。不可以A 依赖 B,B 依赖 C。必须A 、B 均直接依赖 C。A 、B 之间
相互独立,不存在依赖关系。
    检查是否满足第三范式有下面几种方式:
是否有派生属性
比如订单实体的订单总金额。如果在订单表中存储了产品折扣总价、运费、税费、包装费