《数据仓库》阅读笔记（二）

第7章 主管信息系统和数据仓库

7.1 EIS概述

主管信息系统（Executives Information System）是计算的最有效形式之一。通过EIS，高级管理分析人员可以精确指出问题并发现对于管理至关重要的趋势。
EIS处理是出于帮助主管指定决策而设计的。EIS的基本思想是提供信息，但不需要真正理解创建这些信息的基本结构。EIS的典型用途是：

• 趋势分析和发现
• 关键比例指标度量和跟踪
• 向下钻取分析
• 问题监控
• 竞争分析
• 关键性能指标监控

7.2 一个简单的例子

略~

7.3 向下钻取分析

向下钻取数据是指从一个汇总数据开始，将该汇总数据分解成一组更细致的汇总数据。通过获取汇总数据下的细节数据，管理者能够知道究竟正在发生什么事情，特别是汇总数据在哪里出现异常。
EIS另一个重要的功能是跟踪关键性能指标的能力。每个公司通过几个关键性能指标来反映公司某些方面的重要情况。

7.4 支持向下钻取

生成用于向下钻取的基本数据是成功执行向下钻取处理的主要障碍。这个问题之所以严重，是因为主管时而对这件事感兴趣，时而对那件事感兴趣，总是在改主意。每当新问题或者新机遇出现时，管理者的关注焦点就会改变。没有模式能预测管理者关注的下一个焦点是什么。

7.5 作为EIS基础的数据仓库

数据仓库在EIS环境中的操作效率是最高的。数据仓库是根据EIS分析员的需求定制的。
有了数据仓库，EIS分析员不必担心：

• 搜索限定的数据源
• 从现存系统中生成特定的抽程序
• 处理非集成数据寻找合适的数据时基
• …

简而言之，数据仓库提供了EIS分析员有效直吹EIS处理所必需的数据基础。

7.6 到哪里取数据

EIS分析员可能到个体处理层、部门（数据集市）处理层、轻度汇总处理层或档案数据层中去取数据。并且，EIS分析员为满足管理者的需要获取数据的过程，总是遵循一个标准的顺序或层次：
个体处理层->部门（数据集市）->轻度汇总数据->真实档案
采用这种顺序有很充分的理由。在从个体处理层专项档案层的过程中，分析员事实上进行了向下钻取分析。体系结构射界环境中汇总程度最高的数据出现在个体层。个体层的汇总支持层是部门层，支持部门层汇总的数据来自于轻度汇总层。最后轻度汇总层数据有档案层数据支持。

7.7 事件映射

EIS处理使用数据仓库逇一个有用的技术是事件映射。
收入趋势本身是令人感兴趣的，但它只是对公司运营情况的一个肤浅看法。要加强这种看法，要事件映射到趋势曲线上。

7.8 细节数据和EIS

需要多少细节数据才能运行EIS环境呢？一种学院派的说法是需要尽可能多的细节数据，通过存储尽可能多的数据，能做任何当前需要的分析工作。
这种看法是错误的，有几个原因：

• 存储和处理的开销可能是天价
• 大量数据是有效使用分析技术的一个障碍
• 细节分析不可重用。如果新老分析的方式不完全相同，非常相似的分析还可能得到矛盾的结论。

7.9 在EIS中只保存汇总数据

但是，只保存汇总数据也会有一些问题：

• 汇总数据蕴含着一个过程——汇总数据永远是计算过程的结果，任何情况下都不存在独立的汇总数据。如果EIS分析员不理解这个过程是与汇总数据密切相关的，分析结果可能会是误导性的。
• 汇总数据不一定处于合适的粒度级。

第8章 外部数据与数据仓库

8.1 数据仓库中的外部数据

在数据仓库中，存在一些与外部数据的试用和存储相关的问题：

