数据仓库跟数据集市的关系

[Tommy Chang]

现在大家都讨论了不少数据仓库的东东，其中发现有很大一个误区。

在设计数据仓库不是组织以建各种维度为目的为出发点，而是将各个业务系统的数据统一，结构化之后，尽可能容纳进来。建好的数据仓库通常已经包含很多主题的数据集市。
而数据集市则真的是面向主题，按照多个维度来进行数据展现和分析的。

有了数据仓库，在现有数据基础上，再做新的主题时只需要在整个数据仓库挑选相应的维表，然后根据分析的需求，建立相应的实表，数据可以从其它的实表或历史明细表中装载。

:)

表达的可能有问题，欢迎指正

[newskysh]

我觉得目前数据仓库在我们国家还遇到了很多阻力!

1、数据积累不够。目前在我们国家各行业数据积累很少，仅仅在金融和电信稍微积累多点，其他行业都比较少，即使做出来的系统再先进，由于缺少数据，最终导致决策分析上不会取得很好的效果。
2、真正的数据仓库人才很少！目前很多公司出来的数据仓库产品与欧美国家成熟产品相比，还有较大差距！
3、没有一个繁荣的数据仓库市场！（这也是数据仓库作用不大的原因导致）
4、开发工具的问题。不论数据抽取，数据挖掘等等过程使用的工具还不是很成熟，另外就是所有的工具基本都是外国的，和中国的人理念上还是有差距的！

[yongwc]

我倒觉得没有必要把报表系统跟数据仓库系统分开,报表系统是一个结果的展示系统
,而数据仓库系统是一个支持系统,没有数据仓库中集成的数据,有些报表就不好制作. 报表系统也算是数据仓库系统的一个组成部分吧
说到ROI, 跟是否报表系统没有多大关系,主要还是看系统供应商的和用户的应用水平如何? 看上了这个系统是否真的帮用户解决了问题.

[Tommy Chang]

买电脑都开始讲究性价比，客户也要提ROI(return on investment)，只是一个报表系统，为什么要那么多钱来投资呐？

:)

[Tommy Chang]

中国真正这几年积累到数据的其实就只有银行、保险、证券等，电信只留了半年的数据，因为他们的数据量太大了，没那么多钱来买硬件来维护这么大的数据量，特别是在业务系统的模式下。
数据仓库人才有很多层面的，也有数据仓库项目经理、结构设计、模型建立、开发者、行业顾问等很多角色，国内现在还没分的很细，人无全才，所以把所有的脚色加到一个人身上是不可能的，这种全才国外也不多见，恐怕bill跟kimball能算两个吧 :)
数据仓库市场确实不够繁荣，因为很多方面的原因，一个例子，我跟某个客户科技处的人聊的时候，其实业务人员在98年就有一些分析的想法，但被科技处把这种想法给压下去了，过了3年，今年头，才真的开始搞。你能说客户没需求吗？是现在数据仓库基础支持不够普及，搞技术的不懂的将业务部门的问题转化为数据仓库的语言。
成熟？没有什么东西是一成不变的，包含c,c++都还在一直发展扩充。数据仓库发展的年头只比关系型数据库晚不到十年而已，是80年代开始的。
莫非所有的东西都加made in china才能用？china java,china linux,china delphi,china oracle,china 390,china perl,china sql,china xxxx?那样没问题，中国企业的元数据都是自己定义的一套，也甭跟洋鬼子企业交换什么信息了，直接电话联系用啥it技术？什么叫中国人的理念？都是将rdbms中做报表等痛苦的东西提炼出来，才有数据仓库的概念，从基础到概念都是通用，实在不理解何谓“中国人的理念“。很多人认为洋鬼子的理念拿到中国来，有些东西满足不了，这就是不适合中国国情，其实这很正常的，即使洋鬼子的标准在国外一样也有不能直接实现的需求，很正常的，莫非德国人说德国人的理念，非洲人说非洲人的理念，那it没有一个标准能贯彻下来。
数据仓库系统是包含报表系统，这本来就是如此的，但是不仅仅报表系统。仅仅是强调这个"不仅仅"而已。
帮用户解决问题，如果解决问题的价值只是100元请人写段sql脚本，而数据仓库要花几百万呐？他为什么还要数据仓库？一是看解决问题的价值，二是做什么事情更好

:)

如有冒犯，多多指教 ^_^!

[blueskycn]

呵呵，其实很简单
无论怎么说
数据仓库》数据集市

[dataware]

