数据仓库之我见 （设计篇）

建造数据仓库要做些什么？

一般说来，建造数据仓库主要两个方面：

1.     与操作性数据库的接口设计。

2.     数据仓库本身的设计。

看上去好像很简单，但事实并非就这么按部就班，假设我是一个数据库设计师，我完全可以不管三七二十一，先载入一部分数据，让DSS分析员（还没忘吧，就是那个给设计数据仓库的人要求的）分析去吧，等他先给点意见出来，我们在动手也不迟。

下面，我将按照提出问题、解决问题的顺序来上一堂学前班。

 

建造数据仓库的主要难点是什么？

首先纠正一个广泛存在的错误认识：建造数据仓库的过程就是从操作性数据中提取数据的过程，之所以说这是错的，主要是因为：操作性数据大都是非集成的（有谁见过一个计费程序可以把几年的账单条目统计一遍的），你不可能抽取出你真正需要的东西，例如这个月的平均花费，马磊在这个月的加班日等等，不用我说，你也知道：操作性数据主要是为应用程序服务，而每个系统或应用程序都有其特有的“独立性”，在开发的时候，谁会想到以后还要翻旧帐呢？

好了，换一个新的视角看问题：如果不仅仅是抽取的话，那还有些什么问题呢？如下：

第一个问题：系统集成。当成百上千张表放在一起，需要你来统计的时候，你敢肯定这个表的某一字段和另一张表的同名字段是一个含义么？或者反过来说：你敢肯定这个表的某一字段和另一张表的不相同的字段一定是毫无关系的么？这些问题可以归结成一个问题：系统缺乏集成性！解决这个问题的方法除了更好的设计你的数据库，只有靠你的耐心了。还有就是字段的转换问题，看下面这个例子：性别（sex）在数据库中有很多表达形式，可以写成m/f，也可以写成0/1来表示男/女，等等……怎么办？为了保证传唤到数据仓库的数据正确，我们必须建立不同的映射(Sorry，简单的说是：将上面提到的那种性质相同，表示的不同的数据用同一种形式表达出来)，这也是一件需要耐心的工作！

第二个问题：存取现存系统的数据的效率。这很正常，当有很多表格和文件需要扫描的时候，谁能确切的知道一个文件被扫描过？如果，现存系统存在大量的数据，你为了得到其中某一些数据，而把整个数据库扫描一次，这件是一场悲剧。相信谁也不想这种事发生，具体的解决方法在下面的提出。

弄请”how to 避免这些问题”，先搞清楚从操作型环境到数据仓库可能要做那些装载工作（你会选那一项呢？）

l         装载档案数据。（联想一下布满灰尘的旧帐本就知道什么是档案了）

l         装载在操作性系统中目前已有的数据。（就在系统中的数据，还没有备份的）

l         将自数据库上次刷新以来在操作性环境中不断发生的变化（数据库的更新）装载到数据仓库中。

对于第一个选项很简单，翻账本谁不会阿？所以难度很小，但作为一个DSS分析员，放着现有的数据，你会愿意去分析十年前的数据么，不少企业发现，在很多环境下，使用旧的数据得不偿失。

对于第二个选项来说，因为只需要装载一次，所以做起来也不难。通常我们可以根据操作型环境写一个下载的顺序文件，使用这个顺序文件，可以在不破坏联机环境的前提下下载到数据仓库中。（似乎挺不错的）

第三个选项可就有点复杂了，因为，就再你装载数据的时候，数据库正发生着变化，要有效的捕捉到那些变化不是一件容易的事。所以，扫描已有的文件（或者表格）成了数据仓库体系结构设计者的主要难题。怎么办，怎么办……其实方法很多——有五种。

1．      扫描有时戳的数据，你可以清楚的知道：那些需要的数据是最近更新了的，至少我们可以有效避开时间不符的数据。（不幸的是：没有多少数据有时戳）

2．      扫描增量文件，（什么是增量文件，我也不知道，但可以肯定的是，它是由应用程序生成的，仅仅纪录发生改变的数据），不幸的事，没有多少程序有增量文件。L

3．      扫描审计文件和日志文件，这两个文件本质上和增量文件是一样的，除了大了一点，无用数据多了一点，接口程序难做一点，没别的坏处J。

4．      修改应用程序代码，（这好像过分了一点，为了设计数据仓库，居然让别人从写自己的应用程序），这并不常用，应为一个用程序的代码陈旧而且不易修改。L