• 外部数据存在的第一个问题是可用频率。与内部出现的数据不同，外部数据的呈现没有真正固定的模式。
• 外部数据的第二问题是外部数据的形式是完全没有规则的
• 外部数据的第三个问题是其不可预测型。外部去数据几乎叜任何是后续都可能来自于任何数据源。

8.2 元数据和外部数据源

元数据是至关重要的，因为在数据仓库环境中正是通过元数据来对外部数据进行注册、访问控制的的。元数据的典型内容就是元数据重要性的做好解释，例如：

• 文件标识符（ID）
• 进入数据仓库的日期
• 文件描述
• 文件来源
• 文件分类
• …

正是通过元数据，管理者可以判断许多有关外部数据的信息。在许多情况下，管理者甚至不看源文件，只看元数据。。因此，就外部数据而言，适当地建立和维护元数据对于数据仓库的操作是完全必要的。
与元数据相关的另一种数据类型是通知数据。当数据进入数据仓库和元数据时，要检查谁对该数据感兴趣。一旦发现获得的数据是某人感兴趣的，就向那个人发出通知。

8.3 存储外部数据

在许多情况下，将所有的外部数据存储在数据仓库中是不可能的也是不经济的。另一种方法是，在数据仓库的元数据中，对外部数据进行登记，创建一个条目说明什么地方能找到外部数据本身，而外部数据可以存储在任何一个方便的地方。

8.4 外部数据的不同部件

外部数据的重要设计问题之一是它经常包括许多不同的部件。为了管理这些数据，有经验的DSS分析员或工程师需要决定哪些数据单元是最重要的，然后将最重要的数据存储在一个联机的、容易访问的位置。这是第一个存储和访问效率的问题。其余不重要的细节不能丢弃，而是将其放在大容量存储设备中。

8.5 建模与外部数据

数据模型通常的作用是根据设计模型塑造环境。但外部数据是根本不可塑的。能做的最有用的事就是在相关的关键词和关键字解释范围内，记录数据模型和外部数据之间的区别。使用数据模型对外部数据进行任何重大改造都将是一个错误。

8.6 辅助报告

略~

8.7 外部数据存档

每一条信息（外部的或其他的）都有一个有用的声明周期。一旦潮吹了这个声明周期，保存这些信息就不经济了。通常，外部数据可能从数据仓库移出并放到较便宜的存储设备中。元数据对外部数据的引用应及时更新来反映新的存储位置，并且新的存储位置仍然保留在元数据存储单元中。

8.8 内部数据与外部数据的比较

外部数据最有用的一个功能是在一定时间范围内将其与内部数据进行比较。这种比较可以提供给管理者一个独特的视角。例如，将即时性的个体的行为和趋势与普遍的行为和趋势进行比较，能使主管获得其他地方得不到的见解。

第9章 迁移到体系结构环境

9.1 一种迁移方案

1. 这种迁移方案的起点是一个企业数据模型。该数据模型描述了企业的信息需求。需要清楚的是，它描述的是企业需要的信息，而并不一定是企业当前已经具有的东西。在建立这个数据模型时，不考虑任何技术问题。
2. 中间层模型是根据企业数据模型所描述的各个主题域建立起来的，每次只建立一个主题域，而不是一次就将所有的主题域都建立起来，否则将会耗费大量的时间。
3. 企业数据模型和中间层模型建立之后，下一步工作就是定义记录系统。记录系统通常是由企业现有系统来定义的。
4. 在定义好记录系统并找出了将数据迁移导数据仓库所涉及的技术挑战之后，下一步就是设计数据仓库。一旦设计数据仓库，就必须按主题域进行组织。在主题域内，有许多独立的数据表，每张数据表通过一个公用关键字连接。
5. 数据仓库设计好以后，下一步就是设计和建立记录系统和数据仓库之间的接口。这些接口有规律的将数据装载到数据仓库。建立一个数据仓库所需要的大多数开发资源都花费在这点上了。将建立数据仓库所需的80%的精力都花费在这个地方，是正常的。

9.2 反馈循环

