BW DW - 01 主数据与交易数据

要知道数据仓库从90年代诞生之初就是为了缓解业务系统的报表压力的。当业务分析越来越多，源系无法承担后。一个权宜之计就是用数据仓库：把数据都备份出一份到单独的分析系统去。数据被周期性的抽取和储存到分析系统去。一般都是夜里搞。但是近年来，现代化的数据仓库还能远程在线直连数据源了。那这样的话，其实有些数据的加载和储存就没必要了。
客户现在要考虑的是，哪部分数据是要加载并且保存在数据仓库里，哪部分是要直接远程连接的了。考虑的点是性能需求。如果你远程数据源数据量很大，而且需要进行复杂的逻辑处理，那不可避免的如果你远程给直连，报表的性能就不可避免的差。
如果你这个数据量小，而且实时性要求很高，那你就直连，不需要冗余存储在BW里面。直接用BW建模来出报表。
一般数据获取和整合后需要进行聚集计算啦，计算新的指标值啦，转换货币类型啦，添加层级啦。
数据仓库最根本的用途就是提供一个企业完整准确的历史数据集，所有粒度级。也就是任何维度的分析都可以，只要你有这个维度，我就可以提供这个角度的分析，而且要准确。现在硬件 便宜了，物理存储还可以放在便宜的介质上，比如data lake。
但是不论放在那里，都是要提供准确的单一数据来源的。

数据仓库解决方案

SAP现在提供的数据仓库解决方案有三种：

1. SAP BW/4HANA
   一整套工具集，快速配置企业级数据仓库。
2. SAP Data Warehouse Cloud
   云方案，给企业用户提供简便的个人服务来获取，建模和分析他们自己的数据。
3. SAP SQL Data Warehousing
   也是SAP的工具，用来从头开发完全客制化的数据仓库解决方案，严重依赖SQL开发。
   所有三个解决方案都是基于HANA平台。
   
   BW４HANA的前身是BW，完全用ABAP写的。并且BW是需要一个数据库的。你配置BW的时候得给它配一个数据库，Oracle啥的。然后后来有了BW Powered By HANA ，然后 又有了BW4HANA Add On，然后就是全面替换掉其他的数据库，不跟其他人玩了。还是挺狠的。Add On的时候就不允许旧的对象再新建了，只能维护了。
   
   到2016年，SAP完全重写了BW，让它在HANA数据库上游刃有余。原先ABAP代码为了满足各种 数据源，非SAP的数据库，现在HANA优化的ABAP代码把处理直接推到了数据库层，也就是数据存储在哪里，就去哪里直接处理。重写的BW版本就是BW４HANA，而且只用HANA优化的建模对象了。也就是ADSO，OpenODSView啥的。至于代码的优化，举个例子，原先在BW的转换例程里写的代码，DTP处理时是要把数据全都取上来，然后再进行逻辑处理的。现在直接换成AMDP处理方式，数据直接在数据库处理完了再拿上来。这样就会很快。

由于BW4HANA是一套工具，它还提供了支持连其他数据源的工具的。可以夜里抽，也可以实时抽到BW4HANA。许多源系统也是支持只抽取上次抽取后改过的或者是新增的数据的。这就是Delta抽取。
至于抽取机制。待会来写。
对于数据的抽取，SAP ERP里面是有备好的数据提取器的。至于其他的源系统，那就要自己写提取器，用它提供的工具来抽取了。
由于数据一路上到存储对象里，比如ADSO，所以转换用来清理数据，用lookup或者formula填充一些 丢失的数据啦，可以检查数据质量，标识一些坏数据。数据加载完成后，可以用工具建模，比如增加i一些额外的业务场景，分配货币单位给计量值，定义层级等等。
建模层主要就是由物理存储数据的对象和逻辑视图对象结合起来的。最终用户可以使用建模好的数据来分析。
但是一般业务用户建query都是用逻辑视图来建，CP啥的。建一个表的样式，定义小计啦，排序啦，附加的计算啦，过滤值等等。
在Query之上还有最终的展示层，比如SAC和AFO和CR等等。。

