BW数据仓库模型创建注意事项模板.docx

BW数据仓库模型创建注意事项

78

资料内容仅供参考，如有不当或者侵权，请联系本人改正或者删除。
创立一个IO:
Bw中D版本的意思是delivery版本, 就是BW系统预定义的版本

上边是事物数据类型更新
下边是主数据类型更新

当主数据的数据源FlatFile中包含中文时候:

如果主数据包含中文字符字符集要选8400

创立完成InfoObject之后, 上图创立了MasterData Table 和TextTable 并没有创立SID Table

如果选中”带文本”系统就会创立相应文本表, 文本表和SID表、 层级表之间是用主外间关系来关联, 点中和 系统就在文本表中分别创立长文本和语言的2个字段

上图暂时不明白什么意思? ? ? ? ?

上图没有练习过? ?

一般使用

什么情况下使用???:

:
点:

DIS代表Display 说明属性是显示属性
导航属性:

点将Display属性转换为导航属性

创立InfoObject的时候注意取值是大写还是小写, 如果存在小写则选中
InfoObject中存在的数据类型:

分析: SLD表、 属性表、 文本表、 层级表

抽取主数据的时候主数据和语言相关的话中文是 ”1” 英文是 ”E”
当主数据带有文本数据的时候一定要注意文本的长度, 一般选择长文本, 避免文本长度不够的现象, 短文本是20Char的长度, 长文本是60Char的长度
当出现转换错误时, 是0unit转换出错, 就是数量单位的字段, 没有对象正确, 也就是说
CommunicationStructure中的字段和.CSV中的列数据没有对应正确
下边是正确倒入数据后的”维护主数据”

依赖于时间的层次结构:

上图右边圈中是层级表
F: fact table
D: Dimensions table (纬度表)
P: Master Data Table
T: Text Data Table
S: SID Table
H:Hierarchy(层级表)
I: Hierarchy依赖表, 与D(Dimentions表经过ABAP程序关联)
K: Hiearchy依赖表, 与I表关联
/BIC/SIO_SREP: Hiearchy依赖表与K表关联
Navigation attribute:导航属性
Display attribute:显示属性
现在没有做InfoCube因此没有生成SID表, 继续往下练习, 注意生成SID表在哪一步。

InfoCube三种设计方案:
1、 依赖于时间的导航

2、 纬度特征法: 将特征作为纬度的特征
3、 依赖于时间的整体层级关系, 依赖于时间的整体层级允许我们构建聚集, 在开始的练习中不允许我们构建聚集, 开始是依赖于时间的层次结构, 我们当前练习是依赖时间的整体层级

依赖于时间的整体层级关系: 层级自身依赖时间, 层级中的节点和叶子并不依赖时间
依赖于时间的层次结构: 层级自身不依赖时间, 而层级下的节点和叶子依赖于时间

IO_CUSTW1
IO_MATW1

IO_OFFCW

IO_SREGW

IO_SREPW

注意, 抽取平面文件主数据时从新抽取一定要把已经存在的主数据删除, 主数据能够存在文本, 主数据的属性组好不要存在文本

出现这种情况原因? ? ? ?
原因是: 主数据表和文本表中字段不对应, 在文本表中加一列语言代码”1”:

正确后主数据是:

连接offic、 销售地区和销售代表的两种方式:
1、 用属性的方式连接
2、 用依赖时间的层次结构的连接
3、 用依赖依赖时间的整体层级连接
4、 用依赖时间的导航属性连接
几种在显示上没有区别, 仅仅在执行效率上有区别, 最重要的是: 有些能够使用聚集有些不能使用聚集
BW Data Mart
1、 data mart的作用类似ALE
2、 用于数据的清洗作用
ALE的作用是在不同的CLIENT之间交换传递数据:

Data mart 几种分布数据模型:

当创立一个ODS时候, 系统会自动创立一个data mart interface( 数据栈接口) 以8打头的一个导出数据源
用BW中已有的ODS和Cube作为数据源向其它Cube导入数据的时候, 是用data mart interface来导入

下图是两个BW系统之间传递数据

BW到R/3的连接步骤前边有所讲解, 回头要写详细步骤文档

从原系统生成导出数据源:

1、 Generate生成 Export导出, 生成后是以8开头的数据源, 在object tree中是不能显示
找到的, 留下此问题? ? ?
2、 在目标系统中复制数据源, 这样就把刚才的导出数据源复制到了target系统中
3、

复制完成后点data source overview来显示数据源中对象, 检查是否对象已经复制到原系统下

搜索以8开头的原系统中的导出数据源, 看目标系统中是否已经过来了导出数据源

上图说明已经过来了

Assign infosource:

注意: infoobject的数据源assign的时候必须先手动创立出来她, 否则找不到相应的infosource,必须事先手功能创立它

创立之后就能够进行infosource的assign了
Assign之后自动创立的是: transer structure,communication structure,transfer rule下边就能够创立infopackage了, 此时是没有住数据的, 要经过infopackage来加载特征主数据

在目标系统显示复制过来的数据源的8开头的方法:

注意sap liabary上的一些小黄灯, 都是小技巧的地方

在IP中选择抽取条件的时候有时候会出来一个提示框 提示你登陆, 这时把sm59中改成后台登陆
SM59看用户是选择屏幕登陆还是后台登陆

抽取主数据结束后看效果:

重复刚才的操作找到文本数据源, 用搜索来查找

下边小节是介绍从数据源到infocube过程中一个数据清洗的过程

下边首先看BW和R/3的连接配置:
然后把连接配置做好810的, 顺便把上边练习做好

BW到R/3的连接, 以810为例子

在BW中创立一个独立的client作为练习之用
1、 在r/3( P35) 创立一个逻辑系统并复制到BW系统中去
进入810àSPRO
点

定义逻辑系统

定义完成后 把client分配给我们刚才定义的逻辑系统

注意上图点
这样我们能够从BW客户端允许修改810这个client

保存后:

2、 进入BW系统也要做上述步骤àspro

选择定义逻辑系统
定义逻辑系统BWCLNT110:

然后分配client给逻辑系统BWCLNT110

3、 为后台用户命名(创立两个后台通信用户)
创立后台用户client 810 for r/3:ALEREMOTE 密码: pass1234
Client110 for BW:BWREMOTE 密码: pass1234
810:

BW原系统( R/3) 创立步骤:

1、 SM59创立目标系统连接(以P35Cli810为例子)

2、 创立P35CLNT810原系统 RSA1

写入原系统相关信息:

结果:

原系统810创立完毕
下边是将P35CLIENT810的全局变量设置传递到BW中来:

上图代表传送成功! ! ! !

也能够对系统默认ALE用户进行修改:
Tcode:SPRO

在上图中能够对系统默认ALE用户进行修改

下边是新client的创立
110:
维护clinet 110
对于新建的client用sap*进入, 密码: pass

看右下角状态:
注意以上步骤都要在001中完成而不是在300中完成

配置001:
进入spro:

进入: SCCL:

COPY能够是后台也能够是前台
这里我选择的前台马上执行
COPY过来之后,在spro中定义国家中的数据都过来了, 此时能够定义su01用户了

COPY结束如下图:

设置公司或个人:

BW IGS配置过程

IGS配置需要很长时间, 回宿舍在配置, 配置过程要事先安装好patch和组件

第2套资料记录:
BWAUth* 类视频是BW权限控制讲解, 放到最后来看
BW Reporting&Analyzer 报表和分析( 先看此部分视频)
EXTR_LO_* BW物流数据抽取

EXTR_LO_* BW物流数据抽取
1、 利用

  sion="1.0" ?>
-
  0
-

  >

RSZC - Copying Queries between InfoCubes
在InfoCube之间复制queries, 具体好处有待验证

