系统架构设计师学习笔记 第三章

第三章 数据库系统

3.1 数据库管理系统的类型

通常有多个分类标准。如按数据模型分类、按用户数分类、按数据库分布站点分类等。我们需要了解的是按数据模型分类。

当前,主流数据模型为关系数据模型。常见的DBMS按数据模型划分,包括:关系型DBMS、文档型DBMS、键值型DBMS、对象型DBMS等。

3.2 数据库模式与范式

3.2.1 数据库的接口与模式

1. 三级抽象

数据库系统划分为三个抽象级:用户级、概念级、物理级。

  1. 用户级数据库。对应于外模式,是最接近用户的一级数据库,是用户可以看得到和使用的数据库,又称用户视图。主要由外部记录组成,不同的用户视图可以互相重叠,用户的所有操作都是针对用户视图进行的。
  2. 概念级数据库。对应于概念模式。介于用户级和物理级之间,是所有用户视图的最小并集,是数据库管理员可以看到和是哟经的数据库,又称DBA视图。由概念记录组成,一个数据库可以有不同的用户视图,每个用户视图由数据库某一部分的抽象表示所组成,一个是数据库应用系统只存在一个DBA视图,他把数据库作为一个整体的抽象表示,概念机模式把用户视图有机结合成一个整体,综合平衡考虑所有用户要求,实现数据的一致性,最大限度降低数据冗余,准确的反映数据间的联系。
  3. 物理级数据库。对应于内模式,是数据库的低层表示,描述数据的实际存储组织,是最接近物理存储的级,又称内部视图。物理级数据库由内部记录组成,物理级数据库并不是真正的物理存储,而是最接近于物理存储的级。

2. 三级模式

三级模式为内模式、概念模式、内模式。

  1. 概念模式。(模式、逻辑模式)用以描述整个数据库中数据库的逻辑结构,描述现实世界中的实体及其性质和联系,定义记录、数据项、数据的完整性约束条件及记录之间的联系,是数据项值的框架。
    数据库系统概念模式通常还包含有访问控制、保密定义、完整性检查等方面的内容,以及概念/物理之间的映射。
    概念模式是数据库中全体数据的逻辑结构和特征的描述,是所有用户的公共数据视图,一个数据库只有一个概念模式。
    外模式是数据库用户(包括程序员和最终用户)能够看见和使用的局部数据的逻辑结构和特征的描述,是数据库用户的数据视图,是与某一应用 有关的数据库的逻辑表示,一个数据库可以有多个外模式,一个应用程序只能使用一个外模式。
  2. 外模式。(子模式、用户模式)用以描述用户看到或使用的那部分数据的逻辑结构,用户根据外模式用数据操作语句或应用程序去操作数据库中的数据。外模式主要描述组成用户视图的各个记录的组成、相互关系、数据项的特征、数据的安全性和完整性约束条件。
  3. 内模式。内模式是整个数据库的最低层表示,不同于物理层。它假设外存是一个无限的线性地址空间。内模式定义的是存储记录的类型、存储域的表示以及存储记录的物理顺序,指引元、索引和存储路径等数据的存储组织。
    内模式是数据物理结构和存储方式的描述,是数据在数据库内部的表示方式,一个数据库只有一个内模式。

内模式、模式和外模式之间的关系如下:

  1. 模式是数据库的中心与关键;
  2. 内模式依赖于模式,独立于外模式和存储设备。
  3. 外模式面向具体的应用,独立于内模式和存储设备。
  4. 应用程序依赖于外模式,独立于模式和内模式。

两级独立性

指数据库独立性和逻辑独立性。三个抽象级间通过两级映射(外模式——模式映射,模式——内模式映射)进行相互转换,值得数据库的三级形成一个统一的整体。

  1. 物理独立性。是指用户的应用程序与存储在磁盘上的数据库中的数据是相互独立的。当数据的物理存储改变时,应用程序不需要改变。
    物理独立性存在于概念模式和内模式之间的映射转换,说明物理组织发生变化时应用程序的独立程度。
  2. 逻辑独立性。是指用户的应用程序与数据库中的逻辑结构是相互独立的。当数据库的逻辑结构改变时,应用程序不需要改变。
    逻辑独立性存在于外模式和概念模式之间的映射转换,说明概念模式发生变化时应用程序的独立程度。

逻辑独立性要比物理独立性更难实现。

3.2.2 数据模型

主要有两大类,分别是概念数据模型(实体-联系模型)和基本数据模型(结构数据模型)

概念数据模型是按照用户的观点来对数据和信息建模,主要用于数据库设计。概念模型主要用实体——联系方法表示,所以也称E-R模型。

基本数据模型是按照计算机系统的观点来对数据和信息建模,主要用于DBMS的实现。基本数据模型是数据库系统的核心和基础。基本数据模型通常由数据结构、数据操作和完整性约束三部分组成。其中数据结构是对系统静态特性的描述,数据操作是对系统动态特性的描述,完整性约束是一组完整性规则的集合。

常用的基本数据模型有层级模型、网状模型、关系模型和面向对象模型。

层次模型用树形结构表示实体类型及实体间的联系。层次模型的优点是记录之间的联系通过指针来实现,查询效率较高。层次模型的缺点是只能表示1:n联系,虽然有多种辅助手段实现m:n联系,但比较复杂,用户不易掌握。由于层次顺序的严格和复杂,导致数据的查询和更新操作很复杂,应用程序的编写也比较复杂。

网状模型是用有向图表示实体类型和实体间的联系。网状模型的优点是记录之间的联系通过指针实现,m:n联系也容易实现,查询效率高。其缺点是编写应用程序的过程比较复杂,程序变必须数据数据库的逻辑结构。

关系模型用表格结构表达实体集,用外键表示实体间的联系。其优点有:

  1. 建立在严格的数学概念基础上;
  2. 概念(关系)单一,结构简单清晰,用户易懂易用;
  3. 存取路径对用户透明,从而数据独立性、安全性好,简化数据库开发工作

3.2.3 关系代数

关系代数的基本运算主要有并、交、差、笛卡尔积、选择、投影、连接和除法运算。

  1. 并。计算两个关系在集合理论上的并集,即给出关系$R$和$S$(两者有相同元/列数),$R\cup S$的元组包括$R$和$S$所有元组的集合,形式定义如下(也就是数据库中的union):
    $$R\cup S\equiv {t|t\in R\lor t\in S}$$
    式中$t$是元组变量(下同)。显然$R\cup S=S\cup R$。
  2. 差。计算两个关系的区别的集合。即给出关系$R$和$S$(两者有相同元/列数),$R-S$的元组包括$R$中有而$S$中没有的元组的集合,形式定义如下(也就是数据库中的not exists):
    $$R-S\equiv {t|t\in R\land t\notin S}$$
  3. 交。计算两个关系集合理论上的交集,即给出$R$和$S$(两者有相同元/列数),$R\cap S$的元组包括$R$和$S$相同元组的集合,形式定义如下(也就是数据库中的inner join):
    $$R\cap S\equiv {t|t\in R\land t\in S}$$
    显然,$R\cap S=R-(R-S)$和$R\cap S=S-(S-R)$成立。
  4. 笛卡尔积。计算两个关系的笛卡尔乘积,令$R$为有$m$元的关系,$S$为有$n$元的关系,则$R\times S$是$m+n$元的元组的集合,其前$m$个元素来自$R$的一个元组,而后$n$个元素来自于$S$的一个元组。形成定义如下:
    $$R\times S\equiv {t|t\le t_r,t_s>\land t_r\in R\land t_s\in S}$$
    若$R$有$u$个元组,$S$有$v$个元组,则$R\times S$有$u\times v$个元组。
  5. 投影。从一个关系中抽取指明的属性(列)。令$R$为一个包含属性$A$的关系,则:
    $$\pi_A(R)\equiv {t[A]|t\in R}$$
  6. 选择。从关系$R$中抽取满足给定限制条件的记录,记作:
    $$\sigma_F(R)\equiv {t|t\in R\land F(t)=true}$$
    其中F表示选择条件,是一个逻辑表达式(逻辑运算符+算数运算符)。选择运算是从元组(行)的角度进行的运算。
  7. $\theta$连接,$\theta$从两个关系的笛卡尔积中选取属性之间满足一定条件的元组。如果两个关系中进行比较的分量必须是相同的属性组,并且在结果中将重复的属性去掉,则成为自然连接。
  8. 除。

3.2.4 数据的规范化

关系模型满足的确定约束条件为范式,根据满足约束条件的级别不同,范式由低到高分为1NF(第一范式)、2NF(第二范式)、3NF(第三范式)、BCNF(BC范式)、4NF(第四范式)等。不同级别范式性质不同。

把一个低一级的关系模型分解为高一级关系模型的过程,称为关系模型的规范化。关系模型分解必须遵守两个准则。

  1. 无损连接性:信息不失真(不增减信息)。
  2. 函数依赖保持性:不破坏属性间存在的依赖关系。

