【愚公系列】软考高级-架构设计师 058-范式

举报
愚公搬代码 发表于 2024/07/25 11:25:51 2024/07/25
【摘要】 🏆 作者简介,愚公搬代码🏆《头衔》:华为云特约编辑,华为云云享专家,华为开发者专家,华为产品云测专家,CSDN博客专家,CSDN商业化专家,阿里云专家博主,阿里云签约作者,腾讯云优秀博主,腾讯云内容共创官,掘金优秀博主,亚马逊技领云博主,51CTO博客专家等。🏆《近期荣誉》:2022年度博客之星TOP2,2023年度博客之星TOP2,2022年华为云十佳博主,2023年华为云十佳博主...

🏆 作者简介,愚公搬代码
🏆《头衔》:华为云特约编辑,华为云云享专家,华为开发者专家,华为产品云测专家,CSDN博客专家,CSDN商业化专家,阿里云专家博主,阿里云签约作者,腾讯云优秀博主,腾讯云内容共创官,掘金优秀博主,亚马逊技领云博主,51CTO博客专家等。
🏆《近期荣誉》:2022年度博客之星TOP2,2023年度博客之星TOP2,2022年华为云十佳博主,2023年华为云十佳博主等。
🏆《博客内容》:.NET、Java、Python、Go、Node、前端、IOS、Android、鸿蒙、Linux、物联网、网络安全、大数据、人工智能、U3D游戏、小程序等相关领域知识。
🏆🎉欢迎 👍点赞✍评论⭐收藏

🚀前言

数据库范式是一组规范化设计数据库的原则,旨在减少数据冗余、提高数据一致性和避免数据异常。通过将数据库设计分解为多个规范形式,设计者可以确保数据库的结构更加健壮、易于维护和扩展。

通常情况下,数据库设计的规范形式可以分为以下几个范式级别,从第一范式(1NF)到第五范式(5NF):

  1. 第一范式(1NF)

    • 数据表中的每一列都是不可分割的原子值。
    • 没有重复的列或分组。
  2. 第二范式(2NF)

    • 数据表必须符合第一范式。
    • 每一列与主键完全依赖,而不是部分依赖。
    • 即确保每个非主键列都完全依赖于主键,而不是只依赖于主键的部分属性。
  3. 第三范式(3NF)

    • 数据表必须符合第二范式。
    • 非主键列之间没有传递依赖关系,即不存在非主键列依赖其他非主键列的情况。
  4. 巴斯-科德范式(BCNF)

    • 数据表必须符合第三范式。
    • 对于任意非平凡的函数依赖X → Y,X必须是Y的超键。
  5. 第四范式(4NF)

    • 数据表必须符合BCNF。
    • 任何一个多值依赖(即A →→ B,其中A和B都是非主属性集合)都只能是候选键的超集。
  6. 第五范式(5NF)

    • 数据表必须符合第四范式。
    • 只要一个非平凡的多值依赖A →→ B存在,那么A和B都必须是候选键的超集。

通过遵循这些范式,设计者可以消除数据中的冗余、降低数据修改异常的发生率,并使数据库结构更加灵活和高效。然而,有时候为了特定的业务需求或性能优化,可能会在设计中选择部分放宽这些范式要求。

🚀一、范式

🔎1.第一范式

第一范式1NF:要求数据库表中的所有字段都是不可分割的原子值。通俗地说,第一范式就是表中不允许有小表的存在。比如,对于如下的员工表,就不属于第一范式:
在这里插入图片描述
例:用一个单一的关系模式学生来描述学校的教务系统:学生(学号,学生姓名,系号,系主任姓名,课程号,成绩)

依赖关系(学号->学生姓名,学号->所在系,所在系>系主任姓名, (学号,课程号)->成绩)

在这里插入图片描述

🔎2.第二范式

第二范式:在1 NF的基础上,要求数据库表中的每个非主属性完全依赖于某一个候选键。通俗地说,就是表中不能存在联合主键,按照定义,上面的学生表就不满足2NF,因为学号不能完全确定成绩(每个学生可以选多门课)。

