数据库设计流程
数据库设计是指对于一个给定的应用环境,构造最优的数据库模式,建立数据库及其应用系统,使之能够有效地存储数据,满足各种用户的应用需求。主要包括 2 种需求:
需求类型 | 说明 |
---|---|
信息管理要求 | 指在数据库中应该存储和管理哪些数据对象 |
数据操作要求 | 指对数据对象需要进行哪些操作,如查询、增、删、改、统计等操作 |
数据库设计包括数据库的结构设计和行为设计两方面的内容,数据库模式是静态的、稳定的,所以结构设计又称为静态模型设计,行为设计是动态的,所以行为设计又称为动态模型设计。
设计内容 | 说明 |
---|---|
结构设计 | 根据给定的应用环境,进行数据库的模式或子模式的设计,包括数据库的概念设计、逻辑设计和物理设计 |
行为设计 | 指确定数据库用户的行为和动作,也就是对数据库的操作,而这些要通过应用程序来实现 |
数据库设计一般分为六个阶段:
- 需求分析:准确了解与分析用户需求,是后续工作的重要基础;
- 概念结构设计:对用户需求进行综合、归纳、抽象,形成概念模型;
- 逻辑结构设计:将概念结构转换为 DBMS 支持的数据模型;
- 物理结构设计:为逻辑数据模型选择适用的物理结构;
- 数据库实施:基于数据库进行程序设计,并且调试运行;
- 数据库运行和维护:正式将项目落地,运行过程中不断对数据库进行评估、调整和修改。
需求分析
需求分析是通过详细调查现实世界要处理的对象,充分了解原系统工作概况,明确用户的各种需求,是设计数据库的起点。需求调查
通过调查、收集与分析,获得用户对数据库的如下要求:
对数据库的要求 | 说明 |
---|---|
信息要求 | 用户需要从数据库中获得信息的内容与性质,在数据库中需要存储哪些数据 |
处理要求 | 用户要完成的数据处理功能,对处理性能的要求 |
安全性要求 | 体现在数据库安全性、信息安全性和系统平台的安全性等方面 |
完整性要求 | 系统完整性要求系统中数据的正确性以及相容性 |
数据流图
数据流程图就是用来描述数据的流动、处理和存储的逻辑关系,它由数据流、数据处理、数据存储、数据源、数据终点组成。系统的全局数据流图,主要是从整体上描述系统的数据流,反映系统中数据的整体流向,是设计者针对用户和开发者表达出来的一个总体描述。如图所示是我之前 Java 课设开发的 OJ 系统中的全局数据流图。
但是一个较为复杂的系统来讲,要清楚地描述系统数据的流向和加工处理的每一个细节,仅用全局数据流图难以完成。因此需要对全局数据流图的某些局部单独放大,进一步细化,细化可以采用多级方式进行,便是所谓的分级数据流图来描述。这里针对学生、教师在系统中的行为等处理功能作细化的分析对象:
接着就是具体模块的数据流图了,例如用户登录功能的数据流图如下:
数据字典
数据字典是在数据流程图的基础上,对数据流程图中的各个元素进行详细的定义与描述,起到对数据流程图进行补充说明的作用,包括数据项、数据结构、数据流、数据存储、处理过程。
数据项是不可再分的数据单位,例如我之前开发的 OJ 系统中,有关用户和班级信息的数据项列表如下所示。
数据项编号 | 数据项名 | 数据项含义 | 与其它数据项的关系 | 存储结构 | 别名 |
---|---|---|---|---|---|
DI-1 | UsersID | 用户ID | Int(11) | 用户号 | |
DI-2 | UsersUsername | 用户登录名 | Varchar(255) | 用户名 | |
DI-3 | UsersPassword | 用户登录密码 | varchar(255) | 密码 | |
DI-4 | UsersType | 用户类型 | Varchar(4) | 身份 | |
DI-5 | ClassName | 班级名 | varchar(255) | 班名 | |
DI-6 | ClassID | 班级ID | Int(11) | 班级号 | |
DI-7 | ClassCollections | 班级题目集ID | Int(11) | 题目集号 | |
DI-8 | ClassUser | 班级成员ID | UsersID | int(11) | 用户号 |
DI-9 | ClassUserType | 班级成员类型 | Int(1) | 用户类型 |
数据结构反映了数据之间的组合关系,有关用户和班级信息的数据结构如下所示。
数据结 | 数据结构名 | 数据结构 | 组成 |
---|---|---|---|
DS-1 | User | 用户信息 | UsersID,UsersUsername,UsersPassword,UsersType |
DS-2 | Class | 班级信息 | ClassID,ClassCollections,ClassUser,ClassUserType |
概念结构设计
将需求分析得到的用户需求抽象为信息世界的结构,概念结构设计的任务是将需求分析的结果进行概念化抽象,获得系统的 E-R 图。
信息模型
概念模型是现实世界到机器世界的一个中间层次,是现实世界到信息世界的第一层抽象。概念模型一方面应该具有较强的语义表达能力,能够方便、直接地表达应用中的各种语义知识,另一方面它还应该简单、清晰、易于用户理解。信息世界主要涉及以下一些概念:
概念 | 说明 |
---|---|
实体 | 客观存在并可相互区别的事物称为实体 |
属性 | 实体所具有的某一特性称为属性 |
码 | 唯一标识实体的属性集称为码 |
实体型 | 就是用实体名及其属性名集合来抽象和刻画同类实体 |
实体集 | 同一类型实体的集合称为实体集 |
联系 | 不同实体集之间的联系,主要有一对一、一对多和多对多三种联系 |
实体一联系方法
概念模型的表示方法很多,其中最为常用的是实体一联系方法,该方法用 E-R 图来描述现实世界的概念模型。E-R 图提供了表示实体型、属性和联系的方法:
E-R 图组件 | 说明 |
---|---|
实体型 | 用矩形表示,矩形框内写明实体名 |
属性 | 用椭圆形表示,并用无向边将其与相应的实体型连接起来 |
联系 | 用菱形表示,菱形框内写明联系名,用无向边分别与有关实体型连接起来,同时在无向边旁标上联系的类型 |
例如 OJ 系统中,学生、题目集、班级这几个实体的 E-R 图为:
学生、题目集、班级有得分关系,可以得到 E-R 图为:
概念结构设计步骤
在需求分析阶采用的是自上而下的分析方法要在其基础上进一步作概念设计时,要细化的分析数据流图以及数据字典,分析得到实体及其属性后,进一步可分析各实体之间的联系。主要采用的设计手段目前还是实体联系模型(E-R Model),绘制 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 图转换为关系模型实际上就是要将实体型、属性和联系转换为关系模式,一个实体型转换为一个关系模式。对于实体型间的联系有以下不同的情况。
- 一个 1:1 联系可以转换为一个独立的关系模式,也可以与任意一端对应的关系模式合并。
- 一个 1:n 联系可以转换为一个独立的关系模式,也可以与 n 端对应的关系模式合并。如果转换为一个独立的关系模式,则与该联系相连的各实体的码以及联系本身的属性均转换为关系的属性,而关系的码为 n 端实体的码。
- 一个 m:n 联系转换为一个关系模式,与该联系相连的各实体的码以及联系本身的属性均转换为关系的属性,而关系的码为各实体码的组合。
- 三个或三个以上实体间的一个多元联系可以转换为一个关系模式,与该多元联系相连的各实体的码以及联系本身的属性均转换为关系的属性,而关系的码为各实体码的组合。
- 具有相同码的关系模式可合并。
例如上面的 E-R 图转换成关系模式为:
用户(UsersID, UsersUsername, UsersPassword, UsersType)
班级(ClassID, ClassName)
题目集(CollectionsID, CollectionsName)
得分(UsersID, ClassID, CollectionsID, Score)
又例如用户和私信的关系是 1:n,因此可以转换为一个独立的关系模式,也可以与 n 端对应的关系模式合并,统一合并为私信实体。
私信(EmailsID, UserID, EmailsTitle, EmailsAddresserID, EmailsText, EmailsSendtime)
数据模型的优化
数据库逻辑设计的结果不是唯一的,为了进一步提高数据库应用系统的性能,还应该根据应用需要适当地修改、调整数据模型的结构。关系数据模型的优化通常以规范化理论为指导,将关系模式分解为更高级别的范式。例如原来我在写 OJ 系统时,班级的关系模式为:
班级用户(ClassID, ClassUserID, ClassUser, ClassUserType)
原来的设计中班级实体的候选键是(ClassID, ClassUserID),此时每个属性都是不可再分的,属于 1NF。但是存在非主属性对候选码的部分依赖,例如 ClassID->ClassName,而不需要(ClassID, ClassUserID)->ClassName,因此不属于2NF。为了分解为2NF,应该把 ClassUser 和 ClassUserType 独立出来。进行一些合并后得到新的关系模式达到 2NF,同时也消除了非主属性对候选码的传递依赖,达到 3NF。
用户(UsersID, UsersUsername, UsersPassword, UsersType)
班级(ClassID, ClassName)
班级用户(UsersID, ClassID)
并不是规范化程度越高的关系就越优,例如当查询经常涉及两个或多个关系模式的属性时,执行连接运算的代价是相当高的。这时可以考虑将这几个关系合并为一个关系,改为 2NF 甚至是 1NF。又如非 BCNF 的关系模式虽然从理论上分析会存在更新异常或冗余,但如果在实际应用中对此关系模式只查询不更新,则不会产生实际影响。
设计用户子模式
将概念模型转换为全局逻辑模型后,还应该根据局部应用需求设计用户的外模式,可以利用视图设计用户外模式。定义数据库全局模式主要是从系统的时间效率、空间效率、易维护等角度出发,具体包括以下几方面:
- 使用更符合用户习惯的别名;
- 可以对不同级别的用户定义不同的视图,以保证系统的安全性;
- 简化用户对系统的使用。
例如我开发 OJ 系统时,提供了 6 个视图,他们都是用来简化查询操作的。
编号 | 用户子模式(View) | 作用(共性:提供数据保密和安全保护机制) |
---|---|---|
V-1 | answerview | 便于查询学生回答的主观题答案 |
V-2 | Codeview | 便于查询学生回答的编程题答案 |
V-3 | Emailsview | 便于查询用户的私信 |
V-4 | Taskview | 便于查询班级拥有的题目集 |
V-5 | Scoreview | 便于查询学生的成绩信息 |
物理结构设计
数据库在物理设备上的存储结构与存取方法称为数据库的物理结构,为一个给定的逻辑数据模型选取一个最适合应用环境的物理结构的过程就是物理结构设计。数据库物理设计时,先要确定数据库的物理结构,接着对物理结构进行评价。确定数据库的物理结构的主要工作有:
- 确定数据的存储结构方面,设计时要综合考虑存取时间、存储空间利用率、维护代价这三个影响因素;
- 设计合适的存取路径,主要指确定如何建立索引;
- 确定数据的存放位置;
- 确定系统配置,DBMS 产品一般都提供了一些存储分配参数。
评价物理结构时,主要是对数据库物理设计过程中产生的多种方案进行细致的评价,从中选择一个较优的方案作为数据库的物理结构。
数据库的实施和维护
数据库实施的工作内容有:用 DDL 定义数据库结构、组织数据入库、编制与调试应用程序、数据库试运行。在数据库运行阶段,对数据库经常性的维护工作主要是由 DBA 完成的,包括
数据库维护工作 | 说明 |
---|---|
转储和恢复 | 以便于发生故障时尽快恢复数据库到某种一致的状态 |
安全性、完整性控制 | 根据应用环境的安全性和完整性约束的变化,及时进行相应的改变 |
性能的监督、分析和改进 | 分析监测数据,根据情况对系统物理参数优化,或者对数据库重构 |
重组织和重构造 | 由于记录的不断操作会使数据库的物理存储情况变坏,所以需要重构来恢复数据库的性能 |
参考资料
《数据库系统概论(第5版)》,王珊 萨师煊 编著,高等教育出版社