规范化的基本思想是逐步消除不合适的函数依赖,使数据库中的各个关系模型达到某种程度的分离。规范化解决的主要是单个实体的质量问题,是对于问题域中原始数据展现的正规化处理。

规范化理论给出了判断关系模型优劣的理论标准,帮助预测模型可能出现的问题,是数据库逻辑设计的指南和工具。具体有:

  1. 用数据依赖的概念分析和表示各数据项之间的关系。
  2. 消除E-R图中的冗余联系。

1. 函数依赖

就像是自变量x确定以后,相应的函数值f(x)也就唯一确定了一样,函数依赖就是衡量和调整数据规范化的最基础的理论依据。

关系$R<U$,$F>$中的一个属性或一组属性$K$,如果给定给一个$K$则唯一确定$U$中的一个元组,也就是$U$函数完全依赖于$K$,就称$K$为$R$的码。一个关系可能有多个码,选中其中一个作为主码。

包含在任一码中的属性称为主属性,不包含在任何码中的属性称为非主属性。

关系R中的属性或属性组X不是R的码,但X是另外一个关系模型的码,称X是R的外码。

主码和外码就是数据库中的主键和外键。

2. 第一范式

1NF是最低的规范化要求。如果关系R中所有属性的值域都是简单域,其元素(即属性)不可再分,是属性项而不是属性组,那么关系模型R是第一范式的,记作$R\in 1NF$。

这一限制是关系的基本性质,所以任何关系都必须满足第一范式。第一范式是实际数据库涉及中必须先达到的,通常称为数据元素的结构化。

满足第一范式的关系模型会有许多重复值,并且增加了修改其数据时引起疏漏的可能性。为了消除这种数据冗余和避免更新数据的遗漏,需要更加规范的2NF。

3. 第二范式

如果一个关系R属于1NF,且所有的非主属性都完全依赖于主属性,则称之为第二范式,记作$R\in 2NF$。

4. 第三范式

如果一个关系R属于2NF,且每个非主属性不传递依赖于主属性,这种关系是3NF,记作$R\in 3NF$。

5. BC范式

一般满足3NF的关系模型已经消除冗余和各种异常现象,获得比较满意的结果,但无论是2NF还是3NF都没有涉及主属性间的函数依赖,所以有时仍会引起一些问题。由此引入BC范式。通常认为是第三范式的改进。

定义:如果关系模型$R\in 1NF$,且R中的每一个函数依赖关系中的决定因素都包含码,则R是满足BC范式的关系,记作$R\in BCNF$。

当一个关系模型$R\in BCNF$,则在函数依赖范畴内,救认为已彻底实现了分离,消除了插入、删除的异常。

结合1NF、2NF和3NF、BCNF的内涵可概括如下:

  1. 非主属性完全函数依赖于码(2NF的要求)。
  2. 非主属性不传递依赖于任何一个候选码(3NF的要求)。
  3. 主属性对不包含他的码完全函数依赖(BCNF的要求)。
  4. 没有属性完全函数依赖于一组非主属性(BCNF的要求)。

3.2.5 反规范化

数据库中的数据规范化的优点是减少了数据冗余,节约了存储空间,相应逻辑和物理的I/O次数减少,同时加快了增删改查的速度,但是对完全规范的数据库查询,通常需要更多的连接操作,从而影响查询速度。因此,有时为了提高某些查询或应用的性能而破坏规范规则,即反规范化(非规范化处理)。常见的反规范化技术包括:

  1. 增加冗余列
    指多个表中具有相同的列,它常用来在查询时避免连接操作。
  2. 增加派生列
    指增加的列可以通过表中其他数据计算生成,它的作用是在查询时减少计算量,从而加快查询速度。
  3. 重新组表
    指如果许多用户需要查看两个表连接起来的结果数据,则把这两个表重新组成一个表来减少连接而提高性能。
  4. 分割表
    水平分割:根据一列或多列数据的值把数据航放到两个独立的表中。水平分割通常在如下的情况下使用。
  • 表很大,分割后可以降低在查询时需要读的数据和索引的页数,同时也降低索引的层数,提高查询效率。
  • 表中的数据本来就有独立性。
  • 需要把数据存放到多个介质上。
    垂直分割:把主码和一些列放到一个表,然后把主码和另外的列放到另一个表中。如果一个表中某些列常用,而另外一些列不常用,则可以采用垂直分割。另外垂直分割可以使得数据行变小,一个数据页就能存放更多的数据,在查询时就会减少I/O次数。其缺点是需要管理冗余列,查询所有数据需要连接操作。

3.3 数据库设计

数据库设计的过程是将数据库系统与现实世界密切的、有机的、协调一致的结合起来的过程。数据库的设计质量与设计者的知识、经验和水平密切相关。

以数据库为基础的数据库应用系统与其他计算机应用系统相比往往具有数据量庞大、数据保存时间长、数据关联复杂、用户要求多样化等特点。

数据库设计中面临的主要困难和问题有:

  1. 同时具备数据库知识和应用知识的人很少。懂得计算机与数据库的人一般都缺乏应用知识和实际经验,而熟悉应用业务的人又往往不懂计算机和数据库。
  2. 项目初期往往不能确定应用业务的数据库系统的目标。
  3. 缺乏完善的设计工具和设计方法。
  4. 需求的不确定性。用户总是在系统的开发过程中不断提出新的要求,甚至在数据库建立之后还会要求修改数据库结构或增加新的应用。
  5. 应用业务系统千差万别,很难找到一种适合所有业务的工具和方法,这就增加了数据库自动生成工具的难度。因此,研制适合一切应用业务的全自动数据库生成工具是不可能的。

3.3.1 数据库设计的方法

目前已有的数据库设计方法可分为四类,即直观设计法、规范设计法、计算机辅助设计法和自动化设计法。直观设计法又称单步逻辑设计法,它依赖于设计者的知识、经验和技巧,缺乏工程规范的支持和科学依据,设计质量也不稳定,因此越来越不适应信息管理系统发展的需求。因此,将数据库设计规范分为需求分析、概念结构分析、逻辑结构设计和物理结构设计4个阶段。

基于3NF的数据库设计方法基本思想是在需求分析的基础上,识别并确认数据库模式中的全部属性和属性间的依赖,将它们组织成一个单一的关系模型,然后再分析模式中不符合3NF的约束条件,用投影和连接的办法将其分解,使其达到3NF条件。

  1. 设计企业模式。利用上述得到的3NF关系模型画出企业模式。具体包括:
  • 分析应用环境,并设定环境中所使用的各种资料。
  • 确定每一种报表各自所包含的数据元素。
  • 确定数据元素之间的关系,如确定主关键字和一般的数据元素。
  • 对每一组或若干组数据元素推导出3NF的关系模型。
  • 在3NF关系模型的基础上画出数据库的企业模式。
  1. 设计数据库逻辑模式。根据上一步得到的企业模式选定数据模型,从而得出适用于某种DBMS的逻辑模式。根据逻辑模式导出各种报表与事务处理所使用的外模式。
  2. 设计数据库物理模式(存储模式)。根据数据库的逻辑模式和给定的计算机系统设计物理模式。
  3. 评价物理模式。对物理模式估算空间使用情况,并推算输入输出的概率。必要时根据物理模式调整各种报表和事务处理的外模式。对外模式进行存取时间的估算。
  4. 数据库实现。具体实现数据库。

3.3.2 数据库设计的基本步骤

分步设计法遵循自顶向下、逐步求精的原则,将数据库设计过程分解为若干相互独立又相互依存的阶段,每一阶段采用不同的技术与工具,解决不同的问题,从而将问题局部化,减少了局部问题对整体设计的影响。

在分步设计法中,通常将数据库的设计分为需求分析、概念结构设计、逻辑结构设计和数据库物理设计4个阶段。

1. 需求分析

指收集和分析用户对系统的信息需求和处理需求,得到设计系统所必需的需求信息,建立系统说明文档。其目标是通过检查研究,了解用户的数据要求和处理要求,并按一定格式整理成需求说明书。需求说明书是需求分析阶段的成果,也是今后设计依据,它包括数据库所涉及的数据、数据的特征、使用的频率和数据量的估计。这些关于数据的数据称为元数据。在设计大型数据库时,这些数据通常由数据字典来管理。

2. 概念结构设计

是数据库设计的第二阶段,目标是对需求说明书提供的所有数据和处理要求进行抽象和综合处理,按一定的方法构造反映用户环境的数据及其相互联系的概念模型,即用户的数据模型或企业数据模型。这个数据模型与DBMS无关。

3. 逻辑结构设计

设计目标是把上一阶段得到的与DBMS无关的概念数据模型转换成等价的,并为某个特定的DBMS所接受的逻辑模型所表示的概念模式,同时将概念设计阶段得到的应用视图转换成外部模式,即特定DBMS下的应用视图。该阶段的结果是DDL脚本。

4. 数据库物理设计

把逻辑设计阶段得到的满足用户需求的已确定的逻辑模型在物理上加以实现,主要内容是根据DBMS提供的各种手段,设计数据库的存储形式和存取路径,即设计数据库的内模式或存储模式。

