关系数据库设计规范化

2024-06-03 16:12

本文主要是介绍关系数据库设计规范化,希望对大家解决编程问题提供一定的参考价值,需要的开发者们随着小编来一起学习吧!

文章目录

    • 基础知识
    • 规范化
      • 1NF(第一范式)
      • 2NF(第二范式)
      • 3NF(第三范式)
      • BCNF(Boyce Codd Normal Form,巴克斯范式)
      • 4NF(第四范式)
    • 模式分解
    • 总结

基础知识

关系数据库设计的目标是生成一组合适的、性能良好的关系模式,以減少系统中信息存储的冗余度,但又可方便地获取信息。

数据依赖是通过一个关系中属性间值的相等与否体现出来的数据间的相互关系,是现实世界属性间联系和约束的抽象,是数据内在的性质,是语义的体现。函数依赖则是一种最重要、最基本的数据依赖。

函数依赖:设R(U)是属性集U上的关系模式,X和Y是U的子集。若R(U)的任何一个可能的关系r,r中不可能存在两个元组在X上的属性值相等,而在Y上的值不等,则称X函数决定Y或Y函数依赖于X,记作X->Y。

  • 如果X->Y,但 Y ⊊ X Y\subsetneq X YX,则称X->Y是非平凡的函数依赖。如(Sno,Cno)->Sno。
  • 如果X->Y,但 Y ⊆ X Y\subseteq X YX,则称X->Y是平凡的函数依赖。如(Sno,Cno)->Grade。

任何可能的关系:若X->Y,则X叫做决定因子;若X->Y,Y->X,则记做X<–>Y;若Y函数不依赖于X,则记作 X ≠ > Y X \neq> Y X=>Y

常见的函数依赖:

  • 完全函数依赖:在R(U)中,设X->Y,且对于X的任何一个真子集 X ′ X^{'} X,都有 X ′ X^{'} X不能决定Y,则称Y对X完全函数依赖。如(Sno,Cno)->Grade,但 S n o ≠ > G r a d e Sno \neq> Grade Sno=>Grade
  • 部分函数依赖:在R(U)中,设X->Y,但Y不完全依赖于X,则称Y对X部分函数依赖。
  • 传递函数依赖:在R(U,F)中,如果X->Y, Y ⊊ X , Y ≠ > X Y\subsetneq X,Y \neq> X YXY=>X,Y->Z,则称Z对X传递函数依赖。如Sno->Sdept、Sdept->Mname,则Sno->Mname。

多值函数依赖:在R(U,F)中,其属性集为U。X、Y、Z是U的子集,并且Z=U-X-Y。当且仅当对R(U)的任何一个关系r,给定一对(x,z)的值,这组值仅仅决定于x值而与z值无关,则称“Y多值依赖于X”或“X多值决定Y”,记X->->Y。

多值依赖具有6种性质

  • 具有对称性。若X->->Y,则X->->Z,其中Z=U-X-Y。
  • 传递性。若X->->Y,Y->->Z,则X->->Z-Y。
  • 函数依赖可以看成是多值依赖的特殊情况。
  • 若X->->Y,Y->->Z,则X->->YZ。
  • 若X->->Y,Y->->Z,则X->-> Y ∩ Z Y\cap Z YZ
  • 若X->->Y,Y->->Z,则X->->Z-Y。

Armstrong 公理系统:设关系模式R(U,F),其中U为属性集,F是U上的一组函数依赖,那么有一下推理规则:

  • 自反律:若 Y ⊆ X ⊆ Z Y\subseteq X\subseteq Z YXZ,则X->Y为F所逻辑蕴含。
  • 增广率:若X->Y为F所逻辑蕴含,且 Z ⊆ U Z\subseteq U ZU,则XZ->YZ为F所逻辑蕴含。
  • 传递率:若X->Y和Y-Z为F所逻辑蕴含,则X->Z为F所逻辑蕴含。
  • 合并规则:若X->Y,X->Z,则X->YZ为F所蕴含。
  • 传递递率:若X->Y,WY->Z,则XW->Z为F所蕴含。
  • 分解规则:若X->Y, Z ⊆ Y Z\subseteq Y ZY,则X->Z为F所蕴含。