解决方案:将学生表分解为:

  • 学生(学号,学生姓名,系编号,系名,系主任)
  • 选课(选课id,学号,课程号,成绩)。

每张表均属于2NF

🔎3.第三范式

第三范式:在2NF的基础上,要求数据库表中的每个非主属性不依赖于其它非主属性。也就是说,数据表中的每一列都和主键直接相关,而不依赖于其它列,即不能存在传递依赖。

继续上面的实例,学生关系模式就不属于3NF,因为学生无法直接决定系主任和系名,是由学号->系编号,再由系编号->系主任,系编号->系名,因此存在非主属性对主属性的传递依赖,

解决方案:将学生表进一步分解为:

  • 学生(学号,学生姓名,系编号)
  • 系(系编号,系名,系主任)
  • 选课(学号,课程号,成绩)

每张表都属于3NF。

🔎4.BC范式(BCNF)

BC范式(BCNF):规范化数据库设计的一种方法,它对关系型数据库中的表进行分解,其符合第三范式(3NF),同时尽量避免数据冗余和不一致性,提高数据的可靠性和完整性。

假设仓库管理关系表(仓库ID, 存储物品ID, 管理员ID, 数量),且有一个管理员只在一个仓库工作;一个
仓库可以存储多种物品。此关系模式已经属于了3NF,那么这个关系模式是否存在问题呢?我们来看以下几
种操作:

  • 删除异常:当仓库被清空后,所有”存储物品ID”和”数量”信息被删除的同时,”仓库ID”和”管理员ID”信息也被删除了。
  • 插入异常:当仓库没有存储任何物品时,无法给仓库分配管理员。
  • 更新异常:如果仓库换了管理员,则表中所有行的管理员ID都要修改。

解决方案:把仓库管理关系表分解为二个关系表:

  • 仓库管理:(仓库ID, 管理员ID);
  • 仓库:(仓库ID, 存储物品ID, 数量)。
    这样的数据库表是符合BCNF范式的,消除了删除异常、插入异常和更新异常。

🔎5.练习

在这里插入图片描述

在这里插入图片描述


🚀感谢:给读者的一封信

亲爱的读者,

我在这篇文章中投入了大量的心血和时间,希望为您提供有价值的内容。这篇文章包含了深入的研究和个人经验,我相信这些信息对您非常有帮助。

如果您觉得这篇文章对您有所帮助,我诚恳地请求您考虑赞赏1元钱的支持。这个金额不会对您的财务状况造成负担,但它会对我继续创作高质量的内容产生积极的影响。

我之所以写这篇文章,是因为我热爱分享有用的知识和见解。您的支持将帮助我继续这个使命,也鼓励我花更多的时间和精力创作更多有价值的内容。

如果您愿意支持我的创作,请扫描下面二维码,您的支持将不胜感激。同时,如果您有任何反馈或建议,也欢迎与我分享。

在这里插入图片描述

再次感谢您的阅读和支持!

最诚挚的问候, “愚公搬代码”

【版权声明】本文为华为云社区用户原创内容,转载时必须标注文章的来源(华为云社区)、文章链接、文章作者等基本信息, 否则作者和本社区有权追究责任。如果您发现本社区中有涉嫌抄袭的内容,欢迎发送邮件进行举报,并提供相关证据,一经查实,本社区将立刻删除涉嫌侵权内容,举报邮箱: cloudbbs@huaweicloud.com
  • 点赞
  • 收藏
  • 关注作者

评论(0

0/1000
抱歉,系统识别当前为高风险访问,暂不支持该操作

全部回复

上滑加载中

设置昵称

在此一键设置昵称,即可参与社区互动!

*长度不超过10个汉字或20个英文字符,设置后3个月内不可修改。

*长度不超过10个汉字或20个英文字符,设置后3个月内不可修改。