数据库原理与应用 课件 第4-6章 关系数据库理论 -事务管理

数据库原理与应用第4章关系数据库理论本章知识导图本章学习目标了解：基础概念与问题熟悉数据冗余与操作异常问题，掌握函数依赖分类及BCNF的定义与适用场景。理解：本质与逻辑深入理解函数依赖本质，厘清1NF到3NF的递进约束逻辑及无损连接的意义。掌握：核心算法求解熟练掌握属性集闭包计算、最小函数依赖集求解及3NF分解的核心算法。应用：分析与设计实践能够依据依赖集分析最高范式、分解模式并验证无损连接性与函数依赖保持性。素养：职业规范意识养成以理论为指导、追求数据低冗余与高一致性的规范数据库设计职业意识。目录01函数依赖问题的提出、定义与分类、候选码、作用02关系模式的范式1NF、2NF、3NF、BCNF规范化标准03函数依赖的公理系统Armstrong公理、属性集闭包、最小依赖集04关系模式的分解无损连接性、函数依赖保持性、分解算法05本章小结4.1函数依赖问题的提出：关系模式存在的异常与冗余核心概念：函数依赖及其分类形式化定义：候选码的理论推导实际应用：函数依赖在数据库设计中的作用4.1.1问题的提出关系模式定义S(属性列表)sno,sname,ssex,sage,sdept,sdormcno,cname,credit,grade

问题分析：该模式混合了学生基本信息与选课信息，可能导致数据冗余与更新异常。关系实例(表4-1)4.1.1问题的提出

–四个问题01.数据冗余度高学生的姓名、性别等信息，以及课程的名称、学分等信息会被重复存储，占用大量空间。02.数据修改复杂修改一个学生的姓名或一门课程的名称，需要更新所有相关的元组，维护成本高且易出错。03.插入异常新生若未选课，或新课程若未被学生选修，则无法将其基本信息插入到数据库中。04.删除异常删除所有选课记录可能导致学生或课程的基本信息被一并删除，造成数据丢失。4.1.1问题的提出-解决方案（分解）学生关系S(sno,sname,ssex,sage,sdept)课程关系C(cno,cname,credit)院系关系D(sdept,sdorm)选课关系SC(sno,cno,grade)分解优势：数据冗余大幅降低，有效解决插入/删除异常，简化数据修改操作。4.1.2函数依赖及其分类-函数依赖的定义形式化定义设R(U)是属性集U上的关系模式，X和Y是U的子集。若对于R的任意一个关系r，r中任意两个元组s和t，只要满足s[X]=t[X]，就有s[Y]=t[Y]，则称X函数决定Y，记为X→Y。核心本质属性间的“一一对应”约束。给定X的取值，Y的取值被唯一确定，不存在一对多的情况。简化表示关系模式通常表示为：R<U,F>其中F是该关系模式上的函数依赖集。4.1.2函数依赖及其分类–案例学生基本信息依赖sno→sname(姓名)sno→ssex(性别)sno→sage(年龄)sno→sdept(院系)sdept→sdorm(宿舍区)课程信息依赖cno→cname(课程名)cno→credit(学分)成绩信息依赖(sno,cno)→grade(成绩)联合主键决定成绩4.1.2函数依赖及其分类-平凡与非平凡依赖平凡函数依赖定义特征若Y⊆X，则X→Y恒成立。即被决定属性集是决定属性集的子集。典型示例(sno,cno)→sno实际意义未揭示属性间的新关联，对数据库设计通常无实际分析价值。非平凡函数依赖定义特征若Y⊈X，且X→Y成立。即被决定属性集不完全包含在决定属性集中。典型示例sno→sname实际意义涉及不同属性间的决定关系，是分析关系模式规范化问题的核心。4.1.2函数依赖及其分类-完全与部分依赖完全函数依赖定义与记法若X→Y，且X的任何真子集X'都不能决定Y，则Y完全依赖于X，记为X→Y。核心本质决定因素X中的每一个属性都是必要的，无冗余。典型示例(学号,课程号)→成绩解释：少了学号或课程号任何一个，都无法确定成绩。部分函数依赖定义与记法若X→Y，且存在X的真子集X'能决定Y，则Y部分依赖于X，记为X

→

Y。核心本质决定因素X中存在多余属性。典型示例(学号,课程号)→姓名解释：其实只需要学号就能确定姓名，课程号在这里是多余的。ffpp4.1.2函数依赖及其分类-部分函数依赖的问题学生关系S中的依赖关系(sno,cno)→sname(姓名)(sno,cno)→ssex(性别)(sno,cno)→sage(年龄)(sno,cno)→sdept(系别)(sno,cno)→cname(课程名)(sno,cno)→credit(学分)部分函数依赖的危害数据冗余同一学生的信息或同一课程的信息被重复存储多次。修改复杂更新数据时，需要修改所有重复存储的副本，容易导致数据不一致。4.1.2函数依赖及其分类-传递函数依赖形式化定义若X→Y，Y→Z（二者均为非平凡函数依赖），且Y↛X，则称Z传递函数依赖于X，记为X→Z。关键约束条件核心条件是Y不能函数决定X。若Y→X，则X↔Y，此时Z变为直接依赖于X，而非传递依赖。核心本质属性Z并非直接依赖于X，而是通过中间属性Y建立的一种间接决定关系。t4.1.2函数依赖及其分类-传递函数依赖的问题关系模式推导示例(学生关系S)已知依赖关系：学号(sno)→院系(sdept)院系(sdept)→宿舍区(sdorm)

