数据仓库和多维模型的疑惑

[王艺团]

各位大大：

 

作为一名刚入门的bier，在进行数据仓库建模的过程中，产生诸多疑惑，请教各位一下，不知道各位有这些疑惑没有

 

1、星型模式/多维模型怎么体现数据仓库的集成？

按理说，数据仓库出现的动力，就是因为“信息孤岛”，造成同一个实体(?)的信息分散在不同的企业应用里面，所以要进行集成(集成应该说不仅仅是数据的一致性，还要是全面的，对吧？)

那么，星型模式怎么体现出来把数据集成起来呢？？

比如，超市卖东西，如果是销售部门做销售分析，只分析产品的销售数据，这个应该是部门级的数据集市咯，强调的是对销量相关度量的不同维度/角度的分析，强调的是多维分析，因此，要用多维模型，放在关系数据库实现，就是星型模式/雪花模式了

但是，产品的信息肯定不只有销售啊，还包括购进啊、库存啊、计划啊等等，难道这些也都应每个对应部门建立数据集市/多维模型么？这个时候，不同部门的数据集市也还是分散的嘛，怎么体现集成呢？这时候还不是数据仓库吧，那如果要升级到数据仓库，怎么组织刚才说的这些数据？

数据仓库应该是数据面向主题的抽取、转换、清洗、加载和管理，关键是数据要全面、一致，面向企业范围的，如果用维度模型，我看不出来哪里体现了全面和一致。

 

2、主题如何确定？

蛮多的书上，讲到主题，都是说“分析的对象”，那就是从客户的分析需求出发咯

我觉得大部分书上说的主题这个概念更多的是前端展现的概念，如果从业务和客户的需求出发整理出来的主题，就是前端的主题，或者叫展现模型，这时候，用维度模型自然没有问题的，完全满足多维分析

 

而按照本意，主题应该是一个在较高层次上对数据的抽象，注意，是对数据的抽象，不关应用和客户分析需求的啥事，面向主题的数据组织(即数据仓库)应该独立于数据的处理逻辑的，不管是事务处理逻辑还是分析处理逻辑

数据仓库应该不仅适合于分析型的数据环境，还应该适合于建设企业全局数据库吧，这个时候，不应该把多维模型给扯进来，对不对？

那这个时候，主题要怎么确立？《数据仓库》上说，要从企业数据模型转换过来，可是我们平时的应用都是部门级别的数据模型，如果集成到企业数据模型，也没讲清楚。

 

说的有点乱，主要的意思就是，现在大部分的书和文档介绍的应该都是构建数据集市，而没有真正介绍到如何构建真正的数据仓库！

可能我看的书还不够，所以得出以上的结论，如果哪位童鞋有书或者文档可以反驳我的结论的，欢迎，非常欢迎介绍给我，谢谢

 

 

2009-09-09  17:05:59

------------------------------------------------------------

王艺团

[raullew]

你应该马上把这些东西烧掉，投入到企业实际的工作中去！

On 9月9日, 下午5时33分, "王艺团" <theseus.w...@gmail.com> wrote:
> 各位大大：
>
> 作为一名刚入门的bier，在进行数据仓库建模的过程中，产生诸多疑惑，请教各位一下，不知道各位有这些疑惑没有
>
> 1、星型模式/多维模型怎么体现数据仓库的集成？

> 按理说，数据仓库出现的动力，就是因为"信息孤岛"，造成同一个实体(?)的信息分散在不同的企业应用里面，所以要进行集成(集成应该说不仅仅是数据的一致性，-还要是全面的，对吧？)
> 那么，星型模式怎么体现出来把数据集成起来呢？？
> 比如，超市卖东西，如果是销售部门做销售分析，只分析产品的销售数据，这个应该是部门级的数据集市咯，强调的是对销量相关度量的不同维度/角度的分析，强调的是-多维分析，因此，要用多维模型，放在关系数据库实现，就是星型模式/雪花模式了
> 但是，产品的信息肯定不只有销售啊，还包括购进啊、库存啊、计划啊等等，难道这些也都应每个对应部门建立数据集市/多维模型么？这个时候，不同部门的数据集市也-还是分散的嘛，怎么体现集成呢？这时候还不是数据仓库吧，那如果要升级到数据仓库，怎么组织刚才说的这些数据？

> 数据仓库应该是数据面向主题的抽取、转换、清洗、加载和管理，关键是数据要全面、一致，面向企业范围的，如果用维度模型，我看不出来哪里体现了全面和一致。
>
> 2、主题如何确定？
> 蛮多的书上，讲到主题，都是说"分析的对象"，那就是从客户的分析需求出发咯

> 我觉得大部分书上说的主题这个概念更多的是前端展现的概念，如果从业务和客户的需求出发整理出来的主题，就是前端的主题，或者叫展现模型，这时候，用维度模型自-然没有问题的，完全满足多维分析
>
> 而按照本意，主题应该是一个在较高层次上对数据的抽象，注意，是对数据的抽象，不关应用和客户分析需求的啥事，面向主题的数据组织(即数据仓库)应该独立于数据-的处理逻辑的，不管是事务处理逻辑还是分析处理逻辑

[kai ZHANG 张恺]

兄弟你多想了

2009/9/9 王艺团 <theseu...@gmail.com>

[gary hu]

我来说一下我的理解:

1、星型模式/多维模型怎么体现数据仓库的集成？
不要小看星型模式/多维模型哦, 这个概念和数据仓库集成应该不矛盾. 因为dimension可以建立在全局的层次上, 比如calendar表,
肯定是通用的, 比如商品类别表, 这些都是全局性的, 可以和最detail的fact表关联建立一个星形结构, 也可以和一张summary
table建立星形结构.