数据库设计的基本过程和任何复杂系统开发一样,在每一阶段设计基本完成后,都要进行认真的检查,看是否满足应用需求,是否符合前面已执行步骤的要求和满足后续步骤的需要,并分析设计结果的合理性。在每一步设计中,都可能发现前面步骤的遗漏或处理不当之处,此时,往往需要返回去重新处理并修改设计和有关文档。所以,数据库设计过程通常是一个反复修改,反复设计的的迭代过程。

3.3.3 需求分析

需求分析是数据库设计过程中的第一步,是整个数据库设计的依据和基础。目标是通过对单位的信息需求和处理要求的调查分析得到设计数据库所需的数据集及其相互联系,形成需求说明书,作为后面各设计阶段的基础。因此,这一阶段的任务是:

1. 确认需求、确认设计目标

2. 分析和收集数据

3. 整理文档

3.3.4 概念结构设计

该阶段所涉及的信息不依赖于任何实际实现时的环境,即计算机的硬件和软件系统。目标是产生一个用户易于理解的,反应系统信息需求的整体数据库概念结构。任务是,在需求分析中产生的需求说明书的基础上按照一定的方法抽象成满足应用需求的用户的信息结构,即通常所称的概念模型。概念结构的设计过程就是正确选择设计策略、设计方法和概念数据模型并加以实施的过程。

作用是:提供能够识别和理解系统要求的框架;为数据库提供一个说明性结构,作为设计数据库逻辑结构,即逻辑模型的基础。

设计策略主要有自底向上、自顶向下、由里向外和混合策略。在具体实现设计目标时有两种极端的策略或方案,一是建立一个覆盖整个单位所有功能域的全局数据库,称之为全局方案或全局策略;另一种则是对每一个应用都建立一个单独的数据库,称为应用方案或应用策略。

1. 视图设计

在视图分析法中,局部视图设计的第一步是确定其所属的范围,即它所对应的用户组,然后对每个用户组建立一个仅由实体、联系及他们的标识码组成的局部信息结构(局部数据模式)框架,最后再加入有关的描述信息,形成完整的局部视图(局部数据模式)。这样做的目的是为了集中精力处理好用户数据需求的主要方面,避免因无关紧要的描述细节而影响局部信息结构的正确性。整个过程可分为4个步骤:确定局部视图的范围;识别实体及其标识;确定实体间的联系;分配实体及联系的属性。

  1. 确定局部视图的范围。
    需求说明书中标明的用户视图范围可以作为确定局部视图范围的基本依据,但它通常与子模式范围相对应。范围确定的基本原则是:
  • 各种局部视图支持的功能域之间的联系应最少。
  • 实体个数适量。一个局部视图所包含的实体数量反映了该局部视图的复杂性,按照信息论中“$7\pm2$”的观点,人们在同一时刻可同时顾及的事情一般在5~9个之间,其中以6或7最为适当。因此,一个局部视图内的实体数不宜超过9个。
  1. 识别实体及其标识。
    任务是在确定的局部视图范围内,识别哪些数据对象作为局部视图的基本试题及其标识,并定义有关数据对象在E-R模型中的地位。
  2. 确定实体间的联系。
    定义联系就是对联系语义的仔细分析,识别联系的类型,确定实体在联系中的参与度。
  1. 二元联系的类型与定义。二元联系是指两个实体类之间的联系。根据参与联系的两个实体类值之间的对应关系分为一对一、一对多即多对多三种类型。
  • 一对一联系。
  • 一对多联系。
  • 多对多联系
  • 实体内部的联系
  1. 多元联系的识别与定义。两个以上的实体类之间的联系称为多元联系。

2. 视图集成

就是要将反映各用户组数据的局部数据模式综合成单位中某个确定范围内的单一数据视图,即全局数据模式,又称模式汇总。当所有局部视图设计完毕,就可开始试图集成,集成过程中会发生一些冲突,冲突的表现和处理策略如下:

  1. 同名异义。为了发现不同视图间的同名异义问题,可以列出所有同名数据对象,然后逐一辨别其语义。对同名异义冲突通常采用换名加以解决,即可对同名者之一换名,也可对两者都给以重新命名。识别语义的主要方法是进行值域分析。
  2. 异名同义。识别异名同义比较困难,一般由设计者对所有对象一个不漏的逐一鉴别。它同样采用换名的方法解决。若归并时试图将它们合并为一个对象,则可以把其中之一的名称作为合并后的对象名;若集成后,他们仍以两个不同的对象存在,则可对其一换名。当然,若原名都不合适,则可对两者都重新命名。
  3. 同名不同层次。如果两个对象同名,但其中之一作为一个视图中的实体,而另一个是另一视图中的属性,则在集成时会发生同名不同层次的冲突。解决这种冲突的办法有两个,一是将属性转换为实体,二是将实体变换成属性。

实体变换为属性时通常需要满足一些特定条件,例如,该实体工厂只含有一个与同名属性具有共同特征的属性,且一定存在一个与该实体存在联系的另外的实体。

  1. 虽同名同义,但对象联系测度不同。所谓联系测度是指实体联系是一对一、一对多还是多对多。若同名同义对象在一个局部视图中为一对多联系,在另一局部视图中为多对多联系,则在集成时会发生联系测度冲突。一般而言,一对多包含一堆一,多对多包含一对多。所以解决这种冲突的办法往往取较高测度为集成后的相应联系的测度。

3.3.5 逻辑结构设计

任务是把概念结构设计阶段设计好的基本E-R图转换为与其具体机器上的DBMS产品所支持的数据模型相符合的逻辑结构。这一阶段是数据库结构设计的重要阶段。

基础是概念设计的结果,成果应包括某DBMS所支持的外模式、概念模式及其说明和建立外模式和概念模式的DDL程序。

逻辑结构设计一般分为以下几个步骤:

  1. 将概念结构向一般关系模型转化。
  2. 将第一步得到的结构向特定的DBMS支持下的数据模型转换。
  3. 根据应用的需求和具体的DBMS的特征进行调整和完善。

1. 基本E-R模型向关系模型的转换

基本E-R模型主要包含实体和联系两个抽象概念,实体和联系本身还可能附有若干属性,其转换的基本原则是,实体和联系分别转换成关系,属性这转换成相应关系的属性。

  1. 一对一联系
  2. 一对多联系
  3. 多堆垛联系。由两个实体类之间多对多联系组成的E-R模型向关系模型转换时,将两个实体类和一个联系类分别转换成关系,实体类的属性分别转换成对应关系的属性,其标识属性转换为其关键字,由联系类转换得到的关系的属性有两个实体类的标识属性和联系类本身的属性组成,其关键字是有两个联系的实体类的标识属性组成。
  4. 多元联系。实体类分别转换为相应的关系,三个实体类间的多元联系转换为以该联系名为关系名的关系,关系的属性由各实体的标识属性及其联系的属性组成,并以各实体的标识属性为其关键字。
  5. 自联系。是同一实体集的不同实体间的联系。
  6. 弱实体类的转换。一个实体类,如果它的存在依赖于另一个实体类,则称之为弱实体类。

2. 数据模型的优化

优化的内容是改善数据库的性能和节省存储空间两个方面。

  1. 改善数据库性能的考虑。
  1. 减少连接运算。连接运算对关系数据库的查询速度有着重要的影响,连接的关系越多,参与连接的关系越大,开销也越大,因而查询速度也越慢。对于一些常用的、性能要求较高的数据库查询,最好是一元查询,称为逆规范化。
  2. 减少关系大小及数据量。被查询的关系大小对查询速度影响较大。为了提高查询速度,可以采用水平分割或垂直分割等方法把一个关系分成几个关系,使每个关系的数据量减少。
  3. 尽量使用快照。快照是某个用户所关心的那部分数据,与视图一样是一种导出关系,但它与视图有两点不同:一是视图是虚关系,数据库中并不存储作为视图的导出关系,仅仅保留它的定义,快照则是一个由系统事先生成后保留在数据库中的实关系;二是视图随数据当前值的变化而变化,快照则不随原来关系中数据的改变而及时改变。它只反映数据库中某一时刻的状态,不反应数据库的当前状态。快照不是一成不变的,它可以由系统周期性的刷新,或由用户用命令刷新。
  1. 节省存储空间的一些考虑。
  1. 缩小每个属性占用的空间。两种方法:用编码和用缩写符号表示属性。
  2. 采用假属性。可以减少重复数据占用的存储空间。

3.3.6 物理结构设计

数据库在实际的物理设备上的存储结构和存取方法称为数据库的物理结构。数据库物理设计是利用已确定的逻辑结构及DBMS提供的方法、技术,以较优的存储结构、数据存取路径、合理的数据存储位置及存储分配,设计出一个高效的、可实现的物理数据库结构。数据库的物理设计完全依赖于给定的硬件环境和数据库产品。

