1. 理解BW4HANA是干嘛的
好歹干了这么久的活了，从当初的啥也不懂到现在感觉啥都知道点，虽然知道的有限，但是也不是小白。渐渐的也知道了SAP开发的一些逻辑。本来咱是想当个BW的大牛的。但是现在感觉这条船要沉了是怎么回事。个人才稍微摸到点门道，项目整个都要黄了。现在通知说项目要撤了。啥都不说了。
不管以后干不干吧，先把知识点总结下。也算给自己有个交代。
虽说BW的船要沉了，但是我们做数据建模的，我总认为业务对数据分析的需求得基于咱建模的人的熟练技巧，咱得把数据给他提出来，不管是做格式的调整，比如简单的去除前导零，重新格式日期，做货币转换或者做数据join，咱得把数据合并好整理好不是。不是说现在报表能基于数据库强大的功能直接从原始表出，就不用建模了的。毕竟架构好数据集，保留只需要的数据会极大增强报表性能。
合格的BW，得懂数据库：表，视图，函数，存储过程。inner join, outer join, union, 星型结构。 必须得懂SQL。不仅要让你的数据无误，还得让它高效快速的被整合计算出来。当然还得把数据授权玩明白。
同时，也得不停的了解业务，业务才是公司存在及发展的基础。
在看BW是什么之前，先了解下SAP发展到现在，它都有哪些个建模工具了，以及分别怎么去部署他们。
SAP它是三层架构，数据库层->应用层->前端展示层。部署的时候可能是在本地，公有云，私有云，或者混合云上。
本地表示，要自己安装软件，维护硬件。
公有云在不独立拥有硬件和软件设施的情况下，允许用户使用这些功能，而且不用自己去定时更新，因为公有云提供自动更新。
私云类似公有云，就只是不和其他人一起分享。
混合就是本地和云上都有：
以上这几种部署方式，SAP都有涉及。
1. SAP HANA
数据库+复杂建模工具套装 （建在本地，私有云，公有云）我们的HANA架在AWS上，我觉得不如本地的打开和运算速度快。HANA建模就是从最底层数据库层开始，鉴于HANA的多内存，建模在这层，数据处理起来非常快。这层主要用calculation view计算视图。计算视图可以搞过滤，计算，聚集，join等等。还可以自己写SQL。
在计算视图往上，可以快速集成到SAC，BW4，AFO，Crystal Reports等等。
2. BW4HANA
它是本地数据仓库解决方案。主要执行数据分析，历史数据存数，数据清洗和多数据源数据整合。当然私有云上也能部署。由于它现在底层数据库是HANA了，那么HANA上建的计算视图可以直接拿过来混合建模用。咱知道BW本来的数据建模都是在应用层的。和HANA结合可以利用到HANA的强大性能。而且BW有很多预定义好的建模对象可以直接激活使用。建模工作现在是在BWMT里搞了，复杂逻辑客制化需要用到的是ABAP代码。但是现在咱也知道，BW4在HANA上线之后，应用场景可能只有历史数据了。就是说现在需要做历史趋势分析啥的，会需要把数据保存在BW里。其他场景的，简单实时分析，基本上是用不到BW了。BW本来也不好做实时分析的。对于历史数据，主要是通过增量抽取。
3. SAP Datasphere
BW4的轻量级云上版本。公有云上的warehouse-as-a-service。
反正SAP就是要这么发展，咱也不知道他们的策略。BW反正是干不到2040年。那咱就得还学别的，这个SAP Datasphere我也研究了下，虽然咱现在没用上。但是了解下总没坏处的。SAP它以后大概率要用Datasphere来代替BW的，它提供了把BW4的建模包转移到Datasphere上的一系列工具。不论是谁，潮流来的时候，要么跟上，要么被带上，SAP这个也要紧跟潮流，都往云上搞。和SAC一样，这个Datasphere是架在SAP HANA Cloud上的。不同的租户，相同的基础架构。
这个上面的整个建模逻辑其实和BW还是一脉相承的，不过更加图形化，更加简单。一些公式用到了Python。对于咱一窍不通Python的也要学学了。不学习的话，不被潮流卷走，咱就得被拍在沙滩上了。
不过我学了一遍所有功能之后，发现其实它更简化版本的BW，从某种程度上说，它并不可能完全替代BW，就像是主数据的层级，导航属性等等一系列功能。我看都没有，当然也许是我看的潦草，没看到。。。最好的是这个轻量级的工具给业务人员自己去玩耍，而实际的复杂模型仍然是在HANA或者BW4上。讲到这里又得插一嘴，BW确实得精通业务知识。
SAP Datasphere的主要用户对象是两种人，而且是两个建模层：
1.业务人员用业务层，直连底层数据层，自己独立建模。主攻业务模型的优化。
2.专业建模人员从数据层建模。主攻数据提供和复杂逻辑的实现。
4. S/4HANA
S4支持本地，公有云，私有云，混合部署。
S4内置分析，抢了BW一半饭碗。只不过用的不是一种工具，他们用的是虚拟数据模型+Fiori。
和BW跟HANA不一样的是，这个内置分析，只能处理SAP ERP本身的数据，不能整合其他数据源的数据了。虚拟数据模型主要是靠CDS View,直接在数据库表上架视图进行计算，不需要冗余的保存到BW上在应用层搞来搞去了。不过S/4内置分析作为BW部分替代，也是在应用层上搞的，也就是说CDS view是在应用层上，Fiori那肯定是前端的。靠这俩直接进行ERP系统的实时报表分析，还用啥BW哦。😂
5. SAC
SAC踩着SAP Lumira的尸体，看都不看一眼Xcelsius就昂首阔步的来了。它扛着BI的大旗，发誓要把强大的分析，预测，企业计划都一揽子包圆。不过实际来看，也就是换汤不换药，能预测个啥？
除了跟自己的SAP系列集成的好，市场上也没有干过Power BI。它不是个数据建模工具，只是个分析工具。不过它肯定要有点简单的建模工具箱的，有时候这两把小刷子能给不需要复杂建模的小企业用的。它的主要功能就是个讲故事的，在里面建story。跟一般的dashboard工具一样，要图形化分析界面。
SAC是在SAP HANA Cloud数据库上跑的。但是是两个云租户，只不过是云上用一套基础架构和资源。
要说到它的建模能力，那主要就真的是两把刷子：
第一把：直连数据，从本地或者云数据源连接数据表，对于那种有安全权限考虑不能存在SAC上的。进行数据在线分析。
第二把：数据导入，也就是复制存储。原始数据源的数据更改不会反应到导入的数据上。
当然直接在SAC里数据建模的好处就是，能在story和数据模型之间查看，不需要再去其他系统看底层模型怎么架构的了。
6. BO Universe
用Information Design Tool来搞的，我觉得其实SAP买的这个工具还不错的。也许很多后来SAP开发逻辑也是借鉴了BO的。Universe这个名字就起的很绝，宇宙。在宇宙里关联所有数据源，SAP的，非SAP的都能在此关联。Query也能作为universe的源。Universe可以给BO这个大集团的一众报表工具使用：WebI啦，Crystal Reports啦。但是毕竟它很老了，也许以后SAP也要给它搬到云上了。个人之言：BO上的权限管控也是很有巧思的，跟BW的权限各有妙法，又有相似之处。
总结一下：
公有云：SAC、SAP Datasphere
本地：BO
本地+私有云：BW4HANA
本地+私有云+公有云：SAP HANA + S/4 CDS
具体的上面的几种建模区别看我这一篇：SAP提供的几种建模武器
1.1 BW到底是什么，里面都有些什么
BW就是个数据仓库，business warehouse， 不管它这个翻译。实际上现在的BW4HANA就是个部署在本地或者私有云上的数据仓库。SAP说支持到2040年。但是它09年就上线了SAP Datasphere,之前叫SAP Data Warehouse cloud。数据仓库云，作为一个公有云的数据仓库解决方案。这个咱也看过了，有空来写一篇，和BW集成的也挺好。我个人感觉上了S4HANA之后，用SAP Datasphere就可以快速出报表了，然后直接关联SAC，一整套从数据到前端展现快速灵动。不过这个Datasphere的设计逻辑还是很多参照了BW的，也就是那一套处理逻辑。暂时还有些功能也不能替代BW。
1.2 BW4HANA是架在什么框架上的，整个架构是什么样的，到底在数据分析框架的什么位置
BW4HANA和BW相比，一个明显的就是架在HANA上了，不和其他数据库玩了（SAP是说以前在其他数据库上要考虑和他们的集成，不好更新新版本，用了自己的数据库，想怎么更新怎么更新）。利用了HANA数据库的特性。建模的对象更少了，还能直接和HANA的计算视图结合。用Eclipse这个建模环境和Fiori的用户接口结合起来了，要么就是在Eclipse里面拖拖拽拽写写代码，要么就是在Fiori里面点点这个点点那个。
BW4HANA之前所有版本BW都是架在SAP NetWeaver上的，现在是直接架在一个单独的ABAP应用服务器上的，原先的集成在Netweaver组件的代码都被删掉了，大概删了五百万条ABAP代码吧，一些BW对象也被删掉了。只支持能用HANA数据库的对象了。不过用户管理和授权，传输相关的和系统日志追踪啥的都还和以前一样。现在还能看到的组件都是一些基础组件了，比如SAP_BASIS,SAP_ABA,SAP_UI...
1.3 HANA在BW里是个什么角色
整个BW4HANA里最重要的部分是数据仓库服务，对数据建模抽取，数据清洗整理计算都在这里。往上就是支持query的OLAP功能。包括对层级的处理，货币转换的处理，复杂逻辑的计算。
Content里面就是预定义好的一些建模对象，可以拿过来直接用。源数据存储里面就是所有SAP开发的或者是客户自建的对象的目录。Workspace就是用户可以自己存储在这里进行使用的和其他的建模对象独立的一小块自开发空间。openhub用来导出数据到第三方。ODP用来导入SAP系统相关的源数据，包括BW4HANA（也属于这个SAP框架）。
HANA给BW赋能的主要就是两个部分：数据加载和报表性能的提升，同时能存储巨量数据。
性能上多加了好几个内存和CPU。计算能力增强。告诉，多核的CPU能处理更复杂的任务了，还能同步处理加快反应时间。而且数据存储都直接放在内存上。不放硬盘上。
在数据处理方面。主要用列式存储，压缩，增量插入。
列式存储主要对query很友好。因为query只要几个属性。如果行存储去找，要遍历所有行上的列。
BW4HANA所有的模型表都是列存储。
列式存储表由于能把列上相同的值给压缩了，就会省好多空间。列属性值会进行排序和位编码，列的位置上的值有重复的时候会压缩。大幅减少表占用空间。也就是说BW4HANA 能存储更多的数据。
而它在数据进行插入的时候，还用了增量插入和压缩。
存储的位置给分成两块，分别是主存储和增量存储。
因为列式存储是排序好压缩好了的，比如ADSO每天的数据更新。数据进行更新的时候，先进入Delta存储。因为那边主存储都是排序好了的压缩好了的列存储啊。你这个先进来。如果要更新到主存储，得要再花一阵子时间来重新排序，重新压缩。在此期间，如果有读数据的操作呢，那就从两个部分都出数据。如果还要继续写呢，就从增量存储写进去。
一般我们都是在所有上下层的ADSO数据都更新好了，在处理链的最后一步搞delta merge。
但是也有把这一步直接放在DTP步骤里的：
想要了解具体的HANA的设计的：The secret of SAP HANA – Pssst! Don’t tell anyone! | SAP Blogs
HANA的代码下移就是说原先我们是把数据库里的数据拿到应用服务器层进行计算，把数据拿来拿去的。但是上了HANA之后，只是把指令拿来，而在数据库层直接进行计算。
应用服务器层现在主要处理协调和触发数据库内的比如激活ADSO，压缩，重建，选择性删除，请求管理，数据分层等等的这些活了。还有就是来处理用户定义的开始结束专家例程啥的。AMDP。
HANA是把运算逻辑代码下推到数据库层，最后把结果给展现层。不需要把数据带到应用服务器层的。所以它就能快速提升BW里好性能的一些数据处理活动。
比如说：ETL的过程，ADSO的激活，Query的运行还有Planning的一些功能。
同时HANA上直接建的内存式数据模型-计算视图。它也很强大。BW里面的一些建模功能，像权限配置啊，货币转换啊，HANA的计算视图都支持。还有些BW没有的，高级排序，内置SQL，生成数据交集啥的。反正就是SQL有的，它都拿来了。
1.4 BW4HANA的设计原理
BW的设计原理有四个：
基于这四个原理，差不多就能明白BW的初衷和目的。
1. 简单
减少了建模对象的类型和源系统的接口。
维护数据对象和数据量更简单了。
复杂的数据生命周期管理现在是基于多温度的数据概念了。也就是冷-暖-热数据的概念。
2.开放
BW4的模型可以直接开放成外部可用的HANA计算视图，可以直接被SAC或其他的应用使用。
同时能和外部数据虚拟集成，比如用SDA直接和外部数据库数据连接，近乎实时连接数据。
对于云端数据源也能有集成方法。
3.现代化的用户接口
终端用户：SAC、SAP BO
建模开发：Eclipse里的BW Modeling Tools以及网页单端的BW4HANA Cockpit
管理员：网页端的BW4HANA Cockpit（不用GUI了）
4. 高性能
计算和操作都下推到HANA。
能访问HANA的特定库。
1.5 架在BW4HANA上的BPC计划
现在是BPC2021了，和BPC11.1的区别在于，可以不用安装BPC组件就能在BW-IP（Integrated Planning）上用Planning Application Kit(PAK)计划工具集。但是呢，BPC的license还是得单独弄的。
也就是说呢，如果你喜欢在本地上搞一个计划，那么就可以直接用上了。但是SAP以后肯定是倾向于在SAC上搞计划的。
1.6 BW现在用什么工具做
现在用Eclipse里面的BW Modeling Tools.
还有BW Cockpit, 这个里面也有好多好玩的工具。在里面建处理链，创建分析授权，有一种现代感。
还能监控处理链，修复处理链，查看log。
对于数据量，还能看到存储空间的使用率。
还能看到ADSO的请求管理啊，删除激活请求。归档的请求。请求日志。
信息对象的内容，请求等的。主数据展现，层级维护，query的预览都能行，还能增强加一些条件，例外啥的。
在上面多看看就熟悉了页面操作了。为彻底脱离GUI做准备。
你还可以加所有的APP。凡是你能找到的，都能加上去：
咱就是说，还记啥Tcode。不过确实有点慢的。😂
2. BW4HANA中的建模武器库
2.1 InfoObject
第一，信息对象。小兵将。哪里需要搬哪里的一块砖。
主要本领：搞主数据管理。
地位如下：
虽然说现在可以直接基于字段创建ADSO，创建Open ODS View了。但是信息对象还是必不可少的。因为信息对象它是一个类似域Domain的概念。哪里都能用，能被重复使用。相当于一个全局的可复用的一个单位，能保证很多数据的一致性。
2.1.1 基本属性：主数据、文本、层级
2.1.2 数据安全属性、计划功能
2.1.3 非累积特性
2.1.4 例外聚集
2.1.5 增强的主数据更新
现在我们建一个新信息对象，可以看到属性里有几个新的功能：
增强的主数据更新 Enhanced Master Data Update：这个的使用场景就是，比如你有很多个客户端要向这个主数据加载数据，那我们还是一个一个按顺序的加载。并行加载数据是不行的。一般主数据加载我们还都是全量加载。主数据的增量抽取默认不支持的。
而且一般主数据的量都不大，数据加载到属性表或者文本表之后，就会立刻被激活了（没有像ADSO那样需要单独激活的步骤）。
那这个增强的主数据更新是干嘛的呢？
当我设置了增强的主数据更新，也就等于这个信息对象的更新模式变成了ADSO，数据加载的过程中会需要激活这个操作了，那就会额外多出入栈表，激活表和日志表。更新主数据之后，需要再来一个激活操作了。既然有了change log表， 那就又说明你能在这个信息对象到另一个信息对象之间执行增量抽取的操作了。或者说从这个信息对象到另一个ADSO之中都可以执行增量操作了。
而且也能让你同步从多个数据源端加载数据了。
一旦设置了这个增强的主数据更新，你就能看到好几个多出来的新表:
同时，因为有了这个入栈表和日志表，所以处理链处理的时候，要加主数据的激活操作和日志表的删除操作：
这个就是在主数据数据量特别大，数据来源很多的情况下有用，同步抽取更快点，上层能执行增量抽取。但是由于还得多一步激活，所以如果数据量不是很大的话，也没必要搞这个。
而且这个增强的主数据更新只针对于属性和文本，不适用于层级。
2.1.6 支持写接口的信息对象
在增强的主数据更新下，还有一个写接口。这个是啥呢？
这个只有你勾了增强的主数据更新之后，才附加出来的一个功能。那么显然是和这个增强的主数据更新有关的。一般写接口的意思就是可以直接更新，这个也是一样的。可以在没有数据源，没有转换和DTP的情况下让你去直接更新入栈表。啥个意思呢？
不是直接手写的意思，这个写接口是说让你用一个工具像是SAP Data Services或者是SAP Cloud Platform Intergration(CPI)把数据推进去。同理也是只适用于文本和属性。
这个和ADSO的写接口不一样的。这个信息对象的写接口由于只适用于属性和文本，所以它最多可以有两个入栈表，就是针对属性和文本的请求的入栈表。
当设置了写接口之后，就会发现多了几个URL：
这些URL就是来调用写功能的，属性和文本都有不同的URL。在function group RSO_PUSH里面能看到这些RFC的功能模块。这些和ADSO的写接口的功能模块是一样的。
只不过参数里面改了object_type=IOBJ/object_subtype=ATTR/TEXT。
2.1.7 Odata服务
这个Odata就是说可以让你从外部网页去访问这个Infoobject。通过URI（Uniform resource identifier）来直接访问。这个Odata我们用的多的还是在query上。
这个Odata也是比较有意思的，架在ODATAV4网页协议标准上。勾了这个服务，然后直接接活就可用了。但是这个Odata对信息对象有种种限制，不能是参考特性，必须得有属性，不能只有文本，不能有地理属性。而且Odata读不了层级。如果是时间相关的，还得给个时间范围参数。
一般不用。
2.1.8 导航属性和转移属性
特性的属性就是用来描述这个特性的，有时候属性还有自己的属性。比如业务伙伴有个国家来描述它，国家又有首都这个属性。
这里能看到传递属性是true。我想看首都这个属性是可以通过维护转移属性来把它显示出来的。（前提是country国家已经被加到属性里了）
那么到这里其实有个问题了，作为第二层的国家这个导航属性，是可以作为一个独立的特性来在query里查看的。那么这个首都作为国家的传递属性，可以也作为一个独立的特性在query里来使用么？
答案是可以的，因为它在这里就是被勾了作为导航属性。既然作为导航属性，那它就可以用来聚集关键值了。其实这个转移属性也就这个应用场景。至于底层的原理，就是HANA帮忙搞的了。
有一点就是，导航属性要想在query里面用。这个query必须是得架在CP上的。不能是直接从ADSO出来的。只有在CP里才能enable ADSO里面的特性的导航属性。 （除了在output的字段里按字段打开，还能在senario 里点击ADSO里直接全部打开，然后映射到output里）
不过，信息对象的导航属性虽然无法在ADSO里直接打开，但是能用在转换里，在规则look up里间接用上，也就是说去找这个源字段的属性字段。
2.1.9 时间相关的导航属性
2.1.10 时间特性的导航属性
对于一些时间特性，能直接在query里用上他们的导航属性了。
也就是说，比如在ADSO里的条目是直接在日期这层上的，那么用上日期的导航属性，比如月，季，年。那query里能直接在这些高时间维度上聚集关键值。
2.2 ADSO
新的ADSO能有1000个字段（包括字段和信息对象），能有120个key。
2.2.1 简单来讲ADSO有四种类型：
不同的选项决定了ADSO的功能。以及它里面的表。同时这些ADSO还会有一些附加的功能，下下面的特殊属性里。比如说库存功能，计划功能，写接口功能。
1. 标准
使用的最广泛。主要就两种：
1.1 有change log表
change log表就是存储更改变化的，有了这个日志表就能看到所有的新加的，删除的，更改的记录。然后基于此表能往上出delta抽取。有了日志表也能对本身ADSO进行回滚，也就是说删除已经激活了的请求。
所以，一般一些比较重要的交易数据，都用这个标准的有日志表的ADSO。
对于Snapshot快照。 就是如果你的数据源只支持full全量。那么选了快照，就可以把从数据源那里删除掉的记录给更新过来，要不然。上次存储的，下次抽取的时候被源头删了。它还在ADSO就不对了。这个机制就是激活的时候，系统会比对激活表里已经有的数据，如果这条数据在入栈表里没有，那就写到日志表里，当成一个反转像。reverse image。再激活的时候就会相当于冲销一样给删掉了。
对于Unique Data Records。单一数据条目，主要就是这条数据是没有重复值的。比如说非累积关键值的条目。激活的时候，系统检查是不是还有重复条目，如果已经有了这条主键了，那激活就会被取消并且报错。整个流程就只有插入操作。所以比较快。
1.2 没有change log表
如果说不需要往上层增量抽取数据了，那么就直接不要日志表。这种情况也支持单一数据条目。节省系统空间。
2.数据集
业务相关数据集。和infocube一样的。主要用来分析数据和出报表的。
这个ADSO里的所有除了关键值以外的特性都是主键。也就是说你这条记录如果有一个字段改了，那么就会有一个新的组合主键生成，就会有一个新的条目。不会有特性的更新或者删除，所有的更改都会被动保留。
所有的关键值都只能被聚集，不能被覆盖。激活的时候，到激活表实际是被从入栈表复制过去并且按照聚集的方式来分组，相当于压缩操作。此后，数据从入栈表删除。没有日志表。
请求在未激活时可以删除，激活后由于没有日志表所以是不能回滚的。
往上层的delta抽取是从入栈表出来的。在没激活的时候，从入栈表增量提取。
全量和初始化抽取时从入栈表和激活表同时提取的。
报告是从入栈表和激活表组合抽取的。所以不激活入栈表也能看到所有的数据。
2.1 库存ADSO与非累积关键值
库存的ADSO会多出几个表：
- Validity Table: /BIC/A**4
- Reference Point Table: /BIC/A**5
添加了库存关键值信息对象后，比如说是库存余额，系统就会给你加一个新的页签Inventory.非累积关键值一添加，自动会添加对应的更改关键值，比如说inflow的和outflow的两个关键值，进入的发出的。
同时会有两个附加的表：生效表4表和参考点表5表。
参考点用来计算非累积关键值的，是和日志表一起更新的。
所以说这个数据集的ADSO必须得有一个日志表。而且这个ADSO不支持字段只支持信息对象。
对于库存非累积场景，还得看具体的介绍。
3.staging 分段
也就是在数据加载的第一层，在inbound表里就需要进行对数据的协调处理，或者和其他数据合并了。等于说是在PSA层进行数据的预处理。
选择只有入栈表，由于没有激活表，所以加载数据非常快。这个就适用于我想快速把大量数据拿过来。
当我想对大量数据基于一些我设置的语义主键进行压缩，那我就选上compress data。 压缩过后入栈表会被删除，能节省一大部分空间。由于没有日志表，只能按需删除特定条目，不能回滚删除。
如果选了允许报表，有个不同点就是，入栈表的数据不会被删掉，依然会保留。也就是会有个冗余，那么在激活表上可以出报表，之后激活表数据删除了，还能从入栈表重建。只有激活的表数据能用于报表。不过我觉得这个就只是用来快速查看分析下数据，看数据对不对，实际建模场景没有广泛使用。
4.直接更新
不需要再有激活的步骤。直接跳过了标准的加载流程中的激活步骤。也没有入栈表，直接激活表。
可以直接建标准的转换和DTP来抽数，或者通过API：
-
RSDSO_DU_WRITE_API / RSDSO_DU_WRITE_API_RFC: 从内表加载数据到激活表。
-
RSDSO_DU_DELETE_API_RFC: 删除激活表数据，可以直接truncate或者选择性删除。
-
RSDSO_DU_CLEANUP_API_RFC: 删除出错的API请求，如果有时候请求发红阻断下一个了，那就用这个删除。
4.1 写接口
选择写接口能把数据转移到入栈表，也就是PUSH进去。
2.2.2 ADSO中的表
1. inbound表
1表。未压缩表。里面有Request ID，Data Package,Record number, Record mode。
系统生成技术主键key：REQTSN+DATAPAKID+RECORD
2. active表
2表。压缩表。里面有Key 字段1， Key 字段2...+Record mode.
用户定义语义主键：Key 字段1+Key 字段2...
3. changelog表
3表。里面有Request ID，Data Package,Record number, Record mode。
系统生成技术主键key：REQTSN+DATAPAKID+RECORD
除此之外还有6,7,8表：
6表 提取视图
7表 报表视图
8表 外部SQL访问视图
由于1,2,3表是不允许外部直接访问的。所以SAP提供了一个8视图，来给外部SQL访问。也就是说这样的话在分段ADSO的转换里，就能用ABAP的例程或者是AMDP的SQL语法来执行查询操作了。一般我们在例程里也就搞个look-up。
为啥不允许直接访问? 因为ADSO上是有分析授权的。有些权限相关信息对象是用来限制访问权限的。如果开放给外部访问，那这些设置岂不是没有意义了。
所以这个8视图有点像External SAP HANA SQL view,开放给外部，去除了访问限制。
不过HANA计算视图是可以有访问限制的，要配置参数的。
如果说看不到这个8视图，重新激活下RSDG_ADSO_ACTIVATE 就可以了。
中间缺的4,5表在库存ADSO里。
9表是数据温度管理的例外更新。更新到外部冷存储里的。
2.2.3 SID的生成
代理键主要是雪花模型用来复用维度信息对象的。
在ADSO中一般是只保存特性的值，不保存对应的SID。那么当进行query查询的时候，系统就会在query运行时给每一个特性去按值join它的SID表。这样就会导致性能变慢了。如果你这个信息对象在报表内用的很频繁，而且可能它有很多值（俗称高基数），那这种情况下我们就得考虑在ADSO表里给添加一个独立的行来保存SID键值。加快查询的速度，不要让它去join了。
至于要不要保留SID键值，用这个report来查看就行了：SAP_ADSO_DESIGNS
2.2.4 ADSO重构 remodeling
重构也是比较有意思，一般新加属性会在激活的时候自动要求重构。（ADSO已经有数据了）
其他情况下要替换属性也是要重构的。不过替换的话对这个特性有一些限制，不能是参考特性啥啥啥的。
重构进行的操作主要就是为了能更快重新激活有大量数据的ADSO。基本上有对ADSO表的读或者写的修改都需要重构。必须对建模属性更改了，从staging变成standard了，对主键有更改了，对planning的切片有更改了，或者对数据分层有更改了等等。
重构的请求在RSMONITOR下面能看到。或者直接在网页上看。
重构的ADSO传输到另一个系统，也会让你重构，要不然激活不了。我一般传输后重构，然后再重新传输一遍。
2.2.5 处理链中对ADSO数据加载的处理
触发增量合并：把数据从增量存储空间转移到主存储空间。
drop data target：删除ADSO的所有内容。
clean up DSO request：从入栈表活日志表清除请求。对数据集ADSO还能删除激活表请求。
还有一些有用的管理ADSO的tcode:
RSOADSO:展示数据和数据模型，检查激活，管理数据条目，写传输请求，生成where-used列表。
RSDG_ADSO_ACTIVATE:激活ADSO，修复一些模型定义中的小问题。
SAP_ADSO_DESIGNS：分析ADSO大小，计划清理活动。
RSDD_IPRO_KEYFIGURE_CONVERT 货币转换。
2.2.6 ADSO增量数据加载中的delta merge增量合并
由于列式存储主要对读取数据友好，但是写入数据那就一塌糊涂了。所以内存式列式存储就给分配了两块空间，一块是优化读取的主存储，一块是优化写的增量存储。读的时候，主存储和增量存储同时发力。写的时候数据库会来执行增量合并的操作。
增量合并就是来把增量存储里的更改转移到主存储里。首先执行一个异步检查看是否有必要进行增量合并。 如果存储阈值被超过了，那就会在增量存储里执行一个合并。然后读取操作会从主内存和增量内存里进行，结果是被合并过的。
一般是在处理链进行增量合并，因为你可能有很多个更新到ADSO的DTP，等所有DTP都更新完了之后一次性合并最好。
而且这个合并一定要搞，因为HANA的增量存储空间也是每个分区只能20亿条数据，如果不搞，那数据读取的性能将变的很差。
2.2.7 ADSO中大数据量处理及数据库分区
对于那种ADSO里有巨量数据，而且在不断增加的情况。急需要考虑管理数据增加了。
有哪些方式呢？
索引：附加索引，不会减少数据量，只是提高访问速度。主要索引会默认生成，主要就是给组件特性生成的，为了加快主数据表和ADSO之间的join速度。次级索引就是在你需要进行一个非常复杂的需要消耗性能的查询的时候，你可以建。建索引当然是要消耗内存的，还需要索引服务器的一些更新处理。只有在性能是在需要索引的时候才走这一步。
数据库分区：高基数的会自动被分区。我们一般也会按照年份，区域对ADSO数据进行分区。每个分区会自动获得20亿条的容量。也就是一个激活表分3个区，那能存60亿条数据。
语义分区：按照语义组分区也要考虑到。
数据生命周期管理：按照数据重要性和访问频率来管理，把不经常用到的老数据放到一个外部数据库上面，SAPIQ啥的。这样就会导致HANA数据库上的数据量减少。
清理：直接把不要的数据删除掉。