在我看来, 星形结构主要为方便分析考虑 (部分也为BI实施方便考虑), 和是否全局/部分无关.

2、主题如何确定？
这个可能和你的具体的业务有关系. 比如对于taobao.com来说, 我估计"用户"就是一个主题, "商品"是一个主题, "交易"是一个主
题, "Buyer"也许是一个主题, "Seller"也是一个主题, Revenue是个主题....等等.

主题的确定和公司的业务关系非常密切, 还没有想到统一处理的方法.

[王艺团]

谢谢gary的回复

 

dimension建立在全局的层次，这点是没问题，还有些疑问

 

我举个例子哈

 

销量这个事实，要求有两个dim，客户和产品

购进和库存，也要求有两个dim，产品和供应商(同样的产品可能由不同的供应商供应，购入价格也不一样)

 

两种情况：

1、满足客户已知部分需求：销售部门希望分析不同产品的在哪些客户群体里面卖的最好？公司领导希望有关于存销比(库存周转)方面的决策建议和供应商的评价？

2、包容未来的一些需求：做数据仓库，根本的一点就是抓住数据，希望搞出来的数据组织可以支持众多的OLAP需求，比如未来要分析供应商与客户群体的相关性之类的

 

诸如这些，打算如何构建数据仓库？如何建模？

 

事实上，我比较迷惑的一点是，数据仓库不一定要为分析服务，对吧？而你说法“在我看来, 星形结构主要为方便分析考虑 (部分也为BI实施方便考虑)”

 

我比较坚持以下说法：

1、面向主题的数据组织(即数据仓库)应该独立于数据的处理逻辑的(这也是数据库出现的初衷)，不管是事务处理逻辑还是分析处理逻辑

2、OLTP/操作型数据库就是因为本来描述同一客观实体的数据由于与不同的应用逻辑捆绑在一起而变得不统一，使原本是一个完整的客观实体的数据分散在不同的数据库模式/应用系统中

3、多维模型/星型结构，把数据和分析逻辑绑定在一起了，它会提高某个部门的分析效率，但却让其他部门的分析陷入麻烦(To Gary:dimension的全局是必然的，但无法避免这点，fact是全局的么？)

4、数据仓库应该不仅适合于分析型的数据环境，还应该适合于建设企业全局数据库

 

 

to raullew & kai ZHANG 张恺

    谢谢关注，可能是有点“思而不学则罔”了，可是，如果几位大大能直接指出我哪里想岔了，那就更好了。

 

 

2009-09-09

---

王艺团

---

发件人： gary hu

发送时间： 2009-09-09  18:37:35

收件人： ttnn BI 观点

抄送：

主题： Re: 数据仓库和多维模型的疑惑

[kai ZHANG 张恺]

你说的都跟教科书写的差不多。看不出你的POINT在哪里。

2009/9/9 王艺团 <theseu...@gmail.com>

[王艺团]

跟教科书差不多~~~那看来要多说说实践碰到的问题

 

我主要想弄清楚，构建数据仓库和构建数据集市差别在哪里？

我总觉得我现在做的都是数据集市，非常担心“数据仓库”里面的数据没有包含整个企业的数据模型(比如，某个实体的分析角度不全、度量也不全，这些可不可以理解为模型没有设计好？)，那样子的话，如果以后才发现，那样子的话，如果涉及修改(多维)模型或者修改ETL规则等等，不是惨了？担心以后又要被客户的分析需求追着跑~~~因为去年做过的一个项目，用的是总公司提出的一个数据中心的构建方法，死的很惨。

 

 

诸位大大在“新型Olap的设想”http://groups.google.com/group/ttnn/browse_thread/thread/03c104119dbb2416#

里面提到的“破除分析主题”“虚拟主题”“全企业统一视图的指标、维度，和将这些标准化指标进行合理归类的指标体系，是基础，提供可理解、可信赖的业务元数据。”应该才是数据仓库吧

 

2009-09-09

---

王艺团

---

发件人： kai ZHANG 张恺

发送时间： 2009-09-09  19:54:35

收件人： ttnn

抄送：

主题： Re: Re: 数据仓库和多维模型的疑惑

你说的都跟教科书写的差不多。看不出你的POINT在哪里。

[kai ZHANG 张恺]

不管你是DATAMART 还是 DW 。 你公司主数据(ex.客户 产品 供应商 公司层次。。。。。等等 )总是有一致性的。
各个部门数据可能对某些数据归类不一样 比如产品A在采购叫 A1 在销售叫 A2 在LOGISTIC叫 A3 。 这样需要实施的人定义好在仓库里他该叫什么,然后把各个DATAMART的数据源在LOAD进来的时候做好 数据处理 都叫A .

AND 多维模型的构建其实是很细节的了, 只是用于用户在分析时候的数据模型。你可以在不同数据集市根据不同参数构建不同的模型进行分析。

总之设计之前需要把握好 抽取 处理 及报表 性能 这几个方面

2009/9/9 王艺团 <theseu...@gmail.com>

[王艺团]

谢谢 kai ZHANG 张恺

 

你提到的无论是数据集市还是数据仓库，主数据/元数据(这两个还是有区别哈)必须是一致的，这点毫无疑问，是数据集市和数据仓库的共同点

 

从你的说法看出，你也是认同多维模型是在构建数据集市，由用户的需求分析来驱动了

 

也认可你说的设计要把握好 抽取 处理等

 

 

可是问题有两个：

1、我关注的数据集市和数据仓库的区别？

2、从原始数据到最终展现，路径应该是这样的

                                       集成、一致性ETL         (企业范围)            部门抽取                                      

    操作型数据(孤岛、部门隔离)------------------>？？数据仓库？？------------------>

     

 

                                  前端展现工具

    数据集市/多维模型--------------------->即席查询/OLAP分析

 

    

