数据库概述

数据库概述

一、背景

原本想直接进行Mysq的总结，然后简单整理后，发现还是需要进行一个上层抽象概述的。
数据库概述，不仅仅针对Mysql，而是面向所有数据库的一种概述性论述。
广义的数据库包括sqlLite、SqlServer、Oracle，甚至Redis、HDFS等。

---

原本想好好打磨打磨，但是由于最近组织关系调整，暂时无心整理这个。所以，先放出来啦。对部分细节感兴趣的小伙伴，可以私聊或者艾特我。

二、架构

数据库有多种划分方式，其中最出名的，也是大家接触最多的，是ANSI/ SPARC 数据库系统研究组 在1975年提出的三层划分法。又被成为 ANSI-SPARC Architecture。

自我拆解&汇总

1.模式

上述结构图，将数据库拆分为三层。而这三层分别对应者不同的模式、视图（我更喜欢称之为视角）、数据库级别。
模式和数据库级别，谈论起来比较偏向概念，这里不再深入。这里结合实际，谈谈视图。

a.内部视图

这个内部，是针对系统而言的。
内部视图，主要是针对系统内部，关注点在于物理文件。不过，在实际落地时，DBMS往往关注点在逻辑层面的系统文件。其更多是通过系统API，对系统抽象出的文件资源进行操作。

b.DBA视图

DBA视图，很明显是针对各位数据库的DBA们。关注点在数据库的基础表。
这里的基础表，是指我们在履行DBA职责时（实际开发时，开发者往往会作为DBA创建新表等）创建的Table。
这里谈一下我的认识，分布式数据库（如分库分表）下的物理表，也归属于基础表。但分布式数据库下的逻辑表，并不归属于基础表。原因，后面谈。

c.用户视图

用户视图，则是针对后端应用。关注点在于视图View。
如果严格按照规范来说，现在绝大多数情况下，咱们都是没有这一层的。就拿Mysql来说，大部分开发都是直连数据库基本表，而不会创建一个聚合的视图View，来进行访问&连接。之所以抛弃视图View，原因就类似于网络OSI架构，落地后成为TCP五层架构（层次架构的优缺点）。

而在分布式数据库情况下，我认为其逻辑表，完全可以等同于规范中的用户视图层。因为核心是一致的，都是基于基础表的虚表，可以有效随着业务需求进行变化。当然，比起规范中的用户视图，还是缺少数据聚合的能力、权限控制等能力，但这个其实是可以扩展&实现。

2.映射

多个层次的结构，带来视角的不同。而视角的不同，则意味着不同层次对同一事物的观察角度不同。
那么在不同层次间，则需要一个转化与映射。
举个例子，外模式（用户视图）的用户信息视图View，是概念模式（DBA视图）的用户基础表&地址基础表聚合而来。而概念模式（DBA视图）的用户基础表&地址基础表聚合，在内模式（内部视图）其实是两个不同的文件（逻辑/物理）。虽然在不同模式中，这是三个不同的东西。但究其本质，三者是同一个东西。

a.概念模式-内模式

概念模式-内模式映射，主要是针对内部视图-DBA视图。关注点在于基本表与系统文件的映射。
举个例子，在Mysql中，这个映射则是由各大存储引擎负责，如InnoDB、MyIsam等。
这个部分，也决定了具体DBMS的性能。具体实现，我会在后续的InnoDB引擎部分，进行具体的阐述。

b.外模式-概念模式

外模式-概念模式，主要是针对用户视图-DBA视图。关注点在于视图View与基本表的映射。
举个例子，Mysql中的视图View。但实际情况下，大家都是对mysql的基础表进行操作的。
而分布式数据库中，尤其是Proxy类型中，个人理解这个映射就是后端应用与Mysql中间的DB-Proxy。如Mycat、TDDL等。
至于类似shardingJDBC这样的分布式数据库实现，个人接触不多，所以对它的定位思考还不够，这里就不误导大家了。

3.小结

上述例子，大多是基于Mysql的。既然Redis、HDFS也归属于广义的数据库。那么，Redis、HDFS应当也是符合上述定义的。
这里以Redis为例，Redis同样有着分片等集群方式，以及实际内存文件，这就有了三层模式与两层映射的基础。前者是外模式-概念模式的映射，后者是概念模式-内模式的映射。当然这里可能没有DBA，但也有着Redis对应的运维管理人员，这个角色常常有开发者担任。

