相关概念的理解

业务层数据->ODS 层数据->数据仓库数据

具体参考：
http://www.cnblogs.com/wuhuacong/archive/2010/05/11/1732710.html

数据仓库的开发，是完全独立于OLTP系统的，也就是独立于当前各种应用的业务系统而作的分析项目，因此要包含从数据的迁移（提取）、变换、清洗、加载等ETL操作，其中可以分为这么几个数据层。

源数据层
客户的各种业务系统中的数据，如包括企业、车辆和司机信息系统、企业录入数据和及营运等数据，里面存放了大量的事务数据。

ODS数据层
数据库用户ODS数据层主要管理把业务数据层的数据存储到ODS数据层，它的数据表主要就是来源于业务数据表，通过一些存储过程把业务数据表结构改变成基层的数据仓库的表结构。

ODS是一个面向主题的、集成的、可变的、当前的细节数据集合，用于支持企业对于即时性的、操作性的、集成的全体信息的需求。常常被作为数据仓库的过渡，也是数据仓库项目的可选项之一。

为什么需要有一个ODS系统呢？一般在带有ODS的系统体系结构中，ODS都具备如下几个作用：
1） 在业务系统和数据仓库之间形成一个隔离层。
2） 转移一部分业务系统细节查询的功能。
3） 完成数据仓库中不能完成的一些功能。

在实际应用中，如果 etl过程中从业务数据表映射到数据仓库比较复杂，可以考虑 ods 这个中间层。有点类似中间表，这样可以方便开发人员 debug，查看数据出错的环节。然后再从 ods 层到数据仓库层进一步映射。比如说你的基础事实表，设计多个业务数据源的融合或者 join 等。

数据仓库<->数据集市

简单的说：数据仓库是面向整个企业的，而数据集市可能是面向部门或者某个地区的分公司等。类似于中国电信和中国电信浙江分公司关系。
数据仓库的设计方法论上有两种方式：自顶向上，自上向下。这样，你可以先有数据集市提取组织成你的数据仓库，也可以先有数据仓库，然后通过地区粗维度生产中间数据作为部分或者区域性的数据集市。
参考：<>
DW数据层
数据库用户DW主要管理把ODS数据层的数据存储到DW数据层，它的数据表主要就是来源于ODS数据表，通过一些存储过程把ODS数据表结构改变成项目主题数据仓库的表结构。
DW数据层还管理一些对存储过程的记录表，方便数据仓库的维护和管理。
参考：
http://blog.csdn.net/nisjlvhudy/article/details/7895843
https://www.bbsmax.com/A/kmzL00xAzG/
http://www.docin.com/p-795752811.html

Fact,Attribute,Demension,Metric

• Fact:对于detail 的某些数字类型的列， Metric 则为 在事实列基础上进行的聚合函数的计算结果。事实表则有需要用户 group by 的 attribute和 fact 列组成。
• Attribute:为业务表中的某些列，需要走 group 的列
• 多个 Attribute 组成 Demension。当然单个 attribute 也可以是1维的 demension。
• Metric：需要考察的数据指标。通常在事实表或者其他中间表的某些列上做聚合而成。

维度，OLAP

参考：http://www.cnblogs.com/mq0036/p/4155832.html
有的数据仓库系统带有 OLAP，而有的不带。有的 BI系统带有 OLAP 的 cube，同样简单的 BI可能不带，只做报表展示。

数据仓库设计模型

星型：简单事实和维表

雪花型：在星型基础上，分解维表

星系型：多个事实表的雪花型的组合

实例参考：http://www.cnblogs.com/hadoopdev/p/4235257.html

比较常用的是上面的模型，来源于数据仓库建模的方法论-——维度建模法，另外还有实体建模和3NF建模，比较不常用,了解下即可。具体参考http://www.myexception.cn/data-warehouse/1821560.html

实例理解

http://blog.itpub.net/23659908/viewspace-1118762/

多维数据模型的优缺点

参考：http://webdataanalysis.net/web-data-warehouse/multidimensional-data-model/
　　这里所说的多维模型是指基于关系数据库的多维数据模型，其与传统的关系模型相比有着自身的优缺点

• 优点：
  　　多维数据模型最大的优点就是其基于分析优化的数据组织和存储模式。举个简单的例子，电子商务网站的操作数据库中记录的可能是某个时间点，某个用户购买了某个商品，并寄送到某个具体的地址的这种记录的集合，于是我们无法马上获取2010年的7月份到底有多少用户购买了商品，或者2010年的7月份有多少的浙江省用户购买了商品？但是在基于多维模型的基础上，此类查询就变得简单了，只要在时间维上将数据聚合到2010年的7月份，同时在地域维上将数据聚合到浙江省的粒度就可以实现，这个就是OLAP的概念，之后会有相关的文章进行介绍。

缺点：
　　多维模型的缺点就是与关系模型相比其灵活性不够，一旦模型构建就很难进行更改。比如一个订单的事实，其中用户可能购买了多种商品，包括了时间、用户维和商品数量、总价等度量，对于关系模型而言如果我们进而需要区分订单中包含了哪些商品，我们只需要另外再建一张表记录订单号和商品的对应关系即可，但在多维模型里面一旦事实表构建起来后，我们无法将事实表中的一条订单记录再进行拆分，于是无法建立以一个新的维度——产品维，只能另外再建个以产品为主题的事实表。

所以，在建立多维模型之前，我们一般会根据需求首先详细的设计模型，应该包含哪些维和度量，应该让数据保持在哪个粒度上才能满足用户的分析需求。
　　``