我所关注的数据仓库的建模？如何不再分散~~

 

2009-09-09

---

王艺团

---

发件人： kai ZHANG 张恺

发送时间： 2009-09-09  20:44:55

收件人： ttnn

抄送：

主题： Re: Re: Re: 数据仓库和多维模型的疑惑

[raullew]

按我的观点
ODS+报表，这样总体上两层的数据仓库，是最好的
数据仓库，如果想让它发挥价值，应该直接面对需求，只提炼个别模块作为预计算整合公用
这样对于公司业务的支持最好，每个模块都可以实现最大程度的按需灵活扩展
公司有任何业务变更，对数据仓库架构的稳定性影响最小
技术上也将模块间的偶合性降至最低，减少因技术原因使某模块成为瓶颈的可能

On Sep 9, 4:22 am, "王艺团" <theseus.w...@gmail.com> wrote:
> 谢谢gary的回复
>
> dimension建立在全局的层次，这点是没问题，还有些疑问
>
> 我举个例子哈
>
> 销量这个事实，要求有两个dim，客户和产品
> 购进和库存，也要求有两个dim，产品和供应商(同样的产品可能由不同的供应商供应，购入价格也不一样)
>
> 两种情况：
> 1、满足客户已知部分需求：销售部门希望分析不同产品的在哪些客户群体里面卖的最好？公司领导希望有关于存销比(库存周转)方面的决策建议和供应商的评价？

> 2、包容未来的一些需求：做数据仓库，根本的一点就是抓住数据，希望搞出来的数据组织可以支持众多的OLAP需求，比如未来要分析供应商与客户群体的相关性之类-的

>
> 诸如这些，打算如何构建数据仓库？如何建模？
>
> 事实上，我比较迷惑的一点是，数据仓库不一定要为分析服务，对吧？而你说法"在我看来, 星形结构主要为方便分析考虑 (部分也为BI实施方便考虑)"
>
> 我比较坚持以下说法：
> 1、面向主题的数据组织(即数据仓库)应该独立于数据的处理逻辑的(这也是数据库出现的初衷)，不管是事务处理逻辑还是分析处理逻辑

> 2、OLTP/操作型数据库就是因为本来描述同一客观实体的数据由于与不同的应用逻辑捆绑在一起而变得不统一，使原本是一个完整的客观实体的数据分散在不同的数-据库模式/应用系统中

> 3、多维模型/星型结构，把数据和分析逻辑绑定在一起了，它会提高某个部门的分析效率，但却让其他部门的分析陷入麻烦(To Gary:dimension的全局是必然的，但无法避免这点，fact是全局的么？)
> 4、数据仓库应该不仅适合于分析型的数据环境，还应该适合于建设企业全局数据库
>
> to raullew & kai ZHANG 张恺
> 谢谢关注，可能是有点"思而不学则罔"了，可是，如果几位大大能直接指出我哪里想岔了，那就更好了。
>
> 2009-09-09
>

> 王艺团

[Q]

“担心以后又要被客户的分析需求追着跑”，这个担心恐怕是会发生的。要不你提前预计到客户的分析需求，提前应对。要不你就皮厚一点，当客户分析需求追过来的时候，你别跑。

想搞出一个大而全的数据仓库，这种想法我想几乎是每个dw建模者，特别是一开始搞的人通常的想法，我认为没有必要。对于那些能够全局理解业务的设计师来说，他们可以有信心去做这种大而全的东西，因为他们心里有底。否则，还是先根据客户的分析需求来，甚至在开始的时候，很多分析需求都没有浮出水面，谁都没底。比如，分析客户要从哪些方面入手？一开始这类分析需求肯定都是简单的，而一旦你的数据能够快速满足这些需求，才会有更加复杂的需求产生，如果你的数据仓库无法满足，再想办法去修正吧，在一开始，你的dw模型迭代个三四次是起码的。

至于是搞数据仓库和数据集市，区别这也没多大意义，dw架构类型很多，让这两个概念的区分就很模糊，比如集中式的、联邦式的等等，很多项目将数据集市叫数据仓库，不必要理解数据仓库是揽括企业所有的数据，因为不是还有个词叫EDW嘛，企业数据仓库。也许他们只是在规模，在针对性上有些小小差异而已。

在“新型olap的设想”中，没怎么谈到数据仓库，更多是谈到基于dw中统一的数据，如何屏蔽掉常见的多个cube，合成一个大的虚拟cube，以提供一种更好的分析体验。要做到这一步，需要都维度和指标进行规范的管理，至于这种管理是在哪儿，在dw还是dm，无所谓。

2009/9/9 王艺团 <theseu...@gmail.com>

[王艺团]

哈，谢谢raullew的精彩回复，四个字--实用至上

 

很有借鉴意义

 

认可以下观点：

1、数据仓库，如果想让它发挥价值，应该直接面对需求，只提炼个别模块作为预计算整合公用

2、这样对于公司业务的支持最好，每个模块都可以实现最大程度的按需灵活扩展

3、技术上也将模块间的偶合性降至最低，减少因技术原因使某模块成为瓶颈的可能

 

但对“公司有任何业务变更，对数据仓库架构的稳定性影响最小”存在疑问

1、同一分析主题，在不同的粒度上时，如果度量不一样？如何建模？比如，同样是销售分析，月粒度聚合的分析和年粒度聚合的分析肯定有些不一样的度量指标，这些度量指标怎么放到fact或者cube里面

2、如果某个模块的度量增加了或者维度变动，整个模块/模型/主题的数据是不是要重新ETL/加工？