推导结论：由于sdept↛sno，因此存在传递依赖：sno⟶sdorm(传递)传递依赖的危害：更新异常修改复杂若某院系宿舍调整，需遍历修改该院系所有学生的sdorm字段，维护成本高。

数据丢失若某院系学生全部毕业或转专业，该院系的宿舍区信息将从数据库中丢失。t4.1.3候选码的形式定义形式定义设有关系模式R<U,F>，X是U的子集。若X→U(完全函数依赖)，则称X为R的候选码。关键特征(KeyCharacteristics)唯一性：能唯一确定关系中的一个元组最小性：X中没有多余属性（完全函数依赖保证）多样性：一个关系模式可以有多个候选码引申概念：主码·全码·主属性·非主属性4.1.4函数依赖的作用解释问题根源部分依赖和传递依赖是导致数据冗余、修改复杂、插入异常和删除异常的根本原因。指导模式优化范式（如2NF、3NF）的本质就是通过消除不良的函数依赖来优化关系模式，提升数据库设计的质量。确保分解正确性在关系模式分解时，需基于函数依赖判断分解是否满足“无损连接”和“保持函数依赖”两个关键条件。4.2关系模式的范式第1范式·第2范式·第3范式·BC范式4.2.1第1范式（1NF）核心定义若关系模式R中的每个属性都是不可再分的最小数据单位，则称R满足第1范式，记为R∈1NF。满足条件不存在复合属性（属性值不可再分）不存在重复元组存在局限仅解决了属性不可再分的问题，未涉及函数依赖的优化，仍可能存在严重的数据冗余和异常。（本章第一节给出的关系模式即满足1NF）4.2.2第2范式（2NF）定义与概念若关系模式R满足1NF，且每一个非主属性都完全函数依赖于R的任一候选码，则称R满足第2范式。

核心特征：非主属性必须完全依赖于整个候选码。核心目标消除非主属性对候选码的部分函数依赖。

解决问题：避免数据冗余和更新异常，确保依赖关系的完整性。规范化方法通过分解关系模式，将部分依赖的非主属性与对应的决定因素分离，组成新的关系模式。4.2.2第2范式（2NF）-案例学生关系S满足1NF，判断其是否满足2NF。若不满足2NF，应该如何分解？1、已知关系S的候选码是(sno,cno)，则主属性为sno和cno，非主属性包括sname,ssex,sage,sdept,sdorm,cname,credit,grade。结论：S、C和SC三个关系模式中均不存在非主属性对候选码的部分依赖，满足2NF。2、学生关系S中存在以下部分函数依赖。(sno,cno)

sname，(sno,cno)

ssex，(sno,cno)

sage，(sno,cno)

sdept，(sno,cno)

cname，(sno,cno)

credit。因此，学生关系S不满足2NF。3、将部分函数依赖的非主属性与对应的决定因素组成新关系可得如下关系模式。

新的学生关系S(sno,sname,ssex,sage,sdept,sdorm)

候选码为sno

课程关系C(cno,cname,credit)

候选码为cno

选课关系SC(sno，cno，grade)