数据仓库库长期开发成功的关键是数据体系结构设计人员和DSS分析人员之间的反馈循环。关于这个反馈循环，有几个问题对于数据仓库环境的成功来说是至关重要的：

• DSS分析人员要遵循“给我想要的东西，然后我就能告诉你我真正需要的东西”的工作模式。在DSS分析人员知道数据仓库所能提供的东西以前，试图从他们那里获取需求信息是不可能的。
• 反馈循环周期越短，越有可能成功。
• 需要调整的数据量越大，反馈循环所需的周期就越长。

9.3 策略方面的考虑

略~

9.4 方法和迁移

构造数据仓库的方法称为螺旋式开发方法。螺旋式开发方法在几个方面与迁移路径有所不同。迁移路径动态的描述了总体工作步骤，而螺旋式方法则讨论详细的工作步骤、这些工作的结果以及这些工作的次序。两者结合在一起形成了一个完整的对创建数据所需工作的描述。

9.5 数据驱动的开发方法

数据驱动方法一个突出的方面就是，它建立在先前工作的基础之上，用原先已开发的代码和处理。基于原有工作之上的开发要获得成功，唯一的途径就是要找出共同性。在开发输入第一行代码或设计第一个数据库之前，应该知道哪些已经存在，对开发过程的影响如何，必须保持清醒的头脑，利用已有的东西，不做重复工作。这是基于数据驱动的开发的一个基本要素。

9.5.1 概念

数据驱动的方法不是按照一个应用接一个应用的方法去开发系统，而是把原先已建立好的代码和数据作为新代码和数据的基础，而不是新老病例。

9.5.2 系统开发生命周期

操作型系统和DSS系统的开发生命周期之间的深刻区别，从根本上体现了数据驱动开发方法的特点。操作型系统的开发生命周期是，开始于需求，结束于代码；而DSS处理的开发生命周期的特点是，开始于数据，结束于需求。

第10章 数据仓库和Web

Web环境与企业系统进行交互有两种基本方式：

1. 当Web环境产生了一个需要执行的交易（如一个客户的订单）时，就产生一次交互。交易的数据转换为标准格式并装入企业系统中。
2. 通过使用日志，手机Web上用户的活动信息。

Web日志中包含了通常称为点击流的数据。每当因特网用户进行点击而转向另一个网络地址时，就产生一个点击流记录。当用户在浏览公司的不同产品时，同时也会生成一条有关用户浏览了哪些产品、购买了哪些产品以及用户对购买本身的看法的记录。一句话，点击流数据是了解互联网用户心理倾向的关键。
然而，Web环境与企业系统之间的这种作用巨大的交互所需要的技术并不简单。理解源于Web环境中的数据有时是很困难的。例如，Web产生的是细节程度非常低的数据——事实上，它们太详细了，既不能用于分析也不能装入数据仓库。要使点击流数据可用于分析和能够进入数仓库，就必须对日志数据进行读取和提炼。
总之，将数据从Web转移到数据仓库设计以下这些步骤：

• Web收集数据到日志中
• 日志数据通过粒度管理器进行处理
• 粒度管理器将提炼后的数据传递给数据仓库

10.1 支持电子商务环境

略~

10.2 将数据从Web移动到数据仓库

Web日志中的点击流数据在进入数据仓库环境之前，要经过一个成为粒度管理器（GM）的软件处理。粒度管理器执行许多处理，它读入点击流数据并进行如下工作：

• 清除无关数据
• 根据多个相关的点击流日志生成一条记录
• 清除错误数据
• 对在Web环境独一无二的数据进行转换
• 数据汇总
• 数据聚集

简而言之，基于Web的数据在适于进入数据仓库之前要经过严格的清理/转换/约简处理。根据经验，大约90%的数据会被约简掉。

10.3 将数据从数据仓库移动到Web