为设计出一个较好的存储模式,设计者必须了解一下几个方面的问题,做到心中有数。

  1. 了解并熟悉应用要求,包括各个用户对应的数据视图,即数据库的外模式(子模式),分清哪些是主要的应用,了解各个应用的使用方式、数据量和处理频率等,以便对时间和空间进行平衡,并保证优先满足应用的时间要求。
  2. 熟悉使用的DBMS的性能,包括DBMS的功能,提供的物理环境、存储结果、存取方法和可利用的工具。
  3. 了解存放数据的外存设备的特性,如物理存储区域的划分原则,物理块的大小等有关规定及I/O特性等。

3.4 事务管理

数据库系统运行的基本工作单位是事务。事务相当于操作系统中的进程,是用户定义的一个数据库操作序列,要么全做,要么全不做。数据库具有以下特性:

  1. 原子性Atomicity:数据库的逻辑工作单位。
  2. 一致性Consistency:使数据库从一个一致性状态变到另一个一致性状态。
  3. 隔离性Isolation:不能被其他事务干扰。
  4. 持久性Durability:一旦提交,改变就是永久性的。

数据库事务的使用方式,这里就不写了。

3.4.1 并发控制

在多用户共享系统中,许多事务是可能同时对同一数据进行操作,称为“并发操作”。

数据库并发操作带来的问题有:丢失更新问题、不一致分析问题(读过时的数据)、依赖于未提交更新的问题(读了“脏”数据)。

处理并发控制的主要方法是采用封锁技术。它有两种类型:排他型封锁(X封锁)和共享型封锁(S封锁),分别介绍如下:

  1. 排他型封锁(X封锁)。如果事务T对数据A(可以是数据项、记录、数据集乃至整个数据库)实现了X封锁,那么只允许事务T读取和修改数据A,其他事务要等事务T解除X封锁之后,才能对数据A实现任何类型的封锁。
  2. 共享型封锁(S封锁)。X封锁只允许一个事务独锁和使用数据,要求太严,需要适当放宽,例如可以允许并发读,但不允许修改,这就产生了S封锁概念。S封锁的含义是:如果事务T对数据A实现了S封锁,那么允许事务T读取数据A,但不能修改数据A,在所有S封锁解除前决不允许任何事务对数据A实现X封锁。

在多个事务并发执行的系统中,主要采取封锁协议来进行处理。

  1. 一级封锁协议。事务T在修改数据R之前必须先对其加X锁,直到事务结束才释放。一级封锁协议可防止丢失修改,并保证事务T是可以恢复的。但不能保证可重复读和不读“脏”数据。
  2. 二级封锁协议。一级封锁协议加上事务T在读取数据R之前先对其加S锁,读完后即可释放S锁。二级封锁协议可防止丢失修改,还可防止读“脏”数据,但不能保证可重复读。
  3. 三级封锁协议。一级封锁协议加上事务T在读取数据R之前先对其加S锁,直到事务结束才释放。三级封锁协议可以方式丢失修改、防止读”脏“数据与防止数据重复读。
  4. 两段锁协议。所有事务必须分两个阶段对数据项加锁和解锁。其中扩展阶段是在对任何数据进行读、写操作之前,首先要申请并获得对该数据的封锁;收缩阶段是在释放一个封锁之后,事务不能再申请和获得任何其他封锁。若并发执行的所有事务均遵守两段封锁协议,则对这些事务的任何并发调度策略都是可串行化的。遵守两段封锁协议的事务可能发生死锁。

下面讨论封锁的粒度。所谓封锁的粒度即是被封锁数据目标的大小。在关系数据库中,封锁粒度有属性值、属性值集、元组、关系、某索引项(或整个索引)、整个关系数据库、物理页(块)等几种。

封锁粒度小则并发性高,但开销大;封锁粒度大则并发性低,但开销小。

采用封锁的方法会带来死锁问题。

  1. 预防法。采用一定的操作方式以保证避免死锁的出现,顺序申请法、一次申请法等即是此类方法。所谓顺序申请法是指对封锁对象按序编号,在用户申请封锁时必须按编号顺序(从小到大或反之)申请,这样能避免死锁发生。所谓一次申请法即是指用户在一个完整操作过程中必须一次性申请它所需要的所有封锁,并在操作结束后一次性归还所有封锁,这样也能避免死锁的发生。
  2. 死锁的解除法。此方法允许产生死锁,并在死锁产生后通过解锁程序以解除死锁。这种方法需要有两个程序,一是死锁检测程序,用它测定死锁是否发生,另一是解锁程序,一旦经测定系统已经产生死锁则启动解锁程序以解除死锁。

3.4.2 故障与恢复

1. 数据库故障

数据库的故障可以用事务的故障来表示,主要分为四类:

  1. 事务故障。事务在运行过程中由于某些原因,未能运行至正常终止点就被撤销。
  2. 系统故障。系统在运行过程中,由于某种原因,致使事务在执行过程中以非正常方式终止,这时内存中的信息丢失,但是存储在外存储设备上的数据不会受影响。
  3. 介质故障。系统在运行过程中,由于某种硬件故障,是存储在外存储上的数据部分损失或全部损失。
  4. 计算机病毒

在数据库系统中,恢复的基本含义就是恢复数据库本身。也就是说,在发生某种故障使数据库当前的状态已经不再正确时,把数据库恢复到已知为正确的某一状态。目前数据库中最常用的恢复方式是转储和登记日志文件。

2. 故障的恢复

  1. 事务故障的恢复。恢复子系统应对此事务做撤销处理。事务故障的恢复是系统系统完成的,不需要用户敢于,步骤如下:
  • 反向扫描文件日志,查找该事务的更新操作。
  • 对该事务的更新操作执行逆操作。
  • 继续反向扫描日志文件,查找该事务的其他更新操作,并做同样处理。
  • 如期处理下去,直至读到此事务的开始标记,事务故障恢复完成。
  1. 系统故障的恢复。系统故障发生时,造成数据库不一致状态的原因有两个:一是由于一些未完成事务对数据库的更新已写入数据库;二是由于一些已提交事务对数据库的更新还留在缓冲区没来得及写入数据库。系统故障的恢复是在重新启动时自动完成的,不需要用户干预,步骤如下:
  • 正向扫描日志文件,找出在故障发生前已经提交的事务,将其事务标记记入重做(Redo)队列。同时找出故障发生时尚未完成的事务,将其事务标记记入撤销(Undo)队列。
  • 对撤销队列中的各个事务进行撤销处理:反向扫描日志文件,对每个Undo事务的更新操作进行逆操作。
  • 对重做队列中的各个事务进行重做处理:正向扫描日志文件,对每个Redo事务重新执行日志文件登记的操作。
  1. 介质故障与病毒破坏的恢复。在发生介质故障和遭病毒破坏时,磁盘上的物理数据库被破坏,这是的恢复操作可分为三步:
  • 装入最新的数据库后备副本,是数据库恢复到最近一次转储时的一致性状态。
  • 从故障点开始反向读日志文件,找出已提交事务标识将其记录重做队列。
  • 从起始点开始正向读取日志文件,根据重做队列中的记录,重做所有已完成事务,将数据库恢复至故障前某一时刻的一致状态。
  1. 具有检查点的恢复技术。检查点记录的内容可包括:
  • 建立检查点时刻所有正在执行的事务清单。
  • 这些事务最近一个日志记录的地址。
    采用检查点的恢复步骤如下:
  • 从重新开始文件中找到最后一个检查点记录在日志文件中的位置,由该地址在日志文件中找到最后一个检查点记录。
  • 由该检查点记录得到检查点建立时所有正在执行的事务清单队列(A)。
  • 建立重做队列(R)和撤销队列(U),把A队列放入U队列中,R队列为空。
  • 从检查点开始正向扫描日志文件,若有新开始的事务T1,则把T1放入U队列,若有提交的事务T2,则把T2从U队列移到R队列,直至日志文件结束。
  • 对U队列的每个事务执行Undo操作,对R队列的每个事务执行Redo操作。

DBA要做的基本操作是:

  • 重装最近转储的后援副本。
  • 运行日志文件,执行系统提供的恢复命令。

3.5 备份与恢复

备份和恢复计划的制定要遵循以下两个原则:

  1. 保证数据丢失的情况尽量少或完全不丢失,因为性价比的要求,这要取决于显示系统的具体要求。
  2. 备份和恢复时间尽量短,保证系统最大的可用性。

数据库备份按照不同方式可分为多种,这里按备份内容可以分为物理备份和逻辑备份两类。

物理备份是在操作系统层面上对数据库的数据文件进行备份,物理备份分为冷备份和热备份两种。冷备份是将数据库正常关闭,在停止状态下利用操作系统的copy、cp、tar、cpio等命令将数据库的文件全部备份下来,当数据库发生故障时,将数据文件复制回来,进行恢复。热备份也分为两种,一种是不关闭数据库,将数据库中需要备份的数据文件依次置于备份状态,相对保持静止,然后再利用操作系统的copy、cp、tar、cpio等命令将数据库的文件备份下来,备份完毕后再将数据文件恢复为正常状态,当数据库发生故障时,恢复方法同冷备份一样。热备份的另外一种方式是利用备份软件在数据库正常运行的情况下,将数据库中的数据文件备份出来。

