Hi, this is CPT103 Introduction to Databases Exam Prep Guide.

Alright, let's get straight to the point and dive into the main topic.

说在前面

这里是考前总结（无废话版）下，预计阅读时间在半小时内

由于内容过多，基础知识将写在（上），查询语句将写在（中）中，敬请期待

文中附有英文题目及解析

详细笔记可见 MySQL从入门到入土 | 有道云笔记

本人拙见，如有不当处，还望海涵

参考文章写在文末

Over！祝食用愉快！|ू･ω･` )

绪论

函数（了解）

除了我们前面在聚合函数里学到的函数，还有很多很好用的函数

注意我们不需要记忆，了解有个印象即可

函数：是指一段可以直接被另一程序调用的程序或代码

比如(我们前面做到的题)：

1、如何快速计算出入职天数（datediff）

2、这样根据表格中的分数值，快速判定学生分数等级（case when)

通过内置函数

聚合函数

首先回顾下聚合函数

字符型函数

1、HelloMySQL

2、hello

3、HELLO

4、-1-1-01

5、02oi

数值函数

2/1/2/3/0~10/3.24

rand类似Java中可改变随机范围如：10*rand()-5 >> 5~-5

日期函数

流程函数（三元运算符）

注意一个if就行：条件，正确，错误

比如：

select name, if(workaddress = '北京' or workaddress = '上海', '一线城市', '二线城市') '工作地址' from emp;

约束

即各个字段的属性

约束是作用于表中字段上的，可以再创建/修改表的时候添加

实例

primary key：一个表只有一个，非空且唯一

not null：不允许为空值

unique：唯一值，不能重复

auto_increment：自动增长（创建数据时生成，不用手动添加）

外键

外键约束

如果想让两张表之间数据相互有联系

而现在他们只是逻辑上的关联关系，在数据库层面没有关联关系

生成外键语句要背，外键名一般为fk_子表_父表_关联字段(了解)

注：外键必须有子表的关联键指向父表的主键（子表一般为多字段的）

类似于java的继承，子表有些属性不用写开，而是用父亲的

删除外键

注：如果外键和其他表产生了依赖关系，需要先解除依赖关系，才能删除外键

先删儿子再删爸爸

EX1

现在，让我们根据给定的外键约束分析每个选项：

1. constraint fk_a_b foreign key (a2) references b (b1);
   这表示表 a 有一个外键 a2 引用表 b 的 b1 列。
2. constraint fk_b_c foreign key (b2) references c (c1);
   这表示表 b 有一个外键 b2 引用表 c 的 c1 列。

根据理论先删儿子再删爸爸：

• 我们不能先删除表 c，因为表 b 引用它。
• 我们不能先删除表 b，因为表 a 引用它。
• 要成功删除所有表，我们需要先删除 a，然后删除 b，最后删除 c。

所以ace

e set foreign_key_checks = 0; drop table c; - 这个选项禁用了外键检查，因此可以成功删除表 c。(似乎没学，记一下吧)

多表查询

一对多

最合理的

一对多，两张表，多的表，加外键（一个爸爸多个孩子）

多对多

通过关联表组成关系链（关联表主键没实际含义，顶多算这条记录的id）

多对多，三张表，关系表，加外键

这里是满足3NF的改法

一对一

分表降低开发速度，但提高开发质量

一对一，两张表，从的表，加外键

规范性

为了做高效的表，我们提供了很多规范

在数据库设计中，规范化（Normalization）是一个重要的过程，它用于消除数据冗余和更新异常。规范化通常通过一系列步骤或“范式”（Normal Forms）来实现，其中3NF（第三范式）和BCNF（Boyce-Codd Normal Form，也称为巴斯-科德范式）是其中的两个重要范式。

1NF

第一范式（1NF）是关系模式规范化的最低要求，它确保关系中的每个域都是原子的，即不可再分。一个关系如果满足1NF，则必须满足以下条件：

• 关系中的每个属性都是原子的，即属性的值是不可再分的。
• 关系中没有重复的属性组。

也就是一个字段只能有一个信息

这里后两行都包含了两个数据

2NF

第二范式（2NF）建立在1NF的基础上，它进一步要求关系中的每个非主属性完全依赖于整个主键，而不是主键的一部分。一个关系如果满足2NF，则必须满足以下条件：

• 关系满足1NF。
• 关系中的每个非主属性完全依赖于整个主键，而不是主键的一部分。

换句话说，2NF要求消除部分函数依赖。部分函数依赖是指一个非主属性依赖于主键的一部分，而不是整个主键。（针对联合主键）

同一个订单中可能包含不同的产品，因此主键必须是**“订单号”和“产品号”联合组成**，但可以发现，产品数量、产品折扣、产品价格与“订单号”和“产品号”都相关，但是订单金额和订单时间仅与“订单号”相关，与“产品号”无关

所以需要分成两个表

注：这里两个新表都没有主键

3NF

第三范式（3NF）是建立在第二范式（2NF）的基础上的，它要求一个关系满足以下条件：

1. 满足2NF：关系必须满足第二范式，即每个非主属性完全依赖于整个主键。
2. 没有传递依赖：非主属性之间不能有传递依赖关系。也就是说，非主属性不能依赖于主键的一部分（即非主属性不能依赖于主键的某个子集）。

每一列数据都和主键直接相关

这里主键是学号，那么就只能是学生个人信息，而老师信息不是直接关联的

BCNF（巴斯-科德范式）

巴斯-科德范式（BCNF）是一个比3NF更严格的范式。一个关系如果满足BCNF，则必须满足以下条件：

1. 所有决定因素都是候选键：对于关系中的每一个非主属性A，如果A依赖于关系中的某个属性集B，则B必须是该关系的候选键。这里，“决定因素”是指一组能够确定关系中某个属性的值的属性集合。
2. 没有部分函数依赖：与3NF不同，BCNF不仅要求非主属性不依赖于主键的一部分，而且要求主键中的每个属性都不能被主键中的其他属性子集所决定。

假设我们有一个关系模式EmployeeDepartment，用于存储员工和他们的部门信息。原始的表格可能如下所示：

员工ID	员工姓名	部门ID	部门名称	部门经理ID	部门经理姓名
1	张三	1	销售部	101	李四
2	王五	1	销售部	101	李四
3	赵六	2	人事部	102	王七
4	钱八	3	财务部	103	陈九

在这个例子中，我们可以发现数据冗余（如销售部的部门经理姓名多次出现）以及可能的更新、插入和删除异常。为了使其满足BCNF，我们需要进行规范化。

首先，我们确定候选键。在此例中，员工ID和(部门ID, 部门经理ID)都可以作为候选键，因为每个员工都是唯一的，且每个部门和部门经理的组合也是唯一的。

接下来，我们根据BCNF的定义进行规范化。BCNF要求所有非主属性对每一个候选键都是完全函数依赖，并且没有任何属性完全函数依赖于非候选键的任何一组属性。

因此，我们可以将原始表格分解为以下三个表格：

表格1：员工信息

员工ID	员工姓名	部门ID
1	张三	1
2	王五	1
3	赵六	2
4	钱八	3

表格2：部门信息

部门ID	部门名称	部门经理ID
1	销售部	101
2	人事部	102
3	财务部	103

表格3：部门经理信息

部门经理ID	部门经理姓名
101	李四
102	王七
103	陈九

现在，每个表格都满足BCNF的要求。每个非主属性都完全依赖于其所在表格的候选键（即主键），并且没有任何属性完全函数依赖于非候选键的任何一组属性。这样的设计减少了数据冗余，并避免了可能的更新、插入和删除异常。

ER图

用外键将表与表连起来，合理表示

事务（了解）

将几个任务绑定在一起，避免中间环节的出错造成整个进程混乱

不考不多提

引用文章

黑马程序员 MySQL数据库入门到精通-哔哩哔哩