最近给公司写"Advance Dimensional Model Solution"的PPT文档(英文)中, 目标就是帮助在一般项目中如何快速建更好地建模型去服务业务模型以及更多BI应用, 不仅仅是OLAP应用。这里主要讲维度模型，不涉及如何构建整个数据仓库系统，就是谈数据集市这个层面如何更好地为业务需求服务。 主要谈到以下几点: 1. 用DW2.0的某些优点来帮助更好地建设多个数据集市的MD构建思路. 从一个新的角度看待问题，比如数据联通性等等。 ----- 以数据仓库整体架构思路考虑, 适合多个数据集市, 多个部门的多业务分析BI需求. 2. 数据集市和数据模型, 主要谈到由于数据集市面向部门级应用, 针对不同部门的具体需求, 如何统一试图建模,而又满足不同部门不同的业务分析需求. ---- 数据集市建立的整体建议, 在统一维度模型建立后如何满足客户个性化分析需求, 在数据模型的层面上如何实现. 3. 如何具体逻辑建模去满足客户业务需求, 包括从粒度、周期、字段描述等角度结合。 ---- 从具体实施的角度, 去解决客户不同周期、不同粒度分析的角度，从考虑数据模型作为业务分析模型的基础的角度考虑全方位对实现BI的支持。 4. 如何基于成熟行业模型产品去扩展表、视图、字段，并根据需求去合并、汇总来满足客户业务分析、挖掘和查询需求和需求变化。 ---- 如何在拿到一个成熟模型后，去根据客户的具体需求以及需求变换、新需求去扩展数据模型。解决不能把成熟模型达到最大作用的发挥问题，使整体解决方案更加快速和适应BI，而不至于把压力交给前端。 5. 关于主数据和参考数据。一般来说数据建模会以主数据建模，而忽略了参考数据的作用。这里主要介绍主数据与参考数据的结合，以及参考数据的建模。 ---- 一般数据模型只会考虑主数据，对参考数据不会有在整体解决方案里有具体的位置。这里主要解决主数据表和参考数据的结合思路，如何建参考数据表来帮助数据模型更加可靠和灵活。 6. 数据模型支撑ETL。 在ETL阶段，往往会因为数据量太大，而导致不能在客户要求周期内完成ETL，造成BI整体失败。那么数据模型的灵活构建，将在逻辑上对ETL的效率给予直接的提升。 ---- 解决当ETL出现效率问题，而且从数据库优化到ETL代码优化都完成后任何不能解决问题的情况下，以灵活的过度过度模型去拉动ETL效率直到满足效率的要求。 7. 统一视图建模方式的实施方案以及ETL流程。很多实施者看了书仍然不知道具体如何去实施，包括建模和ETL流程，需要用成功案例的实践说明。 ---- 具体解决实施统一视图建模型。统一视图建模只要在多数据集市里有非常重要的意义，能解决数据一致性，降低开发成本、容易维护等多个整体方案问题的特点。 8. 对维表的扩展。扩展维表以满足客户个性化的维度描述的需求，包括以扩展字段的方式，也包括表、视图的扩展。 --- ******* 该问题是最具体的实施问题之一，也是最容易理解的一部分。主要解决客户个性化的分析需求，新的分析角度、新的维度属性等具体问题。 9. 对事实表的扩展。扩展事实表，以及满足客户对分析的需求。包括结合度量和新的维度描述，生成新的字段，也包括维度事实表的建设。 --- ******* 同上，解决最实际的问题。主要解决效率和客户对新度量的需求问题，在现实项目中，可以最有效地解决类似实际问题。 10. 其他。包括建议使用控制表，作为控制ETL流程和数据质量的一部分；建议针对新需求和需求变化，只增加字段或者表、视图，不要擅自修改或者删除已经成熟的对象； 介绍当由于效率、权限等因素造成现有数据集市不能满足BI需求的时候，如何数据集市重组，增加数据仓库生命周期。 ---- 解决其他可能出现的问题。比如控制表帮助控制ETL流程，增加ELT质量的保证等；模型变化处理的常见规则；以及数据集市出现需要大的变动，如何去用更好的方案去处理。 以上很多点在大师书中能找到理论，只是我从另外的一个角度去看问题，结合失败和成功的教训和经验来看，也许换个思路会更好，只不过还是要围绕事物的本质去看待问题。 之所以要把数据模型更灵活更高效率地建设起来，我想在现实中，看到了太多在比较死的数据模型里，面对更多报表和业务分析，只能依靠BI工具去努力实现新的业务逻辑，如果工具不能支持，或者没人能挖掘出这个功能，那么在这个节点上就会耽搁1、2天甚至更长时间。而在现实项目中，处理实际项目中的这类问题还是从后台找解决方案的比较多，然而临时性的补充不会对业务有整体的支持。也有数据模型不够好的时候，出现业务需求一变化，数据模型就不能支持，得做重大修改，这也是普遍的现象，需要注意，不然就得乱投医，去找BI工具了。所以无论是对行业业务本身，还是解决方案，都得有一定积累。 为啥多次强调这些事情要在数据模型处理，帮助前端业务模型，而不是BI工具。这个时候你说数据模型围绕业务模型也好，业务模型为中心也好。有几大原因： 1。 数据模型不依赖任何产品，是逻辑上的东西，可无限复制，仅仅是方案，而BI工具，换个产品就可能不行了，难道你不让客户有选择BI工具的权利？ 2。 效率问题。大家都知道数据仓库的特点是存储，处理好的数据，和BI工具临时去运行，效率比较不言而喻。而且有时为了加强整体效率，数据模型可以结合事实表和维表里某个新定制的维度型产生个性化的度量，这个解决方案有明显的效率优势，而BI工具的效率提高非常有限。 3。灵活性。大家知道没有任何BI工具可以实现所有客户需要的功能，比如客户要做数据挖掘，那么很可能会用SAS，SPSS等专业工具去做，那么他们也需要很多业务逻辑，如果这些业务逻辑转换的事务放到BI工具层面，那么就无法进行扩展了。而数据模型非常灵活，不同的BI应用，都可以提供灵活的支持。至于业务人员灵活分析，那时分析角度的问题，增加的业务分析型就是增加了信息量，普遍认为的观点，还是应该在数据模型里去打好基础，业务分析才能做得更好。而BI厂商可以在分析视图、角度去下功夫，但对于和信息有关的事情，还是让客户在数据层面打好基础，才是最理智的。[@more@] 数据模型支撑BIDW项目之基本思路