这里要提一下BW Content，现在是BW4HANA Content Add-On了，一般系统上线前要安装的。这些内置的各种类型对象可以节省大量开发时间。但是你得激活后Copy一份自己的出来再做建模及数据抽取，防止后期SAP更新给你覆盖了。

BW4HANA和S4HANA内置分析

之前讲了，BW4HANA实际上是个数据仓库，为了解决ERP系统作为一个业务系统里自己分析自己的数据会压力大的问题。那么S4HANA当然也是有自己的内置分析工具的。比如说大家都知道的ABAP写的报表。
但是这种就相当于写SQL写出来的，一个要求写一大段代码，修改起来很困难啊，而且重用性极低啊。但是它快，所以说这俩不冲突。
这是说以前啊，现在S４HANA了，有个新概念叫CDSView了。这些view囊括了主数据和交易数据，而且实时。而且内置分析也提供一些报表，dashboard，以及一些KPI。

看上面这个图就懂了，一些操作性的报表，完全可以ERP自己出，那BW就用来处理一些复杂逻辑的，实时性要求不高的ERP的数据表，同时，用来处理其他系统的数据。
那么一句话来分析，现在BW还不能被取代掉，ERP可以提供操作分析报表，BW用来提供策略分析报表。

理解一下HANA 到底是什么

他是个软件+硬件
硬件不值钱了就可以多搞点内存空间，多搞几个CPU，并行处理搞起来。巨大的内存和多核处理器是HANA的硬件基础。
以前，数据都存储在硬盘上，要用的数据才被取到内存里做处理。现在呢，所有数据都放在内存里。那就是不需要从硬盘到内存这一步了。只要你要这个数据，那立刻马上，我就能拿到。HANA就是个内存式数据库，也就是不需要硬盘。但不是说它没有硬盘。你可以自己决定把历史数据放到硬盘里的。硬盘毕竟便宜很多。
软件角度来讲，HANA　包括很多数据处理引擎。一般来讲BW是个应用，架在数据库上的。而现在HANA把一部分应用集成到自己上面了。也就是也不需要把数据先传到应用层做计算然后再传回到数据库存储，就直接数据库里弄。省时。
还有一个就是它的列式存储。我之前写过了。有利于读。然后还弄了两个main storage 和 Delta Storage的。这个太底层的，有空再写了。
为啥要搞列式存储，因为query天然适合这个。因为绝大多数情况下，我们建一个query不会去拉它所有的列。如果你读一个行存储的表，无论如何你得把所有的行都读一遍。于是你不需要的那些列值也都被读到了。就很费时。
列表加载时会自动压缩。去掉所有重复列值。而且 会有个单独的字典和索引表来重新编码 这个列表，来匹配原值之间的关系。看到这里其实不麻烦。因为你要知道列值是一定会大量重复的。弄字典和最后的索引表其实是为了更快的存储和读取。

每一列都会有一个字典。这样读取会很快，而且省空间。
至于说很久以前，Cube上面的聚集和压缩。现在都是不需要了的。要理解聚集的含义。因为Cube上面是累加值。（此处讲的是非库存类型Cube）所以，当有新的数据进到表里，那我们需要执行聚集的roll-up。当然这一切都是为了报表的性能。roll-up包括一系列啊，要额外空间的，还要建聚集，监控，删除等等。那HANA里面为啥不要了呢？因为一切都在HANA的内存里面弄了。
以前需要的索引，要建，要删，还要重建。要额外空间。在索引删除重建期间不能访问数据。HANA由于强大的性能，基本上不需要索引了。
在BW4HANA上，主要是处理属于BW4HANA的表，而在HANA上，既可以处理B4HANA的表，也可以处理其他非BW4HANA的表，用Schema来区分，对于其他应用的表，你可以自己建Schema。
对于不同的Schema，HANA可以建Calculation View来结合。也就是混合建模。

