前往小程序,Get更优阅读体验!
立即前往
首页
学习
活动
专区
工具
TVP
发布
社区首页 >专栏 >【愚公系列】软考高级-架构设计师 058-范式

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

原创
作者头像
愚公搬代码
发布2024-07-03 08:21:57
1760
发布2024-07-03 08:21:57
举报
文章被收录于专栏:愚公系列-考试考证

🏆 作者简介,愚公搬代码 🏆《头衔》:华为云特约编辑,华为云云享专家,华为开发者专家,华为产品云测专家,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.练习

我正在参与2024腾讯技术创作特训营最新征文,快来和我瓜分大奖!

原创声明:本文系作者授权腾讯云开发者社区发表,未经许可,不得转载。

如有侵权,请联系 cloudcommunity@tencent.com 删除。

原创声明:本文系作者授权腾讯云开发者社区发表,未经许可,不得转载。

如有侵权,请联系 cloudcommunity@tencent.com 删除。

评论
登录后参与评论
0 条评论
热度
最新
推荐阅读
目录
  • 🚀前言
  • 🚀一、范式
    • 🔎1.第一范式
      • 🔎2.第二范式
        • 🔎3.第三范式
          • 🔎4.BC范式(BCNF)
            • 🔎5.练习
            相关产品与服务
            领券
            问题归档专栏文章快讯文章归档关键词归档开发者手册归档开发者手册 Section 归档