3、主题之间的交叉/关联是必然的，如何建模？如何才能保证同一个度量数据，不会因为不同主题的聚合重新演变成“蜘蛛网”？

 

2009-09-10

---

王艺团

---

发件人： raullew

发送时间： 2009-09-10  00:50:28

收件人： ttnn BI 观点

抄送：

主题： Re: 数据仓库和多维模型的疑惑

[myttnn]

打杂很久，DW/DM也好久没实践实施经历了，也不知道说的对不对，蒙两句

当前的所做的工作中正如Q所说，因为是给甲方做事情，他们的东西我们说熟不熟，说不熟又了解一些。所以常常出现他们不知道自己要什么，而我们起初除了头脑风暴出几个脑图之外，也无法确定能给他们什么，一切都是在摸索，常常的改。很多时候，客户的需求跟9月的天气一样，你有新的结果，他们就能依着这个想到新的需求。变来变去，搞得兄弟们最近有点更年症状。不了解艺团兄是在给谁做，对其系统了解到什么程度。个人认为这是一个重要的问题。做DW实施，对于系统的熟悉程度往往能起到关键性作用。比如说，如果你对这套系统很熟悉，包括其业务，资金，采购等这些流程。那么可以考虑像你说的做一套全局的近乎我们这些也不知道是BIer还是DWer还是DMer的兄弟们都曾经希望自己能做成功的DW出来。对于你的那个问题，稍举一例，对不对，或者到底是不是DW，兄弟们也别骂，对这个当前不能给自己带来经济效益的东西很郁闷。

艺团兄如果对当前的业务系统所有流程都很熟悉的话，可以看看这个小例子：

粒度不考虑，具体细节也不管，单纯考虑你说的全局，这样来看DW是不是可以解决你的疑惑呢？

之后你要建的部门级数据集市从上面的库中抽取出相应的部门关注信息：

比如销量：

DM/data market(not data minning):

Table_Fact_Sail

Table_Dim_Customer

Table_Dim_Time

Table_Dim_Product

Table_Dim_Supplier

Table_Dim_Region

 

如果说你对这个系统的各个流程没那么清楚，需要客户提需求，给数据来处理，那么正如前面几位兄弟说的，没必要像你这样想了，客户要什么给什么，也只能临时变了，除非你们公司找个对全局业务都很熟悉的设计师来，可能能实现你所想的那么全面的东西。

"中国制造",讲述中国60年往事

[王艺团]

谢谢 Q

 

看来在dw的构建过程，迭代螺旋前进是不可避免的，关于这一点和需求逐渐浮现的观点，还是有心理准备的

 

主要还在于去年做的项目过程中，模型的修正和数据的重新ETL的成本太大，被搞的很没脾气，寻根追底，根本原因可能还在我们建模的时候，维度和事实抽象的不够，导致模型提供了一堆客户不要的，客户想要的一些东西又无法满足。对于这点，除了要多多研究业务外，是否还有其他要注意的？

 

另外，在当时建模的过程中，有些可能是技术方面引起的原因，比如我之前提到的，对于同一个分析主题，如果在同一个维度的不同粒度上用不同的度量指标，如何构建fact？

 

 

2009-09-10

---

王艺团

---

发件人： Q

发送时间： 2009-09-10  09:38:08

收件人： ttnn

抄送：

主题： Re: Re: Re: 数据仓库和多维模型的疑惑

[Q]

构建多个fact有什么问题不

2009/9/10 王艺团 <theseu...@gmail.com>

..

 

另外，在当时建模的过程中，有些可能是技术方面引起的原因，比如我之前提到的，对于同一个分析主题，如果在同一个维度的不同粒度上用不同的度量指标，如何构建fact？

 

 ..

[王艺团]

谢谢 myttnn 兄：

 

首先介绍一下我的项目背景吧，我们公司是做烟草行业的，本身也算是烟草的第三产业，原来是烟草全资的，后来北京的一家公司注资，提供集成方案，我本人投身这个行业2.5年，业务上的话，还算熟悉。

 

其次，介绍下去年的项目，采用的是北京公司的一套数据中心解决方案，基本原理就是星型模式，每个主题/模型由一组维表和一组事实表(包括一个核心、最细节的事实表和一堆降维/上卷的聚合表)，当然，不同的主题/模型就是通过共同的维表来关联在一起，整体来说，就是一个事实星座/星系模式。

 

myttnn兄的例子基本和我去年的项目是一致的

 

可能没讲到的以及我去年碰到的问题如下：

1、因为当时做的项目的目的是：在替代原有报表系统的基础上，提供即席查询和OLAP分析；因此，我们的工作方法是分两组人，一组分析整理需求，一组分析整理各应用系统/源数据，各自整理出来，然后匹对参考，整理出来指标体系(维度/粒度和度量)，再根据指标体系以及分析需求划分主题，建立数据模型和展现模型

 