Web环境对响应时间非常敏感，如果响应时间过长，它的性能就会受到影响。由于这个原因，数据仓库和Web环境间没有直接的接口。
取而代之的是，这两种环境的接口与数据仓库处于同一个环境的企业ODS。ODS可以实现毫秒级的响应。于是，数据从数据仓库传递到ODS。一旦请求来到ODS中，就可以响应来自Web环境的数据存储请求了。

10.4 对Web的支持

给基于Web的电子商务环境，数据仓库提供了以下几项重要的能力：

• 容纳巨量数据的能力，数据可以迅速的从Web环境移到数据仓库，避免其成为性能或可用性的一个障碍。
• 存取集成数据的能力，Web数据本身没有多大用处，但是一旦同其他的企业数据结合在一起，就会产生巨大的作用。
• 提供优良性能的能力，由于Web在ODS而不是数据仓库中存取数据，因此能够从中获得优良的运行性能。

第11章 非结构化数据和数据仓库

非结构化数据领域是指那些临时的，非正式的活动占优势的情况。
与非结构化数据相反的是结构化数据。典型的结构化数据有标准的DBMS、报告、索引、数据库、域、记录等等。
非结构化数据大致分为两类——通信和文档。通信相对较短且分布有限，而且趋向于一个较短的声明周期。文档则是面向更广大的读者，并且比通信要大很多。文档的生命周期也要比通信长很多。通信和文档的基本形式都是文本。因此，文本就成为非结构化环境的最基本形式。
结构化数据领域是受数字支配的。结构化数据领域包含关键字、域、记录、数据库等。结构化系统具有高度次序化的特点。

11.1 两个领域的集成

通过结构化数据与非结构化数据的结合，引进一个全新的领域也是有可能的。；比如，CRM能够自由地从结构化领域收集到人口统计数据，但缺少通信。通过非结构化领域，能够实现添加客户发出和接收的电子邮件，以及其他通信信息等等。但是要对这两个领域进行匹配却是一个非常困难的任务。

11.1.1 文本——公共连接

那么，匹配这两个领域需要什么？文本。没有文本，要形成连接是不可能的。即使有了文本，一个连接包含的也可能全是误导信息。
如果只进行基于文本的两个领域间的原始匹配，大量的问题会出现，包括：

• 拼错——如果两个环境中发现Chernobyl和Chernobile怎么办？
• 上下文——如果术语“bill”在两个领域都出现了，它们应该匹配吗？表示的是鸟嘴还是欠的钱数？
• 同名——相同的名字“Bob Smith”出现在两个领域里面。是指同一个人吗？
• 缩写——NY和New York一样吗？
• 次干——“moving”应该和“moved”匹配吗？
• …

当对两个环境的文本进行随机匹配时，就像发生假阳性和假阴性一样，几乎没有相对有效的匹配。

11.1.2 基本错误匹配

从语法上看两个环境之间存在很多差别，匹配两个环境的原始数据总是充满了误导结论。也许产生这个问题的最主要原因是在两个领域的环境之间存在着基本的错误匹配。
尽管在不同环境间进行文本匹配是很困难的，但它仍然是数据仓库环境中的数据集成和非结构化数据布局的关键。

11.1.3 环境间文本匹配

为了使匹配有意义，非结构化数据必须先进行基本的编辑：

1. 删除停顿词
2. 将单词约简成词干

11.1.4 概率匹配

进行确定的基本方法是创建一种叫做概率匹配的方法。在一个概率匹配中，搜集尽可能多的数据用来说明你正在寻找的“Bob Smith”，这些数据也是与其他地方出现的“Bob Smith”的类似数据进行匹配的基础。然后，根据所有重叠部分的数据确定对名字的匹配是否有效。

11.2 主题匹配

11.2.1 产业特征主题

