第六篇.揭秘HFM自定义维度加密与解密算法

一、关于2.4版本对自定义维度加密的思考

我们先来看下昨天文章中的自定义维度选项，自定维度可以选择大中小。

在11.1.2.1中，是4个固定自定义维度，后台没有进行加密机制，也就是说数据表中原样使用Custom1~Custom4在维度表中的itemid.

Lcustom1	Lcustom2	Lcustom3	Lcustom4

但是到了2.4版本后，由于支持无限个自定义维度，如果还是保持2.1的思路把所有自定义维度原样展示，那么数据表的列将会越来越多，占用的空间会逐渐增大。所以，Oracle Hyperion团队做了很好的优化，一方面是优化了自定义维度的存储方式，即将自定义维度加密后存储为后台两个字段（custom1-custom2通过加密算法后放到后台表lcustom1，custom3-customN加密放到Lcustom2字段），另一方面对也降低了应用层代码解析的难度。2.1版本大概就是这个样子，值取自app_custom_item表中的itemid。

二、走进2.4版本HFM自定义维度的加密机制

2.1、web端创建应用时选择自定义维度的大小的影响     

首先说明下上面提到的大中小在计算机的世界是这样定义的，

小=1byte，中=2bytes，大=4bytes。

1byte = 255

先来看自定义维度对应的后台的一张神奇的表：

·这张表对应的web端新建应用时选择的类型“大”

·这张表对应的web端新建应用时选择的类型“中”

结论：Web端新建应用时选择不同的自定义维度大小，那么后台custom_map表对应的offset和length是不一样的。这里map表只有5行是因为应用程序只使用了5个自定义维度。如果web端创建应用时是更多自定义维度，那么map表会对应生成相应的行数出来。

2.2、custom_map表中offset和length的推演

以大小为“中”的情景来展示推演的过程

我在map表的基础上加了两列计算出来原表中的数字对应的offset和length。

以Dimid=9的这记录解释下，offset=4，length=4

那么：新的offset：256^4=4294967296，新的length：256^4=4294967296

256是什么？是1byte，还记得上面提到的1byte=255吗。当选择“中”时，上表中的第3行-5行的数据中offset为0、2、4，length为2、2、2

先回答下昨天东哥的问题，直观理选择大中小对应的自定义维度承载的成员个数：

小：256^1=256，中=256^2=65536，大=256^4=4294967296

有点绕，我讲清楚了吗，哈哈。

2.3、解开LCUSTOM1和LCUSTOM2的生成机制

为了更加直观，我再贴一次上面的表，留意公式中的颜色数字

Custom1=  MOD(LCUSTOM1,4294967296)

Custom2= FLOOR(LCUSTOM1/4294967296)

Custom3=  MOD(LCUSTOM2,65536)

Custom4=  MOD(FLOOR(LCUSTOM2/65536),65536)

Custom5=  FLOOR(LCUSTOM2/4294967296)

我们用数据验证下：

2.4、正向加密回去

贴图展示：

三、几点说明

3.1 关于自定义维度的算法机制

       上面讲了这么多自定义维度的加密解密机制，读者可能会问，有什么用处？

可能一方面是笔者对这后面的机制有了解的兴趣。在实际应用中，一般情况不会用到。基于hfm底层表进行开发可能会用到，比如填充单元格文本的内容用来在表单中追溯分录来源就需要解密自定义维度配合sql进行开发。

3.2 其他思路

       事实上，想要获取HFM的数据，Hyperion还提供了一个方案，可以同时得到base层数据和parent数据（上面的解密自定义维度只能只能获取base数据，想要获取parent数据，需要使用sql汇总）。这个方案在2.3版本叫扩展分析（Extend Analytics），简称EA，在2.3可以通过Hyperion安装包中的一个工具配合ODI实现自动化抽取数据，可以抽取任何smartview能刷出来的数据。在2.4将这个功能集成到数据提取的功能中：

遗憾的是，2.4版本由于升级改造，无法实现直接抽取自动化，需要人工干预。

想要了解从hfm抽取数据自动化，敬请期待后续文章