维度模型- 总线矩阵前后

1. 问题

基本上所有书籍对维度模型的表述都是有了维度和业务过程之后， 构建总线矩阵，进行开发。

很少有书籍系统阐述 业务过程和维度怎么来的。为什么呢？

2 .猜测

有了业务过程和维度后， 后续的都是可以标准化的流程。

怎么获得业务过程，可能收环境和当事人背景影响，不好标准化。

3. 歧义

业务过程到底怎么来的？

是可以一个一个的往总线矩阵补充，然后合并成数据仓库。 还是在最开始就对宏观业务有一个抽象，业务过程是宏观业务中，边界清楚的一块。

有了总线矩阵之后，分布式开发，然后多个业务过程通过一致性维度拼成数据仓库这个没意见。但是总线矩阵能这么从下到上的迭代吗?

谁这块有理解，指教一下，谢谢

4. 个人感悟

就跟画画一样， 老师上课时可以举个例子，然后告诉学生该怎么画。学生毕业后想画啥，跟老师一毛钱关系没有。

维度模型也是，最终目的是用数据描述建模人员脑中的业务。 kimball 老师只能举一些例子告诉你怎么用维度模型描述已经定义好的业务， 具体你脑中的业务怎么来的是什么，只有一些通用建议，其实跟kimball老师关系不大。

业务，站在不同的角度，得出的结论不一样。

横看成岭侧成峰，远近高低各不同。

所以呢，维度建模方法论是什么，是对建模人员脑中的业务进行用数据进行描述的一种方法 。

这个已知业务是什么，怎么来的，和维度模型方法论没关系，维度模型方法论就是一个纯函数。

这个已知业务应该是公司内沟通妥协抽象总结来的，统一视角。

 过一阵再折腾一遍，可能结果还不一样。

所以呢， 维度模型分三步

•  确定要做啥， 或者确定要做啥后，才评估用维度模型方法论。可以借鉴一些kimball的通用建议，但是这个很主观， 和维度模型方法论关系不大。 千万别觉得这部没维度模型不行，100年前没有维度模型， 100年后也不见得还有人用维度模型， 但是要做啥还得做。
•  把要做的东西用维度模型方法论拆分成维度和业务过程，构建总线矩阵。
• 落地开发。

所以呢， 个人觉得， 维度模型开发前， 画总线矩阵前， 要对业务有清晰全面的认知，然后按照维度模型的方法论去建设仓库。 而不是一知半解时， 就对片面的东西开始进行维度模型建设。

或者做一个指标： 从开始到结束，业务过程定义进行改变的比率。