数据的业务语义:让业务数据”说人话”的关键

如果您对BTP感兴趣,BTP个人精选内容目录 | SAP Blogs 可能有更多你需要的内容

 

想象一下,你走进一家外国餐厅,菜单上全是你看不懂的外文。即使你知道这些都是食物,但你无法理解每道菜的具体含义、口味特色,更别说做出合适的选择。这正是企业用户面对原始数据表时的真实写照。

据统计,企业大量的数据分析时间都花费在”理解数据含义”上,而非真正的业务分析。

 

数据的业务语义概念是什么?

数据业务语义是为技术数据添加业务含义,让业务人员能直观理解的描述层

 

数据的业务语义存储在哪?

应用内天然拥有针对自身数据的全部语义,以简化后的S/4HANA销售数据表为例:

第一层:源数据表业务语义(即源表直接导出的结果)

销售订单表:

字段名VBELNKUNNRNETWR含义订单号客户编号金额

范例数据:

VBELN:4500000001 | KUNNR:1000001  | NETWR:1500.00

VBELN:4500000002 | KUNNR:1000002  | NETWR:2800.00

 

订单明细表(VBAP)

字段名VBELNMATNRKWMENG含义订单号物料编号数量

范例数据:

VBELN:4500000001 | MATNR:MAT001    | KWMENG:2.000

VBELN:4500000001 | MATNR:MAT002    | KWMENG:1.000

VBELN:4500000002 | MATNR:MAT001    | KWMENG:5.000

发现:原始表的所有字段都是技术编码,VBELN、KUNNR、MATNR对业务用户毫无意义

 

第二层:新建模型CDS-1,该模型为销售订单表添加了业务语义

以订单表原表导出的一行数据为例:

VBELN:4500000001 | KUNNR:1000001  | NETWR:1500.00

从CDS-1中导出的数据会变成:

SalesDocument: 4500000001 | Customer: 1000001 | NetAmount: 1500.00

发现:字段名称变为业务友好,SalesDocument比VBELN更容易理解,但Customer仍然是编号,无法直观了解是哪个客户,NetAmount缺少货币单位信息

 

第三层:新建模型CDS-2,该模型基本代表销售凭证数据,即融合了CDS-1,订单明细表和主数据表的业务语义):

从CDS-2中导出的数据会变成:

销售订单: 4500000001|客户: 北京科技有限公司 (1000001)|净金额: 1,500.00 人民币

明细:

– 产品: 高端笔记本电脑-型号A (MAT001) × 2台

– 产品: 无线鼠标-蓝牙版 (MAT002) × 1个

发现:全部内容都是用户可以理解的,销售凭证数据的业务语义已经齐全,但此时CDS-2已经可以用于最基本的分析场景了,但往往实际的业务需求远不止于此,包括但不限于销售领域的更深层次分析,以及销售+其他模块的综合分析

 

SAP如何助力保持完整的业务语义?

最直接的方法当然是在数据仓库获取到原始表之后一层层重建业务语义,但这个工作费时费力,而且需要大量的积累来适应各种维度的分析

而另一个方法就是从源应用中获取业务语义,例如S/4HANA内置了数万个CDS(即模型层),用户直接在应用内就可以进行SAP数据的各维度分析

而针对企业全面数据的综合分析,SAPDatasphere数仓内置了semantic onboarding语义接入功能,可以从S/4HANA直接抽取业务分析所需要的CDS模型,以及各模型之间的依赖关系,快速的在数仓中重现S/4HANA内数据的业务语义,进而助力客户快速实现企业所有数据的语义层搭建,为业务提供”说人话”的数据

 

总结

企业数据分析的核心挑战除了数据质量,还会受限于语义重建工作,将技术数据转化为业务人员可理解语义的过程费时费力,复用源系统已有的语义模型是提升数据分析效率的解决方案方法之一。

 

关于本文内容有任何问题或见解,欢迎在评论区留下你的想法

 

