数据模型支撑BIDW项目之基本思路

最近给公司写"Advance Dimensional Model Solution"的PPT文档(英文)中, 目标就是帮助在一般项目中如何快速建更好地建模型去服务业务模型以及更多BI应用, 不仅仅是OLAP应用。这里主要讲维度模型，不涉及如何构建整个数据仓库系统，就是谈数据集市这个层面如何更好地为业务需求服务。 主要谈到以下几点:
1. 用DW2.0的某些优点来帮助更好地建设多个数据集市的MD构建思路. 从一个新的角度看待问题，比如数据联通性等等。
2. 数据集市和数据模型, 主要谈到由于数据集市面向部门级应用, 针对不同部门的具体需求, 如何统一试图建模,而又满足不同部门不同的业务分析需求.
3. 如何具体逻辑建模去满足客户业务需求, 包括从粒度、周期、字段描述等角度结合。
4. 如何基于成熟行业模型产品去扩展表、视图、字段，并根据需求去合并、汇总来满足客户业务分析、挖掘和查询需求和需求变化。
5. 关于主数据和参考数据。一般来说数据建模会以主数据建模，而忽略了参考数据的作用。这里主要介绍主数据与参考数据的结合，以及参考数据的建模。
6. 数据模型支撑ETL。 在ETL阶段，往往会因为数据量太大，而导致不能在客户要求周期内完成ETL，造成BI整体失败。那么数据模型的灵活构建，将在逻辑上对ETL的效率给予直接的提升。
7. 统一视图建模方式的实施方案以及ETL流程。很多实施者看了书仍然不知道具体如何去实施，包括建模和ETL流程，需要用成功案例的实践说明。
8. 对维表的扩展。扩展维表以满足客户个性化的维度描述的需求，包括以扩展字段的方式，也包括表、视图的扩展。
9. 对事实表的扩展。扩展事实表，以及满足客户对分析的需求。包括结合度量和新的维度描述，生成新的字段，也包括维度事实表的建设。
10. 其他。包括建议使用控制表，作为控制ETL流程和数据质量的一部分；建议针对新需求和需求变化，只增加字段或者表、视图，不要擅自修改或者删除已经成熟的对象； 介绍当由于效率、权限等因素造成现有数据集市不能满足BI需求的时候，如何数据集市重组，增加数据仓库生命周期。

以上很多点在大师书中能找到理论，只是我从另外的一个角度去看问题，结合失败和成功的教训和经验来看，也许换个思路会更好，只不过还是要围绕事物的本质去看待问题。

之所以要把数据模型更灵活更高效率地建设起来，我想在现实中，看到了太多在比较死的数据模型里，面对更多报表和业务分析，只能依靠BI工具去努力实现新的业务逻辑，如果工具不能支持，或者没人能挖掘出这个功能，那么在这个节点上就会耽搁1、2天甚至更长时间。而在现实项目中，处理实际项目中的这类问题还是从后台找解决方案的比较多，然而临时性的补充不会对业务有整体的支持。也有数据模型不够好的时候，出现业务需求一变化，数据模型就不能支持，得做重大修改，这也是普遍的现象，需要注意，不然就得乱投医，去找BI工具了。所以无论是对行业业务本身，还是解决方案，都得有一定积累。

为啥多次强调这些事情要在数据模型处理，帮助前端业务模型，而不是BI工具。这个时候你说数据模型围绕业务模型也好，业务模型为中心也好。有几大原因：
1。 数据模型不依赖任何产品，是逻辑上的东西，可无限复制，仅仅是方案，而BI工具，换个产品就可能不行了，难道你不让客户有选择BI工具的权利？
2。 效率问题。大家都知道数据仓库的特点是存储，处理好的数据，和BI工具临时去运行，效率比较不言而喻。而且有时为了加强整体效率，数据模型可以结合事实表和维表里某个新定制的维度型产生个性化的度量，这个解决方案有明显的效率优势，而BI工具的效率提高非常有限。
3。灵活性。大家知道没有任何BI工具可以实现所有客户需要的功能，比如客户要做数据挖掘，那么很可能会用SAS，SPSS等专业工具去做，那么他们也需要很多业务逻辑，如果这些业务逻辑放到BI工具层面，那么就无法进行扩展了。而数据模型非常灵活，不同的BI应用，都可以提供灵活的支持。至于业务人员灵活分析，那时分析角度的问题，增加的业务分析型就是增加了信息量，普遍认为的观点，还是应该在数据模型里去打好基础，业务分析才能做得更好。而BI厂商可以在分析视图、角度去下功夫，但对于和信息有关的事情，还是让客户在数据层面打好基础，才是最理智的。

微信扫一扫实时了解行业动态

微信扫一扫分享本文给好友