数据库原理及应用期末复习

有志者，事竟成。

第一章数据库系统概述

数据库基本概念

数据：数据是数据库中存储的基本对象，可以定义为：描述事物的符号记录。

数据库：长期存储在计算机内的、有组织的、可共享的大量数据集合。

数据库管理系统：位于用户与操作系统之间的一层数据管理软件。

作用：它能科学地组织和存储数据，高效地获取和维护数据。
功能：
- 数据定义
- 数据操纵
- 数据库的运行管理
- 数据库的建立与维护

数据库系统：在计算机系统中引入数据库后的系统，是由软件和硬件组成的完整系统。

特点：
- 数据结构化
- 数据冗余度低，实现了数据共享
- 数据独立性高
- 数据由DBMS统一管理和控制

数据模型

graph TB
	a(现实世界)-->b(信息世界)
	b --> c(计算机世界)
	f(问题) --> d(概念模型)
	d --> e(数据模型)

概念模型相关术语：

实体：客观存在的、可以相互区别的事物或概念。
- 实体转换规则
  - 一个实体型转化为一个关系模式
  - 实体的属性就是关系的属性
  - 实体的码就是关系的码
属性：实体所具有的某一个特性。
码：能够唯一标识实体的属性集。
域：属性的取值范围。
同型实体：具有相同属性的实体。
实体型：用实体名及其属性名的集合来抽象和刻画同型实体。
实体集：属于同一个实体型的实体集合。
联系：包括实体内部的联系与实体之间的联系。

概念模型的组成要素：

数据结构: 对系统静态特征的描述。关系结构的数据模型是关系模型。
数据操作：对系统动态行为的描述。数据库主要有检索和更新两大类操作。
完整性约束条件：描述数据结构内数据语法、语义联系、他们之间的制约与依存关系，以及数据动态变化的规则。

概念模型的特点：

能真实、充分地反映现实世界;
易于理解;
易于更改;
易于向关系、网状、层次等各种数据模型转换。

常用数据模型：

层次模型
网状模型
关系模型

数据库三级模式：

数据库系统体系结构从数据库管理系统角度看数据库系统内部的模式结构，通常用三级模式结构：外模式、模式、内模式。

外模式：又称子模式或用户模式，是模式的子集，是数据的局部逻辑结构，也是数据库用户看到的数据视图。一个数据库可以有多个外模式。应用程序都和外模式打交道。
模式：又称逻辑模式或概念模式，它是数据库中全体数据的全局逻辑结构和特征的描述，也是所有用户的公共数据视图。模式实际上是数据库数据在逻辑级上的视图，一个数据库只有一个模式。
内模式：又称存储模式，是数据在数据库中的内部表示，即数据的物理结构和存储方式的描述。一个数据库只有一个内模式。

数据库二级映像

为了在内部实现数据库的三个抽象层次的联系和转换而生

外模式/模式
- 模式描述数据的全局逻辑结构，外模式描述数据的局部逻辑结构，同一个模式可以任意多个外模式
- 对于每一个外模式，数据库系统都有一个外模式/模式映像
- 当模式改变时，数据库管理员对各个外模式/模式映像做出相应改变，以保持外模式不变。应用程序是依据数据的外模式编写的，从而应用程序库不必修改，保证了数据与程序的逻辑独立性
模式/内模式
- 数据库中只有一个模式，也只有一个内模式，所以模式/内模式映像是唯一的
- 定义了数据库的全局逻辑结构与存储结构之间的对应关系
- 当数据库的存储结构改变时，由数据库管理员对模式/内模式映像做出相应改变，以使模式保持不变，使得外模式不变，从而应用程序也不必修改，保证了数据与程序的物理独立性
功能和作用：保证数据库系统中的数据能够有较高的逻辑独立性和物理独立性

数据库系统的外部体系结构

单用户结构的数据库系统
分布式结构的数据库系统
客户机/服务器结构的数据库系统
浏览器/服务器结构的数据库系统

第二章关系数据库

关系数据结构

关系：数据之间的逻辑连接，用于描述数据实体之间的相互关系

