数据库设计
数据库设计定义
数据库设计 是指对于一个给定的应用环境,构造(设计)优化的数据库逻辑模式和物理结构,并据此建立数据库及其应用系统,使之能够有效的存储和管理数据,满足各种用户的应用需求,包括信息管理要求和数据操作要求。-
数据库设计的特点
数据库建设的基本规律
三分技术,七分管理,十二分基础数据结构(数据)设计和行为(处理)设计相结合
- 数据库设计方法
- 新奥尔良(New Orleans) 方法
属于规范设计法,思想:过程迭代逐步求精 - 基于 E-R 模型的数据库设计方法(最常用的方法)
- 3NF(第三范式)设计方法
- ODL(Object Definition Language) 面向对象数据库设计方法
- 新奥尔良(New Orleans) 方法
- 数据库设计基本步骤
- 需求分析
- 概念结构设计
- 逻辑结构设计
- 物理结构设计
- 数据库实施
- 数据库运行和维护
需求分析的方法
调查用户需求的具体步骤:
- 调查组织机构情况,包括了解该组织的部门组成情况,各部门的职责等,为分析信息流程做准备
- 调查各部门的业务活动情况,包括了解各个部门输入和使用什么数据,如何加工处理这些数据,输出什么信息,输出到什么部门,输出结果的格式是什么。这是调查的重点
- 再熟悉了业务活动基础上,协助用户明确对新系统的各种要求,包括信息要求,处理要求,安全性与完整性要求
- 确定新系统的边界,对前面调查的结果进行初步分析,确定哪些功能由计算机完成或将来准备让计算机完成,哪些活动由人工完成,由计算机完成的功能就是新系统应该实现的功能。
常用的调查方法:
- 跟班作业,通过亲身参加业务工作来了解业务活动情况
- 开调查会。通过与用户座谈来了解业务活动情况及用户需求
- 请专人调查
- 询问,对某些调查中的问题,可以找专人询问
- 设计调查表请用户填写。如果调查表设计的合理,这种方法是很有效的
- 查阅记录,查阅与原系统有关的数据记录
数据字典
数据字典:系统中各类数据描述的集合。进行详细的数据收集和数据分析所获得的主要成果
- 数据项
不可分的数据单位
数据项描述 = |数据项名,数据项含义说明,别名,数据类型,长度,取值范围,取值含义,与其他数据项的逻辑关系,数据项之间的联系|
数据结构
数据结构反应了数据之间的组合关系,一个数据结构可以由若干个数据项组成,也可以由若干个数据结构组成,或由若干个数据结构混合组成,对数据结构的描述通常包含以下内容:
数据结构描述 = |数据结构名,含义说明,组成:|数据项或数据结构||数据流
数据流是数据结构在系统内传输的路径。对数据流的描述通常包括下面的内容
数据流描述 = |数据流名,说明,数据流来源,数据流去向,组成:|数据结构|,平均流量,高峰期流量|数据存储
数据存储描述 = |数据存储名,说明,编号,输入的数据流,输出的数据流,责成|数据结构|,数据量,存取频度,存取方式|-
处理过程
处理过程描述 = |处理过程名,说明,输入:|数据流|,输入:|数据流|,处理:|简要说明||数据字典是关于数据库中数据的描述,即元数据,而不是数据本身
概念结构设计
将需求分析得到的用户需求抽象为信息结构即概念模型的过程就是概念结构设计
-
概念结构
特点如下:- 能真实、充分地反映现实世界,包括事物和事物之间的联系,能满足用户对数据的处理要求,是对现实世界的一个真实模型
- 易于理解,从而可以用它和不熟悉计算机的用户交换意见,用户的积极参与是数据库设计成功的关键
- 易于更改,当应用环境和应用要求更改时,容易对概念模型修改和扩充
- 易于向关系、网状、层次等各种数据模型转换。
概念模型的工具是 E-R 模型
概念结构设计的方法与步骤
- 自顶向下,首先定义全局概念结构的框架,然后逐步细化
- 自底向上,首先定义各个局部应用的概念结构,然后将他们集成起来,得到全局概念结构。
- 逐步扩展。首先定义最重要的核心概念结构,然后向外扩充,以滚雪球的方式逐步生成其他概念结构,直至总体概念结构
- 混合策略。即将自顶下下和自底向上相结合,用自顶向下策略设计一个全局概念结构的框架,以它为骨架集成自底向上策略中设计的各局部概念结构
经常采用的策略是自底向上的方法,即自顶向下的锦讯需求分析,然后再自底向上的设计概念结构
需求分析--> 分 E-R 图--> 总 E-R 图
数据抽象与局部视图设计
三种抽象
- 分类 (Classification)
- 聚集 (Aggregation)
- 概括 (Generalization)
E-R 图调整:
为了简化 E-R 图的处置,现实世界的事物能作为属性对待的,尽量作为属性对待。
属性:
- 作为属性,不能再具有需要描述的性质。属性必须是不可分割的数据项,不能包含其他属性
- 属性不能与其他实体具有联系,即 E-R 图中所表示的联系是实体之间的联系
根据需求分析结果 画出第一层数据流图,第二层数据流图等
分别设计它们的 分 E-R 图 再汇总成 局部应用的 分 E-R 图
视图的集成
将所有的分 E-R 图综合成一个系统的总 E-R 图。
-
两种集成方式
- 多个分 E-R 图一次集成
- 逐步集成,用累加的方式一次集成两个分 E-R 图
-
集成过程
- 合并,解决各分 E-R 图之间的冲突,将各分 E-R 图合并起来生成初步 E-R 图
- 修改和重构。消除不必要的冗余,生成基本 E-R 图
-
合并分 E-R 图,生成初步 E-R 图
- 属性冲突
属性域冲突,即属性值得类型、取值范围或取值集合不同、例如零件号,有的部门把它定义为整数,有的部门把它定义为字符型。不同的部门对零件号和编码也不同。又如年龄,某些部门以出生年月日期形式表示职工的年龄,而另一些部门用整数表示职工的年龄。
属性取值单位冲突,例如,零件的重量有的以公斤为单位,有的以斤为单位,有的以克为单位。
属性冲突需要各部门讨论协商,解决起来并非易事
- 命名冲突
同名异议,不同意义的对象在不同的局部应用中具有相同的名字
异名同义(一义多名),即同一意义的对象在不同的局部应用中具有不同的名字。如对科研项目,财务科称为项目,科研处称为课题,生产管理处称为工程
处理命名冲突通常也像处理属性冲突一样,通过讨论,协商等行政手段加以解决
- 结构冲突
同一对象在不同应用中具有不同的抽象,例如,职工在某一局部应用中被当做实体,而在另一局部应用中则被当做属性
解决办法,通常是把属性变换为实体 或 把实体变换为属性,使同一对象具有相同的抽象。
- 属性冲突
同一实体在不同分 E-R 图中所包含的属性个数和属性排列次序不完全相同。
解决办法,使该实体的属性取各分 E-R 图中属性的并集,再适当调整属性的次序
- 消除不必要的冗余,设计基本 E-R 图
逻辑结构设计
逻辑结构设计步骤
- 将概念结构转换为一般关系、网状、层次模型
- 将转换来的关系、网状、层次模型向指定
DBMS 支持下的数据模型转换。
对数据模型进行优化
E-R 图向关系模型的转换
一个实体型转换为一个关系模式,实体的属性就是关系的属性,实体的码就是关系的码
对于实体型间的联系则有一下不同的情况:
一个 1:1 联系可以转换为一个独立的关系模式,也可以与任意一端对应的关系模式合并。如果转换为一个独立的关系模式,则与该联系相连的各实体的码以及联系本身的属性均转换为关系的属性,每个实体的码均是该关系的候选码。如果与某一端实体对应的关系模式合并,则需要在该关系模式的属性中加入另一个关系模式的码和联系本身的属性。
一个 1:n 联系可以转换为一个独立的关系模式,也可以与 n 端 对应的关系模式合并。如果转换为一个独立的关系模式,则与该联系相连的各实体的码以及联系本身的属性均转化为关系的属性,而关系的码为 n 端实体的码
一个 m:n 联系转换为一个关系模式。与该联系相连的各实体的码以及联系本身的属性均转换为关系的属性,各实体的码组成关系的码或关系码的一部分
3 个或 3 个以上实体间的一个多元联系可以转换为一个关系模式。与该多元联系相连的各实体的码以及联系本身的属性均转换为关系的属性,各实体的码组成关系的码或关系吗的一部分
具有相同码的关系模式可以合并
-
数据模型的优化
- 确定数据依赖,按需求分析阶段所得到的语义,分别写出每个关系模式内部各属性之间的数据依赖以及不同关系模式属性之间的数据依赖。
2.对于各个关系模式之间的数据依赖进行极小化处理,消除冗余的联系
按照数据依赖的理论对关系模式逐一进行分析,考察是否存在部分函数依赖、传递函数依赖、多值依赖等,确定各关系模式分别属于第几范式
按照需求分析阶段得到的处理要求,分析对于这样的应用环境这些模式是否合适,确定是否要对某些模式进行合并或分解
-
对关系模式进行必要的分解,提高数据操作的效率和存储空间的利用率。常用的两种分解方法是水平分解和垂直分解。
水平分解是把(基本)关系的元祖分成若干子集合,定义每个子集合为一个子关系,以提高系统的效率。根据“80/20”原则,一个大关系中,经常被使用的数据只是关系的一部分,约20%,可以把经常使用的数据分解出来,形成一个子关心。如果关系 R 上 具有 n 个事物,而且多数事物存取的数据不想交,则 R 可以分解为少于或等于 n 个子关系, 使每个事物存取的数据对应一个关系
垂直分解就是把关系模式 R 的属性分解为若干子集合,形成若干子关系模式。垂直分解的原则是,经常在一起使用的属性从 R 中 分解出来形成一个子关系模式。垂直分解可以提高某些事物的效率,但也可以使另一些事务不得不执行链接操作,从而降低了效率。因此是否进行垂直分解取决于分解后 R 上的所有事务的总效率是否得到了提高。垂直分解需要确保无损链接性和保持函数依赖,即保证分解后的关系具有无损连接性和保持函数依赖性。
-
设计用户子模式 (view 视图模式)
使用更符合用户习惯的别名
可以对不同级别的用户定义不同的 View,以保证系统的安全性
简化用户对系统的使用
数据库的物理设计
数据库物理设计通常分为两步:
确定数据库的物理结构,在关系数据库中主要指存取方法和存储结构
对物理结构进行评价,评价的终点是时间和空间效率
-
数据库物理设计的内容和方法
查询:- 查询的关系
- 查询条件所设计的属性
- 链接条件所涉及的属性
- 查询的投影属性
更新:
- 被更新的关系
- 每个关系上的更新操作条件所涉及的属性
- 修改操作要改变的属性值
内容:
为关系模式选择存取方法
设计关系、索引等数据库文件的物理存储结构
关系模式存取方法选择
存取方法是快读存取数据库中的数据,常用的有三类-
索引存取方法
根据应用要求确定对关系的哪些属性列建立索引、哪些属性列建立组合索引、哪些索引要设计为唯一索引等- 如果一个(或一组)属性经常在查询条件中出现,则考虑在这个(或这组)属性上建立索引(或组合索引)
- 如果一个属性经常违最大值和最小值等聚集函数的参数,则考虑在这个属性上建立索引。
- 如果一个(或一组)属性经常在链接操作的链接条件中出现,则考虑在这个(或这组)属性上建立索引
-
聚簇存取方法
为了提高某个属性(或属性组)的查询素的,把这个或这些属性(称为聚簇码)上具有相同值得元祖集中存放在连续的物理块称为聚簇- 经常在一起进行连接操作的关系可以建立聚簇
- 如果一个关系的一组属性经常出现在相等比较条件中,则该单个关系可建立聚簇
- 如果一个关系的一个(或一组)属性上的值重复率很高,则此单个关系可建立聚簇。
- HASH 存取方法的选择
如果一个关系的属性主要出现在等值链接条件中或主要出现在相等比较选择条件中,而且满足下列两个条件之一,则此关系可以选择 HASH 存取方法。- 如果一个关系的大小可以预知,而且不变
- 如果关系的大小动态改变,而且数据库管理系统提供了动态 HASH 存取方法
-
确定数据库的存储结构
确定数据库物理结构主要指确定数据的存放位置和存储结构,包括:确定关系、索引、聚簇、日志、备份等存储安排和存储结构,确定系统配置等- 确定数量的存放位置
- 确定系统配置
评价物理结构
对时间效率、空间效率、维护代价和各种用户要求进行权衡。
数据库的实施和维护
数据的载入和应用程序的调试
先载入少量数据调试,运行合格后,再大批输入数据,逐步增加数据量。。。数据库调试试运行
首先调试运行DBMS 的恢复功能。-
数据库的运行和维护
下面都是 DBA 的职责- 数据看的转储 和 恢复
- 数据库的安全性、完全性控制
- 数据库性能的监督、分析和改造
- 数据库的重组织与重构造