数据模型

数据模型的不同层次

1. 概念模型（Conceptual Data Model，CDM）
   • 面向现实世界建模
   • 主要用来描述现实世界的概念化结构，与具体DBMS无关
2. 逻辑模型（Logical Data Model，LDM）
   • 面向用户建模
   • 用户从数据库所看到的数据模型；
3. 物理模型（Physical Data Model，PDM）
   • 面向具体的DBMS，面向机器
   • 描述数据在存储介质上的组织结构

数据模型的三要素、

1. 数据结构
   与数据类型、内容、性质有关的对象，如关系模型中的域、属性、关系等 与数据之间联系有关的对象。数据结构是对系统静态特征的描述。
2. 数据操作
   指对数据库中各种对象的实例允许执行的操作的集合，包括操作及有关的操作规则。数据库主要有检索和更新（包括插入、删除、修改）两大类操作。数据模型必须定义这些操作的确切含义、操作符号、操作规则（如优先级）及实现操作的语言。数据操作是对系统动态特性的描述。
3. 数据的约束条件
   一组完整性规则的集合。

数据模型的发展过程：从层次模型到网状模型

关系模型

关系实例

• 由命名的若干列和行组成的表格。一般地，关系指代实例。
• 关系中的行称为元组
• 关系实例中元组的数目称为基（Cardinality）。
• 元组的次序是无关紧要（关系是元组的集合）。

关系模式（Relation Schema）

• 包括：关系名、属性的名字及相关联的域名、完整性约束

• 关系必须是规范化的，满足一定的规范条件

• 最基本的规范条件（第一范式，1NF）：关系的每一个分量必须是一个不可分的数据项，即不能表中有表。

  

关系数据库

关系数据库是关系的有限集合。关系数据库也是由两部分组成：关系模式的集合及对应的关系实例的集合。

• 关系模式的集合称为数据库模式
• 对应的关系实例的集合称为数据库实例

数据结构

关系(Relation)是笛卡尔积的一个有意义的子集

• 是一张二维表

• 每个关系都有一个关系名。

• 二维表存放两类数据：实体本身的数据，实体之间的联系

  

1. 元组(Tuple) ：表中的一行,表示一个实体，关系是由元组组成的。
2. 属性(Attribute) ：表中的每一列在关系中称为属性，每个属性都有一个属性名，属性值则是各元组属性的取值；
3. 域(Domain)属性的取值范围称为域。同一属性只能在相同域中取值。例如，性别属性“Psex”的域为“男”和“女”
4. 分量（Component） ：元组中的一个属性值。
5. 键（Key） ：关系中能唯一区分不同元组的属性或属性组合，关键字的属性值不能取“空值”——实体完整性规则。
6. 候选健（Candidate Key）
   凡在关系中能够唯一区分确定不同元组的属性或属性组合，称为候选健。关系中能够成为关键字的属性或属性组合可能不是唯一的。包括在候选键中的属性成为主属性，不包括在候选键中的属性称为非主属性。
7. 主键（Primary Key，PK）
   当一个关系中有多个候选健的时候，从中选定一个作为关系的主键。关系中主键是唯一的。每个关系中有且只有一个主键。
8. 外键（Foreign Key，FK）
   关系中某个属性或属性组合并非该关系的键，但却是另一个关系的主键，称此属性或属性组合组合为本关系的外键。
   关系模式(Relation Schema)
   对关系的描述称为关系模式，其格式为：
   关系名（属性名l，属性名2，…，属性名n）
   例如：患者（编号，姓名，性别，年龄）

数据操作

关系数据操作包括两类：

1. 查询
2. 更新 (插入、删除和修改 )

用户可以通过关系语言来完成对数据的各种操作，关系语言特点是高度非过程化，即用户只需说明“做什么”而不必说明“怎么做”。

数据约束

关系数据约束：

1. 数据模型中固有的约束，如元组不能重复。
2. 可以在数据模型的模式中直接表述的约束，如数据定义语言（DDL）中指定的完整性约束。
3. 不能在数据模型的模式中直接表述的约束，由应用程序表示和执行。

特点

关系数据模型的优点：

• 关系模型与非关系模型不同，它是建立在严格的数学概念的基础上的。
• 数据结构简单、清晰。
• 更高的数据独立性，更好的安全保密性。
• 丰富的完整性。

关系数据模型的缺点：

• 对“现实世界”实体的表达能力弱。
• 由于存取路径对用户透明，查询效率往往不如非关系数据模型。
• 关系模型只有一些固定的操作集。
• 不能很好的支持业务规则。

性质

1. 有一个关系名，并且跟关系模式中所有其他关系不重名；
2. 每一个单元格都包含且仅包含一个原子值；
3. 每个属性都有一个不同的名字（指同一关系中）；
4. 同一属性中的各个值都取自相同的域；
5. 各个元组互不相同，不存在重复元组；
6. 属性的顺序并不重要；
7. 理论上讲，元组的顺序并不重要。

关系的操作

关系的操作本质上是对集合的操作 ，操作的对象与结果都是集合。
一次一集合（set at a time）。

• 查询：选择、投影、连接、除、并、交、差
• 数据更新：插入、删除、修改

并运算：所有至少出现在两个关系中之一的元组集合。
$$
R\cup S ={ t | t\in R \vee t\in S }
$$
两个关系R和S若进行并运算，则它们必须是相容的

• 关系R和S必须是同元的，即它们的属性数目必须相同。

• 语义是一致的

• R的第i个属性的域必须和S的第i个属性的域相同

  

交运算：结果仍为n目关系，由既属于R又属于S的元组组成，记为：
$$
R\cap S ={ t | t\in R \wedge \ t\in S }
$$

差运算：设关系R和S具有相同的关系模式，。且它们相容，R和S的差是由属于R但不属于S的元组构成的集合，记为：
$$
R-S ={ t | t\in R \wedge t\notin S }
$$

笛卡尔积：两个分别为n目和m目的关系R和S的笛卡尔积是一个 （n＋m）列的元组的集合。
元组的前n列是关系R的一个元组，后m列是关系S的一个元组。
若R有k1个元组，S有k2个元组，则关系R和关系S的笛卡尔积有k1×k2个元组。
$$
R\times S = {t_r \cap t_s | t_r \in R \wedge t_s \in S }
$$

选择运算:从关系中找出满足给定条件的所有元组称为选择。
经过选择运算得到的结果可以形成新的关系，其关系模式不变，但其中元组的数目小于或等于原来的关系中的元组的个数，它是原关系的一个子集。
$$
\sigma_F(R)={t | t\in R , F(t) = True }
$$

投影运算:从关系中挑选若干属性组成的新的关系,投影的结果中要去掉相同的行。垂直方向抽取元组
$$
\Pi_A(R) = { t[A] | t\in R } , A\subseteq R
$$

条件连接（q连接）:A,B为R和S上度数相等且可比的属性列, 为等号时称为等值连接
$$
R \mathop{\bowtie} \limits_{A=B} S = { \widehat{rs}|r\in R\wedge s\in S\wedge r[A] \Theta s[B]}
$$

自然连接:从两个关系的广义笛卡儿积中选取在相同属性列B上取值相等的元组，并去掉重复的行。n\自然连接中相等的分量必须是相同的属性组，并且要在结果中去掉重复的属性，而等值连接则不必。
$$
R\infty S=:{:\widehat{\mathrm{rs}}:|:\mathrm{r\in R}:\wedge:\mathrm{s\in S}:\wedge:\mathrm{r}[\mathrm{B}]=s[\mathrm{B}]:}
$$

左连接（Left Join）
R左连接S：所有来自R的元组和那些连接字段相等处的S的元组。
右连接（Right Join）
R右连接S：所有来自S的元组和那些连接字段相等处的R的元组。

关系数据库的语言

关系的完整性

关系模型的完整性规则是对关系的某种约束条件，保证数据库中数据的正确性和一致性，三类完整性约束如下：

• 实体完整性：主码不能取空值
• 参照完整性：通过外码实现，避免孤子记录
• 用户定义的完整性：各类商业规则

实体完整性和参照完整性是关系模型必须满足的完整性约束条件，被称作是关系的两个不变性，应该由关系系统自动支持。

OpenGauss 函数调研

调研：函数

pgSQL语言函数介绍

PL/pgSQL是一种可载入的过程语言，openGauss实际上就是在postgre数据库的基础上，添加了自己的通信和安全协议，形成的关系型数据库，在许多地方和传统的关系型数据库Postgre十分相像；

在PostgreSQL中，函数是可以执行特定任务的可重用代码块，能够接受参数输入、处理数据并返回结果。这些函数可以用于简化复杂的数据处理操作，提高代码的可读性和可维护性。

用PL/pgSQL创建的函数可以被用在任何可以使用内建函数的地方。

例如，可以创建复杂条件的计算函数并且后面用它们来定义操作符或把它们用于索引表达式。

引入函数的目的

在SQL最初的设计中，这种语言应该是高度非过程化的，这句话的意思是开发者无需关心具体的操作步骤，而应该专注与其查询和更新操作，随着数据库业务拓展，引入函数这种过程化的元素应该有诸多考虑：

