数据库范式总结

db 数据库表结构设计时,遵从一定的范式(NF,Normal 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 范式(DKNF)和第六范式(6NF)

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

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

文章未经特殊标明皆为本人原创,未经许可不得用于任何商业用途,转载请保持完整性并注明来源链接 《四火的唠叨》

16,208 次阅读

6 thoughts on “数据库范式总结

发表评论

电子邮件地址不会被公开。

back to top