域：一组具有相同数据类型的值的集合，就是表的一列的取值范围
笛卡尔积： $D_1 = \{1,2,3\}$ $D_2 = \{A,B\}$
- 二者笛卡尔积为 $D_1\times D_2 = \{(1,A),(1,B),(2,A),(2,B),(3,A),(3,B)\}$
关系：笛卡尔中有实际意义的元组构成关系（一张二维表）
候选码：能唯一标识关系中一个元组的某一属性组（可能不止一个）
主属性：候选码的诸属性称为主属性
非主属性：不存在与任何候选码中的属性称为非主属性
全码：关系模式的所有属性是这个关系模式的候选码，称为全码
性质
- 关系中的属性值不可分解（原子性）
- 表中各列取自同一个域
- 不同属性给予不同属性名
- 行列次序可以交换
- 表中的行叫元组，即一个实体，表中不能有完全相同的两行

关系模式：关系数据库中的数据结构，它定义了表的结构和属性

关系模式是型，关系是值，关系模式是对关系的描述

关系数据库：是一种基于关系模型的数据库。它使用表和列来组织和存储数据

关系数据库操作：

常用关系操作
- 查询操作：选择、投影、连接、除、并、差、交、笛卡尔积，选择、投影、并、差、笛卡尔积是5中基本操作
- 数据更新：插入、删除、修改
关系操作特点
- 集合操作方式

完整性约束：

实体完整性：若属性A是基本关系R的主属性，则A不能取空值（对主码的约束）
- 保证了实体的可区分性
- 保证了实体的唯一性
参照完整性：外码只能取空值或目标关系存在的值（对外码的约束）
- 定义外码与主码之间的引用规则
用户定义的完整性：针对某一具体应用环境，给出关系数据库的约束条件。这些约束条件反应某一具体应用所涉及的数据必须满足的语义要求

关系运算

关系运算符

##第三章 SQL语言

特点：

一体化
高度非过程化
语言简洁
多种使用方式

数据库定义：CREATE DATABASE 数据库名

数据库维护：ALTER DATABASE 数据库名

表定义：CREATE TABLE 表名(属性名数据类型属性约束条件, …,表约束条件)

常用数据类型：varchar(n), text , date, int , bigint, float …

###完整性约束定义

作用范围：列级约束，元组约束，关系约束
实体完整性
- NOT NULL 约束：该约束确保列中的每个值都不为空。
  
  例如，将 ‘customers’ 表中的 ‘customer_name’ 列设为 NOT NULL 约束：
  1
  ALTER TABLE customers MODIFY customer_name VARCHAR(50) NOT NULL;
- UNIQUE 约束：该约束确保列或一组列中的每个值都是唯一的，即不能重复。
  
  例如，将 ‘customers’ 表中的 ‘email’ 列设为 UNIQUE 约束：
  1
  ALTER TABLE customers ADD CONSTRAINT unique_email UNIQUE (email);
- PRIMARY KEY 约束：该约束确保列或一组列中的每个值都是唯一的，并用于唯一标识表中的每个记录。
  
  例如，在一个新表中创建一个名为 ‘orders’ 的主键约束：
  1
  2
  3
  4
  5
  CREATE TABLE orders (
  order_id INT PRIMARY KEY,
  customer_id INT,
  order_date DATE
  );
参照完整性
- FOREIGN KEY 约束：该约束确保列或一组列中的值与另一个表中的值相匹配。这是关联两个表的常用方法。
  
  例如，在 ‘orders’ 表中添加一个指向 ‘customers’ 表的 ‘customer_id’ 列的外键约束
  1
  2
  ALTER TABLE orders ADD CONSTRAINT fk_orders_customer_id
  FOREIGN KEY (customer_id) REFERENCES customers(customer_id);
- 违反参照完整性的处理方式：拒绝、联级删除（修改）、设置为空值，默认是拒绝
用户定义完整性
- CHECK 约束：该约束确保列中的每个值都满足特定条件。
  
  例如，在 ‘employees’ 表中添加一个 CHECK 约束，以确保 ‘salary’ 列中的值大于等于 50000：
  1
  ALTER TABLE employees ADD CONSTRAINT check_salary CHECK (salary >= 50000);
- DEFAULT 约束：该约束指定在未提供值时使用的默认值。
  
  例如，在 ‘orders’ 表中为 ‘order_date’ 列添加一个 DEFAULT 约束，以便在未提供值时使用当前日期：
  1
  ALTER TABLE orders MODIFY order_date DATE DEFAULT CURRENT_DATE;