插曲: sql 删除表中数据:
Truncate是SQL中的一个删除数据表内容的语句, 用法是:
TRUNCATE TABLE [Table Name]。
下面是对Truncate语句在MSSQLServer 中用法和原理的说明:
Truncate table 表名 速度快,而且效率高,因为:
TRUNCATE TABLE 在功能上与不带 WHERE 子句的 DELETE 语句相同: 二者均删除表中的全部行。但 TRUNCATE TABLE 比 DELETE 速度快, 且使用的系统和事务日志资源少。
DELETE 语句每次删除一行, 并在事务日志中为所删除的每行记录一项。TRUNCATE TABLE 经过释放存储表数据所用的数据页来删除数据, 而且只在事务日志中记录页的释放。
TRUNCATE TABLE 删除表中的所有行, 但表结构及其列、 约束、 索引等保持不变。新行标识所用的计数值重置为该列的种子。如果想保留标识计数值, 请改用 DELETE。如果要删除表定义及其数据, 请使用 DROP TABLE 语句。
对于由 FOREIGN KEY 约束引用的表, 不能使用 TRUNCATE TABLE, 而应使用不带 WHERE 子句的 DELETE 语句。由于 TRUNCATE TABLE 不记录在日志中, 因此它不能激活触发器。
TRUNCATE TABLE 不能用于参与了索引视图的表。

Bw Queries开发与设计记录:
Context Menu 开发与设计是重点:
凭记忆内容:
1、 报表设计
2、 ?
3、 ?
4、 ?
5、 ?
6、 ?
7、 ?
8、 ?

BW从R/3加载数据练习记录:
2个目标:
1、 和从平面文件抽取数据的区别
平面文件: 当创立InfoSource的时候系统自动附加DataSource到InfoSource

2、 基本操作步骤( 一个图片)

步骤:

1、 创立或者激活BussinessCountent中的InfoObject
BC:SAP预定义的一些Object
以0plant( 工厂) 为例
2、 进入R/3àrsa5 激活数据源
r/3中DataSource分为两个状态: D状态 Active状态
rsa5中都是D状态版本
在P35-810àrsa5中找不到0plant这个用于主数据的数据源, 不明原因? ?

是否是定在BW端定义原系统的时候传递完全局设置后, 复制数据源, 复制结束后, 在原系统右键激活。

理解BussinessContent中安装相应对象后本质上是安装了哪些东西
0MATERIAL( 出错)
利用sapBussniessContent做为模版修改或者创立新的InfoObject
数据流图:

两种方式:
1、 以0plant作为模版, 创立一个新的InfoObject
2、 以现有DataSouce为模版, 创立一个新的DataSource
手工DIY步骤:

注意点: Replicated Transfer Structure的过程就是将原系统数据源中的Filed和ConmmunicationStructure中的InfoObject建立映射的过程, 类似Xi中的MM.
在原系统中的几个TransferStructure能够经过TranferRule汇集到一个CommunicationStructure

上图就是一个TransferStructure它组成了字段和InfoObject的映射关系

上图右边信息是数据源中的字段和InfoObject的映射, 左边是字段和CommunicationStructure中相应的InfoObject的映射, 这样体现了DataSource中字段和CommunicationStructure、 InfoObject之间的映射关系, 底层传输是RFC, IDOC逻辑系统之间的传输方式。
IO字段是InfoObject中的主要字段, 就是输入输出字段, 对应的是
也就是说原系统中的字段BELNR(凭证编号)最终被映射到了InfoObject中的IO字段DOC_NUM上来

上图中在转换结构中”选择”上打钩

复制完成后激活相应对象和结构, BW将TransferStructure再复制回R/3中去

InfoSource:

UpdateRule:

主要是指定金额数据如何( 运算) 传输到数据目标中去

0vendor供应商
加一个绑定属性”采购组织”在BS(业务目录)中不存在需要自己DIY
ZVENDOR05
属性数据:

文本数据:

步骤:
1、

Tcode: se11

注意: 在西北P35系统上只能以”Z”开头命名
注意: 从D00创立视图然后传到810系统中去
视图ZVENDOR05_ATTR的数据全部来源于LFM1

设计好视图, 检查并激活, 生成传输请求号
同样创立TEXT视图:
此视图中存在表之间联结关系

注意: 联结条件和Filed中的字段必须包括两个表的所有KEY, 不包括则会抱错, 当KEY作为联结条件时, 在Filed中能够只出现一次
2、

用户: yyqchu 密码: pass1234
Tcode: SBIW

在下图打钩, 说明该字段能够作为将来的选择加载数据的条件, 就是数据加载的过滤条件

同样的创立文本数据源:

注意上图选择”文本”而不是”主数据属性”

进入rsa6(active的version), 检查刚才建立的两个数据源:

说明数据源已经激活, 创立数据源完成。( RSA5中并不存在着两个数据源, 因为rsa5是SAP传递过来的标准数据源) RSA5是否是由BussinessConten安装过来的?
到此步骤, TransferDatasource也已经完成, 因为它们已经是Active的状态了
下一步: 在BW中复制数据源( 先将申请号传输到810)
问题:

下图中的作用什么? 是否就是增量加载数据?
3、

上图为特征0VENDOR05的结构, G_EKOGRG为绑定属性, 下边为DISPLAY属性

SAP标准练习记录:

分析一家公司的费用中心帐号使用情况
BC中提供了一个0CCA_C11

费用中心在此公司是13位, 而在BW中是10个字符, 这样需要创立一个新的InfoObject

规则: 以13位为标准, 其它数据源到过来的费用中心都增加三个字符, 变成13位

Step:
1、 创立新的代表费用中心编号的InfoObject
激活InfoObject诀窍:激活它所在的InfoSource就能够激活有用的所有InfoObject

显示属性:

2、 创立InfoCube
以下是视频上没有的几个InfoObject

问题:
什么情况下需要”导航属性””绑定属性”? ? 练习在InfoObject上创立TransferRouting(例如增加3位长度)

上图增加一句检查原系统名称:

如果原系统名称不是I_EXTERN则执行此句下边的语句。

Query上发现新问题:
在QueryDesigner上当两个计算公式发生冲突时, 在下图选择显示哪个公式的结果:

点则显示当前公式结果
点则显示竞争对手的结果
此场景选择”该公式的结果”问题解决!

资产BW分析:
重点:
1、 ODS
2、 聚集
3、 BC学习

InfoCube设计基础:
1、 依赖时间的层次结构( 第一个平面文件抽取例子就是依赖时间的层次结构)

如上图选中在设计层级时就会如下图所示:出现”开始时间”和”结束时间”

记住如下图给层级加上相关的外部特征

三种属性:导航属性、 显示属性、 绑定属性( 绑定属性和主对象密切相关, 在Query中使用主对象时绑定属性随着拖过来, 不显示时写好固定值然后隐藏, 做为查询sql条件)

2、 依赖时间的导航属性

把之前做过的练习的依赖层级的例子改为( 依赖时间导航属性)

上图显示此种立方体设计方法的结构: 主要:
应用此种方式创立InfoCube时, 要选中相应的

例如: IO_SREG、 IO_SOFF作为其它特征的属性的时候不能加在CommunacationStructurez中
依赖时间的导航属性好处: 能够方便灵活的从相关主数据表中修改和维护时间:

( 需要增加练习)

3、 纬度特征设计法

上图特征作为纬度的时候InfoSource中的CommunicationStructure里要加入”销售办公室”等特征
上图三个特征共同组成一个销售代表纬度叫做”纬度特征法

次设计方法完全根据事务数据表中的内容展示数据, 例如”销售办公室随时间变化”这种场景

概念: 纬度随时间缓慢变化( 根据主数据从属关系分析事物数据的4种规则)

纬度特征法属于:

”今天是昨天”就是按照今天的主数据归属去判断昨天的事务数据

昨天是今天类似今天是昨天的道理

上图是”今天和昨天”: 只有昨天和今天的并集才能在报表中被反映
昨天和今天的意思是在”报表”中以什么时间的主数据结构来反映事物数据的标准

相比”依赖时间的导航属性”( 作为主对象的属性同时要作为纬度的属性) ”纬度特征法”速度要比较快, 因为”销售办公室”等距离纬度表比较近
4、 依赖时间的整体层级
以前的依赖时间的层次结构( 将时间作为层级的一个节点) :
缺点: 不能在InfoCube上构成聚集

现在依赖时间的整体层级
解决了不能在层级上构建聚集的缺点, 创立两个层级:

选择要用到特征
创立第一个层级( ２０００．１．１年以后)

创立第二个层级: ( １９９９．１２．３１以前)

点图标:
·

是代表截至日期

InfoCube中多个InfoObject能够分配给同一个纬度, 例如: 下图”成本中心编号”和”成本控制范围”都分配给了”CostCenter”这个纬度