疑问：kimball的数据仓库模式，国内有成功的案例吗？

显示全部楼层 · 2015-3-6 11:57:31

看来看去，国内好像都是3NF的模式，像kimball推荐的直接用统一维度模型来做数据仓库的方式，在国内有实际的应用案例吗？这种模式实际实施到底有什么问题呢？

千问 · 2015-3-6 11:57:31

大多数是混合的

千问 · 2015-3-6 11:57:31

底层DW用3NF，DM用star

千问 · 2015-3-6 11:57:31

greatfoot 发表于 2012-8-19 13:03
底层DW用3NF，DM用star
你说的底层DW是指最细粒度的事实表吗？汇总级的事实表，一般就用比较严格的维度模型了吧。

千问 · 2015-3-6 11:57:31

greatfoot 发表于 2012-8-19 13:03
底层DW用3NF，DM用star
DW和DM之间，其实是数据冗余的，不是无端增加了建设成本吗？
DM存放汇总数据的话，又缺少细节颗粒度的支持，会经常面临需求变更的冲击?

千问 · 2015-3-6 11:57:31

DW采用3NF设计主要是为了保存历史变化数据，保持数据一致性和数据的完整，减少数据冗余，把同一系统内和不同应用系统的数据经过ETL集中到统一数据平台上，在实现时是通过大量的关系表有效区间和代理键的方式把不同的主题和属性关联到一起。在DW实际的设计过程中需要对本行业的业务知识有较深的了解并结合本公司的实际业务处理方式进行分析和设计，减少以业务需求为驱动的设计。DW的模型经过一段时间的建设和完善后是可以稳定下来的。
DM本身就是为满足部门级或者某个特定主题的需求而设计开发的，由于数据都来源于DW可以适当降低数据ETL设计的复杂度，保持维度的一致性，同是提高数据的查询效率。DM的建设本身是一个迭代循环的过程，需要每过一个阶段对已开发的维度和事实进行分析和重构，由于数据来源一致也可以降低迭代重构的难度，同时对已开发的分析报表的影降到最低等，DM的建设更倾向于是个维度和事实的收集、分析和重构的过程。
目前很多DM 的前端工具采用拖拽的方式实现报表，操作简单，可以通过对业务人员的培训而直接由业务人员操作定制自己需要的报表，可是如果制作报表所需要的指标、维度不完整，这一切都是看起来很美。

千问 · 2015-3-6 11:57:31

对于dw和dm的不同定位，我也有所了解。我的疑惑在于，DW的实际稳定性到底是依靠什么来保证的呢？星型模型就不能达到稳定的程度吗？
我一直怀疑，在需求不明确的情况下，设计一个可以支撑以后需求的模型，是不是过于理想化了？所谓的以后的需求，难道不是基于设计人员的猜测？在业务和技术都高速发展的情况下，过于前瞻的设计，是不是都承担了太大的风险？相对来说，星型模型的设计由于简单透明，是不是应该更有优势？
我个人怀疑，是不是由于最低粒度的星型模型的数据量太大，无法实际响应查询，所以才造成了目前3范式为主体的建设模式？没做过真正大规模的数据堆集，不敢说。

千问 · 2015-3-6 11:57:31

知道为啥现在很少直接用维度建模直接用汇总数据做BI？因为硬件技术，特别是大数据时代，最细粒度数据的查询以及向上汇总并非多大的难事，直接降低了维度数据建模的门槛。以往维度数据建模要非常理解业务和建模技术，才能使得模型在稳定性和易用性上得到平衡，而直接在最细粒度上建维度统计，就用物理设计技术降低了业务逻辑设计门槛。

千问 · 2015-3-6 11:57:31

我觉得纯用三范式来描述kimball，太不恰当了，km的理论上自下向上建立dw再加上bi bus，而inmon是建议EDW从上到下。

千问 · 2015-3-6 11:57:31

插一句，维度建模和3NF建模真的有很大的区别么？
个人感觉3NF和维度建模最重要的区别是理念不同，一个是考虑数据的完成性与冗余的消除，一个是关注数据的查询性能与业务的易理解性
但在实际的数据仓库开发中，很多设计也会折中去处理，比如3NF建模中，也会考虑子维度的合并到父维度，提高数据的查询性能。
维度建模的实际应用中，也会把大维度拆分出一些小维度由于某些原因（比如应对经常变更的超大维度表），这样设计就不是维度建模了么？