为了提高物理备份的效率,通常将完全、增量、累积三种备份方式相结合。完全备份是将数据库中的内容全部备份,作为增量、累积的基础;增量备份是只备份上次完全、增量或累积备份以来修改的数据;累积备份是备份自上次完全或累计备份以来修改过的数据。一个备份周期通常由一个完全备份和多个增量、累积备份组成。由于增量或累积备份导出的数据少,所以其导出的文件较小,所需要的时间较少。利用一个完全备份和多个增量、累积备份恢复数据库的步骤如下:

  1. 首先从完全备份恢复数据库。
  2. 然后按照时间顺序从早到晚依次导入多个增量和累积备份文件。

逻辑备份是指利用各数据库系统自带的工具软件备份和恢复数据库的内容。

3.6 分布式数据库系统

3.6.1 分布式数据库的概念

是相对于集中式数据库系统而言的,是将数据库技术和网络技术向结合的产物。分布式数据库DDB比较确切的定义是:分布式数据库是由一组数据组成的,这组数据分布在计算机网络的不同计算机上,网络中的每个结点具有独立处理的能力,称为场地自治,它可以执行局部应用,同时,每个结点也能通过网络通信子系统执行全局应用。负责分布式数据库的建立、查询、更新、复制、管理和维护的软件,称为分布式数据库管理系统DDBMS。分布式数据库管理系统保证分布式数据库中数据的物理分布对用户的透明性。一个计算机网络组成的计算机系统,在配置了分布式数据库管理系统,并在其上建立了分布式数据库和相应的应用程序后,救称其为分布式数据库系统DDBS。

1. 分布式数据库的特点

  1. 数据库的分布性。分布式数据库中的数据分布于网络中的各个结点。
  2. 统一性。主要表现在数据在逻辑上的统一性和数据在管理上的统一性两个方面。
  3. 透明性。用户在使用分布式数据库系统时,数据在物理上的存储对用户是透明的。同使用集中式数据库一样。

与集中式数据库相比,分布式数据库具有下列优点:

  1. 坚固性好。即系统的可靠性和可用性好。
  2. 可扩充性好。可根据发展的需要增减结点,或对系统重新配置。
  3. 可改善性能。在分布式数据库中可就近分布,合理的冗余的原则来分布各个结点上的数据,构造分布式数据库,是大部分数据可以就近访问,避免了集中式数据库的瓶颈问题,减少了系统的响应时间,提高了系统的效率,而且也降低了通信费用。
  4. 自治性好。数据可以分散管理,同意鞋套,即系统中各结点的数据操作和相互作用是高度自治的,不存在主从控制。

同样同集中式数据库相比,分布式数据库也有集中式数据库所没有的问题。首先,异构数据库的集成问题是一项比较复杂的技术问题,目前还很难用一个通用的分布式数据库管理系统来解决这一问题。其次,如果数据库设计的不好,数据分布不合理,以致远距离访问过多,尤其是分布连接操作过多,不但不能改善性能,反而会使性能降低。

2. 分布式数据库的分类

  1. 按DDBMS软件同构度来分,当所有服务器软件(或每个DDBMS)和所有的客户软件均用相同的软件时称为同构型分布式数据库;反之,称为异构型分布式数据库。
  2. 按局部自治度来分。当对DDBMS的存取必须通过客户软件,则系统称为无局部自治;当局部事务允许对服务器软件进行直接存取,则系统称为有一定的局部自治。自治的两个分别是无局部自治和联邦型DDBMS霍城多数据库系统。多数据库系统本质上是集中式和分布式的混合体:对一个局部用户而言,它是自治的,那么是一个DBS;对一个全局用户而言,则是一个分布式DBS,但这个DDBS没有全局概念模式,只有一个由各局部数据库提供给全局允许共享的有关模式的集成。
  3. 按分布透明度来分。分布式透明度的另一个概念是模式集成度。若用户可以对集成模式操作不需要涉及任何片段、重复、分布等信息,则这类DDBMS称为具有高度分布透明(或高度模式集成);若用户必须知道所有关于片段、重复、分布等信息时则这类DDBMS没有分布透明,没有模式集成度。当系统不提供分布透明,用户查询时必须指定特定的场地,特定的片段等信息。当然DDBMS也可以部分分布透明。

3. 分布式数据库的目标

  1. 局部结点自治性。
  2. 不依赖中心结点。即每个结点具有全局字典管理、查询处理、并发控制和恢复控制等功能。
  3. 能连续操作。该目标使中断分布式数据库服务情况减至最少,当一个新场地合并到现有的分布式系统或从分布式系统中撤离一个场地不会导致任何不必要的服务中断;在分布式系统中可以动态的建立和消除片段,而不中止任何组成部分的场地和数据库;应尽可能在不使整个系统停机的情况下对组成分布式系统的场地的DBMS进行升级。
  4. 具有位置独立性(或称位置透明性)。
  5. 分片独立性(或称分片透明性)。将给定的关系分成若干块或片,提高系统的处理性能。
  6. 数据复制独立性。指将给定的关系(或片段)可在物理级用许多不同存储副本或复制品在不同场地上存储。
  7. 支持分布式查询处理。在分布式数据库系统中有三类查询:局部查询、远程查询和全局查询。局部查询和远程查询仅涉及单个结点的数据,查询优化技术是集中式数据库的查询优化技术。全局查询涉及多个结点上的数据,起查询处理和优化要复杂的多。
  8. 支持分布事务管理。事务管理有两个主要方面:恢复控制和并发控制。在分布式系统中,单个事务会涉及多个场地上的代码执行,会涉及多个场地上的更新,可以说每个事务是由多个“代理”组成的,每个代理代表在给定场地上的给定事务上执行的过程。在分布式系统中必须保证事务的代理集或者全部一致交付,或者全部一致回滚。
  9. 具有硬件独立性。
  10. 具有操作系统独立性。
  11. 具有网络独立性。
  12. 具有DBMS独立性。实现对异构型分布式系统的支持。

一个分布式数据库系统,对于用户来说,应当看上去想一个非分布式系统。

3.6.2 分布式数据库的架构

模式从整体上可以分为两大部分:下半部分是集中式数据库的模式结构,代表了各局部场地上局部数据库系统的基本结构;上半部分是分布式数据库系统增加的模式级别。

  1. 全局外模式。是全局应用的用户视图,是全局概念模式的子集。
  2. 全局概念模式。定义分布式数据库中数据的整体逻辑架构,数据如同没有分布一样,可用传统的集中式数据库中所采用的方法定义。
  3. 分片模式。每一个全局关系可以划分为若干不相交的部分,每一个部分称为一个片段,即“数据分片”。分片模式就是定义片段及全局关系到片段的映像,这种映像是一对多的,即每个片段来自一个全局关系,而一个全局关系可对应多个片段。
  4. 分布模式。定义片段的存放结点。分布模式的映像类型确定了分布式数据库是冗余的还是非冗余的。若映像是一对多的,即一个片段分配到多个结点上存放,则是冗余的分布式数据库,否则是不冗余的。
    根据分布模式提供的信息,一个全局查询可以分解为若干子查询,每一子查询要访问的数据都属于同一场地的局部数据库。
    分片模式和分布模式均是全聚德,分布式数据库中增加的这些模式和相应的映像是的分布式数据库系统具有了分布透明性。
  5. 局部概念模式。一个全局关系经逻辑划分成一个或多个逻辑片段,每个逻辑片段被分配在一个或多个场地上,称为该逻辑片段在某场地上的物理映像或物理片段。分配在同一场地上的同一个全局概念模式的若干片段(物理片段)构成了该全局模式在该场地上的一个物理映像。
    一个场地上的局部概念模式是该场地上所有全局概念模式在该场地上物理映像的集合。
    全局概念模式与场地独立,而局部概念模式与场地有关。
  6. 局部内模式。是DDB中关于物理数据库的描述,类似于集中式DB中的内模式,但起描述的内容不仅包含局部本场地的数据的存储描述,还包括全局数据在本场地的存储描述。

在六层模式中,全局概念模式、分片模式和分布模式是与场地特征无关的,是全局的,因此他们不依赖于局部DBMS的数据模型。在低层次上,需要把物理映像映射成由局部DBMS支持的数据模型。这种映像由局部映射模式完成。

这种分层的模式结构为理解DDB提供了一种通用的概念结构。它有三个显著的特征:

  1. 数据分片和数据分配概念的分离,形成了“数据分布独立型”概念。
  2. 数据冗余的显示控制。
  3. 局部DBMS的独立性。也成为“局部映射透明性”。

分布式数据库系统与并行数据库系统的区别

