建模的技巧及优化_小七_新浪博客

建立模型应该考虑的几个问题

数 据仓库建模质量直接影响数据仓库项目的质量，甚至成败。在进行建模之前，要对数据仓库的规模、组成及模型不同部分的功能定位有明确的定义。影响数据仓库建 模的因素众多，且根据不同项目的具体情况而变化口下面的几个问题是较为通用和常见的，远远不是建立模型应该考虑的全部问题。

数据仓库的业务特点对建模的要求

1 数据仓库的数据组织是面向主题的，而不是面向报表的

数据仓库是面向业务分析的主要主题领域的，进行形成数据模型的定义。典型的主题领域主要包括:

· ·顾客购买行为

· ·产品销售情况

· ·企业生产事务

· ·原料采购

· ·合作伙伴关系

· ·会计科目余额

要 对现有的报表需求进行细致的分类、分析和调整，不能为了实现单个报表而进行大量的建模工作。要根据分析的不同内容和主题对报表进行分类，明确报表中每一个 数据的定义、统计口径及不同数据之间的关系，建立在整个数据仓库内统一的数据指标的定义，将数据指标按分析主题及分析维度进行归集，从而形成面向主题的数 据模型。

例如：我们的利润表报表，当业务部门发我们一个利润表 的报表，作为需求时，我们应该进行细致的分析，最终我们确定我们面向的主题不是利润表，而是比利润表更大的一个层次的所有科目业务量的主题，这样我们在做 别的报表，例如资产负债表，现金流量表等报表时，就不用重复建模的工作了，做到了软件工程中的可重用规则。

2. 数据仓库要实现对数据的集成与数据的同构性

3. 数据仓库数据的相对稳定与为实现应用而进行的实时读写操作

往数据仓库里实时写数据就是不可避免的， SAP BI 也提供支持这种处理的数据对象，如实时信息立方体、汇总级别等，并提供相应的管理机制保证数据的一致性。在建模的时候要好好考虑只读的对象与可写入的对象之间的关系。

4. 数据仓库反映历史变化与及时准确的数据处理能力

数据仓库的数据库设计原则的要求

1. 星形结构，实现简明的数据设计模式

2. 数据参照完整性，保证数据的一致性

3. 利用索引，提高查询的处理速度

4. 先去索引、后加索引，提高数据装载效率

5. 自动校验，保证数据的高质量

SAP 商务智能项目实战过程和方法

收集客户需求信息

1. 组织结构

2. 客户最需要分析的数据指标

3. 数据指标的数据来源

4. 对数据指标的多维分析对象

5. 数据指标的优先级

6. 权限要求

收集客户需求的方法

1. 面谈

2. 问卷调查

3. 报表样例分析法

分析客户需求，形成多维分析模型（逻辑建模）

· 实体-关系模型

· KPI与分析维度

一 般情况下主题和属性之间的关系是一对多的关系，通过诸多属性的描述，可以得到客户等对象的最详细的信息。但是有些情况下，也有存在多对多的情况，如一个产 品有多个颜色等，这种情况下，我们设计时，要把他们作为独立的两个特征同时出现在维度表中，也是视实际的关系采用组合属性，时间相关的属性等方法。如例子 中的一个人在不同的时期属于不同的地区，这就是多对多的关系，所以采用了时间相关的属性。

将逻辑模型变成物理模型

利用业务内容（bi content）加快建模进程。

直接从系统中现有的模型来建模和扩展。

多层逻辑模型与BI中的建模技巧

对于大型的数据仓库系统，简单的数据获取、存储及展现的架构是远远不能满足需求的。

大型数据仓库项目的建设，需要对将数据仓库中不同数据的功能与定位进行细分，根据其功能不同，分别采取各种建模方面和技术方面的性能优化措施。

企业数据仓库与数据集市