组织非结构数据的一种方法是通过产业特征主题。在这种方式里，对非结构化数据进行分析是根据现有的与产业主体有关的词语进行的。例如，会计和金融是两个产业特征主题。
搜集到产业特征主题，根据主题逐一与非结构化数据作对比。当发现有单词或词根在非结构化环境中存在，就加以标识。分析结束后，就能够将非结构化文档与分析过的主体的符合程度算出来了。

11.2.2 自然事件主题

另一种组织非结构化数据的方法是通过自然事件主题方式。
在自然主题组织方式中，非结构化数据是基于逐篇文档收集起来后，将词语根据出现次数进行等级划分。然后根据这个登记形成文档的主题。
例如，某个文档包含如下已经分级的词语：

• 火——296次
• 消防员——285次
• 水龙带——277次
• 救火车——201次

能够推测出的结论是文档的主体与火灾或救火有关。
假设文档中还包括如下词语：

• 雪花石膏——1次
• 天使——2次
• Rio Grande河——1次

由于这些词语出现的次数很少，可以推测出文档的主体与雪花石膏或天使关联很小或者根本无关。
由上看出，可以通过查看词语出现的次数和频率来建立文档的主题。

11.2.3 通过主题和主题词关联

在非结构化环境中的主题数据与结构化环境中的数据建立联系的一种方法是通过数据原始匹配。在数据的原始匹配中，如果在结构化环境中任何地方发现一个词语是文档主题的一部分。那么非结构化文档就会与结构化记录关联起来。但这种匹配意义不大，而且事实上容易产生误导。

11.3 两层数据库

在数据仓库环境中存在两种使用非结构化数据的基本方法：

• 访问非结构化环境，然后将数据迁移到结构化环境里。
• 创建一个两层数据仓库，其中的一层对应非结构化数据，而另一层对应结构化数据。

11.3.1 非结构化数据仓库分类

非结构化数据仓库中的数据划分成以下两类：

• 非结构化通信
• 文档和库

通信划分成两类，与商业相关的通信和“废话”（指无商业价值的通信）。典型的废话有“让我们一起吃饭”等。通常，在数据仓库里废话会从通信中删除。
通信包含的关键一般如下：

• 电子邮件地址
• 电话号码
• 传真号

通信与结构化数据之间的关系通过基本标识符形成。

11.3.2 非结构化数据仓库中的文档

由于有太多的变量，在非结构化数据仓库中存储实际文档或许是必要的，或者只存储文档在数据仓库中的位置更有意义。
决定是否存储文档的一种折中的解决方法是存储那些包含有主题词的前后句子。通过存储关键词前后的文本，实际上不用重新获取源文档就可以预览文档了。

11.3.3 非结构数据可视化

略~

11.4 自组织图（SOM）

略~

11.5 适用于两个环境

略~

第12章 大型数据仓库

12.1 快速增长的原因

在数据仓库中，数据增长如此快速存在几个方面的原因：

1. 数据仓库是包含历史的
2. 数据仓库以最低粒度收集数据
3. 需要将很多不同种类的数据聚集

12.2 庞大数据的影响

数据仓库收集到大量数据会产生以下几方面的影响：

1. 花销——大量数据花费很多钱
2. 有效性——企业是否使用收集到的所有数据
3. 数据管理——随着数据量的增加，数据管理规则也要更改

12.2.1 基本数据管理活动

以50GB的数据量为例，大多数基本数据管理活动在不经考虑和准备下完成。下载50GB的数据大概需要1小时或更少。索引这些数据可以在较短时间内完成，大概15分钟。访问数据就更快了，仅以毫秒计算。但是，对于10TB的数据，基本数据管理活动的情况就不同了。现在10TB的数据需要12个小时或更多，索引需要72小时或者更长时间，取决于正在进行的索引。访问响应时间以秒来衡量而不是毫秒级了。此外，索引需要的空间也成为要考虑的问题。

12.2.2 存储费用

随着数据仓库规模的增大，数据仓库的预算也在增加，在一些情况下还是以指数级增长。

12.2.3 实际存储费用

