大数据 建模理论 之 三范式(详解)

三范式简述

0,什么是三范式

        设计关系型数据库时,遵从不同的规范要求,设计出合理的关系型数据库,这些不同的规范要求被称为不同的范式,各种范式呈递次规范,越高的范式数据库冗余越小。
        目前关系型数据库有六种范式:第一范式(1NF)、第二范式(2NF)、第三范式(3NF)、巴斯-科德范式(BCNF)、第四范式(4NF)和第五范式(5NF,又称完美范式)。

       一般来说,数据库只需要满足第三范式就行了。

1,第一范式(简述)

属性不可切割

2,第二范式(简述)

不能存在“部分函数依赖”

 3,第三范式(简述)

不能存在“传递函数依赖”

emmm,如果你有良好的三范式功底,

当你看完上面三张图的时候,你已经可以理解透彻了。

不够明白咱再细讲一遍。

三范式详解

4,第一范式(详解)

       第一范式:保证每列的原子性
       第一范式是最基本的范式。如果数据库表中的所有字段值都是不可分解的原子值,就说明该
数据库满足了第一范式。
       第 一 范 式 需 要 根 据 系 统 的 实 际 需 求 来 定 , 比 如 有 一 张 用 户 信 息 表 :

 

        一般来说"住址"设计成一个字段就行,但是如果经常访问"住址"中城市的部分,那么就非要将"住址"这个属性重新拆分为"省份"、"城市"、"地址"等多个部分进行存储,这样在对"住址"中某一部分进行操作的时候将非常方便。

         这么设计才算满足了数据库的第一范式,修改之后的表结构如图:

5,第二范式(详解)

        第二范式:保证一张表只描述一件事情
        这是通俗的说法,用第二范式的定义描述第二范式,说的是在满足第一范式的基础上,数据库表中不存在非关键字段对任一候选关键字段的部分函数依赖,也即所有非关键字段都完全依赖于任一组候选关键字。
        看不懂是吗,没关系,我也看不懂,下面举一个例子,有一张表如下图:

        上表满足第一范式,即每个字段不可再分,但是这张表设计得并不好,或者说,这张表的设计并不满足第二范式。

        因为这张表里面描述了两件事情:学生信息、课程信息,"学分" 完全依赖于 "课程名称"、"姓名"与"年龄"完全依赖于"学号"。

        所以,此表的结构必须修改,修改后如下:

        这次增加了表,将学生信息与课程信息通过一张中间表关联,很好地解决了上面的几个问题,这就是第二范式的中心----保证一张表只讲一件事情。

6,第三范式(详解)


        第三范式----保证每列都和主键直接相关
        第三范式又和第二范式相关,用第三范式的定义描述第三范式就是,数据库表中如果不存在非关键字段任一候选关键字段的传递函数依赖则符合第三范式,所谓传递函数依赖指的是如果存在"A-->B-->C"的决定关系,则 C 传递函数依赖于 A。

        也就是说表中的字段和主键直接对应不依靠其他中间字段,说白了就是,决定某字段值的必须是主键。

        举个例子,看一下如下的表结构:

     

         第三范式和第二范式有点像,从这张数据库表结构中可以看出,"姓名"、"年龄"、"学院"和主键"学号"直接关联,但是"学院地点"、"学院电话"却不直接和主键"学号"相关联,和"学院电话"直接相关联的是"学院",修改之后的表结构如下图:

        好了,就介绍到这里,欢迎大家用实际的行动,比如说点赞收藏留言,给出你建设性的建议和意见。下次再见。

  • 14
    点赞
  • 15
    收藏
    觉得还不错? 一键收藏
  • 打赏
    打赏
  • 2
    评论
评论 2
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包

打赏作者

不被定义喵

你的鼓励将是我创作的最大动力

¥1 ¥2 ¥4 ¥6 ¥10 ¥20
扫码支付:¥1
获取中
扫码支付

您的余额不足,请更换扫码支付或充值

打赏作者

实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值