数据库基础
概念设计、逻辑设计、物理设计
概念设计
- 概念设计是数据库设计的核心环节。通过对用户需求进行综合、归纳与抽象
数据库概念设计的目标
定义和描述应用领域设计的数据范围
①获取信息模型
②描述数据的属性特征
③描述数据之间的关系
④定义和描述数据的约束
⑤说明数据的安全性要求
⑥支持用户的各种数据处理需求
⑦保证信息模型能转化成数据库的逻辑结构（即数据库模式）
逻辑设计
主要工作是将现实世界的概念数据模型设计成数据库的一种逻辑模式，即适应于某种特定数据库管理系统所支持的逻辑数据模式。与此同时，可能还需为各种数据处理应用领域产生相应的逻辑子模式。这一步设计的结果就是所谓“逻辑数据库”
物理设计
根据特定数据库管理系统所提供的多种存储结构和存取方法等依赖于具体计算机结构的各项物理设计措施，对具体的应用任务选定最合适的物理存储结构(包括文件类型、索引结构和数据的存放次序与位逻辑等)、存取方法和存取路径等。这一步设计的结果就是所谓“物理数据库”。
数据库相关概念
表
- 表是数据的矩阵，表头展示所有列的名称（字段）
行
- 一行（记录）是一组相关的数据
列
- 一列（数据）包含了相同类型的数据
主键
- 主键用来区分、查询、排序数据
- 唯一标识
- 可以对整个表进行索引
外键
- 关联两个表
- 1对多/多对多
数据库设计
需求分析 -> 逻辑设计 -> 数据库创建 -> 维护与优化
需求分析
在需求分析阶段，我们需要梳理系统的业务需求，明确需要存储哪些数据以及这些数据之间的关系。这个阶段需要深入了解业务需求，并对其中的概念和业务流程做出详细的定义和解释
逻辑设计
在逻辑设计阶段，我们需要根据需求分析的结果来设计数据库的逻辑结构。这个阶段需要创建数据实体和它们之间的关系，定义实体之间的约束和操作。常用的逻辑设计工具包括ER图、UML等。
数据库创建
选定好数据库类型之后，需要根据数据库的逻辑设计来建立数据表、视图、索引等数据结构。在数据库建立之后，需要进行数据初始化，包括导入初始化数据、创建触发器和存储过程等
维护与优化
在数据库运行之后，需要对其进行维护与优化。维护的内容包括数据备份与恢复、数据安全与权限控制、数据库性能监测等。优化的内容包括索引的建立、查询语句的优化、数据库的调优等
数据库设计三大范式
一、第一范式
1NF是对属性的原子性，要求属性具有原子性，不可再分解；
表：字段1、 字段2(字段2.1、字段2.2)、字段3 ......
如老师（院系、高级职称人数），如果认为最后一列还可以再分成（教授、副教授），它就不是一范式了，否则就是；
转化第一范式很简单，扁平化即可：
二、第二范式
2NF是对记录的唯一性，要求记录有唯一标识，即实体的唯一性，即不存在部分依赖；
表：职工号，姓名，职称，项目号，项目名称；
这个表明显说明了两个逻辑关系：职工信息，项目信息；由于非主键字段必须依赖主键，这里职工号->姓名，职工号->职称，而项目号->项目名称有依赖关系，所以不符合二范式。
可能会存在问题：
数据冗余:，每条记录都含有相同信息；删除异常：删除所有学生成绩，就把课程信息全删除了；插入异常：学生未选课，无法记录进数据库；更新异常：调整课程学分，所有行都调整。
正确做法:
常用的解决办法是差分表格，比如拆分为：
- 职工信息表（职工ID、职称ID...），或加入职称表（职称表ID、职称、职称等级等）
- 项目信息表（项目ID、职工ID、项目信息...）
三、第三范式
如果一个关系属于第二范式，并且在两个(或多个)非主键属性之间不存在函数依赖。非主键属性之间的函数依赖也称为传递依赖，那么这个关系属于第三范式。
3NF是对字段的冗余性，要求任何字段不能由其他字段派生出来，它要求字段没有冗余，即不存在传递依赖；
表: Student表（学号，姓名，年龄，性别，所在院校，院校地址，院校电话）
**注意：**上表属于第二范式，因为主键由单个属性组成（学号）
因为存在依赖传递: (学号) → (学生)→(所在学院) → (学院电话) 。
可能会存在问题：
数据冗余:有重复值；更新异常：有重复的冗余信息，修改时需要同时修改多条记录，否则会出现数据不一致的情况 。
正确做法：
学生：(学号， 姓名， 年龄， 所在学院)；
学院：(学院，学院名称， 电话)。
四、反范式化
一般说来，数据库只需满足第三范式（3NF）就行了。
没有冗余的数据库设计可以做到。但是，没有冗余的数据库未必是最好的数据库，有时为了提高运行效率，就必须降低范式标准，适当保留冗余数据。具体做法是：在概念数据模型设计时遵守第三范式，降低范式标准的工作放到物理数据模型设计时考虑。降低范式就是增加字段，允许冗余，达到以空间换时间的目的。
例：如订单表，“金额”这个字段的存在，表明该表的设计不满足第三范式，因为“金额”可以由“单价”乘以“数量”得到，说明“金额”是冗余字段。但是，增加“金额”这个冗余字段，可以提高查询统计的速度，这就是以空间换时间的作法。
在Rose 2002中，规定列有两种类型：数据列和计算列。“金额”这样的列被称为“计算列”，而“单价”和“数量”这样的列被称为“数据列”。
五、范式化设计和反范式化设计的优缺点
5.1 范式化
优点：
- 可以尽量减少数据冗余
- 数据表更新快体积小
- 范式化的更新操作比反范式化更快
- 范式化的表通常比反范式化更小
缺点：
- 查询需要对多个表进行关联，可能导致性能降低
- 更难进行索引优化
5.2 反范式化
优点：
- 减少表的关联
- 可以更好的进行索引优化
缺点：
- 存在数据冗余及数据维护异常
- 对数据的修改需要更多成本（语句、查询、删除、验证等）
参考资料
1、通俗地理解数据库三个范式
2、数据库模型设计，第一范式、第二范式、第三范式简单例子理解
3、数据库三大范式最简单的解释
多对多，一对多，多对一场景
多对多
多对多关系描述了两个实体类之间相互对应的关系，这种模型是一种复杂的关系模型。
举个例子，一个学生可以选择多个课程，而一个课程也可以被多个学生选择。这种多对多的关系需要使用中间表来描述课程和学生之间的关系
一对多
一对多关系描述了一个实体对多个实体的关系
举个例子：
- 一家公司可以拥有多个员工，而一个员工只能属于一家公司
- 一篇文章可以有多个评论，但一个评论只能属于一篇文章。
多对一
多对一的关系描述了多个实体对一个实体的关系。
举个例子：
- 一篇文章被多个评论引用，而一个评论只能引用一篇文章。
ER图
关键字/语法
JOIN...ON
JOIN ... ON 是一种 SQL 语法，用于在查询中将多个表进行联接（关联）操作并使用 ON 子句指定联接条件。
ON关键字用于指定在两个表之间进行关联时所使用的条件
SELECT *
FROM orders
JOIN users
ON orders.user_id = users.id;
关联查询/联合查询/多表查询
关联查询是指在 SQL 查询语句中，通过一定的关联条件，将多张表的信息连接起来从而查询出需要的数据。而关联连接则是关联查询的一种方式，通过 join 操作实现表之间的关联。
在 SQL 中，常见的关联连接有左连接、右连接和内连接三种方式
- 左连接（Left Join）: 在左表中，查询时会返回左表的所有记录，不管右表中是否存在匹配记录，对于右表中未匹配的记录将会以 NULL 值填充。
- 右连接（Right Join）：与左连接相反，在右表中，查询时会返回右表的所有记录，不管左表中是否存在匹配记录，对于左表中未匹配的记录将会以 NULL 值填充。
- 内连接（Inner Join）: 仅返回左表和右表之间匹配的记录。
如何区分左表和右表
为了区分左表和右表，我们需要在 SQL 查询语句中指定表的顺序。如果查询语句使用 JOIN 关键字来进行表的关联，那么它的语法通常如下：
SELECT *
FROM table1
JOIN table2
ON table1.id = table2.table1_id;
在这个查询语句中，table1 是左表，而 table2 是右表
FROM关键字后首先出现的表就是左表ON语句指定了左表和右表之间的关联条件
左关联查询
左关联查询（LEFT JOIN）的语法为
SELECT *
FROM table1
LEFT JOIN table2
ON table1.column = table2.column;
其中，table1 为主表，用 LEFT JOIN 关键字连接（左连接）table2 表，ON 子句为连接条件，column 表示连接的条件列
左关联查询（LEFT JOIN）返回主表中所有行，即使在关联表中没有匹配行，也将返回主表中的全部数据
右关联查询
右关联查询（RIGHT JOIN）的语法为
SELECT *
FROM table1
RIGHT JOIN table2
ON table1.column = table2.column;
其中，table1 为主表，用 RIGHT JOIN 关键字连接（右连接）table2 表，ON 子句为连接条件，column 表示连接的条件列
右关联查询（RIGHT JOIN）则返回右表中的所有行，即使在主表中没有匹配行，也将返回右表中的全部数据
内联查询
内联连接查询（INNER JOIN）的语法为
SELECT *
FROM table1
INNER JOIN table2
ON table1.column = table2.column;
内联连接查询（INNER JOIN）则仅返回匹配条件下的所有行，无匹配的行将被舍去。