数据库范式总结

数据库表结构设计时，遵从一定的范式（NF，Noraml Form）可以减少数据冗余和操作异常。

第一范式（1NF）

1NF指的是每个属性值都是不可再分的。

满足1NF的关系被称为规范化的关系，1NF也是关系模式应具备的最起码的条件。

比如有这样一张表user的两列：

• name
• phone_number

  phone_number这一列只存储一个电话号码，如果一条数据同时存储了住宅电话和手机号码，比如：“010-65576558,13765556765”，那么这个属性是可以再分的，违背了1NF。

  第二范式（2NF）

  2NF要求去除局部依赖。

  也就是说，表中的属性完全依赖于全部主键，而不是部分主键。

  比方说user表包含下面几列：

  • user_id
  • name
  • phone_number
  • job_id
  • job_description

    其中job_description依赖于job_id，而不是全部主键（user_id，job_id），所以违背了2NF。这时可以把job部分单独抽取成一张job表，去除冗余。

    第三范式（3NF）

    3NF要求消除非主属性对候选键的传递依赖。

    比如user表现在组成如下：

    • user_id
    • name
    • classification

      仅有user_id是主键，用户姓名依赖于主键user_id，根据姓名name来给用户分类，而用户可能重名，因此name是允许重复的，再有用户分类classification依赖于用户姓名。这张表已经满足了2NF，即属性依赖于全部主键user_id，但是形成了从classification到非候选键name再到主键user_id的传递依赖，不符合3NF。

      BC范式（BCNF）

      3NF中只是排除了非主属性对候选键的传递依赖，于是更进一步，BCNF还要求消除主属性对候选键在内的传递依赖。

      user表现在变成这样：

      • user_id
      • card_id
      • passport_id

        其中护照号passport_id是主键，身份证号card_id和用户号user_id都是候选键，存在主属性passport_id到card_id再到候选键user_id的传递依赖。

        第四范式（4NF）

        4NF是要消除多值依赖。

        在关系模式中，函数依赖不能表示属性值之间的一对多联系，这些属性之间有些虽然没有直接关系，但存在间接的关系，把没有直接联系、但有间接的联系称为多值依赖的数据依赖。

        比如user表：

        • user_id
        • position
        • salary_level

          user_id是主键，薪水等级salary_level看似被用户id直接确定，但其实薪水等级是根据职位position来确定的，和用户本身无直接关系，这就是多值依赖。

          第五范式（5NF）、DK范式—KNF）和第六范式（6NF）

          5NF要求消除连接依赖，并且必须保证数据完整。多值依赖是连接依赖的特殊情况，定义稍复杂。这几种范式已经很少涉及。

          在保证数据完整性基础上，通常达到3NF，有时达到2NF已经足够了，追求过高的NF级别会导致混乱的库表，大量的多表连接查询，性能低下。

          文章系本人原创，转载请保持完整性并注明出自《四火的唠叨》

          1 楼 zhuchao_ko 2013-02-14 ......反范式呢？ 2 楼 lvwenwen 昨天 反范式反范式