Oracle数据库设计与SQL优化.ppt

数据库设计与SQL优化 清华大学计算中心 课程安排 第一章 数据库设计的基本概念 第二章 规范的数据库设计 第三章 SQL优化的基本概念 第四章 基本的SQL优化 第五章 高级SQL优化 第一章 数据库设计的基本概念 数据库设计的目的 空间上的目标 消除冗余数据 占用较小的存储空间 安全上的目标 消除数据间的不一致性。 保护数据的完整性 时间上的目标 高效的数据访问 数据库设计的基本概念 数据库设计和程序设计的关系 一个软件系统包括两方面的问题 数据 对数据进行处理 需求分析阶段 分析用户的数据要求 分析用户的功能要求 设计阶段 设计数据的结构 设计程序模块的结构； 编程阶段 要考虑数据和算法等 数据库设计的基本概念 数据库设计的4个阶段： 分析用户要求 收集和分析用户的要求，包括数据要求、加工要求和种种限制条件等 建立概念性数据模型 用一个“概念性数据模型”将用户的数据要求明确地表达出来 逻辑设计 设计数据的结构 物理设计 设计数据模式的一些物理细节 基本概念 逻辑设计的步骤 确定数据元素 规范化数据表 建立数据表间关系和索引 建立数据库模式 第二章 规范的数据库设计 未合理设计的数据库所带来的问题 冗余数据 有限的记录信息 不一致的数据 不规则的更新 不规则的删除 不规则的插入 第一节 数据库范式 数据库范式是一组数据库结构设计的标准规则，用以保证规范化的数据库设计。 应用数据库范式数据库，可以检验数据库设计的可靠性，找出影响数据完整性和难于维护的设计问题 数据的范式共有七条，在大多数情况下前四条就够用了 第一范式 第二范式 第三范式 BCNF范式 数据库范式 第一范式：在关系模式R中的每一个具体关系r中，如果每个属性值 都是不可再分的最小数据单位，则称R是第一范式的关系 第一范式有三个含义 无多值项目和重复组 每个字段都是原子型的，也就是说每个字段必须包含可能的最小数据元素 以及表格含有关键字 数据库范式 数据库范式 第二范式：如果关系模式R（U，F）中的所有非主属性都完全依赖于任意一个候选关键字，则称关系R 是属于第二范式的 第二范式的含义 表格必须按照第一范式来规范 所有的字段必须引用（或者描述）主键值 如果主键基于一个以上的字段，那么每个非主键字段必须依赖于组合键，而不仅仅是一个非键的字段 不依赖主键的非主键字段应该被移动到另一个表格里去 数据库范式 第三范式（3NF）：如果关系模式R（U，F）中的所有非主属性对任何候选关键字都不存在传递信赖，则称关系R是属于第三范式的 第三范式的含义： 表格必须符合1NF和2NF的要求 所有的字段都必须相互独立，不存在传递关系 任何描述非主键字段的字段都必须被移动到另一个表格里 数据库范式 Boyce-Codd范式（BCNF）：如果关系模式R（U，F）的所有属性（包括主属性和非主属性）都不传递依赖于R的任何候选关键字，那么称关系R是属于BCNF的。或是关系模式R，如果每个决定因素都包含关键字（而不是被关键字所包含），则RCNF的关系模式。 BCNF范式的含义： 表格必须符合1NF和2NF的要求 一定不能存在依赖于非主键的字段。 这条规则实际上是3NF的一个子规则 捕捉可能会通过进程产生的依赖性 数据库范式 规范化的规则能够被简化成下面几点： 每个字段必须尽量小 每个字段只能包含一个数据项 每条记录都必须是唯一的 注意重复的条目 每个字段都必须完全支持主键，而且只支持主键 第二节定义数据库表格之间的关系 关系的类型 一对一：在关系的每一边，这两个表格都只有一条记录。每个关键字的值都只和关系表里的一条记录（或者没有记录）相关。 一对多：主关键字表格只包含有一条记录，这条记录和关系表里的无记录、一条记录或者多条记录相关。 多对多：两个表格里的每条记录都可以和另一个表格里任意数量的记录（或者无记录）相关。 定义数据库表格之间的关系 建立关系 一对一的关系：通过主键建立 一对多的关系：通过组合键建立，且其中一个键是另一张表的外键 多对多的关系 数据库不支持多对多的关系 需要通过建立中间表的形式建立 中间表有组合键，且都为另一张表的外键 定义数据库表格之间的关系 主键的使用 主键必须唯一的识别每一记录 一个记录的主键不能为空 当生成记录时，主键的值必须存在 主键必须保持稳定——不能更改主键的域 主键必须简洁，不要包含过分的属性 主键的值不能改变 定义数据库表格之间的关系 外键的使用 外来关键字字段的数据类型必须和主关键字的相同 在没有特别原因的情况下，不要让外来关键字为空 使用谨慎，可能导致处理上的麻烦 第四节 建立索引 索引的益处 避免全表扫描，加快数据访问的速度 提高查询的效率 索引的弊端 索引文件要占用磁盘空间，如果有大量的索引，索引文件会比数据文件更快地达到最大