范式概述与三大范式详解(小白视角一看就懂)
数据库设计的范式:
* 概念:设计数据库时,需要遵循的一些规范。要遵循后边的范式要求,必须先遵循前边的所有范式要求
设计关系数据库时,遵从不同的规范要求,设计出合理的关系型数据库,这些不同的规范要求被称为不同的范式,各种范式呈递次规范,越高的范式数据库冗余越小
目前关系数据库有六种范式:第一范式(1NF)、第二范式(2NF)、第三范式(3NF)、巴斯-科德范式(BCNF)、第四范式(4NF)和第五范式(5NF,又称完美范式)
* 分类:
1. 第一范式(1NF):每一列都是不可分割的原子数据项
2. 第二范式(2NF):在1NF的基础上,非码属性必须完全依赖于码(在1NF基础上消除非主属性对主码的部分函数依赖)
* 几个概念:
1. 函数依赖:A-->B,如果通过A属性(属性组)的值,可以确定唯一B属性的值。则称B依赖于A
例如:学号-->姓名。 (学号,课程名称) --> 分数
2. 完全函数依赖:A-->B, 如果A是一个属性组,则B属性值得确定需要依赖于A属性组中所有的属性值。
例如:(学号,课程名称) --> 分数
3. 部分函数依赖:A-->B, 如果A是一个属性组,则B属性值得确定只需要依赖于A属性组中某一些值即可。
例如:(学号,课程名称) -- > 姓名
4. 传递函数依赖:A-->B, B -- >C . 如果通过A属性(属性组)的值,可以确定唯一B属性的值,在通过B属性(属性组)的值可以确定唯一C属性的值,则称 C 传递函数依赖于A
例如:学号-->系名,系名-->系主任
5. 码:如果在一张表中,一个属性或属性组,被其他所有属性所完全依赖,则称这个属性(属性组)为该表的码
例如:该表中码为:(学号,课程名称)
* 主属性:码属性组中的所有属性
* 非主属性:除过码属性组的属性
3. 第三范式(3NF):在2NF基础上,任何非主属性不依赖于其它非主属性(在2NF基础上消除传递依赖)
三大范式小白视角:
第一范式(1NF):原子性:强调的是列的原子性,即数据库中每一列的字段都是单一属性,不可再分的。并且这个单一属性必须是由基本的数据类型所构成的,如整数、字符串等。下面给大家举个例子:
这是一张员工表:
员工ID 姓名 性别 部门 联系电话 101 周星星 女 销售部 15015246623
现在我们来分析上表,这张员工表是不符合第一范式标准的,每个员工只有一个员工ID,也确实只有一个姓名,一个性别,只属于一个部门,但是在我们的实际生活中,每个人真的只有一个联系电话吗?这里我们就假设最少的情况,每个人都有个人电话和家庭电话,那么联系电话这一字段就是可再分的。这张表的结构设计就没有达到第一范式
解决方案:我们只需要把联系电话这一字段分为个人电话字段和家庭电话字段,就完全符合了第一范式(如下表)
员工ID 姓名 性别 部门 个人电话 家庭电话 101 周星星 女 销售部 15015246623 663323
第二范式(2NF):依赖性:在满足1NF的基础上再满足依赖性的两个约束:一张表必须有一个主键;非主键类必须完全依赖于主键,而不能只依赖主键的一部分
这是一张商品供销信息表:
商品 供销商 价格 重量 分类 供销商电话 啤酒 饮品1厂 3 300ml 液体 18016253155 啤酒 饮品2厂 5 300ml 液体 18055231233 可乐 饮品2厂 5 250ml 液体 18055231233
需要清楚几点:
1.商品与供销商是多对多的关系
2.该表中关键字是一组组合关键字<商品,供销商>,只有商品和供销商两个字段结合才可标识出一件商品
3.存在以下部分依赖的关系
商品---->价格,重量,分类
供销商---->供销商电话
由以上存在的部分依赖关系就可知道该商品表不符合第二范式了,价格,重量,分类只依赖于商品这个主键,而供销商电话也只依赖于供销商这个主键,已经完全违背了第二范式非主键列必须完全依赖于主键而不能只依赖于主键的一部分这一原则了。
解决方案:把上表商品表拆分为商品表和供销商表两张表,既满足了非主键字段必须完全依赖主键这一条件又减少了供销商电话重复这一冗余
商品 供销商 价格 重量 分类 啤酒 饮品1厂 3 300ml 液体 啤酒 饮品2厂 5 300ml 液体 可乐 饮品2厂 3 250ml 液体
供销商 供销商电话 饮品1厂 18016253155 饮品2厂 18055231233
第三范式(3NF):在满足2NF的基础上,另外再满足一个条件:非主键列必须直接依赖于主键,不能存在传递依赖
这是一张学生课表:
课程编号 课程名字 上课时间 任课老师 老师电话 老师职位 101 马克思理论基础 8:00 Lily 18016253155 讲师 102 经济学 14:00 Lucy 18055231233 教授
主键:课程编号
大致一看,上表中的非主键列确实完全是依赖于主键(课程编号)的,符合第二范式2NF。但是问题是:老师电话,老师职位直接依赖的是任课老师(非主键列),而不是直接依赖于主键,它是通过传递才依赖于主键,所以不符合 3NF
解决方案:依然是通过拆分,把上述学生课表拆分为课程表和教师表
课程表:
课程编号 课程名字 上课时间 任课老师 101 马克思理论基础 8:00 Lily 102 经济学 14:00 Lucy
教师表:
任课老师 老师电话 老师职位 Lily 18016253155 讲师 Lucy 18055231233 教授
【推荐】编程新体验,更懂你的AI,立即体验豆包MarsCode编程助手
【推荐】凌霞软件回馈社区,博客园 & 1Panel & Halo 联合会员上线
【推荐】抖音旗下AI助手豆包,你的智能百科全书,全免费不限次数
【推荐】博客园社区专享云产品让利特惠,阿里云新客6.5折上折
【推荐】轻量又高性能的 SSH 工具 IShell:AI 加持,快人一步
· DeepSeek “源神”启动!「GitHub 热点速览」
· 微软正式发布.NET 10 Preview 1:开启下一代开发框架新篇章
· 我与微信审核的“相爱相杀”看个人小程序副业
· C# 集成 DeepSeek 模型实现 AI 私有化(本地部署与 API 调用教程)
· spring官宣接入deepseek,真的太香了~