除了存储设备本身还有很多成分一起组成磁盘存储设备。包括磁盘控制器，通信线，用来控制数据用途的处理器。还包括保证处理器正常运作的软件。还有数据库软件，操作系统软件，商业智能软件等各种软件。所有这些组成随着数据量的扩充而增加开销。每兆字节存储的实际费用只是其中一项支出。仅仅关注每兆的字节费用和它的降低是一个很大的误导。

12.2.4 大型数据量中的数据使用模式

影响硬件预算增长的另一相关因素是：已经获取到的数据的使用情况。
当一个企业的数据仓库只有50GB的存储容量时，几乎所有的数据都在被使用。大多数查询可以根据需要访问到数据仓库中的所有数据。但是随着数据仓库数据量的增长，这些基本查询却可能不能实现了。
随着数据量的逐渐增加，实际使用数据的百分比却在逐渐减小。

12.2.5 一个例子

略~

12.2.6 两类数据

随着时间推移，数据逐渐倾向于两种状态之一——频繁使用数据或非频繁使用数据。数据仓库变得越大，频繁使用数据就会越少。

12.2.7 数据分类设涉及的问题

在数据仓库DSS环境中，不存在像OLTP环境中遇到的随机访问模式。实际上，大多数DSS处理受日期限制。数据越新，越可能被使用。数据仓库DSS环境存在着明确的访问模式而非随机的。

12.3 数据在不同介质存储

硬件供应商不会因为存储不用的数据而少收取费用。因此，在数据仓库中通过多种形式存储而将其分离就很有意义。将经常使用的数据存放到高性能存储设备。不经常使用的数据则存放到海量存储介质中。
通常海量存储器称作近线存储，是一种顺序存储。

12.3.1 近线存储

近线存储适用于存储大容量的数据，可以存储几十或几百万亿的数据。近线存储的可靠性也可以持续很久。如果需要备份，近线存储中将数据北非到另一近线存储介质上的费用是很低的。
近线存储的性能只消耗在寻找第一条记录上。找到第一条记录后，只需要纳秒的时间就可以访问块结构中的其他记录了。只有访问第一条记录需要机械时间，其他记录只需电子时间。

12.3.2 访问速度和磁盘存储

当访问近线存储数据从电子速度变为机械速度时，需要付出性能代价。但是将数据仓库所有数据存放在磁盘上又会造成其他性能损失。事实上，将大型数据仓库中的所有数据放在磁盘存储要比将数据放到不同的存储介质中慢。

13.2.3 存储存档

出了要对大量数据进行管理，还需要对数据进行分类存储。需要以一种归档的方式管理大量数据。除了磁盘存储和近线存储外，还需要存档存储。
存档存储和近线存储很相似，不同之处在于存档存储中的数据被访问的概率很低。
事实上，在一下情况下，数据的位置对最终用户是透明的。在这种情况下，当最终用户查询时，不知道数据是存放在高性能存储设备还是近线存储设备中。然而，如果数据是存档存储的，最终用户总是知道数据不是存放在高性能存储设备中。因此，近线存储认为是数据仓库的逻辑外延，而存档存储却不是。

13.2.4 透明的意义

透明的意义很重大：

• 如果数据是透明的，那么近线存储中的一行数据在形式上就和数据仓库高性能环境中的一行数据看上去一样了
• 要实现透明性，有必要使近线系统对数据库系统是可用的，两个环境间必须在技术上相容

12.4 环境间数据转移

移动数据的方法见下表：

	优点	缺点
手工	非常简单；立即可用；在行级上进行操作	容易出错；需要人工交互
HSM（分级存储管理）	相对简单；成本不高；全自动	移动整个数据集
CMSM（交叉介质存储管理）	全自动；在行级上操作	成本高；执行和操作较复杂

12.4.1 CMSM方法