最小函数依赖集:如果函数依赖集F满足下列条件,则称F为一个最小函数依赖集,或极小哈书依赖集或最小覆盖。

  • F种任一函数依赖的右部仅有一个属性,即无多余的属性。
  • F种不存在这样的函数依赖X->A,使得F与 F − { X − A } F-\{X-A\} F{XA}等价,即无多余的函数依赖。
  • F种不存在这样的函数依赖X->A,X有真子集Z使得F与 F − { X − > A } ∪ { Z − > A } F-\{X->A\}\cup \{Z->A\} F{X>A}{Z>A},即去掉各函数依赖左边的多余属性。即不存在部分函数依赖。

函数闭包:在关系模式R(U,F)中被F逻辑蕴含的函数依赖的全体构成的集合称F闭包,记作 F + F^{+} F+

求候选码:用图解法确定候选码

  1. 将关系的函数依赖关系,用“有向图”的方式表示。
  2. 找出入度为0的属性,并以该属性集合为起点,尝试遍历有向图,若能正常遍历图中所有结点,则该属性集即为关系模式的候选键。
  3. 若入度为0的属性集不能遍历图中所有结点,则需要尝试性的将一些中间结点(既有入度,也有出度的结点)并入入度为0的属性集中,直至该集合能遍历所有结点,集合为候选键。

示例1:给定关系R(A1,A2,A3,A4)上的函数依赖集F={A1->A2,A2->A3,A3->A2,A2->A4},R的候选关键字为A1。

示例2:关系R(A,B,C)满足下列函数依赖:F{B->C,B->A,A->BC},关系R的候选键为A和B。

规范化

示例:First(Sno,Sname,Status,City,Pno,Qty),F={Sno->Sname,Sno->Status,Status->City,(Sno,Pno)->Qty}

1NF(第一范式)

若关系模式R中,每个数据项都是不可再分的,则称R属于第一范式,简称1NF,记作 R ∈ 1 N F R\in 1NF R1NF

1NF存在4个问题:

  • 冗余度大。部分列可进行再分,部分列代表的信息量大。
  • 引起修改操作的不一致性。由于部分列数据行数相同,进行更新会引起不一致。
  • 插入异常。主码不能取空值或部分为空值,当插入时会异常。
  • 删除异常。如果某个产品不销售了,删除后无法再找回该产品,但是该产品客观存在。

2NF(第二范式)

若关系模式 R ∈ 1 N F R\in 1NF R1NF,并且每一个非主属性都完全依赖于R的码,则称R属于第二范式,简称2NF,记作 R ∈ 2 N F R\in 2NF R2NF。也就是说,1NF基础上消除了非主属性对码的部分函数依赖。主要进行分解关系模式。如First关系分解为First1(Sno,Sname,Status,City)和First2(Sno,Pno,Qty)。

3NF(第三范式)

若关系模式R(U,F)中不存在这样的码X,属性组Y及非属性Z( Z ⊊ Y Z\subsetneq Y ZY)使得X->Y,(YKaTeX parse error: Undefined control sequence: \eq at position 1: \̲e̲q̲>X)Y->Z,则关系模式 R ∈ 3 N F R\in 3NF R3NF2NF基础上消除了非主属性对码的传递函数依赖,则称3NF。由于First1中有Sno->Status,Status->City存在传递,First1分解为First11(Sno,Sname,Status)和First12(Status,City)。

产生冗余和异常的两个重要原因是部分依赖和传递依赖。因为3NF模式中不存在非主属性对码的部分函数依赖和传递函数依赖,所以具有较好的性能。

BCNF(Boyce Codd Normal Form,巴克斯范式)

关系模式 R ∈ 1 N F R\in 1NF R1NF,若X->Y且 Y ⊊ X Y\subsetneq X YX时,X必含有码,则关系模式 R ∈ B C N F R\in BCNF RBCNF。也就是说,当3NF消除了主属性对码的部分函数依赖和传递函数依赖,则称为BCNF。

性质如下:

  • 所有非主属性对每个码都是完全函数依赖。
  • 所有主属性对每一个不包含它的码,也是完全函数依赖。
  • 没有任何属性完全函数依赖于非码的任何一组属性。

示例:设R(Pno,Pname,Mname)的属性分别表示零件号、零件名和厂商名,如果约定,每种零件号只有一个零件名,但不同的零件号可以有相同的零件名;每种零件可以有多个厂商生产,但每家厂商生产的零件应有不同的零件名。这样我们可以得到如下一组函数依赖:Pno->Pname,(Pname,Mname)->Pno。

该关系模式R的候选码为(Pname,Mname)或(Pno,Mname),属性都是主属性,不存在非主席对码的传递依赖,是3NF,但主属性传递依赖于码(Pname,Mname),不是BCNF,可以分解成R1(Pno,Pname)和R2(Mname)。