对于ADSO层的，由于它也是存储在HANA上的表：所以一些routine的处理也都直接在HANA层了，不会说先从数据库层拿到应用层做处理，然后再保存回到数据库上。这个要选择下HANA　runtime，而且要改ABAP代码了。一句话就是代码下沉，先处理后转移数据。

主数据

主数据，就是有属性，文本层级等等的特性信息对象。
你要建一个有主数据的信息对象，前提是你对业务有精准的认识。
就比如你得知道不同客户端的成本中心编号有可能是一样的，那你得给个client做组合对象，要不然数据整合到一起但是不是一个公司的，那就乱了。所以说业务上的主数据你还是要很清楚的。这个嘛，光看技术也没用，得和实施顾问聊聊。
这里提一嘴导航属性和显示属性，导航属性就是你可以单独用的。显示属性那就是只能是你这个对象的附庸。对象不在这，你也不能单独在。你只要在了，你这个对象必然在。但是导航属性，你在info provider里面设置一下，就可以独立出来用了。
如果你不设置，那它只能从对象下面拖出来，那就和显示属性没差。
还有一个比较有用的是时间相关，给属性加上时间相关，它就会带一个时间范围。

主数据的删除

主数据还是交易数据啥的，都是从 源系统抽过来的，用DTP按一个请求 一个请求来抽的。请求里写了是什么个抽取方式，一个请求抽多少条数据。

那么。对于属性文本和层级这些主数据啊。

我如果抽的错了，怎么去删除重抽呢？

光删除这个请求是没用的 ，还要删除数据的：
但是肯定有一种情况是这样的，如果你这个主数据已经被上层ADSO用了，那就没办法直接删除它了。只能从上往下删，不能从下往上删。也就是说没有交易数据用到这个主数据过。而且你这个对象也不能被别的对象用成属性去了。删除层级的话得是 另外的方式。
或者说你剑走偏锋，你知道那些主数据从源头已经被删掉了，你直接selective deletion。
你执意去删主数据，那删掉的也都是没有被用的主数据。然后你再去看那些数据被用了，再继续删。。。（哪些能被删 ，就是下面讲的SID只打了第一个勾的。）
删了后，你去看log，你能看到 哪些没被删的是被用在哪里了。哪些是被删掉的。
去SLG1去看log：

所以说，一般情况下，主数据不太好删的。

对于是否删除SID表呢。
删除了之后呢，如果你有新的属性再加载，就是会加载过程中生成SID时间有些长。有时候，删除SID表会导致数据不一致的问题。但很少见，这是系统提示where used不全导致SID没全删。
保留SID呢，是默认操作。有很多情况下我们不是去添加一个新属性，而是去删除一个已有的属性的时候，我们要把这些旧的删除掉，这样就保留SID就行。
只有必要的时候我们会去连着SID一起删，比如你这个特性信息对象的Key都变了。那就重建吧。

SID表的概念

要理解SID表，你脑海里就要有星型模型的图。
中间是事实表，周围是事实表中的列对应的维度表。维度表再连接主数据表。维度是一个个编号。那么SID表是什么，存在在什么位置？
SID表就在维度表和主数据表中间，维度表里存放的不是实际的维度值，而是SID的四位数字编号值。这样操作虽然复杂，但是好处是读取迅速。

SID其实是特性的编号。特性在这里就是像成本中心，利润中心这种信息对象。对于有组件的信息对象也是一样。这些SID表在不同阶段生成，SID Table在上层用到这个特性时会被生成，attribute SID表是主数据的所有导航属性SID表。主数据加载时会生成。

如果你去查看这些SID表 ，你能看到：



有三个flag，光看这些描述其实还是一头雾水。其实这三个标识是告诉你，其他地方用到这个主数据了。你不能删它。这个是基于where used list的，因为你没这个功能，这三个X也不知道怎么打。
这三个X一打，就是给你这个主数据加了个锁。为了保证数据的一致性，我不能给你乱删。
CHEKFL： 被对象用着呢（主数据自己）。
DATFL：被其他CUBE、ADSO或者信息对象用着。
INCFL：被其他层级用着。