5．      第五种方法就是没有方法！开玩笑。包括本书的所有资料都劝解我们不要这样做，所以，我只随便说两句：按时间做一些映像文件，比较他们的差别。但最好比用，我也觉得着方法不仅麻烦、复杂，而且需要各种资源。所以不到万不得已不用！J

第三个问题： 时基变化，难以把握。现存的操作型数据通常是当前值，精度可控，可以更新，但数据仓库中的数据是不能更新的，所以这些数据必须附带时间元素，实际操作的时候，从操作型系统传送到数据仓库时，必须在数据中进行较大范围的改变。这时，你就必须考虑数据的浓缩了，没办法，数据随时间总在变，数据仓库的空间有限阿！

到此为止，我们涉及了三个问题，以及他们的解决方法，但这还不足以使我们建一个自己的数据仓库，应为我们还没有学具体方法。下面一节的内容将……！

数据/过程模型和体系结构设计方法

首先介绍两个概念：过程建模和数据建模，简单的说，过程建模就像我们在编程之前画的流程图！有开始and结束。数据建模就像是给你白菜，萝卜、醋、食盐等，然后问你能做出什么菜，然后你很自然的回答：醋溜白菜&萝卜汤一样。没有为什么要这样做，应为只能这样做。J

过程建模是绝对不能用在数据仓库的设计上的，因为过程建模是基于需求的，它假设在细节设计之初就已经知道了需求，但在一点在建设数据从那个库的时候并不满足！

数据模型就好得多，它两边都合适！（嘻嘻，像万能胶）建造数据模型的时候不需要考虑现存的、操作型系统与数据仓库之间的差别。要做的事情看上去好像很简单：建一个企业数据模型，再建一个数据仓库模型，最好再来一个操作数据模型，可以这样理解：

企业模型à操作模型à数据仓库模型

三个方面都很重要，而且互不相同。(有点像鸡和蛋的关系)

随便聊聊数据模型吧，分三个层次的建模：高层建模（实体模型RED）、中间层建模（数据项集DIS）和底层建模（物理层）。建造的顺序是由上向下，就好像大家坐在一起，讨论出来一个大体的架构，开始中间层的设计工作（因为RED需要的数据不可能简单的抽取到，需要一定的综合方法），然后根据中间层设计底层模型，（底层模型的数据是可以从操作型数据中得到的）。

呵呵，我还是不深入讨论了，给你留一点内容可以自己琢磨一下（而且本书也不是专门讲建模的教材）。

是不是有点晕了，什么数据建模、什么三个层次，别急，等你带着这些问题去看书的时候，问题很快就没有了，我之是建议你能纪录一下自己的问题，不至于在看书的时候，连问题都忘了。J

数据建模同时也是一个拼积木的过程，每次设计的结果都是一块独特积木，这有在凑够所有的积木之后，才可以完成一幅拼图。（一个任务）

以上介绍的是数据仓库的设计方法——数据建模。下面来谈一谈设计数据仓库的几个细节问题：（这可能会很枯燥）

规范化/反规范化

这种操作的目的是减少系统的I/O操作时间。具体的方法可以归纳为两句话：为了减少I/O操作所用的时间，将一些表合并（规范化），或者引入冗余数据（反规范化）。

 

数据仓库的快照

快照是一个事件的详细纪录。举例：你用了一大笔钱买了一件心爱的东西的时候，突然发现下半个月的生活费没有了，这就是那个事件，而产生的快照如下：

时间 | 键码 | 地点 金额 物品 …… 购买时的心情 | 账户余额 …… 购买后的心情 |

 1     2                      3                                4

不难看出：第三段数据是离散的原始数据，第四段是事件发生后的因果数据（是联系的、可选的）总结一把，快照应该是对一个事件的真实记录，他应该包含以下内容：

l         键码。

l         时间单元。

l         只和键码关联的初始数据。

l         快照发生后所捕获的二次数据，和前面无直接的关系。

 

元数据

关于（使用）数据的（历史）数据，例如说数据仓库导入的第一次时间、第二次时间。源数据在Where，数据结构是what，抽取的历史纪录等等。

 

 

 

数据仓库中的管理参照表

数据仓库中的参考数据（起数据年鉴作用），数据仓库存在目的也就是为了提供参考依据，所以定期的产生参照数据可以减少数据仓库中的数据量。这也不难理解：有了参照数据，自然就没必要保留那些陈年旧帐了。

建立参照数据表有两种方法：

1．  每隔一个特定的时间，就做一个参考表的一个快照。

2．  一个快照就是一张参考表（合而为一），然后，针对每次修改做纪录。

 