• 复杂数据处理和扩展性：适应更广阔的业务场景
• 代码重用，安全性和高级封装：减少开发者的压力，提供API，为上层提供服务
• 事务管理，触发器和事件：胜任更复杂的数据库管理任务
• 高级语言支持和扩展性：支持PL/pgSQL、PL/Python、PL/c
• 减少通信开销：避免对结果的多轮传送和多轮查询解析，实现业务逻辑的集中管理

简单示例解析

以下是一个在openGauss中实现两数之和的函数

1
2
3
4
5
6

CREATE FUNCTION add_two_numbers(a integer, b integer) 
RETURNS integer AS 
$$ BEGIN
  RETURN a + b;
END;$$ 
LANGUAGE plpgsql;

观察语法高亮部分，不难看出有以下关键字可能比较重要：

• CREATE FUNCTION :和存储过程类似，需要有函数的创建声明关键字
• RETURNS AS:和大部分高级语言类似，需要有函数的输入参数和对返回值的类型声明；
• BEGIN END:和事务类似，定义函数体；
• RETURN:函数的返回值
• LANGUAGE:创建函数的语言

函数语法

函数创建

应用PL/pgSQL创建函数的语法为CREATE FUNCTION。PL/pgSQL是一种可载入的过程语言。

其应用方法与存储过程相似，只是存储过程无返回值，函数有返回值。

函数体

PL/pgSQL用于创建函数时，函数体是以字符串的形式存在的，比如'function body text'

1
2
3
4
5
6
7
8
9

CREATE FUNCTION somefunc(integer, text) RETURNS integer 
LANGUAGE plpgsql AS 
'function body text';

CREATE FUNCTION somefunc(integer, text) RETURNS integer 
LANGUAGE plpgsql AS 
$$
function body text
$$;

由于函数体是字符串，所以其中的单引号或者反斜线都要通过双写来转义，这可能会导致可读性变差，我们可以使用$符号引用的方式来改善这种情况。

一个$符号引用的字符串常量的组成

• 由一个$符号
• (可选的)标签名
• 另一个$符号
• 字符串内容
• 一个$符号
• 上面相同的标签
• 另一个$符号组成。

例如

1
2

$$  functionbody  $$
$Tag$  functionbody $Tag$

这里标签的作用：

• 标识一个块以便在一个EXIT语句中使用
• 标识在该块中声明的变量名

函数块

PL/pgSQL是一种块结构的语言。一个函数体的完整文本必须是一个块，它的语法结构为：

1
2
3
4
5
6

[ <<label>> ]
[ DECLARE 一些声明 ]
BEGIN
    [一些操作...]
    RETURN ...;
END [ label ];

这是函数块的结构，注意在END后和RETURN应有分号;

函数的每一条语句后都应该有分号；

声明和初始化往往遵循着以下的规则

1
2
3

<name> <type> [:= value];
a integer := 10;  -- 声明整数变量a，初始化为10
b integer;       -- 声明一个整数变量b

操作一般也和高级语言类似

比如赋值操作

1

b := a+20;

调试打印

1
2

RAISE NOTICE
RAISE DEBUG

控制结构

1
2
3
4
5
6
7

IF <条件> THEN
	-- 代码
ELSIF <条件> THEN
	-- 代码
ELSE 
	-- 代码
END IF;

循环结构

1
2
3
4
5
6
7
8
9
10
11
12

LOOP
    -- 代码
    EXIT WHEN <条件>;
END LOOP;

WHILE <条件> LOOP
    -- 代码
END LOOP;

FOR i IN 1..rows LOOP
    -- 代码
END LOOP;

抛出异常

1
2
3
4
5
6

BEGIN
    -- 代码
EXCEPTION
    WHEN <exception_type> THEN
        -- 异常处理代码
END;

嵌套

一个块的语句节中的任何语句可以是一个子块。

子块可以被用来逻辑分组或者将变量局部化为语句的一个小组。在子块的持续期间，在一个子块中声明的变量会掩盖外层块中相同名称的变量，这点和高级语言中的作用域类似；

但是如果你用块的标签限定外层变量的名字，你仍然可以访问它们。一个嵌套的示例如下：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22

CREATE FUNCTION somefunc() RETURNS integer AS $$
<< outerblock >>
DECLARE
    quantity integer := 30;
BEGIN
    RAISE NOTICE 'Quantity here is %', quantity;  -- Prints 30
    quantity := 50;
    
    -- 创建一个子块
    DECLARE
        quantity integer := 80;
    BEGIN
        RAISE NOTICE 'Quantity here is %', quantity;  -- Prints 80
        RAISE NOTICE 'Outer quantity here is %', outerblock.quantity;  -- Prints 50
    END;


    RAISE NOTICE 'Quantity here is %', quantity;  -- Prints 50

    RETURN quantity;
END outerblock;
$$ LANGUAGE plpgsql;

上述的函数具有两个块，其中变量quantity的值在外层始终为50没有发生变化；

不要把PL/pgSQL中用来分组语句的BEGIN/END与用于事务控制的同名SQL命令弄混。PL/pgSQL的BEGIN/END只用于分组，它们不会开始或结束一个事务。

总结

一个完整的语法结构如下：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25

CREATE [ OR REPLACE  ] FUNCTION function_name
    ( [  { argname [ argmode  ] argtype [  { DEFAULT  | :=  | =  } expression  ]}  [, ...]  ] )
    [ RETURNS rettype [ DETERMINISTIC  ]| RETURNS TABLE (  { column_name column_type  }  [, ...] )]
    LANGUAGE lang_name
    [
        {IMMUTABLE  | STABLE  | VOLATILE}
        | {SHIPPABLE | NOT SHIPPABLE}
        | [ NOT  ] LEAKPROOF
        | WINDOW
        | {CALLED ON NULL INPUT | RETURNS NULL ON NULL INPUT | STRICT}
        | {[ EXTERNAL  ] SECURITY INVOKER  | [ EXTERNAL  ] SECURITY DEFINER | AU
THID DEFINER  | AUTHID CURRENT_USER}
        | {FENCED | NOT FENCED}
        | {PACKAGE}
        | COST execution_cost
        | ROWS result_rows
        | SET configuration_parameter { {TO | =} value | FROM CURRENT }
        | COMMENT 'text' 
        | pipelined_clause
    ] 
    [...]
    {
        AS 'definition'
        | AS 'obj_file', 'link_symbol'
    }

OpenGauss场景运用函数

现在大家学会了如何在PgSQL数据库中如何使用函数写出两数之和了，我们来看看在OpenGauss场景下函数有怎么样的运用吧；

我们关注作业中的表，如下

（查看数据库中的所有表）

1

\dt

这些表的具体内容如下：

案例1：Find the difference between the average rating of movies released before 1980 and the average rating of movies released after 1980. (Make sure to calculate the average rating for each movie, then the average of those averages for movies before 1980 and movies after. Don’t just calculate the overall average rating before and after 1980.)

简要翻译：1980年前电影平均分的平均值和1980年后电影平均分的平均值之差

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32

CREATE OR REPLACE FUNCTION avg_rating_difference_before_after_1980()
RETURNS numeric AS $$
DECLARE
    avg_before numeric;
    avg_after numeric;
    result numeric;
BEGIN 
    WITH avg_ratings_before AS (
        SELECT m.mID, AVG(r.stars) AS avg_rating
        FROM Movie m
        JOIN Rating r ON m.mID = r.mID
        WHERE m.year < 1980
        GROUP BY m.mID
    ) 
    SELECT AVG(avg_rating) INTO avg_before
    FROM avg_ratings_before;
 
    WITH avg_ratings_after AS (
        SELECT m.mID, AVG(r.stars) AS avg_rating
        FROM Movie m
        JOIN Rating r ON m.mID = r.mID
        WHERE m.year >= 1980
        GROUP BY m.mID
    ) 
    SELECT AVG(avg_rating) INTO avg_after
    FROM avg_ratings_after;
 
    result := avg_before - avg_after;

    RETURN result;
END;
$$ LANGUAGE plpgsql;

调用函数我们截图获取结果

1

SELECT avg_rating_difference_before_after_1980();

手动计算发现，或者使用其他SQL语句发现，确实是正确的结果；

课题1：未来数据库管理技术发展方向

目录

[TOC]

介绍

未来数据库系统的新趋势[^0]：

• 云原生数据库；
• 端边云协同数据库；
• 分布式数据库；
• AI原生数据库；
• 新硬件驱动；
• 智能化数据管理和运维；
• 多模态数据管理；
• 数据安全隐私计算；
• ……

根据观察，许多现代数据库的设计都是多个趋势同时出现，这样做除了提高自家数据库产品的竞争力外，也能适应愈来愈多变的市场需求；

这样设计的目的是提升性能、扩展性、安全性和智能化管理能力。这种多重趋势的融合使数据库能够更好地应对当前及未来的复杂数据环境和多样化需求。

