一、概述
深刻掌握技术原理，了解系统的基本的实现过程，有助于快速、准确地锁定技术问题的出处，高效地解决项目中遇到的各类技术问题。在本文中，我们将试图分析与InfoCube模型对象相关的部分技术原理并提出一些设计原则。
二、Info Cube的存储结构
在BW系统中，InfoCube采用扩展的星型模型来存储业务数据，业务数据按照请求号分组上载到InfoCube中，这些数据首先存储在一张事实表中，我们称此事实表为F表。当对某一请求进行压缩操作时，系统会从F表中将这部分数据压缩，并转储到另一张事实表：E表（该表主要用来存储经过压缩的业务数数据）。E表和F表的定义完全相同，下图为事实表定义示例：
InfoCube的事实表中并没有直接将所有的特性字段作为事实表的主键，而是采用了dimension ID字段，每一个dimension ID字段均是与之相对应dimension table的主键。在dimension table中，除dimension ID字段之外，另有在建模时分配给该维度的各个特性字段。其对应关系如下图所示：
每一个InfoCube最多有16个维度表，其中有3个是系统自动产生的：PACKAGE维度，TIME维度，还有UNIT维度。在维度表中，BW并没有直接将特性值存储在dimension table中，而是采用了SID (surrogate ID)来代替维度值，而SID与特性值的一一对应关系存储在特性的SID table中，BW正是通过SID将主数据、特性值、层次结构、文本与维度表相关联。
三、InfoCube所采用的存储结构的优点
1、引入维度表，可以适当消除数据冗余。
在某一维度表中，所有特性值均相同的数据记录只存在一条。当在事务数据中出现多条该记录时，只需要在事实表中重复存储dimension ID，而不需要重复存储该维度包含的所有特性字段。
2、引入SID，可以提高查询效率。
系统在上载数据时，将特性值替换成系统类型统一、自动编号的SID(整型)，节省存储空间，在检索数据时，所有的检索条件均转换成为对整数SID的检索，相比于字符型等其他类型而言，检索效率大幅提升。
3、维表主键全部采用整数类型，节省存储空间(提高缓存利用效率,减少磁盘访问量)，提高检索效率。
4、引入维表，可以减少数据存储空间,提高缓存利用效率,减少磁盘访问量。
四、事实表的索引结构
1、 Bitmap索引结构简介
BW系统为事实表中的每一个维度自动创建一个索引。在基于Oracle数据库的BW系统中，最常用的索引结构为Bitmap索引。针对下表Cost Center列，我们举例简单说明Bitmap索引结构的生成过程。
|
Id（key） |
Cost Center |
Flag |
|
1 |
2100 |
X |
|
2 |
3100 |
X |
|
3 |
1000 |
|
|
4 |
4100 |
X |
|
5 |
2100 |
|
|
6 |
1000 |
X |
1) 首先列出当前表中索引列的所有可能值，将其作为索引的关键字
Cost Center：2100 3100 1000 4100
2) 按位为每个关键字建立基于布尔值的顺序存储结构。在顺序结构中，每一位上的可能取值：1代表记录的相应列值等于该关键字，0代表记录的相应列值不等于该关键字。例如Cost Center列的第一条记录值为2100，则关键字2100的顺序存储结构的第一位为1；第二条记录为3100，则关键字2100的第二位为0。按照同样的逻辑，可以得到关键字2100的顺序存储结构为：1 0 0 0 1 0。依次对表中每条记录进行判断，可以得到每一个关键字的顺序结构，即得到索引结构。
2、 基于Bitmap的数据检索
当检索所有Cost Center=2100的记录时，只需在索引结构中查找到2100对应的顺序结构，便能得到所有包含2100的记录在表中的分布情况。当检索Cost Center=2100或者3100的数据记录时，可以将2100和3100对应的顺序存储结构做或运算，得到：1 1 0 0 1 0，便得到该检索条件下所需记录在事实表中的分布情况。
3、 Bitmap索引效率分析
依据上文介绍的索引结构的生成过程，我们知道，在事实表中，某一维度列的索引关键字是它在表中所有的可能值。因此，该维度的索引结构中的关键字的数目与它的Cardinality值相等。当某一维度的Cardinality值太大，甚至接近事实表中的记录数时，索引结构的关键字数目也同样会很大。此时，在索引结构中查询关键字时，也需要检索相当数量的记录，这与在表中直接查询相比，效率上不会有太大的提升，反而会造成索引结构过大。因此，对于Cardinality值太大的维度，不适合采用Bitmap索引结构。
4、 事实表适用的索引结构
BW系统中，事实表中大多字段的值的重复率很高，同时在报表查询应用中，基本不会涉及逻辑及其复杂的检索条件，大多是只针对表的某些字段取值进行限制的批量查询，这使得采用Bitmap索引结构（典型的一对多索引结构）比其他索引结构（例如B-Tree）更加符合BW报表的应用需求。但是，除Oracle之外多数数据库均不支持Bitmap索引。若BW系统采用Oracle数据库，则系统中维度的默认索引类型为Bitmap。
五、High Cardinality和Line Item Dimension
依据上文所述，BW系统中维度默认的索引类型为Bitmap，但对于 Cardinality值太大的维度，并不适合采用此索引结构。BW系统中提供了相应的机制，允许为Cardinality值太大的维度创建非Bitmap类型的索引结构（例如Oracle
中采用B-Tree）。在InfoCube系统中创建新维度时，选中High Cardinality，示例如下图：
对于维度而言，BW系统还提供了Line Item机制。在创建维度时，选中Line Item Dimension，系统会在生成事实表时，直接使用SID字段来关联该特性的特性值、属性、文本、层次等数据，中间没有通过维度表关联SID，这种机制使得Line Item维度只能包含唯一的一个特性。
六、维度的设计原则
为了使设计的InfoCube性能更高，基于对其存储结构和索引结构的特点的认识，我们可以总结一些设计原则。若系统采用Oracle数据库，在设计维度时，可以遵循以下几点（在具体环境中有待于进一步考察）：
1、尽量减少维度包含的特性，使得该维度的Cardinality值较小，发挥Bitmap索引的性能优势。
2、对于无法避免的高Cardinality值的维度，将其设定成为High Cardinality维度，为其建立非Bitmap索引（例如B-Tree）。
3、若维度的数目有余，将类似于“Sales Number”这样高Cardinality值的特性设置成为Line Item Dimension。
4、若除属于PTU特性的特性之外，其它的特性总数小于13，且明确以后没有增加维度的需求，可将所有的维度均设置成为Line Item Dimension。
5、对于类似于“Sales Number”这样高Cardinality值的Line Item Dimension，同时将其设置成为High Cardinality维度。