在企业级的数据创建建设方法上，存在着两种不同的建设思路。其实这两种建设思路并不是绝对对立的，利用SAP商务智能的配置功能，可以构建更为灵活的多层次的数据仓库结构。

1.两种建设数据仓库的不同思路

一 种是有Inmon提出的企业级数据仓库模型。主张采用第三范式（3NF），先建立企业级数据仓库，再在其上开发具体的应用。其优点是采用了第三范式，数据 存储冗余度低、数据组织结构型好；同时反映的业务主体能力强，具有较好的业务扩展性等。这种建设思路不足的地方时数据表是数据表之间的联系比较多，也比较 复杂，跨表操作多，查询效率较低。由于数据模式复杂，不容易理解，不利于维护。系统建设过程长，周期长，难度大，风险大，容易失败。

另 一种思路是有Kimball提出的多维模型。他主张降低范式化，以分析主体为基本框架来组织数据。其优点是以多维模型开发分析主题，查询速度快，做报表也 快，同时可以实现快速实施，迅速获得投资回报。再在各个分析主题的基础上循序渐进，逐步建成企业级数据仓库。这种主张融合了自下而上和自上而下两种设计方 法的思想，但是需要对数据进行大量的预处理，建模过程相对来说就比较慢。由于数据是按业务主体组织的，当业务问题发生变化，维的比搬动复杂、耗时，而且信 息不够全面、系统欠灵活、数据冗余多。

这两种思路的区别是建设企业数据仓库与数据集市先后次序的区别。这种区别说明了数据仓库不同部分的构成是需要进行功能划分的，建立具有不同的分层的数据仓库系统是大势所趋。

2.具有多层结构的数据仓库系统

从 技术上来说，SAP BI支持建立具有多个层次的数据仓库系统。在软件方面，它提供了技术性能各异的多种数据对象，可以构建不同的逻辑层次；在硬件方面，支持应用服务器与数据 库服务器的动态扩展及根据性能需要进行不同的参数设置。SAP BI 支持建立多个逻辑数据层次，这有助于提高模型设计的灵活性、可以利用同一套数据实现和管理多个不同的需求。BI 的多层建模及在各个模型层次的一些建模技巧，如图。

从数据的存储逻辑上看，图中包含5个逻辑层。

数据抽取准备区

这 是原始明细数据层，这是保存源系统明细数据的存储层，可以使用BI的PSA构建这个层次；每一个PSA表对应着源系统中抽取数据的一个数据源，PSA的表 结构和数据源的结构一一对应，这一层次的数据通过SAP或非SAP的工具实现上传，基本上是各个源系统的副本，没有过多的修改和筛选，为数据的抽取和进一 步的转换作准备。

（2）运营数据存储

这一层次的存在主要是为了满足从BI中出具运营层面的报表。运营报表查看的数据一般是比较明细的数据，对时效性的要求也比较高，所以这一层次的数据相对来说更新频繁，数据比较不稳定。可以使用BI的DSO来构建这一数据层。

（3）企业数据仓库层

这 是面向主题的储存的明细数据层。这一层次的数据主要保存历史的、稳定的、明细的、整合的数据，可以使用DSO来构建这个层次；数据从PSA层向这一层次根 据不同的业务主题进行归集。每个DSO集成了来自不同的源系统的同一业务主题的相关数据。在这一层次上，对不同来源的数据进行整合，对源系统间的数据进行 校验和统一，形成全系统内数据的一个统一的平台。

（4）数据集市层

这是一个面向应用的、具有多级汇总特性的多维分析层，他主要面向业务部门、数据时经过聚集和整合的，可以使用BI的信息立方体及多种虚拟对象来创建。这一层次的数据是根据应用的要求进行不同级别的汇总的。处于应用的需要，还需要在各种汇总级别上搭建跨主题的联合查询。

（5）信息的发布和访问层

这一层包括分析、报表、合并、计划等应用，是提供给各个业务部门使用的，通常使用数据集市或DSO对象来实现。

