在当前数据上实现商业智能的愿望一直存在，并提出了多种方法。他们有一个共同点，由于从未达到预期，Hana失败得很惨。
从技术角度来看，我们确实具备了最终实现这一愿景的所有构建块。
目标显然应该是每一个类别都是绿色的
为了实现实时商业智能，我们提出了两个主要建议：接近实时加载和EII
近实时数据仓库的想法很简单，不是每晚加载一次数据仓库，而是每小时加载一次。不是很"接近"实时，每5分钟，每分钟，甚至每秒钟加载一次？
这种方法在一定频率下是可行的，但数据仓库增量运行需要多长时间？一部分时间是肯定的数据量。但是假设数据加载的频率很高，而且大多数时候源系统中根本没有任何变化，那么这个系数可以减少到零。大部分时间通常花在找出发生了什么变化上。一个表具有基于时间戳的增量，因此执行一个读取所有具有较新时间戳的行的查询。对于其他表，将读取更改日志/事务日志。而且大多数表没有任何变化指标，因此完全读取并与目标进行比较。
上述逻辑不仅需要时间，还需要花费资源。不断地询问来源"有变化吗？"有变化吗？"有变化吗？"。对于每一个表，
虽然这种方法具有数据仓库的所有优点，快速的查询响应时间，没有添加外部数据的问题，没有保存历史数据的问题，网站建站平台，但是除了例外情况之外，构建完全不可行。
另一个在2000年中流行的想法是创建一个虚拟数据仓库，这意味着您可以通过视图创建一个易于理解的数据模型，但数据不会加载到该数据模型中，而是根据请求从各种源查询数据。因此被称为企业信息集成（EII）。因此，所有复杂的转换都是在数据库视图中完成的，而不是在ETL工具中完成的。由于源数据是直接查询的，它会根据定义返回当前数据，并且可以保留整个增量逻辑。
只要对源系统的查询是高度独立的，就可以工作，例如System1:选择季度，sum（revenue）；System2:选择季度，2018世界人工智能大会，business\u year。而且源系统可以足够快地生成结果。
对于典型的商业智能查询，这两点通常都无法实现。
而且，通常您必须减少正在进行的转换的数量，否则查询速度将受到更大的影响。一个常见的例子是对搜索词进行标准化，大数据云计算人工智能，在主数据中查找重复项。这些事情要么是在数据输入过程中完成的——减慢输入数据的人的速度——要么根本不做，因为错误的假设会对决策产生负面影响。
因此，尽管这样的想法有其优点，但由于查询性能差，它很快就消亡了。
从技术角度看，Hana支持EII，在那里被称为智能数据访问（Data Federation）。然而，大数据解决，EII的优点和缺点是相同的。从Hana虚拟表读取时，需要的数据是从远程数据库请求的，因此总体查询性能取决于要传输的数据量、远程数据库生成数据所需的时间以及在Hana中创建最终查询结果所需的时间。
由于只能查询可用的数据，而ERP系统中的变更通常只是，变更，没有历史可用的方式太频繁了。
作为一种临时解决方法，在ERP系统本身在Hana上运行并因此参与Hana查询性能之前，使用并排方案。其思想是将源数据库复制到Hana并保持实时更新，所有对另一个数据库花费太长时间的查询都在Hana框中执行。一旦整个ERP系统在Hana上运行，这些查询可以保持不变，但现在在ERP系统表上运行。
所以基本上这是直接在ERP表上报告。由于Hana的原始计算能力，它的速度要快得多，这又变得可行了，但它没有为查询优化的数据模型那么快。我在这篇博文中列出了这样做的原因：将数据仓库方法与CalcViews进行比较–概述
另一个问题是变化的历史。如果上个月输入的销售订单得到更新，金额从400美元减少到300美元，上个月的收入总额将与昨天不同。在BW中，你会看到上个月400美元的旧金额和今天100美元的另一行金额。因此数据是历史正确的。
Hana智能数据集成选项的一个特点是将实时提要与转换结合起来。以前，由于复杂性，任何其他工具都不可能做到这一点。Realtime被用作复制的同义词，意思是源数据以1:1的比例复制到目标中，就像上面的sidecar方法一样。与此相结合的是EII的缺点。但Hana的实时订阅可以将数据推送到任务中，而不是表中，在任务内部，数据被转换并加载到查询优化的数据仓库数据模型中
因此，实时和数据仓库的优点结合在一起，而不会引入更多的复杂性
使用上述技术，通过联邦和实时转换，可以将外部数据添加到S/4Hana数据库的不同模式中。这样就可以为每种情况选择合适的技术，例如，据说联邦只适用于返回的数据量很小的情况。通常远程数据集很小，因此联邦是完美的。如果不是这样的话，数据就可以被实时地引入Hana，或者简单地复制数据，大数据和云计算，因此在查询时必须对EPR数据进行所有的协调。或者更好的办法是，将实时更改推送到一个已经完成所有协调的任务对象中。因此，生成的视图就像两个完全相同的表结构的联合一样简单，它们都已经在Hana中了。