CMSM技术是全自动的。
首先从系统得到一个请求。分析请求并决定需要哪些数据。如果需要的数据已经在数据仓库（也就是已经在磁盘中），系统令查询继续进行。但是当系统发现需要近线存储的数据时，系统令查询排队等待并进入近线存储环境。当系统刚找到数据后把它们收集起来。一旦收集好，数据就送到数据仓库环境中。数据到达数据仓库后，添加到它们所属的数据仓库表。一旦数据装载到数据仓库后，查询出列并执行。看起来好像要查询的数据一直在数据仓库中一样。

12.4.2 数据仓库使用监控器

进入数据仓库的SQL命令被监控，这些命令的结果集也被监控。系统管理员能够知晓在数据仓库中哪些数据正在被使用或者没有被使用。监控器能从行级和列级掌握数据的使用情况。

12.4.3 不同存储介质下数据仓库的扩展

随着数据仓库从磁盘存储到近线存储和存档存储的扩展，数据仓库也扩展成拥有庞大的数据。数据仓库可以增长到千万亿字节数据量，并且仍然有效和可管理。

12.5 数据仓库转换

几乎所有的企业建立数据仓库的方法都是将数据放到磁盘存储上。随着数据的老化，数据被转义到近线存储或存档存储。在不同存储介质间存在者正常的数据流通。
但还有另一种选择。这种选择指的是首先将数据存放在近线存储。当查询执行完毕，数据从近线存储转义到磁盘环境。进入磁盘环境后，数据被访问和分析，这些数据看起来就好像一直待在这里。一旦分析结束，数据再返回近线存储。

12.6 总费用

略~

12.7 最大容量

度量一台计算机能够处理的字节数是毫无意义的。为了对一台计算机的容量进行有意义的度量，必须给出三个彼此制约的参数：

• 数据量
• 用户数
• 工作量的复杂度

对于任一参数，它可以以另外两个未代价达到最优化。

第13章 关系模型和多维模型数据库设计基础

专业数据仓库面临的一个问题是数据仓库中数据库设计的基本模型的选取问题。广泛采用的数据库设计模式有两种，关系模型和多维模型。普遍认为在数据仓库的数据方法中，关系模型是“Inmon”方法而多维模型死“Kimball”方法。

13.1 关系模型

关系模型数据库设计首先要创建一张数据表，表中一行包含不同的列。关系表可以包含不同的属性。每一数据列表示你不同的物理特征。不同的列可以索引并作为标识符。所有列都是根据数据定义（DDL）标准定义的。
关系型数据是以一种称为标准化的形式存在。数据标准化是指数据库设计会使数据分解成非常低的粒度级。标准化数据以一种孤立模式存在，这种情况下对数据表里的数据关系要求很严格。

13.2 多维模型

多维模型方法也叫做星型连接。多维模型方法的支持者是Ralph Kimball博士。数据库设计多维模型方法的中心是星型连接。
星型连接的中心是一张事实表。事实表是包含大量数据值的一种结构。事实表的周围是维表，用来描述事实表的某个重要方面。维表里的数据量要比事实表里的少得多。

13.3 雪花结构

通常，星型连接只包含一张事实表。但是在数据库设计中要创建一种雪花结构的符合结构需要多张事实表结合。
在雪花结构中，不同的事实表通过共享一个或多个公共维表连接起来。有时称这些共享的维表为一致维表。
多维模型设计的最大优点在于访问的高效性。

13.4 两种模型的区别

作为数据仓库设计的基础，星形连接和关系型结构两者之间存在很多不同。最重要的区别是在灵活性和性能方面。关系模型具有高灵活性，但是对用户来说在性能方面却不是很理想的。多维模型在满足用户需求方面是非常高效的，但是灵活性不好。
另一重要区别在于设计的范围不同。必然地，多维设计只能在有限的范围内进行，也就是说，数据库设计只能在一组请求过程下得到最优化。如果所有不同组请求全部加入到设计当中，最优化变得毫无意义。
当使用关系模型时，在性能方面没有特别的优化方法。既然关系模型要求数据以最低粒度级存储，那么就可以无限制地添加新数据。很显然，添加数据到关系 模型永远也不会停止。正因为这样，关系模式适合大范围数据（如一个企业模型）,而多维模型适用于小范围数据（如一个部门或甚至一个子部门）。