候选码为(sno,cno)4.2.3第3范式（3NF）定义与判定若关系模式R满足2NF，且R中的每一个非主属性都不传递函数依赖于R的任一候选码，则称R满足第3范式(R∈3NF)。核心目标消除非主属性对候选码的传递函数依赖，确保数据结构的直接性与独立性。规范化方法分解关系模式，将传递依赖的非主属性与对应的中间决定因素分离，组成新的独立关系。4.2.3第3范式（3NF）-案例学生关系S(sno,sname,ssex,sage,sdept,sdorm)存在的问题及解决方案1、存在的问题：由于sdorm传递函数依赖于sno，同一院系的多名学生的sdorm重复存储，这是不必要的数据冗余；当某院系的学生宿舍发生变化时，需要修改该院系所有学生的sdorm字段，修改复杂；若某个院系的学生全部转专业了，会导致该院系的信息从数据库消失。2、可见关系S仍然不“完美”，且不满足3NF。3、依据传递函数依赖对关系S进行分解得到院系关系D(sdept,sdorm)和新学生关系S(sno,sname,ssex,sage,sdept)。此时关系D和关系S均满足3NF。4.2.3第3范式（3NF）-不足之处3NF仍然可能存在问题假设：每一学生可选修多门课程，一门课程可由多个学生选修，每一课程可有多个教师任教，但每个教师只能承担一门课程。判断下列给出的关系SCT(S#，CNAME，TNAME)

最高属于第几范式？并分析该模式存在的问题。

S#CNAMETNAMEs1

英语

王平s1

数学

刘红s2

物理

高志强s2

英语

陈进s3

英语

王平

关系SCT的侯选码：(S#，CNAME)和(S#，TNAME)非主属性：无（SCT至少是一个3NF关系)

结论：若关系R的所有属性都是主属性，则R必定是3NF。在关系SCT中还存在以下问题。插入异常。例如，一个新课程和任课教师的数据，在没有学生选课时不能插入数据库。删除异常。例如，删除某门课的所有选课记录，会丢失课程与教师的数据。4.2.4BC范式（BCNF）核心定义若关系模式R∈1NF，且对于R的每一个函数依赖X→Y（Y⊈X），X都包含R的一个候选码，则称R满足BC范式，记为R∈BCNF。与3NF的关系BCNF是3NF的改进形式，要求更严格。满足BCNF的关系模式一定满足3NF，但满足3NF的关系模式不一定满足BCNF。核心目标消除任何属性（包括主属性和非主属性）对候选码的部分和传递依赖。适用场景在实际应用中，通常分解到3NF就足够了，BCNF是一个更高的理论目标。4.2.3第3范式（3NF）-案例将SCT(S#，CNAME，TNAME)分解为满足BCNF的关系模式1、因为TNAME→CNAME，其左部未包含该关系的任一侯选码，所以它不满足BCNF。2、SCT可分解为SC(S#，CNMAE)和CT(CNAME，TNAME)，它们都满足BCNF。结论：任何的二元关系必定是BCNF。4.3函数依赖的公理系统Armstrong公理•属性集的闭包•最小函数依赖集4.3.1Armstrong公理及其推论公理自反律：如果Y⊆X⊆U，则F逻辑蕴涵X

Y。增广律：如果X

Y被F所逻辑蕴涵，且Z⊆U，则F逻辑蕴涵XZ

YZ。传递律：如果X

Y和Y

Z被F所逻辑蕴涵，则F逻辑蕴涵X

Z。推论合并规则：由X

Y和X

Z，有X

YZ。伪传递规则：由X

Y和WY

Z，有XW

Z。分解规则：由X

Y和Z⊆Y，有X

Z。公理系统的作用根据已有的函数依赖推导出新的函数依赖。定义与构成定义4.8：由函数依赖集F所逻辑蕴涵的函数依赖的全体，记为F。数学表达：F={X→Y|X→Y可由阿氏公理导出}包含F本身的所有函数依赖由F推导出的非平凡函数依赖由F推导出的平凡函数依赖计算困难性与结论依赖数量呈指数级增长属性增多时，衍生出的新依赖会像滚雪球一样迅速膨胀，难以统计。推导过程繁琐且易重复需反复套用规则，且需人工检查是否重复，效率极低。结论：直接计算F+不具有实际操作性。4.3.2函数依赖集的闭包++4.3.3属性集的闭包核心定义设F是属性集U上的函数依赖集，X⊆U。所有用Armstrong公理从F推出的函数依赖X→A中，A的属性集合称为X关于F的闭包，记为X⁺。（在不产生歧义的情况下，F可以省略）计算算法步骤01.初始化：令X⁽⁰⁾=X。02.迭代：寻找F中满足V⊆X⁽ⁱ⁾的依赖V→W，令X⁽ⁱ⁺¹⁾=X⁽ⁱ⁾∪W。（V→W使用后标记为已经使用，后续不再用）03.终止：重复步骤2直到X⁽ⁱ⁺¹⁾=X⁽ⁱ⁾，此时即为X⁺。（可用属性或者可用函数依赖已经用完

无法继续更新）主要作用判断属性集X是否为候选码；判断函数依赖X→Y是否能由F逻辑推出。（这个过程是确定的，比“推公式”更实用）FF4.3.3属性集的闭包–案例1问题背景定义已知关系模式R<U,F>：属性集U={A,B,C,D,E}函数依赖F={AB→C,B→D,C→E,EC→B,AC→B}求解目标：计算属性集AB关于F的闭包，即(AB)计算过程与结果初始化：X(0)={A,B}推导：由AB→C,B→D得X(1)={A,B,C,D}推导：由C→E得X(2)={A,B,C,D,E}终止：X(2)=U，计算结束结果：(AB)

={A,B,C,D,E}结论：AB是R的一个候选码++4.3.3属性集的闭包–案例2问题背景定义已知关系模式R<U,F>：属性集U={A,B,C,D,E,F,G}函数依赖F={A→B,B→C,C→D,AD→E,E→F,F→G,BC→E}求解目标：计算属性集AE关于F的闭包，即(AE)计算过程与结果初始化：X(0)={A,E}推导：由A→B,E→F得X(1)={A,B,E,F}推导：由B→C,F→G得X(2)={A,B,C,E,F,G}推导：由C→D得X(3)={A,B,C,D,E,F,G}结果：(AE)

={A,B,C,D,E,F,G}结论：AE是R的一个候选码+终止：X(3)=U，计算结束+4.3.4函数依赖集的等价–基本概念函数依赖集等价的概念在关系模式设计中，若两个函数依赖集F和G逻辑蕴涵的函数依赖集合完全相同（即F=G），则称它们语义等价。

通俗来说，若从F能推导出的所有依赖都能从G推导出，反之亦然，则F和G表达了相同的语义信息。定义：等价与覆盖设F和G是两个函数依赖集，如果F=G，则称F和G是等价的。

也可称F覆盖G，或G覆盖F。这是判断两个函数依赖集是否等价的数学定义。++++核心判定标准：闭包相等(F=G)要证明两个函数依赖集F和G等价，必须同时满足两个方向的推导关系。这是验证等价性最严谨的数学方法。步骤一：证明F⊆G验证F中的每一个函数依赖都可以由G推导出来。这意味着G的逻辑蕴含能力至少不弱于F。步骤二：证明G⊆F验证G中的每一个函数依赖都可以由F推导出来。这意味着F的逻辑蕴含能力至少不弱于G。4.3.4函数依赖集的等价–证明++方法A→B∈F等价于B⊆A(而不是利用公理及推论来推导！)+F++4.3.4函数依赖集的等价–最小函数依赖集定义4.10：满足以下三个条件的函数依赖集F称为最小函数依赖集（记为Fmin）：1.右部单一化F中每一个函数依赖的右部都必须是单个属性。例如：不能出现X→YZ，必须拆分为X→Y和X→Z。2.左部无冗余决定因素X中没有多余属性。即不存在X的真子集X'，使得X'→A与X→A等价。例如：若XY→A成立且X→A也成立，则Y是冗余的。3.整体无冗余F中不存在可以被其他依赖推导出来的冗余依赖。即F与F-{X→A}不等价。每个依赖都是必不可少的。核心特征：最小函数依赖集是在保持与原集合等价的前提下，消除了所有形式冗余的“精炼”集合。4.3.4函数依赖集的等价–案例：最小函数依赖集已知条件关系模式R<U,F>，属性集U={A,B,C,D,E}，函数依赖集F={A→BC,BC→AD,B→C,C→B,AC→D,ABD→C,D→E}。求解步骤(三步走)1.分解利用分解规则使得F中每一个函数依赖右侧都变为单属性。分解后，F={A

B,A

C,BC

A,BC

D,B

C,C

B,AC

D,ABD

C,D

E}。2.去掉多余函数依赖

4.3.4函数依赖集的等价–案例：最小函数依赖集（续）求解步骤(三步走)2.去掉多余函数依赖

最终结果(最小函数依赖集Fmin)经过以上步骤，与F等价的最小函数依赖集为Fm={A

C,BC

A,B

C,C

B,AC

D,D

E}。3.去掉左侧多余属性（1）检查BC

A：因为B⁺=BC和C⁺=BC，均不包含A，则BC

A的左侧没有多余属性。（2）检查AC

D：因为A⁺=ABC和C⁺=ABC，均不包含D，则AC

D左侧没有多余属性。4.4关系模式的分解无损连接性·函数依赖保持性·分解算法4.4关系模式的分解-等价模式分解等价模式分解的定义将关系模式R<U,F>分解为ρ={R1,R2,...,Rn}。若分解后的模式集合ρ与原模式R能够表示相同的数据信息和数据约束（即信息无损且依赖保持），则称该分解为等价模式分解。案例4.11对比分析已知：R(U,

F)，U={Sno,Sname,Cno,Grade},F={Sno→Sname,(Sno,Cno)→Grade}。分解1：ρ1={R1(Sno,Sname),R2(Sno,Cno,Grade)}——保持了所有依赖分解2：ρ2={R1(Sno,Sname),R2(Cno,Grade)}——丢失(Sno,Cno)→Grade依赖结论：分解1是等价的，分解2不等价。模式分解必须保证信息无损且依赖保持。4.4.1无损连接性的概念严格定义设关系模式R<U,F>分解为ρ={R1,R2,...,Rn}。若对R的任何满足F的关系r，都有：r=π(R1)(r)⨯π(R2)(r)⨯...⨯π(Rn)(r)则称分解ρ具有无损连接性。通俗理解将一个大关系分解成若干小关系后，通过自然连接操作，可以精确地还原出分解前的原始关系。这意味着在分解和重构的过程中，没有信息的丢失，也没有产生多余的错误元组。核心价值无损连接性是衡量模式分解是否“好”的重要标准之一。它保证了数据在逻辑上的完整性，确保数据库中的数据在经过规范化处理后，依然能够准确地反映现实世界的信息。4.4.1无损连接性的判定算法（算法4.3）01.初始化表格构造k行n列表格，行对应关系模式Ri，列对应属性Aj。若Aj属于Ui则填aj，否则填bij。02.迭代修改表格检查F中的函数依赖X→Y，对X分量相等的行，将Y分量改为相同值（优先改a，否则改最小行号b）。03.终止条件反复迭代直到某次修改后表格无变化，算法终止。04.判定结果若存在全a行，则分解具有无损连接性；否则，不具有无损连接性。4.4.1无损连接性的判定算法–案例已知条件设有R<U,F>，U={A,B,C,D,E}，F={A→B,A→C,BC→A,B→D,D→E,BC→E}。判断ρ={AB,AC,BC,BD,DE}是否为无损分解。算法执行过程1.初始化表格：根据分解方案构造初始判定表2.迭代修改表格子模式ABCDEABa1a2b13b14b15ACa1b22a3b24b25BCb31a2a3b34b35BDb41a2b43a4b45DEb51b52b53a4a5

3.结果判定

a2a3a5a1a4a4a4a5a54.4.2函数依赖保持性基本定义设关系模式R<U,F>分解为ρ。若F的闭包等于分解后各关系模式依赖集投影的并集的闭包，即F+=(∪Fi)+，则称分解ρ保持函数依赖。判定方法检查F中的每一个函数依赖X→Y是否能被分解后的依赖集所蕴涵。即判断Y是否属于X关于(∪Fi)的闭包，确保每个依赖都能被推导。核心作用确保数据库中的数据约束在分解过程中不丢失，维护数据的一致性和完整性，是模式分解的重要衡量标准之一。4.4.3模式分解算法-确定候选码核心作用候选码是关系模式分解的基础，用于唯一确定元组。确定方法通过计算属性集的闭包来推导最小属性集。典型示例关系模式R<U,F>，U={A,B,C,D}，F={A→B,B→C,C→D}推导：A+={A,B,C,D}，包含所有属性。结论：候选码为{A}确定候选码的标准步骤步骤1：找左部属性找出所有在函数依赖中只出现在左部或两侧均未出现的属性，形成一个属性集，它们一定是候选码的一部分。步骤2：计算属性闭包计算这个属性集的闭包，如果闭包包含了所有属性，则它就是唯一的候选码。步骤3：尝试加入其他属性若闭包不全，尝试逐步加入在函数依赖两侧均出现过的属性，直到找到最小的属性集，其闭包包含所有属性。4.4.3模式分解算法（算法4.4）算法目标：3NF分解的“三赢”将关系模式R<U,F>分解为满足3NF的多个模式，且必须同时具备：无损连接性函数依赖保持性最终结论经过上述步骤处理后，最终得到的分解结果即为满足所有条件的3NF分解方案。核心执行步骤1.求最小依赖集：化简函数依赖集F为Fmin。2.分组分解：按函数依赖形成新关系。3.检查候选码：检查是否有新关系包含原候选码。4.补充候选码：若不存在，则将候选码加入分解。4.4.3模式分解算法（算法4.4）-案例4.15已知条件(R<U,F>)属性集U：{A,B,C,D,E}函数依赖F：{AB→C,C→A,BC→D,ACD→B,D→BE}01.求最小函数依赖集

4.4.3模式分解算法（算法4.4）-案例4.1502.排除与独立排除：不满足排除条件。独立：不存在N类属性，无需独立。03.分组

04.添码

4.4.3模式分解算法（算法4.4）-案例4.1505.优化

06.结论

分解验证：算法4.4目标达成度1.满足3NF范式要求每个关系模式的非主属性均完全依赖于候选码，且无传递依赖。2.具有无损连接性分解结果中包含了原关系的候选码，根据算法性质，该分解天然保证了无损连接。3.保持函数依赖完整性原函数依赖集F中的所有依赖均被分解后的子模式完整保留，未丢失语义。总结：通过算法4.4，成功将“不良”模式转化为满足3NF、无损且保依赖的“优质”模式。本章小结：关系数据库理论核心回顾01.函数依赖关系数据库理论的核心基石，描述属性间的决定关系。重点掌握平凡/非平凡、完全/部分及传递依赖等分类，理解其对数据冗余的影响。02.范式衡量关系模式优劣的标准体系。从1NF到BCNF，约束条件逐级增强，旨在消除插入、删除异常及数据冗余，构建规范的数据库结构。03.Armstrong公理系统函数依赖的形式化推理基础。掌握自反律、增广律、传递律及其推论，能够熟练计算属性集闭包，并求解最小函数依赖集。04.关系模式分解算法解决数据冗余的关键手段。核心目标是将不良模式转化为3NF或BCNF，必须保证分解的无损连接性和函数依赖保持性，这是本章的重点应用。数据库原理与应用技术第5章数据库设计本章知识导图本章学习目标了解：基本流程与需求分析掌握数据库设计基本流程，熟悉跟班作业法、访谈等需求收集方法及核心任务。理解：ER图扩展与逻辑衔接理解ER图特殊属性、弱实体及继承联系；掌握逻辑结构到物理结构的衔接逻辑。掌握：ER图转换与优化原则熟练掌握ER图绘制与转换规则，精通关系模型优化及物理结构中索引设计原则。能够：独立开展设计与建模针对简单业务逻辑独立完成需求分析，设计ER图并转化为满足3NF的关系模式。养成：规范习惯与全周期意识养成规范设计习惯，兼顾业务适配、性能与数据安全，具备数据库全生命周期迭代调整的职业意识。目录5.1数据库概述设计任务、目标与原则、基本流程5.2需求分析任务、方法、结果5.3概念结构设计目标、ER图扩展、设计方法与步骤5.4逻辑结构设计ER图转换、关系模式优化、用户子模式设计5.5物理结构设计内容和方法、索引设计5.6数据库实施与维护实施、运行和维护本章小结5.1数据库概述设计任务·目标与原则·基本流程5.1.1数据库设计概述数据库设计的重要性数据库设计是连接用户业务需求与技术实现的关键环节。

其质量直接决定了数据处理的效率、安全性与系统的整体可用性，是保障后续应用开发顺利进行的基石。数据库设计的核心任务信息管理需求确定在数据库中需要存储和管理哪些具体的数据对象，定义数据的结构与属性。数据操作需求明确对数据对象需要进行的操作类型，如查询、增加、删除、修改等，以满足业务逻辑需求。5.1.2数据库设计的目标与原则设计目标贴合业务需求准确映射用户的业务逻辑，支持各类数据操作，确保系统实用性。保障数据质量确保数据的完整性与一致性，避免冗余与冲突，维护数据可信度。优化系统性能减少响应时间，降低资源占用，确保高并发场景下的系统稳定性。设计原则一致性原则数据定义、编码规则、命名规范保持统一，降低维护成本。完整性原则通过约束确保数据符合业务规则，防止无效或错误数据进入系统。最小冗余原则减少数据冗余，实现“一次存储、多次引用”，提高存储效率。可扩展性原则预留扩展空间，便于未来业务逻辑变化时，系统能够灵活适配。5.1.3数据库设计的基本流程01.需求分析收集并分析用户需求，形成需求分析文档，确定系统边界。02.概念结构设计构建独立于DBMS的概念数据模型（如ER图），抽象信息结构。03.逻辑结构设计将概念模型转化为具体DBMS支持的数据模型（如关系模型）并优化。04.物理结构设计设计数据库的物理存储结构与存取策略，如索引、分区等。05.数据库实施创建数据库对象，加载数据，开发应用程序并进行测试试运行。06.运行和维护持续进行日常维护、性能监控、故障排除与系统优化。5.2需求分析任务、方法、结果5.2.1需求分析的任务数据需求分析确定要存储的数据，包括实体识别、属性定义和数据量估算。功能需求分析确定支持的数据操作，包括基础操作、业务流程关联和查询复杂度分析。性能与约束分析确定数据操作的质量要求，包括业务与技术约束及性能指标（响应时间、并发量）。5.2.2需求分析的方法标准调查步骤1.调查组织机构情况了解组织架构、部门职能及人员分工2.调查业务活动情况深入各部门，掌握具体业务流程与操作细节3.明确系统要求协助用户梳理功能需求、性能指标及特殊约束4.确定系统边界界定新系统与外部环境及其他系统的接口常用收集方法跟班作业深入业务一线，亲身体验流程，获取真实感受访谈法一对一或小组访谈，挖掘用户深层需求与痛点检查文档梳理现有的报表、单据和规章制度，分析数据流向调查问卷针对大量用户设计问卷，收集共性需求与量化数据5.2.3需求分析的结果数据字典对数据库中各类数据对象的描述集合，包括数据项、数据结构、数据流、数据存储和处理过程。需求说明书对需求分析成果的结构化汇总，涵盖需求背景、范围、详细内容、验收标准等。需求确认需求分析文档需经过用户和专家评审确认，作为后续设计的依据。5.3概念结构设计目标、ER图扩展、设计方法与步骤5.3.1概念结构设计的目标精准反映需求完整覆盖所有数据实体、属性及业务关联，确保无遗漏或偏差。具备高可读性采用直观的表达方式（如ER图），便于用户理解和参与评审。预留扩展空间具备一定的抽象性与通用性，能够灵活适配未来业务需求的变化。5.3.2ER图的扩展描述（属性）多值属性用双椭圆表示，实体可对应多个取值。例如：学生的“联系电话”派生属性用虚线椭圆表示，由其他属性推导而来。例如：由出生日期计算的“年龄”复合属性用嵌套椭圆表示，可拆分为多个子属性。例如：“地址”可拆分为省、市、区、街道图示：扩展属性的ER图表示方法5.3.2ER图的扩展描述（继承联系）核心概念：一般与特殊用于描述实体间“一般与特殊”的层级关系，子类继承父类属性并拥有特有属性。实体分类定义父类：一般实体，包含子类的共同属性。子类：特殊实体，继承父类并拥有特有属性。图形表示方法使用三角形连接，顶点指向父类，底边连接子类，清晰展示层级继承关系。典型示例：高校人员管理父类“人员”->子类“教师”、“行政人员”5.3.2ER图的扩展描述（基数）核心定义(Definition)描述实体间联系的数量约束，记为l..h。其中l为最小出现次数，h为最大出现次数。主要作用(Purpose)细化1:1、1:N、M:N等联系类型，明确业务规则中实体关联的具体数量限制。应用示例(Example)学生选课：学生(2..6)门课；课程(0..40)个学生。第一步：识别局部实体根据数据字典拆分业务模块，识别核心实体。要求：实体名称唯一，避免歧义第二步：定义属性与主键为实体添加描述其特征的属性。确定能唯一标识实体实例的主键。第三步：确定实体间联系分析业务逻辑，明确实体间的相互作用。判断联系类型（1:1,1:N,M:N），并按需定义联系属性。5.3.3概念结构设计–局部绘制局部ER图为每个业务模块独立绘制，确保模块内逻辑完整使用标准符号，并正确标注主键、外键等特殊属性整合全局ER图将多个局部ER图合并，消除冗余，形成完整的系统模型。核心任务：解决冲突实体冲突：统一命名与含义，消除同名异义或异名同义属性冲突：统一数据类型、长度及取值范围联系冲突：统一联系的类型（如1:1,1:N,M:N）5.3.3概念结构设计–从局部到整体优化目的旨在提升模型整体质量，通过消除冗余，避免因结构过于复杂导致的维护困难，同时确保语义上的一致性与准确性。识别冗余要素冗余联系：可由其他元素推导得出。冗余属性：可由其他属性推导或重复存储。消除策略核心方法是删除识别出的冗余元素。在分析过程中，可借助计算最小函数依赖集等形式化方法辅助判断，确保优化彻底。5.3.3概念结构设计–消除冗余符号规范严格遵循“实体-矩形、属性-椭圆形、联系-菱形”的符号规则，线段连接准确。命名规范名称简洁、表意，使用业务术语，格式统一（如实体用名词，联系用动词）。主键唯一每个实体必须有且仅有一个主键，确保能唯一标识实例。联系类型准确联系类型（1:1,1:N,M:N）需严格匹配业务逻辑，避免逻辑错误。属性确定属性必须有明确归属，不可无主或共享；联系的属性不可错归为实体属性。5.3.3概念结构设计–核心规则5.3.3概念结构设计–案例设计一个工厂产品、零件和材料的基本ER模型。实体产品：编号，性能参数，价格零件：零件号，规格材料：材料名，价格，库存量联系每种零件只能由一种材料制造，一种材料可以用于制作多种零件一种产品需要多种零件组装，一种零件可以用于组装多种零件局部E-R图设计技术部门：关心的是产品的编号、性能、由哪些零件组成，每个零件的零件号、消耗的材料名和数量。供销部门：关心的是产品的编号、价格和库存量。任务设计局部ER图

全局ER图（初步）

全局ER图（优化）。5.3.3概念结构设计–案例技术部门的局部ER图产品编号组成性能参数零件数零件号规格耗用量材料名消耗零件材料mn1m供销部门的局部ER图编号价格用量材料名价格库存量使用产品材料mn5.3.3概念结构设计–案例全局ER图（初步）产品编号组成性能参数零件数零件号规格耗用量价格用量材料名价格库存量使用消耗零件材料mn1mmn5.3.3概念结构设计–案例全局ER图（优化）产品编号组成性能参数零件数零件号规格耗用量价格材料名价格库存量消耗零件材料mn1m5.4逻辑结构设计ER图转换|关系模式优化|用户子模式设计5.4.1E-R图向关系模式的转换实体的转换基本规则一个实体对应一个关系模式。实体的属性即为关系模式的属性，实体的码即为关系模式的码。具有相同码的关系模式可以合并。联系的转换1:1联系将一方的码加入另一方，或独立建立关系模式。1:N联系将一方（1方）的码加入另一方（N方）或独立建立关系模式。M:N联系必须独立建立关系模式，包含双方码和联系属性。多元联系必须独立建立关系模式，包含双方码和联系属性。特殊情况的转换多值属性为多值属性单独建立一个关系模式。派生属性可以由其他属性得到，省略。复合属性将其拆分为多个简单属性。继承联系采用单表继承或多表继承的方式。案例：1:1联系的转换方法一：将“教师”的码加入“办公室”关系教师(教师号,姓名,职称)办公室(办公室编号,楼栋,面积,教师号)方法二：将“办公室”的码加入“教师”关系教师(教师号,姓名,职称,办公室编号)办公室(办公室编号,楼栋,面积)方法三：独立建立一个关系模式教师(教师号,姓名,职称)办公室(办公室编号,楼栋,面积)办公(办公室编号,教师号)案例：1:N联系的转换转换方法：引入外键将“部门”的码加入“员工”关系模式中，形成如下结构：部门(部门编号,部门名称,部门电话)员工(员工编号,姓名,职位,入职日期,部门编号)核心原理说明在1:N联系中，总是将“1”方的码加入“N”方的关系模式中。案例：M:N联系的转换转换方法：建立独立关系模式学生实体：学生(学号,姓名,性别,所在院系)课程实体：课程(课程号,课程名,学分,

先修课程号)选课联系：选课(学号,课程号,成绩)关键说明：选课关系的码（主键）是“学号”和“课程号”的组合。它不仅记录了学生的选课情况，还存储了成绩这一联系属性。案例：多元联系的转换转换方法：建立独立关系模式供应商(供应商编号,供应商名,地址)工程(工程编号,工程名称)设备(设备号,设备名)供应(供应商编号,工程编号,设备号,数量)关键说明：供应关系的码（主键）是“供应商号”、“工程编号”和“设备号”的组合。案例：特殊情况的转换多值属性：学生联系电话处理方式：单独建立关系模式学生(学号,姓名,专业)学生电话(学号,电话号码)复合属性：学生地址处理方式：拆分为简单属性并入原实体学生(学号,姓名,专业,省,市,区,街道)或者：将地址视作一个属性（类型为字符串）继承：职工

教师/行政人员处理方式1：父类和子类均独立为关系模式职工（工号，姓名，性别，联系电话，人员类型）教师（工号，院系，职称）行政人员（工号，部门，级别）处理方式2：仅子类均独立为关系模式教师（工号，姓名，性别，联系电话，人员类型,院系，职称）行政人员（工号，姓名，性别，联系电话，人员类型，部门，级别）处理方式3：父类与子类合并为单一关系模式教师（工号，姓名，性别，联系电话，人员类型,院系，职称,部门，级别）案例：实体集内部实体间联系的转换职工工号姓名年龄民意测验性别职称领导1m职工（工号，姓名，年龄，性别，职称，领导者工号，民意测验）零件代号名称数量价格组装mn零件（代号，名称，价格）组装（代号，组装件代号，数量）案例：弱实体的转换职工（工号，姓名，年龄，性别，职务）亲属（工号，亲属姓名，亲属关系）职工工号姓名年龄性别职称亲属亲属关系亲属姓名有综合案例P(P#，PP，PC)S(S#，SP)M(M#，MC)L(L#，LC)P-S(P#，S#，Q1)S-M(S#，M#，Q2)M-L(M#，L#，Q3)Q1组成mnP#PP产品PSPS#零件SQ3存放mn材料MM#MC仓库LL#LOCPCQ2消耗n1合并？5.4.2关系模式的优化-关系规范化优化的必要性转换后的关系模式可能存在数据冗余和更新异常，需要进一步优化以确保逻辑模型的健壮性。1.确定数据依赖深入分析关系模式中的函数依赖（FD），明确属性间的约束关系，这是优化的基础。2.关系模式分解根据数据依赖将大模式分解为小模式，消除部分依赖和传递依赖，解决数据冗余问题。3.检查范式确保分解后的关系模式满足更高的范式要求，通常目标是达到3NF（第三范式）或BCNF。4.综合权衡在规范化和查询效率之间寻找平衡点，必要时可适当保留冗余以提升系统性能。案例：关系模式优化优化前：存在数据冗余与异常原始模式：订单(订单号,客户号,客户名,商品号,商品名,数量,单价)核心问题：客户名、商品名等属性重复存储，导致更新异常依赖分析：存在传递依赖（如订单号→客户号→客户名）优化后：满足3NF规范分解结果：订单、客户、商品、订单明细（共4个关系）优化效果：彻底消除了数据冗余，解决了插入、删除和更新异常设计原则：遵循“一事一地”原则，每个表只描述一个实体垂直分割定义：按属性相关性拆分，适用于属性过多且访问频率差异大的场景。目的：减少无效数据加载，提升高频字段查询效率。基本信息表ID/姓名/性别扩展信息表兴趣/地址/简介水平分割定义：按行划分独立子集（如时间、地区），适用于超大表。目的：缩小扫描范围，缓解单表性能压力。订单_2023表：仅包含2023年数据订单_2024表：仅包含2024年数据核心区别总结：垂直分割是“按列拆分”，解决列宽问题；水平分割是“按行拆分”，解决行多问题。两者都是为了优化数据库查询性能。5.4.2关系模式的优化-分割5.4.3用户子模式设计什么是用户子模式？用户子模式（外模式）是数据库整体逻辑模式的一个子集，是为不同用户或应用程序设计的局部数据视图。核心设计原则根据不同用户的需求和权限，设计针对性的用户视图，确保视图既满足业务需求又符合权限控制。主要作用与价值保障数据安全限制用户只能访问其权限范围内的数据，防止越权操作。简化用户操作提供符合业务习惯的数据视图，隐藏复杂的底层结构，提升易用性。确保数据独立性底层逻辑模式变化时，只需调整映射关系即可保证应用程序稳定。5.5物理结构设计内容和方法、索引设计5.5.1物理结构设计的内容和方法核心设计内容存储结构设计确定存储位置及文件组织方式（堆文件、顺序文件、散列文件）。存取路径选择设计数据的存取路径，主要通过索引来实现高效查找。索引设计选择合适的列建立索引，并根据查询模式选择最优索引类型。分区设计对大表进行逻辑或物理分区，显著提高查询和维护效率。标准设计方法确定数据分布策略根据数据的使用频率和重要性，将数据分布在不同的存储设备上。选择存储结构根据数据的特点（如大小、更新频率）和操作需求选择文件组织方式。设计访问方法核心在于索引设计，这是提高系统查询效率的关键环节。5.5.2索引设计索引的作用索引是一种数据结构，如同书的目录，能帮助数据库快速定位数据，显著提升查询效率。核心设计原则选择合适的列：优先在主键、外键及WHERE子句常用列上建立。避免过度索引：索引会增加写操作开销，需权衡查询与更新性能。考虑索引类型：B+树适用于范围查询，哈希索引适用于等值查询。定期维护索引：定期重建或整理，防止索引碎片化影响效率。B+树索引结构示意图5.6数据库实施与维护实施、运行和维护5.6.1数据库实施1.创建数据库对象使用DDL语句（如CREATETABLE,CREATEINDEX）创建数据库、表、视图、索引等，构建物理存储结构。2.数据加载将实际的业务数据导入到数据库中，可利用数据库自带的导入工具（如SQLLoader）或编写专门的迁移程序。3.应用程序开发开发与数据库交互的应用程序，封装数据访问逻辑，实现用户所需的各项业务功能和操作界面。4.系统测试与试运行进行全面的测试（功能、性能、压力），确保系统满足设计要求，并进行试运行以发现潜在问题。5.6.2数据库运行和维护数据备份与恢复定期备份数据库，制定灾难恢复计划，确保数据的安全性与可恢复性。性能监控与优化监控数据库运行性能，分析慢查询，调整索引和配置参数，持续优化系统响应速度。数据结构调整根据业务需求的变化，对数据库结构进行灵活调整和升级，以适应新场景。安全管理严格管理用户权限，实时监控数据库访问日志，防止数据泄露和恶意攻击。数据库备份与恢复策略常见备份策略解析完全备份(FullBackup)备份整个数据库，恢复简单但耗时久、占用空间大。适合作为基础备份。增量备份(IncrementalBackup)仅备份自上次备份后的变化数据，速度快但恢复依赖多，过程较复杂。差异备份(DifferentialBackup)备份自上次完全备份后的变化数据，恢复较简单，但文件体积比增量大。组合策略建议：通常采用“完全备份+增量备份”或“完全备份+差异备份”以平衡效率与恢复速度。本章小结-核心知识点回顾01需求分析核心：明确“做什么”，产出数据字典和需求说明书。02概念结构设计核心：设计ER图，定义实体、属性及联系（继承、基数等）。03逻辑结构设计核心：ER图转关系模式，优化至3NF或BCNF范式。04物理结构设计核心：设计存储结构与索引，目标是优化系统性能。05实施与维护核心：将设计落地，进行持续的运行保障和性能优化。全流程回顾遵循标准流程：需求分析→概念设计→逻辑设计→物理设计→实施维护。本章小结-重点技能回顾独立完成需求分析能够与用户沟通，梳理业务流程，编写数据字典。设计ER图能够根据需求，绘制包含扩展概念的完整ER图。ER图转换能够熟练地将ER图转换为关系模式。关系模式优化能够分析函数依赖，将关系模式分解为3NF。物理设计能够进行简单的表结构设计和索引设计。第6章事务管理事务的定义、恢复与并发控制本章知识导图本章学习目标了解：事务定义与并发基础事务的定义与状态、数据库故障类型，以及并发控制的封锁、时间戳等基础技术。理解：ACID特性与数据一致性事务ACID特性的内涵、数据库恢复的基本原理，以及并发操作导致数据不一致的原因。掌握：恢复策略与封锁协议先写日志后写数据库的原则、三类故障的恢复策略，以及一至三级封锁协议的规则与作用。目录01事务的基本概念定义、状态与ACID特性02数据库恢复技术故障类型与恢复策略03事务的并发控制问题与解决方案04本章小结回顾本章重点内容，总结核心知识点6.1事务的基本概念定义、状