关系数据库理论1

关系数据库理论(上)数据模型演进、核心概念与完整性约束Contents课程目录关系数据库理论（上）——从关系模型的起源到E-R图向关系模式的完整转换路径。01关系模型的诞生与演进02关系模型的核心术语03关系的数学性质与约束04E-R图向关系模式的转换CHAPTER01关系模型的诞生与演进从E.F.Codd的论文到现代数据管理的主干DATABASEHISTORY关系模型的提出与图灵奖1970年E.F.Codd提出关系模型，用简单的二维表取代复杂的指针结构，为数据库技术奠定了坚实的数学基础，并因此荣获1981年图灵奖。011970IBMSanJose研究室研究员E.F.Codd发表《大型共享数据库数据的关系模型》，首次提出关系模型概念02二维表抽象开创了数据库的关系方法和关系数据理论研究，将复杂的物理存储抽象为用户友好的二维表逻辑结构031981E.F.Codd获得ACM图灵奖，关系模型成为现代数据库系统的绝对主流E.F.Codd（1923–2003）·关系模型之父·1981年图灵奖得主DatabaseTheory三种经典逻辑数据模型对比数据模型经历了从层次模型（树形）、网状模型（图）到关系模型（二维表）的演进。关系模型凭借其简单的结构、严格的数学基础和极高的数据独立性，彻底取代了前两者，成为当今数据库领域的绝对标准。经典数据模型演进对比模型名称数据结构代表系统核心特点与局限层次模型树形结构（唯一根节点，每节点至多一个父节点）IBMIMS(1968)清晰直观；只能直接表示1:N联系；查询必须从根出发，路径依赖强网状模型有向图（节点可有多个父节点，可直接表示M:N）CODASYL(1969)更贴近现实；结构复杂；数据独立性差；用户需掌握导航式查询，使用困难关系模型二维表（行=元组，列=属性），概念最简单MySQL/Oracle/SQLServer有严格数学基础；操作简便（SQL）；独立性高；应用最广泛关系模型以二维表为核心，凭借数学严谨性与操作简便性，全面超越了层次与网状模型。RELATIONALMODEL关系模型的组成与"语义过载"关系模型由数据结构、关系操作和完整性约束三部分组成。其"单一数据结构"的特性虽然简化了逻辑，但也带来了"语义过载"问题，即系统无法自动区分实体表与联系表，需要设计者通过外键等机制显式表达业务语义。01关系模型三大支柱：单一的数据结构（二维表）、关系操作集合（Select/Join等）和关系完整性约束（实体/参照/用户定义）三大支柱02优势：概念简单，用户视图即二维表，屏蔽了底层物理存储细节，实现了高度的数据独立性数据独立性03局限（语义过载）：表达实体间复杂关系（如M:N）需拆分多表，DBMS无法原生区分"实体"与"联系"，业务规则需依赖应用层或外键约束维护语义过载关系数据库运行在大规模数据中心基础设施之上CHAPTER02关系模型的核心术语从数学集合论视角重新认识"二维表"RelationalModel·CoreStructures关系(Relation)与元组(Tuple)关系是关系模型的核心数据结构，表现为一张规范化的二维表；元组是关系中的一行，代表现实世界中一个实体的具体实例。学生信息登记表·关系的物理映射01关系Relation—一张规范化的二维表，由表名、属性（列）和元组（行）构成，每个关系在数据库中必须有唯一名称表名·属性·元组02元组Tuple—表中的一行数据，对应现实世界中一个实体的具体实例（如一名学生的全部信息），元组的集合构成了关系的内容一行=一个实体实例03规范化要求—关系必须满足特定的范式条件（如1NF），确保数据结构的严谨性，避免冗余与异常1NF范式RELATIONALMODEL属性(Attribute)与域(Domain)属性是关系中的列，代表实体的某种特征；域是属性的取值范围。属性的同质性与唯一性是保证关系结构合法性的基本前提。01属性（Attribute）：表中的一列，每列有唯一的属性名。一个关系中属性的个数称为该关系的"目"或"度"（Degree）02列的同质性：同一列中的数据类型必须相同（来自同一个域），确保数据处理的逻辑一致性03列名唯一性：同一关系中不能有重名属性，但不同关系可以有同名属性（通过关系名前缀区分）04域（Domain）：属性的取值范围，是一组具有相同数据类型的值的集合（如所有正整数、长度≤20的字符串）图书馆卡片目录柜——属性分类与域约束的物理隐喻RELATIONALMODEL·KEY核心概念：码(Key)的严格定义码是关系模型中用于唯一标识元组的属性集合。理解候选码的'最小性'、主码的唯一性以及主属性与非主属性的划分，是掌握实体完整性约束的前提。唯一标识——码的核心语义01候选码（CandidateKey）—能唯一标识元组的最小属性集合。"最小"意味着其任意真子集都无法单独唯一标识元组02主码（PrimaryKey,PK）—从候选码中选定的一个，作为元组的唯一标识符。主码的所有属性均不允许为NULL03主属性/非主属性—属于任意一个候选码的属性称为主属性；不属于任何候选码的属性称为非主属性（非码属性）RelationalIntegrity外码(ForeignKey)与表间联系外码是建立关系之间语义联系的纽带。通过外码机制，关系模型实现了参照完整性，确保了跨表数据的一致性，并支持自参照等复杂结构。外码定义：本关系中的一个属性（组），其值是另一个（或同一个）关系的主码，用于在两个关系之间建立语义联系参照完整性：外码的值必须要么为空，要么等于被参照关系中某个元组的主码值，防止出现"悬空指针"自参照：外码可以指向自身关系的主码（如Course表中的"先修课程号"指向"课程号"），用于表达层次或递归关系链条链接——外码连接不同关系的隐喻CHAPTER03关系的数学性质与约束从集合论视角解析关系的六大性质与三大完整性RelationalProperties关系的六个基本性质关系作为规范化的二维表，必须满足列同质、列名唯一、原子性、元组唯一及行列序无关等六大性质。其中"原子性"是第一范式（1NF）的核心要求，是关系数据库设计的底线。01原子性（1NF基础）：每个属性值必须是不可再分的原子值，不允许集合、列表或嵌套表出现在一个格中02元组唯一性：不允许有完全相同的两行（无重复元组），由主码约束自动保证03行序/列序无关性：元组与属性的排列顺序无关紧要，任意交换不影响关系语义（逻辑层面）04列同质性：同一列中的所有值必须来自相同的域（数据类型），确保数据的一致性和可比性05列名唯一性：每个属性必须有唯一的名称，同一关系中不能存在两个同名的列06分量原子性：每个元组在每个属性上的取值都是单值，确保关系处于第一范式（1NF）的规范状态EntityIntegrity完整性约束一：实体完整性实体完整性规则要求主码的任何属性均不能为空（NULL）。这是保证元组可被唯一标识的前提，违反了该规则，关系中的实体将失去其存在的逻辑意义。身份证主码：公民身份号码作为实体唯一标识01规则定义：若属性（或属性组）是基本关系的主码，则该属性（或属性组）不能取空值（NULL）02逻辑依据：主码用于唯一标识元组，空值意味着"未知"或"不存在"，导致实体无法被区分或引用03组合主码约束：当主码由多个属性组成时，所有构成主码的属性均不能为空，否则无法保证唯一性ReferentialIntegrity完整性约束二：参照完整性参照完整性规则约束了外码的取值范围，确保关系之间的引用合法有效。它是维护跨表数据一致性、防止"悬空引用"的核心机制。01规则定义若属性F是关系R的外码，且参照关系S的主码Ks，则R中每个元组在F上的值必须：要么为空，要么等于S中某个元组的主码值02业务意义防止出现"悬空指针"（如学生属于不存在的院系），确保数据引用的逻辑一致性03级联操作当被参照表的主码被修改或删除时，DBMS通常提供级联更新/删除、置空或拒绝等策略来维护参照完整性路标指示牌——隐喻外码对主码的"指向"与"引用"关系IntegrityConstraint·III完整性约束三：用户定义完整性用户定义完整性是针对具体应用环境的业务规则约束。它反映了现实世界对数据的特定语义要求，是保证数据'正确性'与'合理性'的最后一道防线。精确度量——每一条业务规则都是数据质量的刻度线01针对某一具体关系数据库的约束条件，反映具体应用所涉及的语义要求，如年龄>0、成绩在0–100之间等业务规则。语义约束02现代RDBMS提供CHECK约束、触发器（Trigger）、存储过程等机制，将业务规则内置于数据库层，避免应用层重复校验。CHECK03若不支持此类约束，业务规则需硬编码在应用程序中，易导致数据不一致与维护困难，增加系统耦合度。一致性RELATIONALOPERATIONS关系操作集合与集合论基础关系模型提供了基于集合论的强大操作能力，包括选择、投影、连接等查询操作及增删改操作。其'一次一集合'的操作方式，奠定了现代SQL语言的高效性与简洁性。文氏图·集合运算可视化01核心操作：包括选择（Select）、投影（Project）、连接（Join）、除（Divide）及并、交、差等集合运算Select·Project·Join02理论基础：关系代数（基于运算）与关系演算（基于谓词逻辑）在表达能力上完全等价，共同构成了SQL的理论基石代数≡演算03操作特点：采用'一次一集合'（set-at-a-time）方式，操作对象与结果均为集合，区别于非关系模型的'一次一记录'方式Set-at-a-TimeCHAPTER04E-R图向关系模式的转换从概念设计到逻辑设计的标准化落地规则CONVERSIONRULESE-R图转换为关系模式的四条规则E-R图向关系模式的转换是数据库逻辑设计的核心步骤。通过实体转换、1:1合并、1:N外键引入及M:N独立建表这四条标准化规则，可将概念模型精准落地为关系表结构。01实体规则：每个实体型转换为一个关系模式，实体属性成为关系属性，实体码成为关系主码021:1联系：可将联系及其属性合并到任意一端关系中（通常选查询更频繁的一端），或单独建表031:N联系：将联系的属性及1端实体的主码加入N端关系中，即N端添加外键指向1端04M:N联系：必须单独建立一个新的关系模式，新关系主码为两端实体主码的组合，联系的属性也加入该关系从概念模型到逻辑结构的转换与组合CASESTUDY实战案例：学生选课系统转换结果以学生选课系统为例，展示实体与联系如何严格按照规则转换为包含主外键约束的关系模式集合。关系模式名称属性列表(含主外键标注)主码与外码约束说明院系(Dept)系编号,系名,系主任主码：系编号学生(Student)学号,姓名,性别,出生日期,系编号主码：学号|外码：系编号→院系.系编号课程(Course)课程号,课程名,学分,先修课程号主码：课程号|外码：先修课程号→Course.课程号(自参照)选课(SC)学号,课程号,成绩主码：(学号,课程号)|外码：学号→Student,课程号→Course该案例完整演示了1:N外键引入、M:N独立建表及自参照结构的落地方法。DatabaseEvolution关系数据库的现代演进与地位关系数据库凭借其数据完整性、可伸缩性和安全性，依然是现代企业任务关键型系统的主干。云原生技术的引入，更使其在AI分析、全球部署等场景中焕发出新的生命力。01核心地位：广泛用于银行、电子商务、大型企业等任务关键型系统，支持数据完整性、可伸缩性和安全性02云原生演进：提供全球规模、高可用性和与分析、AI及新式应用体系结构的兼容性，突破了传统本地部署的局限03架构基石：关系数据库架构（表、列、键、关系）依然是现代数据治理与数据仓库建设的逻辑基础云原生时代的数据中心——关系数据库在全球规模基础设施上持续演进Summary课程核心知识点回顾本节课系统梳理了关系数据库的理论基石，涵盖模型演进、核心术语定义、数学性质、完整性约束及E-R图转换规则，为后