建造数据仓库要做些什么？
普通说来，建造数据仓库次要两个方面：

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