总体而言，为了定义数据对象之间更明确的逻辑关系，数据的流向是从下至上，在多个层次间流动的。但在技术上并没有限制，各个对象之间的数据流动是可以灵活定义的。SAP BI为多层数据仓库模型的构建提供了相应技术以及构建这些数据层次的各种数据对象。

3.各个逻辑层共享主数据

正如前面提到的，信息对象是SAP BI中的基本单位，上述的所有数据层都是使用信息对象构建的。所以在整个系统建模中要通过信息对象共享性，保证不同数据存储模型的数据水平方向一致性，减少数据冗余。

（1）使用业务内容

应该尽量采用SAP预定义的业务内容来构架数据模型。急于SAP BI的业务内容提供的数据模型进行整体设计。

SAP 预定义的业务内容涵盖了所有的SAP产品中的所有主数据、数据模型、抽取程序、报表等定义，可以加快整个项目实施的进程。业务内容是基于SAP所有的产品 模块进行整体设计的，所以在整个设计中保证了设计的继承性和产品的延续性。业务内容不仅包括SAP的产品的，还囊括了一些非SAP得产品， 如：Oracle的财务系统、Siebel的CRM系统等。

（2）统一主数据设计

统一的主数据信息对象的设计，以保证所有R3系统和非R3系统数据的一致性。

在 SAP预定义的业务内容中，已经定义了丰富的信息对象，但是，在实际的实施中，还是会发现已有的SAP预定义的信息对象不一定能够覆盖整个企业的应用需 求。如果SAP预定义的信息对象的特征无法完整地描述用户所需要的信息，建议对信息对象进行有效地扩充，以满足用户的分析需求。如果需要的信息对象不在 SAP预定义的业务内容范围内，建议对非SAP得应用系统应该进行一个统一的，全局的规划和设计。

（3）保证设计的灵活性

主 数据整合是一个渐进的过程，在设计中应保证足够的灵活性。并不是所有的主数据都需要整合，而且主数据的整合过程也是一个渐进的过程，所以，应该在设计初始 阶段采用灵活的方法，以支持主数据整合渐进的过程。一种常见的方式就是先把主数据上传到DSO，再将上传到信息对象进行整合。

下面将就各个逻辑层次的建模特点及技巧做进一步的探讨。

数据集市层的设计技巧与实例

数据集市层往往是基于一定的范围或某个业务部门的应用需求，要求模型能支持多维的分析，能够对历史数据进行有效分析，同时要保证数据的一致性、有效地控制数据冗余。这些多是设计数据集市时要考虑的关键点。

使用虚拟信息提供者

可以利用BI中的各种虚拟的信息提供者来把不同的数据对象，如DSO或信息立方体的数据融合在一个虚拟的信息提供者中。在信息立方体中存放基于关键指标的聚集数据，在数据存储对象中存放详细的业务数据。通过追溯的功能，可以浏览不同阶级的聚集或明细的数据，如图所示。

这 样设计可以保证汇总数据与详细数据的一致性，提高了数据的访问的效率，降低了数据的冗余，在新的项目或创建洗新的应用时，对已有的成果进行回顾和评价分 析，以便在以前的项目成果上进行设计和构架（如通过多信息提供者），以满足新的需求，而避免出现为了一个报表而设计一个信息立方体的情况。这样做在减少数 据的冗余，减少重复设计的冗余的同时，也降低了数据集市和报表的管理难度。

大数据量时尽量对信息立方体的使用物理分区

物理分区就是将数据库表分成几个小区存储，在逻辑上还是一个数据库表，对用户来说是透明的。

适用数据库

物理分区时给予数据库特性使用的，适用于如下数据库。

范围分区：oracle Informix，IBM DB2

哈希分区：IBMDB2

启用分区

BI充分考虑并使用了数据库物理的特征，用于提高存储性能。在BI中物理分区有一部分是有系统自动优化的，也有一部分需要有模型设计着进行手动配置。