4NF(第四范式)

关系模式 R ∈ 1 N F R\in 1NF R1NF,若对于R的每个非平凡多值依赖X->->Y且 Y ⊊ X Y\subsetneq X YX时,X必含有码(不为空),则关系模式 R ( U , F ) ∈ 4 N F R(U,F)\in4NF R(U,F)4NF4NF是限制关系模式的属性间不允许有非平凡且非函数依赖的多值依赖。如x、y、z,x–> y,z 为空集,则为平凡多值依赖,反之为非平凡多值依赖。

模式分解

分解:关系模式R(U,F)的一个分解 ρ = { R 1 ( U 1 , F 1 ) , R 2 ( U 2 , F 2 ) , . . . , R n ( U n , F n ) } \rho=\{R_1(U_1,F_1),R_2(U_2,F_2),...,R_n(U_n,F_n)\} ρ={R1(U1,F1),R2(U2,F2),...,Rn(Un,Fn)},其中, U = ⋃ i = 1 n U i U=\bigcup\limits_{i=1}^nU_i U=i=1nUi,并且没有 U i ⊆ U j ( 1 ≤ i , j ≤ n ) U_i\subseteq U_j(1 \leq i ,j \leq n) UiUj(1i,jn) F i F_i Fi是F在 U i U_i Ui上的投影, F i = { X − > Y ∈ F + ∧ X Y ⊆ U i F_i=\{X->Y\in F_{+} \wedge XY \subseteq U_i Fi={X>YF+XYUi

分解成n个关系,分解的属性都要在子表中,并且子表没有交叉关系,

对一个给定的模式进行分解,使得分解后的模式是否与原来的模式等价有三种情况:

  • 分解具有无损连接性。
  • 分解要保持函数依赖。
  • 分解既要无损连接性,又要保持函数依赖。

示例:关系模式Std(Sno,Sdept,Mname),其属性组上的函数依赖集是F={Sno->Sdept,Sdept->Mname}
a) R11(Sno,Mname)和R12(Sdept,Mname)
b) R21(Sno,Sdept)和R22(Sno,Mname)
c) R31(Sno,Sdept)和R32(Sdept,Mname)
d) R41(Sno)、R42(Sdept)和R43(Mname)

无损连接:关系模式R(U,F)分解为关系模式 ρ = { R 1 ( U 1 , F 1 ) , R 2 ( U 2 , F 2 ) , . . . , R n ( U n , F n ) } \rho=\{R_1(U_1,F_1),R_2(U_2,F_2),...,R_n(U_n,F_n)\} ρ={R1(U1,F1),R2(U2,F2),...,Rn(Un,Fn)},如果对于R的每一个满足F的具体关系r,都有 r = π R 1 ( r ) × π R 2 ( r ) × . . . × π R n ( r ) r=\pi_{R_1}(r)\times\pi_{R_2}(r)\times... \times \pi_{R_n}(r) r=πR1(r)×πR2(r)×...×πRn(r),即r在 R 1 , R 2 , . . . R n R_1,R_2,...R_n R1,R2,...Rn上投影的自然连接等于r,则称分解 ρ \rho ρ具有无损连接。分解后的每个表合并后记录数和列不变,具有无损连接的充分必要条件 U 1 ∩ U 2 − > U 1 − U 2 ∈ F + 或 U 1 ∩ U 2 − > U 2 − U 1 ∈ F + U_1\cap U_2 -> U_1-U_2 \in F^{+}或U_1\cap U_2 -> U_2-U_1 \in F^{+} U1U2>U1U2F+U1U2>U2U1F+

保持函数依赖:关系模式R(U,F)分解为关系模式 ρ = { R 1 ( U 1 , F 1 ) , R 2 ( U 2 , F 2 ) , . . . , R n ( U n , F n ) } \rho=\{R_1(U_1,F_1),R_2(U_2,F_2),...,R_n(U_n,F_n)\} ρ={R1(U1,F1),R2(U2,F2),...,Rn(Un,Fn)},如果 F + = ( F 1 ⋃ F 2 ⋃ . . . ⋃ F n ) + F^{+}=(F_1\bigcup F_2\bigcup ... \bigcup F_n)^{+} F+=(F1F2...Fn)+,即F所逻辑蕴含的函数依赖一定也由分解得到的某个关系模式中的函数依赖 F i F_i Fi逻辑蕴含,则称分解 ρ \rho ρ是保持函数依赖。