数据库概述，在概念上，是位于Mysql、SqlLite、Redis、HDFS上的一个抽象定义。这个抽象定义，使得我们有效把握这些数据库实现的表现骨架。其一方面可以帮助我们更好地把握现有数据库实现，另一方面可以帮助我们更好认识这些数据库实现的差异与方向。
前者比较好理解，这里就后者举个例子。我们可以通过知识迁移，思考Mycat这样的db-proxy的方向。比如是否可以添加数据聚合、权限等能力。另外，mysql的物化视图，是否可以借鉴到Mycat上。Redis是否可以构建类似Mycat这样的proxy，怎么构建。

这样一说，顿时感觉这样更高一层的抽象概念实在有点厉害。毕竟“降维打击”可是更高抽象的重要作用。而最为重要的是，这样的认识是一种更高层次的认识。更高层次的认识，往往更接近底层，更加纯粹，也更加稳定。
当然，光有抽象理论，那也是无法带来直接价值的。所以需要我们从理论中，来到实践，最后再走回理论。从而避免泛泛而谈。

三、数据模型

1.基础（结构）数据模型

a.概述

DBMS的分类方式有很多种，而其中最重要的是数据模型。目前主流采用的数据模型，依旧是关系型数据模型。不过近些年，大量NoSql的出现，也使得键值型数据模型、面向对象型数据模型更多市场应用。
分类：

• 层次型数据模型
• 关系型数据模型
• 网状数据模型
• 键值型数据模型
• 面向对象型数据模型
• 等等

基本数据模型是按照计算机系统的观点来对数据和信息建模，主要用于 DBMS 的实现。
基本数据模型是数据库系统的核心和基础。基本数据模型通常由数据结构、数据操作和完整

PS：有关不同数据模型的简介，可见系统架构师教程（第四版）-3.2.2数据模型。

b.组成

基础数据模型的组成：

• 数据结构
• 数据操作
• 完整性约束

部分组成。其中数据结构是对系统静态特性的描述，数据操作是对系统动态特性的
描述，完整性约束是一组完整性规则的集合。

这里简单举例，解释一下完整性约束。如关系型DBMS的主键非空要求，就是完整性约束规则之一。文章后续，会有更为完善的阐述。

2.概念数据模型

a.概述

概念数据模型是按照用户的观点来对数据和信息建模，主要用于数据库设计。概念模型
主要用实体联系方法（Entity Relationship Approach）表示，所以也称ER模型。

实体-关系模型（ER模型）：Entity-Relation模型

b.ER图

ER图由属性、实体、联系组成。

属性是实体具备的特性，如姓名、联系电话等。
实体是概念上可以区分的事物，如部门、公司、商品等。
联系是实体间的关联关系，如属于（集合间关系）、下单（业务关系）等。

c.模型转换

虽然ER模型，很好地刻画了系统持久化数据的实体（包含核心属性）&联系，但经常是无法直接通过ER图进行数据库表设计的。
举个例子，

转换方式

• 属性：转换时，每个属性就是一个字段
• 实体：每个实体都单独转换为一个关系模式
• 联系
  • 1:1联系：与任意端实体，进行合并
  • 1:n联系
    • 可转单独的关系模式
    • 可与N端实体合并（N端实体添加联系的主键）
  • m:n联系：必须转换为单独的关系模式

转换流程

• 消除冗余

关系模式

关系模型用表格结构表达实体集，用外键表示实体间的联系。其优点有：
1）建立在严格的数学概念基础上
2）概念（关系）单一，结构简单、清晰，用户易懂易用
3）存取路径对用户透明，从而数据独立性、安全性好，简化数据库开发工作。

PS：注意ER模型的转换 -> 进行关系模式的推导

3.构建过程

1. 需求分析
2. 抽象数据
3. 设计局部E-R模型
4. 合并局部模型，消除冲突
5. 重构优化，消除冗余
6. 逻辑设计

其中，2～5称为概念结构设计
集成方法：

• 多个局部E-R图一次集
• 用累加的方式一次集成两个局部E-R

集成产生的冲突，以及解决办法：

• 属性冲突：包括属性域冲突和属性取值冲突
• 命名冲突：包括同名异义和异名同义
• 结构冲突：包括同一对象在不同应用中具有不同的抽象，以及同一实体在不同局部E-R图中所包含的属性签名（属性个数&排序）不完全相同

四、关系代数

关系代数，分为并、交、差、笛卡尔积、投影、选择、连接、除八种。
详见关系代数运算，这里不再赘述。

五、规范化理论

1.价值

非规范化可能导致的问题：