13.4.1 区别的起源

关系环境是通过企业数据模型设计出来的。星型连接或多维模型是根据最终用户的请求塑造的。换句话说，关系模型通过纯数据模型和其他模型设计，而多维模型通过处理请求塑造。
由于关系模型通过抽象数据形成，所以模型自身非常灵活。但是关系模型的这种灵活性，对于直接数据访问的执行却不是最优化的。如果想得到一个高性能的关系模型，最佳的方法是从模型中抽取出数据，并重新构建一种适合于快速访问的模式。尽管关系模型性能有限，但是既然它支持数据重建，那么也有利于数据的非直接访问。
多维模型在直接访问数据方面是快速而高效的。与关系模型支持非直接数据存取相反，多维模式支持直接数据存取。
关系模型隐含的数据模型有着非常高的抽象级，而多维模型包含的处理模型却不是抽象的。因为关系模型所处的抽象级，它可以支持很多用户。多维模型有非常明确的处理请求，所以它只能支持一些特定的需求。

13.4.2 重建关系型数据

同一张关系表可以多次重复用来创建不同的用户表。结合多张关系表来创建新的关系表时很简单的，原因如下：

• 数据已最低粒度级和标准化形式化存储
• 关系表建的关系已经定义好并且包含一个含有外键的关键字表
• 新表可以对关系表中的基本数据集定义新的汇总和筛选

13.4.3 数据的直接访问和间接访问

关系模型适合数据的间接访问而多维模型利于数据的直接访问。

13.4.4 支持将来未知的需求

多维模型在支持将来未知的需求和用户方面不如关系模型。关系模型中存放的粒度级数据好比原子。原子可以组合出许多不同的物质。原子的奥秘在于其粒度级。由于原子有如此好的特性，可以在近乎无穷的方法中使用。

13.4.5 支持适度变化的需求

关系模型的另一个优点就是具有适度变化的能力。也就是说，数据仓库的直接用户访问的是由关系模型转化而来的数据而不是关系模型本身的数据。当发生变化的时候，因为不同的数据仓库用户访问不同的数据库，所以影响是最小的。
多维方法不具有这一能力。多维数据库设计是很脆弱的，是很多处理请求聚集在一起的结果。
关系模型对数据仓库是理想的基础，而星型模型对于数据集市是最佳的。

13.5 独立数据集市

多维模型的另一个特点是通过一种称作独立数据集市方法联合起来。数据集市是用来表示服务一组特定群里（如财会部门）的分析需求的一种数据结构。独立数据集市是指直接通过历史应用创建的数据集市。
与独立数据集市相对应的是从属数据集市。从属数据集市是利用来自数据仓库的数据建立的。它的数据源不依赖于历史数据或操作型数据，只依赖数据仓库。从属数据集市要求有预先的计划、长期的观察、全局的分析和企业各不同部门对需求分析的合作与协调。
独立数据集市存在以下问题：

• 不提供数据重用平台
• 不提供数据一致性的基础
• 不提供单一历史接口程序基础
• 大量的数据冗余

13.6 建立独立数据集市

当建立了一定数量的独立数据集市后，独立数据集市的问题就变得很明显了。很快用户就会发现数据集市之间的信息不统一，也不同步，而且每增加一个数据集市就会出现不断增长的细节数据冗余的问题，需要大量的资源来建立接口程序，维护这些程序也变成了负担。因此独立数据集市不适合与解决企业中的信息问题。
当然，如果企业采用了从属数据集市，并在建立任何数据集市之前先建立一个数据仓库，那么独立数据集市固有的那些体系结构方面的问题就不会出现了。

第14~19章

略~