查缺补漏点
-
锁协议（一段锁协议、二段锁协议、共享锁、排他锁）
- 一次加锁协议One-Time Locking
- 事务执行期间，一次将所有的锁获取完成，才能继续运行，事务完成后释放；
- 不会产生死锁，事务在整个执行期间持有所需的所有资源的锁，并且不会进行锁的释放或再次获取操作；
- 二段锁协议Two-Phase Locking（增长阶段、收缩阶段）
- 保证事务可串行化；
- 第一阶段（增长阶段）可申请，不可释放；第二阶段（收缩阶段）可释放，不可申请；
- 可能会产生死锁；
- 排他锁（X锁）
- 防止R/W操作；
- 冲突锁；
- 共享锁（R锁）
- 防止W操作，可以R操作；
- 非冲突锁；
- 一次加锁协议One-Time Locking
-
数据库三级封锁协议
-
第一级：事务在读取数据时对其进行共享锁定（Shared Lock），其他事务可以读取同一数据，但不能对其进行修改。
-
第二级：事务在修改数据时对其进行排他锁定（Exclusive Lock），其他事务不能对同一数据进行读取或修改。
-
第三级：事务在提交之前对其所使用的所有数据进行锁定，以确保事务的原子性、一致性和持久性。
-
-
并行事务
- 可串行化不一定遵守二段锁协议；
- 假设在执行过程中发生了断电故障，那么需要根据日志文件来恢复数据库的状态。日志文件记录了每个事务对每个数据对象进行的操作以及操作前后的值。如果一个事务已经提交了（即完成了所有操作），那么就需要重做（REDO）该事务的所有操作以保证数据的一致性；如果一个事务还没有提交（即还有未完成的操作），那么就需要回滚（ROLLBACK）该事务的所有操作以取消数据的修改。
- （事务中一般CHECKPOINT的锚定点不会影响做题的判断，可以视作NOOP。）
-
隔离等级(ISOLATION LEVEL)
级别 解释 脏读 不可重复读 幻读 READ UNCOMMITTED 允许读取未提交的数据 √ √ √ READ COMMITTED 只能读取已经提交的数据 × √ √ REPEATABLE READ 同一事务中多次读取同一数据结果始终相同 × × √ SERIALIZABLE 串行化，不会产生死锁 × × × -
READ UNCOMMITTED：允许读取未提交的数据，可能会出现脏读、不可重复读、幻读等问题。
SET TRANSACTION ISOLATION LEVEL READ UNCOMMITTED; SELECT * FROM table_name; -
READ COMMITTED：只能读取已经提交的数据，可以避免脏读，但可能会出现不可重复读、幻读等问题。
SET TRANSACTION ISOLATION LEVEL READ COMMITTED; SELECT * FROM table_name; -
REPEATABLE READ：保证在同一事务中多次读取同一数据时，结果始终相同，可以避免脏读和不可重复读，但可能会出现幻读。
SET TRANSACTION ISOLATION LEVEL REPEATABLE READ; SELECT * FROM table_name; -
SERIALIZABLE：最高的隔离等级，保证所有事务按顺序执行，可以避免脏读、不可重复读和幻读。
SET TRANSACTION ISOLATION LEVEL SERIALIZABLE; SELECT * FROM table_name;
-
-
关系模式
- 表（Table）
- 主键（Primary Key）
- 外键（Foreign Key）
- 索引（Index）
- 视图（View）
- 约束（Constraint）
-
范式（1NF、2NF、3NF、4NF、BCNF）数据库第一二三范式到底在说什么？ - 知乎 (zhihu.com)
- 第一范式（1NF）：确保每个关系表的每个属性都是原子的，不可再分。即每个属性只有一个值。
- 第二范式（2NF）：确保每个关系表的每个非主属性都完全依赖于主属性。即每个非主属性都与主键有关联。
- 第三范式（3NF）：确保每个关系表的每个非主属性都不传递依赖于主属性。即每个非主属性都只与主键有关联，而不与其他非主属性有关联。
- 巴斯-科德范式（BCNF）：确保每个关系表的每个非主属性都不依赖于其他非主属性。即每个非主属性都只与主键有关联，而不与其他非主属性有关联。
- 第四范式（4NF）：确保每个关系表的每个多值依赖都被分解成单值依赖。即每个非主属性都只与主键有关联，而不与其他非主属性有关联，并且每个非主属性都只有一个值。
- 第五范式（5NF）：确保每个关系表的每个非平凡依赖都是由超键决定的。即每个非主属性都只与主键有关联，而不与其他非主属性有关联，并且每个非主属性都是由主键决定的。
-
开发模型（瀑布、螺旋、净室、V型、原型、增量）
开发模型 定义 优点 缺点 瀑布模型 将软件生命周期划分为制定计划、需求分析、软件设计、程序编写、软件测试和运行维护等六个基本活动，它们自上而下。适用于需求完善定义不易变更的项目。 严格遵循预先计划的步骤顺序进行；为项目提供了按阶段分的检查点；可在迭代模型中应用瀑布模型 难以适应需求变化；难以发现问题；难以评估和控制进度和成本；难以应对复杂性；难以应对风险； 迭代模型 一种与传统的瀑布式开发相反的软件开发过程，整个开发工作被组织为一系列短小的、固定长度的小项目，每次迭代都包括需求分析、设计、实现与测试。开始工作无需完整需求，每次迭代完成系统的一部分功能或业务，再通过客户的反馈来细化需求，并开始新一轮的迭代,适用于需求难以确定不断变更的系统 降低一个增量上的开支风险；降低了产品无法按照进度进入市场的风险；加快整个开发进度；用户的需求不断细化。适应需求能力高，复用性更高 频繁的集成和测试；需要充分设计和计划；需要更多沟通协调；需要更多测试和验证；难以处理需求变更；迭代次数过多 增量模型 结合瀑布和迭代模型的特征，随着日程时间进展而交错的线性序列，每一个线性序列产生软件的一个可发布的“增量”。适用于技术风险较大，用户需求较为稳定的软件系统。 每一个增量的使用和评估都作为下一个增量发布的新特性和功能。 频繁的集成和测试；需要充分设计和计划；需要更多沟通协调；需要更多测试和验证；难以处理需求变更。 （快速）原型模型 在原型的基础上逐渐完成整个系统得开发工作。适用于需求复杂难以确定的项目 更好满足用户需求；更快的反馈和迭代；更高的用户参与度；更低的开发成本； 会导致过度设计、过度重构、过度关注细节（需求蔓延）；导致需求频繁变化；导致用户误解 螺旋模型 适用于大型昂贵项目，首次引入风险分析，旨在无法排除重大风险的时候有机会停止减小损失。兼顾原型的迭代以及瀑布模型的系统化与严格监控的特征。 风险管理；适应需求变化；增量式开发；完善的文档管理；更好的用户参与度。 增加开发成本；增加沟通协调难度；过度设计；过度重构；更高水平的技能与经验 V模型 将软件开发过程中不同阶段和相应的测试阶段用V字形的图形表示。强调测试。 明确每个测试阶段所验证的对象和依据 仅测试，忽略需求、设计和文档验证。 -
树（B树、霍夫曼树）
-
B树：B树是一种自平衡的搜索树，用于存储大量的数据并允许在对数时间内进行查找、插入和删除操作。B树的节点可以有多个子节点，通常用于在磁盘或其他外部存储设备上存储数据。B树的主要特点包括：
- 多路搜索：B树的节点可以有多个子节点，通常每个节点有2个或更多的子节点。
- 自平衡：B树的节点可以自动平衡，以便在树的高度保持较小的情况下存储大量的数据。
- 高效的查找：B树的查找操作可以在对数时间内完成，因为每个节点有多个子节点，可以更快地找到目标节点。
- 高效的插入和删除：B树的插入和删除操作可以在对数时间内完成，因为B树可以自动平衡。
-
霍夫曼树：霍夫曼树是一种用于数据压缩的树形结构，可以将数据编码为0和1的位序列。霍夫曼树的节点包括数据和权重，每个节点的权重表示数据在输入文件中出现的频率。霍夫曼树的主要特点包括：
- 最优编码：霍夫曼树可以生成最优的编码，使得编码后的位序列长度最短，从而实现数据压缩。
- 前缀编码：霍夫曼树的编码是前缀编码，即每个编码都不是另一个编码的前缀，从而避免了解码时出现歧义。
- 高效的压缩和解压：霍夫曼树的压缩和解压操作可以在线性时间内完成，因为每个数据都可以用一个短的位序列表示。
- 可变长度编码：霍夫曼树可以根据输入数据的分布动态生成编码，从而实现可变长度编码，适用于多种数据类型和分布。
-
-
有向图、无向图、邻接表
-
有向图是每个边带有方向，顶点的度分为入度（指向该顶点的弧数量）和出度（该顶点出发的弧数量）。
-
无向图是每条边都没有方向，顶点的度就是顶点边的数目。
-
邻接表是一种图的存储结构，它用一个一维数组存储图中的所有顶点，每个数组元素包含顶点的数据和指向第一条依附该顶点的边或弧的指针。每条边或弧用一个结点表示，包含邻接点的位置、权值、信息和指向下一条边或弧的指针。邻接表既可以用于有向图，也可以用于无向图，只是在构造邻接表时，有向图只需要将结束顶点插入到开始顶点对应的链表中，而无向图需要将两个顶点互相插入到对方的链表中。
-
flowchart LR; A((V0)) B((V1)) C((V2)) D((V3)) A --- B --- C --- D A --- C A --- D
-
graph LR; subgraph 3 V3 --> J[0] --> K[2^] end subgraph 2 V2 --> G[0] --> H[1] --> I[3^] end subgraph 1 V1 --> E[0] --> F[2^] end subgraph 0 V0 --> B[1] --> C[2] --> D[3^] end
-
-
-
校验码
- CRC校验码：CRC（循环冗余校验）是一种数据校验码，用于检查数据传输或存储过程中是否出现错误。在数据库中，CRC校验码可以用于验证数据的完整性，以保证数据的准确性和一致性。
- 哈希算法
- MD5校验码：MD5是一种广泛使用的加密算法，可以将任意长度的数据转换为一个128位的固定长度的哈希值。在数据库中，MD5校验码可以用于验证密码和敏感数据的完整性，以保证数据的安全性。
- SHA1校验码：SHA1是一种安全哈希算法，可以将任意长度的数据转换为一个160位的固定长度的哈希值。在数据库中，SHA1校验码可以用于验证数据的完整性和安全性，以保证数据的可靠性和保密性。
-
耦合
- 动态耦合：两个模块之间的耦合关系在程序运行时才会建立，并且可以在运行时改变。
- 静态耦合：两个模块之间的耦合关系在程序编译时就已经建立，不能在运行时改变。
- 数据耦合：两个模块之间通过共享数据进行通信。
- 控制耦合：一个模块通过控制另一个模块的执行来实现通信。
- 外部耦合：两个模块之间通过共享外部资源（如文件、数据库等）进行通信。
- 内部耦合：一个模块内部的各个部分之间的耦合关系。
-
软件测试
- 功能测试：测试软件的功能是否按照需求规格说明书中的要求正常工作。
- 性能测试：测试软件的性能，包括响应时间、负载能力、稳定性等方面的测试。
- 安全测试：测试软件的安全性，包括数据安全、网络安全、系统安全等方面的测试。
- 兼容性测试：测试软件在不同的硬件、操作系统、浏览器等环境下的兼容性。
- 用户界面测试：测试软件的用户界面是否符合设计要求，易用性、可访问性等方面的测试。
- 集成测试：测试软件与其他系统、组件之间的集成情况，是否能正常协同工作。
- 回归测试：测试软件的修改后是否仍然满足原有的功能和性能要求。
- 接口测试：测试软件的各个组件之间的接口是否符合要求，是否能正常通信。
- 公开测试：公众测试，开放给大众用户
- 内部测试：内部开发人员等的专业人员测试，模拟真实场景的情况，不对外开放。
- α测试：开发人员测试，受控的环境场景，内测的一种。
- β测试：特定用户测试，开发后期，测试环境不受控。
-
数据流图
-
示例
graph TD; A[选课系统] -->|学生信息| B(选课) A -->|课程信息| C(课程信息查询) B -->|选课记录| D(选课记录更新) -
该系统的主要功能是允许学生选择他们想要修读的课程。该系统由一个进程“选课系统”组成，它接收来自外部的三种数据流：学生信息、课程信息和选课记录。学生信息包括学生的个人信息和选修课程的列表，课程信息包括课程的名称、编号、学分和时间等信息，选课记录包括学生已经选修的课程和他们的成绩。在该系统中，学生可以通过“选课”进程选择他们想要修读的课程，系统会查询课程信息来确定课程是否可选，并将选课记录更新以反映学生的选择。如果学生想要查询课程信息，他们可以通过“课程信息查询”进程来获取有关课程的详细信息。
-
这副流图的起点是一个进程，即“选课系统”，它代表整个学生选课系统。数据流从外部输入到该进程中，包括学生信息、课程信息和选课记录。同时，该进程也包含了三个处理过程，即“选课”、“课程信息查询”和“选课记录更新”。数据流图的终点是这三个处理过程，它们是从进程中发出的处理逻辑。具体来说，当学生想要选修课程时，他们会通过“选课”进程向系统发送选课请求，该进程会将这个请求转化为选课记录更新的处理过程。同理，当学生想要查询课程信息时，系统会通过“课程信息查询”进程来处理这个请求，并返回有关课程的详细信息。
-
数据流平衡：子加工的输入和输出的数量是相等的。
-
子加工分解：每一个过程（框框）都是一个子加工。
-
-
强实体、弱实体依赖
- 强实体是指在数据库中具有唯一标识符（primary key）的实体，它可以独立存在，不依赖于其他实体。强实体的标识符可以用来唯一标识该实体，同时也可以用来与其他实体建立关联关系。例如，在一个学生信息管理系统中，学生就是一个强实体，每个学生都有唯一的学号作为标识符。
- 弱实体是指在数据库中没有唯一标识符的实体，它必须依赖于其他实体才能存在。弱实体的标识符通常是由与其相关的强实体的标识符和一个区分不同弱实体的标识符（称为“附属标识符”）组成的。例如，在一个订单管理系统中，订单项就是一个弱实体，它必须依赖于订单实体才能存在，订单号和订单项号组成了订单项的标识符。（多对多关系中的中间表）
-
关系代数表达式、转换SQL表达式
- 选择（Selection）操作：关系代数表达式：
σ age>20 (Student)，SQL语句：SELECT * FROM Student WHERE age>20； - 投影（Projection）操作：关系代数表达式：
π name, age (Student)，SQL语句：SELECT name, age FROM Student； - 连接（Join）操作：关系代数表达式：
Student ⋈ SC，SQL语句：SELECT * FROM Student INNER JOIN SC ON Student.ID = SC.ID； - 并集（Union）操作：关系代数表达式：
R ∪ S，SQL语句：SELECT * FROM R UNION SELECT * FROM S； - 差集（Difference）操作：关系代数表达式：
R - S，SQL语句：SELECT * FROM R WHERE NOT EXISTS (SELECT * FROM S WHERE R.ID = S.ID)； - 交集（Intersection）操作：关系代数表达式：
R ∩ S，SQL语句：SELECT * FROM R WHERE EXISTS (SELECT * FROM S WHERE R.ID = S.ID)；
- 选择（Selection）操作：关系代数表达式：
-
函数依赖集
-
这也就是“函数依赖”名字的由来，类似于函数关系 y = f(x)，在x的值确定的情况下，y的值一定是确定的。
-
函数依赖有不同的类型，如非平凡函数依赖、平凡函数依赖、完全函数依赖、部分函数依赖和传递函数依赖。它们分别描述了不同的属性关系，如一对一、一对多、多对多等。
-
非平凡函数依赖：当关系中属性集合Y不是属性集合X的子集时，存在函数依赖X→Y，则称这种函数依赖为非平凡函数依赖。 也就是说X决定Y，但是Y不在X中，这种叫做非平凡函数依赖。
-
平凡函数依赖：当关系中属性集合Y是属性集合X的子集时 (Y⊆X)，存在函数依赖X→Y，即一组属性函数决定它的所有子集，这种函数依赖称为平凡函数依赖。 也就是说如果属性集Y属于X，则X可以决定Y，又可以说属性集X可以决定他的属性子集。
-
完全函数依赖：设X,Y是关系R的两个属性集合，如果U完全函数依赖于X，即X中的所有属性一起才能决定U，则称U为R的候选键。 设X,Y是关系R的两个属性集合，存在X→Y，若X’是X的真子集，存在X’!→Y，则称Y完全函数依赖于X。 白话：完全函数依赖就是说属性组X的所有属性一起（即完全）才能决定属性Y，去掉任何一个属性都不行。
-
部分函数依赖：设X,Y是关系R的两个属性集合，存在X→Y，若X’是X的真子集，存在X’→Y，则称Y部分函数依赖于X。 白话：部分函数依赖就是说属性组X中的部分属性就可以决定Y，用不着全部。
-
传递函数依赖：设X,Y,Z是关系R中互不相同的属性集合，存在X→Y (Y !→X),Y→Z，则称Z传递函数依赖于X。 白话：如果 X 函数决定 Y，Y 函数决定Z，且 Y、Z 都不包含于 X，Z 不包含于 Y ，Y 不能决定 X，则称 Z 传递函数依赖于 X。
-
假设有一个关系模式R (U) ，其中 U = {学号，姓名，年龄，专业} 。我们可以假设不允许有同名的学生，那么我们可以得到以下函数依赖： 学号 → 姓名，年龄，专业 姓名 → 学号，年龄，专业 年龄 → 无 专业 → 无 根据这些函数依赖，我们可以判断它们的类型： 学号 → 姓名，年龄，专业 是非平凡函数依赖，因为右部不是左部的子集。 姓名 → 学号，年龄，专业 也是非平凡函数依赖，因为右部不是左部的子集。 年龄 → 无 是平凡函数依赖，因为右部是左部的子集。 专业 → 无 也是平凡函数依赖，因为右部是左部的子集。 学号 → 姓名 是完全函数依赖，因为学号的任何真子集都不能决定姓名。 学号 → 年龄 是完全函数依赖，因为学号的任何真子集都不能决定年龄。 学号 → 专业 是完全函数依赖，因为学号的任何真子集都不能决定专业。 姓名 → 学号 是完全函数依赖，因为姓名的任何真子集都不能决定学号。 姓名 → 年龄 是完全函数依赖，因为姓名的任何真子集都不能决定年龄。 姓名 → 专业 是完全函数依赖，因为姓名的任何真子集都不能决定专业。 年龄 → 学号 是部分函数依赖，因为年龄和姓名的组合可以决定学号。 年龄 → 姓名 是部分函数依赖，因为年龄和学号的组合可以决定姓名。 年龄 → 专业 是部分函数依赖，因为年龄和学号或姓名的组合可以决定专业。 专业 → 学号 是部分函数依赖，因为专业和姓名的组合可以决定学号。 专业 → 姓名 是部分函数依赖，因为专业和学号的组合可以决定姓名。 专业 → 年龄 是部分函数依赖，因为专业和学号或姓名的组合可以决定年龄。 没有传递函数依赖存在。
-
-
NoSQL
- 非结构化数据存储：NoSQL数据库可以存储非结构化和半结构化数据，例如文档、图形、键值对等，而不仅仅是表格形式的数据。
- 分布式架构：NoSQL数据库通常采用分布式架构，可以跨多个服务器进行水平扩展，以支持大规模数据处理。
- 高可用性和容错性：NoSQL数据库通常具有高可用性和容错性，能够在节点故障时自动恢复，以保障数据的可靠性和可用性。
- 灵活的数据模型：NoSQL数据库通常支持灵活的数据模型，可以根据应用程序的需要进行调整，支持更加灵活的数据操作和查询。
- 高性能和可伸缩性：NoSQL数据库通常具有高性能和可伸缩性，能够处理大量的数据和高并发访问，以支持实时数据处理和分析。
-
NoSQL BASE特性
- Basically Available（基本可用性）：系统能够在部分故障的情况下保证基本的可用性。
- Soft state（软状态）：系统在没有输入时不会一直保持强一致性。
- Eventually Consistent（最终一致性）：系统经过一段时间后最终达到一致性状态。
-
流水线
-
并行流水线：操作按照流水的方式进入处理机
-
假设流水线有，则最终所需时间为：
3Δt + (n - 1) * Δt： -
graph LR; A1 --> A2 --> A3; B1 --> B2 --> B3; C1 --> C2 --> C3; subgraph 1Δt A1; end subgraph 2Δt B1; A2; end subgraph 3Δt C1; B2; A3; end subgraph 4Δt C2; B3; A3; end subgraph 5Δt C3; end
-
-
算数表达式→后缀式
- 使用栈的形式，从左到右依次过，比如：
1 + 2 * 3 - ( 3 - 5 ) / 2 - 入栈的前提是比较栈顶元素优先级：+和- 小于 *和/。判断时，如果存在出栈情况，需要一直比对直到本次的元素入栈为止（＞栈顶直接入栈，≤栈顶时需要出栈，然后继续比较新的栈顶，左括号直接入栈，右括号时直接输出栈直到左括号出栈为止【出栈后表达式不含括号】）。
123*+35-2/-
- 使用栈的形式，从左到右依次过，比如：
-
时间复杂度（图）
-
排序算法（快速、冒泡、哈希、堆、选择、归并）
- 冒泡排序（Bubble Sort）：时间复杂度O(n²)，空间复杂度O(1)，稳定。
- 选择排序（Selection Sort）：时间复杂度O(n²)，空间复杂度O(1)，不稳定。
- 插入排序（Insertion Sort）：时间复杂度O(n²)，空间复杂度O(1)，稳定。
- 希尔排序（Shell Sort）：时间复杂度O(nlog n)，空间复杂度O(1)，不稳定。
- 归并排序（Merge Sort）：时间复杂度O(nlog n)，空间复杂度O(n)，稳定。
- 快速排序（Quick Sort）：时间复杂度O(nlog n)，空间复杂度O(log n)，不稳定。
- 堆排序（Heap Sort）：时间复杂度O(nlog n)，空间复杂度O(1)，不稳定。
-
查找算法（顺序、折半、分块、动态）
- 线性查找（Linear Search）：从头到尾逐个比较，时间复杂度为O(n)，空间复杂度为O(1)，不需要元素有序。
- 二分查找（Binary Search）：只适用于已排序的数组，每次将查找范围缩小一半，时间复杂度为O(log n)，空间复杂度为O(1)，需要元素有序。
- 插值查找（Interpolation Search）：优化了二分查找，根据查找值在数组中的位置估算出其可能的位置，时间复杂度为O(logn)到O(n)，空间复杂度为O(1)，需要元素有序。
- 斐波那契查找（Fibonacci Search）：优化了插值查找，将数组的长度用斐波那契数列来表示，时间复杂度为O(log n)，空间复杂度为O(1)，需要元素有序。
- 哈希查找（Hash Search）：通过哈希函数将查找值转换为数组的下标，时间复杂度为O(1)到O(n)，空间复杂度为O(n)，不需要元素有序。
- 二叉查找树（Binary Search Tree）：基于二叉树的数据结构，用于快速查找、插入和删除元素。时间复杂度为O(log n)到O(n)，空间复杂度为O(n)。
- 平衡二叉查找树（Balanced Binary Search Tree）：对二叉查找树进行优化，保证树的高度平衡，提高查找效率。常见的平衡二叉查找树包括AVL树、红黑树等。时间复杂度为O(log n)，空间复杂度为O(n)。
- B树（B-Tree）：一种多路查找树，每个节点可以有多个子节点，用于在大规模数据集合中查找和维护有序数据。时间复杂度为O(log n)，空间复杂度为O(n)。
- 分块查找（Block Search）的时间复杂度为O(块数+块内元素数)
-
计算机保护条例、软件著作权、软件署名权
- 软件著作权
- 同日申请时，先使用系统的有权（有证据），否则各自协商；
- 非同日申请时，先使用系统的有权（有证据），先申请的有权（无证据）；
- 如无签订协议的，公司职员帮公司编写的程序属于公司，甲方帮乙方编写的程序归甲方。
- 软件署名权
- 公司不得擅自更改著者署名权；
- 软件著作权
-
活动图
-
graph LR; D --> |2|E --> |5|H --> |8|G A --> |4|B --> |3|D --> |9|F --> |2|G A --> |11|C --> |7|F E --> |8|I --> |6|J J --> |2|K --> |10|G
-
最短时间、最长时间、完成x活动需要至少多久。
-
-
数据依赖
-
软考SQL常见语句
-
存储过程
CREATE PROCEDURE 存储过程名(IN|OUT|IN OUT 参数1 数据类型, ···) [AS] BEGIN END -
触发器
CREATE TRIGGER<触发器名> [{BEFORE|AFTER}] -- 在执行处罚语句之前/之后激发触发器 {[DELETE|INSERT|UPDATE OF [列名清单]]} -- 触发器类型删除/新增/修改 ON 表名 [REFERINCING<临时视图名>] -- 执行临时视图别名，存放新值和旧值 FOR EACH ROW [WHEN<触发条件>] -- 触发条件必须包含临时视图名 BEGIN <触发动作> END [触发器名] -
建表
CREATE TABLE <表名>(<列名><数据类型>[列级完整性约束条件], [<列名><数据类型>[列级完整性约束条件]]··· [,<表级完整性约束条件>]); PRIMARY KEY(C_BH) -- 加在字段后面或结尾（分号前） PRIMARY KEY(C_NAME, C_ITEM, ……) -- 多个属性的主键仅可加在结尾 <列名> <类型> NOT NULL UNIQUE -- 等同于主键，仅可加在字段后面，NNU和PK仅一个即可 <列名> <类型> REFERENCES T_TABLE(C_BH) -- 加在字段后面 FOREIGN KEY(C_BH_JZ) REFERCNCES T_TABLE(C_BH) -- 加在结尾（分号前） -
CRUD
-
SELECT
SELECT [ALL|DISTINCT]<目标列表达式>[,<目标列表达式>]··· FROM <表名或视图名>[,<表名或视图名>]··· [WHERE <条件表达式>] [GROUP BY <列名1>[HAVING<条件表达式>]] [ORDER BY <列名2>[ASC|DESC]···] -
UPDATE
UPDATE <表名> SET <字段名>=<值> [WHERE <条件>] -
INSERT
INSERT INTO <表名> (<字段1>, ...) VALUES (<值1>, ...) -
DELETE
DELETE FROM <表名> [WHERE <条件>] -
ALTER
ALTER TABLE <表名>[ADD<新列名><数据类型>[完整性约束条件]] [DROP<完整性约束名>] [MODIFY<列名><数据类型>];
-
-
TRANSACTION
BEGIN TRANSACTION -- 开始事务 END TRANSACTION -- 结束事务 COMMIT -- 提交事务 ROLLBACK -- 回滚事务 -
GRANT
GRANT <权限>[,<权限>]··· ON <对象类型><对象名> TO <用户>[,<用户>]··· [WITH GRANT OPTION] -- 获得该权限的用户还可以将该权限赋给其他用户 -
CURSOR
DECLARE CURSOR <指针名> IS <SELECT语句>; BEGIN OPEN <指针名>; LOOP FETCH <指针名> INTO <ITEM_NAME>; EXIT WHEN <指针名>%NOTFOUND; <逻辑判断> END LOOP; CLOSE <指针名>; END;
-
-
实体联系图（ER图）
erDiagram STUDENT ||--o{ CLASS : class_no STUDENT { int stu_no string stu_name int class_no } CLASS { int class_no string class_name } -
约束关系
-
参照完整性约束（外键约束）
REFERENCES <表名><列名> [ON DELETE CASECODE|SET NULL] -- 加在字段后面 FOREIGN KEY(<列名>) REFERCNCES <表名><列名> [ON DELETE CASECODE|SET NULL] -- 加在结尾（分号前） -- 说明： -- ON DELETE CASECODE 删除被参照关系的元组时，同时删除参照关系中的元组 -- ON DELETE SET NULL 删除被参照关系的元组时，同时将参照关系中元组所属字段置为null -
实体完整性约束（主键约束）
<列名> <数据类型> [PRIMARY KEY] -- CREATE 语句中 或 PRIMARY KEY(<列名>[,<列名>]···) -- CREATE 语句结尾
-
-
主键、候选键
- 主键（Primary Key）是用来唯一标识关系表中的记录的属性或属性组合。主键必须满足唯一性、非空性和稳定性等条件，并且可以用来作为关系表之间建立关系的依据。在一个关系表中只能有一个主键，且主键不允许为空值。
- 候选键（Candidate Key）是指在关系表中可以作为主键的属性或属性组合。与主键类似，候选键也必须满足唯一性、非空性和稳定性等条件，但与主键不同的是，一个关系表可以有多个候选键。候选键也可以用来作为关系表之间建立关系的依据。
-
事务调度表
-
分布式数据库CAP特性
- Consistency（一致性）
- Availability（可用性）
- Partition tolerance（分区容错性）
-
数据不一致
- 读脏数据不一致：一个事务读取到了另一个未提交事务中的数据，这些数据被称为“脏数据”，因为它们可能会被另一个事务回滚或修改。
- 丢失修改：多个事务同时对同一数据进行修改时，其中一个事务的修改可能会被另一个事务覆盖，导致前一个事务的修改结果丢失。
- 不可重复读：一个事务多次读取同一数据，在读取的过程中，其他事务对该数据进行了修改，导致事务多次读取到的数据不一致。
- 读幻影：多个事务同时读取同一数据时，由于其中一个事务对该数据进行了修改，其他事务读取到的数据与实际数据不一致，形成了“幻影数据”。
-
内聚
- 偶然内聚: 指一个模块内的各个处理元素之间没有任何联系。
- 逻辑内聚:指模块内执行几个逻辑上相似的功能，通过参数确定该模块完成哪一个功能.
- 时间内聚: 把需要同时执行的动作组合在一起形成的模块。
- 通信内聚:指模块内所有处理元素都在同一数据结构上操作，或者指各处理使用相同的输入数据或者产生相同的输出数据
- 顺序内聚:指一个模块中各个处理元素都密切相关于同一功能且必须顺序执行，前一个功能元素的输出就是下个功能元素的输入。
- 功能内聚: 是最强的内聚，指模块内所有元素共同完成一个功能，缺一不可。
-
数据库三级模式二级映射
-
设计用户外模式：逻辑结构设计
-
设计用户内模式：物理结构设计
-
graph LR; A[外模式<应用>] ---|映射|B["(概念)模式<表结构>"] subgraph 逻辑独立性; A; end B ---|映射|D["内模式（物理）"] subgraph 物理独立性; D; end
-
逻辑独立性：修改表结构，只需要修改外模式和概念模式的映像，不需要修改用户程序。
-
物理独立性：修改了数据物理存储的方式，表结构不变。
-
概念模式：建表语句建出来的东西
-
外模式：用户与数据库的接口，暴露API而不展示内部结构，例如：View
-
内模式：物理存储方式的描述，例如：什么排序方式？加密还是明文？
-
