BW - 02 数据源、ADSO、composite provider、BWA、BI Content 、HANA、infocube、SID表

数据源

按一个最简单的文本数据源来看。
就是在datasouce下面：

要知道，你建数据源是个框架，为了把你的表抽过来的。所以先看你的表，有没有值类型的交易数据。如果有，那就得选交易数据，而不是主数据文本拉，主数据属性啥的。

数据源里面会有什么呢？一般信息是这个数据源的描述。位置啥的。

提取页面，就是source哪来的。然后是否第一行要要的拉，数据格式拉，一些具体的设置。
如果你从CSV来的，一般我们都是用逗号分隔的。如果你有其他的分隔符，那也写上。

提议，就是SAP认为的你想看的数据的样子。看起来有点乱，有时候你要在你的fields页面设置下：
当你load example data之后，SAP会自动帮你把field，数据类型，长度给你天上。长度就是你的数据源CSV表里的值的最大长度。
当然你建info object给的长度一般要大于你最大的值的长度的。
比如下面第一个user是12位，那咱可能建的是20位。或者你建短了的，那就没办法展示全了。

字段：
这里你可以做些更改。比如说你是一个交易数据源，有数值是小数，那你就得把数据类型改成DEC，长度也得改，小数位也得改。

预览，最后可以预览下你的数据。保证数据源先激活，然后关掉你的数据源，别被自己锁住，然后SAP会依据你在fields里面的设置来展示你的数据。

注意一点，有时候你的系统设置，比如是小数位是，千位是. 这个就是德国的系统搞的。不用管。

现在不用PSA了，那么数据源上载也是用DTP：

DSO

再提一下DSO，原先的DSO有三种，标准，直接更新（就是从program直接写数据，BAPI拉，function module来写拉，不是用DTP来推数据，一句话要写代码），写优化，就是直接写不检查，场景是直接存储大量数据。你只需要考虑好写，一直往数据库填数据，但是不要考虑读。
现在就是更复杂，ADSO，各种。
然后原始的分区和索引还在：

还有个InfoCube模板，那难道维度有13个，维度里面就是放infoobjects,infoobjects最多248个，不过一般不会放这么多，key figure可以有233个？不晓得。一般咱也不需要计算那么多值。。
我以前好像写过一个维度里放超过10个info object就会影响性能？忘记了。
现在只记得F表包括所有的请求，E表压缩之后没请求了，只有总计后的数据。
然后rollup聚集拉，collapse压缩拉。现在都不需要用了。

拿标准ADSO来看，也是三张表。changelog就是从new到active之间更改的所有数据，有对冲的。这个changelog要么手动删，要么设个job或者处理链来删，要不然会巨大。

原先还有info cube的时候，在info cube上查看，会有infocube content 和 fact table这两个表。fact表压缩后变成E表。

当你去看fact表，里面会有info cube的维度，不同的维度里面全是维度ID，是数字123，这个就是通过维度ID去找维度表。每个维度会有一个维度ID，咱知道Info cube最多有16个维度，但是不是每个维度里面只有一个信息对象啊。
当我把公司名称和公司地址放到一个维度里，那这时候这个组合值会有一个维度值的，不同的组合值会有不同的维度值1，2，3的。

这个Fact表就是SAP的星型模型的核心。

像这种概念，虽然过时了，但是如果你不去项目里面去实践，去看他的表，就很难理解。我这句话虽然是个病句，但是意思是，如果你不去真正去看到info cube的fact表的数据，那你很难理解。
fact表就是几个维度，下面维度值1，2，3然后后面的列是关键值。

fact表有了，是/BIC/Finfocube
那么它里面的维度表/BIC/Dinfocube
有了它的维度编号，我们去维度表里找（毕竟最多只有13个自定义维度），就能看到维度里面每一个特性的SID，你一个维度包含两个特性，那就有两个SID，换一种展示方式你就能看出来了，下图换成name不要label。

那么接下来去找SID表，有两个要找的，这里咱就找个一个。后面那些flag不管。

这是个客户维度SID表，从这个SID表找到了客户编号。
然后下一步，就是从这个客户编号来找客户的主数据了，属性P表和文本T表的。


就是这么个一环套一环。为了啥啊，为了报表的性能啊。
一个info cube的请求竟然有这么多表，简直了。这不都占的空间么。这性能哪能好起来啊。这是谁想出来的啊。

然而时代变迁，到了上HANA的时候，就只有ADSO了。
对于ADSO来说，作为一个二维表。key fields里面的所有字段，是用来唯一确定一条记录的。
也就是说如果你的原本表里是班级姓名性别，你不能只把姓名放在关键字段里，因为这个姓名可能有不同的班级，不同的性别。缺一不可。

数据字段么，就包括你的其他属性维度和关键值拉，以及关键值带的单位。

到这里就只有激活表啥的了。大大减少了表的数量啊。

就只有1，2，3表和6，7view了。
那这个扩展星型结构，是直接被HANA碾压式舍弃了。

composite provider

最后我们来看一下composite provider。
毕竟咱不用multi provider了。
但是不管multi provider还是composite provider,都是不存数据的。也就是说他们union啊，join啊。搞这些乱起八糟的，但是实际上，他们只是个SQL 语句。因为BW本质就是个数据库加一些应用。

真正存数据的是底下的ADSO。
做query要从composite provider出，意思也是一样的，最顶层的不会变，随便你底下加多少ADSO。对我的query数据不影响。加主数据的info object拉，加calculationview拉，都行。
一般咱都用union。join太慢了。

BI Content

再说下BI content，这玩意呢，就是SAP提供给你的，他们已经建好的好多模型你可以用的。针对不同行业的，什么石油拉，工业拉。只需要激活就能用。
当然不用也行：

要么你拖拽过去，要么右键插入。

有激活版本的就是已经激活过了，灰的就是没激活过。

模拟看下要花多少时间，或者直接在当前对话框安装，又或者后台job去执行，se37你能看到运行的job.
装好了的话，就能在RSA1下面看见了。

BWA

其次提一嘴BWA　warehouse　accelerator加速器。
我想大概是HANA的前身，加速啥呢。
原先我们从info package加载到PSA，然后继续DTP加载到DSO，再加载到Info Cube这就到顶了。０５年以前是这样的。后来搞了个BWA，也就是说在info cube上再搞一层，以前么，你性能不好就没辙了，重做模型呗。后来嘛，给你搞了BWA，就是让你把info cube的数据给复制到in-memory（内存）设备里，那这个报表就会贼拉快。以前你跑十分钟，现在两秒。那显然的，也贼拉贵。
缺点也是info cube更新了，BWA也要重新更新。

你填写一个provider，然后会有create，然后update，就会从数据库给你推到内存设备里。上图呢，BWA没安装哈。连不到BWA上。
现在HANA上了，没BWA什么事了。

好了问题来了，HANA和BWA啥区别？

HANA

HANA实际上是取代的数据库，你在BW上的所有东西，现在都是in-memory了，在内存上了。以前你要一点一点加数据到BWA上来改善性能。现在呢，不需要了。硬盘啥的，移除掉了。
现在呢，不论你是加载数据还是读取数据（报表）那性能都是杠杠的。所以说现在能付得起HANA的钱的，都上了HANA了。
从DBACOCKPIT来看你家BW的数据库。

当前呢，这个BW是在哪个数据库上，选当前的系统哈，不是你的啥Openｈｕｂ的转出去的数据库系统。有些你是从BW出去到别的数据库上的。

你可以看些数据库的详细信息，还有alert,告诉你哪些数据库的用户密码可能要过期了的。