自动分区。以范围分区为例，系统在下列情况下自动对物理表进行分区：

信��立方基本事实表：系统自动按照请求，即对上传的数据包进行分区。

PSA表：同上。

DSO的更新记录：同上。

用户自定义分区：用户也可以自定义分区。比如对于信息立方体的聚集事实表，用户可以指定分区方法。

点击跳到：

在这个窗口中可以按照时间特征进行分区。

使用物理分区可以明显地提高数据存储与访问的性能，有利于系统实现并行处理分区，每次查询只读取较小的数据集，在进行数据删除时可以快速删除分区。

大数据量时尽量通过多信息提供者，实现逻辑分区。

逻辑分区实现示例

通 过多信息提供者把大数据分割成小的数据分区，可以按照不同的年份，计划/实际，区域，业务区域等进行数据分区。如图所示为一个常见的例子，可以按照不同的 地区将数据存储在3个结构相同的信息立方体中。如果需要进行全局的查询，再使用多信息提供者将3个分信息立方体联合起来。

逻辑分区的优缺点

这样设计的思路和物理分区有异曲同工之处，如果逻辑分区得当，可以实现以下优点：

查询的执行分布在不同的信息提供者，减少了运行时间。

下层的单个信息提供者比一个大的信息提供者在设计上更简单。

不需要付出额外的数据存储空间。

可以对单个信息提供者实现同步进行数据上传。

对于报表设计来说是透明的。

可以对单个信息者进行归档比较容易。

当然，这样设计也是有代价的。比如，由于多信息提供者本身不存储数据，所以无法对多信息提供者使用聚集。此外，虽然这一方案不会增加数据存储空间，但是有额外的I/O开支。

适时地使用行项目维度和“基数高度”标志

行项目维度

我们知道，在一般情况下，信息立方体的维度表存放的是维度ID和多个特征的SID的对应关系，工作SID再连接到主数据。这种设计提高了模型的灵活性。但是在某个别情况下，这种设计不是最优。

如果维度表，和事实表之间有着多对多的关系，那么连接结构如图：

SID表和事实表之间是多对多的关系，因为一个维度中包含很多特征。

如果出现这种情况，就意味着，维度表和数据表几乎一样大，这时候不能在使用星型连接技术连接这些大表了，因为出现了三个大表的多重连接。BI提供了“行项目的选项”，就是说，将维度表示为行项目维度，并且该维度表仅分配一个信息对象，即行项目信息对象。

激 活立方体时，系统不会对行项目维度创建新的维度表，而是将信息对象的SID直接 保存到信息立方体的事实表中，该字段直接指向信息对象的主数据标识符表。换句话说，系统忽略了使用维度表的路线。原来信息块à维度à信息对象，变成了行项 目维度中的信息块à信息对象的链接方式。信息立方体的事实表直接与主数据表的SID关联，而没有维度表，在该行项目维度中只有一个特性。

这样的设计使得在报表运行中，无需大数量的join处理，在数据上传时，也无需通过我维度表来确定维度ID。

“基数高度”选项

这是另一个维度可以设置的属性，当一个维度包含很多条目，或者说具有很高的基数高度时，设置这一标识可以提高性能。一般而言，维度的记录数至少是事实表的记录的20%时，可以设置这一标识。

设置这一标识，系统会自动调整表的物理格式，选择合适的索引类型（根据特定的数据库不同），从而保证在读取维度中的记录时具有良好的性能。

系统实现示例

点击属性

专家建议：事实表和纬度表的大小的比例应该在10：1到20：1之间是比较合适的。

尽量使用聚集，以提高报表性能

聚集的工作原理

聚集是数据仓库经常使用的一个方法。是对信息立方体的数据按照指定的一个子集进行数据汇总，汇总的数据存放在不同的独立事实表中，根据常用的查询种类，一个基本事实表可以设置多个聚集事实表。

