【andy教程第三十讲】Transformer 高级设计--指标维度解决思路

Cognos BI V8工具中Transfomer是OLAP多维设计建模工具，利用自身特性设计指标维度不能在Transfomer中组织，事先在数据库设计好，或者在IQD和FM中实现。基于业务要求设置同一个指标存储不同类型算法的数据。
如下图：

根据业务需求整理，测试OLAP如下：

1、维度有日期、指标集（包含总保费、标准保费、月人均标保产能（元/人）和人均标保增长率（%））

2、统计指标有：本期、累计、环比和同比。

3、在多维分析中，指标只有四个，同其他维度组合过滤得到指标集成员实际值。注意，指标集中的成员是必选条件，对指标集合计结果是没有任何意义，Cube会自动聚合。

最有意思的需求是，从业务部门拿到的指标都是率值，初步统计有百多个。指标多数是衍生指标，再计算同环比和占比，基本没有基础指标，目的是为满足审计部门需求分析。也是第一次遇到，同时把所有指标都做到Cube分析，还有考虑每个指标的预警值。几经周折考虑一种新的设计思路，把所以指标进行分类，做成类似产品维度，有层级关系。真正的指标值只有四个，这四个指标存储的数据有三种值：整点值、平均值、率值。每个值都有不同的算法组成，考虑多维自由操作灵活性，必须整理指标算法分类，归类以上三种值。

对于同比、环比计算率差，还要考虑上月同比环比。复杂而繁琐的设计工作不肯能用一个通用的模型套用，还不知道后期有多少变动等因素。我用了两天时间研究Transfomer，没有白费设计；上图就是我想要的结果。

通过前期需求人员了解，从业务报表系统或者手工报表提取经常关注的指标，自由组合一张大表，再整理成需求规范文档，对于报表设计是不存在问题，毕竟报表设计思路多样化，实现比较灵活。而把这些指标设计成一个有规律、有逻辑、有严谨计算关系的Cube，会存在很多问题。就算是设计出来，供用户使用会发现，越来越不是作分析的多维，反而成了一张查询的报表分析Cube，扩展性差，模式过于固定。

头疼这种设计思路，客户说什么，就的实现，需求只能微调。针对本需求自己琢磨过，客户比较了解EDW系统，而本次是实现一个功能，特殊需求特殊处理，对设计人员也是一种考验与探索。

本设计思路只适合特殊需求，不是公用模版，需求人员和设计人员值得参考。提醒大家，Cognos Transfomer价值不是简单体现在分析功能，而是反映一个行业与艺术的结合。无论什么工具工具，都不能停留在工具操作上的理解，而是认识他本身的价值优势。虽然设计一种自己没有尝试过的模型，而满足客户需求，这样付出的代价很高。就如同你利用飞机去运载火车拉的集装箱，付出的代价和风险太高了。


转载于wengr的博客