标准的商业分析应用，需要经过复杂的 ETL 过程来准备数据，再经过繁琐的多维建模过程来建立立方体，然后才能应用于各种分析应用。这种标准应用有两个缺点：
1 、操作的复杂度与技术要求决定了这些功能只能由开发人员或者高级实施人员来使用，最终用户只能作为报表使用者的角色出现；
2 、开发任务量非常巨大，成本高昂。
而现实应用中，除了上述标准应用流程，客户有些分析应用并不需要如此大的数据量，也不需要复杂的多维建模，客户追求的是即时、快捷的进行小数据量分析。我们姑且称之为即时分析。
虽然开发分析报表的过程得以简化，但分析应用所依赖的数据、多维模型不可或缺。
1 、数据
对于即席分析这种业务场景，用户分析的数据量不会太大，并且模型涉及的维度不会太多，不会消耗大量的系统资源。基于此，我们完全可以使用业务库来直接作为数据来源，使用这些原始的业务数据进行分析处理。
2. 多维模型
即席分析的便捷性决定了用户并不需要显式的创建多维模型，我们可以通过用户选择的业务实体模型，再基于业务关系模型来智能化、隐式建立多维模型。这是整个技术方案的关键点，下面我们将重点阐述。
现在主流的 ERP 系统，一般都有自己的业务模型层，基于此来建立业务应用。而我们的整个技术方案也是基于此业务模型。
下面以典型的销售订单来阐述如何基于业务模型来生成多维模型。
销售订单的业务实体模型可以简化如下：
基于业务关联模型，我们能得到如下关联图：
以上述业务模型为基础，我们用树形结构来展现该业务实体，实体上的字段的关联关系在树上表现为节点展开关系，即 字段展开后加载该字段上关联的目标实体的所有字段。如此，我们得到如下树形结构，
用户在设计报表时可以使用该业务实体树上的任何字段。每个字段在该树上都有唯一路径。如果用户在行列轴上使用了如下选中字段：
我们可以用如下表达式来表示上图选中字段的路径：
业务员 . 所属部门 . 所属公司 . 公司名称
我们可以把此路径理解为一条分析路径，即维度。该路径上的每层节点即表示了级别。据此路径，我们得到该维度的三个级别：“公司”，“部门”，“人员”。每个节点的展开关系表示的是业务实体间的关联关系，在 sql 中表现为 join 。如此，我们可以得到如下查询语句：
select 人员 id ，人员名称，部门 id ，部门名称，公司 id ，公司名称 from 人员表 join 部门表 join 公司表
我们可以把上述查询语句作为该维度的维表来使用， select 部份的字段分别对应不同的级别：
公司 id ，公司名称 对应级别“公司”；
部门 id ，部门名称 对应级别“部门”；
人员 id ，人员名称 对应级别“人员”。
由此，我们即得到一个完整的维度定义。
指标一般选取事实表中的数值字段，如为树展开字段，处理方式与上述一致。
根据上述规则，我们即可根据用户选取的字段来构造完整的多维立方体模型。具备了数据、多维模型这些元素，我们就可以进行下一步的分析处理 。
