数据仓库的发展和软件的发展共性分析

Jerome 20060516

--一般建议数据集市不做ETL，为啥，因为很多ETL工作是跨主题的，那么这种情况数据集市就成了数据孤岛，怎么能轻松ETL？

ETL是跨主题的，数据集市就成了数据孤岛吗？那MD架构中的conformed table和bus architecture是做什么用的？

--那么EDW行不行，显然不行，因为需要一个维度建模方式的DW才行，于是中间层的需求就出现了。

EDW为什么不行呢，ETL最关键的就是数据的整合和清洗，而EDW就是ETL的结果，在EDW上建立数据集市应该是最舒服的事了。

--因为前提是EDW不是按照维度建模的，是3NF方式，所以无论如何，到数据集市都要经过一个模型的转换。

Kimball提出的conformed table分为两种，分别是conformed dimension（一致性维度）和conformed fact（一致性事实），这两个概念是和bus architecture（总线结构）一起提出的，目的性应该很明显。因为Kimball建立数据仓库的方法是先建立数据集市再合成数据仓库，为了保证能合并成数据仓库而不是一个烟筒集市，需要在Staging Area（数据准备区）先分析好整体的结构包括总线矩阵、一致性维度等。这样才能保证在建立下一个数据集市时保证合成一个企业的视角。而Inmon的CIF架构中的EDW中已经建立好的整个企业视角的数据，该整合、该清洗的都完成了，直接建立数据集市就可以，没有必要再添加一个CDW层做中间过渡。

个人感觉CDW应该是数据仓库发展过程中的一个中间概念，和EDW应该指的是一个东西。

当然了，数据仓库的架构每个企业都有自己的实现方式，也一定各有优缺点，既然IBM有这样的设计，也一定要他的道理。
随便说了几句，欢迎大家拍砖，呵呵。

Innovate 20060517

Kimball提出的bus architecture很多人都看过，在设计的时候，是绘制一个直观的图，把data mart和dimension看看有哪些交叉点，保持一致性是肯定的，但是由于有多个数据集市可能要使用同一个conformed table，那么在每一个具体的集市去ETL显然不明智的，工作重复了。

就象上面提到的，EDW到数据集市中，在哪里建dimensional model？显然不能在EDW建，那么在集市中才开始建？那么Kimball提出的conformed dimension/fact table在不同集市中各自建（数据集市可能庞大到几十个甚至上百个）？这才是中间过度的需要，要不然IBM当初就成傻帽了。

刘庆 20060517

这样干谈太让人犯晕了，不如结合实例说吧，可以来构建一个虚拟的场景。我对电信熟一些，就拿电信业的例子来说吧，当然这不一定有代表性，为了说明自己的观点，大家可以补充这个场景。

场景：

X省有C1、C2、C3三个地市，每个地市各自维护自己营帐(A系统)、计费系统(B系统)，分别是A1、A2、A3和B1、B2、B3，现在要在省公司要分析全省的用户发展，实时监控话费。因此需要在省公司建立一个数据仓库系统。数据源就是三个地市的六个系统。

需要获取的接口包括（[]给出字段，*标识为主键，>表示该字段有相应代码表。）：

1、用户信息(Userinfo)
[*用户ID、客户ID、用户入网时间、>用户状态]
{每日给出发生数据变化的用户数据}
2、客户信息(CustInfo)
[*客户ID、>性别、年龄、>客户级别、客户注册日期]
{每日给出发生数据变化的客户数据}
3、帐单(Bill)
[*用户ID、客户ID、*帐务月份、*>费用类型、费用]
{每月月初给出上月帐单}
4、通话详单(CDR)
[用户ID、号码、对方号码、通话时间、通话时长、>呼叫类型、>通话地区、通话费、批价时间]

{每隔两个小时给出上两个小时的通话详单}

以上四个接口，其中1、2、3接口从每个地市的A系统出，接口4从B系统出。因为各地市的系统独立，编码方式不同，所以诸如用户ID，两个地市可能有重复，而诸如客户级别的编码方式也是不一样。

用这个场景来讨论ODS、EDW、CDW、DM都将会是什么样子吧。

goldenfish 20060517

ODS区:

通过数据通路(接口文件或数据库直连,但首选接口文件),存入ODS.
ODS完成数据合并.其数据结构跟接口需求一致,编码使用类似如下的规范:
C1的 用户ID = "C1"+C1系统的用户ID
C2的用户ID ="C2"+C2系统的用户ID 等.
ODS采用文件存储或数据库存储,不保留历史信息.

EDW:

1. ODS的数据进入EDW的Staging区. Staging区转换为数据库存储,并在装入时进行数据标准化,如费用类型代码标准化.

2. 通过ETL,Staging区的数据进入EDW的数据存储区(EDW提供3NF的模型方式存储)

模型包括: 客户、事件、账务、合约等主题。其中用户信息进入合约主题；客户信息进入客户主 题；帐单信息进入账务主题；通话记录进入事件主题。

客户主题下可能包含 客户、客户协议历史、客户状态历史、客户轮廓历史（人口地理信息）、客户级别历史等；账务主题包含费用历史等；

CDW：不太认同它作为单独的层次。作为到DM的过渡层次，可以在EDW中通过视图来实现某一时点的数据视图。它为DM的事实表提供基础数据，将分散、致密的3NF模型连接成平面表。实际也就是恢复成例如用户费用表（包含用户ID、用户入网时间、用户状态、号码、对方号码、通话时间、通话时长、>呼叫类型、>通话地区、通话费、批价时间等属性）；
Staging Area：与上面一样作为过渡。

DM： 星型模式

例如完成用户费用分析

维度包括：

入网时间区间（5年以上、3到5年、1－3年、1年以内）：根据用户入网时间计算；
用户状态；
通话时长区间（1分钟以内、1－10分钟、10分钟以上等）：根据时长分段；
呼叫类型；
通话地区（分区内、区间、长途等）；
等等；

度量包括：通话费

Jerome 20060517

我先在这表个态，goldenfish3的架构和建模很好，呵呵。和CIF的架构方式基本一样，不同的只是名称的不同，CIF的Staging Area＝goldenfish3的ODS＋Staging区，CIF的ODS goldenfish3没有建立。

采用CIF架构设计

1.建立数据准备区（Staging Area），也称集成转化层。建立临时表，将接口文件导入临时表，进行整合和清洗，导入给数据仓库准备数据的临时表，这部分客户不能访问。整合和清洗的方法略，goldenfish3的方法就很好。

2.操作数据存储（ODS），如果有必要的话操作数据存储的模型和数据仓库基本上是一样的，只是保存的数据量新一些，小一些。根据需要，可以两个小时导入一次（如果源系统能提供的话），保存一天或者一个月或者更多，这部分用户可以访问。
这部分其实我不太清楚，没有在项目中建立过，DW2.0里ODS的概念和以前好像也不一样了，不建议建立ODS。

3.数据仓库（EDW），将临时表中准备好的数据导入数据仓库（3NF），对于变化的数据，增加时间标识（开始时间）和原主键共同作为主键，建立新的记录，进一步增加截至时间。比如前面提到的用户和客户。

对于帐单和通话详单通过发生时间或者记录时间可以和用户、客户表中的开始时间和截至时间相比，找到当时的用户或者客户信息。
这样生成的数据仓库访问起来不太容易，一般不建议用户访问，对于用户的各种需求，由开发人员将数据仓库中的数据导入相应的数据集市或者探索仓库。

4.建立数据集市，数据集市采用维度建模，对于象用户和客户这样要建立成维度表的信息，根据需求来决定是否反映变化情况，数据仓库中保存着所有的历史信息和变化情况，有什么样的需求都可以加载到相应的数据集市。

对于在数据仓库和数据集市之间需不需要staging，我觉得没必要，staging的意思就是将数据写到硬盘上，Staging area的意思就是我要保存数据，不管是以文件形式还是数据库形式，这部分如果通过工具或存储过程可以直接将数据导过去，如果中间非要加一层来存临时数据的话，不能说不可以，但是总觉得没必要。

对于是否有必要建立CDW，我觉得也没必要，这里如果建立CDW，并且不能用户访问的话，其实就是Staging area。kimball提出conformed table目的就是建立多个数据集市时数据要统一，CIF架构中的表本来就是建立在一起的，也就是说建立多少个数据集市，都是从一个地方出的数据，如果要保证在每个数据集市中的相同维度显示的文本都要统一的话，可以在数据仓库中直接把描述信息统一就可以了，没必要非得建立一个象CDW这样一个大的中间层。

dimensional model直接建立在数据集市中，数据都是在EDW中出，EDW中的数据已经是一致的了。

采用MD架构设计

1.建立数据准备区（Staging Area）

建立临时表，将接口文件导入临时表，进行整合和清洗，导入给数据集市准备数据的表。根据需要来决定保存数据的时间长短。
建立查找表，加载到内存，用来替换代理键。
建立一致性维度，给其他数据集市做准备。
从功能上来说，MD的staging area 相当于 CIF 的staging area+EDW。

目的是做好不出烟囱集市的准备后就可以直接建立数据集市，不用等所有的数据都进入数据仓库后再建立数据集市。这部分用户不能访问。

2.建立数据集市

维度建模来实现数据集市，使用一致性维度。
可以和其他的数据集市一起组合成数据仓库。

bty,这个虚拟的场景有点简单，不能很好的区分CIF和MD的差别和优缺点。

innovate 20060518

我想Jerome的假设都是建立在比较单一的情况,如果是单一的情况, 甚至EDW的建设都可以省去.比如刘庆列举的例子, 大家觉得有必要建设EDW么?根本建设数据集市就能满足各种分析需求了嘛。

如果是多种情况, 我们不用说太具体的例子,不然就说太长了. 比如一个500强制造业,需要一个全方位企业级数据仓库的建设,数据源有来自ERP的, 有来自CRM的, 有来自OA的,还有来自手工录入的调查资料等等. 数据内容含盖采购、生产、库存、销售、定单、物流、财务，以及客户关系数据等。同时客户的部门级以及总部的很多需求（假设之前客户采用数据集市的方式分别满足需求，现在需要统一建立中心企业数据仓库）。

就拿大的分析需求方向来讲，每个大区分公司的重点可能是不同的，总公司的关心点也得考虑。为了节约成本，采购、生产、库存、物流肯定都得分析，为了占领市场制高点，销售、客户关系环节非常重要，而财务则需要综合以上所有因素得出结果。比如产品这个dimensional-fact, 将会贯穿生产、物流、销售、客户关系、财务等多个主题方向；客户/代理商维贯穿物流、销售、客户关系、财务多个主题。当然，时间、地点维贯穿几乎所有主题。

在我们建设企业级数据仓库的时候，这些通用的事实/维是统一集成ETL，他们不再是孤立的。要过度到数据集市，所谓的conformed table的建设是必要的，这个时候要在多个不同的数据集市各自形成conformed table是不符合其特点的，也就是说它还是得在企业级环境下形成，最后分发给数据集市。试问，如果有没这层，conformed table在哪里形成，是在EDW么？那不是显得不伦不类？

刘庆 20060518

这下清楚多了，试图将三位的观点总结一下，不知道对不对，有误解之处，请指正。

Innovate：

接口->ODS->EDW->CDW->Staging Area->DM
ODS：和接口结构完全一样
EDW：3NF建模，保存历史，统一编码
CDW：多维建模，是否保存历史（？ ）
Staging Area：？
DM：维度建模
Godenfish：

接口->ODS->Staging Area->EDW->DM
ODS：和接口结构相同，作一定的统一编码，不保留历史
Stage Area：？
EDW：3NF建模，保存历史，统一编码
CDW：无
DM：维度建模
Jerome
CIF：

接口->Staging Area->ODS->EDW->DM
Staging Area：和接口结构完全一样，进行数据清洗
ODS：不保存历史，统一编码
EDW：3NF建模，保存历史
CDW：无
DM：维度建模，只有一个
总线架构：
接口->Staging Area->DM
Staging Area：先建和接口一样的临时表（或者从文件），进行维度建模，统一编码，建立一致维度
DM：维度建模

我也提出一种以往电信经营分析项目中用过架构，当然，几乎是从总线架构派生出来，只是名称不同而已：

接口->ODS->DW->DM
ODS：几乎跟接口接口一摸一样，但进行数据清洗和统一编码，代码表完全转换成维表
DW：维度建模，保存历史
DM：维度建模
CDW：无
Staging Area：无

从以上几种架构看，对数据集市，采用维度建模这是没有异议的拉，对于EDW进行3NF并保存历史数据，似乎也是没有异议的。但ODS、DW的功能、特点似乎有些差别。

而对于Staging Area，大家都称它为过渡作用，但它究竟是什么，也是很模糊。可以理解为一个数据库，都是放了一些临时表，主要用来存放ETL中间环节的数据。或者它就是文件系统中临时存放中间数据的地方。大家也都认同它不会向最终用户提供访问，那么是否有必要将它作为一个和EDW、DM同一层面的概念呢？从接口到ODS要ETL，就需要Staging Area，从CDW到DM也要ETL，同样需要它。

还有godenfish提出来的架构中，为什么在ODS进行一部分统一编码，到EDW中又进行编码标准化的工作？

另外，jemore觉得这个场景太简单，不能说明CIF和总线架构的区别，可以改进这个场景啊，当然也能够保证它足够简单。

goldenfish 20060518

首先要说的是，我不认为staing area应该拿出来与ODS/EDW/DM等并列。它位于EDW内的第一层。如果划的更细点，EDW还可以先landing area（数据降落，就是接口数据落地存储，落地过程中可能会做数据标准化处理）再staging area（登台文件转入数据库中）。
在ODS中进行统一编码，是说将用户ID等统一编码。而不是编码标准化。例如对于客户类别，

A1系统中使用 1. 大客户 2.中小客户 区分；
A2系统中使用 1.大中型客户 2 小客户 区分；
那么在ODS中，对于客户类别可能采用： 1. A1大客户 2. A1中小客户 3.A2大中客户 4 A3小客户 这种代码统一编码方式。

编码的标准化放在了EDW的Staging过程中了，因为ODS是比较薄的一层。要考虑硬件性能等能否支持高效的数据标准化。(如果DW的硬件性能更好，不如放在DW。）当然在ODS进行编码标准化也无不可，也就是将客户类型统一成1.大客户 2 中客户 3 小客户。
也可以有权衡的做法，例如，即记录级的标准化工作在ODS完成，跨记录的标准化在staing area完成。

还有EDW如果与CDW都存在的话，CDW也保留历史，肯定要考虑存储代价。当10T的源数据却需要20T的存储时，决策者很难认同这种方案。也听说过DW采用维度建模而不使用CIF的思路的，只有几个事实表，但有100多个维度。听起来很不可思议，不知道细节是什么样的。
Innovate 20060518
首先CDW只是一个中间层，不然我不会将它比喻为中间件了，当然不会保存历史纪录，只是按照数据集市需求的去从EDW准备待处理数据。在一些英文文档中是这样描述的：CDW is a temporary layer to extract the data which will be process for XX layer

所谓staging area, 在这里拿到CDW的dimensional数据，根据数据集市的需要再进行一定的ETL，最后生成大家都知道conformed tables。要知道一个conformed table, 可不止一个数据集市需要，N多数据集市都可能需要，所以在每个数据集市里去处理，显然很不明智。

再次提到很具体而且必须考虑的问题，试想，如果没有过渡，数据集市需要的conformed tables怎么去形成？如果这个问题不解决，利用Kimball的思想建设数据集市就是空话。
Dumpedjoe 20060518
这个主题热闹。

CDW是中间层，不好称之为中间件。对于采用Kimball的维度建模无需引入CDW，CDW是应对传统CIF架构（Inmon对CIF有更新）的EDW和时下流行的MD数据集市有效沟通的一个好的解决方法。

采用CIF构建EDW对各方面要求更高（相对MD），包括对企业全局业务的理解、数据的分布等等，也是时下MD流行的原因。

老外其实很苦啊，当年硬上EDW，没整好（刚上路嘛），IBM聪明啊，搞个CDW，挣钱，不好推倒重来嘛。

刘庆给出的场景缺少需求，要是加上基于DW的、有需求交叉的多个数据集市的简单需求就能看出MD和EDW引入CDW的区别。比如卡分析和信用风险分析，应该可以看出采用不同方法生成conform table的不同过程。

Jerome 20060518

--我想Jerome的假设都是建立在比较单一的情况,如果是单一的情况, 甚至EDW的建设都可以省去.比如刘庆列举的例子, 大家觉得有必要建设EDW么?根本建设数据集市就能满足各种分析需求了嘛.

我想我可能是表达的不太清楚，我只是就着这个例子说几句，没有假设比较单一的情况，呵呵。觉得单一可能是因为关于数据整合、清洗部分我没有发表言论。

这个例子是比较简单，没必要建立EDW，只是借用这个例子来说明一下架构。很遗憾，我对电信业务不熟悉，所以举出的例子中涉及电信业务的内容写不出东西来，只是泛泛的谈了谈架构。

--再次提到很具体而且必须考虑的问题，试想，如果没有过渡，数据集市需要的conformed tables怎么去形成？如果这个问题不解决，利用Kimball的思想建设数据集市就是空话。

innovate511 能详细介绍一下conformed table要实现的功能或具体的实现方法吗？我想了解一下为什么在EDW中不能实现同样的功能。confomed table当然不能在dm中实现，但dimension model是建立在dm中的。

如果建立EDW的话，不见得要建立confomed table，但是类似confomed table
的功能是一定要在EDW中实现。kimball在staging area中就能实现confomed table，为什么inmon不能在staging area+edw中实现同样的功能，还要再加一层来实现呢？

如果不考虑费用和复杂性的话，建立CDW当然是一个很好的选择，可以把这部分功能再细化一下到CDW中。但是EDW已经够复杂的了，要多大的工程才能允许我们建立更复杂的架构?个人更倾向于直接建立MD架构。

--Jerome
--CIF：
--接口->Staging Area->ODS->EDW->DM
-- Staging Area：和接口结构完全一样，进行数据清洗
-- ODS：不保存历史，统一编码
-- EDW：3NF建模，保存历史
-- CDW：无
-- DM：维度建模，只有一个
--总线架构：
--接口->Staging Area->DM
-- Staging Area：先建和接口一样的临时表（或者从文件），进行维度建模，统一编码，建立一致维度
-- DM：维度建模

Staging Area只是为了处理数据方便建立的一个存储区，建不建立完全看自己的需要，觉得直接能导过去，就不要staging，觉得中间建立一些表，处理数据方便的话，就可以staging，ETL架构师凭自己的经验来做决定。

当然也可以有一些其他的考虑，如给审计用，保留数据来源的历史记录，导入失败的话重新开始方便一些等。建不建立要看具体情况，复杂的情况下，可以包括下面几部分：

1.和接口结构一样，装载数据。
1.5中间整合业务等根据需要建立一些表。
2.和EDW结构一样，保存处理好的数据，以便一次性装载入EDW，因为处理的过程有可能是记录级的处理，一条一条的写入EDW不太好。简单的情况，就不用staging了。直接用etl工具或写存储过程导。

ODS只是一个可选的。

CIF架构中，DM是不止一个的，在理论上说，数据集市和探索仓库应该是不限数目的。因为CIF的思想就是，在EDW中是整合好的最全的数据，有什么需要都可以单独建立数据集市或者探索仓库给他用。

--我也提出一种以往电信经营分析项目中用过架构，当然，几乎是从总线架构派生出来，只是名称不同而已：

--接口->ODS->DW->DM
ODS：几乎跟接口接口一摸一样，但进行数据清洗和统一编码，代码表完全转换成维表
-- DW：维度建模，保存历史
-- DM：维度建模
-- CDW：无
-- Staging Area：无

我觉得在这个架构里，ODS就是Staging Area。只是概念上的不统一。

--首先要说的是，我不认为staing area应该拿出来与ODS/EDW/DM等并列。它位于EDW内的第一层。如果划的更细点，EDW还可以先landing area（数据降落，就是接口数据落地存储，落地过程中可能会做数据标准化处理）再stagingarea（登台 文件转入数据库中）。

把Staging Area归入EDW，这个只是概念上和物理位置的不同吧。功能应该是一样的。另外这个ODS是用户可以访问的吗？ODS这个概念尤其的不统一。

--也听说过DW采用维度建模而不使用CIF的思路的，只有几个事实表，但有100多个维度。听起来很不可思议，不知道细节是什么样的。

这怎么可能呢，几个事实表能分析些什么。

Innovate 20060519

不好意思,可能我也没有完全表达清楚，毕竟一个比较大的讨论.简单的说,首先建设EDW的项目,到底数据集市是否使用dimensional设计思路,如果数据集市也是3NF结构,那么我们的讨论点就有很大的出入了,也就没有讨论下去的必要了.

如果数据集市是使用dimensional设计思路, 那么是否把EDW的数据直接影射到数据集市,不需要过度?我想反对者的观点应该是直接把EDW ETL好的,具有一致性的数据导入数据集市. 我就比较奇怪了,3NF结构和dimensional结构相差很大,如何能一步到位?

一般来说, 数据集市使用dimensional设计是最好的方法, 现在简单说一下几点不可能直接从EDW到数据集市一步到位的原因:

1. 数据集市需要的很多数据, EDW不能提供, 因为EDW面向企业通用的基本信息,而数据集市面向客户刁钻的具体应用. 举一个简单的例子,一家全球性企业需要定义一些特别的时间,不同国家不同日期为假期, EDW比较难实现,因为它没有专门的时间维表去记录这些特殊的标志, 如果每个有时间的表都要ETL, 那这个系统估计得死了.

如果直接从EDW到数据集市, 那么放到数据集市去处理如何? 前面我们说过,由于这是企业级通用的, 应该在数据集市之前就搞定conformed table, 供所有数据集市使用, 不适合数据集市单独使用。

2. EDW不适合使用代理键技术,因为这个技术是建立在维度建模方式上的.但如果仅仅在数据集市使用代理键, 那一致性就完了,也就是说局限了不能使用代理键, 多好的技术呀.

其他的一时没想起来,现在也太晚了,晚上加班才回来看到回帖.但是如果能解决实际问题,比如效率、准确性和扩展性, 作为工程,只要好使就可以, 没有绝对的事情.但是大项目中加层是很普遍的现象, 因为效率原因,我们不能让复杂的ETL在海量数据中一步到位,那是知名的. 但是由于CDW也是面向企业级的,而又是维度建模方式, 所以显得很特别.

Jerome 20060520

这个话题讨论到这里也该有个终结了，虽然还遗留的几个颇有争议的问题让人
意犹未尽。在以后的话题中我们还有很多机会来进行更深一步的探讨。
innovate511,goldenfish3,dumpedjoe对数据仓库架构了理解，以及刘庆高度概括的能力和优美的文笔都让我非常的钦佩。很高兴参与本话题的讨论。

happy 20060522

看了各位对数据仓库架构的分析，我受益厞浅。有几个问题请教各位：

ODS与EDW一样都采用3NF建模，ODS和接口文件机构相同，那么EDW的结构与ODS有什么不同啊？除了ODS不保存历史记录外，它们各自保存的数据有什么不同？为什么说EDW是面向主题的、集成的？那么与ODS的结构和数据相比，怎么才能做到面向主题且集成？如果哪位可以结合个例子来说就更好了。

我看了inmon关于EDW的解释，说EDW中的数据是light Normalized，是不是可以这么理解：ODS中的数据结构与接口文件和operational data source一样，都是Normalized，数据在ODS中是没有冗余的；而EDW虽然是3NF的，但不是完全按照3NF来进行的，因为对ODS中的数据进行面向主题的组织，并且按照业务进行了集成（具体怎么实现我不会，还要请教大家），所以数据是轻度冗余的。

EDW之后就是DM了，DM是多维模型，数据是冗余的。就这样，数据是逐渐从3NF格式过渡到维度模型的。

不知这样理解对不对？我没有按照EDW来做过项目，还请各位指点！

innovate 20060523

这就出现了我前面提到的问题了，我参加过NCR的某省移动的项目，就是采用EDW的方案，但是数据流向DM的时候出现了很多问题，也许这不是NCR的真正实力，DM那块是国内公司去做的。当时的特点就是DM不是维度建模，但是很多东西都是过早汇总，并没有把业务的变化体现在原子粒度上，我想这不是EDW项目的原意吧？

sean 20060524

"我也提出一种以往电信经营分析项目中用过架构，当然，几乎是从总线架构派生出来，只是名称不同而已：

接口->ODS->DW->DM
ODS：几乎跟接口接口一摸一样，但进行数据清洗和统一编码，代码表完全转换成维表
DW：维度建模，保存历史
DM：维度建模
CDW：无
Staging Area：无"

我比较赞同刘庆的观点。层次上越简单越直观越好，具体层次上的扩展可以大点，但层次上尽量扁平化。而且，从目前电信行业的应用来看，即使上10TB的数据量，也应用不到那么复杂的EDW,CDW。

和刘庆稍有不同的是，建议在ODS层单独建个用户，存放源数据，即生产系统来的原封不动的数据，做为生产系统数据的快照。结构化存储源数据，有利于提高应用时的速度；另外，建议数据和抽取分离存放，抽取越简单越好，能不用工具最好，我倾向于纯过程ETL。

innovate 20060524

需要补充几点

看见前面有朋友提到数据集市的问题时候，说采用conformed tabls建模就可以解决数据集市信息孤岛的问题。要知道Kimball说的conformed table可不是数据集市层做的，是在数据仓库做的，是面向企业的，不是面向部门的。再重复下他打的比喻，数据仓库好比厨房，各种客户需求的东西都在这里做，数据集市好比餐桌，只是某些特定用户需要的东西，对于这个用户来说，他们要的东西就是孤立的。他们一旦有新的需求，那么就得叫“厨房”帮他们搞定，然后再端上他们的“餐桌”。

正如软件的发展，CS结构不可以么，为啥有的产品或者项目非要用BS结构？结构越来越复杂，并不是搞个花样，而是解决实际的问题。分层处理有几个最大的优点，复杂的业务、海量数据容易处理；新需求容易满足、扩展性强；查询错误容易查询。而且采用conformed tables模型设计的时候，已经注定企业通用的事实、维是可信的，可重用的，新需求一出来，如果仅仅是部门级特别的需求，可以重用conformed tables，那么一旦有数据质量问题，我们查询的范围也就缩小了。