分布式数据库

概念

分布式数据库是用计算机网络将物理上分散的多个数据库单元连接起来组成的一个逻辑上统一的数据库[^1];

• 每个被连接起来的数据库单元称为站点或节点；
• 分布式数据库有一个统一的数据库管理系统来进行管理，称为分布式数据库管理系统。

与分布式相对而言的概念是单机式数据库，单机数据库指的是数据存储和管理完全依赖于一台服务器（单一节点）的数据库系统,分布式和区块链中的「去中心化」概念比较接近；

许多传统的数据库（例如MySQL，PostgreSQL）采用的就是单机式数据库，架构简单，适用于小规模应用，但是对于海量数据和高并发请求，容易遇到性能瓶颈和单点故障；

因此许多新诞生的数据库（例如华为GaussDB，阿里OceanBase），都往往选择了分布式架构的设计模式，也包括某些传统的数据库也开始向分布式转型；

也就是说，其实分布式架构是数据库解决高数据量和高并发的一种办法，在设计上还是有关系型和NoSQL之分的

注意，分布式不等于集群；

• 分布式：多个独立的计算节点（服务器）协作完成任务，这些节点通过网络相互通信，但对于用户来说，它们表现为一个单一的系统。
• 集群：一组协同工作的计算机（节点），它们紧密耦合来完成某些特定任务。集群中的节点通常位于同一个数据中心；
• 分布式更关注任务和数据的分布，节点相互独立，需要协调一致性和容错性，而集群系统更关注的是任务的协同处理和负载均衡，节点间通常同构，更强调同步和高效协作。

（提问：分布式和集群哪个更复杂？分布式要主要解决数据一致性问题，分布式锁，网络延迟问题，而集群主要考虑负载均衡）

（提问：为什么说分布式和集群往往同时出现？解决复杂计算和大规模数据处理场景下具有互补性…）


特点

1. 物理分布性:
   • 数据存储在多个节点上;
   • 节点可能分布在不同的服务器、数据中心，甚至跨越不同的地理区域;
2. 逻辑整体性
   • 有一个统一的中心协调事务的分配与管理；
   • 节点间彼此通信，保证数据和事务的一致性；
3. 站点自治性
   • 各个节点相对独立，处理自己的计算事务，存储事务
4. 数据分布透明性
   • 用户不需要知道数据存储在什么地方，数据库系统会自动管理这些细节。
   • 用户可以像操作单一数据库一样访问和使用数据。
5. 按既定协议达成共识的机制[^2]
   • 共识机制能在数据一致性、故障容忍、网络分区、顺序一致等关键问题上确保节点之间协调工作；
   • 常见的协议有Paxos协议，raft协议,ZAB协议
6. 适当的数据冗余度
   • 存在数据复制和冗余机制；
   • 在部分节点失效时仍然保持系统的正常运行，有一定的抗风险能力和容错性；
   • 如果某个节点发生故障，系统可以切换到其他节点继续工作，确保数据的持久性和可访问性。

工作原理

CAP定理

在理论计算机科学中，CAP定理[^3]指出对于一个分布式计算系统来说，不可能同时满足以下三点：

• 一致性(Consistency):所有节点访问同一份最新的数据副本;
• 可用性(Availability):每次请求都能获取到非错的响应;
• 分区容错性(Partition tolerance):以实际效果而言，分区相当于对通信的时限要求，即系统能够容忍网络分区的发生。(注：网络分区指的是系统中的节点因为网络故障而无法通信，分布式系统必须继续运行，即便部分节点之间不能正常通信。)

分布式数据库在设计上必须做出权衡，一般会在读写数据库上采取不同的设计策略，来满足各种场景的需求，一般分为CP系统和AP系统；

（提问：在互联网领域的绝大多数的场景中，最广泛的设计是什么：都需要牺牲强一致性来换取系统的高可用性，系统往往只需要保证“最终一致性”，只要这个最终时间是在用户可以接受的范围内即可。）

数据操作

分布式数据库的核心原理包括数据分片、数据复制和数据一致性保证[^4]。

1. 数据分片

   数据分片是将数据分散到多个数据库节点上进行存储和处理的过程。通过数据分片，可以将大量的数据分散到不同的节点上，从而提高系统的可扩展性和性能。数据分片的关键在于如何合理地将数据划分为不同的片段，并确定每个片段的存储位置。

2. 数据复制

   数据复制是在多个数据库节点上创建数据副本的过程。通过数据复制，可以提高系统的可用性和容错性。当某个节点出现故障时，其他节点可以接管其任务，保证系统的正常运行。数据复制的关键在于如何保证数据的一致性和同步性。

3. 数据一致性保证

   数据一致性保证是分布式数据库系统的核心问题之一。由于多个节点之间可能存在数据复制和更新操作，因此需要确保不同节点上的数据保持一致性。常用的数据一致性保证方法包括两阶段提交、三阶段提交和分布式事务等。

分布式锁

分布式还有一个确保共享的重要机制：分布式锁[^5]；

为了保证一个方法或属性在高并发情况下的同一时间只能被同一个线程执行，在传统单体应用单机部署的情况下，可以使用并发处理相关的功能进行互斥控制。

但是，随着业务发展的需要，原单体单机部署的系统被演化成分布式集群系统后，由于分布式系统多线程、多进程并且分布在不同机器上，这将使原单机部署情况下的并发控制锁策略失效，单纯的应用并不能提供分布式锁的能力。

分布式锁正是这种跨机器的互斥机制来控制共享资源的访问，目前有三种实现方式:

• 基于数据库
• 基于缓存
• 基于Zookeeper

优点

• 随时能针对各区域的用户做调整：例如一个全球电商平台可以将用户的购物数据存储在离用户最近的数据中心，从而减少请求的延迟。
• 资料共享和分布式控制 ：去中心化保证一个节点故障不会导致整个系统不可用，其他节点依然可以继续工作，增强了系统的容错能力和弹性。
• 增加处理绩效，可作平行处理：在大数据分析场景下，分布式数据库可以将大规模的数据集分片，分配到不同的节点进行并行计算，加快数据处理速度。
• 系统管理费用较低：这是相对于中心化的传统数据库而言的。提升存储能力和计算能力就要更高级的服务器配置，分布式系统允许通过增加便宜的节点来提高存储和计算能力
• 质量维持容易：在数据备份和恢复方面，如果某个节点的数据丢失或损坏，其他节点的备份副本可以帮助恢复，降低数据丢失风险。
• 增加结点可以轻易实现拓展：这种水平拓展有利于业务的拓展；

缺点

• 重复存储资料很花时间：写入操作需要将数据复制到多个节点，在所有节点完成写入之前，操作可能无法确认成功，这会增加操作的延迟。
• 资料处理与管理上具复杂度，为保证共识的基础上，性能可能会有一定损耗：例如在Raft协议中，写操作必须等待大多数节点确认，才能算作成功提交，这可能导致响应时间增加，尤其是在节点分布较广的情况下。
• 资料的保密性与安全性受到威胁：分布式数据库中的数据被存储在多个节点和地理位置，这意味着安全性问题变得更加复杂。需要考虑如何在不同节点之间安全地传输数据、如何确保不同节点的数据访问权限不被滥用。此外，更多的节点也意味着更多的潜在攻击面。

应用场景

（此处需要图片）

• 大规模网站和应用：如社交网络、电子商务网站，它们需要处理大量的并发用户请求和数据存储。
• 全球化业务：需要在多个地理位置提供快速的本地化数据访问。
• 大数据分析：分布式数据库可以作为大数据平台的数据存储后端，支持分布式计算框架（如Hadoop和Spark）进行高效的数据分析。

云原生数据库

概念

云原生数据库是通过云计算平台构建和访问的数据库服务[^6]。

• 它的许多功能与传统数据库相同，但增加了云计算的灵活性。
• 用户在云基础架构上安装软件来实施该数据库。

云计算是一种基于互联网的计算方式，通过这种方式，共享的软硬件资源和信息可以按需求提供给计算机各种终端和其他设备，使用服务商提供的电脑基建作计算和资源，其三大服务模型包括：基础设施即服务(IaaS),平台即服务（Pass），软件即服务(Saas)[^7];

简单理解云计算：用户透过浏览器、桌面应用程序或是移动应用程序来访问云的服务。

上云意味着用户无需管理底层硬件和设施，也能做到存储，访问和管理数据，因此相较于其他的NewSQL，云数据库节省了硬件成本，也可以适应如今的企业海量的数据管理和动态的业务需求；


特点

1. 按需自助服务：用户可以选择多种方式管理数据库（自托管云，自动化云，托管云，自治云）
2. 广泛的网络访问：云计算服务可以通过各种设备（如电脑、手机、平板等）和网络轻松访问。
3. 资源池化：云计算将底层资源（如服务器、存储、网络带宽等）进行集中管理，按需动态分配给多个用户，资源是共享的，但对每个用户是隔离的。
4. 快速弹性：云计算可以根据需求快速扩展或缩减资源，无论是增加计算能力还是存储空间。
5. 按使用付费：用户根据实际使用的资源量（如处理能力、存储空间、网络带宽等）进行付费，不使用时无需付费，避免了资源的浪费。

