数据库复习笔记汇总
数据库复习1——基本概念
数据库复习2——数据模型
数据库复习3——关系模型
数据库复习4——数据库设计
数据库复习5——数据库基本原理
数据库复习6——事务处理
数据库模式
- 数据库系统的三级模式结构是指数据库系统是由外模式、模式、内模式三级构成；
- 数据与程序之间的独立性，使得数据的定义和描述可以从应用中分离出去。
模式
模式也称逻辑模式，是数据库中
全体数据的逻辑结构和特征的描述，是所有用户的公共数据视图。
- 定义模式时不仅要定义数据的
逻辑结构，还要定义数据之间的联系，定义数据有关的安全性、完整性要求。
外模式
也称子模式或用户模式，它是数据库用户能够看见和使用的
局部数据的逻辑结构和特征的描述，是数据库用户的数据视图，是与某一应用有关的数据的逻辑表示。
- 一个数据库可以有多个外模式；
- 同一外模式可以为某一用户的多个应用使用；
- 一个应用程序只能使用一个外模式；
内模式
也称存储模式，它是
数据物理结构和存储方式的描述，是数据在数据库内部的表示方式。
- 一个数据库只有一个内模式
外模式/模式映象
- 每一个外模式，都有一个外模式/模式映像，这些映像通常包含在外模式的描述中；
- 模式改变时，只需改变外模式/模式映像，使得外模式保持不变，进而保证应用程序不用改变；
- 保证了数据与程序的逻辑独立性，简称数据的逻辑独立性；
模式/内模式映象
- 内模式唯一，因此模式/内模式映像唯一，定义了数据全局逻辑结构与存储结构的对应关系，通常包含在模式的描述中；
- 内模式改变时，只需改变模式/内模式映像，使得模式保持不变，进而保证应用程序不用改变；
- 保证了数据与程序的物理独立性，简称数据的物理独立性；
范式
1NF
如果一个关系模式R的所有属性都是不可分的基本数据项则R属于第一范式
第一范式是对关系模式的最起码的要求，不满足则不能成为关系数据库。
2NF
若R属于第一范式，且每个非主属性都完全函数依赖于码则R属于第二范式，即每一行被码唯一标识。
3NF
若R每个非主属性都不传递依赖于R的码则属于第三范式。即第三范式要求一个数据库表中不能包含其他表中已包含的非码信息。
BCNF
关系模式R<U,F>属于第一范式，若X→Y 且Y→X时X必含有码，即每个属性都不传递依赖于R的码，则R属于BC范式。等价于每一个决定因素都包含码，即消除任何属性对码的部分和传递函数依赖。
结论：
- 所有非主属性对每一个码都是完全函数依赖。
- 所有主属性对每一个不包含它的码也是完全函数依赖。
- 没有任何属性完全函数依赖于非码的任何一组属性。
- 属于BCNF一定属于3NF，反之则不一定。
简单理解：若A能推出B，且B不在A的内部，则A必包含码，如能找到反例则不属于BCNF。
简称：每个决定因素都含有码
- R属于BC范式是R属于第三范式的充分不必要条件；
- 若R属于第三范式，且R只有一个候选码，则R属于BC范式是R属于第三范式的充要条件。
多值依赖
R(U)是属性集U上的关系模式，XYZ是U的子集，并且Z=U-X-Y。关心模式R(U)中多值依赖X→→Y成立，当且仅当对R(U)的任意关系r，给定的一对(x,z)值，有一组Y的值，这组值仅仅决定于x的值而与z的值无关。
若X→→Y，而Z为空，则X→→Y为平凡的多值依赖。
- 增广律：如果X→→Y，V包含于W包含于U，则WX→→VY。
- 传递律：如果X→→Y，Y→→Z，则X→→Z-Y
- 补余律：如果X→→Y，则X→→U-X-Y
4NF
4NF，关系模式的属性之间不允许有非平凡且非函数依赖的多值依赖。如果属于第四范式，则必属于BC范式。
- 任意二元关系一定是4NF
总结
| 规范化 | 步骤 |
|---|---|
| 1NF到2NF | 消除非主属性对码的部分函数依赖 |
| 2NF到3NF | 消除非主属性对码的传递函数依赖 |
| 3NF到BCNF | 消除主属性对码的部分和传递函数依赖 |
| BCNF到4NF | 消除非平凡且非函数依赖的多值依赖 |
模式分解
- 分解具有无损连接性
- 分解要保持函数依赖
- 分解纪要保持函数依赖，又要具有无损连接性
以上三个定义是实行分解的三个不同准则，不同的分解准则，模式所能达到的分离程度不同，各种范式就是对分离程度的测度。
无损连接判断：
无损连接定理
关系模式R(U，F)的一个分解，ρ={R1<U1,F1>,R2<U2,F2>}具有无损连接的充分必要条件是：
U1∩U2→U1-U2 €F+ 或U1∩U2→U2 -U1€F+
数据库设计步骤
- 需求分析
- 概念结构设计
- 逻辑结构设计
- 物理结构设计
- 数据库实施
- 数据库运行维护
需求分析
对应系统的整个应用情况作全面的详细的调查，确定用户的目标和需求，并把要求写成用户和数据库设计者都能够接受的文档。
输入：信息需求、处理需求、安全性和完整性需求
输出：需求说明书
- 数据字典：是对系统中数据的详尽描述，提供对数据库数据描述的集中管理。包含数据项、数据结构、数据流、数据存储和加工过程。
概念结构设计
反应企业组织信息需求的数据库概念结构。独立于数据库逻辑结构，独立于DBMS，不依赖于计算机系统。
ER图
描述现实世界关系概念模型的有效方法,完成对系统中数据部分设计。
ER图三要素:
- 实体：实体可以时具体的人、事、物，也可以是抽象的概念或联系。用矩形表示。
- 属性：实体所具有的某一特征，用椭圆形表示，并用无向边将其与相应的实体连接起来。属性不可再分，不可与其他实体有联系。
- 联系：实体内部或实体间的关联，用菱形表示，用无向边连接相应实体，并在无向边旁边表明联系的类型(1:1,1:n,n:m)。
E-R图扩展
IAS联系
- 父类实体与子类实体之间的联系称为
ISA联系，用三角形表示。例如：研究生 is a 学生。 - 分类属性：三角形旁边可以标明
分类属性，分类属性的值表示该父实体型被分派到的子实体型中。 - 不相交约束与可重叠约束：若父类实体不能同时属于多个子类中的实体集，则称为
不相交约束，否则称为可重叠约束,其中不相交约束在三角形内画一个X。 - 完备性约束：若父类实体必须为某一个子类实体则称为
完全特化用父类子类用双线连接,否则为部分特化用单线连接。
基数约束
是1:1、1:n、n:m的细化，用
min..max表示。
- 0≤min≤max,例如0…1，1…3，1…* (*表示无穷大)。
- 当min=1时，约束称为强制参与约束，即实体型每个实体都要参与；min=0则为非强制参与约束，可以不在联系中。
例1:班级与学生，一个学生必须加入一个班级且只能加入一个班级，一个班级可以容纳30到40名学生。因此在学生一端的联系上标 30…40 ，在班级的一端的联系上标 1…1。
独占联系
- 依赖其他实体存在的实体称为
弱实体用双矩形表示，反之则为强实体，强实体与弱实体之间的联系称为独占联系(Part-of)用双菱形表示。 - 弱实体一般没有作为码的属性。
例1：一次贷款可以有多次还款，显然"还款"实体依赖于"贷款"实体存在。
例2：楼房包含多个房间，房间有房间号，但是房间号不能区别在哪个楼房，因此房间依赖楼房存在。
大型项目一般采取自底向上的方法，先设计子系统的分E-R图，然后进行合并成最终的E-R图。
E-R图的冲突
合并过程一般会出现三类冲突：属性冲突、命名冲突、结构冲突。
- 属性冲突
- 属性域冲突：例如数据类型、取值范围
- 属性单位冲突：例如市斤、公斤
- 命名冲突
- 同名异义
- 异名同义
- 结构冲突
- 同一对象在不同应用中具有不同的抽象
例如：职工在局部为实体，在别处为属性。一般将统一对象变成同一抽象（都为实体或都为属性） - 同一实体在不同子E-R图中的属性个数、排列方式不一致
取同一实体的不同部分属性取并集，并统一排列方式即可。 - 实体间的联系在不同的E-R图中未不同类型
例如：产品和零件有构成关系，产品、零件和供应商有供应关系，两个子图合并时因为"构成"和"供应"两个联系不能相包含，因此将其综合起来，两个关系同时存在。
消除E-R图冗余
在合并之后，消除冗余的数据和实体间冗余的联系。冗余的数据是可由基本数据导出的数据。冗余联系是指可由其他联系导出的联系。
逻辑结构设计
把概念结构中的ER图转换成具体DBMS所支持的数据模式相符合的逻辑结构。（包括数据库模式、外模式）
步骤：
- E-R图向关系模式的转换
- 数据模型的优化
不是规范化越高的的关系越优，适当的冗余可以提高查询效率。 - 设计用户子模式
使用符合用户习惯的别名、针对不同级别的用户定义视图、简化用户多系统的使用。
物理结构设计
对给定的逻辑数据模型选取一个合适的物理结构。主要指物理设备上的存储结构和存取方法。
数据库存储结构：
一般基于存取时间、存储空间利用率、维护代价三方面权衡。
存放位置：
- 稳定部分和易变部分分开存放
- 数据大表、数据和索引、日志文件和数据库对象存在多个不同的磁盘阵列，并行存取，提高效率
关系模式存取方法的选择：
索引法（B+树、Hash）、聚簇(clustering)
B+树索引法
一般条件：
- 一个(组)属性经常在查询条件中出现，考虑在该属性上建立(组合)索引
- 一个属性经常作为最大值和最小值等聚集函数的参数，考虑建立索引
- 一个(组)属性经常在连接操作的连接条件中出现，考虑建立索引
注意：
若一个关系更新频率很高，则要花费大量时间更新索引，因此不适合建立太多索引
Hash索引法
一般条件:
- 一个关系的大小可预知，且不变。
- 关系的大小动态改变，但数据库管理系统提供了动态hash存储方法。
聚簇
为提高某个属性(组)的查询速度，将这些属性上具有相同值的元组存在连续的物理块中称为聚簇。该属性(组)称为
聚簇码(cluster key)
聚簇的优点
- 在数据库系统中，I/O操作的时间开销很大，而聚簇大大降低了I/O操作
- 聚簇也适用于多个常用于连接的关系，即把多个连接关系的元组按连接属性值聚簇存放，相当于
预连接。 - 一个数据库可以有多个聚簇，一个关系只能加入一个聚簇。
聚簇的缺点
- 聚簇建立维护开销很大，需要与优点权衡
- 对已有关系建立聚簇，会移动数据的物理地址，即原索引全部失效，需要重新建立索引
- 聚簇码值修改会导致数据物理地址移动
聚簇的选择要求
- 经常进行连接操作的关系
- 关系中的一组属性经常出现在相等比较中
- 关系的个或一组属性上的值重复率很高。即聚簇码值平均元组数不能太少。
- SQL语句经常出现
ORDER BY、GROUP BY、UNION、DISTINCT等子句。 - 不经常进行全表扫描
- 连接操作多于更新操作
- 一个表只能加入一个聚簇，如果有一个表符合多个，则选择最优的
约束的使用
实体完整性
关系模型中的实体完整性在create table 中用primary key定义（对单属性构成的码可以定义为列级约束条件，也可以定义为表级约束条件，而对于多个属性构成的码只有一种说明方法，即定义为表级约束条件）。
检查与违约处理：
- 检查主码是否唯一，如果不唯一则拒绝插入或修改。
- 检查主码的各个属性是否为空，只要有一个为空就拒绝插入或修改。
参照整性
关系模型的参照完整性在create table中使用foreign key短语定义哪些列为外码，用reference短语指明这些外码参照哪些表的主码。
参照表与参照表的违约处理：
| 被参照表 | 参照表 | 违约处理 |
|---|---|---|
| 可能破坏参照完整性 | 插入元组 | 拒绝 |
| 可能破坏参照完整性 | 修改外码值 | 拒绝 |
| 删除元组 | 可能破坏参照完整性 | 拒绝/级联删除/设置为空 |
| 修改主码 | 可能破坏参照完整性 | 拒绝/级联删除/设置为空 |
用户定义完整性
用户定义完整性就是针对某一具体应用的数据必须满足的语义要求。
- 属性上的约束条件
- 列值非空（
NOT NULL） - 列值唯一（
UNIQUE） - 列值是否满足条件表达式（
CHECK）
- 列值非空（
- 元组上的约束条件
在create table语句中可以使用check定义元组上的约束条件。例如check (sex = '女' or name not like 'Ms.%')，即男性姓名不以Ms.开头
总结
| 完整性类型 | 约束类型 | 说明 |
|---|---|---|
| 实体完整性 | PRIMARY KEY | 唯一标识每一行，保证用户不输入重复的数据，且创建一个索引来提高性能，不允许空值 |
| 实体完整性 | UNIQUE | 防止非主键关键字的重复，并保证创建一个索引来提高性能，允许空值（最多一个） |
| 用户定义完整性 | DEFAULT | 指定在INSERT语句中没有明确提供一个值时，为该列提供的值 |
| 用户定义完整性 | CHECK | 指定在一个列中可接受的数据值 |
| 参照完整性 | FOREIGN KEY | 定义一个列或几个列的组合，他们的值匹配同一个表或另一个表中的关键字 |
例题
1. 关系模式R(商店编号、商品编号、数量、部门编号、负责人)，规定，每个商店的每种商品只在一个部门销售；每个商店的每个部门只有一个负责人；每个商店的每个商品只有一个数量；求函数依赖关系和分解成3NF模式集；
依赖关系：
(商店编号,商品编号) -> 数量；
(商店编号,商品编号) -> 部门编号；
(商店编号,部门编号) -> 负责人；
分解：
每个商店的每种商品只在一个部门销售同时只有一个数量，因此得到R1
R1(商店编号,商品编号,部门编号,数量)
每个商店的每个部门只有一个负责人，因此得到R2
R2(商店编号,部门编号,负责人)
2. 试述数据库设计过程中形成的数据库模式
- 在概念结构设计阶段，独立于DBMS绘制E-R图，形成概念模式
- 在逻辑结构设计阶段，E-R图转成数据库支持的数据模型、创建视图，形成外模式
- 在物理结构设计阶段，规划存取策略、建立索引，形成内模式
2200
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
