随着财务数据量的增长，企业为了获得更好的报表功能和分析能力一直在努力简化数据管理。

在近期出版的《SAP Simple Finance软件概述》一书中，Lob财务和SAP创新中心负责人Jens Krüger博士向读者介绍了SAP Simple Finance的HANA驱动应用的内部原理，这种应用就是为简化财务操作而设计的。

本系列文章节选自第三章：消除冗余。文中对SAP Simple Finance背后的核心理念之一（消除冗余）做了深度解释。

简化核心数据模型

企业应用过去需要冗余存储数据以满足用户的性能预期，因为数据库性能是有局限性的。基于磁盘数据库的传统应用现状仍然不能突破这种局限性。SAP Simple Finance软件是基于SAP HANA的，因此它利用了内存数据库在性能方面的极大提升。同时，它的数据模型不会对SAP ERP财务数据模型产生破坏性的改造，因此出于性能原因考虑消除一切冗余已经势在必行。

我们看看SAP ERP财务数据模型，有几个数据冗余的实例很快就能显现出来。对不同组件（比如财务会计，控制，盈利能力及其它）的基本区分在于独立的表结构，这会出现一种重复数据的情况。

这些组件的每个数据模型都存在物化视图和物化聚合的数据冗余。为了解释基本层面的变化，我们现在仔细了解一下财务会计总账（G/L）数据模型。对它的解释同样可以适用于其它组件；它们也会以相同的指导思想被简化。

我们更进一步看看财务会计模块。虽然如此，出于比较的目的，我们参考了财务会计模块旧的设计表。利用Universal Journal，下一步是将目前独立的组件合并数据结构。每个财务会计系统中基本的和必要的数据元组（除了主数据）都是会计文件和它们的行项目。系统记录每笔事务至少有两个行项目会计凭证（分别是借方录入和贷方录入），但是有可能会有更多。

面对数以百万甚至十亿计的会计文件（头信息主要存储在表BKPF），以及它们的行项目（表BSEG）和基于磁盘的响应很慢的性能，SAP ERP财务需要物化视图和物化聚合以提供对具体属性或聚合值的令人满意的快速访问。出于这个原因，核心数据模型财务会计（如图3.2所示）主要包括六个物化视图（三个用于应收账款、应付账款和G/L账号各自的行项目；另外三个用于以相同的方式分别清理行项目）和三个物化聚合做相应总计统计。

SAP ERP财务旧有数据模型。

例如，在SAP ERP财务系统中，所有开放应收账款行项目（表BSID）的物化视图都包含有每个行项目（包括属性子集）的一份副本，要满足以下条件：行项目是开放的（即没有被清理），而且要是应收账款明细账的一部分。毫无疑问，当事务清理项目时，它还必须删除来自开放应收账款项物化视图的相应元组，并将其添加到已清理应收账款项的物化视图中。

相比之下，在SAP Simple Finance软件中，所有这些物化操作都被取消掉了，这是消除冗余的第一步。相反，相应表被兼容性视图所代替。会计凭证和行项目都是单一来源，任何来源数据都会在内存中计算，比传统基于磁盘的系统计算次数更多，但是性能更好。这一行为包括但不限于物化版本中之前已经存在的视图和聚合。

下图展示了财务会计模块产生的无冗余数据模型，功能上与以前的数据模型是等价的。从简化的角度来看，它只包含有会计凭证基本表，和为会计凭证行项目记录业务交易。此外，兼容性视图对之前冗余存储在物化视图和物化聚合中的同样的信息提供透明的访问。这些冗余表陆续会过时，因为SAP HANA在内存中可以计算得到它们存储的信息。

财务会计模块无冗余新数据模型

兼容视图与它们所替代的物化数据模式具有相同的名字，这样可以确保修改更小无缝衔接，不需要SAP客户修改它们的定制程序。任何程序，不管是SAP标准程序还是客户定制程序，过去访问开放应收账款行项目物化视图的应用现在都可以无缝转到相应的兼容性视图。兼容视图为根据需要为每个查询计算结果，而不会牺牲性能，这全靠SAP HANA才能做到。在这种情况下，该视图会直接从会计凭证行项目原始表中查询属于应收账款辅助分类账的清项。任何附加的查询条件（例如指定具体客户）都会立即传递给查询优化器，然后整合到查询的执行计划中去。

同样的方法也可以应用到其它组件。例如，用在控制凭证之上的物化聚合不再必要，在Universal Journal中打开了整合不同会计要素的可能性。

总的来说，SAP Simple Finance软件数据模型现在完全是基于行项目的，没有了任何预构建的物化聚合和其它数据冗余。不仅数据模型更简单了，程序架构也更简单了：系统只需要“简单”地在所有业务交易发生时候做记录就行。所有其它计算都在内存中进行，根据对数据的算法处理执行。对已经在SAP系统做的投资没有任何负面影响，切换到SAP Simple Finance软件你可以立即获益。