数据周期

所谓数据周期是指从操作型环境数据发生改变，到这个变化在数据仓库中体现出来所用的时间。例如某位银行用户搬家，他的新地址被添加在操作型数据中，数据仓库觉察到后，立刻把自己的数据更新。这就是一个数据周期。

问题来了，这种调整应该什么时间进行一次呢？原则上是大于或等于24小时。这是为了数据的稳定和代价问题。

 

转换和集成的复杂性

这里有很多很多的内容，偏偏他们都很零碎，象是在介绍经验一样，还是留给你一点研究吧。（我要偷懒啦）这就是建数据库的方法。

 

触发数据仓库纪录

触发数据仓库需要一个事件，而这个事件应该是一重要活动，重要的以至于不能忽略它的存在，呵呵，简单点就像点了一个按钮，弹出了一个对话框一样。当捕获到这个事件的时候，在数据仓库中添加这个事件的快照。很简单，不是么？可能你会想知道，什么事件，怎么触发？举个例子，你的一个重要的客户，打电话通知你，修改交货地点，OK！你的反应恐怕是先找到这条发货纪录和客户纪录（这是快照），修改其中的交货地点（二次数据），写入数据仓库中。明白了？

 

管理数据仓库

管理的目的是为了让数据该走的走，该留的留，该统计的就统计，不要让过了期的数据占用宝贵的空间，呵呵，说着容易做着难，每人知道用户那一天会发疯似的翻陈年旧帐，万一出了差错，会坏事的哦。所以正确的处理方法就是：·#￥%…！·#。没看懂？啊哈，不好意思，这是外语，嘻嘻，总结一下有两点：

1．    使用简单纪录方式，概括、综合数据。这里有一个综合尺度的问题，不要一次就把数据综合到底，不要一次就丢掉数据的所有细节。让简单纪录的第一遍为第二遍提供依据。

2．    同时建立数据备份。这是最保险的方法，找张光盘阿，磁带阿之类的，写进去丢到保险箱里就完事了。什么？费钱费时，我觉得挺好啊，用户查的时候，可以收她的费么。还赚了一笔J

 

根据以上诸多的论述，你是不是已经建立了一个大体的框架？知道什么才算是数据仓库，怎样的表结构才算是符合数据仓库的？说句老实话，我现在也没能明白数据模型到底是个什么东西？是类似c++里的对象，还是类似数据结构里的结构体？我从中学到的是：数据仓库在设计的时候就必须考虑什么，而不是怎样做。所以，你一定要把这个东西搞明白，近期是不可能的。只能通过不断的实践，只应该是一个经验积累的过程，可以说还没有一个完全可行，可以照搬的方法来设计数据仓库。J是不是挺失望的，没关系，这本来就是一个需要反复的过程，%50的成功率就算是不错的了，所以没必要担心 :P

好吧，假设我们在考虑了所有的情况后，建了一个十分完美的数据仓库（有点厚颜无耻,xixi），开始访问吧，你必须牢记这样一个事实，数据仓库一定有你所需要的数据，否则就必须进行二次补丁开发。你开始统计、抽取、计算等等，没有能不能，只有要不要！

模拟一下，你是一个银行雇员，在收到了一个用户的借贷请求，那你就必须想方法确定这个用户的信用值和个人资产以及工作情况，来判断是否给这个人贷款。这里有一个非常复杂的程序在后台做这件事情。而且数据仓库中也为这种请求准备了相应的数据。这种审核是综合的也是非常快的。这时，必须考虑：

1.       偿还历史。

2.       私有财产。

3.       财务管理。

4.       净值。

5.       全部收入。

6.       全部开销。

7.       其它的无形资产。

……

在经过复杂的计算后，才能得到审核的最后结果，但这个过程所需的很多数据都是数据仓库整理出来的。Ok,你是不是明白了数据仓库还是挺有用的。

但让我们考虑一下这种数据的存在形式吧，……，有没有发现最后的数据是一个综合了很多情况的合成数据。很多很多的内容，像一个大锅腊八粥，但里边的配料来在不同的地方。嘻嘻，其实这是数据仓库中必然的现象，称之为星型联接。哦——，其实这些部分都是有名字的，中间的综合的是“事实表”，周边的是维表。而且这里边还有一个现象：事实表中包含了维表的主键。你可能没有反应过来，但事实就是这样。

这里遍蕴含了数据仓库的访问技巧。

好好想想吧，想明白了最好能教一下我J。

 

 

 

 

 

 