我也说两句，我感到数据仓库其实是一个大集中，把所有的数据（进可能全）地集中在一起。当然在它上面的应用主要是olap分析，但不应仅仅局限于olap分析，而应该成为整个企业范围内数据分析与挖掘的基础。而数据集市却往往针对特定的问题进行olap分析。这就要求我们在数据仓库建模的时候不应采用星型结构，而应该使用标准的实体－关系模型，而在数据集市建模的时候可以采用星型结构。遗憾的是，在国内人们一提到数据仓库就想到星型模型、olap分析，对于整个企业数据的整合与资源的合理利用却只字不提；在这种情况下，我们要作的分析不是olap怎么办？如果数据仓库仅仅是olap分析，我看还不如不上，而自己开发olap应用，又省钱又灵活。要知道一般意义上的bi产品多是为最终用户提供的，可进行二次开发的很少。所以我非常同意tommy的观点，我们国内（可能也包括老外）对数据仓库的认识比较多样化，正象老外也有inmon和kimball之争（可能名字拼的不对，请原谅）。很高兴与大家讨论数据仓库的问题。另外，我认为数据仓库就应建立在关系型数据库之上，而所谓的数据集市可建立在多维数据库之上。

[Tommy Chang]

很失望，还居然没人从深层次应用的角度来看两个的关系。

:(

[Tommy Chang]

http://www.itpub.net/showthread.php?s=&threadid=34660

连接 数据仓库跟数据集市的关系

这是在itpub上讨论的一点东东，哥们看看

:)

[yongwc]

对cxgtommy 的理由4:
数据仓库并不是什么星星、雪花的东东，还是走标准范式那一套，而集市才是星星、雪花xxx。 如果你的数据仓库有大量的星星，恐怕就只是一堆的数据集市

很怀疑,企业级的数据仓库也应该是按主题组织的吧

[Tommy Chang]

企业级的数据仓库是按主题组织没错，但主题并不应该是星星、雪花之流

有矛盾吗？

:)

[yongwc]

我一直对如何建立数据仓库的数据模型还不是很清楚,所以正想请教
我的看法是这样:
数据仓库主要是面向分析的,要求对查询有较快的响应速度,所以,数据仓库中的
数据是可以有大量的冗余的. 而这对于标准范式来说,这似乎是不可接受的.
在工作中,将主题数据按星星,雪花的形式来组织,还是可以满足大部分的查询要求的.不一定要非得把他们规范化到第三范式吧.
数据集市是数据仓库的一个子集,两者的区别是在于其所管理的数据范围,如果是部门一级的我们可以说是数据集市,如果是面向整个企业的,我们就可以说是数据仓库.
在同一个企业里,它们的数据模型甚至可以一摸一样,只是其中管理的数据内容,数据量不一样.
我不认同星星,雪花就是数据集市,标准化范式就是数据仓库的看法

tommy你认为呢?

[Tommy Chang]

首先数据仓库是为查询优化的，你可以在数据仓库里做N多张表的关联、查询等，也是所谓的join from hell，但带来的问题是查询优化复杂。翻过来，数据集市才真的是面对分析，分析的时候不会关心全部信息，通常也就是在主题内。

数据仓库就是范式这个说法其实在国外也有争议，到底数据仓库怎么建，我给的是标准方式之一。至于其它的方式，如果能贯穿整个数据仓库，也不会星星到底的，充其量是一些混合型。

我想说的问题关键是在于设计仓库就把过多分析的东西加进来，会影响仓库的稳定性，因为分析有很大程度是不断在变的，而数据仓库的好处应该是把变化的范围缩小到数据仓库-〉数据集市，而不应该简单认为数据集市组成了数据仓库。

inmon和kimball之争作为我们，需要了解两家的不同之处，要想兼两家所长实在不容易。inmon的书难度大点，读懂的人也少些，国内现在更多的是kimball的读者，然后很多人就把两者混为一谈了。

:)

对于应用来讲，其实能在适当的时候选择适当的模型，这是最关键的，单纯的较真只具学术意义，不一定能解决实际问题。 我究这个问题也是希望抛砖引玉，看看大家平时常出的问题怎样。

[scy_cd]

kimball的电子书籍，你那里有吗？

[KINGKANG]

!

[Tommy Chang]

没有啊

:)

[given]

见到大家热烈，我也来说两句：

