当前位置:主页 > 轻量服务器 >

百度云_服务器是_促销

简介

我想分享我的经验,并分析我在几个零售项目中遇到的BW任务的可能解决方案。

我认为这个问题非常有趣,因为它是一个总体思想的例子:我们如何避免在没有HANA的BW系统上使用联接(信息集)。

问题描述

让我们想象一下我们有POS数据(收据),每个收据的每个位置都可以关联到多个(!)促销活动或折扣。这意味着可以对同一接收位置应用多个操作。例如,其中一个是季节折扣,第二个是客户关系管理的忠诚度行动,第三个是奖金购买行动等等。这个数据是从POS系统加载到BW的(具体的方法在这种情况下并不重要,可能是POSDM或者abap代理或者别的什么)。

所以我们有以下数据:

用户希望通过任何一个动作(一个或者多个)来过滤报表中的销售数据。当然,在报告中,我们必须显示从收据位置的全部金额,而不考虑按促销过滤。例如,物联网开发,如果用户按动作P001过滤报表,那么报表中的金额应该是100,而不是33,33.

那么,问题是:BW中如何组织这样的数据,我们应该建立哪种数据结构?

可能的解决方案

有几种不同的变体:

变体A。在一个infoprovider(infocube或dso)中,我们存储带有数量、金额等的收货位置,在第二个infoprovider中,我们存储组合[收货编号、位置编号、促销ID]。然后我们通过一个信息集将它们组合起来,并对其进行Bex查询。这是标准的BW方法,也是最简单的数据结构,但是它有一个问题,那就是在大数据量的情况下不起作用。如果我们正确地构造了这个结构,那么这个连接将在HANA级别上工作,并且它将非常快。

但是如果我们在classis DB上使用BW,那么使用Infoset将导致两个非常大的表之间的连接(因为它们都由接收位置组成),大数据教程,并且这个连接将非常慢。每个表的大小可以是数千万条记录甚至更多。因此,这种情况下的Bex查询将工作数小时或根本不工作。

变量B。第二个变量是使用一个infocube,广西大数据,并将数据加载到多维数据集期间接收位置的每一行乘以此行的操作数。在我的例子中,企业软件公司,它将是:

在这种变体中,我们需要对收据关键数字(如数量或金额)进行特殊聚合,否则它们将在报表中相乘(300而不是100)。

这也是一个非常糟糕的变体,因为按维度"receipt"和"receipt position"使用特殊聚合将不允许我们使用聚合。在这种情况下,聚合的报表将使用原始的infocube而不是它的聚合,特殊的聚合将在应用服务器上计算,报表的速度将非常差。此外,在这种变体中,我们需要将infocube中的行数相乘,因为infocube已经非常大了。这将增加加载时间和使用的磁盘空间。

变量С。我最终选择的变体。这个变体基于以下思想:我们创建了一个额外的服务维度,它为每个收据的位置存储促销id的组合。这个维度的代码是由一些特殊符号(例如"&")分隔的promo id的串联。此维度在数据加载期间填充,用于通过任何促销操作组合过滤数据。

因此,在此变体中,我们应执行以下步骤:

因此,我们得到以下结构的立方体:

在BEX查询级别:

因此,用户可以按任意数量的促销动作设置过滤,查询结果将包含与用户过滤中的一个或多个动作相关的所有收货位置。然后,如有必要,iot物联网,用户可以向报表添加单独的维度"Promo1"、…、"Promo5"。这种方法不需要任何特殊的聚合,允许我们使用聚合,因此提供了高的报告性能。

因此,最好的变体是在HANA上使用BW,并忽略连接的此类问题:)但在classic DB上仍有BW实现,因此此信息可能有用。我在两个这样的项目中使用了最后一个变量(var.C),它确实有效

猜你喜欢

微信公众号