OLAP报表：欲追求完美自由
代 严
在BI行业中的OLAP Reports应用中，默认（常见）的都是有若干同类指标（度量）和若干维度（指标所对应的关注角度）构成一张报表。
在一个相关应用年代已久的公司，这些报表都有不同的业务用户属主（业务公司或业务部门），报表相关的定义和变更均由该属主决定。随着时间的流逝，不同报表（甚至是不同属主）之间可能出现类似名称的报表和相同或极度相似名称的指标——报表和指标对业务以其名称做标识——而这些报表的用户包含若干部门若干层级的若干个体，假如譬如"指标字典"一样的辅助支持不到位，则用户面对这些不同报表中的同名指标将无比困惑，无法做出选择。
于是，业务用户开始了冥思苦想，问题到底出在哪里？除"指标字典"一类的辅助支持需要完善、指标定义（含体系）需要清理（整理）外，他们还发现令他们兴奋无比的一点——根本原因：现有的开发是以报表为中心开发的，业务需要一个指标数据则必须到某个报表中取。并判断这正是一切问题的根源！所以，根本解决之道就需要将开发架构修改为"以指标为中心"，业务用户"任意"选择指标和维度后点击一个按钮再生成所需报表，自由组合、自由定制、自由分析!
我宁愿将这种愿景称作OLAP报表追求的"自由"，喔，这里又出现了"报表"二字——按照业务方的"构想"，在他们选择好自己喜欢的指标和维度之前并按下按钮之前，并不存在任何"报表"一类的概念。
如果为这种"自由"加一个"限度"，那什么样的限度才是核心的呢？可能大家都会想：定义主题，在一个适当粒度的主题范围内实现这种自由。这含于DW的理论与实践中，似乎有了支撑，目前我也只能这么去琢磨。
但是，如果这个粒度定义得非常大——这正是业务用户所强烈要求的，暂且不管其理性与否——产出品能否实现这种自由组合将首先面临IT技术上的门槛，譬如如果维度较多却某些维度使得数据难于有效汇总，则基于ROLAP实现在效率上将是个悲剧，因为很多一个指标（现有报表中的指标）的一段时间（几个月到一年，再长时间都只能拆开）内的事实数据都是千万甚至轻易就过亿级；如果居于MOLAP，给用户提供多维立方体（CUBE）供其随意展现，这个CUBE的扩展性是被首先质疑的，同时，大数据量带来的生成CUBE的效率和CUBE文件的大小也将是噩梦。
如果，这个粒度定义得比较细，恐怕就成为现有的报表了，甚至连外面的皮都不用换，那还不如就清理清理报表和指标的定义什么的即可——就不存在业务领导所要看到的将"以报表为中心"修改为"以指标为中心"的"颠覆性"（业务所需）的变化了，项目的意义也将不存在。
需要给这样的愿景加一些定义条件，使得项目可行。在大型数据仓库或者数据集市项目设计方面经验比较丰富的同行前辈们愿不愿意给出一些点拨？本人在此感激不尽。
--
---------------------------------------------------------------
---DAI YAN BEST WISHES！
笨笨
"所以，根本解决之道就需要将开发-架构修改为"以指标为中心"，业务用户"任意"选择指标和维度后点击一个按钮再生成所需报表，自由组合、自由定制、
自由分析! "
这个早就实现了~~
On Jan 7, 1:09 am, "代 严" <daiyani...@gmail.com> wrote:
> 在BI行业中的OLAP Reports应用中，默认（常见）的都是有若干同类指标（度量）和若干维度（指标所对应的关注角度）构成一张报表。
>
> 在一个相关应用年代已久的公司，这些报表都有不同的业务用户属主（业务公司或业务部门），报表相关的定义和变更均由该属主决定。随着时间的流逝，不同报表（甚至-是不同属主）之间可能出现类似名称的报表和相同或极度相似名称的指标----报表和指标对业务以其名称做标识----而这些报表的用户包含若干部门若干层级的若干个体，-假如譬如"指标字典"一样的辅助支持不到位，则用户面对这些不同报表中的同名指标将无比困惑，无法做出选择。
>
> 于是，业务用户开始了冥思苦想，问题到底出在哪里？除"指标字典"一类的辅助支持需要完善、指标定义（含体系）需要清理（整理）外，他们还发现令他们兴奋无比的-一点----根本原因：现有的开发是以报表为中心开发的，业务需要一个指标数据则必须到某个报表中取。并判断这正是一切问题的根源！所以，根本解决之道就需要将开发-架构修改为"以指标为中心"，业务用户"任意"选择指标和维度后点击一个按钮再生成所需报表，自由组合、自由定制、自由分析!
>
> 我宁愿将这种愿景称作OLAP报表追求的"自由"，喔，这里又出现了"报表"二字----按照业务方的"构想"，在他们选择好自己喜欢的指标和维度之前并按下按钮之-前，并不存在任何"报表"一类的概念。
>
> 如果为这种"自由"加一个"限度"，那什么样的限度才是核心的呢？可能大家都会想：定义主题，在一个适当粒度的主题范围内实现这种自由。这含于DW的理论与实践-中，似乎有了支撑，目前我也只能这么去琢磨。
>
> 但是，如果这个粒度定义得非常大----这正是业务用户所强烈要求的，暂且不管其理性与否----产出品能否实现这种自由组合将首先面临IT技术上的门槛，譬如如果维度-较多却某些维度使得数据难于有效汇总，则基于ROLAP实现在效率上将是个悲剧，因为很多一个指标（现有报表中的指标）的一段时间（几个月到一年，再长时间都只-能拆开）内的事实数据都是千万甚至轻易就过亿级；如果居于MOLAP，给用户提供多维立方体（CUBE）供其随意展现，这个CUBE的扩展性是被首先质疑的，同-时，大数据量带来的生成CUBE的效率和CUBE文件的大小也将是噩梦。
>
> 如果，这个粒度定义得比较细，恐怕就成为现有的报表了，甚至连外面的皮都不用换，那还不如就清理清理报表和指标的定义什么的即可----就不存在业务领导所要看到的-将"以报表为中心"修改为"以指标为中心"的"颠覆性"（业务所需）的变化了，项目的意义也将不存在。
Qing
interstage
宗旨是"help buyers make the most of their OLAP tool selection and
implementation projects. " 显然看Qing的描述"OLAP Report",不是olapreport.com的东西,
仅仅是基于Olap工具后的展现报表,该报表的"自由"+"限度"的平衡点就是BIER最难把握的东西. 我在"OLAP工具毁了BI"一文中已经讲
过, OLAP最基本的概念其实只有三个：多维观察、数据钻取、CUBE运算。如果从OLAP这3个角度着力点去开发报表(因为BI分析的载体一定是报
表,图形只是报表的变异而已),Olap就一定会毁掉报表的价值,甚至BI的价值本身(就是分析). 所以,OLAP 如果在另外3点着力,可能会绕过
这个问题,那就是1,随部门不同的业务术语的快速变化(有点元数据管理的感觉);2,ad hoc分析报表计算的新要求快速实现(有点象CUBE计算的
快速实现);3,新视角(维)随业务环境变化(其实是分析思路的变化)不断的被沉没或被唤醒. (有点OLAP的多维角度变化游离出IT人员进入业务人
员手上的感觉). 我一直认为,OLAP这3点着力点上太少,就是有点工具有,也只是面向IT人员,这也是被限制. 这也是我一直对BI关注的重点,
因为分析本身是无极限的.如果基于分析载体的报表受限了,分析也就受限了."减少分析的受限"其实可能是"OLAP Report" 追求的真谛.
daiyan
概念“多维观察、数据钻取、CUBE运算”。每张报表有若干自己的的指标和若干自己的维度。
用户觉得这样“以报表为展示单位”“导致了很多问题”，不好，于是要求升级为“以指标为展示中心”，用户访问系统见到的将不是一张张报表，而是一个个可
选指标和可选维度，用户只有选择一个或多个指标维度然后点个按钮生成所想要的报表。
虽然不一定要有一个点击按钮的过程，但是我理解用户所要的其实就是想以标准化规范化的指标来替换报表，并直接与指标交互。因为各报表之间被割裂开的独立
性使得出现混乱的同名指标，或者类似口径含义的指标在不同报表间不具有可比性，等等。所以想先标准化指标，达到消除冗余指标、明确区分类似指标、准确充
分定义指标含义逻辑口径等目的，然后以指标为基本单位改造现有的报表。
应该说，标准化指标并不一定彻底改变IT开发基础，也不见得就要“消灭”报表。但是业务把此列为最核心的项目目标。没得回旋余地。
现实的OLAP开发总是要基于一些平台，如Oracle、Cognos等，在这些平台或者是其它平台上，不知道有没成熟的解决方案能够实现用户这种“想
象”。
（可能还有描述不全面的地方，现在时间不充裕，往后再续）
daiyan
我这里所要描述的是打破一张报表限制的自由组合和定制分析，并能由业务用户随意保存定制结果（类似于Cognos 8里面的各种Stdio组件自定义一
个报表后保存，这个开发过程要求不需要IT直接介入，IT一旦直接介入就要求这种定制被提起设计并固定下来）。
On 1月7日, 上午10时33分, 笨笨 <caozhen...@gmail.com> wrote:
> "所以，根本解决之道就需要将开发-架构修改为"以指标为中心"，业务用户"任意"选择指标和维度后点击一个按钮再生成所需报表，自由组合、自由定制、
> 自由分析! "
>
> 这个早就实现了~~
>
> On Jan 7, 1:09 am, "代 严" <daiyani...@gmail.com> wrote:
>
>
>
> > 在BI行业中的OLAP Reports应用中，默认（常见）的都是有若干同类指标（度量）和若干维度（指标所对应的关注角度）构成一张报表。
>
> > 在一个相关应用年代已久的公司，这些报表都有不同的业务用户属主（业务公司或业务部门），报表相关的定义和变更均由该属主决定。随着时间的流逝，不同报表（甚至--是不同属主）之间可能出现类似名称的报表和相同或极度相似名称的指标----报表和指标对业务以其名称做标识----而这些报表的用户包含若干部门若干层级的-若干个体，-假如譬如"指标字典"一样的辅助支持不到位，则用户面对这些不同报表中的同名指标将无比困惑，无法做出选择。
>
> > 于是，业务用户开始了冥思苦想，问题到底出在哪里？除"指标字典"一类的辅助支持需要完善、指标定义（含体系）需要清理（整理）外，他们还发现令他们兴奋无比的--一点----根本原因：现有的开发是以报表为中心开发的，业务需要一个指标数据则必须到某个报表中取。并判断这正是一切问题的根源！所以，根本解决之道就需要-将开发-架构修改为"以指标为中心"，业务用户"任意"选择指标和维度后点击一个按钮再生成所需报表，自由组合、自由定制、自由分析!
>
> > 我宁愿将这种愿景称作OLAP报表追求的"自由"，喔，这里又出现了"报表"二字----按照业务方的"构想"，在他们选择好自己喜欢的指标和维度之前并按下按-钮之-前，并不存在任何"报表"一类的概念。
>
> > 如果为这种"自由"加一个"限度"，那什么样的限度才是核心的呢？可能大家都会想：定义主题，在一个适当粒度的主题范围内实现这种自由。这含于DW的理论与实践--中，似乎有了支撑，目前我也只能这么去琢磨。
>
> > 但是，如果这个粒度定义得非常大----这正是业务用户所强烈要求的，暂且不管其理性与否----产出品能否实现这种自由组合将首先面临IT技术上的门槛，譬如-如果维度-较多却某些维度使得数据难于有效汇总，则基于ROLAP实现在效率上将是个悲剧，因为很多一个指标（现有报表中的指标）的一段时间（几个月到一年，再-长时间都只-能拆开）内的事实数据都是千万甚至轻易就过亿级；如果居于MOLAP，给用户提供多维立方体（CUBE）供其随意展现，这个CUBE的扩展性是被首-先质疑的，同-时，大数据量带来的生成CUBE的效率和CUBE文件的大小也将是噩梦。
>
> > 如果，这个粒度定义得比较细，恐怕就成为现有的报表了，甚至连外面的皮都不用换，那还不如就清理清理报表和指标的定义什么的即可----就不存在业务领导所要看-到的-将"以报表为中心"修改为"以指标为中心"的"颠覆性"（业务所需）的变化了，项目的意义也将不存在。
>
> > 需要给这样的愿景加一些定义条件，使得项目可行。在大型数据仓库或者数据集市项目设计方面经验比较丰富的同行前辈们愿不愿意给出一些点拨？本人在此感激不尽。
>
> > --
> > ---------------------------------------------------------------
> > ---DAI YAN BEST WISHES！- 隐藏被引用文字 -
>
> - 显示引用的文字 -
Qing
..
用户觉得这样"以报表为展示单位""导致了很多问题"，不好，于是要求升级为"以指标为展示中心"，用户访问系统见到的将不是一张张报表...
笨笨
至少MSTR是实现了，维度和指标作为对象直接映射底层数据仓库。报表开发人员只要将这些对象拖入报表模板即可生成报表。
BO的实现不知道哪位高手能描述描述？
On Jan 7, 11:48 pm, daiyan <daiyani...@gmail.com> wrote:
> 对你这个回答很干兴趣，能否烦请稍微详细解释一下？谢谢：）
>
> 我这里所要描述的是打破一张报表限制的自由组合和定制分析，并能由业务用户随意保存定制结果（类似于Cognos 8里面的各种Stdio组件自定义一
> 个报表后保存，这个开发过程要求不需要IT直接介入，IT一旦直接介入就要求这种定制被提起设计并固定下来）。
>
> On 1月7日, 上午10时33分, 笨笨 <caozhen...@gmail.com> wrote:
>
>
>
> > "所以，根本解决之道就需要将开发-架构修改为"以指标为中心"，业务用户"任意"选择指标和维度后点击一个按钮再生成所需报表，自由组合、自由定制、
> > 自由分析! "
>
> > 这个早就实现了~~
>
> > On Jan 7, 1:09 am, "代 严" <daiyani...@gmail.com> wrote:
>
> > > 在BI行业中的OLAP Reports应用中，默认（常见）的都是有若干同类指标（度量）和若干维度（指标所对应的关注角度）构成一张报表。
>
> > > 在一个相关应用年代已久的公司，这些报表都有不同的业务用户属主（业务公司或业务部门），报表相关的定义和变更均由该属主决定。随着时间的流逝，不同报表（甚至---是不同属主）之间可能出现类似名称的报表和相同或极度相似名称的指标----报表和指标对业务以其名称做标识----而这些报表的用户包含若干部门若干层级-的-若干个体，-假如譬如"指标字典"一样的辅助支持不到位，则用户面对这些不同报表中的同名指标将无比困惑，无法做出选择。
>
> > > 于是，业务用户开始了冥思苦想，问题到底出在哪里？除"指标字典"一类的辅助支持需要完善、指标定义（含体系）需要清理（整理）外，他们还发现令他们兴奋无比的---一点----根本原因：现有的开发是以报表为中心开发的，业务需要一个指标数据则必须到某个报表中取。并判断这正是一切问题的根源！所以，根本解决之道就需-要-将开发-架构修改为"以指标为中心"，业务用户"任意"选择指标和维度后点击一个按钮再生成所需报表，自由组合、自由定制、自由分析!
>
> > > 我宁愿将这种愿景称作OLAP报表追求的"自由"，喔，这里又出现了"报表"二字----按照业务方的"构想"，在他们选择好自己喜欢的指标和维度之前并按下按--钮之-前，并不存在任何"报表"一类的概念。
>
> > > 如果为这种"自由"加一个"限度"，那什么样的限度才是核心的呢？可能大家都会想：定义主题，在一个适当粒度的主题范围内实现这种自由。这含于DW的理论与实践---中，似乎有了支撑，目前我也只能这么去琢磨。
>
> > > 但是，如果这个粒度定义得非常大----这正是业务用户所强烈要求的，暂且不管其理性与否----产出品能否实现这种自由组合将首先面临IT技术上的门槛，譬如--如果维度-较多却某些维度使得数据难于有效汇总，则基于ROLAP实现在效率上将是个悲剧，因为很多一个指标（现有报表中的指标）的一段时间（几个月到一年，-再-长时间都只-能拆开）内的事实数据都是千万甚至轻易就过亿级；如果居于MOLAP，给用户提供多维立方体（CUBE）供其随意展现，这个CUBE的扩展性是-被首-先质疑的，同-时，大数据量带来的生成CUBE的效率和CUBE文件的大小也将是噩梦。
>
> > > 如果，这个粒度定义得比较细，恐怕就成为现有的报表了，甚至连外面的皮都不用换，那还不如就清理清理报表和指标的定义什么的即可----就不存在业务领导所要看--到的-将"以报表为中心"修改为"以指标为中心"的"颠覆性"（业务所需）的变化了，项目的意义也将不存在。
>
> > > 需要给这样的愿景加一些定义条件，使得项目可行。在大型数据仓库或者数据集市项目设计方面经验比较丰富的同行前辈们愿不愿意给出一些点拨？本人在此感激不尽。
>
> > > --
> > > ---------------------------------------------------------------
> > > ---DAI YAN BEST WISHES！- 隐藏被引用文字 -
>
> > - 显示引用的文字 -- Hide quoted text -
>
> - Show quoted text -
daiyan
目前我们和业务的沟通达不到我们在这里讨论这般超脱。但是Qing和interstage等几位提供的意见在理念上对我理解业务的真实需求很有启发。
xichen...@gmail.com
interstage
拽相应的维度和指标生成报表.也就是说业务分析角度定义还是在IT部门,和几年前是一样的. 这样,这个报表内涵的分析矛盾还是无法解决.只有业务分析
角度定义权在业务人员,才有可以解决这个问题.因为分析一定是业务人员的事情,而且分析往往涉及证实和证伪,这样报表的出现会很多,而有效的报表随着业
务变化会变化,很多无效的报表被沉没,这就是分析报表的内涵,而IT部门定义的业务分析角度,就限制出了业务人员的分析能力,他们只是基于固定业务分析
角度的灵活报表生成者,根本不是业务分析者.
Solo Zhu
务关联性的，比如产品和地区，产品和时间，还有业务人员和地区，时间，产品的关系。业务是活的，管理是活的，但是OLAP的结构，相对而言是固定的。
报表和数据统计的确能做得很好，也有很多人用，但是谈到衍生信息，我想报表就不一定能做到，衍生信息就是知道top10的产品，而且还要知道top10
相关产品的客户类型或者是其地理特点，或者是时间关联性，而这些是不能预定义的，如果指标和维度信息过多的话，分析和操作处理就变得困难。使用者也不一
定会用，所以操作定义需要业务关系。
所以在BI的项目中，如果工具具有语义层的话，比如BO的，最好能详细的对用户进行不定期的培训。如果别人使用效果很好，我想他不一定会说出来，毕竟企
业内也有竞争的，如果使用效果不好，他可能会提出来，我们就需要认真的考虑模型或者语义层的设计了。