SAP BW 学习笔记
SAP BW 学习笔记（一）
SAP BW 全称 Business Information Warehouse，在版本3.5之后又称SAP Business Intelligence.
处于SAP Netweaver整体架构当中的Information Integration这一层，与之并列的还有主数据管理（Master Data Management）和知识管理（Knowledge Management），这一块所谓的Information Integration，就是从企业的底层数据到最高表现层之间的一层分析的部分。但是它又不完全是在进行分析，因为这一层本身，也包含了数据挖掘（Data Warehousing），商务智能平台（BI Platform），商务智能表现（BI Suite）三个细的层次。
或许对BW的精确解释，就是如何能让企业的商务活动，变得高效和便捷的关键一步吧。
SAP Business Intelligence is an enterprise-class, complete, open and integrated solution that delivers actionable insight. 呵呵，自己解释不清楚的时候，只能抄一句讲义上的定义了。不过这个定义还是基本准确的。基本上阐述了BW的功能和应用对象。
BW的最底层，Data Warehousing。传说中的数据仓库，这一层里面主要完成的任务包括，ETL流程（Extraction，Transformation，Loading），数据仓库管理和商业建模三块内容。其中的ETL流程，通过各种途径和方法，把种类繁多的元数据进行处理，清洗，从而转化为系统所需的统一格式的数据类型，便于之后所有的需要。是BW中非常基础非常关键的一步。之后的数据仓库管理，则将这些数据根据种类，划分成主数据，PSA，ODS Objects等不同的类型，加以管理。商业建模则是数据仓库中比较难很快掌握的内容，这块内容，基本上是和客户的需求紧密联系，并根据需求建立合适高效的模型。这个技能，也不是一天两天的理论学习能够涵盖的，需要项目经验的积累。
第二层所谓的BI Platform，是BI中偏重逻辑处理的一块，它把Data Warehousing的数据，按照需求进行各种计算，规划和进一步的细致的处理，这一层更多地是对数据进行统一的处理和基本的封装。在这一层里面，完成的内容有business calculations, planning and forecasts, exception scanning, alerting, query pre-calculation, caching, background printing和data mining等。主要的产品有OLAP，metadata management，data mining，Analysis process designer and BPS（Business Planning and Simulation）。
第三块是BI Suite，这一块其实完全是在对BI Platform里面出来的东西的再加工了，主要的内容就是对BI Platform出来的内容加入一些商务智能的要素，比如Query的多样化选择，自动报表的生成，多维度的数据分析，信息发布，公开的面向第三方的分析接口和具体的Web页面体现。有了以这一块，sap的BW才显得更为文章，更为专业。
BW目前的市场很大，供需关系不平衡，近几年应该都会比较火。SAP靠它产品的完备性和强大的集成功能，一方面在项目选择上有更大余地，接受一些较为大型的项目，另一方面这个平台的推广，也给它带来了无限的商机。掌握了SAP系统软件的一些内涵，就能在这个行业吃开来了，IBM，Accenture在这一块也都有很大的一块业务。不过，他们更多地是作为SAP的partner。SAP目前最大的竞争对手是Oracle，不过Oracle同时也是SAP系统的一个支持对象，所以SAP和Oracle又是合作伙伴。哎哎，好复杂。
对了，还有一点补充一下，SAP的系统之所以这么好用，还以为它预定义了很多很多有用的模板，当实施变得轻松而美观的时候，企业自然也会觉得你更加优秀。
好了，这次就这些闲话吧，以后有了更深的了解，再来谈一谈好了。
SAP BW 学习笔记（二）
今天主要看了SAP BW中的ETL Services中的Extraction部分的前面两个引入话题的小节。（效率真是汗啊-。-）
做了一点笔记，其实几乎是在翻译了。
Extraction
Basic Principles
1, Classes of Data
Data在典型的像SAP一样的ERP系统中被分为三种，主数据，事务数据和配置数据。
先说主数据，主数据通常是组织的实体，也有作为外部实体出现的，还可以是其他的事务，比如材料（@@？）。主数据在数据仓库中的重要性就在于，它提供了多维数据分析中的那些维数。
在BW中，主数据通常又是由三种表现方式呈现的，属性，层级和文本。属性就是描述实体属性的那些域，层次则大多数是一些独立的表，它们表述的通常是主数据之间的父子关系。而文本表则是包含了主数据的一些文字表述，它们通常也被分别保存在独立的表中，因为它们通常都是依赖于语言的。
主数据的关键键值，通常因为应用而异，所以有时候即使是相类似的概念，也会根据业务的需求制定复合的信息对象（Compound InfoObjects），以适应于不同的业务类型。
层次表相对属性表来说更复杂。首先，层次中主数据的相互联系可以很复杂，第二，保存这些层级关系的技术也因应用而异，许多应用模块只有唯一的层次表达方式，
事务数据用来表述一个商业事件，或者商业过程的结果。比如一个交易请求或者一个产品的当前库存。事务数据也被分为两个种类，文档事务数据和总结性事务数据。
就文档事务数据来说，通常可以从三个部分来描述，一个是开篇部分，一个是内容，一个是时间表的内容，开头部分主要是文档相关的信息，比如作者和建立时间，内容部分是文档的详细描述，时间表则是在文档需要被划分为若干个阶段发布时候文档发布的时间表。通常最适合数据抽取的往往是最低级别的颗粒数据，因为它们的信息量也是最大的。动态的总结性数据表则多是一些冗余的对表述内容的总结。SAP BW稳定的将SAP R/3中的总结性数据的部分孤立开来。
在SAP R/3 的HR系统中，主数据和事务数据的差别不是很大的。（只是举个例子）
配置数据是整个ERP的逻辑驱动者，在许许多多的ERP软件中都能找到配置数据表，如此多的应用程序的逻辑被放置到配置数据表中，是的企业级别的软件解决方案趋于高度用户化。
配置数据虽然本意是用来定义业务过程的细节的，但是它在数据仓库中也常常得到应用，举例省略。
备注：在SAP BW系统中，配置数据被模块化为特征，并且可能包含有主数据的属性，文本或者层次，所以在SAP BW中，主数据和配置数据是不作区分的。
主数据，事务数据和配置数据就组成了BW系统中所有的数据类型，包括报表相关的和不相关的（那些专业性很强的部分数据，可以忽略，对业务的分析和汇报没有实际意义）。一些报表相关的数据需要在转化过程（Transformation）之前就要做一些改动（意即在Extraction过程中开始做一些conversion——原作没有在这里用transformation，可见转化的区别）。
2，Data Flow and Integration
SAP R/3是个包含了各种各样拥有独自的数据模型特性的系统，随着R/3的发展，不同的系统之间经常发生分歧和合并的矛盾，知道现在将R/3分为四个大块, mySAP Financials, mySAP Human Capital Management, mySAP Logistics and mySAP Product Lifecycle Management.每块由着自己不同于其他块的特性，特别是从信息系统的角度来看。当然，如果从更大的角度出发，就会发现其实他们之间还是有着千丝万缕的联系。
熟悉和了解过程流对于跨不同应用类型的建模和辨别相当重要，特别是对于关键项来源究竟在哪里如何确定。
P209，P210讲述了两个具体的例子进行了具体分析。讲述了数据流和整合的重要性。
SAP BW 学习笔记（三）
继续写ETL部分的学习体会，今天是Extraction的第三部分
Dimensions of Data Extraction (数据抽取的维数)
数据抽取的过程通常可以由四种不同的维度来进行描述和分类。
首先是抽取模式，抽取模式通常分为完全抽取和动态抽取。两者意思很明确，完全抽取是每次抽取的时候讲数据源可用的所有数据都抽取过来，而动态抽取则是每次抽取的时候只抽取更新和增加了的新的数据。
其次是按照抽取的情景作为抽取的维度，分为推式抽取和拉式抽取，推式抽取时，数据抽取和传输过程的发起者是操作的系统，反之在拉式抽取时，发起者变成了数据仓库。推式和拉式抽取的共存也暗含了一个领导角色的概念，因为在实际生活中，信息后台更多地是在和发起者进行交易。另外一种更好的解释方法是将推式抽取和拉式抽取分别比拟为信息的发布与预定和请求与反应的情形。
第三种抽取的维度是时间的滞后性，这里常用的有三种时间滞后尺度：同步的（就是实时的），不同步的（存储和转发）和不同步批处理（按需或者事件触发或者调度式的）。
第四种维度则是抽取的范畴，抽取范畴对我们抽取数据方法角度的一种描述，是从映射的角度，还是从选择的角度，还是从聚合的角度，来进行这么一次抽取。
每一次数据抽取的过程都可以拿这四种维度来衡量，SAP BW中首先符合SAP 3/R数据抽取需求的抽取器就主要是异步批处理拉式完全抽取模式。现在主流的数据抽取还都是集中在拉式抽取这一块内容，不过随着业务的需求变化，现在的数据抽取已经稳步地由动态总结表变成业务表，动态抽取的捕捉机制更加复杂化了。
动态抽取的难点在于，如果和识别那些动态变化了的部分，这里通常也有两种不同的方法，一种是用增量队列的方法，一种是时间戳判断法。时间戳判断方法比较常用，也因为它比较容易实现，所以常用。但是时间戳法有缺憾就是在时间戳被记录的时间和抽取实际开始的时间之间有段无法弥补的空白，这段时间内的文件更新将会丢失。不过也有对付这个的“安全增量”法，那就是将用户的时间戳调后几小时，这样便能避免了。
另外一种代价不菲但是质量有保证的方法就是增量队列法了，这个类似于对每次的更新和新加入元素进行记录，形成log，就是所谓的增量队列了，增量队列关键就表现为一些记录了主要键值发生变化的抓拍过程。
和时间戳法相对比来说，增量队列法不需要更多的安全方面的顾虑，它完全与数据的更新频率没有了关系，另外两者还有一个不同之处就在于，时间戳技术只能获取在抽取时间内出现的版本序列，而不是全部，相比之下，增量队列法会有一个完备的版本连续性。
不管使用哪种方法，动态抽取一个比较复杂的地方都在于，如何在互相紧密依靠的表之间的微小改变。除此之外，动态抽取的另一个挑战在与它要随时随地地面对多个不同的数据源的不同数据表的不同时间的数据更新。它却需要提供一个统一的东东，来统一这一切。
当前来讲，同步的推式抽取还不能被SAP BW完全支持，同时对于拉式的对事务信息立方体的实时更新却能够实现。这种更新总是直接性的绕开了正规的分段运输过程，它们也丝毫没有运用传输或者是更新法则，它们甚至不在SAP/BW的监控范围内。
推式抽取技术通常和增量更新脱不开干系，而拉式抽取则可以同时用于完全和增量抽取模型。现在BW中为开发报表最普遍深入的技术还是通过使用远程的信息块，实现抽取技术。这一进步的带来的最相关的就是性能了，通过使用多个提供者的模式，则会使得性能减低。然而，当需要实时的颗粒状数据时，异步抽取依然是可取的方法。
当对R/3可用的抽取器满足了选则的动态规范和映射规范时，只有一小部分是满足对集合层面的规范，对异步抽取来说，你通常可以通过直接在SAP BW中聚合数据而不是在数据源中聚合，来弥补这个不足，对同步抽取来说，这个就是无法实现的了。
1.1 SAP BW 学习笔记（四）
继续....看的好慢啊我-。-
OLTP(On Line Transaction Process) Technology Considerations 联机事务处理的技术考虑事项
这一部分主要讲述了联机事务处理的系统中涉及到的数据存储方式（包括写入和读取数据库）。
物理更新，数据在R/3系统中进行更新的时候通常有两种形式，同步和不同步的。同步更新都有程序执行，用户需要等待确认完成。而不同步更新则通常是接近实时地完成，用户无需等待业务操作执行结束。按照周期的长短，不同步更新又被分为了V1和V2两种更新方式。V1是时间要求相对严格的更新，它的更新进度完全取决于交易表所限定的进度。而V2则是时间要求不严格的，它通常用来更新一些不需要经常变化的和交易相关的统计数据。一般来说，任务队列越长，更新的速度就越慢，这个基本上是要取决于系统负荷的。
从数据仓库的角度出发，在运作系统中数据的写入有两种基本方法，使用增量变化捕获机制和不使用这一机制的。目前，SAP BW中的增量捕获机制正在发展中，R/3中已经实现了增量捕获机制。
在SAP BW出现之前，就有趋势将R/3分为几个分开的实例，并在其间仍然进行数据流通，这个时候业务框架的概念得以发展，而原先版本的应用程序渐渐淡化，并让它们都通过ALE进行交互。工作流包括在供应链中的预警和通知等，也渐渐的从中清除。在ALE出现之前，其实也已经有一种用于审计的变化日志的存在来实现类似的功能。也有部分主数据增量抽取器使用ALE作为更新检查工具过，不过最近来讲，最牛的还是增量队列法。
另外还有一种增量检验机制的方法，是由BADI提供的。在此不做赘述。
不稳定文档，SAP BW中的每一项事务，都有一个过程——生命周期，它也有两种不同的状态，活动和不活动状态。属于活动状态的事务，相关的描述文档可以是连续更新的，比较常见的就是一个交易（order）追踪文档的状态有好多种，它本身的内容，就包括了它的当前状态，而且这也是非常重要的。
相似地，一些后发的数据流。也会跟随这商务的进行而与之联系在一起。
理解数据的不稳定性，对于理解BW的信息模型是大有好处的，在R/3当中何时需要更新和重新获取数据，在一个商务文档变得不再活动的时候把它放到另外一种类型的文档中去。在BW中，有关不活动文档的数据通常只需要加载一次即可。因为它们不会发生变化。（这句是废话-。-）
读取数据，经常会发生第三方的产品想要连接到SAP BW中进行数据读取而脱离开SAP的应用层的事例，尽管SAP R/3中的许多数据都是直接可调用的，但是仍然有一些复杂的地方，首先，需要过滤掉商业逻辑后将这些数据表全部得到，其次，你可能会遇到技术上的困难，比如应用服务器缓冲的数据和锁定的数据等等。处理这些问题需要对业务逻辑的技术细节极其熟悉才行。即使当数据提交给数据库的时候，它也未必在一个很容易读取访问的地方。SAP将它的数据表们分成了几种不同的类型，以进行技术上的区别。
它们分别是：
l 简单表（Transparent Tables）：简单表就是简单表，你最开始接触的那种表就是了。
l 数据库视图：就是你知道的那种视图的定义，呵呵，这个没有做进一步的细分。
l 池状表（Pooled Tables）这个在SAP发展R/3的初期出现，早期的时候，数据表的数量有限制，这个时候随着SAP BW中对数据量的增加，人们开始将许多的表放到一个表里面，这个原先的作为母体的表，就被称为Pooled Table.这些表把子表的表明作为主键，数据则以一种很长的row string 来表示。
l 群状表，和Pooled Tables差不多吧，主要区别就是Cluster tables里面会有一些复杂的存在于程序内存中的数据对象可以直接存在其中而不需要任何其他的操作。
l 逻辑数据库，这一层次可以表现实际上的表，也可以不表示，它流行于报表制作的阶段，因为用户无需考试实际数据的问题而进行报表的构思。
SAP BW 学习笔记（五）
这段时间没怎么看书，都在BW的系统里面摸索，今天继续看了 Mastering SAP BW... 一点小小心得，流于此，但愿后面能多看看...
SAP Source System
元数据流
元数据在BW系统中，贯穿了整个数据传输的过程，在这其中，元数据流的作用就是基本上用来决定了数据从各种元数据到达BW的数据源系统的过程中的传输规则的制定。 它是一个域的集合，包括了进行上述第一步无损失的数据传输的过程中需要进行域的选择，哪些数据要映射到数据源系统中，哪些不用，哪些需要选择，哪些不需要，都由它决定。
之所以要进行这样的处理，是为了提高数据载入的效率，节约数据抽取占用的资源。
按照习惯来讲，数据域的聚合，是应该在进行数据查询的执行过程中执行的，而不是在数据抽取的过程中。但是我们注意到，通常数据的聚合必然带来的就是数据信息的丢失，而如果在执行数据查询的过程中就会带来数据的丢失，显然是会影响到整体的数据完整性的。只要远程信息立方体是由源系统抽取器直接生成的，这个抽取器就得支持抽取时间的因为性能要求而聚合。