sapbw意味着不灵活和昂贵的整体？那不一定！使用sapbw/4hana，开发可以比以前更加迭代。因此，以下适用（？）：SAP BW/4 HANA=更精简、更快…更便宜？这取决于你的建筑！通过这篇文章，我想给你一个印象，为什么sapbw/4hana（finally）支持对变化做出灵活反应的数据模型！

另见上一篇帖子：点击我

我们要评估订单。数据模型如下图所示。

迭代3

经典方法

在较旧的SAP BW系统中，必须扩展InfoObject供应商以包含属性。此外，还必须调整多维数据集和多提供者。随着时间的推移，一个大型主数据对象的创建变得越来越难以适应变化。

SAP BW在变化方面具有不灵活和昂贵的声誉，这不是没有理由的。幸运的是，我们不必再这样工作了。

动态灵活星型，维度卫星和雪花

随着动态灵活星型，人工智能的技术有哪些，维度卫星的选项也被引入。一个aDSO的一个字段可以在复合提供者中多次关联

在场景中，业务领域和地区的信息来自不同的系统。没有直接的技术联系。主数据存储在封装的卫星中是有意义的。我们为供应商得到三个InfoObjects.

供应商：属性系统1供应商：业务区供应商：地区

由于复合供应商中存在虚拟关联，因此不必调整订单的持久数据模型。这样做的好处是，通过创建卫星，大淘客网，我们可以创建更小的单位，可以对未来的变化作出更灵活的反应。Snowflaking或transitive属性还可以将产品组作为附加字段包含在复合提供者中。它的行为就像一个单独的原始字段。可以使用产品组的导航属性

创建卫星维度时，一定要检查每个维度的意义。例如，物联网技术及应用，如果业务区域是来自其他主数据所来自的同一源表的字段，那么额外的附属数据就没有意义了。卫星形成的标准可以是，例如，数据模型的波动性（数据模型结构发生变化的频率）或变化的频率（必须装载卫星的频率）。在项目中，我们还创建了一些属性需要特征组合（例如，公司代码的复合信息对象）而其他属性不需要时的卫星。通过将其划分为两个附属对象，可以为报表中的适当属性形成总和，而不需要括号内的字段，就像经典的SAP BW模型一样。

维度附属对象集在逻辑上表示业务实体/对象。在我们的示例中，几个InfoObjects构成了业务实体Supplier。如果在复合提供者中必须考虑更多的对象，这可能会对数据模型的透明度带来挑战。如果您想使用InfoObjects对主数据建模，一个可能的解决方案是创建一个所谓的"Link"InfoObject。各个InfoObject作为属性插入到中心InfoObject提供者中。"链接"InfoObjects的属性可以在复合提供者中作为可传递属性激活。透明度的提高是用较少的灵活性换来的。这意味着不能再访问链接的InfoObjects的可传递属性。此外，还进行了一个额外的连接，这可能会有性能上的缺点，特别是对于非常大的模型。

主数据的虚拟化

主数据建模的虚拟类型在发生变化时特别有价值。如果在只有一个主数据表的情况下，建模似乎过大，则该方法现在显示出其优势。

OOV下方的计算视图可以灵活扩展，以包括已建模为aDSO的其他卫星。在本例中，虚拟OOV表示供应商业务实体。两者兼有：通过虚拟化实现高度的灵活性，同时通过中央业务对象实现高度的透明性。还可以使用计算视图中的虚拟连接灵活地映射结构（如雪花状剥落等）。数据模型可以根据需要进一步扩展。我们的分析表明，即使是大型场景也能很好地工作。

可能的下一次迭代

数据模型的进一步可想象的扩展也可以在额外的事务数据中，例如所下订单的计划数据。在这里，sapbw/4hana也是灵活的。在计划数据的简单情况下，复合提供者可以很好地形成一个统一的图，以便通过联合或简单联接进行报告。如果它变得更复杂，并且您仍然希望不使用持久性，那么计算视图在这里也非常适合映射复杂的事实。

我希望相当简单的示例已经清楚地说明了SAP BW/4 HANA对数据建模的影响。新的、更灵活的数据模型和开发过程模型是可能的。特别是使用虚拟化的数据模型，在基于SAP BW的数据仓库的开发中，可以很好地实现敏捷和迭代的工作方式。

我已经制定了四个原则，在我看来，这些原则对于敏捷的SAP BW建模至关重要：

现在所有的数据模型都应该虚拟化吗？InfoObjects（很大程度上）是多余的吗？

没有适用于所有情况的通用建模建议。主数据模型或转换逻辑的虚拟化提供了非常高的灵活性。但是，如果只评估SAP S/4 HANA财务数据，则通常根本不需要这样做。数据建模依赖于几乎不变的稳定结构。此外，业务内容还提供了可立即使用的主数据模型。同时，对于同一sapbw系统中的其他资源，物联网应用技术是什么，云赚，建立一个高度虚拟化的数据模型是绝对必要的