如果只打了第一个勾，那就是只有自己加载了自己，那就可以删除自己的主数据。

虚拟主数据

在什么情况下需要创建这个虚拟主数据呢？注意是说虚拟主数据，不是虚拟信息对象。
这个信息对象是一样的创建方法，是带主数据的。不是关键值的。关键值的不能虚拟。
那这个主数据为啥说是虚拟的？从哪里来呢？
是从HANA的view来的。

你要选择主数据从HANA的view来，然后选package，选view。把view里面 的字段和主数据的属性及文本一一对应之后再激活这个info object。
要注意你这个信息对象是要和HANA View的主数据特性对应起来的。相当于是主键连接。最后刷新数据，也就是从HANA View直接读数。这是不需要从数据源抽数，也就是虚拟主数据。

一般数据源与ODP

数据源有好多种。SAP的现在统一用ODP的方式。ODP也就是用RFC（ABAP系统）和HTTP或者HTTPS的通信方式（ABAP系统以外）。

那么以ODP方式抽取，那前提得是你得有个Operational Data Provider。这个东西定义了交易数据和主数据的接口。对于 SAP的 源，都定义好了对应的Provider了，它们都通过operational Delta Queue来传。大家都在队列里。
你可以套用它的ODP，也就是说在SAP Extractor上右键新建数据源，直接借用它已有的Operational Data Provider作为来源。
如果你这个源还能 传递数据改变的值，那ODP也支持增量处理。
也就是说ODP是一个框架机制，在SAP源那边配置好了相应的接口，那就能通过ODP来抽数了。
对于一般数据源呢，也就是客户定义数据源，在SAP源系统的SBIW里面去看。
这个SBIW里面有Business Content数据源和Generic 数据源。其实分别对应RSA5和RSO2.

一般我们创建数据源的最简单的方法就是去建基于view的数据源。se11建 一个基于主数据表的view，然后再去创建一个数据源。可是好像S4HANA之后都要用 CDS View了。

通过ODQMON我们来监控Delta Queue，在queue里数据都是压缩的，你能看到一个队列会有好几个request，因为有好几个target去请求它。当然也有那种一次性Full的抽取，那就会只有一个一次性的请求，下次看不见了。在这个queue里一般都是Delta请求。
而且queue里面数据的保留时间是可以定义的。以防你BW那边ADSO抽数有问题，需要重新抽取一次。你可以设置数据保留时间为一天啥的。
你这里有四个可观察的内容：
1.queue系统所有队列及状态，请求该队列的目标及请求数。
2.subscriptions 谁请求了这些队列。
3.request 请求的详细信息。
4.unit 哪些请求的数据可以被共同传输。
自建的数据源，然后你把它replicate复制到BW那边去了，然后再去激活它才能用。这中间，是RFC在起作用。然后用ODP的方式抽取。因为你自建的激活时会会自动发布到ROOSATTR这个表里。直接可以用ODP的方式。

如果没在这个表里面，这个FLAG没打上，那你就可以去下面程序去发布去。

那你可以用程序：RODPS_OS_EXPOSE

把你自己建的这个数据源也给发布了，发布到ODP去（注意这里是它没自动发布到ODP框架时候，你才去用程序发布）。这样你的数据源会出现在上面那个ROOSATTR的表里面。
这里可能会有一个疑问，那是 什么一样的extractor会出现在Delta Queue里面呢？
自建的已经发布到ODP了的，会出现在队列里面么？
如果按照这个思路走下来，就是所有ODP的数据源都会出现在queue里面才是。

