🏆 作者简介,愚公搬代码 🏆《头衔》:华为云特约编辑,华为云云享专家,华为开发者专家,华为产品云测专家,CSDN博客专家,CSDN商业化专家,阿里云专家博主,阿里云签约作者,腾讯云优秀博主,腾讯云内容共创官,掘金优秀博主,亚马逊技领云博主,51CTO博客专家等。 🏆《近期荣誉》:2022年度博客之星TOP2,2023年度博客之星TOP2,2022年华为云十佳博主,2023年华为云十佳博主等。
🏆《博客内容》:.NET、Java、Python、Go、Node、前端、IOS、Android、鸿蒙、Linux、物联网、网络安全、大数据、人工智能、U3D游戏、小程序等相关领域知识。
🏆🎉欢迎 👍点赞✍评论⭐收藏
数据库范式是一组规范化设计数据库的原则,旨在减少数据冗余、提高数据一致性和避免数据异常。通过将数据库设计分解为多个规范形式,设计者可以确保数据库的结构更加健壮、易于维护和扩展。
通常情况下,数据库设计的规范形式可以分为以下几个范式级别,从第一范式(1NF)到第五范式(5NF):
通过遵循这些范式,设计者可以消除数据中的冗余、降低数据修改异常的发生率,并使数据库结构更加灵活和高效。然而,有时候为了特定的业务需求或性能优化,可能会在设计中选择部分放宽这些范式要求。
第一范式1NF:要求数据库表中的所有字段都是不可分割的原子值。通俗地说,第一范式就是表中不允许有小表的存在。比如,对于如下的员工表,就不属于第一范式:
例:用一个单一的关系模式学生来描述学校的教务系统:学生(学号,学生姓名,系号,系主任姓名,课程号,成绩)
依赖关系(学号->学生姓名,学号->所在系,所在系>系主任姓名, (学号,课程号)->成绩)
第二范式:在1 NF的基础上,要求数据库表中的每个非主属性完全依赖于某一个候选键。通俗地说,就是表中不能存在联合主键,按照定义,上面的学生表就不满足2NF,因为学号不能完全确定成绩(每个学生可以选多门课)。
解决方案:将学生表分解为:
每张表均属于2NF
第三范式:在2NF的基础上,要求数据库表中的每个非主属性不依赖于其它非主属性。也就是说,数据表中的每一列都和主键直接相关,而不依赖于其它列,即不能存在传递依赖。
继续上面的实例,学生关系模式就不属于3NF,因为学生无法直接决定系主任和系名,是由学号->系编号,再由系编号->系主任,系编号->系名,因此存在非主属性对主属性的传递依赖,
解决方案:将学生表进一步分解为:
每张表都属于3NF。
BC范式(BCNF):规范化数据库设计的一种方法,它对关系型数据库中的表进行分解,其符合第三范式(3NF),同时尽量避免数据冗余和不一致性,提高数据的可靠性和完整性。
假设仓库管理关系表(仓库ID, 存储物品ID, 管理员ID, 数量),且有一个管理员只在一个仓库工作;一个
仓库可以存储多种物品。此关系模式已经属于了3NF,那么这个关系模式是否存在问题呢?我们来看以下几
种操作:
解决方案:把仓库管理关系表分解为二个关系表:
原创声明:本文系作者授权腾讯云开发者社区发表,未经许可,不得转载。
如有侵权,请联系 cloudcommunity@tencent.com 删除。
原创声明:本文系作者授权腾讯云开发者社区发表,未经许可,不得转载。
如有侵权,请联系 cloudcommunity@tencent.com 删除。