Open ODS view怎么理解

1.介绍

从BW 7.4 SP5 on HANA 开始,我们就有一个新的元数据对象叫OpenODS view.这个是个新的概念,使得我们不需要预先存储数据在数据仓库里了,我们可以直接集成外部数据到我们核心数据仓库.我们可以来丰富外部数据结构,BW也可以在线分析不在HANA上的数据.

说人话,就是这个东西不要先建info object了.直接从源数据系统建个连接来拉数据,而且还可以是实时的.

插播

这个概念由于是新的,对我这个渣渣来讲,我一眼就跟ODP混了, 什么Operational Data Provisioning,操作数据提供?原先我们用PSA来拉的数据,现在好多我们都用这个:

而且由于我这么多年,已经忘了啥是PSA,这会又来跟我搞这个ODP, 我能不跟ODS(Operational Data Store)混么,而且我依稀还记得啥ODQ(Operational Data Queue)的. 反正我现在是傻傻分不清楚. 何况还有多年前ODS和DSO(Data Store Object)的.我此刻欲哭无泪啊.先把这个Open ODS View(Open Operational Data Store)搞了.

反正这个O的,一会是Open,一会是Operational,一会是Object.

S么,那就Store.

插播结束

在LSA++架构上,OpenODSView 处在OpenODS 层.

 

(好了,问题来了,LSA是个什么鬼?  呃,是这个 Layered Scalable Architecture.就是个多层(伸缩)架构.

这样一来,我想起来了,很久以前我们DSO那块是三层的,什么A层,T层D层啥的,反正具体我忘了,最底层是直接用PSA从ERP抽来的数据,不动的.然后上层再做一些运算啥的. 底层Acquisition获取,中层transformation转换,上层data mart数据集市.

现在LSA++是个on HANA的,更简单,更小,更快,没这么多复制的冗余层了.而且不是有个这个Open ODS view了么,这个虚拟的东西,直接从源系统来了,还要那么多层数据干啥.)

 

和传统的数据获取层一起,OpenODS是一个使用给基于字段的模型建设方式.这种方式就直接是一个虚拟视图方式去获取外部数据,然后和我们的核心info provider来关联.这样基于字段直接获取就意味着我们不需要再在系统里为每个字段创建一个infoobject.

(重点来了: 基于字段,虚拟,直接连composite provider,一步到模型顶层)

创建基于外部数据的OpenODSview,然后再在report里面使用,我们就不用把数据复制到BW里并且长久保存了.省空间了啊.但是必然这种方式也有局限,首先肯定不能是大量的数据.

而且通常这个外部数据是要在非BW管理架构但是装了HANA database的或者一个独立的数据库,但是可以通过Smart Data Access和装了HANAdatabase相连的. 通过定义单个字段与信息对象的association或者单个字段和其他BW openODSview的association连关联外部数据和BW模型.

这里他的一个极大的优势就是可以把外部数据集成到我们的数据模型上,而且不需要修改query或授权.

同时这个都是在BW modeling tools上才能操作的. 

(好了,知道了,只要是新介绍的,旧的上面都没有,都得在BW modeling tools上面弄)

 

2.场景

接下来以本身就存储在HANA 架构上的不同Schema里面的数据来解释.

( 插播: 现在我稍微知道点, 在 HANA Studio里面,会有很多个不同的perspective视角,我也不知道这个怎么翻译.

反正就是这个 右上角的有很多标签,类似于工作区间的.

这新版的建模,可以是HANA上的模型和BW里的模型结合建模.

那在HANA Modeler里面就是HANA database上的table啦.这些table在catalog(目录下面)的各个 Schema下面.Schema下面可以看到HANA数据库上的表,当然咱也可以自己建表.

下面还有个content(内容),这个里面是你来建HANA模型的,就是一些calculation view,analytic view, attribute view.基于上面catalog里的表,你来建view,然后这些view可以用在BW的composite provider里面,也就是和BW的建模相关联.

 由于右上角直接有一个BW modeling tools的视角,你也就不需要重新登录到BW系统,直接从这个视角进到BW里面.

这样很方便了,到BW里面再建模,用上刚才在HANA里建好的view,爽歪歪,还可以和其他BW里面的ADSO做关联. 插播结束)

