购买
下载掌阅APP,畅读海量书库
立即打开
畅读海量书库
扫码下载掌阅APP

3.1 数据模型设计

SAP BW/4HANA中数据模型的设计、开发与需要支持的数据分析场景息息相关。一般在分析场景设计中需要提前明确5W2H相关信息,从而确定分析场景需要的指标、维度、计算逻辑等信息,如图3-1所示。

分析场景设计完成后,在具体模型搭建前需要先进行数据模型设计。数据模型设计核心要素有数据结构、数据计算、数据管理。将分析场景确定后输出的指标、维度、计算逻辑等信息转换为后台数据模型设计核心要素,最终数据模型为分析场景的实现提供数据支撑。因此,数据模型设计非常关键,它决定了企业数据中心架构的稳定性、可靠性及可扩展性。分析场景和数据模型设计的转换如图3-2所示。

图3-1 分析场景核心要素

图3-2 分析场景和数据模型设计的转换

3.1.1 分析场景和数据模型

在企业的分析需求中,常用的指标分析场景有如下几种。

(1)累计指标的统计分析,如销售数量、销售收入、采购数量、采购成本等。该类型的特点是指标可累加,常用于统计期间发生值。

(2)非累计指标的统计分析,如库存数量、库存金额等。该类型的特点是指标非累加,计算量大,多用于统计时点状态值。此类指标需要特别关注计算和展现性能,如物料的库存数量计算。

(3)累计余额的统计分析,如资产、负债等。该类型的特点是指标值为所有统计期间发生额的汇总值,指标计算量大,需要关注计算和展现性能,典型应用是公司资产负债表。

(4)特殊计算逻辑的统计分析,如最大值、最小值、平均值、计数器等。该类型的特点是指标值的计算逻辑与特定需求挂钩,与不同粒度的维度组合时,需要重新计算指标值,典型应用是统计个数(计数器)。

分析场景确定后,需要给后台数据建模输入数据结构、数据计算及数据管理三类信息,以便进行数据模型设计。其中,数据结构决定了数据模型的维度和度量范围,数据计算决定了数据模型使用的类型及度量的计算类型,数据管理决定了数据模型是否启用附加数据管理功能。

以上四种分析场景对后台数据建模有着不同的技术要求。其中,第一种场景需要提前计算逻辑,且指标是累计指标,如果需要考虑业务主键,则适合采用标准 ADSO;第二种场景需要从性能的角度考虑如何实现实时计算历史时点库存值,适和采用BW提供的专用库存模型;第三种场景中的资产负债表需要从总账中取余数,适和采用 Data Mart 类型的ADSO;第四种场景则需要将BW提供的例外聚合指标信息对象与标准ADSO结合使用。

3.1.2 数据模型设计思路

数据模型是对现实业务处理结果进行抽象整合,以支撑后续数据分析的后台对象,数据模型核心组成部分有数据结构、数据计算及数据管理。SAP提供了不同类型的信息提供者以实现不同的数据结构、数据计算、数据管理功能。针对不同场景的统计需求,需要选择具有特定技术特点的信息提供者作为后台数据模型。SAP BW/4HANA提供的信息提供者如图3-3所示。

图3-3 SAP BW/4HANA提供的信息提供者

SAP BW/4HANA提供的各类型信息提供者说明如下。

(1)InfoObject(信息对象)。在SAP BW/4HANA中,信息对象是主数据管理的关键对象。虽然并不是业务场景中的所有非指标字段都必须被建模为InfoObject(如备注字段一般不会进行信息对象建模),但信息对象提供的主数据统一管理、属性共享的关键理念使之成为企业数据仓库不可或缺的组成部分。所有主数据的存储、管理都以信息对象为基础模型。

(2)Advanced Datastore Object(高级数据存储对象,ADSO)。在SAP BW/4HANA中,ADSO是持久化的业务数据存储对象,通过ADSO模型属性的不同配置组合,实现适用于各种分析场景的后台模型。ADSO 代替了 SAP BW 中的 InfoCube 和 DSO,是 SAP BW/4HANA提供的核心数据存储对象。

(3)CompositeProvider(复合信息提供者)。在SAP BW/4HANA中,数据处理逻辑可分为实时逻辑、非实时逻辑两大类。其中,非实时逻辑是指指标提前在数据流处理中计算落地,存储在ADSO中。实时逻辑则是指在查询执行期间通过执行Union或Join物理数据模型(信息对象、ADSO等)进行数据检索和计算。CompositeProvider是逻辑信息提供者,处理的是实时逻辑,提供对基础模型的Union或Join操作,支撑后续的Query开发。

(4)Open ODS View。它提供用于直接访问远程数据库表、视图之类对象的SAP BW逻辑模型。Open ODS View允许灵活地集成,不需要创建任何信息对象。这种灵活的数据类型集成使得在SAP BW中使用外部数据源成为可能,而不需要Staging。

(5)BADI Provider。SAP BW/4HANA提供基于“BADI:RSO_BADI_PROVIDER”的虚拟信息提供者,可以被包含在CompositeProvider中。

数据模型设计涵盖从业务数据源表到最终支持数据分析场景的后台数据表之间的一系列模型设计。需要综合考虑主数据建模,再根据数据仓库分层规范,结合每个数据模型核心组成部分需要支持的应用场景,选择合适的信息提供者进行业务模型设计。

任何一个业务主题的模型设计都不是孤立的,通常涉及主数据调研、业务流程调研、业务分析体系设计、分析场景设计、后台数据存储探源、数据源激活、数据模型和数据流设计等一系列环节。