​ 如果您对BTP感兴趣,BTP个人精选内容目录 | SAP Blogs 可能有更多你需要的内容 想象一下,你走进一家外国餐厅,菜单上全是你看不懂的外文。即使你知道这些都是食物,但你无法理解每道菜的具体含义、口味特色,更别说做出合适的选择。这正是企业用户面对原始数据表时的真实写照。据统计,企业大量的数据分析时间都花费在”理解数据含义”上,而非真正的业务分析。 数据的业务语义概念是什么?数据业务语义是为技术数据添加业务含义,让业务人员能直观理解的描述层 数据的业务语义存储在哪?应用内天然拥有针对自身数据的全部语义,以简化后的S/4HANA销售数据表为例:第一层:源数据表业务语义(即源表直接导出的结果)销售订单表:字段名VBELNKUNNRNETWR含义订单号客户编号金额范例数据:VBELN:4500000001 | KUNNR:1000001  | NETWR:1500.00VBELN:4500000002 | KUNNR:1000002  | NETWR:2800.00 订单明细表(VBAP)字段名VBELNMATNRKWMENG含义订单号物料编号数量范例数据:VBELN:4500000001 | MATNR:MAT001    | KWMENG:2.000VBELN:4500000001 | MATNR:MAT002    | KWMENG:1.000VBELN:4500000002 | MATNR:MAT001    | KWMENG:5.000发现:原始表的所有字段都是技术编码,VBELN、KUNNR、MATNR对业务用户毫无意义 第二层:新建模型CDS-1,该模型为销售订单表添加了业务语义以订单表原表导出的一行数据为例:VBELN:4500000001 | KUNNR:1000001  | NETWR:1500.00从CDS-1中导出的数据会变成:SalesDocument: 4500000001 | Customer: 1000001 | NetAmount: 1500.00发现:字段名称变为业务友好,SalesDocument比VBELN更容易理解,但Customer仍然是编号,无法直观了解是哪个客户,NetAmount缺少货币单位信息 第三层:新建模型CDS-2,该模型基本代表销售凭证数据,即融合了CDS-1,订单明细表和主数据表的业务语义):从CDS-2中导出的数据会变成:销售订单: 4500000001|客户: 北京科技有限公司 (1000001)|净金额: 1,500.00 人民币明细:- 产品: 高端笔记本电脑-型号A (MAT001) × 2台- 产品: 无线鼠标-蓝牙版 (MAT002) × 1个发现:全部内容都是用户可以理解的,销售凭证数据的业务语义已经齐全,但此时CDS-2已经可以用于最基本的分析场景了,但往往实际的业务需求远不止于此,包括但不限于销售领域的更深层次分析,以及销售+其他模块的综合分析 SAP如何助力保持完整的业务语义?最直接的方法当然是在数据仓库获取到原始表之后一层层重建业务语义,但这个工作费时费力,而且需要大量的积累来适应各种维度的分析而另一个方法就是从源应用中获取业务语义,例如S/4HANA内置了数万个CDS(即模型层),用户直接在应用内就可以进行SAP数据的各维度分析而针对企业全面数据的综合分析,SAP的Datasphere数仓内置了semantic onboarding语义接入功能,可以从S/4HANA直接抽取业务分析所需要的CDS模型,以及各模型之间的依赖关系,快速的在数仓中重现S/4HANA内数据的业务语义,进而助力客户快速实现企业所有数据的语义层搭建,为业务提供”说人话”的数据 总结企业数据分析的核心挑战除了数据质量,还会受限于语义重建工作,将技术数据转化为业务人员可理解语义的过程费时费力,复用源系统已有的语义模型是提升数据分析效率的解决方案方法之一。 关于本文内容有任何问题或见解,欢迎在评论区留下你的想法   Read More Technology Blog Posts by SAP articles 

#SAP

#SAPTechnologyblog

You May Also Like

More From Author