5.1 SAP BW on HANA 数据建模特性

本章节主要介绍优化理念（optimized concepts）、新特性（new features）、对ABAP开发的影响（impact on ABAP development）

5.1.1 Optimized Concepts for SAP BW on SAP HANA

以前使用infoCube是出于性能的考虑（星型模型和减少数据量）。在SAP BW on HANA中，由于HANA的高性能，我们可以直接从DSO出具报表，它的速度会和infoCube一样快。在做完BW on HANA迁移之后就可以考虑是否可以不再使用InfoCube。如果你主要是基于MultiProviders创建查询，在理想的情况下，你可以很容易的使用数据传输层相应的DSO替代相关的InfoCube。当创建新的数据模型的时候，通常就不再考虑使用InfoCube。

首先，如果数据在DSO和InfoCube中都存在，我们可以删除一些数据量比较大的InfoCube，这样不仅能减少内存的需求量，而且能够减少或者简化运维任务。例如，可以减少数据库备份的时间和备份文件的大小，同时由于可以跳过DSO往infoCube上数的这个过程，从而可以减少BW处理链的执行时间。由于几乎所有的数据都保留在内存里面，巨大的数据量会导致内存的紧缺，必须要升级硬件或者是归档数据（例如使用NLS，近线存储方案），这种情况下，删除InfoCube就可以更加有效的使用内存，释放的内存可以应用于未来的数据增长。

然而，还是有一些原因需要你在BW on HANA的环境下面继续使用InfoCube，例如

• 从使用InfoCube转换到使用DSO需要付出巨大的工作量
• 当数据抽取到InfoCube的时候包含逻辑转换
• 非累计关键值（non-cumulative key figures）的使用，例如库存模块
• BW集成规划模块的实时InfoCube
• 通过RSDRI接口访问InfoCube
  
• 使用virtual Info Providers
• 模型需要超过16个主键（key fields）（DSO最多只能创建16个key fields）

HANA-optimized InfoCube

如果由于这些原因你想继续使用InfoCube,你可以将它转化为HANA-optimized InfoCube，后面会介绍它与传统的InfoCube有什么区别

New CompositeProvider as the basis for BEx queries

到目前为止，SAP推荐不要直接基于InfoCube或者是DSO创建Query，而是基于MutiProvider，主要原因是使用MutiProvider可以结合不同的InfoProvider的数据。即便是Query是从一个InfoProvider中出的，为了方便以后的扩展也推荐使用MutiProvider。在BW on HANA （7.4 SPS 05之后）.中，SAP放弃了这个建议，CompositeProvider将替代MutiProvider，从长远的来看，它会替代InfoSets, TransientProviders 和 VirtualProviders。

Merging SAP BW data and data from SAP HANA views

SAP BW on HANA可以合并HANA View的数据。你可以通过SAP Lumira 和 SAP BusinessObjects Design Studio等工具直接消费HANA里面的数据，一些特殊的数据模型必须直接在HANA里面创建，过往的经验表明，你可以有效的结合HANA和BW的优势，这个具体后面章节会详细介绍

Delta merge and DTPs

在HANA里面，数据的更改最初是存储在delta sto