关于业务封装的理念

今天厂商给我们做BW培训，感觉BW用户友好性设计还是和SAP一样比较差，不过其业务封装式的模型和开发，与我们设计的BI理念不谋而合，只是他们做的东西操作繁复，面向是BI专人人士，而非业务用户，这点还是老传统理念。

封装的好处就是让你不用去理解复杂的数据模型，理解各个表之间的关系，你只需要知道你要那个业务对象的哪个业务字段，知道怎么利用他们整合到你的下一个整合模型中去就OK，以业务为导向。其实在普通DW开发的时候，有如下2种情况，也可以自己设计这样的模式，使开发变得更有扩展性，更可控。

1. 如果你的ETL要外包开发，或者设计者交给别人开发，而不想花太多时间来解释你的mapping，或者你不想让对方知道你的物理模型关系，你可以先用VIEW将数据源逻辑封装，将数据字段整合成为面向业务的接口，这样就可以轻松达到你的目的。

2. 当这个项目需求不确定，或者需求变化太快，也请将物理逻辑封装起来，只面向业务，这样的话，无论业务系统有变化，还是用户需求有变化，他们变的无非是数据源的字段、或者业务字段的公式，但我们DW不用改变太多，因为我们的设计是面向业务的，而不是面向数据库物理字段的。

这是数据源的封装以及其目的，而EDW如果进行面向业务的深入扩展的时候，也可以这样，面向基本的业务流定义字段，不用考虑用户怎么用，怎么分析，因为那是变化的，只需要整合纯粹的业务流程，将你认为需要整合起来才能讲述一个完整的业务故事进行处理。

还有一个需要进行封装的地方，就是BI展现，BI厂商质疑用户不能自己开发报表的唯一理由，就是BI的界面都是些字符数字。那为何不将最终展现的业务字段进行封装呢？比如物流订单里的一个指标就叫“未出库现货订单数量”，接着点击这个指标，还有其公式和来源、定义显示，请问这个接口还不能让只懂业务的人使用么？

第一点思路很赞成， 不过一般不会ETL设计之后将这部分放给外包，貌似很少啊，BI在国内还没这么发达，呵呵。一般的ETL developer 都会看物理模型的。


第二点，需求不确定，需求变化太快 还能够将物理逻辑封装， 这个不太理解。 设计的逻辑肯定是根据需求来的，需求都变了，封装物理逻辑感觉两码事。

用户需求变化和业务系统有变化，DW肯定会变化的，而且会根据需求的变动量而决定变的多少。

将业务字段封装，已经达到很高级别的封装了，封装在我看来有两个目的：一是具有原子功能化的意思 二是具有安全性的意思

实际的BI项目中BI的安全性对BI 开发者应该来说基本公开的，很难做到通过封装来控制，当然对用户是另外一个概念了。