在报表运行中，系统自动根据报表的查询维度找到最合适，也就是数据量最少的聚集事实表中读取数据。由于数据量的减少，降低了报表的运行时间。也就是说，聚集的设置对最终用户是透明的，用户没有必要关系是否找到了合适的聚集，系统会自动找出相应聚集表。

聚集的系统实现

聚集是在基本的事实表上设置的。可以按照特征建立，可以按照导航属性建立，也可以按照层次建立。

具体操作现场录屏。。

正确划分特征与关键值，提高模型效率

在大部分情况下，主数据和交易数据，或者说维度和关键值是显而易见的，但是主数据也会变化，主数据和划分并不是绝对的，这不仅体现在信息立方体建模上，也体现在特征的建模上。

一个最常见的例子就是商品价格的建模问题，价格是商品的一个属性呢还是一个关键值呢？

将价格作为特征中的属性：

如果商品价格较少变动，而且主要是为了出具报表使用，可以把价格设置成一个导航属性。由于价格只是偶尔变动，一个时间相关的导航属性应该是可以接受的。如果价格用于分析，可以考虑使用一个特征维度或者分类维度（层级）。

如果在报表中药使用商品的价格进行简单计算，可以再查询设计器中使用一个公式变量。

将价格作为关键值：

如果价格经常变动或者需要运用这个来进行大量计算，还是建议设置成关键值。

利用关键值的属性和设置，采用正确的方法以满足数据计算的不同需求

使用参照值的多种汇总方式

如要计算日均收入等计算，不用专门的计算，使用关键值的属性设置就可以了。

由于数据集市层直接面对着复杂多变的业务变化和需求，因而它的设计也最为复杂多变，既要考虑到存储和报表的功能，也要充分满足业务的需要。

企业数据仓库层的设计技巧

企业数据仓库层是面向主题的存储的明细数据层。这一层的数据主要保存历史的，稳定的，明细的，整合的数据。作为数据仓库层，对于不同来源的数据进行整合，对于源系统间的数据进行校验和统一，形成全系统内数据的一个统一平台。这一层有着明显不同于数据集市层记得建模目标。

企业数据仓库层的建模目标

实现“真相的唯一性”，所有的数据必须经过数据仓库层，才能进步数据集市层，进入具体的各种应用，这样可以保证所有应用的数据都是一致的。

保 证数据的完整性，基于数据仓库层的数据是明细数据，重要的数据往往具有很强的分析意义，在从业务系统向BI系统进行数据更新时，不应该对重要信息进行覆 盖，从而应该增加新的数据版本，从而保存不同的时间点的数据。这样一旦出现新的应用，可以保证数据仓库层可以满足其数据要求，而不再从原系统进行数据抽 取。

实现有效地控制数据的抽取和准备。比如：实现一次抽取多处使用，避免数据冗余。

可重用性和灵活性。

实现数据集成性。

企业数据仓库等的主数据建模

重要主数据

对 于重要的主数据，尽可能的保存历史数据以便数据的灵活分析。来自不同业务系统的重要主数据，应该先通过DSO再进入相应的主数据信息对象。例如：有个 特征在业务系统中曾于2007年4月30日将属性从x修改成y，为了保存完整修改的记录，在数据仓库中可以通过DSO对象保存不同时期的数据版本，再通过 DSO对象更新BI中的信息对象。

非重要数据

对于非重要数据可以直接从原系统上传到主数据信息对象中，不保存中间的修改版本。

企业数据仓库的业务数据建模

数据存储对象的划分

首先是DSO的划分问题，划分几个DSO？如何划分？

一般情况下，可以按不同的业务主体划分DSO。

数据粒度的选择

选择合适的数据对象类型

在企业数据仓库层，使用较多的是数据存储对象DSO。

1.4运营数据存储层的设计技巧

运营数据存储层是比较特别的一个数据层，它的存在主要是为了满足从BI系统中出具运营报表。

运营数据存储层的建模目标