如果从现有的概念来理解我觉得数据仓库不能等同于数据集市的集合，只是因为数据仓库除了能演变成数据集市外，他还可以用在oltp上面，因此此应用层次决不是数据集市能做得到的。cisco的goto query就是数据仓库的一个很好的例子。但是从我个人来理解，两者应该统一到一块来，也就是用作OLTP的表也可以做面向主题，也就是数据集市的表。这样对于数据集市或数据仓库来说虽然增加了数据冗余，但这值得，因为这种应用创造的价值更高。也是我们追求的，而这带来一些负面的影响，如资源竞争产生瓶颈之类的应该不会对其受到影响。而且数据仓库做的小了就是你可以认为那是一个报表系统，但是此报表系统创造的价值决不是一个业务系统所能比拟的。所以说，不应该评论数据仓库做成一个报表系统就觉得是一个得不偿失的工作。
以上为个人一些措见，请指教！

[Tommy Chang]

对rose的佩服犹如滔滔江水，连绵不绝，不过听口气像是自问自答，莫非是两个人用一个id？

:)

[w_rose]

我不懂数据仓库。看了这么多天的贴子，很想谈谈我的看法，有不对的地方请指教，我不声感激！

不管黑猫白猫，逮找耗子的冒才能活下来，逮不着耗子的冒就是浪费粮食。所以用户对数据仓库的真实看法根本没有这么技术化。

另一方面，用户对于数据库、软件技术也没有那么技术化！

用户要求的是一种单个数据库、单个软件开发技术所不善长解决的面向信息分析的工具。

这种工具决不是单一一种数据库。在一种数据库中，我们写一个复杂的SQL或者存储过程就能进行数据分析了。但是当用户告诉我们：“我的某个部门的报表在某台机器上使用SmartDraw绘图软件写的一个分析表”时，我们会不会拒绝用户给用户分析这类数据？在传统的数据库应用重视我们强迫用户建立集中的数据库格式，在数据仓库项目中是我们配合用户来使用任意格式的数据库（包括在任意机器上），因此就比单一数据库的项目具有了竞争优势。

从数据的收集上来说，它是过程性的。我们必须根据不同的数据所在的位置、格式开发或者集成各种数据抽取技术。当用户广州分店用Excel写的给香港公司的报表写好后，我们在上海的总公司的数据仓库在必要时可以将这个数据抽取到上海，并且在广州那边的报表一旦更新，总公司的数据也必须更新。

从数据的使用上来看，不管是提供给分析人员一个数据库查询界面，还是一个类似Web浏览器之类的应用界面，反正用户看不到不同数据的格式上的差别，只需要关心数据有没有就行了。用户只要打入一个SQL语句，这个SQL语句可能实际上从几十个不同格式的外部数据库（包括文件）中抽取数据。用户对数据操作是“说明性”的，因此为用户隐藏了数据抽取的复杂性。

有什么好处呢？原始数据的（相对）唯一性就是最大的好处。如果在一个集团公司工作过的人都知道，要想让各分公司把自己的报表按照总公司的格式打印和传送过来，往往需要1个月的时间，早就没有了用于经营控制的价值了！如果采用说明性的手段定义远程数据，数据仓库自己远程读取数据，自动进行格式转换，并且自动监视原始资料的变动，只要满足这三个条件，那么，公司在信息系统上的痛苦可以减轻一大半，很多在信息系统的“无用”技术上的投资就可以靠这个技术挽回一大半。

[w_rose]

假如说，您已经建立了一套这样的数据仓库系统，那么通过新的数据仓库再抽取这个数据仓库的结果，这样“自举”，可以更快地建立新的“综合”数据仓库，所费的时间最少、所得到的有效数据最多、逻辑最简单有效、面向多种“综合”数据仓库时伸缩性最好（也就是可以同时建立几个综合版本试试效果，而付出的研究成本相对很小）。

[w_rose]

我没有谈论数据查询语言上的差别，不是说一种数据仓库不需要这种技术。数据仓库肯定在技术上是对数据库的继承，因此，数据仓库产品完全应该集成数据库的查询和保存（至少是缓冲）数据的功能。但是，不能把数据查询语言上的一点点差别作为本质的东西，除非我们打算让后来者都不知道什么是数据库，而只知道数据仓库。将数据库技术和数据仓库技术在本质上严格分开，可以使得我们在谈论任何一项技术时都用比较简练和明确的思路说清问题。所以，手按搞清楚那些技术是传统数据库技术所擅长的，那些技术是现代数据仓库技术所擅长的非常重要。在谈论数据仓库技术时，就不要围绕数据库技术争论不休（尽管数据仓库产品本身肯定包含数据库产品的功能，但是在技术上一到分开）。