暂时不管这个问题，要知道一般我们分析数据是从BW的info provider出的。虽然info provider的最底层也是data source。
但是，有了ODP Operational Data Provisioning，就有了一个元数据的概念，Analytic query可以直接在业务系统弄起来了（业务系统本身也有一套ETL和增量处理机制）。其实是因为Operational Data Provider本身就是由data source extractor 来的，它就不是单一的数据源，实际上是有主数据相关的业务数据这种信息的了，所以基于ODP，ERP自己也可以出报表。
那么同时，对于BW而言，由于ODQ里面存储的是压缩了的数据，而且由于它这个ODP的框架，使得直接通过DTP就能把Delta的增量拉过去。不需要Infopackage再去存一次了。

那么一个Delta Queue到底是啥？说他是队列，实际上它是实际存数的。要么是原系统直接更新进去的，比如说是0CO_OM_CCA_9，要么是用抽取器抽过来的，像是0COSTCENTER_ATTR.
一个数据源可以提供不止一个delta queue，因为要它的可能不止一个人。一般数据源啥名，它就是啥名字。也可能一个人要了不止一个数据源，啥时候我要这个数据，那就会有这个队列。这个它请求上会有时间。一天要几次也是可以的。还有一种情况就是我一次性全抽，这个就没有后续的增量队列了。
在队列中数据会有保留时间的，这个会要自己设置的。

层级的加载

相较于属性和文本的时间相关，层级我认为要更复杂一点。结构来看就相对复杂。
从分组的观点来看，它就是有很多的节点，很多的叶子。所以就组成了父节点与子节点的关系。层级既可以自己建，也可以从原系统抽取或者从其他文本文件或者是其他系统抽取。

有几点要注意的是，一个参考另一个信息对象建的信息对象是不能有层级的。
一个层级下面可以有很多个不同的版本，但是特性的值加上compounding也不能超过32位。（这个我就不太明白）
还有一些正负号的应用场景，以后遇到了再写吧。
写了也不明白，这些只能自己去试，去看那些不同的转换对应的不同的表。我感觉Hierarchy的表还挺多的。对应很多不同的内容。

未解决问题

到了这里，还是有很多未决的问题需要在以后的工作中慢慢解答：
1. 是不是只要以ODP的方式加载数据就会出现在ODQ里面？
2. ODQ的队列到底怎么实现的？有什么顺序和时间上的操作么？原理是啥呢？
3. 主数据清理的实际场景和解决方案。
4. SID表填充和删除的场景，维度表和SID表的外键关系。

交易数据

在写交易数据之前我们要知道，放交易数据的容器是啥。
主数据是放在信息对象里的。
信息对象包括 特性，关键值，单位。
那么除了这个最小的放主数据的存放单位。我们交易数据的容器是啥呢？
是Info Cube和ADSO， 是的 ， Info Cube过时了，但是它的灵魂依然存续，那就是：
Data Mart数据集市类型DSO。

标准ADSO

1. write change log ，选了这个就是有Delta会保存在change log表里。那么再往上层的Delta抽取实际上都是从这个change log表出来的。也就是说这个是上层Delta的表的根基。也是有这个日志表，请求才可以被回滚。回到激活前的状态。
2. snapshot support，快照 ，这个是得你的数据源不支持增量，只能全量抽取 ，那你选这个。可以识别数据源那里被删除和更新的数据。当你激活的时候，系统会识别在激活表里但是不在inbound表里的数据。然后这些被删除的数据会写到Change log表里作为reverse image反转镜像（所以如果数据源条目有被删除的可能那就选全量更新啊），再往上层更新呢就从change log出。
3. unique data records，你确定你数据源没有重复的，那你就选这个。这个呢就是你激活的时候系统检查如果你有重复条目了，会直接给你报错 。
   

staging DSO

1. inbound queue only就是只有inbound表啦，所有请求只进到inbound表。
2. compress data只有激活表。当你激活了表，它数据会压缩。就是从inbound表直接一步进到active表。激活的时候，数据根据语义键来聚集并写入激活表。没有change log表。不能删请求，只能selective deletion。
3. reporting enabled 数据被写入active表，同时保留在inbound表。由于数据在inbound表是会冗余保存，那么数据从active表是可以被删除并且从inbound表重建的。查询从active表出。

