数据库的逻辑结构设计和物理设计
概念结构设计
概念结构
概念模型
将需求分析得到的用户需求抽象为信息结构(即概念模型)的过程就是概念结构设计。
**概念模型的特点**
- 能真实、充分地反映现实世界,是现实世界的一个真实模型。
- 易于理解,从而可以用它和不熟悉计算机的用户交换 意见。
- 易于更改,当应用环境和应用要求改变时,容易对概念模型修改和扩充。
- 易于向关系、网状、层次等各种数据模型转换
描述概念模型的工具
E-R模型
E-R模型
实体之间的联系
(1)两个实体型之间的联系:
-
一对一联系(1∶1)
学校里一个班级只有一个正班长,而一个班长只在一个班中任职,则班级与班长之间具有一对一联系。 -
一对多联系(1∶n)
一个班级中有若干名学生,而每个学生只在一个班级中学习,则班级与学生之间具有一对多联系。 -
多对多联系(m∶n)
一门课程同时有若干个学生选修,而一个学生可以同时选修多门课程,则课程与学生之间具有多对多联系。
(2)一般的,单个实体型 and 两个以上的实体型之间也存在着一对一、一对多、多对多联系。
联系的度:参与联系的实体型的数目
2个实体型之间的联系度为2,也称为二元联系;
3个实体型之间的联系度为3,称为三元联系;
N个实体型之间的联系度为N,也称为N元联系
E-R图 E提供了表示实体型、属性和联系的方法:
-
实体型:用矩形表示,矩形框内写明实体名。
-
属性:用椭圆形表示,并用无向边将其与相应的实体型连接起来。
例如,学生实体具有学号、姓名、性别、出生年份、系、入学时间等属性,用E-R图表示如图
-
联系:用菱形表示,菱形框内写明联系名,并用无向边分别与有关实体型连接起来,同时在无向边旁标上联系的类型(1∶1,1∶n或m∶n)。
联系可以具有属性
概念结构设计
实体与属性的划分原则:
为了简化E-R图的处置,现实世界的事物能作为属性对待的,尽量作为属性对待。
两条准则:
作为属性,不能再具有需要描述的性质。属性必须是不可分的数据项,不能包含其他属性。
- 属性不能与其他实体具有联系,即E-R图中所表示的联系是实体之间的联系。
例: 职工是一个实体,职工号、姓名、年龄是职工的属性。
职称如果没有与工资、福利挂钩,根据准则1,则可以作为职工实体的属性
如果不同的职称有不同的工资、住房标准和不同的附加福利,则职称作为一个实体更恰当
E-R图的集成
E-R图的集成一般需要分两步
- 合并。解决各分E-R图之间的冲突,将分E-R图合并起来生成初步E-R图。
- 修改和重构。消除不必要的冗余,生成基本E-R图。
(1)合并E-R图,生成初步E-R图
各个局部应用所面向的问题不同,各个子系统的E-R图之间必定会存在许多不一致的地方,称之为冲突。
子系统E-R图之间的冲突主要有三类:
-
属性冲突
-
- 属性域冲突,即属性值的类型、取值范围或取值集合不同。
例如零件号,有的部门把它定义为整数,有的部门把它定义为字符型。
- 属性域冲突,即属性值的类型、取值范围或取值集合不同。
-
- 属性取值单位冲突。
例如,零件的重量有的以公斤为单位,有的以斤为单位,有的以克为单位
- 属性取值单位冲突。
-
命名冲突
-
- 同名异义,即不同意义的对象在不同的局部应用中具有相同的名字。
-
- 异名同义(一义多名),即同一意义的对象在不同的局部应用中具有不同的名字。
如对科研项目,财务科称为项目,科研处称为课题,生产管理处称为工程。
- 异名同义(一义多名),即同一意义的对象在不同的局部应用中具有不同的名字。
-
- 命名冲突
可能发生在实体、联系一级上,也可能发生在属性一级上
通过讨论、协商等行政手段加以解决
- 命名冲突
-
结构冲突
-
- 同一对象在不同应用中具有不同的抽象。
例如,职工在某一局部应用中被当作实体,而在另一局部应用中则被当作属性。
解决方法:把属性变换为实体或把实体变换为属性,使同一对象具有相同的抽象。
- 同一对象在不同应用中具有不同的抽象。
-
- 同一实体在不同子系统的E-R图中所包含的属性个数和属性排列次序不完全相同。
解决方法:使该实体的属性取各子系统的E-R图中属性的并集,再适当调整属性的次序。
- 同一实体在不同子系统的E-R图中所包含的属性个数和属性排列次序不完全相同。
-
- 实体间的联系在不同的E-R图中为不同的类型。
实体E1与E2在一个E-R图中是多对多联系,在另一个E-R图中是一对多联系
解决方法是根据应用的语义对实体联系的类型进行综合或调整。
- 实体间的联系在不同的E-R图中为不同的类型。
(2)消除不必要的冗余,设计基本E-R图
冗余的数据: 能由基本数据导出的数据,
冗余的联系: 能由其他联系导出的联系。
注意:
并不是所有的冗余数据与冗余联系都必须加以消除,有时为了提高效率,不得不以冗余信息作为代价。
消除冗余方法:
-
分析方法(主要采用)
即以数据字典和数据流图为依据,根据数据字典中关于数据项之间逻辑关系的说明来消除冗余。 -
用规范化理论来消除冗余
-
- 确定分E-R图实体之间的数据依赖。
实体之间一对一、一对多、多对多的联系可以用实体码之间的函数依赖来表示。于是有函数依赖集FL。
- 确定分E-R图实体之间的数据依赖。
-
- 求FL的最小覆盖GL,差集为 D=FL-GL。
逐一考察D中的函数依赖,确定是否是冗余的联系,若是,就把它去掉。
- 求FL的最小覆盖GL,差集为 D=FL-GL。
由于规范化理论受到泛关系假设的限制,应注意下面两个问题:
冗余的联系一定在D中,而D中的联系不一定是冗余的;
当实体之间存在多种联系时,要将实体之间的联系在形式上加以区分。
逻辑结构设计
逻辑结构设计的任务
把概念结构设计阶段设计好的基本E-R图转换为与选用数据库管理系统产品所支持的数据模型相符合的逻辑结构。
对于我们来说就是指:将E-R图转换为关系模式
转换内容
E-R图由实体型、实体的属性和实体型之间的联系三个要素组成。
关系模型的逻辑结构是一组关系模式的集合。
将E-R图转换为关系模型就是指:将实体型、实体的属性和实体型之间的联系转化为关系模式
转换原则:
一个实体型转换为一个关系模式。
关系的属性:实体的属性
关系的码:实体的码
实体型间的联系有以下不同情况
-
一个1:1联系可以转换为一个独立的关系模式,也可以与任意一端对应的关系模式合并。
① 转换为一个独立的关系模式
关系的属性:与该联系相连的各实体的码以及联系本身的属性
关系的候选码:每个实体的码均是该关系的候选码
②与某一端实体对应的关系模式合并
合并后关系的属性:加入对应关系的码和联系本身的属性
合并后关系的码:不变 -
一个1:n联系可以转换为一个独立的关系模式,也可以与n端对应的关系模式合并。
①转换为一个独立的关系模式
关系的属性:与该联系相连的各实体的码以及联系本身的属性
关系的码:n端实体的码
②与n端对应的关系模式合并
合并后关系的属性:在n端关系中加入1端关系的码和联系本身的属性
合并后关系的码:不变
可以减少系统中的关系个数,一般情况下更倾向于采用合并 -
一个m:n联系只能转换为一个关系模式
关系的属性:与该联系相连的各实体的码以及联系本身的属性
关系的码:各实体码的组合 -
三个或三个以上实体间的一个多元联系转换为一个关系模式。
关系的属性:与该多元联系相连的各实体的码以及联系本身的属性
关系的码:各实体码的组合 -
具有相同码的关系模式可合并
目的:减少系统中的关系个数
合并方法:
1将其中一个关系模式的全部属性加入到另一个关系模式中
2然后去掉其中的同义属性(可能同名也可能不同名)
3适当调整属性的次序
举例:
可以将部门压缩到职工
可以将领导压缩到部门
参加n:m所以必须独立
负责:可以将职工压缩到产品中
供应:n:m:p 必须独立
压缩后:5个关系变为
5个实体+2个关系
优化数据模型的方法:
数据库逻辑设计的结果不是唯一的。
优化数据模式就是指: 从一范式优化到到更高的范式优化。
-
确定数据依赖
按需求分析阶段所得到的语义,分别写出每个关系模式内部各属性之间的数据依赖以及不同关系模式属性之间数据依赖。 -
对于各个关系模式之间的数据依赖进行极小化处理,消除冗余的联系。
-
按照数据依赖的理论对关系模式进行分析,考察是否存在部分函数依赖、传递函数依赖、多值依赖等,确定各关系模式分别属于第几范式。
-
按照需求分析阶段得到的各种应用对数据处理的要求,分析对于这样的应用环境这些模式是否合适,确定是否要对它们进行合并或分解。
注意: 并不是规范化程度越高的关系就越优
非BCNF的关系模式虽然会存在不同程度的更新异常,但如果在实际应用中对此关系模式只是查询,并不执行更新操作,就不会产生实际影响。 -
对关系模式进行必要分解,提高数据操作效率和存储空间的利用率。
常用分解方法
-
水平分解
把(基本)关系的元组分为若干子集合,定义每个子集合为一个子关系,以提高系统的效率。
实际中:
对符合80/20的,把经常被使用的数据(约20%)水平分解出来,形成一个子关系。
水平分解为若干子关系,使每个事务存取的数据对应一个子关系。 -
垂直分解
概念: 把关系模式R的属性分解为若干子集合,形成若干子关系模式。
分解原则 经常在一起使用的属性从R中分解出来形成一个子关系模式
优点
可以提高某些事务的效率
缺点
可能使另一些事务不得不执行连接操作,降低了效率
分解要求:
垂直分解必须不损失关系模式的语义(保持无损连接性和保持函数依赖)
设计用户子模式(视图)
- 使用更符合用户习惯的别名
- 针对不同级别的用户定义不同的视图,以保证系统的安全性。
- 简化用户对系统的使用
- 如果某些局部应用中经常要使用某些很复杂的查询,为了方便用户,可以将这些复杂查询定义为视图。
物理结构设计
数据库的物理结构
数据库在物理设备上的存储结构与存取方法。它依赖于选定的数据库管理系统。
设计目标:
为一个给定的逻辑数据模型选取一个最适合应用要求的物理结构的过程。
关系数据库物理设计的内容
- 为关系模式选择存取方法(建立存取路径)
- 设计关系、索引等数据库文件的物理存储结构
存取方法选择
常用存取方法
- B+树索引存取方法
选择索引存取方法的一般规则
-
- 如果一个(或一组)属性经常在查询条件中出现,则考虑在这个(或这组)属性上建立索(或组合索引)
-
- 如果一个属性经常作为最大值和最小值等聚集函数的参数,则考虑在这个属性上建立索引
-
- 如果一个(或一组)属性经常在连接操作的连接条件中 出现,则考虑在这个(或这组)性上建立索引
- Hash索引存取方法
优点:等值查询速度max
缺点:范围查找太慢,不允许出现两个相同值。
选择Hash存取方法的规则
-
- 如果一个关系的属性主要出现在等值连接条件中或主要出现在等值比较选择条件中,- - - 而且满足下列两个条件之一
该关系的大小可预知,而且不变;
该关系的大小动态改变,但所选用的数据库管理系统提供了动态Hash存取方法。
- 如果一个关系的属性主要出现在等值连接条件中或主要出现在等值比较选择条件中,- - - 而且满足下列两个条件之一
- 聚簇存取方法
解释: 为了提高某个属性(或属性组)的查询速度,把这个或这些属性(称为聚簇码)上具有相同值的元组集中存放在连续的物理块中称为聚簇。
缺点: 一个表只能建立一个,后期维护成本高。
优点: 某些场景可以提高速度,节省存储空间(减少聚簇码的存储)
适用条件
很少对基表进行增删操作
很少对其中的变长列进行修改操作
确定数据库的存储结构
确定数据库物理结构主要指确定数据的存放位置和存储结构。
包括:确定关系、索引、聚簇、日志、备份等的存储安排和存储结构,确定系统配置等。
考虑因素:
综合考虑存取时间、存储空间利用率和维护代价3个方面的因素。
1.确定数据的存放位置
基本原则
根据应用情况将
易变部分与稳定部分分开存放
经常存取部分与存取频率较低部分分开存放
例
可以将比较大的表分别放在两个磁盘上,以加快存取速度,这在多用户环境下特别有效。
可以将日志文件与数据库对象(表、索引等)放在不同的磁盘以改进系统的性能。
- 确定系统配置
数据库管理系统一般都提供了一些存储分配参数(如缓冲区大小等等)
在进行物理设计时需要根据应用环境确定这些参数值,以使系统性能最优。
在物理设计时对系统配置变量的调整只是初步的,要根据系统实际运行情况做进一步的调整,以切实改进系统性能。
评价物理结构
评价方法
-
定量估算各种方案
存储空间
存取时间
维护代价 -
对估算结果进行权衡、比较,选择出一个较优的合理的物理结构。
数据库的实施和维护
数据的载入
数据库结构建立好后,就可以向数据库中装载数据了。
组织数据入库是数据库实施阶段最主要的工作。
数据装载方法
人工方法
计算机辅助数据入库
应用程序的调试
在组织数据入库的同时还要调试应用程序。
数据库应用程序的设计应该与数据设计并行进行。
数据库的试运行
应用程序调试完成,并且已有一小部分数据入库后,就可以开始对数据库系统进行联合调试,也称数据库的试运行。
主要工作包括:
功能测试:实际运行应用程序,执行对数据库的各种操作,测试应用程序的各种功能。
性能测试:测量系统的性能指标,分析是否符合设计目标。
数据的分期入库
原因:
重新设计物理结构甚至逻辑结构,会导致数据重新入库
由于数据入库工作量实在太大,所以可以采用分期输入数据的方法
先输入小批量数据供先期联合调试使用,待试运行基本合格后再输入大批量数据,逐步增加数据量,逐步完成运行评价。
数据库的转储和恢复
在数据库试运行阶段,系统还不稳定,硬、软件故障随时都可能发生。
系统的操作人员对新系统还不熟悉,误操作也不可避免
因此必须做好数据库的转储和恢复工作,尽量减少对数据库的破坏
数据库的运行和维护
在数据库运行阶段,对数据库经常性的维护工作主要是由数据库管理员完成的,包括:
-
数据库的转储和恢复
数据库管理员要针对不同的应用要求制定不同的转储计划,定期对数据库和日志文件进行备份。
一旦发生介质故障,即利用数据库备份及日志文件备份,尽快将数据库恢复到某种一致性状态。 -
数据库的安全性、完整性控制
初始定义
数据库管理员根据用户的实际需要授予不同的操作权限
根据应用环境定义不同的完整性约束条件
修改定义
当应用环境发生变化,对安全性的要求也会发生变化,数据库管理员需要根据实际情况修改原有的安全性控制
由于应用环境发生变化,数据库的完整性约束条件也会变化,也需要数据库管理员不断修正,以满足用户要求 -
数据库性能的监督、分析和改进
在数据库运行过程中,数据库管理员必须监督系统运行,对监测数据进行分析,找出改进系统性能的方法。
利用监测工具获取系统运行过程中一系列性能参数的值
通过仔细分析这些数据,判断当前系统是否处于最佳运行状态
如果不是,则需要通过调整某些参数来进一步改进数据库性能 -
数据库的重组织与重构造
(1)数据库的重组织
重组原因:
数据库运行一段时间后,由于记录的不断增、删、改,会使数据库的物理存储变坏,从而降低数据库存储空间的利用率和数据的存取效率,使数据库的性能下降。
重组织的形式
- 全部重组织
- 部分重组织
只对频繁增、删的表进行重组织
重组织的目标
提高系统性能
重组织的工作
- 按原设计要求
重新安排存储位置
回收垃圾
减少指针链 - 数据库的重组织不会改变原设计的数据逻辑结构和物理结构
数据库管理系统一般都提供了供重组织数据库使用的实用程序,帮助数据库管理员重新组织数据库。
(2)数据库的重构造
重构造原因
数据库应用环境发生变化,会导致实体及实体间的联系也发生相应的变化,使原有的数据库设计不能很好地满足新的需求。
数据库重构造的主要工作
根据新环境调整数据库的模式和内模式
增加或删除某些数据项
改变数据项的类型
增加或删除某个表
改变数据库的容量
增加或删除某些索引
注意:
重构造数据库的程度是有限的
若应用变化太大,已无法通过重构数据库来满足新的需求,或重构数据库的代价太大,则表明现有数据库应用系统的生命周期已经结束,应该重新设计新的数据库应用系统了。
小结
数据库的设计过程
-
需求分析
综合各个用户的应用需求(现实世界的需求)。 -
概念结构设计
概念模式(信息世界模型),用E-R图来描述。 -
逻辑结构设计
在逻辑设计阶段将E-R图转换成具体的数据库产品支持的数据模型如关系模型,形成数据库逻辑模式。
然后根据用户处理的要求,安全性的考虑,在基本表的基础上再建立必要的视图,形成数据的外模式 -
物理结构设计
在物理设计阶段根据DBMS特点和处理的需要,进行物理存储安排,设计索引,形成数据库内模式 -
数据库实施
-
数据库运行维护