知识点
根据提供的来源,我为您提取并整理了第一讲:数据库系统概述中1.1至1.4节的全部核心内容:
1.1 数据库系统的基本概念
- 数据 (Data):数据是有结构的,“记录”是其在计算机中的存储格式。数据具有“型”(描述)与“值”(具体内容)之分,并受类型和取值范围的约束。
- 信息 (Information):信息是客观事物特征的抽象描述,是数据处理的结果,对决策具有价值。
- 数据与信息的关系:数据是信息的载体,信息是数据的内涵。
- 数据库管理系统 (DBMS) 的主要功能:
- 数据定义 (DDL):定义数据库中的数据对象。
- 数据操纵 (DML):实现查询、插入、删除和修改等基本操作。
- 数据库控制(运行管理):包括安全性控制、完整性控制、并发控制和存取控制。
- 数据库维护:数据的装入、转储、恢复、重组织以及性能监控。
1.2 数据管理技术的产生与发展
数据管理经历了以下三个主要阶段,其特征对比显著:
- 人工管理阶段 (20世纪50年代中期以前):主要用于科学计算。数据不长期保存,由程序员人工管理,数据不具有独立性且不能共享。
- 文件系统阶段 (20世纪50年代后期至60年代中期):用于信息管理,数据可长期保存。虽然有了记录内的结构化,但整体无结构,导致数据冗余度大、独立性差且联系弱。例如阿波罗计划曾因文件系统的分散管理导致60%的数据冗余。
- 数据库系统阶段 (20世纪60年代后期至今):
- 整体结构化:数据面向整个企业或组织,最小存取单位是数据项。
- 高独立性:具有高度的物理独立性和一定的逻辑独立性。
- 高共享、低冗余:易于扩充,能避免数据不一致性。
- 控制功能完整:由DBMS统一提供安全、完整、并发控制和恢复能力。
1.3 数据库系统的组成 (DBS)
数据库系统是指在计算机系统中引入数据库后的整体构成,主要包含以下要素:
- 硬件平台:需要足够大的内存、磁盘(或磁盘阵列)以及较高的通道能力。
- 软件:包括 DBMS (核心)、操作系统 (OS)、高级语言及其编译系统、应用开发工具以及数据库应用系统 (APP)。
- 人员:
- 数据库管理员 (DBA):负责规划、设计、协调、维护和管理数据库。
- 系统分析员和数据库设计人员:负责需求分析和模式设计。
- 应用程序员:设计和编写应用模块。
- 最终用户:包括偶然、简单和复杂用户。
1.4 数据库系统的模式结构
数据库系统采用三级模式结构,通过二级映像实现数据独立性:
- 三级模式:
- 模式 (Schema):也称逻辑模式,是数据库中全体数据的逻辑结构和特征的描述,是所有用户的公共数据视图,一个数据库只有一个模式。
- 外模式 (External Schema):也称子模式或用户模式,是用户能够看见和使用的局部数据的描述,用于简化视图并保证安全性。
- 内模式 (Internal Schema):也称存储模式,描述数据的物理结构和存储方式(如索引、压缩、加密),一个数据库只有一个内模式。
- 二级映像与独立性:
- 外模式/模式映像:定义外模式与模式的对应关系,保证了逻辑独立性(模式改变时,外模式和应用程序可保持不变)。
- 模式/内模式映像:定义逻辑结构与存储结构间的对应关系,保证了物理独立性(存储方式改变时,模式和应用程序无需修改)。
💡 形象化总结(比喻):
- 数据管理的发展:就像从早期的“个人记事本”(人工管理)进化到“乱序的文件柜”(文件系统),最终演变为“自动化智能图书馆”(数据库系统)。
- 三级模式与映像:就像电影院。内模式是后台放映机里的胶卷(物理存储);模式是整部电影的剧本和所有画面(逻辑全貌);外模式则是不同观众买票看到的特定片段(如3D版或剪辑版)。而映像功能就像是一套自动适配系统,无论电影院换了什么放映机(物理改变)或调整了剪辑顺序(逻辑改变),作为观众的你(应用程序)看到的画面逻辑永远是连续且正常的。
根据提供的来源,我为您提取并整理了第二讲:数据模型中2.1至2.3节的核心内容:
2.1 数据模型的概念
- 定义:数据模型是对现实世界客观事物的数据抽象描述,能确切反映事物、特征及联系,是一组严格定义的概念集合。通俗地说,它就是现实世界的模拟。
- 地位:数据模型是数据库系统的核心。
- 研究目标:如何以逻辑和物理方式安排和识别数据。
- 性能要求:
- 能真实模拟现实世界。
- 容易为人所理解。
- 便于在计算机上实现。
- 抽象层次:分为概念数据模型、结构(逻辑)数据模型和物理数据模型三个层次。
2.2 概念数据模型 (Conceptual Data Model)
- 基本特征:它是数据库设计中的高层抽象工具,按用户观点建模,与具体 DBMS 无关,是设计员与用户交流的语言。
- 核心模型:简称概念模型,最著名的是实体-联系(E-R)模型。
- 关注点:仅关注现实世界中哪些是重要的“事物”(实体)、特征(属性)及如何关联,不涉及技术实现细节。
- 基本概念:
- 实体 (Entity):客观存在并可相互区别的事物,如学生、课程。
- 属性 (Attribute):实体所具有的特征,如学号、姓名。
- 实体型 (Entity Type):对一类实体特征的结构描述。
- E-R图表示法:
- 矩形:表示实体型。
- 椭圆:表示属性。
- 菱形:表示联系,并在边上标明联系类型(1:1, 1:n, m:n)。
- 联系的种类:包括两个实体集之间的联系,也包括实体集内部的联系(如领导与被领导关系)。
2.3 结构数据模型 (Structural Data Model)
这是数据库技术发展的核心主线,主要经历了几代变革:
2.3.1 层次模型 (Hierarchical Model)
- 数据结构:树(Tree)。
- 特征:有且只有一个根结点;其他结点有且只有一个双亲结点。
- 优缺点:结构简单,联系固定时性能优于关系模型;但只能表示1:n联系,处理m:n联系非常复杂,且查询/更新操作编写困难。
2.3.2 网状模型 (Network Model)
- 数据结构:有向图(Directed Graph)。
- 特征:允许一个以上结点无双亲;一个结点可以有多个双亲。
- 优缺点:能更直接描述现实世界,性能良好;但结构复杂,DDL/DML 语言深奥,用户不易掌握。
2.3.3 关系模型 (Relational Model)
- 数据结构:二维表结构。
- 优点:
- 建立在严格的数学理论基础(关系代数)之上。
- 概念单一,实体和联系均用“关系”表示。
- 存取路径对用户透明,具有更高的数据独立性和安全性。
- 数据操作是集合操作。
- 关系模型常用术语对照:
- 关系模式:对应 E-R 模型的“实体型”,文件系统的“记录型”。
- 关系 (表):对应 E-R 模型的“实体集”,文件系统的“数据文件”。
- 元组:表中的一行,对应 E-R 模型的“实体”,文件系统的“数据记录”。
- 属性:表中的一列,对应文件系统的“字段”。
- 候选键/主键:能唯一确定元组的属性组。
- 外键:对应另一个关系模式的主键。
💡 形象化总结:
- 概念模型(E-R图) 就像是装修房子前的概念设计图,只谈功能(客厅、卧室)和关系(门连着走廊),不谈装修材料。
- 结构模型(层次/网状/关系) 就像是具体的施工图纸。层次模型像家族族谱(树);网状模型像交通路线图(图);而关系模型就像是Excel表格集合,既整齐又科学。
根据您提供的资料,我为您提取并整理了第三讲:SQL数据定义语句中3.0至3.2节的所有核心内容:
3.0 初识数据库
- 数据的存储逻辑:数据库通过基本表来存放数据,例如在教学管理系统中,需要保存学生信息、课程信息、教师信息、选课信息和授课信息。
- 关系模型术语:
- 关系模式(Schema):对应二维表的表头(记录型)。
- 元组:对应表中的每一行数据(数据记录)。
- DBMS 的差异性:不同的数据库管理系统(如 SQL Server 和 MySQL),其内模式(物理存储方式)是不同的。
- 三级模式结构:MySQL 支持三级模式结构,通过外模式/模式映像和模式/内模式映像,由 DBMS 自动管理数据。
3.1 MySQL 概述
- 数据库构成:
- 系统数据库:包括
information_schema(元数据库,保存所有数据库信息)、mysql(存储用户权限控制)、performance_schema(监控服务器性能参数)和sys(简化性能监控数据)。 - 用户数据库:由用户根据实际需求手动创建。
- 系统数据库:包括
- 存储引擎(基于表):
- InnoDB(默认引擎):设计用于处理巨大数据量的最大性能,是事务安全的,支持外键、行级锁和全文搜索,适用于大量更新操作。
- MyISAM:非事务安全,不支持外键,使用表级锁,适用于以查询为主的表。
- 查看命令:使用
SHOW ENGINES;或SHOW variables like '%storage_engine%';查看支持的引擎。
- 字符集与校验规则:
- MySQL 支持在服务器级、数据库级、表级和列级进行四个级别的默认设置。
- 目前 MySQL 默认推荐选择 UTF-8 (Unicode)。
3.2 SQL 数据定义语句 (DDL)
- 操作对象与方式:
- 数据库:
CREATE DATABASE(创建)、DROP DATABASE(删除)、ALTER DATABASE(修改)。 - 基本表:
CREATE TABLE(创建)、ALTER TABLE(修改表结构)、DROP TABLE(删除表)。 - 索引:
CREATE INDEX(创建)、DROP INDEX(删除)。
- 数据库:
- 核心语法规范:
- 创建数据库:
CREATE DATABASE [IF NOT EXISTS] <数据库名> [[DEFAULT] CHARACTER SET 字符集名]。 - 删除基本表:
DROP TABLE [IF EXISTS] <表名>;执行后数据和结构都会被删除,相关索引也会一并删除。 - 修改基本表 (ALTER TABLE):
- 添加列:
ADD [COLUMN] <新列名> <类型> [FIRST|AFTER 列名]。 - 修改列:
MODIFY [COLUMN] <列名> <新类型>。 - 删除列:
DROP [COLUMN] <列名>。 - 重命名列:
CHANGE [COLUMN] <旧名> <新名> <类型>。
- 添加列:
- 创建数据库:
- 索引的分类与创建:
- 直接创建:
CREATE [UNIQUE] INDEX <索引名> ON <表名>(<列名> [ASC|DESC])。 - 间接创建:在创建主键约束(自动产生唯一性聚簇索引)或唯一性约束(自动产生唯一性非聚簇索引)时系统自动创建。
- 直接创建:
💡 形象化总结:
如果把 3.0-3.2 的内容比作开办一家工厂:
- 3.0 (初识):是决定工厂要生产什么产品(如学生表、课程表),并理解工厂的图纸(模式结构)。
- 3.1 (MySQL概述):是选择工厂的底层设备,比如是选择更安全稳健但复杂的“InnoDB引擎”生产线,还是简单的“MyISAM”生产线,并统一员工的交流语言(字符集)。
- 3.2 (DDL语句):就是具体的行政指令。
CREATE是盖新厂房(建库建表),ALTER是装修或扩建厂房(加减字段),INDEX则是为仓库货物贴上快速检索的标签(建索引)。
根据您提供的资料,我为您提取并整理了第四讲:MySQL语言基础与单表查询中4.1至4.3节的完整内容。
4.1 MySQL语言的规则与规范
- 基本书写规则:
- SQL语句可以单行或多行书写,为了提高可读性,建议各子句分行并使用缩进。
- 每条命令必须以分号(
;)、\g或\G结束。 - 关键字不能缩写也不能分行。
- 标点符号规范:
- 必须保证括号、单引号、双引号成对结束,且必须使用英文半角输入法。
- 字符串和日期时间类型数据建议使用单引号(
' ')。 - 列的别名建议使用双引号(
" "),且不建议省略AS关键字。
- 大小写规范:
- 受操作系统影响:在Windows环境下大小写不敏感,但在Linux环境下,数据库名、表名、变量名严格区分大小写。
- 忽略大小写部分:关键字、函数名、列名(字段名)及其别名在所有环境下通常忽略大小写。
- 推荐规范:对象名(数据库、表、字段等)使用小写,而SQL关键字、函数名使用大写。
- 命名规则:
- 数据库和表名不得超过30个字符,变量名限制为29个。
- 只能包含字母(A-Z, a-z)、数字(0-9)和下划线(_)。
- 对象名中间不能包含空格,且在同一层级内不能重名。
- 若字段名与保留字冲突,必须使用着重号(`)引起来。
- 注释结构:
- 单行注释可使用
#(MySQL特有)或--(注意此处包含一个空格)。 - 多行注释使用
/* 注释内容 */。
- 单行注释可使用
4.2 SELECT语句简介
- 一般格式:
- 完整的查询结构包括:
SELECT [DISTINCT] <目标列表达式> FROM <表/视图> [WHERE <条件>] [GROUP BY <列名> [HAVING <条件>]] [ORDER BY <列名> [ASC|DESC]] [LIMIT [偏移量,] 行数]。
- 完整的查询结构包括:
- 核心功能分类:
- 条件查询:按“行”进行筛选。
- 投影查询:按“列”进行筛选,可使用
*代表所有属性列。 - 分组统计:按“组”进行数据聚合。
- 结果排序:对查询出的数据进行升序(ASC)或降序(DESC)排列。
- 查询类别:包括单表查询、连接查询、嵌套查询和集合查询。
4.3 MySQL的单表查询
- 无条件查询:
- 不使用
WHERE子句,直接提取表中指定列或所有列的数据。 - 可以使用表达式计算,例如通过
(YEAR(NOW()) - YEAR(Sbirth))计算学生年龄并起别名为 "Sage"。
- 不使用
- 条件查询(常用运算符与函数):
- 范围匹配:使用
BETWEEN ... AND ...匹配数值区间。 - 集合匹配:使用
IN (...)匹配多个离散值,如筛选职称位“讲师”或“助教”的教师。 - 类型转换与截取:
CONVERT(expr, type)用于转换数据类型,LEFT(expr, n)用于获取字符串左侧指定长度的子串。
- 范围匹配:使用
- 分组统计高级特性:
- 去重计数:普通计数建议用
COUNT(*),若需去除重复后计数则使用COUNT(DISTINCT <列名>)。 - WITH ROLLUP:在常规分组基础上生成多层次的小计和总计行。
- 互斥规则:
WITH ROLLUP和ORDER BY是互相排斥的,不能在同一个语句中同时使用。
- 去重计数:普通计数建议用
- 分页显示:
- 使用
LIMIT子句控制返回结果的行数和起始位置。
- 使用
💡 形象化比喻:
如果把数据库查询比作在超市选购商品:
- 4.1 规范 就是超市的入场守则(必须推购物车、不能逆行、标签要贴对),违反了这些规则你根本进不去店里(报错)。
- 4.2 SELECT 就像是你的购物清单总框架,决定了你要从哪个货架取(FROM)、取哪些属性的商品(SELECT)、只要哪一部分(WHERE)。
- 4.3 单表查询 则是最基础的快速导购。你可以“无脑全买”(无条件),也可以“只要单价5元到10元的”(BETWEEN),最后结账时,
WITH ROLLUP就像是收银条最后的“各类商品小计”和“全场总计”。
根据提供的资料(the sources),我为你提取并整理了第五讲:MySQL数据操纵语句——复杂查询中5.1至5.3节的所有核心内容。
第五讲:MySQL 复杂查询 (5.1 - 5.3)
当一条查询语句涉及到多个表或需要多层筛选时,称为复杂查询。
5.1 连接查询 (Join Queries)
连接查询是指通过两个表之间的关联字段,将不同表中的元组(行)合并生成一张新表的查询方式。
- 等值与非等值连接:
- 等值连接:使用“=”比较运算符,将两个表中对应属性值相等的元组连接起来。
- 非等值连接:使用其他运算符(如
>、<、BETWEEN等)进行比较连接。 - 注意:当多个表中包含同名属性列时,必须使用表名或别名作为前缀(如
Students.Sno),否则系统会提示歧义(ambiguous)。
- 自然连接 (Natural Join):
- 这是一种特殊的等值连接。
- 它会自动对两个表中所有同名属性列进行等值比较,并自动去掉重复的属性列。
- 自身连接 (Self Join):
- 指同一个表与其自身进行连接。
- 必须在
FROM子句中为该表取两个不同的别名(如Courses A, Courses B)以便区分。
- 多表连接:
- 涉及两个以上表的连接。
- 连接时应尽量控制表的数量,因为多表连接类似于嵌套循环,非常消耗资源且会严重降低性能。
- 外连接 (Outer Join):
- 以某个表为基准,即使另一个表中没有匹配记录,也会保留基准表的所有元组。
- 左外连接 (LEFT JOIN):包含左表所有记录,右表无匹配项处显示为
NULL。 - 右外连接 (RIGHT JOIN):包含右表所有记录,同理左表不匹配处补
NULL。
5.2 嵌套查询 (Nested Queries)
嵌套查询是指将一个查询块(子查询)嵌入到另一个查询块的 WHERE 子句或 FROM 子句中。
- 核心逻辑:将一个完整的查询结果作为临时表或过滤条件来使用。
- 常用运算符:
IN/NOT IN:判断值是否在子查询结果集中。- 比较运算符:
=、<>、>=、<=。 - 量化谓词:
ANY(任意一个)、ALL(所有)。 - 存在性判定:
EXISTS/NOT EXISTS。
- 示例应用:例如查询选修了全部课程的学生,需要通过多层嵌套来实现。
5.3 集合查询 (Set Queries)
集合查询是将多个 SELECT 语句的结果集进行逻辑运算。
- 并操作 (UNION):
- 将多个查询结果合并,并自动去除重复元组。
- 要求:参加操作的各个结果表必须具有相同的列数,且对应列的数据类型必须相同。
- MySQL 的限制:
- MySQL 不支持直接的交操作(
INTERSECT)和差操作(EXCEPT)。 - 这些操作通常需要通过带
IN或EXISTS的条件查询来变相实现。
- MySQL 不支持直接的交操作(
💡 形象化比喻:
- 连接查询 就像是在举办一场联谊派对。等值连接是只有拿相同编号门票的人才能组队;外连接则是即使有人没找到伴侣,也允许他独自留在舞池里,只是他的舞伴位置是“空”的。
- 嵌套查询 就像是套娃或剥洋葱。你需要先通过里面的小洋葱(子查询)拿到一个名单,然后再把这个名单交给外面的一层去处理。
- 集合查询 就像是合并两个班级的通讯录。
UNION就是把两份表格拼在一起,如果王五在两份名单上都有,合并后也只会出现一次,确保名单整洁。
希望这些整理能帮助你高效复习!🚩
根据您提供的来源(the sources),我为您提取并整理了第六讲:MySQL 数据操纵语句——更新语句(涵盖 6.1 至 6.3 节)的完整核心内容:
6.1 插入数据 (INSERT)
插入数据主要有两种方式:插入元组和插入子查询结果。
1. 插入元组
- 命令格式:
INSERT INTO <表名> [(<属性列1>[, ...n])] VALUES (<常量1> [, ...n]);。 - 功能:将新元组插入指定表中。
- INTO 子句规则:
- 可以指定属性列顺序,该顺序不一定与表定义一致。
- 省略属性列:表示插入完整元组,值的顺序必须与表定义完全一致。
- 指定部分列:未指定的列将自动取空值(NULL)。注意:若该列定义为
NOT NULL且无默认值,系统会报错。
- VALUES 子句规则:提供的值必须在个数和数据类型上与 INTO 子句中的属性列匹配。
- 示例:
- 同时插入多个学生元组:
INSERT INTO Students VALUES ('ID1', '姓名1', ...), ('ID2', '姓名2', ...);。 - 向选课表插入特定信息:
INSERT INTO Reports (Racademicyear, Rterm, Cno, Sno) VALUES (2017, 1, '042p0123', '2017115102');。
- 同时插入多个学生元组:
2. 插入子查询结果
- 命令格式:
INSERT INTO <表名> [(<属性列1>[, ...n])] SELECT 子查询语句;。 - 注意:子查询的目标列必须与 INTO 子句的属性列个数相同,且数据类型兼容。
- 案例:统计每个班级的人数并存入新表
StuNum中。
6.2 修改数据 (UPDATE)
- 命令格式:
UPDATE <表名> SET <列名1>=<表达式1>[, ...n] [WHERE <条件>];。 - 功能:修改满足
WHERE子句条件的元组。如果省略WHERE,则修改表中所有元组。
四种修改方式:
- 修改单个元组:例如修改特定学号学生的出生日期。
- 修改多个元组:例如为 1980 年前出生的讲师统一增加津贴。
- 带子查询的修改:
- 示例:将讲授特定课程(如“计算机网络”)的教授工资上调 10%。
- 带子关系的修改(成批修改):
- 原理:将两个关系连接,利用其中一个关系的值更新另一个关系的属性。
- 格式:
UPDATE <表1>, <子关系/表2> SET <表1.列>=<子关系.值> WHERE <连接条件> AND <选择条件>;。 - 案例:将每个学生获得的总学分从统计结果批量更新到
StuInfo表中。
6.3 删除数据 (DELETE)
- 命令格式:
DELETE FROM <表名> [WHERE <条件>];。 - 功能:删除满足条件的元组。若省略
WHERE,则清空表内所有记录,但表的结构定义(模式)依然保留在数据库中。
三种删除方式:
- 删除某一个元组:例如删除编号为
T002的教师。 - 删除多个元组:例如删除某个特定班级(如
20141151)的所有学生。 - 带子查询的删除:
- 示例:从选课表中删除所有属于某个班级名称的选课记录。
- 示例:删除某位教师所授特定课程名称的所有授课记录。
特别提示:
- 清空表:除了
DELETE,还可以使用TRUNCATE TABLE <表名>;快速删除所有记录。 - 安全注意:在 MySQL 中,如果表与其他表有外键关联,直接删除可能会受限。执行删除操作时需格外小心。
💡 形象化比喻:
如果把数据库表比作一个班级名册:
- INSERT:就像是给班级增加了几个转校生,把他们的名字和信息填在名册的新行里。
- UPDATE:就像是发现某个同学改名了或考了高分,你拿着橡皮擦掉旧信息,改写成新的。
- DELETE:就像是有同学退学了,你直接把名册上对应的那一行涂掉。如果你没写具体名字(WHERE)就执行删除,就像是把整页名册都擦干净了,只剩下一个空表格。
根据你提供的教学资料,我为你提取并整理了第七章:关系数据模型(涵盖7.1至7.4节)的全部核心内容。
7.1 关系数据结构 (Relational Data Structure)
- 基本概念:关系数据模型建立在严格的数学理论基础上,其核心数据结构是关系(即二维表)。
- 域 (Domain):是一组具有相同数据类型的值的集合(如整数、实数、指定长度的字符串等)。
- 笛卡尔积 (Cartesian Product):给定一组域,$D_1, D_2, \dots, D_n$ 的笛卡尔积是这些域中所有分量可能组合形成的元组集合。其包含的元素个数称为基数,计算公式为各域元素个数的乘积。
- 关系 (Relation):是笛卡尔积的有限子集,用于表示现实世界的实体及其实体间的联系。
- 关系的性质:
- 每一列(属性)中的值必须来自同一个域,且列名必须唯一。
- 元组中的每个分量必须是不可分的数据项(满足第一范式)。
- 关系中不允许有重复的元组,且行与列的次序无关紧要。
- 关系模式 (Relational Schema):是对关系的结构性描述(型),包括关系名、属性名、域类型等,通常是相对固定的;而“关系”是元组的集合(值),随时间动态变化。
- 键 (Key):包括候选键(能唯一标识元组的最小属性组)、主键(选定的一个候选键)和外键(在当前关系中不是主键,但对应另一个关系的主键)。
7.2 关系模型的完整性约束 (Integrity Constraints)
- 实体完整性 (Entity Integrity):规定关系中的主键属性对应的分量不能取空值 (NULL),以保证每个元组的可区分性。
- 参照完整性 (Referential Integrity):定义了关系之间的联系。若属性 A 是关系 R 的外键且对应关系 S 的主键,则 A 的值必须为 S 中已存在的主键值或取空值。
- 在实现参照完整性时,需考虑插入、删除和修改时的策略,如受限 (Restrict)、级联 (Cascade) 或置空值 (Nullify)。
- 用户定义完整性 (User-defined Integrity):也称域完整性,是针对具体应用环境定义的语义约束,如限制属性的取值范围(如年龄必须为正整数)。
7.3 关系代数 (Relational Algebra)
- 基本定义:关系代数是一种抽象的查询语言,它利用代数运算来表达关系的查询要求,其操作的对象和结果都是关系。
- 传统的集合运算:
- 包括并 ($\cup$)、交 ($\cap$)、差 ($-$) 和笛卡尔积 ($\times$)。
- 进行并、交、差运算的两个关系必须是相容的(即具有相同的度,且对应属性来自相同的域)。
- 专门的关系运算:
- 选择 ($\sigma$):根据条件在关系中进行水平方向的行过滤。
- 投影 ($\pi$):在关系中进行垂直方向的列选取,并自动消除重复行。
- 连接 ($\bowtie$):从两个关系的笛卡尔积中选取满足条件的元组,包括等值连接和自然连接。
- 自然连接 (Natural Join):特殊的等值连接,要求比较属性组同名,并去掉结果中的重复属性列。
- 除法 ($\div$):是笛卡尔积的逆运算,通常用于处理包含“全部”或“所有”语义的查询。
- 象集 (Image Set):在除法运算中,给定关系 $R(X, Z)$,当属性组 $X$ 取某个值 $x$ 时,对应的 $Z$ 中所有分量的集合称为 $x$ 在 $R$ 中的象集。
7.4 查询优化 (Query Optimization)
- 重要性:SQL 是高度非过程化的语言,同一查询需求可有多种执行策略,查询优化的好坏直接影响系统的性能。
- 一般策略:
- 选择运算应尽早执行,这是优化策略中最基本的一条。
- 将投影运算和选择运算合并进行,或与前后的双目运算(如连接)结合,减少扫描次数。
- 把笛卡尔积与其后的选择运算合并为连接运算。
- 执行步骤:首先将查询要求转换成内部表示(如语法树),然后转换为优化形式,选择底层存取路径,最后生成并选择代价最小的执行计划。
- 语法树特征:叶结点表示关系,非叶结点表示操作(如 $\sigma, \pi, \times$)。
💡 形象化比喻:关系操作与查询优化
如果把数据库比作一个巨大的仓库,关系代数就是你手中的分拣指令。
- 选择 ($\sigma$) 就像是告诉机器人:“只要红色的箱子”(按行筛选)。
- 投影 ($\pi$) 就像是说:“不管箱子颜色,我只要箱子上的标签信息”(按列筛选)。
- 查询优化 就像是一个资深管家。如果你先让机器人把所有箱子搬出来再筛选红色(先笛卡尔积再选择),管家会纠正你:“应该先在货架上找出红色的箱子再搬出来”(选择运算尽早执行),这样能节省大量的体力和时间。
根据您提供的来源资料(the sources),我为您提取并整理了第九讲“关系模式的规范化设计理论”中9.1至9.5节的完整内容:
9.1 问题的提出:为什么要进行规范化?
在数据库设计中,如果简单地将所有属性放在一个关系模式中,往往会导致一系列异常问题。
- 异常表现:
- 冗余过多:如学生姓名、课程名等信息在多个元组中重复出现,浪费存储空间。
- 插入异常:如果一个新学生尚未选课,其基本信息可能因缺少主键(如课程号)而无法存入表中。
- 更新异常:修改某一属性(如教师任课变动)时,必须修改所有相关记录,否则会导致数据不一致。
- 删除异常:删除某个选课记录可能导致该课程或学生的基础信息也被一并抹除。
- 根本原因:关系的结构中属性之间存在过多的“数据依赖”。
- 解决方法:对关系模式进行分解,分析并掌握属性间的语义关联,从而得到合理的设计方案。
9.2 关系模式的函数依赖 (FD)
- 核心定义:设 $R(U)$ 是属性集 $U$ 上的关系模式,$X, Y$ 是 $U$ 的子集。若对于任一具体关系 $r$,只要任意两个元组在 $X$ 上的值相等,它们在 $Y$ 上的值也必然相等,则称“$X$ 函数确定 $Y$”或“$Y$ 函数依赖于 $X$”,记作 $X \to Y$。
- 决定因素:在 $X \to Y$ 中,称 $X$ 为该函数依赖的决定因素。
- 本质:函数依赖是一个语义范畴的概念,体现了现实世界属性间的内在联系和性质。
9.3 关系模式的规范化 (1NF - BCNF)
规范化是将低一级范式的关系模式通过分解转换为高一级范式的集合的过程。
- 第一范式 (1NF):要求关系模式的所有属性都是不可再分的基本数据项。这是关系数据库最基本的要求。
- 第二范式 (2NF):满足 1NF,且每一个非主属性都完全函数依赖于每个候选键。其目的是消除非主属性对候选键的部分依赖。
- 第三范式 (3NF):满足 2NF,且每一个非主属性都不传递依赖于候选键。其目的是消除非主属性的传递依赖。
- BC范式 (BCNF):是修正的 3NF。要求对于每一个非平凡函数依赖,其决定因素必须包含候选键。在 BCNF 中,所有属性(包括主属性)都不能对候选键有部分依赖或传递依赖。
- 多值依赖 (MVD):$X \to\to Y$ 表示 $Y$ 的一组值仅由 $X$ 决定,而与关系中的其他属性 $Z$ 无关。这是通往更高范式(如 4NF)的考量点。
9.4 函数依赖的推理规则 (Armstrong 公理)
用于从已知的函数依赖集 $F$ 推导出被逻辑蕴涵的其他函数依赖。
- 逻辑蕴涵:如果关系模式满足 $F$,同时也必然满足 $X \to Y$,则称 $F$ 逻辑蕴涵 $X \to Y$。
- 闭包 ($F^+$):被 $F$ 逻辑蕴涵的所有函数依赖构成的集合。
- Armstrong 公理系统:
- 自反律:若 $Y \subseteq X \subseteq U$,则 $X \to Y$。
- 增广律:若 $X \to Y$,则 $XZ \to YZ$。
- 传递律:若 $X \to Y$ 且 $Y \to Z$,则 $X \to Z$。
9.5 关系模式的分解特性
模式分解的关键在于实现“等价分解”。
- 评判标准:
- 无损连接性 (Lossless Join):分解后的关系通过自然连接能够完全恢复原状,不丢失也不产生多余数据。
- 保持函数依赖 (Dependency Preservation):分解后各个模式所满足的函数依赖之并集等价于原有的函数依赖集。
- 重要事实:
- 分解总可以达到 3NF 且同时满足无损连接和保持函数依赖。
- 分解达到 BCNF 时一定可以保证无损连接,但不一定能保持函数依赖。
- 设计原则:好的分解应具备表达性(等价)、分离性(概念单一)和小冗余性。
💡 形象化总结(比喻):
规范化过程就像是整理衣柜。
- 1NF 是保证每件衣服都是独立的(不是一坨粘在一起的)。
- 2NF 就像是给每件衣服贴标签,确保标签上的“洗涤说明”(非主属性)只和“衣服种类”(候选键)有关,而不是跟“挂钩颜色”挂钩(消除部分依赖)。
- 3NF 则是确保标签上的信息是直接的,比如直接写“棉质”,而不是写“产自A厂→A厂只做棉织品”(消除传递依赖)。
- 分解特性 则像是在把衣服分到不同抽屉后,当你需要搭配时,你依然能把原来那套衣服原封不动地找回来(无损连接),且原来关于衣服的搭配禁忌依然生效(保持依赖)。
根据您提供的资料,我为您提取并整理了第十讲:数据库的安全与保护(10.0-10.4节)的完整核心内容:
10.0 数据库的安全与保护概述
- 数据破坏的主要原因:包括自然灾害(火灾、地震)、人为恶意破坏(病毒、篡改)、更新操作误操作(程序错误)、并发操作引起的不一致性,以及软硬件故障。
- DBMS的核心保护功能:
- 安全性 (Security):防止非法用户非法使用,避免泄露或篡改。
- 完整性 (Integrity):保证数据的正确性和一致性。
- 并发控制 (Concurrency Control):保证多用户共享时维护数据一致性。
- 数据库恢复 (Recovery):在系统失效后利用备份恢复数据。
10.1 数据库的安全性保护
- 主要措施:用户鉴别、存取权限控制、视图机制、跟踪审查(审计)和数据加密存储。
- 用户鉴别:DBMS提供的最外层保护。MySQL作为多用户系统,通过 root用户(超级管理员)和普通用户进行分类管理。
- 存取权限控制:
- 权限级别:分为用户权限(全局)、数据库权限、表权限和列权限。
- 授权粒度:粒度越细,安全性越完善,但系统开销也越大。
- 核心权限表:MySQL通过
mysql.user(用户层)、db(数据库层)、tables_priv(表层)、columns_priv(字段层)等系统表进行控制。
- 视图机制:视图是物理上不存在的虚拟表。通过视图可以限制用户只能访问局部数据,从而简化视图并保证安全性。
- 跟踪审查 (审计):一种事后监视措施,MySQL支持错误日志、二进制日志(记录操作但不记录查询)、通用查询日志和慢查询日志。
10.2 数据库的完整性保护
- 安全性 vs 完整性:安全性防范的是“非法用户”;完整性防范的是“不合语义的数据”(由合法用户引起)。
- 完整性约束分类:
- 按执行时机:立即执行(语句结束即检查)和延迟执行(事务提交前检查)。
- 按控制方法:实体完整性(主键)、参照完整性(外键)和用户定义完整性。
- 参照完整性处理策略:当删除或修改被参照表数据时,可采取级联 (Cascades)、受限 (Restricted) 或 置空值 (Nullifies) 策略。
- 触发器 (Triggers):一种特殊的存储过程,在执行增、删、改操作时自动触发,比普通约束更灵活。
10.3 数据库的并发控制技术
- 事务 (Transaction):并发控制的基本单位,具有 ACID特性(原子性、一致性、隔离性、持续性)。
- 并发控制不当的问题:
- 丢失修改(写-写冲突)。
- 脏读(读-写冲突,读取了回滚前的临时数据)。
- 不能重读。
- 幻读(由于其他事务插入数据导致结果集不一致)。
- 并发控制方法:
- 封锁技术:包括表级锁和行级锁(共享锁S和排他锁X)。
- 隔离级别:序列化 (Serializable)、可重复读 (Repeatable Read,MySQL默认)、提交读、未提交读。
- 死锁处理:采用预防法(如一次封锁法)或解除法。
10.4 数据库的恢复技术
- 故障种类:事务故障(运行中断)、系统故障(非正常终止)、介质故障(磁盘损坏)和病毒破坏。
- 恢复基本原理:增加数据冗余。
- 建立冗余的技术:
- 数据转储:定期复制数据库副本。分为静态/动态转储、海量/增量转储。
- 日志文件:记录每一次更新操作。登记原则是必须先写日志,后写数据库。
- 恢复策略:
- 事务/系统故障:通过日志执行 撤销 (UNDO) 或 重做 (REDO)。
- 介质故障:装入后备副本并重做日志中的事务。
- 检查点机制:在日志中记录特殊标记,以最大限度提高恢复效率。
💡 形象化比喻:
如果把数据库比作一个大型金库:
- 安全性保护 是门外的保安和指纹锁,确保只有拿着钥匙的人(合法用户)能进门。
- 完整性保护 是金库里的质检员,防止有人往钱堆里塞假钞或白纸(不合语义的数据)。
- 并发控制 是一套存取流程,防止两个搬运工同时抢一个箱子,导致箱子损坏或记账错误(数据不一致)。
- 数据库恢复 则是金库的备份系统,即便金库被火烧了,我们还能根据“监控录像”(日志文件)和“分库备份”(数据转储)把所有的钱和账目重新还原回来。
根据您提供的来源(the sources),尤其是“总复习(理论).pdf”及各章节的课件内容,我为您提取并整理了数据库系统原理总复习(理论篇)的完整核心内容:
一、 数据库系统概述 (第1讲)
- 基本概念:
- 数据描述:包括数据、数据项、记录型(型)和数据记录(值)。
- 信息关系:数据是载体,信息是内涵,信息具有客观性、价值性、无限性等特性。
- 系统构成:由数据库(DB)、数据库管理系统(DBMS)、应用程序和数据库管理员(DBA)组成。
- DBMS 核心功能:包括数据定义(DDL)、数据操纵(DML)、数据控制(DCL)和数据库维护。
- 三级模式结构:
- 内模式:描述物理结构和存储方式。
- 模式(逻辑模式):描述全体数据的逻辑结构,是所有用户的公共视图。
- 外模式(用户模式):描述局部数据的逻辑结构,保证安全性和简化视图。
- 二级映像与独立性:通过外模式/模式映像实现逻辑独立性;通过模式/内模式映像实现物理独立性。
二、 数据模型与关系模型 (第2 & 7讲)
- 模型三要素:数据结构、数据操作、完整性约束。
- 概念模型 (E-R模型):
- 核心元素:实体、属性、联系(1:1、1:n、m:n)。
- 转换规则:实体型转为关系模式;联系根据类型并入主键或生成新模式。
- 关系代数运算:
- 集合运算:并 ($\cup$)、交 ($\cap$)、差 ($-$)。
- 专门运算:选择 ($\sigma$)、投影 ($\pi$)、连接 ($\bowtie$)、除法 ($\div$)。
- 完整性约束:
- 实体完整性:主键不能为空。
- 参照完整性:外键必须是已存在的主键值或为空。
- 用户定义完整性:针对具体数据的语义要求。
三、 SQL 数据语言 (第3-6讲)
- 数据定义 (DDL):使用
CREATE、ALTER、DROP操作数据库、表和索引。- 存储引擎:MySQL 常用 InnoDB(支持事务、外键)和 MyISAM。
- 数据操纵 (DML):
- 单表查询:
SELECT-FROM-WHERE结构,支持ORDER BY(排序)、GROUP BY(分组)、HAVING(分组条件)。 - 复杂查询:包含连接查询(内/外连接、自身连接)、嵌套查询(子查询)和集合查询(UNION)。
- 更新数据:
INSERT(插入)、UPDATE(修改)、DELETE(删除)。
- 单表查询:
四、 规范化设计理论 (第9讲)
- 异常问题:非规范化模式会导致冗余度大、插入异常、删除异常和更新异常。
- 函数依赖 (FD):
- 类型:完全函数依赖、部分函数依赖、传递函数依赖。
- 推理规则(Armstrong公理):自反律、增广律、传递律。
- 范式级别:
- 1NF:属性不可再分。
- 2NF:满足1NF且消除非主属性对候选键的部分依赖。
- 3NF:满足2NF且消除非主属性对候选键的传递依赖。
- BCNF:满足3NF且消除主属性对候选键的部分/传递依赖。
五、 数据库的设计、安全与保护 (第8 & 10讲)
- 设计步骤:规划、需求分析、概念设计、逻辑设计、物理设计、实施、运行维护。
- 安全性:鉴别用户、权限控制(
GRANT/REVOKE)、视图机制、审计 [10.1, 69]。 - 并发控制:
- 事务 (Transaction):基本单位,具备 ACID 特性。
- 封锁技术:排他锁 (X锁) 和共享锁 (S锁),用于解决丢失修改、脏读等问题。
- 数据库恢复:
- 原理:数据冗余(转储和日志文件)。
- 策略:登记原则是先写日志后写数据库;利用日志进行
UNDO(撤销)和REDO(重做)。
💡 形象总结:
学习数据库理论就像是在建设一座大型现代化图书馆:
- 第一讲是图书馆的建筑框架(三级模式),确保不论书架怎么挪(物理独立),读者查书的索引(逻辑独立)不变。
- 第二/七讲是编目规则(数据模型),决定是用“作者-书名”还是“类别”来整理书籍。
- 第九讲是排架优化(规范化),防止同一个作者的信息散落在十个地方(减少冗余),避免撕掉一张借书证就弄丢了整本书的信息(消除异常)。
- 第十讲则是安保与备份系统,保安(安全性)拦住小偷,监控(日志)记录借阅,而防火喷淋和异地备份(数据恢复)则保证了即便发生火灾,图书馆也能重新开张。