分解具有无损连接性和分解具有保持函数依赖是两个相互独立的标准。具有无损连接性的分解不一定保持函数依赖。保持函数依赖的分解也不一定具有无损连接性。

示例1:关系模式Std(Sno,Sdept,Mname),其属性组上的函数依赖集是F={Sno->Sdept,Sdept->Mname}

  • a) R11(Sno,Mname)和R12(Sdept,Mname)。 F 1 ⋃ F 2 = { S n o − > M n a m e , S d e p t − > M n a m e } F_1\bigcup F_2=\{Sno->Mname,Sdept->Mname\} F1F2={Sno>Mname,Sdept>Mname},无Sno->Mname,不保持函数依赖。
  • b) R21(Sno,Sdept)和R22(Sno,Mname) 。分析: U 1 ∩ U 2 = S n o → U 1 − U 2 = S d e p t U_1\cap U_2=Sno \rightarrow U_1-U_2=Sdept U1U2=SnoU1U2=Sdept,具有无损连接性。
  • c) R31(Sno,Sdept)和R32(Sdept,Mname)。分析: U 1 ∩ U 2 = S d e p t → U 2 − U 1 = M n a m e , U 1 − U 2 = S n o U_1\cap U_2=Sdept \rightarrow U_2-U_1=Mname,U_1-U_2=Sno U1U2=SdeptU2U1=MnameU1U2=Sno,具有无损连接性。 F 1 ⋃ F 2 = { S n o − > M n a m e , S d e p t − > M n a m e } F_1\bigcup F_2=\{Sno->Mname,Sdept->Mname\} F1F2={Sno>Mname,Sdept>Mname},都有,则保持函数依赖。
  • d) R41(Sno)、R42(Sdept)和R43(Mname)。

示例2:设关系模式R(U,F),其中U={A,B,C,D,E},F={A->BC,C->D,BC->E,E->A},则分解成 ρ = \rho= ρ={R1(ABCE),R2(CD)}满足具有无损连接和保持函数依赖。

分析: U 1 ∩ U 2 = C → U 1 − U 2 = A B E o r U 2 − U 1 = D U_1\cap U_2=C \rightarrow U_1-U_2=ABE or U_2-U_1=D U1U2=CU1U2=ABEorU2U1=D,具有无损连接性。F中的决定在分解的子表都存在。

总结

关系数据库设计的规范化是构建高效、可靠数据库系统的基础。它要求设计师深入理解并应用第一范式(1NF)、第二范式(2NF)、第三范式(3NF)、Boyd-Codd范式(BCNF)以及第四范式(4NF)。这些范式旨在引导设计师逐步消除数据中的冗余和更新异常,从而确保数据的原子性、独立性和稳定性。

在规范化的过程中,模式或表的分解是一个核心环节。设计师需要通过模式分解来保持函数依赖和无损连接,这意味着在分解过程中既要确保数据不丢失,又要维持数据间的内在联系。这种精细的操作不仅有助于提高数据的访问效率,还能保证数据在不同表之间的一致性和完整性。

除了遵循规范化原则,数据库设计还需考虑性能优化和可扩展性。设计师应通过合理的索引策略、查询优化和适当的硬件配置来提升数据库的性能。同时,设计应具备灵活性,以便在未来能够适应业务需求的变化和技术的更新。

这篇关于关系数据库设计规范化的文章就介绍到这儿,希望我们推荐的文章对编程师们有所帮助!



http://www.chinasem.cn/article/1027472

相关文章

不懂推荐算法也能设计推荐系统

本文以商业化应用推荐为例,告诉我们不懂推荐算法的产品,也能从产品侧出发, 设计出一款不错的推荐系统。 相信很多新手产品,看到算法二字,多是懵圈的。 什么排序算法、最短路径等都是相对传统的算法(注:传统是指科班出身的产品都会接触过)。但对于推荐算法,多数产品对着网上搜到的资源,都会无从下手。特别当某些推荐算法 和 “AI”扯上关系后,更是加大了理解的难度。 但,不了解推荐算法,就无法做推荐系

怎么让1台电脑共享给7人同时流畅设计

在当今的创意设计与数字内容生产领域,图形工作站以其强大的计算能力、专业的图形处理能力和稳定的系统性能,成为了众多设计师、动画师、视频编辑师等创意工作者的必备工具。 设计团队面临资源有限,比如只有一台高性能电脑时,如何高效地让七人同时流畅地进行设计工作,便成为了一个亟待解决的问题。 一、硬件升级与配置 1.高性能处理器(CPU):选择多核、高线程的处理器,例如Intel的至强系列或AMD的Ry

