3.2 数据库模式与范式
数据库模式与范式是数据库系统中的两个重要概念,是进行数据库设计的基础。
3.2.1 数据库的结构与模式
数据库技术中采用分级的方法将数据库的结构划分为多个层次。最著名的是美国 ANSI/ SPARC 数据库系统研究组 1975 年提出的三级划分法,如图 3-1 所示。
- 三级抽象
数据库系统划分为三个抽象级:用户级、概念级、物理级。
(1) 用户级数据库。用户级数据库对应于外模式,是最接近用户的一级数据库,是用户可以看到和使用的数据库,又称用户视图。用户级数据库主要由外部记录组成,不同的用户视图可以互相重叠,用户的所有操作都是针对用户视图进行的。
(2) 概念级数据库。概念级数据库对应于概念模式,介于用户级和物理级之间,是所有用户视图的最小并集,是数据库管理员可看到和使用的数据库,又称 DBA(DataBase Administrator,数据库管理员)视图。概念级数据库由概念记录组成,一个数据库可有多个不同的用户视图,每个用户视图由数据库某一部分的抽象表示所组成。一个数据库应用系统只存在一个 DBA 视图,它把数据库作为一个整体的抽象表示。概念级模式把用户视图有机地结合成一个整体,综合平衡考虑所有用户要求,实现数据的一致性、最大限度降低数据冗余、准确地反映数据间的联系。
(3) 物理级数据库。物理级数据库对应于内模式,是数据库的低层表示,它描述数据的实际存储组织,是最接近于物理存储的级,又称内部视图。物理级数据库由内部记录组成, 物理级数据库并不是真正的物理存储,而是最接近于物理存储的级。
2.三级模式
数据库系统的三级模式为外模式、概念模式、内模式。
(1) 概念模式。概念模式(模式、逻辑模式)用以描述整个数据库中数据库的逻辑结构,描述现实世界中的实体及其性质与联系,定义记录、数据项、数据的完整性约束条件及记录之间的联系,是数据项值的框架。
数据库系统概念模式通常还包含有访问控制、保密定义、完整性检查等方面的内容,以及概念/物理之间的映射。
概念模式是数据库中全体数据的逻辑结构和特征的描述,是所有用户的公共数据视图。一个数据库只有一个概念模式。
外模式是数据库用户(包括程序员和最终用户)能够看见和使用的局部数据的逻辑结构和特征的描述,是数据库用户的数据视图,是与某一应用有关的数据的逻辑表示。一个数据库可以有多个外模式。一个应用程序只能使用一个外模式。
(2) 外模式。外模式(子模式、用户模式)用以描述用户看到或使用的那部分数据的逻辑结构,用户根据外模式用数据操作语句或应用程序去操作数据库中的数据。外模式主要描述组成用户视图的各个记录的组成、相互关系、数据项的特征、数据的安全性和完整性约束条件。
(3) 内模式。内模式是整个数据库的最低层表示,不同于物理层,它假设外存是一个无限的线性地址空间。内模式定义的是存储记录的类型、存储域的表示以及存储记录的物理顺序,指引元、索引和存储路径等数据的存储组织。
内模式是数据物理结构和存储方式的描述,是数据在数据库内部的表示方式。一个数据库只有一个内模式。
内模式、模式和外模式之间的关系如下:
(1) 模式是数据库的中心与关键;
(2) 内模式依赖于模式,独立于外模式和存储设备;
(3) 外模式面向具体的应用,独立于内模式和存储设备;
(4) 应用程序依赖于外模式,独立于模式和内模式。
3.两级独立性
数据库系统两级独立性是指物理独立性和逻辑独立性。三个抽象级间通过两级映射(外模式—模式映射,模式—内模式映射)进行相互转换,使得数据库的三级形成一个统一的整体。
(1) 物理独立性。物理独立性是指用户的应用程序与存储在磁盘上的数据库中的数据是相互独立的。当数据的物理存储改变时,应用程序不需要改变。
物理独立性存在于概念模式和内模式之间的映射转换,说明物理组织发生变化时应用程序的独立程度。
(2) 逻辑独立性。逻辑独立性是指用户的应用程序与数据库中的逻辑结构是相互独立的。当数据的逻辑结构改变时,应用程序不需要改变。
逻辑独立性存在于外模式和概念模式之间的映射转换,说明概念模式发生变化时应用程序的独立程度。
希赛教育专家提示:逻辑独立性比物理独立性更难实现。
3.2.2 数据模型
数据模型主要有两大类,分别是概念数据模型(实体—联系模型)和基本数据模型(结构数据模型)。
概念数据模型是按照用户的观点来对数据和信息建模,主要用于数据库设计。概念模型主要用实体—联系方法(Entity-Relationship Approach)表示,所以也称 E-R 模型。
基本数据模型是按照计算机系统的观点来对数据和信息建模,主要用于 DBMS 的实现。基本数据模型是数据库系统的核心和基础。基本数据模型通常由数据结构、数据操作和完整性约束三部分组成。其中数据结构是对系统静态特性的描述,数据操作是对系统动态特性的描述,完整性约束是一组完整性规则的集合。
常用的基本数据模型有层次模型、网状模型、关系模型和面向对象模型。
层次模型用树形结构表示实体类型及实体间的联系。层次模型的优点是记录之间的联系通过指针来实现,查询效率较高。层次模型的缺点是只能表示 1:n 联系,虽然有多种辅助手段实现 m:n 联系,但比较复杂,用户不易掌握。由于层次顺序的严格和复杂,导致数据的查询和更新操作很复杂,应用程序的编写也比较复杂。
网状模型用有向图表示实体类型及实体间的联系。网状模型的优点是记录之间的联系通过指针实现,m:n 联系也容易实现,查询效率高。其缺点是编写应用程序的过程比较复杂, 程序员必须熟悉数据库的逻辑结构。
关系模型用表格结构表达实体集,用外键表示实体间的联系。其优点有:
(1) 建立在严格的数学概念基础上;
(2) 概念(关系)单一,结构简单、清晰,用户易懂易用;
(3) 存取路径对用户透明,从而数据独立性、安全性好,简化数据库开发工作。
3.2.3 关系代数
关系代数的基本运算主要有并、交、差、笛卡尔积、选择、投影、连接和除法运算。
(1) 并。计算两个关系在集合理论上的并集,即给出关系 R 和 S(两者有相同元/列数),R∪S 的元组包括 R 和 S 所有元组的集合,形式定义如下:
RUSo{t|tÎRútÎS}
式中 t 是元组变量(下同)。显然,R∪S=S∪R。
(2) 差。计算两个关系的区别的集合,即给出关系 R 和 S(两者有相同元/列数),R-S的元组包括 R 中有而 S 中没有的元组的集合,形式定义如下:
R -So{t|tÎR ùtÏS}
(3) 交。计算两个关系集合理论上的交集,即给出关系 R 和 S(两者有相同元/列数),
R∩S 的元组包括 R 和 S 相同元组的集合,形式定义如下:
RISo{t |tÎRùtÎS}
显然,R∩S = R-(R-S) 和 R∩S = S-(S-R)成立。
(4) 笛卡尔积。计算两个关系的笛卡尔乘积,令 R 为有 m 元的关系,S 为有 n 元的关系,则 R×S 是 m+n 元的元组的集合,其前 m 个元素来自 R 的一个元组,而后 n 个元素来自 S 的一个元组。形成定义如下:
R′So{t |t=<tr,ts >ùtr ÎRùts ÎS}
若 R 有 u 个元组,S 有 v 个元组,则 R×S 有 u×v 个元组。例如,有关系 R 与关系 S 如表 3-1 和表 3-2 所示。
对 R 与 S 做笛卡尔积运算,其结果有 4+2=6 列,元组数量有 3*2=6 条。如表 3-3
所示。
![](https://img2018.cnblogs.com/blog/302746/201912/302746-20191220113835251-1022638206.png)
(5) 投影。从一个关系中抽取指明的属性(列)。令 R 为一个包含属性 A 的关系,
则
pA(R)o{t[A]|tÎR}
例如,对表 3-1 关系 R 做投影操作, p1,2(R),则结果如表 3-4 所示。
注意:在关系代数操作中涉及的数字代表的是列号,, p1,2(R)操作是对第 1 列与第 2
列做投影。
其中 F 表示选择条件,是一个逻辑表达式(逻辑运算符+算术表达式)。选择运算是从元组(行)的角度进行的运算。
(7)θ连接。θ连接从两个关系的笛卡儿积中选取属性之间满足一定条件的元组,记作:
![](https://img2018.cnblogs.com/blog/302746/201912/302746-20191220113926876-1891088961.png)
其中 A 和 B 分别为 R 和 S 上元数相等且可比的属性组。θ 为“=”的连接,称为等值连接,记作:
![](https://img2018.cnblogs.com/blog/302746/201912/302746-20191220113941344-667448889.png)
如果两个关系中进行比较的分量必须是相同的属性组,并且在结果中将重复的属性去掉, 则称为自然连接,记作:
例如,对表 3-1 关系 R 与表 3-2 关系 S 做自然连接操作。结果集如表 3-6 所示。
![](https://img2018.cnblogs.com/blog/302746/201912/302746-20191220114028403-210766086.png)
(8)除。设有关系 R(X,Y)与关系 S(Z),Y 和 Z 具有相同的属性个数,且对应属性出自相同域。关系 R(X,Y)÷S(Z)所得的商关系是关系 R 在属性 X 上投影的一个子集,该子
集和 S(Z)的笛卡尔积必须包含在 R(X,Y)中,记为 R÷S,其具体计算公式为:
![](https://img2018.cnblogs.com/blog/302746/201912/302746-20191220114043335-669115142.png)
例如,对表 3-1 的关系 R 与表 3-2 的关系 S 做除法运算。
求解过程为:首先,按除运算定义要求,确定 X,Y,Z 属性集合。Y 是关系 R 中的属性集合,Z 是 S 中全部属性的集合,即 Z={U3,U4},由于 Y=Z,因此,Y={U3,U4}, X={U1, U2}。也就是说,R÷S 结果集包含属性 U1 和 U2;然后,将关系 R 的 U1、U2(共有<a, b>、<c,a>两个元组)与关系 S 作笛卡尔积操作,结果如表 3-7 所示。
通过检查表 3-7,可以发现元组<a,b>与 S(Z)的笛卡尔积被包含在 R(X,Y)中,而元组
<c,a>与 S(Z)的笛卡尔积有一个元组未被包含在 R(X,Y)中,所以,结果集中只有元组<a, b>。
3.2.4 数据的规范化
关系模型满足的确定约束条件称为范式,根据满足约束条件的级别不同,范式由低到高分为 1NF(第一范式)、2NF(第二范式)、3NF(第三范式)、BCNF(BC 范式)、4NF(第四范式)等。不同的级别范式性质不同。
把一个低一级的关系模型分解为高一级关系模型的过程,称为关系模型的规范化。关系模型分解必须遵守两个准则。
(1) 无损连接性:信息不失真(不增减信息)。
(2) 函数依赖保持性:不破坏属性间存在的依赖关系。
规范化的基本思想是逐步消除不合适的函数依赖,使数据库中的各个关系模型达到某种程度的分离。规范化解决的主要是单个实体的质量问题,是对于问题域中原始数据展现的正规化处理。
规范化理论给出了判断关系模型优劣的理论标准,帮助预测模式可能出现的问题,是数据库逻辑设计的指南和工具,具体有:
(1) 用数据依赖的概念分析和表示各数据项之间的关系。
(2) 消除 E-R 图中的冗余联系。
- 函数依赖
通俗地说,就像自变量 x 确定之后,相应的函数值 f(x)也就唯一确定了一样,函数依赖是衡量和调整数据规范化的最基础的理论依据。
例如,记录职工信息的结构如下: 职工工号(EMP_NO)
职工姓名(EMP_NMAE) 所在部门(DEPT)。
则说 EMP_NO 函数决定 EMP_NMAE 和 DEPT,或者说 EMP_NMAE,DEPT 函数依赖于 EMP_NO,记为:EMP_NO→EMP_NMAE,EMP_NO→DEPT。
关系 R<U,F>中的一个属性或一组属性 K,如果给定一个 K 则唯一决定 U 中的一个元组,也就是 U 函数完全依赖于 K,就称 K 为 R 的码。一个关系可能有多个码,选中其中一个作为主码。
包含在任一码中的属性称为主属性,不包含在任何码中的属性称为非主属性。
关系 R 中的属性或属性组 X 不是 R 的码,但 X 是另一个关系模型的码,称 X 是 R的外码。
主码和外码是一种表示关系间关联的重要手段。数据库设计中一个重要的任务就是要找到问题域中正确的关联关系,孤立的关系模型很难描述清楚业务逻辑。
2.第一范式
1NF 是最低的规范化要求。如果关系 R 中所有属性的值域都是简单域,其元素(即属性)不可再分,是属性项而不是属性组,那么关系模型 R 是第一范式的,记作 RÎ1NF。这一限制是关系的基本性质,所以任何关系都必须满足第一范式。第一范式是在实际数据库设计中必须先达到的,通常称为数据元素的结构化。
例如,表 3-8 所示的结构就不满足 1NF 的定义。
![](https://img2018.cnblogs.com/blog/302746/201912/302746-20191220114846421-1734437570.png)
表 3-8 为非第一范式,分解如表 3-9 所示。
![](https://img2018.cnblogs.com/blog/302746/201912/302746-20191220114920923-2037665764.png)
就满足了第一范式。经过处理后,就可以以省、市为条件进行查询和统计了。
满足 1NF 的关系模型会有许多重复值,并且增加了修改其数据时引起疏漏的可能性。为了消除这种数据冗余和避免更新数据的遗漏,需要更加规范的 2NF。
3.第二范式
如果一个关系 R 属于 1NF,且所有的非主属性都完全依赖于主属性,则称之为第二范式,记作RÎ2NF。
为了说明问题,现举一个例子来说明:
有一个获得专业技术证书的人员情况登记表结构为:
省份、姓名、证书名称、证书编号、核准项目、发证部门、发证日期、有效期。
这个结构符合 1NF,其中“证书名称”和“证书编号”是主码,但是因为“发证部门” 只完全依赖于“证书名称”,即只依赖于主关键字的一部分(即部分依赖),所以它不符合 2NF, 这样首先存在数据冗余,因为证书种类可能不多。其次,在更改发证部门时,如果漏改了某 一记录,存在数据不一致。再次,如果获得某种证书的职工全部跳槽了,那么这个发证部门 的信息就可能丢失了,即这种关系不允许存在某种证书没有获得者的情况。
可以用分解的方法消除部分依赖的情况,而使关系达到 2NF 的标准。方法是,从现有关系中分解出新的关系表,使每个表中所有的非关键字都完全依赖于各自的主关键字。可以分解成两个表(省份、姓名、证书名称、证书编号、核准项目、发证日期、有效期)和(证书名称、发证部门),这样就完全符合 2NF 了。
4.第三范式
如果一个关系 R 属于 2NF,且每个非主属性不传递依赖于主属性,这种关系是 3NF, 记作 RÎ3NF。
从 2NF 中消除传递依赖,就是 3NF。例如,有一个表(职工姓名,工资级别,工资额),其中职工姓名是关键字,此关系符合 2NF,但是因为工资级别决定工资额,也就是说非主属性“工资额”传递依赖于主属性“职工姓名”,它不符合 3NF,同样可以使用投影分解的办法分解成两个表:(职工姓名,工资级别),(工资级别,工资额)。
5.BC 范式
一般满足 3NF 的关系模型已能消除冗余和各种异常现象,获得比较满意的效果,但无论 2NF 还是 3NF 都没有涉及主属性间的函数依赖,所以有时仍会引起一些问题。由此引入 BC 范式(由 Boyeet 和 Codd 提出)。通常认为 BCNF 是第三范式的改进。
BC 范式的定义:如果关系模型 R∈1NF,且 R 中每一个函数依赖关系中的决定因素都包含码,则 R 是满足 BC 范式的关系,记作 RÎBCNF。
当一个关系模型 R BCNF,则在函数依赖范畴里,就认为已彻底实现了分离,消除了插入、删除的异常。
综合 1NF、2NF 和 3NF、BCNF 的内涵可概括如下:
(1) 非主属性完全函数依赖于码(2NF 的要求);
(2) 非主属性不传递依赖于任何一个候选码(3NF 的要求);
(3) 主属性对不含它的码完全函数依赖(BCNF 的要求);
(4) 没有属性完全函数依赖于一组非主属性(BCNF 的要求)。
3.2.5 反规范化
数据库中的数据规范化的优点是减少了数据冗余,节约了存储空间,相应逻辑和物理的I/O 次数减少,同时加快了增、删、改的速度,但是对完全规范的数据库查询,通常需要更多的连接操作,从而影响查询速度。因此,有时为了提高某些查询或应用的性能而破坏规范规则,即反规范化(非规范化处理)。
常见的反规范化技术包括:
(1) 增加冗余列
增加冗余列是指在多个表中具有相同的列,它常用来在查询时避免连接操作。例如:以规范化设计的理念,学生成绩表中不需要字段“姓名”,因为“姓名”字段可以通过学号查询到,但在反规范化设计中,会将“姓名”字段加入表中。这样查询一个学生的成绩时,不需要与学生表进行连接操作,便可得到对应的“姓名”。
(2) 增加派生列
增加派生列指增加的列可以通过表中其他数据计算生成。它的作用是在查询时减少计算量,从而加快查询速度。例如:订单表中,有商品号、商品单价、采购数量,我们需要订单总价时,可以通过计算得到总价,所以规范化设计的理念是无须在订单表中设计“订单总价”字段。但反规范化则不这样考虑,由于订单总价在每次查询都需要计算,这样会占用系
统大量资源,所以在此表中增加派生列“订单总价”以提高查询效率。
(3) 重新组表
重新组表指如果许多用户需要查看两个表连接出来的结果数据,则把这两个表重新组成一个表来减少连接而提高性能。
(4) 分割表
有时对表做分割可以提高性能。表分割有两种方式。
水平分割:根据一列或多列数据的值把数据行放到两个独立的表中。水平分割通常在下面的情况下使用。
情况 1:表很大,分割后可以降低在查询时需要读的数据和索引的页数,同时也降低了索引的层数,提高查询效率。
情况 2:表中的数据本来就有独立性,例如表中分别记录各个地区的数据或不同时期的数据,特别是有些数据常用,而另外一些数据不常用。
情况 3:需要把数据存放到多个介质上。
垂直分割:把主码和一些列放到一个表,然后把主码和另外的列放到另一个表中。如果一个表中某些列常用,而另外一些列不常用,则可以采用垂直分割,另外垂直分割可以使得数据行变小,一个数据页就能存放更多的数据,在查询时就会减少 I/O 次数。其缺点是需要管理冗余列,查询所有数据需要连接操作。
3.3 数据库设计
数据库设计的过程是将数据库系统与现实世界密切地、有机地、协调一致地结合起来的过程。数据库的设计质量与设计者的知识、经验和水平密切相关。作为数据库应用系统的重要组成部分,数据库设计的成败往往直接关系到整个应用系统的成败。
以数据库为基础的数据库应用系统与其他计算机应用系统相比往往具有数据量庞大、数据保存时间长、数据关联复杂、用户要求多样化等特点。
数据库设计中面临的主要困难和问题有:
(1) 同时具备数据库知识与应用业务知识的人很少。懂得计算机与数据库的人一般都缺乏应用业务知识和实际经验,而熟悉应用业务的人又往往不懂计算机和数据库。
(2) 项目初期往往不能确定应用业务的数据库系统的目标。
(3) 缺乏完善的设计工具和设计方法。
(4) 需求的不确定性。用户总是在系统的开发过程中不断提出新的要求,甚至在数据库建立之后还会要求修改数据库结构或增加新的应用。
(5) 应用业务系统千差万别,很难找到一种适合所有业务的工具和方法,这就增加了研究数据库自动生成工具的难度。因此,研制适合一切应用业务的全自动数据库生成工具是不可能的。