尝试在软考66天前开始成为软件设计师-数据库系统
三级模式-两级映射
层次型架构设计 ---便利,应变能力↗
- 外模式 (用户与数据库系统的接口 视图
- 概念模式 (数据库中全体数据的逻辑结构和特征
- 内模式 (数据物理结构和存储方式
外模式/模式映像。
该映像存在于外部级和概念级之间，实现了外模式到概念模式之间的相互转换。（逻辑独立性）
模式/内模式映像。
该映像存在于概念级和内部级之间，实现了概念模式到内模式之间的相互转换。（物理独立性）
数据库设计
需求分析
产出:数据流图,数据字典,需求说明书
概念结构设计
产出:ER模型 看数据实体-联系
逻辑结构设计
转换规则,规范化理论-->关系模式
物理设计
ER模型
实体,属性,联系
通常从局部开始 集成为一个ER图
集成时产生的冲突:
- 属性冲突: 属性域冲突&属性取值冲突
- 命名冲突:同名异义&异名同义。
- 结构冲突:同一对象在不同应用中具有不同的抽象，同一实体在不同ER图中属性个数和属性排列次序不完全相同
ER图转换为关系模式
一个实体转成一个关系模式
1:1 联系可以随任意一方
1:n 记录在多的一方 (部门:员工|1:n|记录在员工
n:n 联系单独记录成一个关系模式
关系代数
投影看列
选择看行(
向下看列,
向右看行
连接操作,一般下面写条件
规范化理论
函数依赖
类似于y=ax Y函数依赖于X,X函数决定Y
学号-->姓名 姓名(同名)确定不了学号
部分函数依赖 为例 (学号,课程号)-->姓名
主键一个部分就能确定属性
传递函数依赖同理
价值与应用
非规范化的关系模式，可能存在的问题包括:数据冗余、更新异常、插入异常、删除异常
键
- 超键 (唯一标识元组)
- 候选键 (不存在冗余,唯一标识元组)
(学号,姓名,性别) 学号-->性别 (学号,姓名)-->性别 都是超键
但 (学号,姓名)不能为候选键,有学号在内冗余
- 主键 (候选键任意一个)
- 外键 部门有作外键--职员
求候选键
关系模式画成图形(有向图)
寻找入度为0的属性(A1只有一条出度), 能遍历整图便是候选键 例一A
例二 (ABCD)组合键
例三 如果没有入度为0的结点, 找能到其他结点的 A和B
范式
规范化程度越高,数据密度越小弊端
- 1NF
属性值都是不可分的原子值
- 2NF
消除非主属性对候选键的部分依赖
- 3NF (实际)
消除了非主属性对候选键的传递依赖
- BCNF
消除了主属性对候选键的传递依赖
1NF
只包含原子值
不满足,高级职称人数可以再分
2NF
每一个非主属性完全依赖主键 (不存在部分依赖)
例: 学号,课程号,课程分,学分
课程号 -->学分 部分依赖 (学号,课程号)-->课程分
解决方案:分离出一个新的
3NF
没有非主属性传递依赖于码
DNAME 和LOCATION 冗余
DNO,DNAME,LOCATION组成新
BC范式
每个依赖决定因素 必定包含某个候选键
模式分解
保持函数依赖分解
分解后依赖依然存在 ,不保持冗余的函数依赖
例: A->B->C 分解成 A->B , B->C 保持函数依赖
而分解 A->B , A->C 就没有保持
无损分解
有损不能还原,无损可以还原
无损联接分解:指将一个关系模式分解成若干个关系模式后，通过自然联接和投影等运算仍能还原到原来的关系模式
并发控制
事务--e.g.: 银行转账,要求转账到账一致进行
存在问题
- 丢失更新
- 不可重复读
本用来演算,但演算过程中数被改
- "脏"数据
不应该读成70
封锁协议
X锁 写锁; S锁读锁
排他锁（Exclusive Locks，简称X锁）共享锁（Share Locks，简称S锁）
- 一级封锁协议
事务T在修改数据R之前必须先对其加X锁，直到事务结束才释放. 防丢失修改
- 二级封锁协议
一级协议+读取数据之前加S锁,读完释放 防丢失修改+防脏数据
- 三级封锁协议
二级+结束才释放S锁 防丢失修改+防脏数据+防重复读
- 两段锁协议
可串行,可产生死锁
封锁协议就可能产生死锁
数据库完整性约束
实体完整性约束
约束主键
参照完整性约束
约束外键,填入外键时 必须根据那个主键
用户自定义完整性
完整性确保数据正确
触发器 可以写脚本 保证复杂的完整性
数据库安全
- 用户标识
- 存取控制(用户授权)
- 密码存储&传输
- 视图保护 (操作哪些区域)
- 审计 (记录操作,事后处理)
数据备份
冷备份
静态备份,将数据库关闭,进行备份 ,速度快,复杂度低
热备份
动态备份,使用备份软件,正常运行时进行备份, 不能出错
- 完全备份 (全部
- 差量备份 (上次"完全备份"之后变化的数据
- 增量备份 (上次备份之后变化的数据
增量备份,需要之前完全备份恢复完后,再次才能恢复备份内容 麻烦
- 静态海量转储 全部
- 静态增量转储 上次转储后更新过的数据
- 动态海量转储
- 动态增量转储
日志文件
反规范化
由于规范化会使表不断的拆分,从而导致数据表过多。
虽然减少了数据冗余，提高了增、删、改的速度,但会增加查询的工作量。系统需要进行多次连接,才能进行查询操作,使得系统效率大大下降
技术手段以下
- 增加派生性冗余列
- 增加冗余列
- 重新组表
- 分割表
例如 :数量*单价 可以加上一个总价 --> 空间换时间