相似点:它们都是通过网络连接各个数据处理结点的,整个网络中的所有结点构成一个逻辑上统一的整体,用户可以对各个结点上的数据进行透明存取等。区别有以下几个方面:

  1. 应用目标不同。并行数据库的目标是充分发挥并行计算机的优势,利用系统中各个处理机结点并行的完成数据库任务,提高数据库的整体性能。分布式数据库系统的主要目标在于实现各个场地自治和数据的全局透明共享,而不要求利用网络中的各个结点来提高系统的整体性能。
  2. 实现方式不同。在并行数据库中,为了充分发挥各个结点的处理能力,各结点件采用高速通信网络互联,节点间数据传输代价相对较低。当负载不均衡时,可以将工作负载过大的结点上的任务通过高速通信网络送给空闲结点处理,从而实现负载平衡。在分布式数据库系统中,各节点(场地)间一般通过局域网或广域网互联,网络带宽比较低,各场地之间的通信开销较大,因此在查询处理时一般应尽量减少结点间的数据传输量。
  3. 各结点的地位不同。在并行数据库中,各结点之间不存在全局应用和局部应用的概念,各个结点协同作用,共同处理,而不可能有局部应用。
    在分布式数据库系统中,各结点除了能够通过网络协同完成全局事务外,还有自己结点场地的自治性。也就是说,分布式数据库系统的每个场地又是一个独立的数据库和自己的客户,可运行自己的DBMS,执行局部应用,具有高度的自治性。这也是并行数据库与分布式数据库之间最主要的区别。

2. 数据分片和透明性

分片的方式有多种,水平分片和垂直分片是两种基本的分片方式,混合分片和导出分片是较复杂的分片方式。

  1. 分片透明性是分布透明性的最高层次。指的是用户或应用程序只对全局关系进行操作而不必考虑数据的分片。当分片模式改变时,只要改变全局模式到分片模式的映像(映像2),而不映像全局模式和应用程序。全局模式不变,应用程序不必改写,这就是分片透明性。
  2. 位置透明性是分布透明性的下一个层次。指用户或应用程序应当了解分片情况,但不必了解片段的存储场地。当存储场地改变时,只要改变分片模式到分配模式的映像(映像3),而不影响应用程序。同时,若片段的重复副本数目改变了,那么数据的冗余也会改变,但用户不必关心如何保持各副本的一致性,这也提供了重复副本的透明性。
  3. 局部数据模型透明性是指用户或应用程序应当了解分片及各片段存储的场地,但不必了解局部场地上使用的是何种数据模型。模型的转换及语言等的转换均由映像4来完成。

3. 分布式数据库管理系统

任务,首先就是把用户与分布式数据库隔离开来,使其对用户而言,整个分布式数据库就像是一个传统的集中式数据库。换句话说,一个分布式数据库管理系统和用户之间的接口,在逻辑上与集中式数据库管理系统是一致的,但是考虑到分布式数据库的特点,其物理实现上又与集中式数据库不同。

DDBMS由4部分组成:

  1. LDBMS(局部DBMS)。局部场地上的数据库管理系统的功能是建立和管理局部数据库,提供场地自治能力、执行局部应用及全局应用的子查询。
  2. GDBMS(全局DBMS)。全局数据库管理系统的主要功能是提供分布透明性,协调全部事务的执行,协调各局部DBMS以完成全局应用,保证数据库的全局一致性,执行并发控制,实现更新同步,提供全局恢复功能。
  3. 全局数据字典。存放全局概念模式、分片模式。定义及各模式之间映像的行医:存放有关用户存取权限的定义,以保证全局用户的合法权限和数据库的安全性;存放数据完整性的约束条件的定义,其功能与集中式数据库的数据字典类似。
  4. CM,通信管理。在分布式数据库各场地之间传送消息和数据,完成通信功能。

DDBMS功能的分割和重复及不同的配置策略就导致了各种架构。

  1. 全局控制集中的DDBMS。特点是全局控制成分GDBMS集中在某一结点上,由该结点完成全局事务中的协调和局部数据库转换等一切控制功能。全局数据字典只有一个,也存放在该结点上,它是GDBMS执行控制的依据。优点是控制简单,易实现更新一致性,但由于控制集中在某一特定的结点上,不仅容易形成瓶颈而且系统较脆弱,一旦该节点出故障,整个系统就会瘫痪。
  2. 全局控制分散的DDBMS。特点是全局控制成分GDBMS分散在网络的每一个结点上,全局数据字典也在每个结点上有一份,每个结点都能完成全局事务的协调和局部数据库转换,每个结点即是全局事务的参与者又是协调者,一般称这类结构为完全分布的DDBMS。优点是结点独立,自治性强,单个结点退出或进入系统均不会影响整个系统的运行,但是全局控制的协调机制和一致性的维护都比较复杂。
  3. 全局控制部分分散的DDBMS。这种结构是根据应用的需要将GDBMS和全局数据字典分散在某些结点上,是介于前两种情况之间的架构。

局部DBMS的一个重要性质是:局部DBMS是同构的还是异构的。同构和异构的级别可以有三级:硬件、操作系统和局部DBMS。

异构型DDBMS的设计和实现比同构性DDBMS更加复杂,他要解决不同的DBMS之间及不同的数据模型之间的转换。

3.7 数据仓库

3.7.1 数据仓库的概念

数据仓库是一个面向主题的、集成的、相对稳定的、且随时间变化的数据集合,用于支持管理决策。

1. 面向主题的

操作型数据库的数据组织面向事务处理任务(面向应用),各个业务系统之间各自分离,而数据仓库中的数据是按照一定的主题域进行组织的。主题是一个抽象的概念,是指用户使用数据仓库进行决策时所关心的重点方面。一个主题通常与多个操作型信息系统相关。

2. 集成的

最重要特性。面向事务处理的操作型数据库通常与某些特定的应用有关,数据库之间相互图例,而且往往是异构的。而数据仓库中的数据是咋对原有分散的数据库数据抽取、清理的基础上经过系统加工、汇总和整理得到的,必须消除数据中的不一致性,以保证数据仓库内的信息是关于整个企业的一致的全局信息。

3. 相对稳定的

操作型数据库中的数据通常实时更新,数据根据需要及时发生变化。数据仓库的数据主要供企业决策分析,所涉及到的数据操作主要是数据查询,一旦某个数据进入数据仓库以后,一般情况下将被长期保留,也就是数据仓库中一般有大量的查询操作,但是修改和删除操作很少,通常只需要定期的加载、更新。

4. 随时间变化的

操作型数据库主要关心当前某一个时间段内的数据,而数据仓库内的数据通常包含历史信息,系统记录了企业从过去某一时刻点(如开始应用数据仓库的时点)到目前的各个阶段的信息,通过这些信息,可以对企业的发展历程和未来趋势做出定量分析和预测。

数据仓库反映历史变化的属性主要表现在:

  1. 数据仓库中的数据时间期限要远远长于传统操作型数据库系统中的数据时间期限,传统操作型数据库系统中的数据时间期限可能为数十天或数个月,数据仓库中的数据时间期限往往为数年甚至几十年
  2. 传统操作型数据库系统中的数据含有“当前值”数据,这些数据在访问时是有效的,当然数据的当前值也能被更新,但数据仓库中的数据仅仅是一系列某一时刻生成的复杂的快照;
  3. 传统操作型数据系统中可能包含也可能不包含时间元素,如年、月、日、时、分、秒等,而数据仓库中一定会包含时间元素。

数据仓库与传统数据库的比较

比较项目 传统数据库 数据仓库
数据内容 当前值 历史的、归档的、归纳的、计算的数据(处理过的)
数据目标 面向业务操作程序、重复操作 面向主体域,分析应用
数据特性 动态变化、更新 静态,不能直接更新,只能定时添加、更新
数据结构 高度结构化,复杂,适合操作计算 简单、适合分析
使用频率
数据访问量 每个事务一般只访问少量记录 每个事务一般访问大量记录
对响应时间的要求 计时单位小,如秒 计时单位相对较大,除了秒,还有分钟、小时

3.7.2 数据仓库的结构

数据仓库系统要包含数据源、数据准备区、数据仓库数据库、数据集市/知识挖掘库和各种管理工具和应用工具。数据仓库建立之后,首先要从数据源中抽取相关的数据到数据准备去,在数据准备去中经过净化处理后再加载到数据仓库数据库,最后根据用户的需求将数据导入数据集市和知识挖掘库中。当用户使用数据仓库时,可以利用包括OLAP在内的多种数据仓库应用工具向数据集市/知识挖掘库或数据仓库进行决策查询分析或知识挖掘。数据仓库的创建、应用可以利用各种数据仓库管理工具辅助完成。

1. 数据仓库的参考框架

由数据仓库基本功能层、数据仓库管理层和数据仓库环境支持层组成。

  1. 数据仓库基本功能层。包含数据源、数据准备区、数据仓库结构、数据集市或知识挖掘库,以及存取和使用部分。功能是从数据源中抽取数据,对所抽取的数据进行筛选、清理,将处理过的数据导入或者加载到数据仓库中,根据用户的需求设立数据集市,完成数据仓库的复杂查询、决策分析和知识的挖掘等。
  2. 数据仓库管理层。由数据仓库的数据管理和数据仓库的元数据管理组成。
    包含数据提取、新数据需求与查询管理,数据加载、存储、刷新和更新系统,安全性及用户授权管理系统及数据归档、恢复及净化系统等四个部分。
  3. 数据仓库的环境支持层。由数据仓库数据传输层和数据仓库基础层组成。数据仓库的不同结构之间的数据传输需要数据仓库的传输层来完成。
    数据仓库的传输层包含数据传输和传送网络、客户/服务器代理和中间件、复制系统及数据传输层的安全保障系统。

