DW逻辑模型技术可快捷阶进

随着公司BI覆盖几乎所有部门，我们少数2个资深的人设计不过来了，得靠新晋升为资深人士的同事一起设计更多项目的分析模型。不过为了把团队技术积累更好，且让大家更有发挥空间，我计划与团队分享一些快速阶进的设计技术与基本原则，大概思路如下：

首先，为了长远和近期2种考虑，建设EDW与数据集市都得做，都重要，EDW为基础业务数据，但以主题为事实划分，例如订单事实表，除了整合订单自身的业务数据外，还需要将订单相关的业务整合进来，方便数据集市使用，例如订单分析重要的物流信息、订单相关的重要合同信息等，形成一个较为完整的订单业务全局视图。虽然这个EDW并非所有人想的那种设计方式（和其他事实表有一定信息冗余），但也是主流的之一，且既容易设计，也容易随着设计而深入理解业务。

其次维度分析模型，这个其实在应用中最为重要，虽然EDW是基础，也非常重要，但这个可是直接体现BI价值的基础。我认为维度模型需要划分为事件点式模型和过程式模型2种。

何谓事件点式模型，其实就是最常见的事实表设计方法，由时间、地点、单位、商品等维+销售、利润、成本等指标，以及一些事实属性共同构成最为经典和传统的事实表，它能提供最为直接的某个专题的重要信息，但是它是在某个业务点上，例如零售是一个事件点，一个结果，同理客户订单等也是。

那何谓过程式模型呢？这个就是需要自己抽象的分析模型了，就是将业务系统中零散的事件点，你用模型串起一个业务过程，让用户能分析过程中发生了什么事情，用户重点提高过程中哪一步才最有效。常见的业务包括大宗商品销售过程、网络营销过程、商品生产过程、物流配发过程等等，这个设计的最大好处，就是让用户既能看到某个事件点到底发生了什么，还能看到整个过程是否正常，问题出在哪个节点，才能知道如何下手改善，从能业务整体来发现问题，使用户找到解决问题的捷径。

过程式分析模型中，如果业务系统有过程这个事实或概念，那么设计人员较容易入手设计。但多数业务系统还是需要BI人自己去根据事情情况抽象的。最核心的思想，就是抽象出业务过程这个概念来串连整个业务，使用户既可分析点，也可分析面，达到最佳分析目的。

其实我非常喜欢过程式分析模型的研究，因为发挥空间大，价值深，模型就能讲故事，减少人工介入拼凑分析。同时用户看似很复杂的分析需求，我可以一个事实表就帮助他们分析，甚至可能超过了一些用户的期望。

那何谓过程式模型呢？这个就是需要自己抽象的分析模型了，就是将业务系统中零散的事件点，你用模型串起一个业务过程，让用户能分析过程中发生了什么事情，用户重点提高过程中哪一步才最有效。常见的业务包括大宗商品销售过程、网络营销过程、商品生产过程、物流配发过程等等，这个设计的最大好处，就是让用户既能看到某个事件点到底发生了什么，还能看到整个过程是否正常，问题出在哪个节点，才能知道如何下手改善，从能业务整体来发现问题，使用户找到解决问题的捷径。

----------------------------
我对你这个建模方式比较感兴趣，但是有些疑问

1、在过程中这些流程还是由各个属性组成，比如地点，时间（维度）+各种中间指标产生。相当于在一系列业务流程的snapshot而已。还是属于时间点式建模。
2. 过程建模我觉得你的意思是：事件点式模型是以某个流程节点来当作主题建模。过程式模型你想把各个流程节点汇总到一个模型里面。我觉得实质上还是一个观察时点的问题，只要抽象出一个时点维度就可以了。

总的来说。事件式是某个节点（流程节点或业务节点），流程式是把单独的节点串起来而已。实际上是需求的偏重不同而已。前者是看业务节点做了什么。后者是看业务流程的运转（从这点来看确实有好处，但是通过设置观察时点建模同样能达到目的）。不知lz能否讲的更细，比如从过程式建模抽象出的维度和指标有那些?