6.1 数据库设计概述
什么是数据库设计:从数据库理论的抽象角度看,数据库设计是指对于一个给定的应用环境,构造出某种数据库管理系统支持的优化的数据库模式,并据此建立数据库及其应用系统,使之能够有效地存储和管理数据,满足各种用户的应用需求(包括信息管理要求和数据处理要求)
6.1.1 数据库设计特点
三分技术,七分管理,十二分基础数据
结构设计和行为设计相结合
6.1.2 数据库设计方法
为了使数据库设计更合理更有效,需要有效的指导原则,这种原则就称为数据库设计方法学。
6.1.3 数据库设计基本步骤
需求分析:需求收集和分析,得到数据字典和数据流图。
概念结构设计:对用户需求综合、归纳与抽象,形成概念模型,用E-R图表示。
逻辑结构设计:将概念结构转换为某个DBMS所支持的数据模型。
物理结构设计:为逻辑数据模型选取一个最适合应用环境的物理结构
数据库实施:建立数据库,编制与调试应用程序,组织数据入库,程序试运行
数据库运行和维护:对数据库系统进行评价、调整与修改。
6.2 数据库需求分析
目的:确定数据库应用系统要做什么?
任务:
充分了解原系统(手工系统或计算机系统)工作概况
明确用户的各种需求(信息需求、处理需求、安全性和完整性需求)
确定新系统的功能
重点:调查、收集与分析用户在数据管理中的信息需求、处理需求、安全性与完整性需求
6.2.1 需求分析的方法
调查了解是需求分析的主要方法。常用的调查方法: 跟班作业、开调查会、请专人介绍、设计调查表请用户填写、查阅原系统有关记录。
6.3 数据库概念结构设计
将需求分析得到的用户需求抽象为概念模型的过程就是概念结构设计。
独立于DBMS和计算机硬件
E-R模型描述概念结构
6.3.1 概念结构设计方法
自底向上: 先定义每个局部应用的概念结构,然后按一定的规则把它们集成起来,从而得到全局概念模型。
自顶向下:先定义全局概念模型,然后再逐步细化。
由里向外:先定义最重要的核心结构,然后再逐步向外扩展。
混合策略:将自顶向下和自底向上结合起来使用。先用自顶向下设计一个概念结构的框架,然后以它为框架再用自底向上设计局部概念结构,并把它们集成。
最常用的设计策略是自底向上策略。
6.3.2 自底向上的概念结构设计步骤
根据需求分析的结果,对现实世界的数据进行抽象,设计各个局部E-R图。
集成局部E-R图,即设计全局E-R图。
优化全局E-R图。
6.3.3 局部E-R图设计
实体:一组具有某些共同特性和行为的对象就可以抽象为一个实体。
属性:描述对象类型的特征可以抽象为实体的属性。
联系:1:1、1:n、m: n
设计原理:实体要尽可能的少,现实世界中的事物若能作为属性就尽量作为属性对待。只考虑系统范围内的属性。属性一般要满足下面的准则:属性必须不可分,不能包含其它属性,属性不能和其它实体具有联系。
6.3.4 综合举例
百度外卖系统
分析:
餐厅:餐厅名,所属区域,GPS坐标x,GPS坐标y,地址,接单说明,起送价,配送费
区域:区域编号,区域名,GPS坐标x,GPS坐标y
菜品:菜品名,所属餐厅,价格,图片路径
顾客:姓名,地址,手机号码
订单:订单号,总价,下单时间,支付状态,送餐状态
送餐员:姓名,手机号码
上述实体之间经分析存在以下联系:一个区域有多家餐厅,一家餐厅一定位于某一确定区域;一家餐厅经营多种不同菜品,一种菜品专属于某一餐厅;一份订单可以订购多种菜品,一种菜品也可以被多份订单所订购;一位顾客可下多份不同订单,一份订单一定由某一确定顾客所下;一位送餐员可以对多份不同订单进行送餐,而一份订单由一位指定送餐员进行派送;顾客订餐交易完成后可对所下订单的服务质量进行评价
学生管理系统
基本信息管理部分:学生管理部分包括管理学生的宿舍,档案,掌握学生的分班和班主任管理的情况 每个班级可以有一个班主任和多个学生,一位教师只能任一个班的班主任,一间宿舍可以住多位学生,每位学生有自己唯一对应的一份档案材料。
选课管理部分:每位学生可以选修多门不同的课程,每门课程可以由不同的学生选修;一位教师可以教授多门不同的课程,但同一门课程只能由同一位老师讲授;一间教室可以在不同时段容纳多门课程开设,但同一门课程必须在同一教室上课。
6.3.5 全局ER图设计
将各子系统的分E-R图综合成整个系统的全局E-R图
一次集成 逐步集成
解决冲突是该阶段的主要工作和关键所在
属性冲突:属性域冲突。即属性的类型、取值范围和取值集合不同;属性取值单位冲突
命名冲突:结构冲突。同名异义;异名同义
结构冲突:同一对象在不同应用中具有不同的抽象;同一实体在不同的E-R模型中,其属性的个数和排列次序不完全相同;实体间联系在不同局部E-R图中类型不同
将百度外卖系统的局部E-R图合并生成初步全局E-R图
初步的全局E-R图
6.3.6 优化全局E-R模型
一个好的E-R模型除了能反映用户需求外,还应满足如下条件:
实体个数尽可能少;
实体所包含的属性尽可能少;
实体之间联系无冗余。
消除冗余方法:
1.合并实体
一般相同主码或1:1联系的两个实体可以合并为一个实体
如果两个实体在应用中经常需要同时处理,可考虑合并,例如病人和病历,如果实际中通常是查看病人时必然要查看病历,可考虑将病历合并到病人实体中
减少了联接查询开销,提高效率
2.消除冗余属性
冗余属性的几种情形:
同一非主属性出现在几个实体中
一个属性值可从其它属性值中导出,例如出生日期和年龄
冗余属性有时也有意保留,以存储空间和维护代价来换取效率
3.消除冗余联系
对百度外卖系统的全局E-R图进行优化
6.4 逻辑结构设计
任务:把概念设计阶段的基本E-R模型转换为具体数据库管理系统支持的组织层数据模型,也就是导出特定的DBMS可以处理数据库的逻辑结构。
步骤:将概念层模型转化为组织层数据模型、优化数据模型、设计用户外模式
6.4.1 E-R模型转化为关系模型
E-R图中实体的关系表示:一个实体转换为一个关系,实体的属性转换为关系的属性,实体的码就是关系的码。
联系为1:1,将任意一端实体的主码放入另一端实体的关系中
联系为1:n,将一端实体的主码放入多端实体的关系中
联系为m:n,必须转换为一个关系。该联系相连的各实体的主码和联系本身的属性转换为该关系中的属性。
三个或三个以上实体间的一个多元联系可转换为一个关系模式。与该多元联系相连的各实体的码以及联系本身的属性均转换为此关系模式的属性,而此关系模式的主码包含各实体的码。
6.4.2 数据模型的优化
逻辑结构设计的结果并不是唯一的,为了进一步提高数据库应用系统的性能,还应该根据应用的需要对逻辑数据模型进行适当的修改和调整,这就是数据模型的优化。 关系数据模型的优化通常以规范化理论为指导,并考虑系统的性能。
6.4.3 设计外模式
将概念模型转换为逻辑数据模型之后,还应该根据局部应用需求,并结合具体的数据库管理系统的特点,设计用户的外模式。
定义外模式时需考虑的因素:
使用更符合用户习惯的别名
对不同级别的用户定义不同的视图,以保证数据的安全
对经常使用的复杂查询可以定义成视图,简化用户对系统的使用
6.5 物理结构设计
对已确定的逻辑数据结构,利用DBMS提供的方法、技术,以较优的存储结构、数据存取路径、合理的数据存储位置、存储空间分配,设计出高效的、可实现的物理数据库结构。
物理结构设计分两步:
确定数据库的物理结构,在关系数据库中主要指存取方法和存储结构;
对物理结构进行评价,评价的重点是时间和空间效率。
1.确定物理结构
确定数据的存取方法:索引方法、聚簇方法
(1)索引
索引是SQL Server 使用的一种内部表结构,它基于表中一个或多个列的值,提供对表中行的快速存取。
索引适用范围:某属性或属性组经常出现在查询条件中、某个属性经常作为分组的依据列、某属性和属性组经常出现在连接操作的连接条件中
优点:加速查询速度
缺点:索引本身要占用存储空间;需要系统进行维护,每更新一个关系时,必须对这个关系上相关的索引均作出相应的修改
(2)聚簇
为了提高某个属性或属性组的查询速度,把这个属性或属性组上具有相同值的元组集中存放在连续的物理块上的处理称为聚簇。该属性或属性组称为聚簇码
可以大大提高按聚簇属性进行查询的效率,但是建立和维护聚簇的开销也很大,应适当建立。
确定数据的存储结构
评价物理结构:对数据库物理设计过程中产生的多种方案进行评价,选择一个较优的方案作为数据库物理结构