2、这时候发现，一些度量不好处理，表现以下方面：

    A、同一个主题里面，度量A在高层综合有意义，但在轻微综合没有意义，而公司的产品要求，同一个主题的所有度量必须在最细事实表(我们称之为核心表)存在，因为主题的模型配置这边，聚合导航如果找不到聚合表的话，应该要允许到核心表即席汇总聚合，就想Oracle的查询重写，如果找不到物化视图，那就查询源表了。问题就在这里，既然是即席查询，我们无法控制客户会怎样去查询分析，会怎样的交叉查询，如果客户配置的某个查询没有对应的聚合表，该度量在细节粒度上又没有意义，查询出来的结果也就没意义。

      当然，上面这个问题，我们有个解决方法，就是设置度量和粒度的互斥，这个本来是好的，问题在于，我们的主题划分似乎很失败，主题范围太大了，度量和力度太多，导致互斥的地方也很多，维护到后来，就有点崩溃了

      到最后呢，想了一下，如果我们把主题再细分一下，太复杂的查询和分析就是通过跨主题查询分析来实现，可惜当时产品提供的跨主题查询不好，没有太多实践。

     

      以上这种情况，兄弟们给点改进意见？主题要如何划分比较合适，才不会产生这些问题？

 

   B、对于‘整体’的度量（就是那种无法从下一级累计上来的，只能从整体的细节汇总），比如产品数，假设由细节汇总到某区县的销售产品数，接下来要汇总地市，肯定不能将区县的数据累加。这种度量，各位要怎么处理呢？

       看过《数据挖掘：概念和技术》这本书，里面把度量分为三类：分布的(比如销量、销售额)、函数的(比如均价，有销售和销售额代数计算得出)、整体的(就是上面提到的产品数那种，就是SQL里面的count(distinct)，count计算本身是分布的)

 

3、myttnn兄举的星系模式的例子，理解起来完全没有问题。我的问题一个是上面提到的度量/事实的问题，一个是：有哪些措施能促进我数据集成的全面性呢？有哪些细节需要注意，是否有一些方法可以指导使用呢？我知道具体的措施肯定和具体的业务有关系，但是各位大大搞过这么多项目了，肯定有些比较可操作的经验可借鉴，请不吝赐教。

 

ps：叨扰各位了哈，见谅~~~目前大部门的介绍数据仓库的书籍和文档，在介绍到数据仓库的构建时，尤其是建模时，都是很笼统，或者只是战略层次上的，对于我这种新手来说，还是比较希望有份可操作性比较强的经验可以指导哈，当然了，我会自己多多实践的

 

在这两天的讨论过程中，收获颇多，希望我的项目可以顺利完成，到时再贡献我的项目经验。

 

 

2009-09-10

---

王艺团

 

=====================================华丽的分割线===================================

---

发件人： myttnn

发送时间： 2009-09-10  10:41:31

收件人： ttnn

抄送：

主题： Re: 数据仓库和多维模型的疑惑

打杂很久，DW/DM也好久没实践实施经历了，也不知道说的对不对，蒙两句

当前的所做的工作中正如Q所说，因为是给甲方做事情，他们的东西我们说熟不熟，说不熟又了解一些。所以常常出现他们不知道自己要什么，而我们起初除了头脑风暴出几个脑图之外，也无法确定能给他们什么，一切都是在摸索，常常的改。很多时候，客户的需求跟9月的天气一样，你有新的结果，他们就能依着这个想到新的需求。变来变去，搞得兄弟们最近有点更年症状。不了解艺团兄是在给谁做，对其系统了解到什么程度。个人认为这是一个重要的问题。做DW实施，对于系统的熟悉程度往往能起到关键性作用。比如说，如果你对这套系统很熟悉，包括其业务，资金，采购等这些流程。那么可以考虑像你说的做一套全局的近乎我们这些也不知道是BIer还是DWer还是DMer的兄弟们都曾经希望自己能做成功的DW出来。对于你的那个问题，稍举一例，对不对，或者到底是不是DW，兄弟们也别骂，对这个当前不能给自己带来经济效益的东西很郁闷。

艺团兄如果对当前的业务系统所有流程都很熟悉的话，可以看看这个小例子：

粒度不考虑，具体细节也不管，单纯考虑你说的全局，这样来看DW是不是可以解决你的疑惑呢？

之后你要建的部门级数据集市从上面的库中抽取出相应的部门关注信息：

比如销量：

DM/data market(not data minning):

Table_Fact_Sail

Table_Dim_Customer

Table_Dim_Time

Table_Dim_Product

Table_Dim_Supplier

Table_Dim_Region

 

如果说你对这个系统的各个流程没那么清楚，需要客户提需求，给数据来处理，那么正如前面几位兄弟说的，没必要像你这样想了，客户要什么给什么，也只能临时变了，除非你们公司找个对全局业务都很熟悉的设计师来，可能能实现你所想的那么全面的东西。

 

在2009-09-10 09:37:46，Q <happ...@gmail.com> 写道：

“担心以后又要被客户的分析需求追着跑”，这个担心恐怕是会发生的。要不你提前预计到客户的分析需求，提前应对。要不你就皮厚一点，当客户分析需求追过来的时候，你别跑。

想搞出一个大而全的数据仓库，这种想法我想几乎是每个dw建模者，特别是一开始搞的人通常的想法，我认为没有必要。对于那些能够全局理解业务的设计师来说，他们可以有信心去做这种大而全的东西，因为他们心里有底。否则，还是先根据客户的分析需求来，甚至在开始的时候，很多分析需求都没有浮出水面，谁都没底。比如，分析客户要从哪些方面入手？一开始这类分析需求肯定都是简单的，而一旦你的数据能够快速满足这些需求，才会有更加复杂的需求产生，如果你的数据仓库无法满足，再想办法去修正吧，在一开始，你的dw模型迭代个三四次是起码的。

至于是搞数据仓库和数据集市，区别这也没多大意义，dw架构类型很多，让这两个概念的区分就很模糊，比如集中式的、联邦式的等等，很多项目将数据集市叫数据仓库，不必要理解数据仓库是揽括企业所有的数据，因为不是还有个词叫EDW嘛，企业数据仓库。也许他们只是在规模，在针对性上有些小小差异而已。

在“新型olap的设想”中，没怎么谈到数据仓库，更多是谈到基于dw中统一的数据，如何屏蔽掉常见的多个cube，合成一个大的虚拟cube，以提供一种更好的分析体验。要做到这一步，需要都维度和指标进行规范的管理，至于这种管理是在哪儿，在dw还是dm，无所谓。