2. 数据仓库的架构

  1. 数据源。数据仓库系统的基础。通常包括企业内部信息和外部信息。内部信息包括存放于RDBMS(关系型DBMS)中的各种业务处理数据和各类文档数据。外部信息包括各类法律法规、市场信息和竞争对手的信息等。
  2. 数据的仓库与管理。是整个数据仓库系统的核心。数据仓库的真正关键是数据的存储和管理。数据仓库的组织管理方式决定了他有别于传统数据库,也决定了其对外部数据的表现形式。数据仓库按照数据的覆盖范围,可以分为企业级数据仓库和部门级数据仓库。
  3. OLAP服务器。对分析需要的数据进行有效集成,按多维模型予以组织,以便进行多角度、多层次的分析,并发现趋势。具体实现可以分为:ROLAP、MOLAP和HOLAP。ROLAP基本数据和聚合数据均存放在RDBMS之中;MOLAP基本数据和聚合数据均存放在多维数据库中;HOLAP基本数据存放在RDBMS中,聚合数据存放于多维数据库中。
  4. 前端工具。主要包括各种报表工具、查询工具、数据分析工具、数据挖掘工具及各种基于数据仓库或数据集市的应用开发工具。其中数据分析工具主要针对OLAP服务器,报表工具、数据挖掘工具主要针对数据仓库。

3.7.3 数据仓库的实现方法

数据仓库的建立过程分为:需求分析、概念模型设计、逻辑模型设计、物理模型设计和数据仓库生成。

从整体的角度看,数据仓库的实现方法主要有自顶向下法、自底向上法和联合方法。

1.自顶向下法

在该方法中,首先应找出数据仓库解决方案所要满足的商业需求,把商业需求视为实际数据仓库的首要任务。自顶向下法的优缺点如下表

优点 缺点
商业需求清楚的描绘出数据仓库实现的范围,因此是实现数据仓库解决方案的有效方法 有时会超出当前的业务范围
技术取决于商业 技术可以促进商业和竞争优势,但开始时对商业的促进是不明显的
易于向决策者提供数据仓库的收益情况 一旦数据仓库已经实现,可能就不再要求更公告的目标

该方法一般用于以下情况:

  1. 实现单位比较熟悉技术,并具有根据商业需求采用自顶向下法开发应用程序的丰富经验
  2. 决策层(总经理、决策者、投资者)完全清楚数据仓库的预测目标。
  3. 决策层(总经理、决策者、投资者)完全清楚数据仓库用作哪些机构的决策支持工具。
  4. 决策层(总经理、决策者、投资者)完全清楚数据仓库已经是长夜过程中的一个子过程。

2. 自底向上法

一般从实现和基于技术的原型入手。先选择一个特定的、众所周知的商业问题的子集,再为该子集制定方案。实现自底向上法一般是比较快的。优缺点如下表:

优点 缺点
实现的需求和开始时的需求远远超过自顶向下分析和长期考虑的范围 最初方案实现以后,最好回顾一下方案是如何服务于整个企业的。
在企业对数据仓库了解的初期,该方法使企业无需巨大投入就可见到效益 单个自底向上工程项目的失败可能推迟潜在技术的实现
少数人集中工作在一个部门范围,可以加速实现决策过程 早起的小组应不断发展为较大的小组,以扩充最初方案的覆盖范围。

自底向上法一般用于以下情况:

  1. 企业还没有确定掌握数据仓库技术,希望进行技术评估来决定运行该技术的方式、地点和时间。
  2. 企业希望了解实现和运行数据仓库所需要的各种费用情况。
  3. 企业在对数据仓库进行投资选择。

3. 联合方法

在以上两种方法的联合方法中,企业在保持自底向上的快速实现和基于应用的同时,还可以利用自顶向下方法的规划和决策性质。这种方法依赖于以下两个因素:

  1. 自顶向下的结构、标准和设计小组,可以从一个项目向另外一个项目传递知识,也可以把战术决策变为战略决策。
  2. 自底向上的项目小组,它直接负责在短期内实现一个集中的、部门级的商务解决方案。

联合方法具有以上两种方法的优点,但是难以作为一个项目来管理,该方法一般有用于:

  1. 实现企业拥有经验丰富的设计师,有能力建立、证明、应用和维护数据结构、数据结构和企业模型,可以很容易从具体(运作系统中的元数据)转移到抽象。
  2. 企业拥有固定的项目小组,完全清楚数据仓库技术应用的场所。他们可以清楚的看到当前的商务需求。

3.8 数据挖掘

目前的数据库系统可以高效的实现数据的录入、查询、统计等功能,但无法发现数据中存在的关系和规则,无法根据现有的数据预测未来的发展趋势。

3.8.1 数据挖掘的概念

三种基础技术分别为:海量数据搜集、强大的多处理器计算机和数据挖掘算法。

从技术角度来看,数据挖掘就是从大量的、不完全的、有噪声的、模糊的、随机的实际应用数据中,提取隐含在其中的、人们实现不知道的、但又潜在有用的信息和知识的过程。这个定义包括好几层含义:数据源必须是真实的、大量的、含噪声的;发现的是用户感兴趣的知识;发现的知识要可接受、可理解、可运用;并不要求发现放之四海皆准的知识,仅支持特定的发现问题。

从商业角度来看,数据挖掘是一种新的商业信息处理技术,其主要特点是对商业数据库中的大量业务数据进行抽取、转换、分析和其他模型化处理,从中提取辅助商业决策的关键性数据。

简而言之,数据挖掘其实是一种深层次的数据分析方法。按企业既定业务目标,对大量的企业数据进行探索和分析,揭示隐藏的、未知的或验证已知的规律性,并进一步将其模型化的先进有效的方法。

数据挖掘与传统的数据分析(如查询、报表、联机应用分析)的本质区别是数据挖掘是在没有明确假设的前提下去挖掘信息、发现知识。数据挖掘所得到的信息应具有先知、有效和可实用三个特征。

数据挖掘技术从一开始就是面向应用的。它不仅是面向特定数据库的简单检索查询调用,而且要对这些数据进行微视、中观乃至宏观的统计、分析、综合和推理,以指导实际问题的求解,企图发现事件间的相互关联,甚至利用已有的数据对未来的活动进行预测。

3.8.2 数据挖掘的功能

数据挖掘通过预测未来趋势及行为,做出前摄的、基于知识的决策。数据挖掘的目标是从数据库中发现隐含的、有意义的知识。主要有以下五类功能。

1. 自动预测趋势和行为

2. 关联分析

关联可分为简单关联、时序关联、因果关联。关联分析的目的是找出数据库中隐含的关联网。

3. 聚类

数据库中的记录可被划分为一系列有意义的子集,即聚类。聚类技术主要包含传统的模式识别方法和数学分类学。

4. 概念描述

是对某类对象的内涵进行描述,并概括这类对象的有关特征。分为特征性描述和区别性描述。前者描述某类对象的共同特征,后者描述不同对象之间的区别。生成一个对象的特征性描述只涉及该类对象中的所有对象的共性。生成区别性描述的方法很多,如决策树方法、遗传算法等。

5. 偏差检测

基本方法是:寻找观测结果与参照值之间有意义的差别。

3.8.3 数据挖掘常用技术

1. 关联分析

主要用于发现不同事件之间的关联性,即一个事件发生的同时,另一个事件也经常发生。重点在于快速发现那些有实用价值的关联发生的事件。主要依据是事件的发生概率和条件概率应该符合一定的统计意义。

2. 序列分析

主要用于发现一定时间间隔内接连发生的事件。这些事件构成一个序列,发现的序列应该具有普遍意义,其依据除了统计上的概率之外,还要加上事件的约束。

3. 分类分析

通过分析具有类别的样本的特点,得到决定样本属于各种类别的规则或方法。利用这些规则和方法对未知类别的样本分类时应该具有一定的准确度。其主要方法有基于统计学的贝叶斯方法、神经网络方法、决策树方法和支持向量机。

4. 聚类分析

是根据物以类聚的原理,将本身没有类别的样本聚集成不同的组,并且对这样的组进行描述的过程。其主要依据是聚集到同一个组的样本应该彼此相似,而属于不同组的样本应该足够不相似。

5. 预测

与分类类似,但预测是根据样本的已知特征估算某个连续类型的变量的取值的过程,而分类知识用于判别样本所属的离散类别而已。预测常用的技术是回归分析。

6. 时间序列分析

分析的是随时间变化的时间序列,目的是预测未来发展趋势,或者寻找相似发展模式或者是发现周期性发展规律。

3.8.4 数据挖掘的流程

数据挖掘的大致流程如下:

1. 问题定义