工作原理

云数据库使用混合云概念收集、交付、复制组织的所有数据并将其推送到边缘。用户不再需要部署依赖的中间件来将数据库请求传递到世界任意位置。他们可以将应用程序直接连接到数据库。

混合数据库创建分布式混合数据云，以提高性能、覆盖范围、正常运行时间、移动性和节省成本，以便组织能够：

• 从小处着手，发展壮大
• 按需弹性扩展
• 跨多个数据中心的集群
• 独立管理云，或让提供商为他们管理云
• 混合和匹配云提供商以优化地理覆盖范围、服务级别协议 (SLA)、定价和法规需求。

例如，金融组织正在采用混合概念，将数据库作为所有不同数据源的核心数据库，然后以 JSON 格式提供这些金融数据。然后，这些数据作为服务分发到数据库，并复制到世界各地的地理区域。如果新加坡的客户必须等待 4 秒以上才能从新泽西州的数据库检索其移动应用程序数据，则该客户不太可能再次使用该应用程序。数据库即服务 (DBaaS) 可以立即进行复制和分发，并在全球范围内提供近乎实时的数据访问。

优点

• 基于标准，易于访问：用户几乎可以使用提供商的 API 或 Web 界面从任何地方访问云数据库，为实现出色的互操作性和工作负载可移植性，云原生服务通常基于开源和标准技术构建而成，这有助于降低供应商依赖，提高可移植性[^8]。
• 可扩展性：云数据库可以在运行时扩展其存储容量，以适应不断变化的需求。组织只需为其使用的内容付费。
• 增强敏捷性和创新：用户可以非常快速地创建和停止云数据库，轻松、快捷地测试、验证和实施新的业务构想。当企业决定停止实施某个项目，则可以直接放弃项目（及其数据库），然后继续下一个创新。
• 加快上市速度：将新产品添加到开发队列后，企业无需购买硬件，等待发货，进行安装和设置网络，只需几分钟即可访问数据库。
• 降低风险：云数据库（尤其是 DBaaS 模式）能够从多个方面降低整个企业的风险。云技术服务提供商可以通过自动化方法来实施安全性优秀实践和特性，降低人为错误几率 — 这是软件停机的主要原因。同时，自动化的高可用性和服务水平协议 (SLA) 可以减少甚至彻底消除因停机而造成收入损失。最后，在实施项目时，由于云技术解决方案是一个无限、实时的基础设施和服务池，容量预测将不再是难题。
• 降低成本：得益于云数据库按使用付费的订阅模式和动态扩展能力，最终用户可以先行少量供应，满足稳定状态下的需求，然后在繁忙时段扩展，满足峰值需求，并在需求恢复到稳定状态时再缩减供应。这意味着，与本地部署相比，云数据库可以显著降低成本。采用本地部署时，即便每个季度的峰值需求只持续几天，企业也需要购买足够强大的物理服务器。而采用云数据库，企业无需如此，甚至可以在不需要时关闭服务，利用少量基础设施投资实施全球计划，降低成本。最后，在很多情况下，云技术软件自动化可以代替成本高昂的数据库管理员 (DBA)，消除昂贵的内部资源需求，降低运营支出[^8]。

缺点

• 数据库迁移场景多变复杂：将现有的本地数据库迁移到云端可能涉及大量的工作，包括数据结构调整、应用改动以及确保数据的完整性和安全性；
• 用户对数据库控制权有限：用户无法像在本地数据库那样对硬件、操作系统和数据库进行完全的自定义配置。这可能限制特定应用的性能优化。
• 网络依赖性：云数据库完全依赖于网络连接，对于实时性要求较高的应用，可能会产生延迟问题。
• 成本难以预测：对于需要频繁读写大规模数据的应用，成本可能比预期高出很多。

应用场景

（可补充）

• 通信物联网
• 金融与电子商务
• 大数据挖掘,高性能计算

智能数据库

概念

从构建一个高效、高可靠、 高可用、自适应性强的数据库系统角度出发，从下 面八个方面来总结基于机器学习的数据库技术[^9]


智能数据库利用机器学习来处理数据索引、查询优化、模式检测以及自动化调优等任务，从而减轻人工操作负担，并提高系统的整体效率和性能。

前景展望

目前没有太好的商业级的智能数据库，以期解决数据库设计可能存在的问题；

市场上大部分数据库产品，内置的Copilot是一个组件，在数据库运维方面能做到高效的自动化，在大数据挖掘方面也有不错的发挥；

我们相信随着机器学习技术的不断发展，未来我们将看到更多的数据库系统利用机器学习技术实现更高的智能化和自动化。

一些NoSQL

Redis:键值对数据库，基于内存

内存数据库是指一种将全部内容存放在内存中，而非传统数据库那样存放在外部存储器中的数据库。

• 内存数据库指的是所有的数据访问控制都在内存中进行，这是与磁盘数据库相对而言的，磁盘数据库虽然也有一定的缓存机制，但都不能避免从外设到内存的交换，而这种交换过程对性能的损耗是致命的。
• 由于内存的读写速度极快（双通道DDR3-1333可以达到9300 MB/s，一般磁盘约150 MB/s），随机访问时间更是可以纳秒计,所以这种数据库的读写性能很高，主要用在对性能要求极高的环境中，但是在服务器关闭后会立刻丢失全部储存的数据。
• 常见的例子有redis、eXtremeDB、FastDB、SQLite、Microsoft SQL Server Compact等,下均以redis进行举例[^10]；

优点[^11]

• 响应迅速：Redis 响应非常快，每秒可以执行大约 110 000 个写入操作，或者 81 000 个读操作，其速度远超数据库。如果存入一些常用的数据，就能有效提高系统的性能。
• 支持多种数类型：它们是字符串、哈希结构、列表、集合、可排序集合和基数。比如对于字符串可以存入一些 Java 基础数据类型，哈希可以存储对象，列表可以存储 List 对象等。
• 操作都是原子的：所有 Redis 的操作都是原子的，从而确保当两个客户同时访问 Redis 服务器时，得到的是更新后的值（最新值）。在需要高并发的场合可以考虑使用 Redis 的事务，处理一些需要锁的业务。
• 高性能：Redis是一个基于内存的数据库，数据存储在RAM中，因此具有非常快的读写速度。它采用了高效的数据结构和算法，能够在微秒级别完成大量的操作，使其成为处理高并发场景的理想选择。
• 简单易用：Redis提供了简洁、直观的命令行接口和易于使用的API，使开发人员可以轻松地进行数据存储和检索。其支持丰富的数据类型，如字符串、哈希表、列表、集合和有序集合，可以满足不同场景下的需求。
• 数据持久化：Redis支持数据的持久化存储，可以将内存中的数据保存到磁盘上，以防止数据丢失。它提供了两种持久化方式：快照和日志追加，用户可以根据实际需求选择适合的方式。
• 高可用性：Redis支持主从复制和Sentinel机制，可以实现数据的自动备份和故障转移。主从复制可以将数据从主节点复制到多个从节点，提高读取性能和数据冗余；Sentinel机制可以监控主节点的状态，并在主节点故障时自动切换到从节点，确保系统的高可用性；

缺点

1. 内存限制：由于Redis的数据存储在内存中，因此受到可用内存大小的限制。当数据量超过内存容量时，性能会受到影响，甚至导致系统崩溃。虽然Redis提供了数据淘汰策略和内存优化选项，但仍需要合理规划和管理内存资源。
2. 单线程模型：Redis采用单线程模型来处理客户端请求，这意味着在高并发场景下，性能可能受到限制。虽然Redis通过异步操作和事件驱动的方式提高了并发处理能力，但在某些特定场景下，单线程模型可能成为瓶颈。
3. 缺乏复杂查询支持：Redis主要用于键值对存储和简单的数据结构操作，并不支持复杂的查询操作。相比之下，关系型数据库具有更强大的查询语言和查询优化。

GUI

下图可以很明显的看到键值对存储，基于内存的特征：



支持多种数据结构：


内置的AI和大数据可视化：




应用场景

Redis适合的场景主要局限在较小数据量的高性能操作和运算上，在频繁读写的场景下表现较好；

• 缓存应用；
• 会话共享等分布式场景；
• 文章阅读量，点赞数等计数器；
• 消息队列；


MongoDB：基于文档

MongoDB是一种面向文档的数据库管理系统，用C++等语言撰写而成，介于关系型数据库和非关系型数据库之间，以解决应用程序开发社区中的大量现实问题[^12]。

特点

1. 高性能:MongoDB提供高性能的数据持久性。对嵌入式数据模型的支持减少了数据库系统上的IO活动。索引支持更快的查询，并且包含嵌入式文档和数组的键。
2. 高可用性：MongoDB的复制工具称为副本集（reolica set），它包含提供自动故障转移和数据冗余。
3. 高可用性：MongoDB提供了水平可扩展性作为其核心功能的一部分。分片将数据分布在一组集群的机器上。（海量数据存储、服务能力水平扩展）
4. 丰富的查询支持：MongoDB支持丰富的查询语言，支持读写（CRUD）操作、比如数据聚合、文本搜索、地理空间查询等，MongoDB自己号称「任何结构的数据均可查询」，因为它们基于文档的特性；