2009/9/9 王艺团 <theseu...@gmail.com>

跟教科书差不多~~~那看来要多说说实践碰到的问题

"中国制造",讲述中国60年往事

[interstage]

个人经验如下：
1，在项目实施开始阶段，先放弃什么是数据仓库和数据集市以及多维模型定义，除非这个项目你还没中标，需要这些归纳性理论和DEMO来忽悠客户，或者项
目结束后需要提交一份技术总结。或者这个项目不是一个业务分析性项目，只是一个控制数据质量的项目。
2，对于主题的确认，千万别临时去套什么总结性技术书描述的，那些书是和你在平时反思和总结用的，是增强你的内功，如果用它套一个项目，会被具体这个项
目最终使用的业务部门骂死。主题确认最简单的方式，让业务口拿出他们平时用的报表，从很多报表中整体出一些通用性报表，这些通用性的表侧和表头很多就是
你需要确认的主题。同理，从数据仓库中抽象主题，是项目结束后或者项目未中标前的事情。

以上2点，绝对是我10年的经验，免费赠送给你。 数据仓库项目对技术人员其实最烦的还不是以上这个问题，恰恰是数据质量的问题。

[Q]

对于这2.A问题谈谈想法。

主题划分的问题，度量和粒度太多。如此看来，你们必定是有元数据去记录有哪些度量和维度，以及他们粒度了，我想要做的是对这些元数据进行梳理，比如用户即席查询的日志，就包含丰富的分析需求信息。虽然多，但二八原理在此肯定是适用的，在这乱七八糟的信息里面找出最常用的维度跟度量的结合，然后为这些构建事实表，甚至是单独出来一个主题。尽量别做跨主题的查询。

2009/9/10 王艺团 <theseu...@gmail.com>

谢谢 myttnn 兄：

 。。

2、这时候发现，一些度量不好处理，表现以下方面：

    A、同一个主题里面，度量A在高层综合有意义，但在轻微综合没有意义，而公司的产品要求，同一个主题的所有度量必须在最细事实表(我们称之为核心表)存在，因为主题的模型配置这边，聚合导航如果找不到聚合表的话，应该要允许到核心表即席汇总聚合，就想Oracle的查询重写，如果找不到物化视图，那就查询源表了。问题就在这里，既然是即席查询，我们无法控制客户会怎样去查询分析，会怎样的交叉查询，如果客户配置的某个查询没有对应的聚合表，该度量在细节粒度上又没有意义，查询出来的结果也就没意义。

      当然，上面这个问题，我们有个解决方法，就是设置度量和粒度的互斥，这个本来是好的，问题在于，我们的主题划分似乎很失败，主题范围太大了，度量和力度太多，导致互斥的地方也很多，维护到后来，就有点崩溃了

      到最后呢，想了一下，如果我们把主题再细分一下，太复杂的查询和分析就是通过跨主题查询分析来实现，可惜当时产品提供的跨主题查询不好，没有太多实践。

     

      以上这种情况，兄弟们给点改进意见？主题要如何划分比较合适，才不会产生这些问题？

 ...

[王艺团]

Q的意思是在运行一段时间后，通过对客户使用分析的审计日志进行分析，进一步优化主题？

 

再问个问题：就是为这些重新构建事实表，如果在物理存储上出现了事实数据的重叠，即同样的事实数据在不同的主题重复存储，会不会走到“蜘蛛网”的路子？

 

 

2009-09-10

---

王艺团

---

发件人： Q

发送时间： 2009-09-10  12:19:12

收件人： ttnn

抄送：

主题： Re: Re: 数据仓库和多维模型的疑惑

[王艺团]

赞一个，谢谢interstage的实用经验，反复咀嚼中~~~

 

1、interstage兄建议的最佳实践方法，还是从分析需求出发，赶紧建数据集市，满足最终用户的分析需求~~~~~嗯，现在就是这么做来的

2、嗯，数据质量确实是最重要的，强烈同意

3、小小的疑问和感概：传说中的数据仓库，与事务处理逻辑和分析处理逻辑无关的数据仓库，真的没法搞？

 

 

2009-09-10

---

王艺团

---

发件人： interstage

发送时间： 2009-09-10  12:10:40

收件人： ttnn BI 观点

抄送：

主题： Re: 数据仓库和多维模型的疑惑

[xichen...@gmail.com]

应该有法搞，不过搞不搞不是技术人员单独能决定的，是公司上上下下，方方面面的因素决定的。

在09-9-10，王艺团 <theseu...@gmail.com> 写道：

[xichen...@gmail.com]

我也参加过一个烟草项目一小段时间，最大的感受就是那个字段和表名是汉语拼音首字母缩写，我那个吐血啊。比如烟叶资源=YYZY。

在09-9-10，xichen...@gmail.com <xichen...@gmail.com> 写道：

[王艺团]

哈哈，那你可能比较早啦，现在还好，至少我目前碰到的系统都基本已经升级过了，除了那种特别历史悠远的，不是很重要的业务系统。

 

 

2009-09-10

---

王艺团

---

发件人： xichengmylove

发送时间： 2009-09-10  14:22:29

收件人： ttnn

抄送：

主题： Re: Re: 数据仓库和多维模型的疑惑

[raullew]

与事务处理逻辑和分析处理逻辑无关的数据仓库 用处体现在哪里？