运营数据报表不同于一般的分析报表，具有自己的特点：

需要明细的数据展现；

数据时更新覆盖的；

面向操作人员的；

频繁地数据上载；

从 上述特点中我们不难发现，运营数据存储层与BI的企业级数据仓库上存在较大的差异。同样是明细的数据，但是数据仓库层的数据主要保存历史的，稳定的数据， 而运营数据报表需要的数据时近实时的，要频繁的更新的。一般而言，运营数据层的数据时经过加工的数据，并且是基于具体的项目需求而设计的。

信息立方体的优化：

SAP BW的各信息提供者中可以说最重要的就是信息立方体，因为它是分析报表最主要的基础。而对于信息立方体模型，最重要的莫过于维度的设计，它不只决定着查询 的性能，而且会影响到数据上传的时间。一个好的设计方案，不只能提高查询的访问速度，而且可以大大降低把数据更新到信息立方体的时间。

在信息立方体的设计中，如果能够遵循下面的这些基本的原则，那么你就可以构建一个相对高效的信息立方体模型：

1 不要把查询用不到的CHARACTERISTIC放到信息立方体中。

如 果一个CHARACTERRISTIC不会被查询用到，而且你也不能确定它一定会在以后的查询中用到，那么就不要把它放到信息立方体中。因为信息立方体中 每多包含一个特征，它的查询性能和数据上传性能就会降低一分。对于一个多层的数据仓库架构来说，我们常常把这种特征放到中间层的DSO中。这样一方面不会 影响到信息立方体的性能，另一方面，当后续开发的查询用到这个特征的时候，我们可以重新把它加入到信息立方体中，然后从DSO上传数据到信息立方体。由于 它的信息已经存在于DSO中了，我们不需要重新从源系统抽取数据，避免影响到业务系统。

2 对于NAVIGATIONAL属性和特征，前者有利于数据上传性能，而后者有利于报表性能。

这 个很好理解。但是它们还代表了不同的历史事实性。对于特征来说，它代表的是业务发生时候的历史事实。而NAVIGATIONAL属性代表的是当前事实或者 某个指定时间的历史事实。比如如果你把物料甲的物料组建模为一个特征，那么基于它的报表显示的是业务发生时候的物料组。不管物料甲的物料组在这笔业务后有 没有被修改过，报表数据都是基于这笔业务产生时候的物料组显示的。如果你把物料组建模为属性，那么非时效属性对应的是当前的物料组分派，也就是说不管物料 甲在一笔业务发生时候的物料组分配是什么，报表数据都是基于当前分配的物料组的。而时效属性则对应于某个指定时间的物料组分配。

3> 尽量减小维度表。

对于普通的维度，它的索引类型是BIT-MAP索引，降低维度表的大小可以大大提高BIT-MAP索引的性能，进而大大提高报表性能。另外合理的维度设计可以大大减少数据上传过程中维度ID的生成次数，提高数据上传性能。

04> 减少维度数，但是减小维度表更重要。特别是当两者冲突的时候。

5> 对于高CARDINALITY的特征来说，比如销售订单号，我们应该使用LINE ITEM维度。

[0 普通的维度是一个扩展了的星形结构，中间是事实表，事实表首先关联到维度表，然后经过维度表关联到主数据表。而对于LINE ITEM维度来说，它没有中间层的维度表，事实表直接和主数据表关联。这样执行SQL的时候，可以减少一个JOIN。

6> 对于高CARDINALITY的维度来说，我们应该使用B-TREE索引.

普通维度的默认索引时BIT-MAP，如果一个维度表太大，那么BIT-MAP索引的性能会大大降低。 这时候我们应该选择使用B-TREE索引，也就是将一个普通维度改为HIGH-CARDINALITY 维度。

07> 如果一个信息立方体的特征数小于等于13， 那么你可以去掉推荐架构中的维度表这一层。将所有的特征建模为一个LINE ITEM维度。