好了,回到正题来:假设我们在HANA的其中一个schema里面有两张表,需要和我们的模型整合.

下面图是别人的,在别人的HANA系统的DEMO这个schema下面,有两张表,分别是销售sales表(里面有客户编号,产品,订单日期...价值,数量单位啥的)

还有个客户具体信息表,客户编号,姓名,性别,地址啥的. 

 

第二个表里面具体的customer的内容:--咋这么多widow?

 

我们以customer表作为主表,另外一张表是sales表保存交易数据.

在sales表里,外键CustID关联到主表.

 

那我们现在怎么集成这个外部数据到BW中呢? 

3.应用

所有的应用呢都是在BWmodeling tools上面来搞的.因为HANA studio把ABAP development tools,HANA modeling tools和啥的都集成到一起了.我们在BW modeling tools里面用virtual table, HANA table, 计算或分析视图等等啥的都好使.

前提你得有权限,至少你能看到Schema能读表.

常规BW方法我们从建模维度开始.也就是开始主数据对象的建模,例如属性,文本,和层级.然后是交易数据结构.但是用OpenODS view那就是全新的一套思路,我们完全基于关系架构一点点建模.我们可以从事实表开始往维度建模,逐步填充模型.

以上对于本渣又有点绕了.我怀疑小学时我阅读理解基础没打好.

不管了,来建一个看看.(在你的BW project下面,一般在Info Area下面)

3.1 定义事实表的Open ODS view

我们选Fact作为语义开始,就先来建Sales那张表的view.

然后下面的InfoArea可以改的,其次你要写这个view的技术名,描述,语义是啥的.这里我们选的Fact.

接着下一步: 我们选数据库的表,从Scheme拿表.说实话,在下面,我不知道该选啥了,我选了个Existing BW Source System.

(上面有好多个数据源类型选项,就看出Open ODS view的本事了,从BW来的可以,HANA数据库的表或视图可以,虚拟表可以(用Smart Data Access这个我以后也得看看)然后ADSO啦,什么transformation?是个什么东东,不知道.)

然后下一步,去搜的话,发现了这两个源系统,也就是说只有这两个源系统?我又懵了:

本渣猜测第一个HANA_DB,应该是BW连接的HANA 数据库,然后另外一个SAPABAP1BW,这个嘛,由于我们老的BW都是ABAP的平台上操作,我猜测这个是BW自己的表系统.以后如果发现有错我再来改,也许我会忘记来改....

那我选第一个HANA的. 好了,然后你去找你的这个表,反正是在你的HANA数据库里的.

添加了之后,内容是这个样子的:原先你只是一个表,现在,系统自动把DEC格式的给加到关键值 key figures里面了.

然后INT和Char类型的加到特性characteristic里面了.

然而它并没有把Currency和orderunit加到对应的文件夹下面么.

看来还得手工操作一下.

首先,移到对应的位置:

其次,把单位和数量匹配一下子,一样的,要把货币和amount也要匹配一下子.

在相应的Key Figures的属性区域,可以设置对应的单位或者货币,然后呢,还有聚集也可以设置的哦.

 

要是不设置这个的话,那有一个词叫做"参照完整性"...

这会我们把这个建好的view激活,然后我们来看这个view里面的数据.

 

不同单位的key figures,在BW里面是不能被合计的,会有一个*.这个咱都知道.

那么,其实这个表的功能就已经显示了,我如果从客户和日期维度来看所有的值,可以看到了.

但是我希望升级下这个表,我不知道这个客户是谁,只能看到个编号而已,而且这个日期,格式不太友好.这些都要改下.

 

那怎么办呢,重点:我们这里要用到OpenODSview的功能,在field这个level来分配其他的OpenODSview或者Info Object

 日期咋改?我们分配0CALDAY这个字段给它,这样,日期字段就继承了关联的信息对象0CALDAY的属性了.(有点类似我之前做的composite provider里面的信息对象的association功能,都是继承,然而上次这个功能有坑的,我继承了个主数据的文本...唉)