On Sep 9, 9:40 pm, "王艺团" <theseus.w...@gmail.com> wrote:
> 赞一个，谢谢interstage的实用经验，反复咀嚼中~~~
>
> 1、interstage兄建议的最佳实践方法，还是从分析需求出发，赶紧建数据集市，满足最终用户的分析需求~~~~~嗯，现在就是这么做来的
> 2、嗯，数据质量确实是最重要的，强烈同意
> 3、小小的疑问和感概：传说中的数据仓库，与事务处理逻辑和分析处理逻辑无关的数据仓库，真的没法搞？
>
> 2009-09-10
>

> 王艺团

[jackeroo]

按照我的理解，操作型数据环境就是因为数据与事务处理逻辑捆绑，即OLTP应用，以至数据就分散在不同应用里面，且数据模型设计是为事务服务；同样了，
如果数据与分析处理逻辑捆绑在一起，那么数据不是也被不同的分析应用所分离？如果数据为了某个分析而设计，肯定也是为了满足该分析的一些要求而做特定的
设计，那么，这样子是不是会以损失其他的分析为代价，如果其他分析也涉及到这些数据的话？

[interstage]

呵呵，"传说中的数据仓库'，这个"传说"2字很有意思，"传说"的东东永远是最美丽的，这世界上什么东西最美丽，是想象中的和刚刚开始创造的东西最美
丽，真实的东西永远有需要改进的地方。数据仓库也是如此。与事务处理逻辑和分析处理逻辑无关的数据仓库，是那个美丽的"传说中的数据仓库"吗？如果是，
我个人认为这不是一个技术层面考虑的问题，涉及的东东太多太复杂呀，我更认为是文化上层面的问题。不过在TTNN上，有个"传说"的牛人，他致力于用技
术的手段来搞出与事务处理逻辑和分析处理逻辑无关的数据仓库，就是你所说的那个"传说中的数据仓库"，他采用"传说中的混合式数据仓库架构"。利用
ODS-EDW-CDW-DM的4大组件来实现的，楼主可以向他请教，应该有所收获。

On 9月10日, 下午12时40分, "王艺团" <theseus.w...@gmail.com> wrote:
> 赞一个，谢谢interstage的实用经验，反复咀嚼中~~~
>
> 1、interstage兄建议的最佳实践方法，还是从分析需求出发，赶紧建数据集市，满足最终用户的分析需求~~~~~嗯，现在就是这么做来的
> 2、嗯，数据质量确实是最重要的，强烈同意
> 3、小小的疑问和感概：传说中的数据仓库，与事务处理逻辑和分析处理逻辑无关的数据仓库，真的没法搞？
>
> 2009-09-10
>

> 王艺团

[王艺团]

interstage兄，你用了一堆的"传说"，弄的我有点郁闷哈，呵呵，不知道是不是在调侃我哈

不过你说的那个"传说"的牛人是谁啊？我刚来ttnn两天呢

ps：
今天下午请了Oracle专家来介绍Oracle数据仓库解决方案，在讨论过程中，Oracle专家坚称他以前做过的项目，确实有EDW成功的例子，再
三确定，的确如此。可惜，一个下午时间而已，说下次还会来具体深入讨论，比较期待。

另外，现在在看interstage兄的bifactor.pdf，受益颇多，再次遥致敬意。

[xichen...@gmail.com]

如果传说中的那个牛人出来了，这个帖子的长度会增加一倍的！！！

在09-9-10，王艺团 <theseu...@gmail.com> 写道：

[Chris]

为何地市不能从下一级累加得到销量？
>

对于'整体'的度量（就是那种无法从下一级累计上来的，只能从整体的细节汇总），比如产品数，假设由细节汇总到某区县的销售产品数，接下来要汇总地市，

肯定-不能将区县的数据累加。

> > > 以上2点，绝对是我10年的经验，免费赠送给你。 数据仓库项目对技术人员其实最烦的还不是以上这个问题，恰恰是数据质量的问题。- Hide quoted text -
>
> - Show quoted text -

[daiyan]

关于维度建模，我也琢磨了一套方案，吸收了众多同事和已有项目的众多经验，还有理论界的和行业模型的诸多观点，也包括从ttnn得到的启发——思索方案那段时间，在这里发帖了，其中一句话，出现在了下面。这几天看着这个帖子的讨论得热火朝天，我只能抑制住心中的激动，因为，现在正在天天加班实施那套维度建模方案，可紧张了！

待过一阵有个相对安静的时间，再回头来总结一下，其中的核心思想——对于一个需要在特定背景下在特定时期特定环境中实施的方案，需要考虑的极其重要因素是产出品的服务级别协议，也即我们产品的KPI指标——譬如“时效”和“准确性”这些我们所要达到的朴素而关键的目标。

第一是明确建模的目标。维度建模更多地归向了应用层次，和需求的分析主题挂钩，所以维度建模容易形成一种直通式模型——即围绕具体的分析主题（或者报表，指多维分析报表，在此处等价于分析主题概念）建立模型，相同的事实会被重复、多次获取，存放到数量众多的事实表中等。

直通式模型在现应用中应该是广泛存在的。这个模型的好处是各个报表数据准备流程的耦合度低，某个程序出问题的时候不至于影响一大片。但我觉得问题更是显而易见，而且这中模型的缺陷是本质上的缺陷，是必须从数据建模方案的高度来克服的。

关于维度建模的目标，我下了一个定义，原文为了严谨，比较冗长，这里不太方便发布（有点给隔靴瘙痒了，多原谅），核心思想就在于 把握数据的业务本质和业务分析的过程，对这个过程建立集成、一直的模型，保证事实一致性和维度一致性（我的观点是，维度一致性可不是都引用同一个维表就可以美其名曰了，真正的核心在于维度键值计算的一致性——这个可以算是方案中的一个大挑战了），并对ETL架构和方案友好，达成关于时效和准确性方面的服务级别协议约定，提供对业务规模和种类的扩展性支持（扩展性也不能过于苦苦追求）。