3.1.3 采购订单数据模型设计示例

在SAP ERP中,一个完整的采购流程包含采购申请、定商定价、采购订单、货物接收、付款清账、发票校验六大环节。当然,也有企业不通过SAP系统管理采购申请,采购流程从采购订单开始。核心主数据有物料、供应商、公司、工厂等,这些主数据贯穿整个业务流程,如图 3-4 所示。采购订单建模主要包括主数据(物料、供应商等)建模和业务数据(采购订单表头、行项目、计划行)建模。

图3-4 采购流程和主数据

在对交易数据建模前,需要调研确认核心主数据的属性清单、层次和文本信息,并明确采购主题关键指标的分析维度,明确哪些主数据属性需要按历史事实分析、哪些需要按当前属性值分析历史。这些将为后续的采购订单建模提供参考。

制造业标准的采购流程,主要包含采购申请、定商定价、采购订单三个环节。

1.采购申请

采购申请是指采购需求(PR),一般通过运行MRP产生,也可以手动创建。为了方便管理,有的企业会连接流程系统,通过完成流程审批的方式下达采购需求。PR 主要包括PR单号、PR项目号、PR申请时间、PR审批完成时间、PR订单量、物料等信息,且审批完成后会生成采购订单号、项目号和定价编号。采购申请经过审批会进入定商定价环节,也会转为采购订单。

2.定商定价

定商定价(PA)是指SAP系统中的采购询价、报价管理功能。有些企业采用线下管理或通过非SAP系统管理。在PR审批完成后,会根据采购物料进行定商定价。有的物料是常采购物料,有规定的价格,因此可以快速走完PA流程,否则要经过供应商主数据维护、供应商报价、供应商定价等流程,待PA审批完成,才能定下最终采购价格。PA主要包括定价编号、PA申请时间、PA审批完成时间、PA价格、PR单号、物料等信息。PA完成后就可以进入采购订单环节。

3.采购订单

将采购申请下达为采购订单(PO),或者手动录入采购订单。该订单经过审批后,会正式下达给供应商,由供应商提供送货日期等信息。PO主要包含PO单号、PO项目号、PO申请时间、PO审批完成时间、物料、价格、数量、送货日期等信息。

以上为“PR-PA-PO”流程,完成PR审批才会有PA和PO申请,完成PA审批才会有PO 审批。但是,PO 申请日期可以在 PA 审批日期之前,收货日期一般至少细化到计划收货日期和供应商交货日期。

采购订单核心主数据的详细说明如表3-1所示。

表3-1 采购订单核心主数据说明表

采购订单业务数据的详细说明如表3-2所示。

表3-2 采购订单业务数据说明表

针对SAP ERP中常规业务模块的主数据和业务数据,系统提供了预置的标准数据源,因此在数据建模前首先要做的是找到相应的数据源并激活。采购订单核心主数据的数据源如表3-3所示。

表3-3 采购订单核心主数据的数据源

续表

采购订单业务数据的数据源如表3-4所示。

表3-4 采购订单业务数据的数据源

梳理完采购订单的主数据和业务数据清单后,就可以在BW端创建相关的模型。在创建具体的模型前,需要先完成以下两项工作。

(1)在ERP端激活相关的数据源,并将其复制到BW端。

(2)在BW端激活采购订单相关的预置模型。

完成以上两项工作后,系统不仅会在BW端自动生成相应的采购订单模型,而且会生成模型和数据源之间的转换、不同层次模型之间的数据流。采购订单数据流结构如图 3-5所示。

直接对接数据源层的模型为基础模型,其和数据源基本保持一样的结构,主键也和源系统业务表主键保持一致。自动生成的采购订单行项目ADSO模型结构如图3-6所示,其模型主键为采购订单号、行项目号,和表EKPO保持一致。

图3-5 采购订单数据流结构

图3-6 采购订单行项目ADSO模型结构

BI Content激活生成的预置模型技术名称以“/IMO”开头,首先需要将该模型复制为客户命名空间的新模型,然后确认模型是否满足所有需求,如不满足则进行定制开发,满足则可直接使用。该模型结构和数据源保持一致,不做逻辑处理。

基础模型保存了采购订单的明细数据,接下来需要根据采购订单主题的最终应用需求,在基础模型之上做进一步的逻辑处理,形成应用数据模型。应用数据模型有如下特点。

(1)数据管理要求决定模型类别。模型的数据管理要求比较多,如是否支持出具报表,是否向上层模型提供增量数据,是否为多维模型,是否支持快照,是否物理落地等。因此,进行应用数据模型设计时需要根据数据管理要求的不同选用不同模型。如果需要整合多个数据模型,支持出具Query,则选用CompositeProvider模型;如果需要汇总维度、指标数据存储,不再匹配业务主键,则选用Data Mart类型ADSO。但是,在一些特殊场景中需要使用特殊类型的模型,如库存模型。

(2)数据结构设计匹配业务需求。应用模型多按主题设计,数据结构应匹配最终应用需求,设计时应关注性能、可扩展性和运维便利性,而不应只追求规范化设计。

(3)数据计算基于指标信息对象的计算功能进行基础配置。SAP BW在创建Key Figure信息对象时,通过配置计算方法即可实现累计、非累计、最大值、最小值、例外聚合等计算功能,因此在指标逻辑确认后,需要创建合适类型的Key Figure信息对象。 YkHOP4J3eBEu3+bvtCfNwWGZb/OedKu2BDzN5C2WWgqay5ezbBmW4qd58wDc2JW2

点击中间区域
呼出菜单
上一章
目录
下一章
×