优缺点

MongoDB的最小存储单位是文档对象，相当于MySQL中的行，数据以BSON文档的形式存储在磁盘上。BSON采用了类似于C语言结构体的名称、支持内嵌的文档对象和数组对象，具有轻量级、可遍历性、高效性三大特点，可以有效描述非结构化数据和结构化数据，灵活性高，但空间利用率不是很理想。

GUI

支持对json或csv文件的导入，存入数据库；


下图是内置的数据分析组件：


应用场景

• 数据量大
• 读写操作频繁
• 数据价值较低，对事务要求不高

（比如：游戏内的装备信息，物流中的订单，物联网中的设备信息，直播中的用户信息，点赞互动）


参考文献

[^0]: 战略研讨-《“十四五”数据库发展趋势与挑战》报告正式发布 (ccf.org.cn)
[^1]: https://zh.wikipedia.org/wiki/%E5%88%86%E5%B8%83%E5%BC%8F%E6%95%B0%E6%8D%AE%E5%BA%93
[^2]: 分布式一致性（共识）算法(Paxos,raft,ZAB)的一些总结_分布式算法有几种 paxos、raft、zab-CSDN博客
[^3]: https://zh.wikipedia.org/wiki/CAP%E5%AE%9A%E7%90%86
[^4]: 深入剖析分布式数据库：原理、架构与实践 (baidu.com)
[^5]: 什么是分布式锁？实现分布式锁的三种方式 - 刘清政 - 博客园 (cnblogs.com)
[^6]: 什么是云数据库？| IBM
[^7]: https://zh.wikipedia.org/wiki/%E9%9B%B2%E7%AB%AF%E9%81%8B%E7%AE%97
[^8]: 什么是云数据库？ | Oracle 中国
[^9]: Microsoft Word - 2019-4-23-07898-确认稿.docx (tsinghua.edu.cn)
[^10]: https://blog.csdn.net/giantleech/article/details/
[^11]: https://zhuanlan.zhihu.com/p/632293767
[^12]: https://zh.m.wikipedia.org/wiki/MongoDB

特点

• 高度统一：集DDL，DML，DCL于一体
• 高度非过程化：只需要提出做什么，无需声明怎么做
• 面向集合的操作：操作的对象和结果均为集合
• 两种使用方法：自主式使用（CLI，GUI），嵌入式语言

核心命令

1. DDL：CREATE DROP ALERT
2. DML: SELECT INSERT UPDATE DELETE
3. DCL: GRANT REVOKE

数据类型

聚集函数

聚集函数可以直接对查询结果进行统计
但是只能出现在SELECT的后面，而且只会返回一个元组

与关系代数的联系

数据查询

关键字

无条件查询

SQL语句：SELECT <字段列表> FROM <表名>

可以用*表示所有列名；

例如查询所有医生的信息：

1

SELECT * FROM Doctor;

结果如下：

条件查询

SQL语句：SELECT <字段列表> FROM <表名> WHERE <查询条件>

条件之间的连接可以使用以下的连接运算符：

例如：查询年龄小于或等于40岁的男医生信息

1

SELECT *  FROM  Doctor  WHERE Dsex='男' AND Dage<=40 ;

结果如下：

列的别名

改变查询显示列的标题，用关键字AS,跟在SELECT的属性后面；

SQL语句：SELECT <字段1> AS <别名1>,..., <字段吗> AS <别名m> FROM <表名>

例：查询医生姓名和职称并重命名

1

SELECT Dname AS 医生姓名, Dlevel 专业职称 FROM Doctor;

结果如下：

查询表达式

查询条件可以用表达式表示

例：在药品信息表中，查询药品单价提高15%后超过30元的药品信息

1

SELECT Mno 编号，Mname 药品名，Mprice 单价，Mprice*1.15 调整单价 FROM medicine  WHERE Mprice*1.15>=30;

字符串匹配

字符串的模式匹配：正则表达式支持

• %:表示任意长度（包括长度为0）的字符串
• _：表示任意单个字符

例如：查询职称为副某的医生信息

1

SELECT *  From Doctor  Where Dlevel Like '副%';

结果去重

使用DISTINCT合并查询结果的重复记录

例如：查询部门编号

1

SELECT DISTINCT Ddeptno FROM Doctor; 

结果排序

使用ORDER BY

• 系统缺省为升序排序ASC
• 也可以设定为降序DESC

例如：按部门编号升序而按年龄降序查询医生信息

1

SELECT * From Doctor  ORDER BY Ddeptno ASC ,Dage DESC ;

统计查询

统计查询是通过聚集函数实现的；它可以对查询结果直接进行统计；

• 聚集函数一般忽略空值；
• 选项DISTINCT表示只计算不同的记录值，不计入重复值和空行；
• 一次聚集函数返回一条记录

分组查询：使用GROUP BY，对所查询的表按字段进行分组，值相同的在一组，和聚集函数一起使用，聚集函数对每一组产生一个统计结果

分组筛选:使用HAVING子句，选出复合条件的统计分组，放在GROUPBY子句后

例如：

查询申请了计算机专业总申请数量

查询各个专业总申请数量;

计算机专业申请者数量大于等于2的高校；

1
2
3

SELECT COUNT(*) FROM Apply WHERE Major='计算机';
SELECT COUNT(*)  FROM Apply  sID cID GROUP BY major;
SELECT cID, COUNT(DISTINCT sID) FROM Apply WHERE Major='计算机' GROUP BY cID HAVING COUNT(DISTINCT sID) >=2;

连接查询

连接满足查询条件或结果来自多个表；
连接同名之短时需要消除歧义；
连接条件的不同特点：等值连接，非等值连接，自然连接，自连接

内连接

找出符合条件的共有记录，

• FROM R1, R2 WHERE R1.A1 <比较运算符> R2.A2
• FROM R1 INNER JOIN R2 ON + R1.A1 <比较运算> R2.A2
• FROM R1 INNER JOIN R2 USING(A1)

等值连接

例如：
在医生基本信息表中，需要查询患者的每个处方用药信息;

1

SELECT RecipeDetail.* Medicine.* FROM RecipeDetail, Medicine WHERE RecipeDetail.Mno=Medicine.Mno;

自然连接

要求连接列的列名相同，并且查询结果列不重复 NATURE JOIN
例如：在医院信息数据库中，需要查询开出处方的医生信息。

1
2
3
4

SELECT Rno,Pno,Dno,Dname,Dsex,Dage,Ddeptno,Dlevel
FROM RecipeMaster R NATUAL JOIN Doctor D 
FROM RecipeMaster R NATUAL JOIN Doctor D
SELECT Rno,Pno,D.Dno,Dname,Dsex,Dage,Ddeptno,Dlevel 

自连接

支持表自身的连接,即同一张表的两个副本之间的连接
例如：在医院部门表中，需要医院的各部门名称和上级部门名称

1
2
3

SELECT First.DeptName 部门名称,Second.DeptName 上级部门
FROM Dept First ,Dept Second
WHERE First.ParentDeptNo=Second.DeptNo

外连接

左外连接：LEFT OUTER JOIN
右外连接：RIGHT OUTER JOIN
全外连接：FULL OUTER JOIN
不一定所有数据库支持外连接；

嵌套查询

在一个查询语句中包含另一个完整的查询语句；
外层的查询：父查询
内层的查询：子查询
子查询的结果作为主查询条件的一部分；

• 不相关子查询：子查询条件不依赖于主查询，独立执行，顺序从内至外；
• 相关子查询：子查询依赖于主查询，子查询需要引用主查询的表
  例如：

1
2
3
4
5
6
7
8
9
10
11
12
13

SELECT sID,sName，GPA
FROM Student NATURAL JOIN Apply
WHERE cID=‘10614’AND GPA>
（SELECT AVG(GPA)
FROM Student NATURAL JOIN Apply 
WHERE cID=‘10614’）;

SELECT sID,sName，GPA
FROM Student NATURAL JOIN Apply A
WHERE AND GPA>
（SELECT AVG(GPA)
FROM Student NATURAL JOIN Apply B 
WHERE A.cID=B.cID）;

子查询结果是一个关系，可以利用集合运算符

• IN/NOT IN: 测试一个元素是否属于一个集合
• EXISTS/NOT EXISTS：测试一个集合是否为空
• 关键字在父查询的FROM子后

1
2
3
4
5
6
7
8
9

SELECT sName FROM Student 
WHERE sID
IN
( SELECT sID FROM Apply
WHERE major=‘计算机’);
SELECT sName FROM Student S1
WHERE NOT EXISTS
( SELECT * FROM Student S2
WHERE S2.GPA>S1.GPA);

谓词