对建模过程的设计和定义也非常关键，尤其是项目规模较大，范围广，建模人员较多的时候。我们也参照、舍弃、扩展了许多业界方案的做法，自己设计了一套建模的标准和产出物模板，引入可视化数据建模（其中含有数据模型和ETL数据流的关系），在宏观和微观上同时下功夫，在建模的同时完成和模型完全共生的ETL设计，实现了建模、编码、单元测试、回归的同步推进。

建模和开发工作还在艰苦跋涉中，遇到的挑战可比这里所描述的艰难得多，也远远超越我早先的预想。

现在还没有到完整的总结的时候，先就讨论这么多吧。欢迎指教，多谢！

---------------------------------------------------------------
---代 严  恭祝万事如意！
---DAI YAN    BEST WISHES！

2009/9/9 王艺团 <theseu...@gmail.com>

[王艺团]

呵呵，销量是分布的度量，当然可以累加，我说的是产品数，你没看清楚咯

 

2009-09-13

---

王艺团

---

发件人： Chris

发送时间： 2009-09-11  20:52:38

收件人： ttnn BI 观点

抄送：

主题： Re: 数据仓库和多维模型的疑惑

[Ryan]

哈哈 越来越有意思啦`
不过还是回到问题上来·~可别扯远了

On 9月11日, 上午9时36分, xichengmyl...@gmail.com wrote:
> 如果传说中的那个牛人出来了，这个帖子的长度会增加一倍的！！！
>
> 在09-9-10，王艺团 <theseus.w...@gmail.com> 写道：

> > > ODS-EDW-CDW-DM的4大组件来实现的，楼主可以向他请教，应该有所收获。- 隐藏被引用文字 -
>
> - 显示引用的文字 -

[王艺团]

谢谢daiyan的精彩发言。

先发几句牢骚，公司是烟草的第三产业，60年国庆+中秋到了，天天被抓去唱歌，搞“爱国歌曲大家唱”~~~都没法干活了，所以早早看到daiyan童鞋
的精彩发言，到现在才回复哈

以下正式回复和疑问：
1、daiyan童鞋的观点也是走实用的路子，嗯，做应用不是做产品，客户需求才是最最重要需要考虑的，所以从客户的分析需求出发，走维度建模；
2、“分析主题概念”--赞，不是我咬文嚼字啊，我觉得对于维度建模来说，数据仓库面向主题的特性中的主题，说成分析主题更贴切点哈；到目前为止，我所
理解的“传说”中的数据仓库应该是与任何事务逻辑、分析逻辑无关的，所以它的主题应该仅仅是数据本身的概念上的划分(不过，说实话，我也讲不太清楚，因
为我说了哈，“传说”，我不知道是不是存在)；我只是觉得，数据库是信息的集合，它关注信息的存储，而不关注信息是怎么使用，如果信息为满足某种处理而
优化、重组，那么OLTP和OLAP，从本质上来说，是没有啥区别的，都是把数据组织成对各自的处理来说是最优化的，那么，假设将来，又有新的类型的处
理呢？
3、但是，从应用开发和商业软件来说，满足客户需求才是最重要的，就是前辈说的“应该赶紧烧掉书，投入实际的开发”和daiyan兄说的“考虑的极其重
要因素是产出品的服务级别协议....我们所要达到的朴素而关键的目标”，这个时候，维度建模是最佳的选择。
4、daiyan兄说到“ 对建模过程的设计和定义也非常关键”和“自己设计了一套建模的标准和产出物模板”，不知道介意多多介绍一下这个不？非常关
注，很希望有操作性比较强的建模过程的指导。

daiyan wrote:
> 关于维度建模，我也琢磨了一套方案，吸收了众多同事和已有项目的众多经验，还有理论界的和行业模型的诸多观点，也包括从ttnn得到的启发----思索方案那段时间，在这里发帖了，其中一句话，出现在了下面。这几天看着这个帖子的讨论得热火朝天，我只能抑制住心中的激动，因为，现在正在天天加班实施那套维度建模方案，可紧张了！
>
> 待过一阵有个相对安静的时间，再回头来总结一下，其中的核心思想----对于一个需要在特定背景下在特定时期特定环境中实施的方案，需要考虑的极其重要因素是产出品的服务级别协议，也即我们产品的KPI指标----譬如"时效"和"准确性"这些我们所要达到的朴素而关键的目标。
>
> 第一是明确建模的目标。维度建模更多地归向了应用层次，和需求的分析主题挂钩，所以维度建模容易形成一种直通式模型----即围绕具体的分析主题（或者报表，指多维分析报表，在此处等价于分析主题概念）建立模型，相同的事实会被重复、多次获取，存放到数量众多的事实表中等。

>
> 直通式模型在现应用中应该是广泛存在的。这个模型的好处是各个报表数据准备流程的耦合度低，某个程序出问题的时候不至于影响一大片。但我觉得问题更是显而易见，而且这中模型的缺陷是本质上的缺陷，是必须从数据建模方案的高度来克服的。
>
> 关于维度建模的目标，我下了一个定义，原文为了严谨，比较冗长，这里不太方便发布（有点给隔靴瘙痒了，多原谅），核心思想就在于

> 把握数据的业务本质和业务分析的过程，对这个过程建立集成、一直的模型，保证事实一致性和维度一致性（我的观点是，维度一致性可不是都引用同一个维表就可以美其名曰了，真正的核心在于维度键值计算的一致性----这个可以算是方案中的一个大挑战了），并对ETL架构和方案友好，达成关于时效和准确性方面的服务级别协议约定，提供对业务规模和种类的扩展性支持（扩展性也不能过于苦苦追求）。