函数依赖已经总结完了,直接总结第三范式,第三范式的形式化定义是这样的:关系模式R(U)中如果不存在这样的码X,属性组Y以及非主属性Z(Z不包含于Y),使得X函数确定Y, Y函数确定Z, Y不能函数确定X(也就是X不是R(U)的候选码),则称R(U)属于第三范式。第三范式讲的是:一个非主属性既不能部分依赖于码,也不能传递依赖于码。
对于上一节的第二范式总结中,为了达到第二范式,原来的S-L-C(Sno,Sdept,Sloc,Cno,Grade)被分解为SC(Sno,Cno,Grade)、SL(Sno,Sdept,Sloc),但是这些分解后的关系模式达到第三范式了吗?请看下图:
对于关系模式SL有这样的依赖关系:Sno函数确定Sdept,Sdept函数确定Sloc,可以得出Sno函数确定Sloc,所以SL关系模式中,存在非主属性对码的传递依赖,故而关系模式SL不属于第三范式,而关系模式SC则属于第三范式。
总结:第三范式约束关系模式中的非主属性只能完全函数依赖于码,而不能依赖于非码的属性(这样就不存在传递依赖于码了)。相对于第二范式的“非主属性都得全部依赖于码”的要求,第三范式又多了一个限定,所以约束性更强了。
下面接着总结一下BCNF(Boyce Codd Normal Form),它是由Boyce和Codd提出的,比上述的3NF又进了一步,有时称其为扩展的第三范式,其形式化的定义是:关系模式R(U)属于第一范式,如果X函数确定Y,且Y不包含于X时,则X必含有码,那么该关系模式属于BCNF,也就是说,关系模式R(U)中,每一个决定性因素都包含码,一个满足BCNF的关系模式有以下特性:
1、所有的非主属性对一个码都是完全函数依赖。
2、所有的主属性对一个不包含它本身的码也是完全函数依赖。
3、没有任何属性完全函数依赖于非码的任何一组属性。
可以看出,BCNF排除了任何属性对码的传递依赖和部分依赖,故而如果一个模式是BCNF,那么它必定是第三范式,但是反之未必,因为3NF中,可能存在主属性对码的部分依赖和传递依赖。
【推荐】国内首个AI IDE,深度理解中文开发场景,立即下载体验Trae
【推荐】编程新体验,更懂你的AI,立即体验豆包MarsCode编程助手
【推荐】抖音旗下AI助手豆包,你的智能百科全书,全免费不限次数
【推荐】轻量又高性能的 SSH 工具 IShell:AI 加持,快人一步
· 从 HTTP 原因短语缺失研究 HTTP/2 和 HTTP/3 的设计差异
· AI与.NET技术实操系列:向量存储与相似性搜索在 .NET 中的实现
· 基于Microsoft.Extensions.AI核心库实现RAG应用
· Linux系列:如何用heaptrack跟踪.NET程序的非托管内存泄露
· 开发者必知的日志记录最佳实践
· TypeScript + Deepseek 打造卜卦网站:技术与玄学的结合
· Manus的开源复刻OpenManus初探
· AI 智能体引爆开源社区「GitHub 热点速览」
· 三行代码完成国际化适配,妙~啊~
· .NET Core 中如何实现缓存的预热?