Direct Update DSO

直接更新到active表，无需激活。只能全量抽取。数据抽取完就可以用来出报表，但是有一点，DTP执行的时候会检查SID啦，时间特性啦，有没有被NLS或者冷存储锁住。

Data Mart DSO

数据到inbound表，然后你可以激活到active表。激活表就是聚集执行了，请求号就删了。一激活呢，inbound表相应数据就被删掉了。没有change log表哈。
即使你没激活呢，出报表的时候数据也都是从active表和inbound表一起出的。只不过一般都激活。

对infoprovider的理解源于对数据该如何处理的理解。这又要回到一开始我们需要BW的目的上来了。作为一个分析系统，我们是为了进行复杂的分析处理的，对于大量历史数据的快速准确的分析。
从SAP源头来的数据先是存储于ODQ中，然后需要冗余地存放在BW的物理层，例如ADSO和Cube（也就是数据集市ADSO），再往上层，我们需要一个view来出报表，就是composite provider。这是个通过主外键把很多物理表连接在一起的结构，最后跑报表的时候才会真正去取数。
回到infoprovider的概念上来。
主数据特性是一种infoprovider，ADSO是一种infoprovider，Open ODS View也是一种infoprovider，以及最顶的composite Provider。

从上图很清晰的看出标准ADSO和数据集市ADSO的区别就在于一个是明细数据，一个是聚集数据。也就是之前和Cube的区别。
从最底层的数据源，也就是告诉你数据原始位置与结构。
ODQ也就是以原始格式保存所需数据的。
看一个明细表的内容：
这种一般都是存储明细级别的长年的数据。
而DataMartDSO用来存储总计的做了复杂计算的长年的数据。因为做明细数据的报表很费时间哦。

对于最上层的CP，他是个虚拟层，可以连接主数据，DSO（两种）还有Open ODS view。

单位变量0CURRENCY、0UNIT

那么回到交易数据的原始点上，它是交易数据，那么就得有数值。这个数值就必然得有单位，金额是多少，数量是多少。大抵有这么两个类型。要么是货币单位 ，要么是数量单位。
对于金额类型的你可以选一个固定的货币单位，或者是一个货币单位变量0CURRENY。
对于一个数量类型，你可以选一个固定的数量单位，像KG或数量单位变量0UNIT。
一般都给个变量。
这个变量是啥意思呢？就是和常量相反，它是可变的。有个条件让它来变。这个条件可以是你自己去输入值，也可以是它根据什么逻辑去填入值，这就是写代码去了。

另外对于关键值，你要定义它的聚集方式。因为当它保存到BW的表里的时候，你得给它一个保存的方式了。
还有那个什么exception aggregation，这个是在报表执行的时候进行计算的。
那么回到之前的点，聚集的这些方式，在标准ADSO里是不执行的。只有当你的ADSO是Data Mart的时候才执行。
也就是说 ，你设置它的聚集，那它自己一个是没办法聚集的，只有它有特性维度 的时候才能聚集 ，而对于标准 ADSO，有激活表和change log表，也是不聚集它的。要的是明细的每一条的数据。根据需要的维度来进行聚集，这个是要在Cube和上层的Info provider里面进行的操作。
而这个exception aggregation是query上的默认聚集方法。

这里还要提一嘴非累积值，有哪些呢？人头数，资产负债，库存。
这种不能累加的，不能说这个月公司12人，下个月公司12人加一起。这些跟时间没关系的。。
不能说这个月期末余额和下个月期末余额加一起，这些要到年末来算的。库存也是的。

未解决问题

到这里还有一个问题了–那我的单位变量是怎么用的呢？
我最后是用在query里面的，那单位变量是什么值呢？

建模Data Mart ADSO

说到这个ADSO，那真是有的说了。
因为它换汤不换药，把之前那些乱七八糟的东西都放到ADSO里面了。我觉得我得暂停去写一篇ADSO详细划分。
唉，扶我起来，我还能再写三篇。。。😂
好了，这就是今天的活了。ADSO详细划分.