INDEX 约束：该约束创建一个索引，以提高对该列的检索效率。

例如，在 ‘products’ 表中为 ‘product_name’ 列添加一个索引：
1
CREATE INDEX idx_product_name ON products (product_name);
…

###索引

优点：可以加快查询速度
缺点：本身会占用用户数据库空间，会增加维护索引的时间成本
种类
- 聚集索引：数据库表中的数据按照索引关键字的顺序存储。一张表只能有一个聚集索引
- 非聚集索引：表的物理顺序和索引关键字顺序不同。一张表可以有多个非聚集索引
- 唯一索引：索引关键字不允许重复。`聚集索引和非聚集索引都可以是唯一索引
建立索引

在SQL中创建索引的常规语法如下：
1
2
CREATE INDEX index_name
ON table_name (column1 ASC, column2 DESC, ...);
其中：
- index_name 是所创建的索引的名称，在同一表中索引名称必须唯一。
- table_name 是数据表的名称。
- (column1, column2, ...) 是包含一个或多个列的索引列列表。
注意事项：
- 索引应该尽可能放在用于筛选、排序和连接（JOIN）数据的列上。
- 索引可能会影响插入、更新和删除操作的性能，因此应该只在需要索引的列上创建索引。
- 过多的索引可能会影响查询性能，因此应该仅在必要的列上创建索引。

###数据查询：自己多写写SQL语句，增删改查

单表查询
多表查询
子查询
集合查询
基于派生表查询
使用TOP选择结果集元组

###数据更改

插入数据（insert）
修改数据（update）
删除数据（delete）

###视图

##第四章 Transact-SQL

不要求

##第五章数据库管理与维护

###安全性管理

###并发控制

事务
- 概念：由用户定义的一系列数据操作语句构成，这些操作语句要么全部执行、要么都不执行。事务是数据库运行的最小的、不可分割的工作单位。
- 特性（ACID）
  - 原子性（Atomicity）：指事务中的操作不可分割，要么全部执行成功，要么全部回滚，保证数据的一致性。原子性是事务概念本质的体现和基本要求
  - 一致性（Consistency）：事务执行完成后，数据库中的数据必须全部更新，确保事务执行后使数据库从一个一致性状态变成另一个一致性状态，此时数据库中的数据具备正确性和完整性。当数据库只包含事务成功提交的结果，说明数据库处于一致性状态。如果不一致要进行回滚
  - 隔离性（Isolation）：指并发执行的事务之间是隔离的，每个事务对于其他事务的操作是不可见的，避免了数据的冲突。
  - 持久性（Durability）：指事务一旦提交，对数据库中数据的改变是永久的，即使系统崩溃或者重启，也不会丢失。
- SQL Server 的事务处理模型
  - 显式事务：事务有显式的开始和结束标志
  - 隐式事务：每条数据操作语句都自动成为一个事务
并发
- 事务的串行执行：一个事务完成后，再执行另一个事务
- 事务的并发执行：DBMS同时接收多个事务，这些事务在时间上重叠执行
  - 好处：并发执行可以提高系统资源利用率，改善短事务的响应时间
  - 坏处：并发执行可能会破坏事务的ACID特性
- 并发操作导致的问题（破坏了事务的隔离性导致以下问题）
  - 丢失更新：当两个或两个以上的事务选择同一数据值，在更新最初的读取值时，会发生丢失更新的问题
  - 读“脏”数据：指一个事务读取了另一个事务失败运行过程中的数据
  - 不可重复读：一个事务在执行过程中多次读取同一行数据时，由于其他事务对该行数据进行了更改，则每次读取的结果都不同。
并发控制
- 概念：使用某种方法来执行并发操作，使得一个事务的执行不受其他事务的干扰，避免造成数据的不一致
- 方法
  - 排他锁（X锁）（写锁）：并发事务对数据进行访问，其他事务不能读取或更新锁定的数据。X锁采用的方法是：禁止并发操作
  - 共享锁（S锁）（读锁）：允许事务并发读取数据。其他事务可以读取锁定的数据，但是不能再释放锁之间进行修改数据操作
  - 加锁的真正目的：防止更新操作对数据一致性的破坏
  锁的兼容性：（事务T1加了某个锁，T2还能不能加某个锁）
  
  T2\T1 排他锁（X锁）共享锁（S锁） –没有锁
  
  排他锁（X锁）否否是
  
  共享锁（S锁）否是是
  
  –没有锁是是是

T2\T1	排他锁（X锁）	共享锁（S锁）	–没有锁
排他锁（X锁）	否	否	是
共享锁（S锁）	否	是	是
–没有锁	是	是	是

SQL Server的封锁技术

封锁协议

一级封锁协议
- 定义：事务T在修改数据对象之前必须先对其加上排他锁（X锁），直到事务结束（正常or非正常）释放锁
- 好处：防止丢失数据更新问题
- 不足：不能保证可重复读和读“脏”数据
二级封锁协议
- 定义：在一级封锁协议的基础上，加上事务T要读取数据之前，必须先对其加上共享锁（S锁），读取完毕立即释放S锁
- 好处：可以防止数据丢失更新问题，还可以防止读“脏”数据
- 不足：不能保证可重复读数据
三级封锁协议
- 定义：在一级封锁协议的基础上，加上事务T读取数据之前须先对其加上共享锁（S锁），读取完后不释放S锁，而是等到事务T结束才释放
- 好处：可以防止丢失更新和不读“脏”数据，防止不可重复读

三个封锁协议都规定对数据对象的更新必须加X锁，区别在于读取操作是否需要申请加锁，何时释放锁

封锁协议	排他锁（X锁）	共享锁（S锁）	不丢失更新	不读脏数据	可重复读
一级封锁协议	必须加锁，事务结束释放	不加锁	是
二级封锁协议	必须加锁，事务结束释放	加锁，读完立即释放	是	是
三级封锁协议	必须加锁，事务结束释放	加锁，事务结束释放	是	是	是

死锁和活锁
- 活锁
  - 定义：当两个或多个事务请求对同一个数据进行封锁时，可能会存在某个事务处于永远等待锁的情况
  - 解决方法：采用先来先服务的策略
- 死锁
  - 定义：在同时处于等待状态的两个或多个事务中，其中每一个事务都在等待其他事务释放锁后才能继续执行，即多个事务彼此相互等待
  - 解决方法
    - 采取一定的措施来避免死锁的发生
    - 允许死锁的发生，但是采取一定的手段定期诊断系统中是否有死锁，有则解除它
  - 预防方法
    - 一次性封锁法：每个事务必须一次性对用得到的数据全部加锁，否则不能执行
    - 顺序封锁法：按照预先约定的封锁顺序进行封锁
  - 死锁的诊断与解除
    - 超时法：设置时限，事务等待时间超时则解除死锁
    - 事务等待图法：看有向图有没有回路
并发调度的可串行性
- 定义：多个事务的并发执行是正确的，当且仅当结果与按照某一顺序串行执行的结果相同时，称这种调度策略为可串行化的调度
- 可串行性是并发事务正确调度的准则
两段锁协议（保证调度的可串行化）
- 定义：事务必须分为两个阶段对数据对象进行加锁和解锁
- 两个方面的内容：
  - 对任何数据进行读写操作前，要先申请并获得对数据的封锁
  - 释放一个封锁后，事务不再申请和获得对该数据的封锁
- 两个阶段
  - 第一阶段：申请封锁，事务可以申请获得任何数据对象上的任何类型的锁，但不允许释放任何锁
  - 第二阶段：释放封锁，事务可以释放任何数据对象上的任何类型的锁，但不允许申请任何锁
- 事务遵循两段锁协议是可串行化调度的充分条件，不是必要条件

数据备份
- 备份类型
  - 完全备份（完全数据库备份）：备份整个数据库，包括所有数据对象和事务日志
    - 操作简便，便于使用。但是随着数据库规模增大，会花费更多的时间和空间
  - 差分备份（增量备份）：仅备份自上次完全备份依赖对数据进行修改的内容
    - 相比完全备份速度更快，空间更节省，简化了数据库备份操作，减少了丢失数据的可能性，减少还原频繁修改数据库的时间，适用于修改频繁的数据
  - 事务日志备份：对事务日志进行备份，备份时复制自上次备份依赖对数据库所做的改变
    - 用户可以使用事务日志备份将数据库恢复到特定的即时点或故障点
  - 文件或文件组备份
数据恢复
- 事务故障：事务在运行到正常终止点前被中止
  - 解决方法：利用事务操作的日志文件撤销该事务对数据库进行的修改
- 系统故障
  - 未完成事务对数据库的更新已经写入数据库
    - 解决方法：强行撤销所有未完成的事务并清除事务对数据库的修改
  - 已提交事务对数据库的更新可能还留在缓冲区，没来得及写入磁盘上的物理数据库
    - 解决方法：将事务提交的更新结果重新写入数据库
- 介质故障
  - 发生介质故障后，磁盘上的物理数据和日志文件被破坏，可能造成数据无法恢复
  - 解决方法：重装数据库，然后重做已完成的事务

第六章关系数据库

关系：实质上是一张二维表。表的每一行叫做一个元组，每一列叫做一个属性

关系模式：就是这个元组集合的结构上的描述

关系模式的形式化定义 $R(U,D,DOM,F)$ R:关系名，U：组成该关系的属性集合，D：属性组U中属性所来自的域，DOM：属性向域的映像集合，F：属性间数据的依赖关系集合

关系数据库：以关系模型为基础的数据库

数据依赖：函数依赖、多值依赖

只考虑函数依赖存在的问题：
- 数据冗余
- 更新异常
  - 插入异常
  - 更新异常
  - 删除异常

函数依赖：一个或多个属性的取值决定了另一个属性的取值

eg: 假设我们有一个关系R（A，B，C），其中A是主键。如果我们知道A的值，那么B和C的值就可以唯一确定。因此，我们可以说存在函数依赖A -> B，A -> C。

完全函数依赖（Fully functional dependency）：关系模式R（U）中，如果 $X\rightarrow Y$ ,并且对于X的任何一个真子集 $X'$ ，都有 $X’ \nrightarrow Y$ ，则称Y完全函数依赖于X
部分函数依赖（Partial functional dependency）：若 $X \rightarrow Y$ ，但Y不完全函数依赖于X，则称Y部分函数依赖于X
传递函数依赖（Transitive functional dependency）：关系模式R（U），如果 $X\rightarrow Y,Y\rightarrow Z$ ，且 $Y\nsubseteq X,Y\rightarrow X$ ，则称Z传递函数依赖于X

主码：设 K 为 R ( U , F )中的属性或属性集合，若U完全函数依赖于K，则K为R的候选码。若候选码多于一个，则选定其中一个为主码

候选码可以唯一地识别关系的元组
一个关系模式可能具有多个候选码，可以指定一个为识别关系元组的主码
包含在任意一个候选码中的属性叫做主属性，反之叫非主属性或非码属性
最简单的情况下，候选码只包含一个属性
最复杂的情况下，候选码包含关系模式的所有属性，称为全码

外码：关系模式R中属性或属性组X并非R的码，但X是另一个关系模式的码，则称X是R的外部码，简称外码

###范式

满足不同程度要求的关系等级称为范式 ||| 现在把范式理解成符合某一种级别的关系模式的集合，R为第几范式可以写成 $R\in nNF$
各范式联系： $5NF\subset 4NF\subset BCNF\subset 3NF\subset 2NF\subset 1NF$
规范化：一个低一级范式的关系模式，通过模式分解可以转换为若干个高一级范式的关系模式的集合，这种过程称为规范化（简单化、单一化、减少出现更新异常）
几种范式
- 第一范式（1NF）：一个关系模式R的所有属性都是不可分的基本数据项，记作 $R\in 1NF$
- 第二范式（2NF）： $R\in1NF$ ，且每一个非主属性都完全函数依赖于码，记作 $R\in 2NF$
- 第三范式（3NF）： $R\in2NF$ $R \in 2 NF$ ，且R中每一个非主属性都不传递函数依赖于R的候选码，记作 $R\in3NF$ $R \in 3 NF$
  - 没有限制主属性对码的依赖关系
  - 如果R只包含两个属性，则R一定属于第三范式
- BC范式（BCNF）：关系模式是1NF，如果对于R的每一个函数依赖 $X\rightarrow Y$ $X \to Y$ ,若Y不属于X时X必含有候选码，记作 $R\in BCNF$ $R \in BCNF$
  - 特性
    - 所有非主属性对每一个码都是完全函数依赖
    - 所有主属性对每一个不包含它的码也是完全函数依赖
    - 没有任何属性完全函数依赖于非码的任何一组属性
- 第四范式（4NF）：关系模式 $R(U,F)\in 1NF$ ，如果对于R的每一个非平凡多值依赖 $X\rightarrow \rightarrow Y(Y\nsubseteq X)$ ，X都含有候选码

关系模式的规范化过程：

1687487451489

第七章数据库设计

###数据库设计的方法

直观设计法（手工试凑法）
规范设计法
- 新奥尔良方法
- 基于E-R模型的方法
- 基于3NF的方法
计算机辅助设计法

###数据库设计的特点

数据库设计是涉及多学科的综合技术
数据库设计是软件、硬件和干件的结合
数据库设计具有反复性、试探性，应分步进行
数据库设计需要将结构设计和行为设计密切结合

`数据库设计的步骤`

需求分析阶段
- 重点是数据和业务处理，业务处理的对象是数据，业务处理也会产生数据
- 数据字典：各类数据描述的集合，包括：数据项、数据结构、数据流、数据存储、处理过程
概念结构设计阶段
- 概念模型特点
  - 能够充分真实地反应现实世界
  - 易于被人们理解
  - 易于更改
  - 易于向关系、网状、层次等各种数据模型转换
- 概念模型的E-R表示方法
  - 实体关系：一对一（1：1），一对多（1：n），多对多（m：n）
  - E-R规则
    - 实体：矩形表示，框内写实体名
    - 属性: 椭圆表示，用无向边将其与对应的实体连起来
    - 联系：菱形表示，写明关系名，用无向边将其与对应的实体连起来，并标上联系类型（1:1,1:n，m:n）
- 概念结构设计的方法
  - 自顶向下方法
  - 自低向上方法
  - 逐步扩张方法
  - 混合策略方法
- 数据抽象和局部视图设计
  - 选择局部应用
  - 设计分E-R图
- 视图集成
  - 合并分E-R图，生成初步的E-R图
    - 属性冲突（讨论协商）
    - 命名冲突（讨论协商）
    - 结构冲突（根据应用语义对实体联系的类型进行综合或调整）
  - 修改重构，生成基本E-R图
  - 评审
逻辑结构设计阶段
- 概念模型向关系模型转换
  - 一个实体转换成一个关系模式，实体的属性就是关系的属性，实体的码就是关系的码
  - 一个1:1的联系可以转换成一个独立的关系模式，也可以与任意一端的关系模式合并
  - 一个1：n的联系可以转换为一个独立的关系模式，也可以与n端对应的关系模式合并
  - 一个m：n的联系转换为一个独立的关系模式(只能独立)，与该联系相连的各实体的码以及联系本身的属性均转换为关系的属性，各实体的码共同组成该关系模式的码
  - 三个或三个以上的实体间的一个多元联系可以转换为一个关系模式，与该联系相连的各实体的码和联系本身的属性均转换为该关系的属性，关系的码为各实体的码的组合
  - 具有相同码的关系模式可以合并
- 关系模型优化
  - 确定数据依赖
  - 对数据依赖进行极小化处理
  - 确定关系模式属于第几范式
  - 根据需求分析要求，分析这些模式是否合适
  - 对关系模式进行必要的合并和分解
- 用户子模式设计
物理结构设计阶段
- 确定数据库的物理结构
  - 存储记录的结构设计
  - 确定数据的存放位置
  - 存取方法的设计
  - 确定系统配置
- 评价物理结构
- 撰写物理设计说明书和相关文档
数据库的实施
- 定义数据库结构
- 组织数据入库
- 应用程序的调试
- 数据库试运行
数据库的运行与维护阶段
- 数据库的转储和恢复
- 维护数据库的安全性和完整性
- 检测并改善数据库性能
- 数据库的重组织和重构造

数据库原理及应用期末复习

一个很闲的vegetable

数据库原理及应用期末复习

第一章数据库系统概述

数据库基本概念

数据模型

第二章关系数据库

第六章关系数据库

第七章数据库设计

`数据库设计的步骤`

其他文章

数据库原理及应用期末复习

一个很闲的vegetable

数据库原理及应用期末复习

第一章 数据库系统概述

数据库基本概念

数据模型

第二章 关系数据库

第六章 关系数据库

第七章 数据库设计

数据库设计的步骤

其他文章

第一章数据库系统概述

第二章关系数据库

第六章关系数据库

第七章数据库设计

`数据库设计的步骤`