理解数据库范式
内容导读
互联网集市收集整理的这篇技术教程文章主要介绍了理解数据库范式，小编现在分享给大家，供广大互联网技能从业者学习和参考。文章包含2984字，纯文字阅读大概需要5分钟。
内容图文
当前我们使用的主流数据库是关系型数据库，所以我是记录在关系型数据库中对范式的一些理解和看法。数据库库范式分为六种（其实还有有一个BCNF），分别为从第一范式到第六范式。高级一层是建立在所有低层的基础上的，如第2范式是建立在第一范式的基础上的，依
当前我们使用的主流数据库是关系型数据库，所以我是记录在关系型数据库中对范式的一些理解和看法。数据库库范式分为六种（其实还有有一个BCNF），分别为从第一范式到第六范式。高级一层是建立在所有低层的基础上的，如第2范式是建立在第一范式的基础上的，依次类推。下面分别举例讲解各种范式：
- 第一范式(1NF)
- 第二范式(2NF)
- 第三范式(3NF)
- 第四范式（4NF）
- 第五范式（5NF）
- 第六范式（6NF）
第一范式的核心描述为：数据库表的每一列都是不可分割的基本数据项，同一列中不能有多个值。该范式讲的是列的原子性。有两层意思：一层是说每一列只能存一个属性值（如果把2个属性值存在1列中）。第二层说的是在一张表中属性值不能重复。在现代关系行数据库中，都是默认满足第一范式的，所以你想要写出不满足第一范式的结构来还是不可能的事情，所以第一范式就不再多说。如果想深入，可以研究下其他非关系型的数据库的情况。
第二范式的核心描述为：行有唯一的主键，非主键仅对主键依赖。有2层意思，第一层，每一行都要有主键（单独信息或组合信息），这个容易理解。第二层意思是非主键对主键依赖，如果是复合主键的情况，非主键属性不能依赖于部分主键属性。如 【产品，仓库号，数量，仓库地址，仓库管理员】，这里（产品+仓库号）为复合主键，而仓库地址和仓库管理员依赖于仓库号，这就是上面描述的“主键属性不能依赖于部分主键属性”，因此这是违背第二范式的，符合范式的设计应该为：【产品，仓库号，数量】，【仓库号，仓库地址，仓库管理员】。
第三范式的核心描述为：非主键属性互不依赖。这个很容易理解，直接上例子：【学生编号，姓名，系编号，系办公地点，系办公电话】，这里学生编号是主键。然后这里的非主键属性系编号->系办公室+系办公电话，这里应该把该表拆成2个表，然后外键相连。符合范式的设计应该为：【学生编号，姓名，系编号】和【系编号，系办公地点，系办公电话】。
BC范式(BCNF), 是两个叫 Raymond F. Boyce 和 Edgar F. Codd 的总结出来的，取他们的姓拼成范式名。BC 范式是第三范式的加强版。
第四范式的核心描述为：不允许冗余的多对多关系。这个范式的核心思想也是节省数据库空间。举例来说，【员工，技能，语言】，一个员工能拥有多项技能和多种语言能力，而同一技能或语言可以有多个员工掌握。在这种情况下，依据第四范式，我们应该把表单设计成【员工，技能】+【员工，语言】。在存储时，我们能节省一些空间，但是在操作时，join 往往带来更多的系统开支。
第五范式指在可能的前提下继续打碎数据表。这个范式和第四范式的思想是相同的，希望消除冗余，在可能的情况下，继续打碎信息。例如上面的例子，一个三列的表，如果表的各列是两两之间多对多的关系，则按照第五范式的思想，应该建立三张表，每张表有之前表的两列信息。
第六范式已经挺极端了，按文献的说法，只有数据量大到数据仓储级别，才有使用的必要。貌似是仔细设计表单的依赖关系和 join 关系的，就不仔细研究下去了。
在做数据库设计的时候，满足范式要求的数据库设计是结构清晰的，同时可避免数据冗余和操作异常。一般情况下满足第二和第三范式就OK（第一范式是默认满足的），这并意味着不符合范式要求的设计一定是错误的，这种较特殊的情况下，不符合范式要求反而是合理的。
内容总结
以上是互联网集市为您收集整理的理解数据库范式全部内容，希望文章能够帮你解决理解数据库范式所遇到的程序开发问题。 如果觉得互联网集市技术教程内容还不错，欢迎将互联网集市网站推荐给程序员好友。
内容备注
版权声明：本文内容由互联网用户自发贡献，该文观点与技术仅代表作者本人。本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。如发现本站有涉嫌侵权/违法违规的内容， 请发送邮件至 gblab@vip.qq.com 举报，一经查实，本站将立刻删除。
内容手机端
扫描二维码推送至手机访问。