基于HANA数据库的BW4HANA

最近忙于看叛逆者，没时间写东西。。。
昨天一直看到老顾死了，然后突然就不想看下去了，联想端午以来，确实轻轻松松啥事没干，还是得收收心，回到工作上来啊。。。

回到主题，BW基于HANA了，就是说BW的表都存在HANA上了。
那么存哪里了？这么多的Schema我不知道是哪一个啊 。。。

我只知道Catalog下面存HANA的 Schema。
Content下面建package来 放view 。
Provisioning可以建虚拟表 数据源啥的。
Security下面 是用户角色和权限。

我回到BW Modeling Tools下面也看不到啥啊 。

查看BW的表在HANA中的位置

为了混合建模 ，BW中能直接用上HANA的view，我先给attach上：


这样我可以直接在BW Modeling Tools里面看到所有的Schema和package里的view。
回到开头那个问题，我知道现在我建的DSO啦，CP啦表都会被存放到HANA数据库上，可是到了哪个Schema下面了呢？
不管是哪个，肯定是系统帮我生成的。已经在了，我只要知道它名字。

在系统状态里面看：
SAPGUI里面可以看到系统定义的Schema名字 ，你建的ADSO的表都在这个里面。

接着你去这个Schema下面看表，就相当于去看Se11，这里有个Main Storage和Delta Storage就是HANA数据库上为了优化列存储表的写操作而弄出来的。有空来单独写 。你可以看到index和在ADSO上做的分区，不过当你去data preview就知道HANA这么快的处理速度，已经用不上index了。

这里提一嘴HANA数据库支持的数据提供方式：
SAP HANA Enterprise Information Management是指HANA自己SDI、SDA、还有SDS（smart Data Streaming）

一般用SDA 就够了，SDA支持的数据源有：

SAP HAHA/SAP IQ/SAP Adaptive Service Enterprise/SAP Event Stream Processor/SAP MaxDB/ Hadoop/ Teradata/
Microsoft SQL Server2012/Oracle 12c/ IBM DB2/IBM Netezza/Apache Spark
SDStreaming 那种一直要检测，用于抽取传感器啊 智能设备啊 社交媒体的，没用过。当然还可以用来监控 IT系统，财务的市场价格 啥的。

看看HANA建模中的JOIN和UNION

半壁江山给了HANA。

开头我们就讲了，BW 里面建模的表是存在HANA 数据库Schema里的。
同时结合我之前写的一篇： 混合建模-从BW对象生成外部HANA视图.你就能知道，在HANA Modeler里面可以混合BW的对象建模，在BW里面也能用HANA那里建的view来直接在CP里面建模。

其实不是半壁江山了，从下图看是快四分之三了。BW主要还是对数据量大的，历史性需要复杂逻辑处理整合的数据存储。HANA里面多是强调实时性，数据量没那么大。
BW里主要是SAP ERP的数据，HANA则更加支持其他非 SAP系统的数据。两强联合。但是无论怎么看都感觉BW会 被取代掉，但是SAP说会支持BW4HANA到2040年。。。鸿蒙都出来了，谁晓得2040年是什么样。。。

要了解HANA建模，那就得从了解Calculation View能用来干什么说起。
Calculation View里面可以有attribute，measure，calculate column，counter，hierarchy，variable，input parameter
既可以图形化创建模型，也可以自己写SQL。

而且还可以用很多join：

1. referential Join: 要求参照完整性的时候用。
   实际语义上它还是内连接，只不过预判是满足参照完整性。这个参照完整性是啥意思呢，就是我左边表里的条目，在右边必然会有一个对应的。这个参照join是简化的Inner join。我假设右边的表里会有条目和左边的表对应的。省去检查的这一步。
   实际执行的时候就是这么一回事：**如果右表中的数据被获取，那我就执行Inner join。如果我不需要获取右表中的数据，那我就执行left outer join。**就看你取不取，以此来优化性能，毕竟左外比内联快多了。
   啥场景用它呢？
   由于他这个是默认参照完整性的，也就是说你左表的行必须在右表至少有一个对应的行。左右都使用这个参照完整性。如果没有参照完整性，那这个join出来计算的列就错了。你左边有，右边没，为了保证他这个参照完整性，他会给你在右表创建一个。但是你实际上没有这个，那数据就错了。
2. inner join：同时存在在两张表中。
3. left/right join：左边或者右边的内容全展示。不管另一边有还是没有。
   数据库视图就是用的 inner join，而help view和 maintenance view用的就是outer join。
4. Text Join：语言相关的描述匹配。
   可能有些奇怪，这个用来干什么的呢？你有一个产品表包含的是产品编号，但是没有描述。另外你有一个文本表，包含语言相关的产品文本描述。那你就可以用一个text join。来获取语言相关描述。右表必须得是文本 表。还必须确定语言列。如果文本不是语言相关你 也可用 左外连接。也就是说如果没有language这个列那你就用不了text join。
   
   

看看HANA中的Schema

_SYS_BIC
所有激活的对象的列视图，当你激活Calculation View，Analytic Privilege，Procedure，相应的运行时对象都会被放在这个下面。

_SYS_REPO
系统有的都在这里。激活的，未激活的，包细节，运行对象信息，就是你得有这个Schema的select权限。

_SYS_BI
列视图的元数据。这里面有变量，时间数据，Schema映射内容映射的表信息。

_SYS_STATISTICS
系统配置和参数信息 。

_SYS_XS
HANA的扩展应用服务。我记得有个叫XS的。。。

Calculation View

以前还有建Analytic View和Attribute View，但是现在我感觉建Information View都只建Calculation View了。毕竟它不仅能 适用于不同的数据源，一层层叠加复杂逻辑，可以结合好多个表，视图，可以用join，union，投影，聚集层，还可以用自定义SQL 。可以包括计算值也可以只包括维度值。

Cube 的类型默认就是一个聚集节点，你当然还可以加上with Star Join。
Dimension那就是一个投影节点。没有计算值或者层级 。不能直接用于报表，可以用Sql来读取。

一个calculation view里面的scenario场景下都有啥呢？
首先是semantics下面的节点，如果你选cube，第一个节点就是aggregation，如果你选了dimension，那第一个节点就是projection，如果你选的是cube with star join，那第一个节点就是Star Join。Semantics就是最终输出的结构。
在右边还能看到column，所有列，你能把列定义成属性或者数值。如果是个Star Join，那这些列底下还会有底层视图的shared columns，也就是维度。层级那一页也是从 底层维度视图或者在计算视图上定义的层级。参数变量包括用来过滤属性值的变量 和参数。
其他的Union，join ，projection，star join，aggregation，rank都很好用。

BW4HANA的Info provider和 HANA 的Calculation View结合

怎么合并这两个源的数据？那就是用join或者union。也就是composite Provider大法。

最顶层的这个CP虚拟层，提供报表和分析层的虚拟数据集市。从这个图可以看出，HANA 里面是直接视图来的。那么意思是这个view可以是SAP的源，也可以是非SAP的源。
以往在BW里面建模，那么必须得有一层info object，这是BW独有的。在BW之外，那都是字段 。这其实很费功夫。现在的话，这个中间通道在HANA这里打通了，不需要一定有info object了，可以直接字段了。
不仅省了好大功夫 ，而且这意味着不需要把数拉到BW再存一遍了。这个就很简单，你以前建了一个Calculation view和ADSO啥的，或者你建了一个CP可以用于其他CP的。那么你现在可以再建一个CP，用Union节点把你的CV和ADSO、CP都包进去。然后Data preview来看就行了。