03 - 数据库技术
1 数据库体系结构
1.1 三级模式
- 视图
视图时保存在数据库中的SELECT查询,其内容由查询定义,因此,视图不是真实存在的表,而是一个或者多个导出的虚拟表。
内模式:管理如何存储物理的数据,对应具体物理文件。
概念模式:通常使用的基本表,根据应用、需求将物理数据划分成一张张表。
外模式:对应数据库中的视图这个级别,将表进行一定处理后再提供给用户使用。
1.2 两级映像
逻辑独立性:外模式和概念模式之间的映射。表和视图之间的映射,应用程序与数据库的逻辑结构独立,当数据的逻辑结构改变时,应用程序不变。
物理独立性:概念模式和内模式之间的映射,是表和数据的物理存储之间的映射,应用程序与磁盘中的数据相互独立。当数据的物理存储改变时,应用程序不变。
2 数据库设计
2.1 需求分析
分析数据的存储要求,产出物有数据流图、数据字典、需求说明书。获得用户对系统的三个要求:信息要求、处理要求、系统要求。
2.2 概念结构设计
就是设计E-R图,也叫实体-联系图。
2.2.1 属性冲突
局部ER图转换成全局ER图时,需要消除冲突,冲突类型有:
2.3 逻辑结构设计
其任务是将概念模型转换成关系模型,ER图向关系模式转换规则:
- ER图的实体转换为关系
- ER的属性转换为关系的属性
- ER图的关键字转换为关系的关键字
2.3.1 复合属性
- 将每个分量属性作为复合属性所在实体的属性
- 将复合属性本身作为所在实体的属性
2.3.2 多值属性
- 将多值属性与所在实体的主键一起组成一个新的关系
- 将多值属性提升为一个实体,通常为弱实体
2.3.3 派生属性
派生属性是可由其他属性计算得到,在转化成关系模式时,通常不转换派生属性。例如:“学生”实体中有“生日”和“年龄”等属性,从“生日”可以计算出“年龄”属性的值,“年龄”属性就是派生属性。
2.4 物理设计
包括确定数据分布、存储结构和访问方式。
3 数据模型
数据模型包括:概念数据模型(实体–联系模型)和基本数据模型
概念数据模型:是按照用户的观点来对数据和信息建模,主要用于数据库设计。也称 ER模型
基本数据模型:按照计算机系统的观点来对数据和信息建模,主要用DBMS实现。常用的基本数据模型有 层次模型、网状模型、关系模型和面向对象模型。
3.1 概念数据模型
用ER图来表示,在ER模型中,椭圆标识属性、长方形标识实体、菱形标识联系,联系的两端要填写联系类型。
3.2 基本数据模型
网状模型:表示实体类型及其实体之间的联系,一个事物和另外几个都有联系,形成一张网。
面向对象模型:采用面向对象的方法设计数据库,以对象为单位,每个对象包括属性和方法,具有类和继承等特点。
3.3 数据的约束条件
数据模型三要素:数据结构、数据操作、数据的约束条件
3.3.1 完整性约束
实体完整性:指实体的主属性不能取空值。
参照完整性:指外键参照的完整性。若A关系中的某个或者某些属性参照B或其他几个关系中的属性,那么在关系A中该属性要么为空,要么必须出现B或者其他的关系的对应属性中。
用户定义完整性:反映某一个具体应用所对应的数据必须满足一定的约束条件。
4 关系代数运算
4.1 关系型数据库常见名词
4.2 关系代数运算
4.2.1 选择
针对行
4.2.2 投影
取关系R中符合条件的列,组成新的关系
4.2.3 笛卡尔积
4.2.4 自然连接
等值连接:关系R、S,取两者笛卡尔积中属性值相等的元组进行连接
自然连接:一种特殊的等值连接,要求比较的属性列必须是相等的属性组,并且把结果中重复属性去掉。
4.2.5 外连接
5 关系数据库的规范化
5.1 函数依赖
5.1.1 常见名词
超键:能唯一标识此表的属性的组合
候选键:超键去掉冗余属性,剩余的属性就是候选键
主键:任选一个候选键,可作为主键
主属性:候选键内的属性为主属性,其他属性为非主属性
5.1.2 函数依赖
给定一个X,能唯一确定一个Y,就称 X 确定 Y,或者说 Y 依赖于 X。
部分函数依赖:A 可以确定 C,(A,B)也可确定C,(A,B)中的一部分可以确定C,称为部分函数依赖
传递函数依赖:当A和B不等价时,A可确定B,B可确定C,则A可确定C
5.1.3 Armstrong公理
5.2 规范化
5.2.1 第一范式(1NF)
关系模式R的每个分量不可再分。如下图,不属于第一范式:
5.2.2 第二范式(2NF)
每个非主属性完全依赖主键。
5.2.3 第三范式(3NF)
在满足1NF的基础上,表中不存在非主属性对码的传递依赖
5.2.4 BC范式
在 3NF的基础上,进一步消除主属性对码的部分函数依赖和传递依赖。
5.3 模式分解
保持函数依赖:对于关系模式R,有依赖集F,若对R进行分解,分解出来的多个关系模式,保持原来的依赖集不变,则为保持函数依赖的分解。
保持函数依赖的判断:
6 数据库的控制
6.1 事务管理
6.2 并发控制
不可重复读、丢失更新、读脏数据
为处理并发控制,主要采用封锁协议
- 排他锁(简称X封锁,写锁):如果事务 T 对数据A进行了X封锁 ,则只允许事务 T 读取和修改数据A,其他事务要等事务T解除X封锁以后,才能对数据A实现任何类型的封锁。
- 共享锁(简称 S封锁,读锁)允许并发读,但不允许修改
6.3 备份
6.4 故障恢复
6.4.1 事务故障恢复
指事务未运行到正常终止点前被撤销,这时恢复子系统应对此事务做撤销处理。由系统自动完成,不需要用户干预。
- 反向扫描日志文件,查找该事务的更新操作。
- 对该事务的更新操作执行逆操作
- 继续反向扫描日志文件,查找该事务的其他更新操作,并做同样处理
- 如此处理下去,直至读到此事务的开始标记,事务故障恢复完成
6.4.2 系统故障的恢复
系统故障发生时,造成数据库不一致状态的原因有两个:
- 一是由于一些未完成的事务对数据库的更新已写入数据库
- 二是由于一些已提交事务对数据库的更新还留在缓冲区没来得及写入数据库
系统故障的恢复是在重新启动时自动完成,不需要用户干预:
- 正向扫描日志文件:找出在故障发生前已经提交的事务,将其事务标识记入重做(Redo)队列。同时找出故障发生时尚未完成的事务,将其事务标识计入撤销(Undo)队列
- 对撤销队列中每个事务进行撤销处理:正向扫描日志文件,对每个Undo事务的更新操作执行逆操作
- 对重做队列中的各个事务进行重做处理:正向扫描日志文件,对每个Redo事务重新执行日志文件登记的操作
7 分布式数据库
7.1 分布式数据库体系结构
分布模式:分布式数据库的本质特性就是数据分布在不同的物理位置,分布模式主要职责是定义数据分段
7.2 分布式数据库特点
共享性:不同的结点数据共享
自治性:每个结点对本地数据都能独立管理
可用性:某一场地故障时,可以使用其他场地上的副本而不至于使整个系统瘫痪
分布性:数据分布在不同场地上存储
7.3 分布透明性
分片透明性:不需要知道逻辑上访问的表具体如何分块存储的
位置透明性:不必了解片段的存储场地
逻辑透明性:无需知道局部使用的是那种数据模型
复制透明性:不关心复制的数据从何而来
8 数据仓库技术
数据仓库是一个面向主题的、集成的、非易失的、且随时间变化的数据集合,用于支持管理决策。
面向主题:按照一定的主题域进行组织
集成的:数据仓库中的数据是在对原有分散的数据库数据抽取、清理的基础上经过系统加工、汇总和整理得到的,必须消除源数据中的不一致性,以保证数据仓库内的信息关于整个企业的一致全局信息。
相对稳定的:数据仓库的数据主要供企业决策分析之用,所涉及的数据操作主要是数据查询,一旦某个数据进入数据仓库后,一般情况下将被长期保留,数据仓库中一般由大量的查询操作,但修改和删除操作很少,通常只需要定期的加载、刷新
反应历史变化:通常包含历史信息,可以对企业的发展历程和未来趋势做出定量分析和预测。
数据仓库的结构通常包含四个层次,如下图所示:
- 数据源
- 数据的存储与管理
- OLAP(联机分析处理)服务器
- 前端工具
BI系统主要包括 数据预处理、建立数据仓库、数据分析和数据展现四个主要阶段。
9 NoSQL数据库
9.1 关系型数据库的缺点
- 不满足高并发读写需求
- 不满足海量数据的高效率读写
- 不满足扩展性和可用性
9.2 CAP理论
9.3 BASE理论
9.4 NoSQL数据库与SQL数据库比较
9.5 NoSQL数据库分类
9.5.1 键值数据库
9.5.2 列族数据库
9.5.3 文档数据库
9.5.4 图形数据库
10 数据库优化技术
10.1 集中式数据库优化技术
10.1.1 反规范化设计
10.2 分布式数据库优化技术
10.2.1 主从复制
binlog有三种模式
- 基于SQL语句的复制,每一条更新的语句都会记录在binlog中
- 基于行的复制:不记录SQL语句,只记录那个记录更新前和更新后的数据,可以保证主从之间数据绝对相同,缺点是:1条SQL更新1000行的数据无法再偷懒,必须原原本本同步1000行的数据量
- 混合复制:以上两种模式的混合
主数据库可以通过binlog复制的方式,同步给多个从库,甚至从库又和一个数据库组件主从关系。
10.2.2 读写分离
让主数据库负责写操作,从数据库负责读操作,通过角色分担的策略,分别提升读写性能,有效减少数据并发操作的延迟。
10.2.3 分库分表
分表
分库
是将原本存放在一个实例上众多分类的数据表,分别存放到不同的实例上,有利于差异化管理
在实现分库分表的同时,要解决使用的透明度,不能让应用代码了解到分库分表的复杂度,造成两者之间耦合性太强。因此数据访问中间件是很好的解决方案。
10.3 分布式缓存技术
10.3.1 过期策略
惰性删除:查询key的时候才对key进行检测,如果已经到达过期时间,则删除,缺点是,如果过期的key没有被访问,则一直无法删除,占用内存
定期删除:redis每隔一段时间对数据库做一次检查,删除里面的过期key,由于不可能对所有key去做轮询来删除,所以redis会每次随机取一些去做检查和删除
10.3.2 持久化
10.3.3 常见问题
缓存穿透:访问大量不存在的key,可能原因:
1. 恶意攻击,解决方法:限制访问次数,使用布隆过滤器,验证key的合法性,提前拒绝不合法的请求
2. 业务刚上线:解决方案:预热redis;在前端进行流量控制,逐步释放请求进来,如果数据库里没有的key,要在redis中设置key为null
缓存雪崩:大量key同时失效,可能的原因
1. redis故障:出现故障,进行服务降级,熔断、限流等措施
2. key采用了相同的过期时间:为key设置随机过期时间
缓存击穿:少量热点key,缓存失效,可能原因:设置时间太短
1. 对特点key可以设置永久有效,如:秒杀场景下的库存数量。
2. 使用分布式锁:如果热点key失效了,可以只允许一个请求去访问数据库,去除最新key,存放到redi
10.3.4 主从复制、切片
- 主从复制集群
- 哨兵集群
- cluster集群
进行分片,可以有如下分片技术: