结合我实际工作中的数据仓库逻辑区域划分
客户提供的txt文件为source
数据库中raw，cvt表为staging
fact表和dimension表为ODS(Operational Data Store)
MSOLAP中建立好的cube和dimension以后为BaseLine或者DataMart

数据仓库逻辑区域

***Source System（源业务系统） -- Staging Area（暂存区） -- Operational Data Store（ODS，数据存储区）-- Baseline（中央数据仓库）/Datamart(数据集市)***

Staging Area：

主要是为了保证数据移动的顺序进行而开设的增量性的数据存储空间，它是源系统业务数据进入数据仓库的缓存区。从业务系统到Staging的数据传输，应该避免复杂的数据处理，以保证数据的快速导入而尽量减少对业务系统的压力。需要进入数据仓库主题系统的数据首先快速传输到Staging Area，通过Staging Area再转移到目标数据仓库中。从业务系统（如ERP，PSP,NOTES）到Staging Area的数据传输，应该避免复杂的数据处理，以保证数据的快速导入而尽量避免对业务系统的压力。一般，可以创建与OLTP交易系统结构相同的属性，同时在Staging区域需要增加两个属性。

1.Source Code  用来表示源系统

 2.Last Modification Date  用来获得数据处理的时间

如果原来的数据中已有上述两个属性，则需要在新属性中增加DW后缀进行标识。数据成功导入数据仓库之后，应清空Staging Area中的数据。

Staging区域只是为了简化或者使ETL过程，结构更合理，更利于管理等设置的中间存储层，Staging层里的数据理论上是可以对用户不可见的，或者说更像一个技术策略，所以Staging层只是数据仓库中的一个很小的技术模块。

Staging层一般可以理解为数据缓冲层，用来接收源数据，在一定时间里Hold住源数据，一边后续处理，甚至重复处理，这些处理可以完全独立于源系统。

Operational Data Store（ODS）:

ODS的数据作为数据仓库系统数据存储。ODS区域可以从系统上分为两个部分：

1.存放OLTP系统的历史数据

    这部分数据需要考虑是否需要对OLTP中的数据进行LIFE CYCLE的记录（包括交易数据 fact data和基础数据 dimension data，即缓慢变化的处理 SCD）

 2.存放数据仓库部分加工信息

    即通过ODS历史数据经过整合后的信息，这些信息更加全面的反映出主题中某件事务的全貌。

ODS一般可以讲是大型数据仓库中一个独立的系统或环境，是否需要ODS取决于业务需求，通常情况下，如果建立了ODS，那个ODS就要承担较大的数据整合的任务，一边数据仓库主要集中于解决数据应用层面的需求，另外一般如果有ODS的话，ODS也会向外提供一定的应用，所以ODS是对用户可见的，而不死附属于数据仓库的。

数据模型的建立要看系统更侧重于解决什么样的业务问题，ODS理论上是一个兼具生产系统和分析系统特性的系统，所以要看建设ODS到底是为了解决分析系统多一些，还是为了解决生产系统问题多一些如果两者兼顾，那么对数据模型要求多层设计，分别满足不同需求。

Baseline（中央数据仓库）:

它是真正具有星型结构的多维数据存储区，这个部分包括两种实体（FACT ENTITY和DIMENSION ENTITY）。Baseline部分需要支持最细粒度级别，保证可以在最细粒度级别实现多维的分析。即能够支持汇总数据以及明细数据的多维查询。

FACT ENTITY:

   它是对某个事物（可能是某一笔交易，某一个项目，如一笔到货明细，某一个任务令）的各方面信息的描述，描述行的属性包括：该事物各方面的度量信息，相关度量信息的维度信息

DIMENSION ENTITY:

   此处的维度信息是与FACT ENTITY相关的维信息，包括很多FACT ENTITY共有的维度信息，比如时间维度等。以及某个FACT ENTITY需要的专有的维信息。Baseline部分需要能否支持最细粒度级别，可以保证最细粒度级别实现多维的分析。

Data Mart（数据集市）：

它是某个主题领域的专业的多维数据区。实现某一特定主题领域的多维查询需求。这个部分也包括两个实体（FACT ENTITY和DIMENSION ENTITY）两部分，但是与Baseline不同的是这部分的FACT ENTITY和DIMENSION ENTITY都是为某一主题服务的。