把两个日期的关联对象都分配了.

 日期搞好了,那客户属性咋弄呢?

我们知道在表层面Sales表有外键关联到主表Customer的.在OpenODSview里面怎么用这个关联呢?

看来我们还得再建一个基于customer的OpenODSView,说干就干.

3.2 定义维度表的OpenODSView

就是上面一套,此处开头选master data

然后一直到加了表,之后到视图的维护界面就是这样的:

你可以自己指定源表字段到中间视图字段的哪个目录,中间的文件目录是从我们开始选语义的时候就确定好了的.由于我们选了master data,所以这里有好多text的文件夹.当然系统会自动帮我们分配一下子. 

那重点又来了: 我们这个是一个主数据类型的OpenODSView,上面有一个目录叫做: representative key field代表键字段.

这个字段必须得有的.

其次我们要在报表前端看到这个用户的描述,text里我们也得给一个.

以上基于报表要求,我们选customer作为text,且键值给了CUSTID.

同样和fact的OpenODSView一样,每个字段的属性我们都可以分配更多的细节性的东西:

像是连接啦,权限相关啦,参照完整性啦(针对key figures)还有些报表属性啥的.这里就不设置了.(以下是个示意图)

 

好了,然后我们保存并激活这个View.直接到AFO里面打开这个数据源.

 Customer在text里面,所以直接能看到.

3.3  定义对象的关联

上面提到了可以用association这个功能的.这个功能只适用于特性,可以把特性连接到已经设计了文本或主数据的OpenODSView字段.或者连接到已定义的info object.

然后其实你也可以定义更多的属性给这个关联的对象. 组件啦,层级啦.

(其实这里这个继承,说的太抽象了,一般我们需要转换来连线,才把这个连接拉过来的.这现在说实话我也不知道底层怎么实现的,我感觉像个导航属性的外挂)

如果我想基于OpenODSView的这个字段来做查询,而且是查询外部的层级,那前提是我要给这个OpenODSView的字段分配一个信息对象.

对于关键值类型的,你分配了一个信息对象后会继承人家的聚集操作.

好了,回归正题.

我们现在的需求是,在前一个OpenODSView的query上面能查询到customer的text.

铺垫了这么多,到这里就很简单了.就是在Sales的那个OpenODSView里面给CUSTID这个字段做关联到Customer的OpenODSView,关联之后我们就可以查询到客户的性别,城市,国家.也就是把customer这个视图的customer的维度信息当成是导航属性.

除此之外,由于我们早就把0CALDAY分配给了Sales里面的两个日期字段.我们现在能看到的这个view的定义是这样的:

最后再来看以下query.

 很明显看出来,客户有姓名了,日期格式也变了.

但是别忘了,刚才还选了几个导航属性呢.所以性别,城市,国家.都可以下钻的.

3.4 货币和单位的处理

到这里还不算结束,还有一个*在啊,这是咋回事呢.

这得处理下货币和单位啊. 但是不同单位和货币,那本来求和就没意义的.可咋办呢?

当我们把字段从源拖到View的Unit或者Currency文件夹下的时候,你可以注意到,参照一致性的设置项是灰的.

系统就不允许你设置这个参照一致性.

一般的逻辑是啥,就是得有个转换汇率啥的,把货币给设置成统一的.这样才能计算.单位也是一样的,有个换算规则.大家都换算成统一的.

所以我们要给货币或单位分配一个参照字段.

真实的业务场景有这样的:当我们有一条新数据产生,这条数据插入到Sales Order表中,而且它有一个新的Order Unit.

插入语句是这样的:

INSERT INTO YSHSALES VALUES (0000000051,'0000000956','000000000000315413','20120903','20121101', 97, 59, 687.59, 3225.6, 60,'EUR','STK')

这个新的Unit对于BW来说是完全未知的.此时再去跑query,系统没办法给你识别,会给你报错.

这个错就说没有STK这个UNIT的SID表啊.