基于51单片机的自动转向修复系统的设计与实现

文章目录 前言资料获取设计介绍功能介绍设计清单具体实现截图参考文献设计获取 前言 💗博主介绍:✌全网粉丝10W+,CSDN特邀作者、博客专家、CSDN新星计划导师,一名热衷于单片机技术探索与分享的博主、专注于 精通51/STM32/MSP430/AVR等单片机设计 主要对象是咱们电子相关专业的大学生,希望您们都共创辉煌!✌💗 👇🏻 精彩专栏 推荐订阅👇🏻 单片机

SprinBoot+Vue网络商城海鲜市场的设计与实现

目录 1 项目介绍2 项目截图3 核心代码3.1 Controller3.2 Service3.3 Dao3.4 application.yml3.5 SpringbootApplication3.5 Vue 4 数据库表设计5 文档参考6 计算机毕设选题推荐7 源码获取 1 项目介绍 博主个人介绍:CSDN认证博客专家,CSDN平台Java领域优质创作者,全网30w+

单片机毕业设计基于单片机的智能门禁系统的设计与实现

文章目录 前言资料获取设计介绍功能介绍程序代码部分参考 设计清单具体实现截图参考文献设计获取 前言 💗博主介绍:✌全网粉丝10W+,CSDN特邀作者、博客专家、CSDN新星计划导师,一名热衷于单片机技术探索与分享的博主、专注于 精通51/STM32/MSP430/AVR等单片机设计 主要对象是咱们电子相关专业的大学生,希望您们都共创辉煌!✌💗 👇🏻 精彩专栏 推荐订

Spring的设计⽬标——《Spring技术内幕》

读《Spring技术内幕》第二版,计文柯著。 如果我们要简要地描述Spring的设计⽬标,可以这么说,Spring为开发者提供的是⼀个⼀站式的轻量级应⽤开发框架(平台)。 作为平台,Spring抽象了我们在 许多应⽤开发中遇到的共性问题;同时,作为⼀个轻量级的应⽤开发框架,Spring和传统的J2EE开发相⽐,有其⾃⾝的特点。 通过这些⾃⾝的特点,Spring充分体现了它的设计理念:在

开题报告中的研究方法设计:AI能帮你做什么?

AIPaperGPT,论文写作神器~ https://www.aipapergpt.com/ 大家都准备开题报告了吗?研究方法部分是不是已经让你头疼到抓狂? 别急,这可是大多数人都会遇到的难题!尤其是研究方法设计这一块,选定性还是定量,怎么搞才能符合老师的要求? 每次到这儿,头脑一片空白。 好消息是,现在AI工具火得一塌糊涂,比如ChatGPT,居然能帮你在研究方法这块儿上出点主意。是不

创业者该如何设计公司的股权架构

本文来自七八点联合IT橘子和车库咖啡的一系列关于设计公司股权结构的讲座。 主讲人何德文: 在公司发展的不同阶段,创业者都会面临公司股权架构设计问题: 1.合伙人合伙创业第一天,就会面临股权架构设计问题(合伙人股权设计); 2.公司早期要引入天使资金,会面临股权架构设计问题(天使融资); 3.公司有三五十号人,要激励中层管理与重要技术人员和公司长期走下去,会面临股权架构设计问题(员工股权激

分布式文件系统设计

分布式文件系统是分布式领域的一个基础应用,其中最著名的毫无疑问是 HDFS/GFS。如今该领域已经趋向于成熟,但了解它的设计要点和思想,对我们将来面临类似场景 / 问题时,具有借鉴意义。并且,分布式文件系统并非只有 HDFS/GFS 这一种形态,在它之外,还有其他形态各异、各有千秋的产品形态,对它们的了解,也对扩展我们的视野有所俾益。本文试图分析和思考,在分布式文件系统领域,我们要解决哪些问题、有

(入门篇)JavaScript 网页设计案例浅析-简单的交互式图片轮播

网页设计已经成为了每个前端开发者的必备技能,而 JavaScript 作为前端三大基础之一,更是为网页赋予了互动性和动态效果。本篇文章将通过一个简单的 JavaScript 案例,带你了解网页设计中的一些常见技巧和技术原理。今天就说一说一个常见的图片轮播效果。相信大家在各类电商网站、个人博客或者展示页面中,都看到过这种轮播图。它的核心功能是展示多张图片,并且用户可以通过点击按钮,左右切换图片。