在开始数据挖掘之前,需要先弄清楚背景知识,即决定到底要干什么

2. 建立数据挖掘库

将要挖掘的数据收集到一个数据库中,而不是采用原有的数据库或数据仓库。这是因为大部分情况下需要修改要挖掘的数据,而且还会遇到采用外部数据的情况;另外,数据挖掘还要对数据进行各种纷繁复杂的统计分析,而数据仓库可能不支持这些数据结构。

3. 分析数据

是通常所进行的对数据深入调查的过程,从数据集中找出规律和趋势,用聚类分析区分类别,最终要达到的目的就是搞清楚多因素相互影响的、十分复杂的关系、发现因素之间的相关性。

4. 调整数据

对分析的数据进行进一步的明确化和量化。针对问题的需求对数据进行增删,按照对整个数据挖掘的过程的新认识组合或生成一个新的变量,以体现对状态的有效描述。

5. 模型化

在问题进一步明确,数据结构和内容进一步调整的基础上,救可以建立形成知识的模型。这一步是数据挖掘的核心环节,一般运用神经网络、决策树、数理统计、时间序列分析等方法来建立模型。

6. 评价和解释

上面得到的数据模型,有可能是没有实际含义或者没有使用价值的,也有可能是其不能准确反映数据的真实意义,甚至在某些情况下是与事实相反的,因此需要评估,确定哪些是有效的、有用的模式。评估的一个办法是直接使用原先建立的挖掘数据库中的数据来进行检验,另一种办法是另找一批数据并对其进行检验,在一中办法是在实际运行的环境中取出新鲜数据进行检验。

数据挖掘过程的分布实现,不同的步骤需要不同专长的人员,他们大致可以分为三类;

  1. 业务分析人员。要求精通业务,能够解释业务对象,并根据各业务对象确定出用于数据定义和挖掘算法的业务需求。
  2. 数据分析人员。精通数据分析技术,并较熟练的掌握统计学,有能力好把业务需求转化为数据挖掘的各步操作,并为每步操作选择合适的技术。
  3. 数据管理人员,精通数据管理技术,并从数据库或数据仓库中收集数据。

由上可见,数据挖掘是一个多种专家合作的过程,也是一个在资金上和技术上高投入的过程,这一过程要反复进行,在反复过程中,不断地趋近事物的本质,不断地优选问题的解决方案。

3.9 NOSQL

即Not Only SQL,不仅仅是SQL。NOSQL数据存储不需要固定的表结构,通常也不存在连接操作。在大数据存取上具有关系型数据库无法比拟的性能优势。

与关系型数据库相比,NOSQL数据库具有以下几个优点:

1. 易扩展

去掉关系数据库的关系型特征。数据之间无关系,这样就非常容易扩展,在架构的层面上带来了可扩展的能力。

2. 大数据量,高性能

具有非常高的读写性能,尤其在大数据量下,同样表现优秀。这得益于它的无关特性,数据库的结构简单。一般MySQL使用Query Cache,每次表一更新Cache就失效,它是一种大粒度的Cache,在针对Web2.0的交互频繁的应用,Cache性能不高。而NOSQL的Cache是记录级别的,是一种细粒度的Cache,所以NOSQL在这个层面上来讲性能就好很多。

3. 灵活的数据模型

无须事先为要存储的数据建立字段,随时可以存储自定义的数据格式。

4. 高可用

在不太影响性能的星空,就可以方便的实现高可用的架构,通过复制模型也能实现高可用

当然,NOSQL也存在很多缺点,例如:并未形成一定标准,各种产品层出不穷,内部混乱,各种项目还需要时间来检验,缺乏相关专家技术的支持等。

3.10 大数据

指无法在一定时间范围内用常规软件工具进行捕捉、管理、和处理的数据集合,是需要新处理模式才能具有更强的决策力、洞察发现力和流动优化能力的海量、高增长和多样化的信息资产。

1. 大数据的特点

业界通常用4个V(即Volume、Variety、Value、Velocity)来概括大数据的特征。

  • Volume:指的是数据体量巨大,从TB级别跃升到PB级别、EB级别,甚至于达到ZB级别。
  • Variety:指的是数据类型繁多。这种类型的多样性也让数据被分为结构化数据和非结构化数据。
  • Value:指的是价值密度低,价值密度的高低与数据总量的大小成反比。
  • Velocity:指的是处理速度快,也是大数据区别于传统数据挖掘的最显著特征。

2. 传统数据与大数据的比较

比较维度 传统数据 大数据
数据量 GB或TB级 PB级或以上
结构化程度 结构化或半结构化数据 所有类型的数据
数据分析需求 现有数据的分析与检测 深度分析(关联分析、回归分析)
硬件平台 高端服务器 集群平台

3. 大数据处理关键技术

一般包括:大数据采集、大数据预处理、大数据存储及管理、大数据分析及挖掘、大数据展现和应用(大数据检索、大数据可视化、大数据应用、大数据安全等)。

4. 大数据应用

大数据可以在各行各业得到应用。

©著作权归作者所有,转载或内容合作请联系作者
  • 序言:七十年代末,一起剥皮案震惊了整个滨河市,随后出现的几起案子,更是在滨河造成了极大的恐慌,老刑警刘岩,带你破解...
    沈念sama阅读 211,948评论 6 492
  • 序言:滨河连续发生了三起死亡事件,死亡现场离奇诡异,居然都是意外死亡,警方通过查阅死者的电脑和手机,发现死者居然都...
    沈念sama阅读 90,371评论 3 385
  • 文/潘晓璐 我一进店门,熙熙楼的掌柜王于贵愁眉苦脸地迎上来,“玉大人,你说我怎么就摊上这事。” “怎么了?”我有些...
    开封第一讲书人阅读 157,490评论 0 348
  • 文/不坏的土叔 我叫张陵,是天一观的道长。 经常有香客问我,道长,这世上最难降的妖魔是什么? 我笑而不...
    开封第一讲书人阅读 56,521评论 1 284
  • 正文 为了忘掉前任,我火速办了婚礼,结果婚礼上,老公的妹妹穿的比我还像新娘。我一直安慰自己,他们只是感情好,可当我...
    茶点故事阅读 65,627评论 6 386
  • 文/花漫 我一把揭开白布。 她就那样静静地躺着,像睡着了一般。 火红的嫁衣衬着肌肤如雪。 梳的纹丝不乱的头发上,一...
    开封第一讲书人阅读 49,842评论 1 290
  • 那天,我揣着相机与录音,去河边找鬼。 笑死,一个胖子当着我的面吹牛,可吹牛的内容都是我干的。 我是一名探鬼主播,决...
    沈念sama阅读 38,997评论 3 408
  • 文/苍兰香墨 我猛地睁开眼,长吁一口气:“原来是场噩梦啊……” “哼!你这毒妇竟也来了?” 一声冷哼从身侧响起,我...
    开封第一讲书人阅读 37,741评论 0 268
  • 序言:老挝万荣一对情侣失踪,失踪者是张志新(化名)和其女友刘颖,没想到半个月后,有当地人在树林里发现了一具尸体,经...
    沈念sama阅读 44,203评论 1 303
  • 正文 独居荒郊野岭守林人离奇死亡,尸身上长有42处带血的脓包…… 初始之章·张勋 以下内容为张勋视角 年9月15日...
    茶点故事阅读 36,534评论 2 327
  • 正文 我和宋清朗相恋三年,在试婚纱的时候发现自己被绿了。 大学时的朋友给我发了我未婚夫和他白月光在一起吃饭的照片。...
    茶点故事阅读 38,673评论 1 341
  • 序言:一个原本活蹦乱跳的男人离奇死亡,死状恐怖,灵堂内的尸体忽然破棺而出,到底是诈尸还是另有隐情,我是刑警宁泽,带...
    沈念sama阅读 34,339评论 4 330
  • 正文 年R本政府宣布,位于F岛的核电站,受9级特大地震影响,放射性物质发生泄漏。R本人自食恶果不足惜,却给世界环境...
    茶点故事阅读 39,955评论 3 313
  • 文/蒙蒙 一、第九天 我趴在偏房一处隐蔽的房顶上张望。 院中可真热闹,春花似锦、人声如沸。这庄子的主人今日做“春日...
    开封第一讲书人阅读 30,770评论 0 21
  • 文/苍兰香墨 我抬头看了看天上的太阳。三九已至,却和暖如春,着一层夹袄步出监牢的瞬间,已是汗流浃背。 一阵脚步声响...
    开封第一讲书人阅读 32,000评论 1 266
  • 我被黑心中介骗来泰国打工, 没想到刚下飞机就差点儿被人妖公主榨干…… 1. 我叫王不留,地道东北人。 一个月前我还...
    沈念sama阅读 46,394评论 2 360
  • 正文 我出身青楼,却偏偏与公主长得像,于是被迫代替她去往敌国和亲。 传闻我的和亲对象是个残疾皇子,可洞房花烛夜当晚...
    茶点故事阅读 43,562评论 2 349

推荐阅读更多精彩内容