我好好的跑数据,为啥给报了这种错?不应该啊?这是什么逻辑?

这就是内部设置,BW里面对于货币和单位有特殊处理.你所有的货币和单位,必须要在货币和单位的一个集中的表里先定义了,先维护了才可以.

要解决上面的错.我们必须得在BW设置"STK"的基础单位.然后query才能正常跑.

---SPRO

 

到这个里面去设置

 

等设置完了,就可以看到了

到这里,那还没结束了.

什么参照完整性呢?还有一点小尾巴呢?

3.4.1 当映射到信息对象时参照完整性设置的影响

要解释下这个参照完整性,那还得用个小例子做个背景介绍. 

我们有个OpenODSView,其中的一个外部数据源字段分配到一个InfoObject 0D_NW_BP.我们也通过相应设置确定了参照完整性.

 

那当我跑query的时候会是什么样的呢?

实际上当我设置了确认参照完整性的时候,系统是去帮我在外部表D_NW_BP_SALES的字段D_NW_BP和SID表的这个被associated的信息对象0D_NW_BP之间建立参照连接.(referential join) 也就是说,当我去跑query的时候,我们只能获取外部表和SID表的该键值同时存在的结果集.

(SID表和fact表和维表的关联也要知道的)

比如说设置了参照完整性之后,数量的总值是21000.

我们再来看一下,不设置参照完整性.不打这个勾.

那么系统所执行的就不是参照连接,而是在这个外部表D_NW_BP_SALES和我们的SID表之间执行一个左外连接.(left outer join)

(所有的连接的区别啥的下次写一篇) 

 

.现在来看query,由于在外部表中有两个多出来的供应商,这两个供应商并不在我们的信息对象0D_NW_BP的主数据表中.

所以现在的query值不一样了,是224了而不是210.

所以你得确认设置这个选项来满足需求.

而且你得知道,一旦你不设置参照完整性,你的关联的信息对象的主数据表会出现多余的外部表的数据.

比如,未设置参照完整性时,执行报表前,信息对象0D_NW_BP的主数据表有45条数据.

 执行报表后,会多出两条:

4.传输

当使用外部表,尤其是非SAP的数据时.有时候我们要经常修改外部表数据.或者项要更好使用BW的功能.

一个典型的例子就是,结合日期和时间字段,像'2016-09-08 13:14:32.123'这种格式.要用到BW的时间处理方式,像特定地区,日期层级啥的.

在OPen ODS 框架下,可以有多种方式来处理这种问题.如果源数据是个数据库表或者视图.那有一个简单的方式,就是创建另外一个基于该数据源的视图,而且包含转换逻辑.同时我们也可以在BW传输中来使用简单的公式来转换格式.

看这里是有个标志叫做 SAP HANA Processing possible

也就是这个query是可以被下推到HANA来处理的.

如此一来,日期下钻的时候就可以被识别语义,并且有时间层级的功能了.(具体下次有空再细看这个层级功能)

5.从虚拟到现实

OpenODSView其实不仅可以以虚拟的形式访问数据,同时也允许从一个远程数据源转换和传输数据到BW中.

在一个物理星型模型中,事实表可以和主数据维度分离,同时,文本表一般需要和主数据表分离,因为他们有一个附加的Key字段来标记语言代码.

OpenODS view在创建的时候也可以选择事实表,主数据表或者文本表这些语义.因此当从OpenODS view来创建报表视图时,整个的结构模型可以转换成BW层的保存数据的模型. 就是当我们从远程访问来保持Service Level Agreements很困难时,或者需要一个日常的稳定的数据snapshot时,或者需要传输来和外部或者其他BW数据整合时,虚拟的方式就变复杂了.

同时,转换成BW模型时,之前的workbook或者query都是可用的.Open ODS 可以从一个Open ODS View底层来转换源:创建了BW层保存数据的对象后,你可以把原始数据表和新建的BW DSO做替换,并且继续使用你之前建立的query.

现在BW也支持基于field的DSO(field从OpenODSview来). 同时也可以把OpenODSview的数据源转换成新建的DSO.