转自：http://www.iniu.net/iwork/2008/01/hyperion-bi.html
在配置Hyperion的测试环境的时候，感觉相比较Oracle以前的Oracle DB（可能包含OLAP）+OWB(或ODI)+BIEE方案而言，Hyperion的产品看起来要更加复杂一些，而且每个产品都是独立的安装介质，我开 始创建完essbase数据库和安装完smartview for office之后，发现excel怎么样都无法连接到我已经创建的essbase数据库，后来看了一些材料才知道还需要安装essbase provider服务进行provider配置才可以。所以本文的目的是解释Hyperion的各个必要的组件来介绍如何能够搭建一个可供自己学习使用的 essbase的设计和测试的环境。个人觉得使用excel来操作essbase是最直观最好用（大部分业务人员的最爱）的方法，所以本文介绍的是如何能 够开始进行essbase的OLAP设计和如何能用excel来查看操作和使用essbase里的数据。
需要安装什么？
根据我们的目标（能够进行essbase设计和使用excel进行数据操作），首先需要安装一个关系数据库产品（如 Oracle，SQLSERVER等），Hyperion需要把自己的一些产品的组合配置信息存储在关系数据库里，这个数据库需要先建立好一个用户和密 码，到时候需要输入到配置界面里（需要连接数据库的配置界面主要有两个地方，一个是配置shared service的数据库配置，另一个是安装reporting and analysis service的时候的进行配置）。
Hyperion整个安装首先需要安装的是shared service（除了数据库，其他部件的安装次序不是非常重要，因为安装完后才需要使用configuration utility进行配置，而且也可以选择安装了但先不配置，等到最后依次做配置）。这部分属于Hyperion模块的一个公共部分，shared service主要完成的功能是用户的管理，即注册到shared service里的模块都可以使用shared service进行统一的用户管理。
安装完shared service的时候可以发现会出现openldap模块和Apache tomcat模块（当然shared service可以选择被部署到weblogic或者其他商用应用服务器上），openldap模块被用于内置用户的管理，即通过shared service创建的用户可以被放在openldap里，当然其实Hyperion的用户管理也可以集成外部的ldap的用户。
下一个需要安装的就是我们做分析的核心服务essbase（又称之为analytic service），windows平台的安装就是跟着向导一个劲地点下一步！
然后还需要安装analytic administration service，这个是essbase的一个图形界面（管理控制台），对于essbase数据库的创建，对于多维模型的创建，配置数据的加载，建立计算脚 本等都是通过administration service的console进行的，安装完这个服务之后就可以使用console开始进行多维模型的设计了。
一开始觉得奇怪的是如果需要通过嵌在excel的smart view来查看到essbase里的数据，则还需要安装一个provider服务，然后通过console配置添加provider服务之后才可以通过集 成在excel的smart view去通过provider来查看和操作数据。当然，如果是通过安装essbase客户端来集成excel的话则就不需要安装这个provider服 务了。
需要说明的是上面这些安装都有自己独立的安装文件，需要一个一个单独安装，那么这些模块安装好之后如何连起来使用呢？比如说既然每个模块安装的顺序可以不 固定，如何让这些模块中一起使用相同的用户进行管理呢？答案是通过configuration utility工具，这个配置工具可以配置具体的模块向shared service进行注册，注册之后的模块就可以通过shared service进行验证了。如下图（点击查看大图）：
是一个configuration utility的配置界面，除了shared services，其他每个模块都需要配置成注册到shared services里，整个配置过程还是比较简单的。对于这行图形的配置方式不习惯的地方是，如果配置出了错，就比较难以解决，我觉得要是提供手工的修改一 些配置文件的额外方法，对于配置的查错可能会更容易一些！
通过运行配置工具就可以完成各个独立安装的各个模块之间的一个连接配置，我们所说过的组件就可以配合在一起使用了。这个时候我们就可以开始进行多维分析设计和使用excel进行数据的录入或者分析了！
对了，记住缺省的admin console的用户名是admin，密码是password，一开始我找了半天都没找到，还是问了人才知道的，简直是什么事呀，需要注意的是安装 essbase的时候会提示输入另外的用户名和密码，那个是属于essbase数据库的密码，和管理密码是两回事，比如在配置excel连接 essbase的时候，输入的是essbase数据库的密码而不是admin！
额外BI模块的安装
虽然安装完上面的模块就可以进行简单的essbase验证了，但是事实上一个完整的bi环境是还需要安装BI展现工具的，9.3.1的 Hyperion版本的的所有BI工具都已经整合在一起，统一叫做reporting and analysis，包含了以前的brio（现在叫interactive reporting），financial reporting，web analysis等工具，安装的时候会安装在Hyperion Home的BIPLUS目录下，也就是Hyperion以前称之为BI+的工具包（现在全部合并到Oracle的BIEE里统一叫BIEE PLUS），BI+的总体结构如下图：
主要分为web client端，Web服务器端和service端也是多层次的结构，不要以为我这里说的都是理论上的东西，其实安装的时候各个层次连安装介质都是分开 的，撇开web client端不说（因为有了web服务器的内容，就自然能够产生web客户端的界面），Web服务器上要安装reporting and analysis的UI层（是单独的安装介质），然后还需要用另一个介质安装reporting and analysis的service层（也就是上图的foundation service）；最后不能不提的是，你还需要安装一个客户端的开发环境（就是图上左下角的studio），用studio开发的东西（比如bqy文 件），就能够部署在整个BI+运行环境里供用户访问。
前面说了BI+是包含了报表和分析等多个产品的一个BI包，这些产品都可以通过workspace来统一进行访问，这个就是原来Hyperion集成多个工具的一种方式，可能Oracle以后也会这么做吧
转自：http://iniu.net/iwork/2008/01/hyperion-essbase.html
Essbase的名字其实是Extended SpreadSheet dataBase。
这个大概是为什么essbase能够和 excel工具深度集成的原因，因为essbase很多设计都是来源于excel等工具对于分析的限制和不足。但是excel不失为essbase的一个 非常友好的前端，对于非常习惯使用Excel工具的业务人员，他们可以非常容易地使用和分析essbase里的数据，Oracle里关于Essbase卖 点的一个经常使用的场景是：当业务人员把数据放在多种表格的时候，到了最后他都不知道哪张表格的数据是最新的，而如果把所有的数据都放在essbase里 的时候，你可以轻易地得到最新的数据并且分析数据和数据之间的关系。（大意是你可以把essabase想像成多张叠起来的excel表格，不仅仅在单张excel上可以进行表格之间的各种运算，在多张excel表格之间也可以做各种累计运算！）
Essbase的一般设计
对于MOLAP数据库一个通常的观念是MOLAP不能存储很大的数据量，当essbase以BSO（块存储）来存储多维数据的时候（传统方 式），则称之为Essbase Analytic module，这种传统方式对于维度数据非常多，数据量非常庞大的时候的处理性能一般，这个也是造成许多人认为MOLAP多维数据库不适合分析非常大量的 数据的方式的缘由，但是BSO存储方式能够更好地支持大量回写的应用，如what-if分析，并且能够提供更好的分析功能。
当数据量很大或者多于10个维度的时候，essbase建议使用ASO聚合存储方式来压缩存储的数据（据说性能在这种方式下能够快几十倍，而存储量能减少 几十倍），使用这种存储方式就称之为Enterprise Analytic Module，从而提供了修正这种MOLAP大数据量限制的很好的方式。这种存储方式用于分析维度数量比较多，同时并非每个维度的数据都很稠密的时候是性 能会非常好，可以处理大量的数据，这两种不同的存储，对于上层应用透明，在同一个应用里可以混合使用。
多维数据库的设计（维度和度量）在essbase里称之为outline，以.otl的后缀存储，一个典型的多维数据库设计过程是包括：先需要通过admin console创建一个outline。
在outline里定义维度和层次和累计方式，然后就是通过admin console编辑数据加载规则来把外部数据按照设计好的outline加载到essbase数据库里。（其实essbase提供了非常丰富的api接口，也可以使用api来创建和修改outline）
加载规则基本上有三种方式：
然后使用计算脚本计算生成立方体里的其他所需要的数据，就可以通过excel或者BI工具来访问和分析多维数据库里的数据了。
- 一是通过文本文件加载。
- 二是通过Open sql的方式从ODBC数据源加载。
- 最后一种是使用ETL工具进行加载。
转自：http://iniu.net/iwork/2008/01/hyperion-essbaseessbase.html
Essbase已经根据大部分多维模型项目的需要，归纳出一些在大部分项目都需要的特殊维度和属性，提供了预定义的这些 维度和属性的行为，这是essbase的一个很大的特点，只要根据不同的需求去选择不同的维度类型和维度属性，就能够自动产生许多针对该维度类型相关的分 析。这个特点也是熟悉其他OLAP产品的人学习Essbase的一个主要疑惑，就是为什么Essbase的教材总要花很多时间去交代各种各样的维度类型和属性。
这些预定义的维度和属性比如：account维度类型（度量）和属性，时间维度和属性，场景维度（scenario）和属性，这些维度在大部分的项目都会用到，并且都是计算密集和分布密集的维度。
Essbase里的第一种特殊的维度也是最复杂的维度是account dimension，account dimension其实是对应了多维模型里的度量，所以属性是和其他维度相差最大的维度类型，它有非常丰富的各种属性和各种各样可定义的行为。
Account dimension主要用于描述销售额，利润，利润率等企业的关键指标，所以多维数据库的设计里需要花许多时间做account dimension的设计。下面是account维度的一些属性的描述：
- 时间余额属性（Time Balance）：
虽然在OLAP运算中大部分用到的是根据不同的层次进行累加，比如一个季度的销售额是三个月销售额的总和，但是对于某些业务概念的表达则不能简单的进行相加。比如存货数量，当一月存货是100，二月存货是200，3月存货是80的时候，则第一季度的存 货是多少呢？很显然并非是这三个月的总和380，而是根据预先的设定是取期初余额，还是取期末余额来还是取平均值来决定，如果是使用期初规则，则这个季度 的存货数量是100，如果是期末规则，则存货数量是80，类似于这种的属性则称之为account维度的时间余额（time balance）属性。
- 费用属性（Expense）：Account Dimension成员里的第二种特殊属性是Expense属性和差异计算：一个成员可以标记为费用属性从而会自动具有财务上费用属性的特征，所谓具备财 务费用上的特征的意思是，对于一个不具备费用属性的数值而言，如销售额，如果销售额从100变为200的时候，这个时候应该是好事，也就是数值上的反应应 该正数，以红色来表示（如果红色代表好的话）；但是对于费用的数值则相反，因为费用从100变为200的时候，实际上对于公司而言并非是什么好的事情，如 果采取和一般数值相同的算法（即200-100=一个正数的100的话），则看起来好像也是好事，而这和实际业务是有冲突的，所以所有费用属性的数值会采 取相反的方式（100-200=负的100），这样就能够很直观地看出来费用实际上是有问题的；当然如果使用别的OLAP来定义出费用属性，你可能就需要 定义一个计算列，这个计算列，这个计算列前面加一个负号来表示费用属性，我们通过这个属性不难看到，essbase在长期的积累中已经出现了大量的现成的 可以使用的属性行为，而这些属性行为都是可以让业务人员很容易理解的。这个费用属性的具体表现还体现在差异计算中，在差异计算比较实际发生和预算数的时 候，当一个维度不是费用属性的时候，如销售额，假设实际是100，而预算数是120，则差异计算 variance=@VAR(actual,budget)计算出来是-20；而另一个维度如果标记成费用维度，则相同的公式给出的数值是20。
时间维度是essbase里另外一个非常重要的维度，一个OLTP和OLAP的主要区别就可以通过时间维度来说明：
在交易系统里我们关注的时间特性是交易发生的时间，如果有两个交易分别发生在是15点10分和15点20分，这对于交易 系统而言是有本质的区别的，但是对于一个以一个小时为最小单位的OLAP的设计来说，这个两个交易是没有区别的，他们同样是发生在15点到16点的这个区 间里，所以交易系统关心时间上的点，而OLAP系统则关心时间的区间。
这个也提出了设计时间维度的一个基本问题就是时间维度的设计的最小的时间粒度应该是什么的问题，是一个小时，一天，还是15分钟，其实这些都取决于应用的具体需要。
比如一个分析一天内超市销售行为的分析系统一个合理的最小单位是半个小时或甚至15分钟，这样的时间区间可以分析出中午 吃饭的时间是不是对于销售额有明显的影响，但是这样的区间对于分析一年销售量随着时间的变化的曲线则没有任何意义，在这样的场景则最小单位取1天甚至1周 更加合适。
时间维度的另一个重要设计是关于年度的概念，可能是因为essbase起源于财务领域有关系，而任何真实公司财务系统都是按照年的概念（财政年度）来分开交易的。
（发生在12月31日--还是今年和1月1日—已经是明年的交易对于财务系统而言有本质的区别，虽然其实他们从某种观点来看不过就是今天和明天的区别）所以essbase里也需要对财务年度的选取有特殊的考虑，最传统的一个设计是在使用一个时间维度的同时，再增加使 用另一个维度来代表年度，这种设计方式就可以完全按照财务的理解来处理年份，Hyperion的财务应用就使用这种设计方式，如下图是按照财政年度来处理 年份的设计：
这种设计的方式可以和财务年度做很好的对应，但是对于分析一些跨年的连续的时间行为（如疾病发生的数量不会和财政年度有什么联系）的时候就不适合了。在这样的情景可能直接使用一个包含年和更细时间粒度的单一时间维度更合适一些，下图就是单一时间维度的典型设计方式：
PTD计算
对于一般的应用而言，PTD（Period-to-Date）等按时间累加到某一状态的需求是比较常见的（如Q-T-D季度当前值，如 果当前是二月份，则计算的时候会把数据求和更新到二月份，等到了三月份再用户再发出同样的请求，则数据就会自动累计计算到三月份），essbase里对于 这种类型的计算也有相应的设计考虑。
Essbase使用两种方式来满足这种设计需求，第一种是通过成员公式（member formula），的方法，如下图：
这种方法对于需要创建QTD的维度而言，创建一个outline里的结构来计算QTD，从上图很容易看出，实际上在该outline结构里已经把组成QTD的各个成员摆在相应的位置来得出QTD的值。这样就可以创建出所需要的QTD或者YTD，这种方式比较繁琐，但是很容易理解，最大的好处是可以完全自己控制累加的方式（可以满足某些特殊的需求，比如如说不想把某个月包含在计算里面）。如QTD Jan下只有一月份的成员，而QTD Feb下则包含一月和二月份的值，这种方式从道理上很容易理解，一般使用这种方式的时候所引用的成员可以使用共享成员的方式引用原来存在的各个数据 （Jan，Feb一般都已经在时间维度上已经存在）。这样设计之后，当在一月份的时候，需要使用QTD Jan成员来得出QTD的值，而在二月份的时候，需要使用QTD Feb成员来得出当时QTD的值，而到了四月份，则QTD的值重新回到包含当季的的第一个月。
第二种得出QTD的值的方式是使用Essbase内置的PTD的功能，这种方式是通过时间序列的定义的方式来实现，仅对于被定义为时间维度的维度类型起作用，通过右键选择“动态时间序列”，则出现以下的选择：
选择所需要计算的的PTD的类型和在第几代的后代上进行相应的PTD计算，则当使用excel来操作的时候，只需要填入Q-T-D，或者Y-T-D就可以 自动得到当前的根据时间更新的累计值,这种方式则是完全由essbase通过定义提供的PTD的功能，只需要做一些定义，就可以实现PTD的各种功能，提 供预定义的行为。Scenario维度和属性
Essbase的另一种特殊维度是scenario维度：scenario维度的主要目的是为了比较不同的数据集的差异计算，比如为了比较 实际发生和预算值，则scenario就会有两个成员actual代表实际发生数据集，而budget则代表预算数据集，这样就可以使用各种方式去分析比 较他们的差异，使用同样的方式还可以进行所谓的what-if分析，比如可以有一个数据集时今年发生数，通过拷贝今年发生的数据集并且相对应的发生乘于一 个系数（比如明年销售额是今年的120%），就可以在这种假设下进行很多计算来模拟各种不同的场景，这些主要都是通过scenario维度来实现的。
转自：http://iniu.net/iwork/2008/01/hyperion-essbase-1.html
如果大家熟悉Oracle的物化视图，就能够很容易理解为什么这种方式能够提供快速计算的能力。因为所有维度都是按照层次关系组织起来的：
比如对于区域维度而言，很显然全国的销售额一定是各个省的销售额的总和，而各个省的销售额一定是下面各地市销售额的总和，这种天 然的汇总关系为实现这种按层次的汇总提供可能性，因为我们通过MOLAP可以很容易计算出各个层次的累计数值，这样做查询的时候就能够很快地把所需要的数 值拿出来（不管你要的是哪一级的汇总）
从这种角度来说，使用Oracle关系数据库来模拟多维数据库是可能的，只要你建立足够多的物化视图，在每一个层次都提供汇总计算，当然这个是理论 上的，真正这么去实现在很多应用里根本就不现实，事实上，我一直在想，物化视图的技术是不是就是受MOLAP数据库的启发产生出来的呢？
理解Essbase计算
多维数据库里的数据有些是从源数据导入的，有些则是运算出来的，比如对于一个最小时间单位为天的分析销售量的立方体，每天的销售量都是从源系统导入 到Essbase里的，但是对于每个月的销售量，则是由Essbase根据更加细粒度的数据计算出来的，所以立方体里的数据在这种区别下可以分为两大类数 据，一类是从源系统导入的，另一类则是Essbase运算出来的，一般而言输入数据都是level 0数据（最低端的叶子）。
由Essbase根据导入的数据再计算生成我们所需要的别的数据的过程称之为calculation，Calculation也分为两种：
第一种方式是按照outline层次预先设定的方式进行叠加（Consolidation operator）。
第二种方式是使用自己写的计算公式进行计算（member formula）。
我们通过以下的例子来说明第一种的计算方式，在outline的设计的时候，一个必须指定的属性就是所谓的指定层次间的汇总关系（Consolidation operator），缺省的汇总关系总是相加，如下图：
计算按照成员出现的次序进行，上图的设计含义是Qtr1成员的值是前三个月的总和（注意成员后面括号里的+号）即：
Qtr1=Jan+Feb+Mar
请注意+号不是唯一能够使用的符号，还可以有-（减），*（乘），/（除），%（百分比）等，比较特殊的是~（排除，意即该成员不参与到运算里）， 这种计算的设计里最重要的是同一层次的成员出现的顺序，因为同一层次的计算顺序是按照出现的顺序来进行，而不是按照通常的运算符号本来的优先次序。
这种基于consolidation操作符进行运算的关系也是推荐的运算方式，因为这种方式可以提供更好的性能，而且对于使用者而言更加直观和容易理解。
Outline里另一种计算是使用成员公式（member formula）来进行，有时候当成员并不是按所想要的次序出现的时候，就需要使用公式去表现成员的关系去计算一个所需要的值，使用这种自定义的计算公式 能够描述更加复杂的计算关系，essbase提供了逻辑测试关系符（if else），各种统计和财务函数来方便计算。
维度计算的优先次序是先计算account维度的值，其次是时间维度的值，然后是计算其他稠密维度上的值，最后再计算稀疏维度上的值。而计算two pass的值则是在其他所有计算都完成之后。
转自：http://iniu.net/iwork/2008/01/hyperion-essbase-2.html
当Essbase里已经有了各种各样的数据的时候，如何使用essbase里的数据呢？使用essbase里的数据有多种方式，既可以通过 Hyperion BI+里的工具产品如IR，PR，FR，WA等来展现和分析essbase里的数据，也可以通过excel等office工具来展现和分析essbase 里的数据，当然，因为Essbase是业界一个很通用的产品，也可以使用很多第三方的软件如BO等来使用Essbase的数据，另一种更加困难但是却更为 灵活的方式是使用api调用的方式去操作Essbase里的数据，这是最困难也是最灵活的操作方式（所谓方便和灵活不能兼得吧！）。
通过Excel来操作essbase的数据又有两种方式，一种是安装essbase spreadsheet plugin客户端（传统的excel客户端），仅适用于Excel工具，另一个方式就是安装Smart View for Office产品，SmartView不仅仅可以用于Excel，还可以嵌在其他MSoffice如powerpoint里使用。
需要说明的是，Smart View不仅可以用于分析essbase里的数据，同时还可以作为一个统一的客户端操作Hyperion的其他应用产品如planning里面的数据。
Smart View architecture
Smart View并非是传统意义上的Excel spreadsheet Plugin的简单升级，因为它完全采用了经典的三层结构（spreadsheet plugin是一个两层结构），如下图（点击查看大图）：
Smart View的发展是Hyperion战略的一个重要部分，客户端虽然是嵌在office产品里的小应用，但是该应用完全使用典型的三层架构通讯协议 HTTP(HTTPS)和应用层交互，应用层已经不是一般意义上的应用服务器的概念，而更多的是指运行在中间层的真正的“应用”的概念（比如 Hyperion Planning应用或者Analytic Service），每一个应用通过一个provider的转换和客户端进行各种交互，从这种思路可以看出来，当将来Hyperion发布更多的行业应用产 品的时候，就可以通过相应的增加provider来使Smart View能够以一种一致的方式使用新的应用。所以在Hyperion System9里，Smart View的目标是能够为所有Hyperion产品提供MSOffice集成操作的统一界面。
举例来说，Smart View客户端和分析服务的交互是Excel把分析命令发给provider，然后provider再把请求转交给分析服务，分析服务完成命令后把结果返 回provider，再由provider把结果返回给Smart View，Smart View再通过Excel把结果展示出来。
SmartView 基础概念
因为Smart View是使用office工具（主要是Excel）来展现多维数据，所以首先需要熟悉的是如何在Excel里来表现多维数据。
什么是POV？
因为Excel只有行和列，所以Excel能够表现的维度最多是两维的，为了表现Essbase里多维的概念，必须想像对于立方体进行 一个切片，一个切片就可以直接平铺在一个Excel里形成一张电子表格，这个就是使用Excel来表现多维的方法，切片的动作是使用POV（Point of View）来进行的，所谓在一个维度上切片，就是在一个维度的一个层次上选定一个特定的值，比如对于区域维度，我们可以选定华东区，或者选定上海市，这样 就是对区域维度做了一个切片动作。
Smart View的数据在跨整个MS Office的产品都是动态的，比如用Excel里的Smart View剪裁出来的数据片，可以使用Hyperion-》copy data在所有Office产品之间进行拷贝，被拷贝后的数据维持和原来同样的Essbase连接，而且可以动态刷新，
Excel操作
感觉Smart View一个超级好玩的功能就是，你可以随便在excel表格里写维度的名称，如下图：
我是随便在excel的行和列上写Product和Year，然后双击表格（就是代表retrieve data的意思），则数据就出来了，如下图：
Excel 的处理是Smart View会把excel表格填入的东西和多维数据库里的维度进行对比，如果找到匹配，就会把相应的数据按照我们所填入的方式展现出来。请注意如果维度的成 员名称是数值，则需要用单引号括起来。对于通常的多维操作的旋转功能只需要按着右键把维度拖动到相应的位置就可以了，还是比较直观的。
转自：http://iniu.net/iwork/2008/01/hyperion-essbase-3.html
要更好地理解Essbase的计算过程，就需要理解Essbase的存储结构，记得以前学习Oracle数据库里内置的OLAP的时候，教材只是交 代了OLAP是以BLOB的形式存储在数据库字段里的，当时对于BLOB里的实际存储结构并没有特别多的说明，但是学Essbase的时 候，Essbase里的确交代了Essbase数据库里存储原理的更加详细的信息，从而也就容易明白为什么稠密维度和稀疏维度对于Essbase数据库性 能和大小至关重要的影响。
立方体里的“立方体”
和通常的关系数据库一样，Essbase使用两种基本的数据结构来存储数据，一种是数据块，另一种是索引，当用户请求一个数据的时 候，Essbase一般而言先通过索引找到包含该数据的数据块，然后把该数据块复制到内存中，来完成数据的处理过程。可是什么是Essbase的数据块， 什么是Essbase的索引呢？Essbase的数据块和索引和普通关系数据库的概念有比较大的区别。这是因为Essbase数据块和索引来源于多维数据 库的“稠密”和“稀疏”的概念。
Essbase的最小的一个IO操作单位是数据块，而数据块在Essbase里的定义则是由所有的稠密维度组成的“小立方体”组成，一个形象化的表 示数据块的例子是当稠密维度只有两个的时候（例子中的稠密维度只有两个，销售数量和时间），则这个“小立方体”则退化为一个Excel表格，如下图：
这个完完全全就是一个数据块在现实中表现出来的样子，也就是一个有两个稠密维度的数据块的真实样子。
一般而言，我们在Smart View操作Essbase的数据的时候通常都是以稠密维度做为行和列来展现Essbase里的数据。数据块又由数据单元（data cell，也就是上图中每一个Excel单元格）组成，每个数据单元包含8个字节的硬盘数据，数据单元里真正存储着维度交叉后的数据值（稠密维度空间的 值）。
不管是否存在数据，任何一个稠密维度空间里的数据单元都是存在的，所以可以想像，当我们在设计不恰当的时候把一个稀疏维度当成稠密维度来设计，就会在这个稠密“小立方体”里留下很多空着的但是仍然占着8个字节存储的空单元格。
那么稀疏维度的作用是什么呢？ Essbase使用所有存在至少一个实际组合的稀疏维度来形成Essbase里所说的索引文件指向由稠密维度组成的“小立方体”，稀疏维度不存在的组合并 不会在索引里存在记录，因而也不会因为大量不存在的值而浪费大量的空间（比如上面的例子假设我们还有两个稀疏维度，一个是客户，一个是产品），则这个由两 个稠密维度和两个稀疏维度组成的多维数据库可以想像成在由稀疏维度组成的二维坐标空间了，稀疏地放着由稠密维度组成的小立方体。如下图：
当Essbase寻找一个数据的时候，先是从由稀疏维度组成的索引里去寻找一个数据块（“小立方体”），然后把这个小立方体拷贝到内存里，最后才真正处理这个“小立方体”里的真正存储着数据的Essbase的数据块。
从这个描述可以看出，Essbase里的数据块和索引的概念和关系数据库很不一样，稠密维度对于Essbase的数据存储至关重要，因为所有具有稠 密属性的维度所形成的一个小立方体就是我们所说的Essbase的数据块，所以一旦一个Essbase的outline设计完成了，也就意味着该数据库的 数据块决定了，数据块的大小是所有稠密属性成员数的乘积。
为什么会这么设计呢，因为Essbase总是希望能够在一次内存处理里尽量处理更多的数据，如果数据块里有很多空的单元（稀疏维度必然导致空单 元），则会大大降低处理效率，但是如果把所有稠密的单元组成的所谓“小立方体“放到内存里，自然而然就可以在一次处理里处理许多数据，这个也是我们设计维 度需要考虑的一个问题，定义一个维度是稠密还是稀疏并不是一件无关紧要的事情，而是会真正对性能有很大关系的决定。如果把一个稀疏维度定义为稠密维度，比 如会造成每一个数据块有非常多的空值，而浪费大量的空间，并且降低数据处理的性能。
没有评论:
发表评论