好了，刚才写了一下ADSO的详细划分，是的，我还没写完。但是不管了，才疏学浅，以后再写吧。
不管三七二十一，１，２，３分别对应标准，写优化，直接更新。方框对应Cube。如果有些东西你理解不了，说明这个东西对于你来说是空中楼阁，哪里断掉了。就像你让一个小学生去理解线性代数，他理解不了。因为他初中和高中衔接的那部分没学。
而在学BW的时候也是这样的，基础也要慢慢打牢。一遍理解不了就多看几遍。多练习，练习的途中停下来思考思考。

我们一般用的多的也就是标准ADSO和cube了。
标准ADSO有三张核心表。不是只有三张。
这三张表是为了支持数据的抽取。
１.　inbound表　未压缩的事实表
２.　active表　压缩的事实表
３.　change　log表**（Cube是没有这张表的）**

对于cube来说，报表读取的数据是Inbound和active结合的表。
这时**，你可能有问题，为啥？激活了ADSO后，inbound表不是空了么？？**对的，当你激活inbound表的数据，就等于说inbound表的数据先copy到active表，然后按聚集方式来被分组，最后，从inbound表删除。
但是info cube在数据抽取之后，还没激活就可以直接出报表了。激活之后，inbound表也就没有数据了。info cube设计之初，就是架在DSO上面的，DSO的active表就相当于Cube的inbound表了。如果不是DSO的数据量过大，计算过于复杂导致报表性能下降，我们也不会加一层Cube在上面。
对于Cube来说，所有特性列都是key,激活表中的关键值都是聚集值。当数据进入inbound表的时候，是通过请求号来区分的也就是时间戳，你可以在这里进行请求的删除，也就是未激活前的数据删除。但是你一旦激活了数据了，激活表中就没办法按请求号删除数据了。除非你全删。
所以他这个说报表从Inbound和active出就是前面的请求已经激活了，后面还有继续的请求没激活。但是我感觉没必要吧，直接激活了用呗。

标准DSO

对于标准DSO来讲，我们都很熟悉了。
对于关键字以外的特性，都是直接覆盖的。
关键值可以设置成覆盖，累加或者不做更新。
激活inbound表的步骤是，激活开始时，激活表里的数据按照DSO的语义主键进行排序。然后inbound表里面的数据根据技术主键排序。再然后，你可以选择不同的请求的change log请求归结为一个，还是每个请求也 生成一个change log请求。毕竟只有inbound表和change log表里面有请求号。
加载请求就是说哦我这些数据啥时候加载进来的。change log请求就是说哦数据啥时候激活的，啥时候从inbound表进到我change log表来的。

文本数据源的提取

当你去定义文本数据源的时候，也就从你本地的文件提取上去。那么你这个文件里面的内容要定义：地址，文件名，抬头行数，数据格式，编号格式，数据分隔符　。还有要注意增量处理的方式，就是怎么来提取。
一般你可以放到application　server上，就免掉放到自己电脑里。因为放自己电脑里没办法用process　chain啊。
如果数据量巨大，可以用ASCII文件。比CSV要快。注意前提是巨量数据。

对于文件数据源的类型呢，一个是Text类型就是　只包含能被展示和读取的字符。包括CSV和ASCII格式。
你去创建数据源的时候，字段名会是你的数据的列名，系统会自动检测数据类型。

至于这个内部或者外部格式，是说它是以你原本的保存到BW的格式来呢，还是以数据库里面的格式，也就是内部格式来保存。一般对于时间类型的，我们都选内部格式。

composite provider

就是用SQL写的join或者union的视图。
这就是数据结合的另一种方式。
我们用的方式要么就是在ADSO里结合不同的数据，这个是物理层的实际保存的。
要么就是用CP，是在query运行时去取数据的。
CP还有一点比较牛的，就是它能去使用HANA view。去混合建模。