• 与集合所有元素比较ALL
  例如GPA最高的学生姓名SELECT sName FROM Student WHERE GPD >= ALL (SELECT GPA FROM Student)
• 与集合中任意一个元素比较
  例如GPA最高的学生姓名SELECT sName FROM WHERE NOT GPA < ANY (SELECT GPA FROM Student)

应该优先选择子查询而不是连接查询

• 查询多次带来的IO开销不可忽略
• 连接查询在内部有查找优化（索引+二分），性能并不是线性相乘

数据更新

插入操作

引入关键字：INSERT INTO … VALUES
格式如下

• 表名：指要插入数据的目标表
• 列名：指定表的目标列，参数省略时默认全部列
• 值表：具体要插入的值

1

INSERT INTO <表名> [(<列名>)] VALUES (<值表>)

增加操作

格式为

• select子句中选择的列应该和列名保持对应
• 类型和长度兼容，列名可以不同

1

INSERT INTO <表名> [(<列名>)] <select子句>

修改操作

引入关键字UPDATE
格式为

1
2
3

UPDATE <表名> 
SET <列1>=<表达式1>, <列2>=<表达式2>,…
[WHERE]

数据删除

引入关键字DELETE
格式为

1

DELETE FROM <表名> WHERE <条件>

数据库范式

数学表示

关系模式的五元组表示：$\rm R(U, D, DOM, F) $

• $R$：关系名
• $U$：组成该关系的属性名集合
• $D$：属性组U中属性所来自的域
• $DOM$：属性向域的映象集合
• $F$：属性间数据的依赖关系集

对于一个简化的关系模式三元组表示：$\rm R(U,F)$

• 数据依赖是现实世界属性相互联系的抽象
• 数据依赖是数据内在的性质
• 数据依赖是寓意的体现
  规范化解决的问题是如何构造合适的关系模式

设计好的模式：大模式的分解，信息完整

模式的分解：自动化，模式设计包含所有信息，按照一定规则分解的小模式没有数据冗余和更新异常

数据依赖

• 函数依赖FD：一个关系表中属性之间的联系
• 多值依赖MVD：关系中属性之间在语义上的关联特性

函数依赖

对于关系模式$R(U)$,$X,Y \subseteq U$,设$t,s$是关系$R$中的任意两个元组；

称$Y$函数依赖于$X$,$X$称为决定因子，$Y$称为依赖因子，若$t[X]=s[X]$,则$t[Y]=s[Y]$;

• 对于$Y\subseteq X$,这种情况视为平凡函数依赖
• 由于不反映新的寓意，所以函数依赖一般指非平凡的；

完全依赖/部分依赖

对于$X,Y$是关系的不同属性集，满足$X\to Y$；

若$\nexists X’ \subset X,X’\to Y$,称$Y$完全函数依赖于$X$,否则称为部分依赖

传递依赖

对于$X,Y,Z$是关系的三个不同的属性集

若$X\to Y,Y\to Z,Y\nrightarrow X$,有$X\to Z$, 称$Z$传递依赖于$X$

• 某一个属性列唯一，那么这个属性可以决定其他属性
• 这个属性的任意超集也可以决定其他属性

逻辑蕴含

对于关系$R$上的依赖集$F={ A\to B, B\to C }$

若$A\to C$在$R$上也成立，称$F$逻辑蕴含$A\to C$,记为$F\models A\to C$

也就是说，一个函数依赖可以由其他函数推出，那么这个函数依赖被视为多余的；

对于函数依赖的闭包，定义为
$$
F^+={X\to Y| F \models X\to Y}
$$

• 这个集合定义了由给定函数依赖集能够推导出所有的函数依赖
• 根据一直的函数依赖集，推导出其他函数依赖的规则称为推理规则
• 由已知函数依赖集推导闭包是NPC问题；

Armstrong公理

闭包中的函数依赖可以通过三个关系找出，这样的推导是正确且完备的，不过从$F$找到对应的闭包是一个NPC问题；

• 自反性：$$ Y\subseteq X\subseteq U \models X\to Y$$
• 增广性：$$X\to Y,Z\subseteq U \models X\cup Z\to Y\cup Z $$
• 传递性：$$ X\to Y,Y\to Z\models X\to Z$$
• 合并性：$${X\to Y,Y\to Z}\models X\to Y\cup Z$$
• 伪传递性：$${X\to Y,WY\to Z}\models XW\to Z$$
• 分解性：$${X\to Y,Z\subseteq Y}\models X\to Z$$
• 复合性：$${X\to Y, W\to Z}\models XW\to YZ$$
• 通用一致性：$${X\to Y,W\to Z}\models X\cup (W-Z) \to YZ$$

属性集闭包

定义以下的属性集闭包：
$$
X^+ = { A| A\in U, X\to A\in F^+}
$$
属性集的闭包是P问题；$X\to Y$能使用Armstrong规则推导出的充分必要条件为$A\subseteq X^+$;

属性集闭包算法：

1
2
3
4
5

X_clo := X
do{
	if A→B,A⊆X+
		X+ = X+ ⋃ B
}while(X+ changes)

最小依赖集

函数依赖集逻辑等价记作$F=G$；

$F,G$是$R(U)$的两个函数依赖集，若$F^+ = G^+$,称$F,G$是等价的函数依赖集；

最小依赖集定义如下：

• $F_{min} ^+ = F^+$;
• 每个函数依赖的右边是单属性；
• $F_{min}$没有冗余的函数依赖；
• 每个函数依赖左边没有冗余的属性

最小依赖集算法：

• 计算$F$等价的$G$，要求$G$的每个依赖集右边为单属性；
• 消除$G$中每个函数依赖左边的冗余属性
• 消除$G$中的冗余的函数依赖

候选码

若$K$为$R(U,F)$中的属性或者属性结合，若$K\xrightarrow{f} \ U$,则$K$为$R$的候选码；

若候选码多于一个，可选定一个当作主码(primary key)

• 单个属性是码，称为单码
• 整个属性组是码，称为全码

模式分解

函数依赖可以引起的数据冗余和更新异常等问题，需要对关系模式进行分解

关系模式$R$的分解就是用两个或两个以上关系来替换$R$，分解后的关系模式的属性集都是$R$中属性的子集，其并集与$R$的属性集相同

具体来说，对属性集$U$,关系模式$R(U)$,若用一组关系模式的集合${R_1(U_1),\cdots,R_k(U_k)}$来取代$U=\bigcup_{i=1}^k U_i$,则称此关系模式的$R$的一个分解，记作$\rho = {R_1,\cdots,R_k}$

关系模式分解的两个特性实际上涉及两个数据库模式的等价问题

• 数据等价是指两个数据库实例应表示同样的信息内容，如果是无损分解，那么对关系反复的投影和连接都不会丢失信息；
• 依赖等价是指两个数据库模式应有相同的依赖集闭包。在依赖集闭包相等 情况下，数据的语义是不会出错的

保持依赖

设$\rho={R_1,…,R_k}$是$R$的一个分解；$F$是$R$的一个FD集；

如果
$$
\bigcup_{i=1}^k \prod R_i(F) \models F
$$
称分解$\rho$保持函数依赖集$F$

无损分解

对于关系模式$R$,其一个函数依赖集为$F$,其一个模式分解为$\rho = {R_1,\cdots,R_k}$,

若对于$R$中满足$F$的每一个关系$r$，均有
$$
r=\pi_{R_1}(r) \bowtie \cdots \bowtie \pi_{R_k}(r)
$$
则称分解$\rho$是相对于依赖集$F$的一个无损连接分解，否则则是有损分解；

利用Chase算法将关系模式一分为二，判断是否为无损分解；

设$\rho={R_1(U_1),R_2(U_2)}$是关系模式$R$的一个分解，则$\rho$是无损分解的充分必要条件为以下关系满足其一即可
$$
(U_1\cap U_2)\to(U_1-U_2)\(U_1\cap U_2)\to(U_2-U_1)
$$
模式分解能消除数据冗余和操作异常现象， 分解以后，检索需要作笛卡尔集或连接操作，带来时间开销，为了消除冗余和异常，对模式的分解是值得的；

范式

范式是关系的状态，也是衡量关系模式的好坏的标准，一个规范化的方式有最小的数据冗余

除了与援助进行连接的外键之外，数据库实例中的其他属性值不能被复制

1NF

在每个关系模式$R$每个属性值都是不可再分的原子值；1NF是关系模式应具有的最起码条件；

换言之，1NF要求不存在表中之表；

2NF

在1NF的基础上，消除了部分依赖导致的冗余和操作异常，2NF是通往更高范式的中间步骤，它消除了1NF存在的部分问题,但仍可能出现冗余和异常；

如果关系模式$R\in 1NF$且每个非主属性完全依赖于候选码，称$R$满足2NF；

以下简单情况必定满足2NF

• R的码是单码
• R的码是全码
• R是二元关系

2NF分解算法：