• 数据冗余
• 更新异常
• 插入异常
• 删除异常

2.函数依赖

关系模式：R(A, B, C)

a.部分（函数）依赖

A -> C，AB -> C

C可以有AB推导，也可以由AB的子集A推导，这就表示存在部分依赖。
如果先弄清楚，最好是参照《架构师教程》进行画图。

这里，为了表达的简洁，我直接使用推导，而不是依赖关系的表达。

b.传递（函数）依赖

A -> B，B -> C
A可以推导出B，B可以推导出C，也就意味着A可以推导出C。这就表示存在传递依赖。

3.键

关键键 -> 超键 -> 候选键 -> 主键 -> 外键

4.范式

a.第一范式

第一范式（1NF）是指数据库表的每一列(即每个属性)都是不可分割的基本数据项，同一列中不能有多个值，即实体中的某个属性不能有多个值或者不能有重复的属性。简而言之，第一范式就是无重复的列。

一个关系模式R的所有属性都是不可分的基本数据项。

b.第二范式

第二范式（2NF）是在第一范式（1NF）的基础上建立起来的，即满足第二范式（2NF）必须先满足第一范式（1NF）。第二范式（2NF）要求数据库表中的每个实例或行必须可以被唯一地区分。

满足第一范式，然后消除部分依赖。

c.第三范式

满足第三范式（3NF）必须先满足第二范式（2NF）。在满足第二范式的基础上，切不存在传递函数依赖，那么就是第三范式。

满足第二范式，消除传递依赖。

d.BC范式

BCNF 在第三范式的基础上，数据库表中如果不存在任何字段对任一候选关键字段的传递函数依赖则符合第三范式。

（1）所有非主属性对每一个码都是完全函数依赖；
（2）所有的主属性对于每一个不包含它的码，也是完全函数依赖；
（3）没有任何属性完全函数依赖于非码的任意一个组合。

e.反规范化

虽然违反范式，但是可以带来性能等优势

• 增加派生性冗余列：生日 -> 年龄
• 增加冗余列：学号 -> 姓名
• 重新组表
• 分割表：逻辑表下的物理表是按照字段进行分割的

f.无损分解

为了进行冗余的消除等，我们常常需要对关系模式进行分解。
而如果分解过程中，不存在依赖关系对丢失，则称为无损分解。

PS：简单说，分解后对关系模式，可以倒推回原有的关系模式。

六、并发控制

1.基本概念

（图：）

2.存在的问题

• 更新丢失
• 不可重复度
• 幻读（读”脏“数据）

3.封锁协议

• 一级封锁协议
• 二级封锁协议
• 三级封锁协议
• 二段锁协议

共享锁（读锁-S锁）
排他锁（写锁-X锁）

七、应用

1.常见DBMS

mysql

2.非常规DBMS

Redis

3.分布式数据库

（图：）

分布透明性

• 分片透明性
• 位置透明性
• 局部数据模型透明性

分布式DBMS-组成

• LDBMS
• GDBMS
• 全局数据字典
• 通信管理（CM）

数据库分区（分库&分表）

4.大数据

b.联邦数据库

支持异构数据的联合

c.数据仓库

d.数据挖掘

5.Nosql、内存数据库、图数据库、对象数据库等

八、完整性约束

1.设计完整性约束

• 实体完整性约束（主键的唯一性&非空性）
• 参照完整性约束（外键：要能查到）
• 自定义完整性约束性（自定义年龄：0-150）

2.安全完整性约束

• 用户标识&鉴定
• 存取控制
• 密码存储&传输
• 视图的保护
• 审计：日志&分析

3.数据备份

分类：

• 冷&热
  • 冷备份
  • 热备份
• 备份数据
  • 完全备份
  • 差量备份
  • 增量备份
  • 余量备份
• 日志文件（机制：先写日志，再操作数据库）

常见备份规划
如一周：全、增、增、差、增、差、增

4.数据库故障&恢复

可以预先避免，也可以通过冗余等方式避免单点问题。

• 事务本身的可预期故障（本身逻辑）：rollback
• 事务本身的不可预期故障（违反存储保护）：DBMS的恢复模块（日志，进行修改）
• 系统故障（系统停止运转）：使用检查点法
• 介质故障（外存被破坏）：通过日志，重做业务

最后，愿与诸君共进步。

九、附录

1.参考资料

• 系统架构设计师
• 系统分析师
• 个人笔记
• [数据库] 第一范式、第二范式、第三范式、BC范式