在明白了涉及数据仓库的几大要素之后，OK! Let’s go on. 下面的问题将很深入的讨论类似于设计细节和管理细节的话题。看过之后需要深入的思考，这才能从中领悟作者的本意。主要原因也包括翻译问题。

来看看第一个问题：

数据仓库的粒度

数据仓库中的粒度是指数据的详细程度，同样为了描述一个情况，我可以用很多的数据，但同样我也可以只用必需的数据。而这起决于存储器。如果有很大的硬盘，那就没有我们不能存的事情。所以，估计一年内里表中的最大行数和最小行数，是设计者的最大问题。这里牵扯到了一个概念：上下限推测的方法。（别问我，我也不懂）

然后通过简单的计算可以知道数据库大概的情况，然后可以调整我们的策略。说的仔细一点，我们可以采用双重粒度或者单一粒度的办法。

双重粒度是降低数据量的最佳方法。而且，大多数公司都采用这种方法。下面来一个分析：

双重粒度包括：低细节级和高细节级。要知道：在很低的细节级上建立轻度汇总数据是没有意义的。反过来，在太高的细节级建立汇总数据也是没有用的。所以，一定要进行数据粒度的评估，然后才能得出最佳的汇总方案。而可笑的是，这根本都是猜测出来的，没有正确性的保证，嘿嘿，没办法，谁让我们本来就是在做一件不知道条件，指知道结果的方程式呢，但你可以把你的结果给最终用户看，让她来评价这个好坏，别指望%100的通过，%50就很不错了：）

这里有一些反馈技巧和一个例子，在90页，你可以参考一下。

如果说，数据粒度教你建数据仓库的话，下一个话题就是教你管理啦！

数据仓库和技术

这里有好多我看不懂的管理技术，嘻嘻，比如说：通过寻址，通过检索，通过数据外延，通过有效的溢出管理…… 这里的管理包括：管理大量数据库的能力和能管理好数据仓库的能力。任何生成支持数据仓库的技术都要满足能力于效率的要求。

你要能管理多介质，主存、扩展内存、高速缓存、DSAD(如硬盘)、光盘、磁带……

数据仓库的灵魂就在于灵活性和对数据的不可预测性的访问，看不懂么？所的简单点，就是它能对以往所有的数据进行评估，提供分析依据。数据仓库如果不能方便有效的利用索引，那么数据仓库的建立就是不成功的。多利用一些二级索引、动态索引、临时索引等等。

多种技术接口，这我不用再解释了吧，这你应该明白的。

对数据存放位置的控制，就像一开始讲的，必须使数据仓库有一整套完善的数据存放机制。而且最好是自动的噢！

数据的并行存储和管理，假定对数据的访问都是等概率的，则性能的提高与数据所分布的物理设备的多少成正比。

元数据的管理，记住这个事实吧，再好的房子，如果没有钥匙你也没办法！！所以，管理元数据的重要性甚至超过了管理数据仓库中的数据。这包括表的结构，表的属性，源数据（纪录系统），映射关系，数据模型说明，抽取日志，共用例行程序。

语言接口，SQL语言接口，就是你要做一个前台控制程序，可以插入、删除……。

数据的高效装入，自己想吧，（什么，老师偷懒，我就偷懒，怎么样）这里没有什么好说的，你需要根据不同的环境做不同的处理。

高效索引的利用、数据压缩、复合键码、变长数据、加锁管理、快速恢复。我就不再多说了，这你比我还明白。

DBMS类型和数据仓库,

多维数据库管理系统（俗称”数据集市”），提供了一种信息系统结构使得对数据库的访问非常灵活。如果我没理解错误的话，数据集市提供了一种数据的管理、考察方案，所以它是凌驾于数据仓库之上的，所以数据仓库的数据，是数据集市的主要数据来源，可以这么说，两者的差别就在于数据粒度的不同，数据仓库中的粒度很小，DBMS的数据粒度很大。当然，这样做是有目的的，这不仅是为了使储存的时间更长，也可以数据更集中！

这里还有很多其他的作用：

例如：

ü         支持数据的动态连接。

ü         能够支持通用的数据更新处理。

ü         关系结构清晰明了。

那它是不是就完美了呢？其实不然！其实也有不少弊病需要克服。

数据量不如关系数据库支持的那么多。

¨         不支持通用的更新技术。

¨         张如时间长。

¨         结构不灵活。

¨         动态支持还有问题。      

 

这是我看完数据仓库后的一点感受，拿出来大家一起研究、研究，哈哈……