1. 对于关系模式$R(U)$，主键为$W$，$R$上存在函数依赖$X\to Z$，其中$Z$是非主属性，$X\subset W$
   则$W\to Z$是部分依赖，进行分解

   • $R1(XZ)$,主键为$X$
   • $R2(U-Z)$，主键为$W$，外键为$X$

2. 若$R1,R2$仍然不是2NF，重复上述分解过程

3NF

若关系模式$R\in 1NF$，而且每个非主属性都不传递依赖于$R$的候选码，称$R$属于3NF；

定理：若$R$是3NF，必有$R$是2NF
证明：对于关系模式$R(U)$，主键为$W$，若存在部分依赖$W\to Z$,意味着R上存在函数依赖$X\to Z$，其中$Z$是非主属性，$X\subset W$，可以看成$W\to X, X\to Z$,这样特殊的传递依赖;

以下的简单情形必定满足3NF;

• 关系模式是全码；
• 所有二元关系；

3NF分解算法：

1. 对关系模式$R(U)$，主键为$W$，$R$上存在FD：$X\to Z$,其中$Z$非属性，$X$不是候选键, 说明$W\to Z$是传递依赖，进行如下分解

   • $R1(XZ)$，主键为$X$

   • $R2(U-Z)$，主键为$W$，外键为$X$

2. 若$R1,R2$不是3NF，继续进行如上分解

分解的原则应该从传递依赖链的尾部开始；

BCNF

BCNF，也称修正3NF，若关系模式R是1NF，而且每个属性都不传递依赖于R的候选码，那么称R是BCNF；

• 非主属性对每一个码都是完全函数依赖；
• 非主属性对不包含它的码也是完全函数依赖；
• 没有任何属性完全依赖于非码的任何一组属性；

关系为单码，并且已经是3NF，那么关系一定是BCNF；

BCNF分解算法

• 对于关系模式R，R上成立的函数依赖集F，找到最小依赖集$F_m$；
• 将最小依赖集中左部相同的FD用合并性合并，
• 对最小依赖集中的每个FD $X\to Y$构成模式$(XY)$
• 对于生成的模式集中，若每个模式不包含R的候选码，此时将候选码作为一个模式放入模式集中

不过这样的分解可能是有损的，违背了我们分解的初衷；

反范式

提高查询效率，采用空间换时间的实现思路；

• 存在频繁查询时，可以容忍适当的冗余设计，目的是减少多表关联 查询，提高效率
• 有些信息频繁变动，需要保存历史信息反范式化一定要适度，并且在原本已满足三范式的基础上再做调整的

数据库设计

数据库设计：根据用户需求研制数据库结构的过程

• 数据库结构设计：针对给定的应用环境，进行数据库的模式和子模式设计，包括概念设计，逻辑设计和物理设计，属于静态模型设计
• 数据库行为设计：确定数据库用户的行为和动作，属于动态模型设计

设计方法：直观设计，New orleans方法，基于实体-关系的方法，3NF设计方法，面向对象的方法（ODL），辅助软件CASE…

设计过程

• 需求分析：明确系统需要完成的任务
• 概念设计：将现实世界抽象地理解和表达
• 逻辑设计：概念模型转换具体的数据模型
• 物理设计:逻辑模型转化为确定的物理存储结构
• 实现阶段:进行数据库的构建工作，包括数据库的应 用程序开发和调试，数据的录入
• 运行和维护阶段:数据进行备份和维护，以保证数据库系统的效率

概念设计

概念模型：生成能准确反映用户组织和实用信息需求的抽象信息结构

• 真实充分地反映现实世界
• 易于理解更改和转换
• 描述概念模型最常用的工具：实体-关系模型；
• 易于转换成关系、网状、层次等各种数据模型

概念数据模型

• 面向用户、面向客观世界的模型
• 用来描述现实世界的概念化结构，与具体DBMS无关
• 概念数据模型必须转换成逻辑数据模型才能在DBMS中实现

E-R图

ER图是一种面向问题的概念模型，只关心现实世界的事物，特征和联系，用简单的图形方式描述显示世界的数据

1. 实体：用 矩形框 表示
2. 联系：一个或多个实体之间的关联关系，用菱形表示 ，用无向边连接
3. 属性：用椭圆表示，现实世界的事物尽量看作属性，属性不能有需要描述的性质，不能与其他实体具有联系；

数量关系表示

• 一对一联系：对于实体A中的每一个实体，实体B中至多有一个实体与之联系，反之亦然；
  • 完全一对一：$[1]\to [1]$,严格的对应关系；
  • 不完全一对一：$[0,1]\to [0,1]$
• 一对多联系：对于实体A中的每一个实体，实体B中有多个实体与之联系，对于实体B中的每一个实体，实体A中至多有一个实体与之联系；
• 多对多联系：对于实体A中的每一个实体，实体B中有多个实体与之联系，反之亦然

属性分类

• 简单属性/复合属性

• 单值属性/多值属性：多值属性用双椭圆表示，一般需要转化成弱实体，用双线矩形表示，其联系用双菱形框表示

• 派生属性：通过具有相互依赖的属性推导出来的属性称为派生属性，用虚线椭圆形与实体相连

• 空值属性

设计方法

1. 自顶向下：采用总分方式将大的概念模式逐步分解为更详细的较小划分模式
2. 逐步扩张：逐步扩张 采用了层状扩展的方式，先定义出用户需求中核心的概念结构，然后在此基础上向 外扩展，逐步将非核心的需求融入到模式中，最终完成系统的概念结构设计
3. 自底向上：首先构建起局部概念模式，然后再向上组合成全局模式
   数据抽象：对需求分析阶段收集到的数据进行分类、组织，确定实体，实体的属性和联系数量关系
   1. 分类：定义某一类概念作为现实世界的彝族对象的类型，抽象了对象值和型之间的语义
   2. 聚集：定义了某一类型的组成成分，抽象了对象内部类型和成分的语义
   3. 概括/继承：定义类型之间的某一子集联系，抽象了类型之间的语义

ER图绘制步骤

1. 选择局部应用

2. 逐一设计分ER图

3. 集成分图，进行合并和修改；

   • ：实体在不同层抽象成不同的类型，不同的ER图联系数量关系不同

逻辑设计

• 逻辑设计依赖于实现的DBMS基础
• 逻辑设计的任务是为了概念结构设计阶段生成的全局ER图转换成特定DBMS支持的数据模型

ER模式向关系模型的转换

• 实体联系和属性转换成关系的集合表示
• 实体-关系模式，实体属性-关系属性，关系的键-实体的键
• 联系相连的实体的键转换成关系模式的最佳实践：
  1. 1:1的联系：与任意一端的关系模式合并
  2. 1:n的联系：既可以独立，也可以和n端合并
  3. m:n的联系：转换成一个关系模式，需要识别外码
  4. 在ER图中，用下划线表示主码，波浪线表示外码

模式优化

用关系理论规范化理论对关系数据模型进行优化

• 确定范式的使用
• 实现规范化
• 反范式设计

物理设计

• 存储结构的设计：数据存放的位置，确定系统的配置
• 存取方法的设计：
  • 聚簇：节省存储空间，提高查询速度
  • 索引：提高检索速度，避免重复值的记录，保证数据完整性
  • 基于HASH：计算Hash值获得存取地址

关系代数理论

概述

域（Domain）：由属性构成，是属性的所有取值，一组具有相同数据类型的值的集合；

关系：是域作笛卡尔积后的，有一定意义的，有限的子集；

• 关系名，应该和其他关系不重名；
• 单元格包含一个原子值；
• 同一关系中属性不同名
• 统一属性的值取自相同的域；
• 不应该有重复原则；
• 属性的顺序并不重要；
• 元组的顺序一般也不重要；

关系是一张二维表，每一行对应一个元组，每个列对应一个属性域；

集合运算

关系和关系运算符组合的有意义的表达式；

一次一关系：

• 关系运算操作数：关系
• 关系运算结果：关系
• 这说明关系运算是一个闭包；

关系名

最简单的表达式：$R$(关系名，表示拷贝)

并

至少在两个关系出现一次的元组集合
$$
R\cup S = {t|t\in R \vee t\in S}
$$
相容性：

• 一般指有相同的数据结构（属性要同名）
• 广义上，对应属性来自相同的域，两个关系的属性数量相同；
• 语义一致

差

属于$R$但不属于$S$的元组集合
$$
R-S={t|t\in R \wedge t\notin S}
$$
差运算也要求相容性；

交

既属于$R$又属于$S$的元组集合
$$
R\cap S = {t|t\in R \wedge t\in S}
$$
注意交集可以用差集表示出来：
$$
R\cap S = R-(R-S)
$$

笛卡尔积

属性求全集的操作，关系是笛卡尔积的子集
$$
R \times S = {<t_r,t_s>|t_r\in R \wedge t_s\in S}
$$

选择

从关系中找出满足给定条件的所有元组称为选择

• 从行的角度进行的运算，即水平方向抽取元组
• 经过选择运算得到的结果可以形成新的关系，其关系模式不变，是原
  关系的一个子集

$$
\sigma_F(R)={t|t\in R,F(R)=true}
$$

垂直方向规模变小

投影

从关系中挑选若干属性组成的新的关系

• 从列的角度进行的运算，即垂直方向抽取元组
• 投影的结果中要去掉相同的行

$$
\Pi_A(R)={ t[A]|t\in R}, A \subseteq R
$$

水平方向规模变小；

投影的结果需要自动去重，因此垂直方向也有可能变少；

条件连接（$\theta$连接）

任何一个连接可以用笛卡尔积和选择关系来表示；

记$\theta$为比较运算符，$\theta$为等号时称为等值连接，$A,B$为$R,S$上度数相等且可比较的属性列：
$$
R \mathop{\bowtie} \limits_{A\theta B} S = { \widetilde{rs} | r\in R\wedge s\in S\wedge r[B]\theta s[B]}
$$
自然连接：从广义的笛卡尔积选取相同属性列$B$上取值相等的元组，去掉重复行：

• 自然连接中相等的分量必须时相同的属性组；
• 先计算笛卡尔积，选择同时出现在$R$和$S$中相等的元组，去掉所有重复属性；

自然连接和等值连接的区别：

• 自然连接是某种特殊的等值连接；
• 两个关系中进行比较的分量必须是相同的属性组；
• 结果重复列去掉；

外连接

左外连接

左外连接(left outer join):左外连接返回左表中的所有记录，以及右表中满足连接条件的记录。

如果右表中没有满足条件的记录，结果会包括左表中的记录，右表的对应字段值为 null
$$
R \ltimes _{\theta} S = (R \theta S) \cup (R \setminus \pi_R (R \theta S))
$$

右外连接

右外连接(right outer join):右外连接返回右表中的所有记录，以及左表中满足连接条件的记录。

如果左表中没有满足条件的记录，结果会包括右表中的记录，左表的对应字段值为 null
$$
R \rtimes_{\theta} S = (R \theta S) \cup (S \setminus \pi_S (R \theta S))
$$

全外连接

全外连接(full outer join):返回左表和右表中的所有记录，以及左右表中满足连接条件的记录。

如果左表或右表中没有满足条件的记录，结果会包括表中未匹配的记录，对应另一表的字段值为 NULL
$$
R \mathop⟗\limits_{\theta} S = (R \theta S) \cup (R \setminus \pi_R (R \theta S)) \cup (S \setminus \pi_S (R \theta S))
$$

重命名运算

对模式名和属性名重命名：
$$
\rho_{R(A_1,A_2,…,A_n)}E
$$
特殊的，对模式重命名和对属性名如下：
$$
\rho_{R}E，\rho_{(A_1,A_2,…,A_n)}E
$$
重命名运算符的作用：

1. 统一集合运算两端的关系模式
2. 自连接

除法

象集：给定关系$R(X,Y)$，$X,Y$为属性组，当$t[X]=x$时，$x$在$R$中的象集(Image Set)如下：
$$
Y_X={ t[Y]|t\in R, t[X]=x}
$$
象集表示$R$中属性组$X$上值为$x$的各个元组在$Y$分量上的集合；

除法：

给定关系$R(X,Y),S(Y,Z)$，其中

• $X,Y,Z$为属性组；

• $R,S$中$Y$出自相同的域；

• $P=R ÷ S$,其中$P$满足$R$中满足下列条件的元组在$X$上的 投影
  $$
  R÷ S= {t_r[X]=t_r\in R \wedge \Pi_Y(S)\subseteq Y_X}
  $$

查询优化

关系数据库管理系统首先将用户的 ＳＱＬ语句转换为等价的关系代数表达式，然后利用系统信息和上面介绍的运算律进
行优化；

若选择运算与广义笛卡儿积满足交换律，则选择运算应该尽可能最先执行，因为选择运算减少了数据，而笛卡儿积应尽可能后执行，因为广义笛卡儿积会产生大量的组合数据．

关系模式

关系数据模型

• 关系实例
  • 关系实例由命名的若干列和行的表
  • 行也称为元组
  • 元组的数目成为基数
  • 列一般需要命名
• 关系模式
  • 关系名R，属性列表U，域D，属性到域的映射DOM，属性约束F
  • 可以用五元组$R(U,D,DOM,F)$表示，也可以简单地用三元组$R(U,F)$，二元组$R(U)$表示；
  • 关系必须是规范化的
    • 1NF：关系的每个分量必须是不可分的（不允许表中有表）；
    • 2NF，3NF，BCNF：更高级的设计模式
• 优点：理论严格，线性结构简单，数据独立性，安全性和完整性；
• 缺点：对现实世界表达能力弱，存取对用户透明，查询效率不如NoSQL，只有固定的操作集，不能很好地支持商业规则；

关系数据库

关系数据库是 关系的有限集合；

• 数据库模式：关系模式的集合；
• 数据库实例：对应关系实例的集合；

关系：

• 关系是笛卡尔积的一个有意义的子集，有对应的关系名；

• 一个关系是一张 没有重复行，重复列 的二维表；

  • 实体本身的数据；
  • 实体之间的联系；

• 元组： 表中的一行，表示一个实体

  属性：表中的一列，有属性名

  域：属性的取值范围

  分量：元组中的属性值

以下是有关术语理论和实践不同的表述：

关系的三要素

1. 数据结构
2. 关系操作
3. 数据约束

数据结构

1. 键
   • 唯一区分不同元组的属性；
   • 又称关键字，码；
2. 候选键
   • 在关系中能唯一区分确定不同元组的属性；
   • 包括在候选键的属性称为主属性；
   • 不包括在候选键的属性称为非主属性；
3. 主键
   • 当多个候选键存在时，选定一个作为主键；
   • 每个关系中，主键是唯一的；
4. 外键
   • 在关系中并非键，但在另一个关系中的主键；

关系操作

关系的操作：集合操作，包括查询，投影，连接，除，并，交，差

数据约束

关系的完整性规则：对关系的某种约束条件，保证数据库值的数据的正确性和一致性；

• 实体完整性：主键非空；
• 参照完整性：外键要么为空值，要么来自于被参照关系表中的某个原则的主键值；
• 用户定义的完整性：各种商业规则

数据模式

模式(Schema)

• 数据库逻辑结构和特征的描述
• 反映的是数据结构及其联系
• 模式是相对稳定的

实例(Instance)

• 模式的一个具体值
• 反应数据库的某一时刻的状态
• 实例随数据的更新而变动
• 同一模式可以有很多实例

三级模式

模式

• 数据库中全体数据的逻辑结构和特征的描述,所有用户的公共数据视图，综合了所有用户的需求

• 数据在数据库内部的表示方式

  • 记录的存储方式（顺序，b树，hash）
  • 索引的组织方式
  • 数据是否压缩存储
  • 数据是否加密
  • 数据存储记录结构的规定

• 地位：一个数据库只有一个模式，是数据库系统模式结构的中间层

  • 与数据的物理存储细节与硬件环境无关
  • 与具体的应用程序，开发工具和高级语言无关

• 定义：数据库逻辑结构；

  • 数据项的名字，类型，取值范围；
  • 表结构的定义
  • 数据的联系，数据有关的安全性，完整性要求

• DBMS提供数据定义语言DDL来描述逻辑模式

外模式

• 数据库用户使用的局部数据的逻辑结构和特征的描述

  • 模式的子集，与某一应用的数据的逻辑表示
  • 不同用户的外模式可以不同
  • sql定义的视图

• 地位：介于模式和应用之间

• 模式与外模式：一对多，一个数据库可以有多个外模式，对模式中同一数据，在外模式中结构，类型，长度都可以不同

内模式

• 是数据物理结构和存储方式的描述
  • 一个数据库只有一个内模式
  • 是数据在数据库内部的表示方式
• 举例：存储方式，索引的组织方式，是否压缩存储，是否加密，数据存储记录结构的规定

模式/模式映射

• 定义外模式与模式之间的对应关系
• 每个外模式对应一个外模式/模式映射
• 保证数据的逻辑独立性，外部模式不受概念模式的变化影响；

模式/内模式映射

• 模式/内模式映射定义了数据全局逻辑结构与存储之间的对应关系
• 数据库中模式/内模式映射是唯一的
• 保证了数据的物理独立性

数据库体系结构

数据库架构

数据库架构的演变有两种趋势：

1. 单机架构–多机架构
2. 集中式–共享存储

单机架构

优点：部署简单，容易实现一致性；
缺点：拓展性差，系统故障导致数据丢失；

主备架构

优点：数据可靠性增强；
缺点：数据开销大，IO性能瓶颈；

主从架构

优点：IO性能提高
缺点：存储开销大，数据同步开销大

多主架构

优点：部署简单，容易实现事务一致性；
缺点：拓展性差，系统故障导致数据丢失；

Share-Nothing

优点：良好水平拓展，数据多副本存储，无需共享存储
缺点：计算和存储能力同时拓展灵活不足，分布式查询，分布式事务开销大；

Shared-Disk

优点：兼容性好，容易垂直拓展；
缺点：节点拓展能力受存储限制，及IO依赖共享存储设备；