本文档详细介绍了SAP BW数据仓库的开发规范，包括数据仓库架构、数据源、抽取层和合并层的设计，以及HANA开发的基本说明和通用规则。在BW开发中，强调了命名规范、数据粒度、生命周期管理和权限设计，而在HANA开发中，规定了SID、HOSTNAME、SCHEMA等要素以及包和对象的命名规则，旨在提高开发效率和系统维护性。
目录
3.3 ApplicationComponent（应用组件）
3.8 Open Hub Destination（Open Hub）
3.10 DataStore Object（advanced）
3.12 CompositeProvider（混合信息提供者）
3.17 可重用约束指标（Restricted Key Figure）
3.18 可重用计算指标（Calculated Key Figure）
3.22 Authorization Object（授权对象）分析权限
前言
随着信息化 -> 数字化进程的加速，各企业都需要管理海量的数据信息并从中挖掘有价值的信息，以向企业管理者提供决策支持。SAP BW是商务智能（BI）的集成套件之一，为SAP数据和非SAP数据的采集、存储、分析和管理提供一个集成的、面向商务的平台。
而在BW的开发过程中，模型与模型之间，处理链与处理链之间，数据源与数据源之间，以及他们互相都需要有一套明确、易懂、有助于在系统快速定位的命名规范来让BW开发者、运维人员和其他系统应用BW数据的产品经理、开发人员提升开发效率，降低运维、沟通成本。
1、基本说明/要求
1.1 数据仓库的架构
基于层次的设计，通过层与层之间提供的服务，保证了整个数据仓库对未来需求的变化的适应性，并且，在各个层次间，我们通过命名规则界定了各个层次的命名，明确了数据流的定义，使企业级数据仓库的设计更为有序。
具体包含以下层次：
数据源，数据抽取层，数据合并层，报表层（业务分析层，访问抽象层）；
1.2 数据源
数据源可以是各种ODP 系统、SAP BI 系统、文本文件、HANA本地数据源或第三方ETL工具的输出、大数据数据源等等；
1.2.1 SAP标准数据源
要求采用SAP 提供的标准数据源，对于特定数据源中不存在的字段，可以进行增强。仅当SAP 不存在对应的数据源时，才考虑开发新的数据源。
对于自定义数据源的抽取方式，一般采用“从视图中提取”方式， 需要进行复杂逻辑处理的数据抽取采用“通过函数提取”方式，尽量能够利用delta机制。
1.2.2 SLT数据源
从SLT队列中获取增量数据，生成数据源。
1.2.3 文本文件
文本处理模式要求用户联机到SAP BI 系统上手工执行，不能安排为后台作业执行。如果需要在后台安排作业执行，则需要将文本文件传输到SAP BI 应用服务器上。
1.2.4 第三方数据抽取工具
SAP 数据仓库支持和第三方数据抽取工具的集成，比如Infomatica，DataStage，DataService 等等。仅当SAP 提供的工具不能满足数据抽取需求的时候，我们才可考虑评估第三方数据抽取工具的可能性。
1.3 抽取层
抽取层的输入数据源来自于源系统。抽取层保存和源系统一致的信息，不进行编码转换、数据清洗、语义逻辑加工。在抽取层要求完成一定的附加处理：（增加数据来源标识－源系统）抽取层的数据供合并层使用，采用DSO 来进行数据存储。抽取层不适用于信息对象。
1.3.1 数据粒度
按照源系统的关键字及源系统标识0LOGSYS进行数据保存，抽取层中保存尽可能细的数据粒度。
1.3.2 历史分区设计
拆分保存历史数据，使得在一个DSO 中保存较少的数据量，减少对服务器资源的要求，加快DSO 激活的过程，充分利用数据仓库的并行处理能力，缩短数据上载的时间。
1.3.3 集成度
对应于源系统的每一个数据源，在抽取层均需设置一个DSO 用于对应的数据存储，数据源和DSO 为1：1 对应。
1.3.4 生命周期
永久储存区（DSO）及更改日志数据(Change Log)中的数据需要定期进行删除，生产系统上，在应用稳定后至多保存一个月。数据删除统一安排处理链进行。
1.3.5 技术要点
- 1、抽取层中的数据一律采用DSO 来进行保存。
- 2、DSO类型：标准DSO
- 3、关键指标处理模式：覆盖
- 4、仅当数据源不支持覆盖时进行特殊处理。
-
1.3.6 报表的可访问性
- 抽取层中的数据一律不允许用户通过查询进行访问。
-
1.4 合并层
-
合并层的输入数据源来自抽取层的数据，从抽取层到合并层根据业务需求定义完成编码统一，业务逻辑统一。合并层的数据主要供后续的应用使用，不适用于信息对象。只适用于权限对象，筛选对象，流入流出，货币转换，选择信息对象存储。
合并层采用ADSO 来进行数据存储。
-
1.4.1 数据粒度
-
按照源系统的关键字及源系统标识0LOGSYS进行数据保存，合并层中根据业务需求保存所需字段。
-
1.4.2 历史分区设计
-
拆分保存历史数据，使得在一个ADSO 中保存较少的数据量，减少对服务器资源的要求，加快DSO 激活的过程，充分利用数据仓库的并行处理能力，缩短数据上载的时间。
-
1.4.3 生命周期
-
更改日志数据(Change Log)中的数据需要定期进行删除，生产系统上，在应用稳定后至多保存一个月。数据删除统一安排处理链进行。
-
-
-
-
- 3、关键指标处理模式：覆盖
- 2、DSO类型：标准DSO
1.4.4 技术要点
1、合并层中的数据一律采用ADSO 来进行保存。
2、ADSO类型：标准ADSO
3、关键指标处理模式：覆盖
4、例程处理：采用配置函数方式，提高系统可扩展性。
1.4.5 报表可访问性
合并层中的数据允许用户通过查询进行访问。
1.5 信息展现层
信息展现层的设计取决于部门应用的需求，由各应用根据需求进行设计。最终在CompositeProvider上进行展示。维度展现文本，选择适用信息对象。
1.6 信息对象设计
信息对象是SAP BI 模型建设的基础，主要包含特性和关键指标。
尽量使用业务内容中提供的标准信息对象，如果没有可以单独创建。统一规划，统一使用，避免重复建设，如果没有可单独创建。
1.7 数据上载
数据仓库要求从多个系统中抽取数据，因此合理、统一的数据上载流程安排是至关重要。
1.7.1 DTP
DTP用于安排数据从源系统上载到数据仓库的作业。针对每个数据源创建4 个对应的DTP：
1、完全抽取数据信息包
2、初始化数据信息包
3、增量抽取数据信息包，用于处理链中使用
4、临时抽取数据信息包
数据传输进程，针对每个数据源创建3 个对应的数据传输进程(DTP)：
1、完全抽取数据DTP
2、增量抽取数据DTP，用于处理链中使用
3、临时抽取数据DTP
1.8 处理链
通过处理链可以把不同的处理任务进行集中地，周期地计划，并且进行监控。
处理链总体架构参考模型层次架构设计。
除了日常数据上载的处理链，需要安排定期进行数据处理的处理链：
1、ADSO全量数据的删除，至少删除30 天前的数据
2、更改日志数据的删除，至少删除30 天前的数据
1.9 客制化增强
采用BADI- RSROA_VARIABLES_EXIT_BADI增强方式。
1.10 权限设计
数据仓库中的权限分为两种概念：标准权限和分析权限。
1、标准权限可以对数据仓库工作台,业务浏览器,计划工作台及分析流程设计器和数据挖掘工作台进行权限的控制。
2、分析权限是用来管理和控制用户可以通过报表进行查看数据仓库内容的权限。
对于分析权限按两个层次进行划分
报表级别：由BO中角色组进行控制。
字段级别：由BW中分析权限及角色组合进行控制。
2、HANA开发规范
2.1 基本说明
2.1.1 SID
系统ID(System id),系统标识符，限定由三位字符组成；
2.1.2 HOSTNAME
主机名，用于解析主机的IP地址；
2.1.3 SCHEMA
用于组织HANA持久化对象，schema里面包含了各种持久化对象如tables, views, sequences, procedures, synonyms, indexes等；
2.1.4 PACKAGE
包，用于组织HANA建模对象，如属性视图，分析视图，计算视图等；
2.1.5 DELIVERY UNITS
交付单元，以包为单位，用于HANA模型在开发测试生产各环境间导入导出；
2.2 通用规则
2.2.1 单词缩写规则
采用英文单词给各数据对象命名时，会使用多个单词组合的方式使描述更加具体清晰，但同时也产生了对象名称过长，阅读及使用不便的问题，这时单词缩写就显得尤为必要，灵活的单词缩写既缩短了对象名称的长度，又保证了对象可读性；
建议当对象名超过20个字符时就应该尝试用单词缩写重新命名，如果名称长度在此之内，原则上讲则尽可能不用缩写以使表述具体清晰，对象最终的名称长度要严格控制在32个字符以内，单词缩写具体规则如下：
- 1. 标准缩写：如果可以在字典里找到一个词的缩写，就用这个做为缩写，比如：Monday=Mon、December=Dec ，可在此网站下查找到一些英文单词的缩写：http://shortof.com/；
- 2. 去元音及重复字母缩写：可以删除单词元音(词首字母除外)和每个单词的重复字母来缩写一个单词。比如：Current = Crnt、Address = Adr、Error = Err、Average = Avg；
- 3. 取前N位字母缩写：采用2.1.1及2.1.2方式缩写不能获得满意结果时，可以采用直接截取英文单词前N位的方式进行缩写，建议取3到4位字符，比如：Purchase = Pur、Delivery = Del；
- 4. 主从表缩写：某些场景命名可能会涉及到主从表，上述1~3的单词缩写原则也适用于主从表，对于主从表，如果主表名称没有缩写而从表的名称需要缩写，则从表名称从第二个单词开始缩写，第一个名词尽可能和主表保持一致。比如企业基本信息表名称为enterprise，则企业诉讼表enterprise_litigation可简写为enterprise_ltg，企业证书表enterprise_certificate可简写为enterprise_crt。最终的数据库表及由数据库表生成的程序在集成环境中是按名称排列的，这样做是为了让相似功能的表、类文件排列在一起，方便开发者操作；
2.2.2 基本命名要求
- 使用有意义的英文词汇，或汉语拼音首字母；
- 可以用字符(a～z)、(A～Z) 、数字（0～9）以及下划线等组合构成对象的名称；
- 除包（Package）名称用小写字符外，其余所有字符均大写，不允许使用中文字符，不允许使用空格；
- 使用字符(a～z)、(A～Z)开头，即首字符不能为数字和下划线；
- 末尾字符不能为下划线；
- 下划线可用于分割字符，但不允许连续使用2个及以上的下划线来分割字符；
- 使用下划线分割字符，对象中的下划线原则上不超出5个；
- 避免使用HANA数据库的保留字， 函数名或者操作符名， 比如用 SAP命名包（Package）；
- HANA中对象长度限制为127个字符，实际使用中，原则上不要超过32个字符；
3、BW/4模型开发
3.1 BW Project（工程）
3.1.1 命名规范
格式：<系统环境>_<client号>_<ProjectName>_ ZH_<功能应用码>
解释：
系统环境：BW/4开发环境，BWD开发，BWQ测试，BWP生产
Client号：开发环境Client号
<ProjectName>：工程名称
ZH:中文语言
功能应用码：参照ABAP开发规范
示例：B4D_100_FINANCIAL_ZH_BW
中文描述：系统自动生成无需命名
3.1.2 开发规范
整个开发阶段将使用统一的工程名称:B4D_100_<ProjectName>_ZH_BW，存在并行开发时直接在该工程名后加三位编号，如：B4D_100_<ProjectName>_ZH_BW001。
用于测试的工程名称 B4D_100_<ProjectName>_ZH_BW_用户名，如B4D_100_<ProjectName>_ZH_BW_ZSAP01。
3.2 InfoArea（信息范围）
3.2.1 命名规范
根信息范围：Z1BI
格式：Z+<编号>+BI+_<业务划分>+_<数仓分层>+_<功能的应用码>
解释：
编号：整体项目编号1
业务划分:如某公司-<公司代码>
数仓分层：三层模型，E(抽取层)\C(合并层)\R(报表层)\M (主数据层)
<功能的应用码>:按照ABAP功能应用码区分：如FI财务管理，SD销售管理
备注：
示例：Z1BI_<公司代码>_E_FI某公司抽取层财务管理
中文描述：
根目录：某公司-商务智能
二级目录：<公司/业务系统>+-数据仓库
示例：Z1BI_<公司代码>：某公司-数据仓库
Z1BI_BPC：BPC-数据仓库
三级目录：<公司/业务系统>+-<数仓分层>
示例：Z1BI_<公司代码>_E：某公司-抽取层
四级目录：<公司/业务系统>+-<功能的应用码>
示例：Z1BI_<公司代码>_E_SD：某公司-营销管理
3.3 ApplicationComponent（应用组件）
3.3.1 命名规范
格式：Z+BI_<源系统>+<内容描述>
解释：
源系统：参照BW源系统类型
内容描述：源系统抽数的内容
示例：ZBI_HANA_ZSAP01
中文描述：<公司或业务系统>+<组件内容描述>
示例：ZBI_HANA_ZSAP01：HANA系统ZSAP01库
3.4 Source System（源系统）
3.4.1 命名规范
格式：Z_<源系统种类>_<子公司或系统名称>
解释：
数据源种类： FILE 文件数据源
S4组件直接使用对应逻辑系统
第三方 使用数据库种类简称
- ORA Oracle
- MSS SQL Server
- HDB hana
- 4、MYSQL MYSQL 。。。。。。
子公司或系统名称：某子公司：<子公司>
示例： ZFILE_<子公司>
ZORA_<子公司>
中文描述：<公司或业务系统>+<系统内容描述>
示例：ZORA_<子公司>：某子公司ORACLE源系统
3.5 DataSource（数据源）
3.5.1 命名规范
1、SAP数据源
ODP数据源：
格式： Z+X+_<功能应用码>+_源系统表名或表名简称
分两类：SAP与非SAP
解释：
X:TD-交易数据; MA-主数据属性；MT-主数据文本
数据源：业务数据： ZTD_XX_源系统表名或表名简称
主数据属性： ZMA_XX_源系统表名或表名简称
主数据文本： ZMT_XX_源系统表名或表名简称
示例：ZTD_FI_AR(财务应收账业务数据)
中文描述：<公司或业务系统>+-<表内容描述>
示例：ZTD_FI_AR：某公司-财务应收业务数据
CDS数据源：
格式： ZBW_+CDS+_源系统表名或表名简称
示例：ZBW_CDS_ ZTGL0066 (总账科目配置表)
2、非SAP数据源
格式： Z+X+_<业务源系统>+_表名简称
解释：
X:TD-交易数据；MA-主数据属性；MT-主数据文本
业务源系统：抽取数据的业务系统主要的覆盖范围
数据源：
业务数据： ZTD_XX_源系统表名或表名简称
主数据属性： ZMA_XX_源系统表名或表名简称
主数据文本： ZMT_XX_源系统表名或表名简称
示例：ZTD_HR_V_YX_WORKER(人力系统WORKER表)
中文描述：<公司或业务系统>+-<表内容描述>
示例：ZTD_HR_V_YX_WORKER(人力系统WORKER表)
3.6 InfoSource（信息源）
格式： Z+<数仓分层>+<功能应用码>+I+_<流水号>
解释：
功能应用码：参照ABAP开发规范
数仓分层：三层模型，M (主数据层)\E(抽取层)\C(合并层)\R(报表层)
I： ODS View
示例： ZEFII0001集团财务应收数据
中文描述：<公司>+-<数据内容描述>
示例：ZEFII0001集团-财务应收数据
3.7 InfoObject（信息对象）
3.7.1 命名规范
格式：Z+<八位数功能描述>（共九个字符）
解释：
功能描述：该信息对象应该包含具体的业务含义，尽量使用英文，非英文使用拼音首字母简称
示例： ZPLANT（工厂）
中文描述：<字段内容描述>
示例： ZPLAN：工厂
备注：自定义信息先参考标准，如果标准没有，尽量使用英文，非英文使用拼音首字母简称
3.7.2 开发规范
BW4中信息对象会根据类型自动划分到特征或关键指标，应使用自动分类
3.8 Open Hub Destination（Open Hub）
格式： Z+<数仓分层>+<功能应用码>+H+_<流水号>
解释：
功能应用码：参照ABAP开发规范
数仓分层：三层模型，M (主数据层)\E(抽取层)\C(合并层)\R(报表层)
示例： ZCFIH01集团财务业务数据输出
中文描述：<公司或系统>+-<输出内容描述>
示例： ZCFIH01：集团财务业务数据输出
3.9 Open AODS View（AODS View）
3.9.1 命名规范
格式： Z+<数仓分层>+<功能应用码>+V+_<流水号>
解释：
功能应用码：参照ABAP开发规范
数仓分层：三层模型，M (主数据层)\E(抽取层)\C(合并层)\R(报表层)
V： AODS View
示例： ZEFIV01集团财务应收数据
中文描述：<公司>+-<财务应收数据>
示例：ZEFIV01集团-财务应收数据
3.10 DataStore Object（advanced）
3.10.1 命名规则
格式： Z+<数仓分层>+<功能应用码>+O+_<流水号>
解释：
功能应用码：参照ABAP开发规范
数仓分层：三层模型，M (主数据层)\E(抽取层)\C(合并层)\R(报表层)
O： ODS View
示例： ZEFIO0001集团财务应收数据
中文描述：<公司>+-<数据内容描述>
示例：ZEFIV0001集团-财务应收数据
3.11 Data Flow（数据流）
3.11.1命名规则
1、SAP分析主题：
格式： Z+DF_<ABAP的功能应用码>_+<ABAP的功能应用码子主题>
解释：
分析主题： 按照ABAP的功能应用码区分
分析子主题：按照ABAP的功能应用码子模块区分
示例： ZDF_FI_GL 集团-总账数据流
中文描述：<公司>+-<数据流描述>
示例：ZDF_FI_GL 集团-总账数据流
2、非SAP分析主题：
格式： Z+DF_<业务场景区分>_+<业务场景区分子主题>
解释：
分析主题： 按照业务场景区分
分析子主题：按照业务场景的子模块区分
示例： ZDF_SALES_SLXT 销售系统-销售数据流
中文描述：<公司>+-<数据流描述>
示例：ZDF_SALES_SLXT 销售系统-销售数据流
备注： DATA FLOW在实际开发过程中，用去不大，因此建议在建模过程中无需使用DATA FLOW
3.12 CompositeProvider（混合信息提供者）
3.12.1 命名规范
1、SAP分析主题：
格式： Z+<数仓分层>+<功能应用码>+CP+_<流水号>
解释：
功能应用码：按照ABAP的功能应用码区分或业务场景区分
数仓分层：三层模型，M (主数据层)\E(抽取层)\C(合并层)\R(报表层)
示例：ZRFICP02集团-利润表
中文描述：<公司>+-<业务分析内容>
示例：ZRFICP02：集团-利润表
2、非SAP分析主题：
格式： Z+<数仓分层>+<业务场景>+CP+_<流水号>
解释：
功能应用码：按照业务场景区分
数仓分层：三层模型，M (主数据层)\E(抽取层)\C(合并层)\R(报表层)
示例：ZRFHYXCP01某公司-销售数据
中文描述：<公司>+-<业务分析内容>
示例：ZRFHYXCP01某公司-销售数据
3.13 Transformations（转换）
3.13.1 命名规则
由系统标准生成，请勿自己命名
3.14 DTP（数据传输处理）
3.14.1 命名规范
<X>-<系统标准生成>
业务描述： 如销量分析
X：F-完全更新的DTP，D-增量更新DTP，<X>-其他限制规则全量更新DTP
示例： 增量抽取：D-0FI_GL_4 / S4DCLIT120 -> ZEFI04
全量抽取：F-0FI_GL_4 / S4DCLIT120 -> ZEFI04
全量限制抽取：X-0FI_GL_4 / S4DCLIT120 -> ZEFI04
如：时间限制（2017-2018）-0FI_GL_4 / S4DCLIT120 -> ZEFI04
只全量抽取2017年-2018年数据源0FI_GL_4到ZEFI04模型数据
中文描述：无中文描述
3.15 Query（查询）
3.15.1 命名规则
格式： <CompositeProvider名称>_Q+_三位编号
解释：
示例： ZRFICP02_Q_001：集团-财务应收查询
中文描述：<公司>+-<查询内容描述>
示例： ZRFICP02_Q_001：集团-财务应收查询
3.16 Query Variable（变量）
3.16.1 命名规范
格式： Z<信息对象>+ _<X1>+<X2>+<X3>+<X4>+_三位编号
解释：
X1－建议采用如下命名规则：
M-手动输入/预设值(Manual Input/Default Value)
R-替代路径(Replacement Path)
C-客户出口(Customer Exit)
A-权限(Authorization)
X2－建议采用如下命名规则：
V-可见，N-不可见
X3－建议采用如下命名规则：
S-单值，M-多个单一值，O-查询选项，I-间隔，P-预计算值
X4－建议采用如下命名规则：
M-必输入 O-可选
示例:Z0PLANT_CVMM_001(工厂变量属性为，客户出口，可见，多值，必选)
中文描述：<分析主题字段内容>
Z0PLANT_CVMM_001：工厂
3.17 可重用约束指标（Restricted Key Figure）
3.17.1 命名规则
格式： Z+<信息对象>+R+三位编号
解释：
信息对象： 信息对象技术名称
示例： Z0SALE_ R_001 集团-销售数据
中文描述：<公司>+-<指标内容描述>
示例： Z0SALE_ R_001 集团-销售数据
3.18 可重用计算指标（Calculated Key Figure）
3.18.1 命名规则
格式： Z+<信息对象>+C+三位编号
解释：
信息对象： 信息对象技术名称
示例： Z0SALE_C_001集团-销售数据
中文描述：<公司>+-<指标内容描述>
示例： Z0SALE_ R_001 集团-销售数据
3.19 可重用Query结构
3.19.1 命名规则
格式： <信息提供者>+T+三位编号
解释：
信息提供者： 信息提供者技术ID
示例： ZRFICP02_T_001集团-财务应收结构
中文描述<公司>+-<查询业务内容描述>
示例： ZRFICP02_T_001集团-财务应收结构
3.20 处理链
3.20.1 命名规则
1-3级处理链：<应用>
|— <数仓分层>
|—<模块>
4级处理链格式：
格式： Z1BI+_<数仓分层>+_<功能应用码>+_<两位编号>
数仓分层：三层模型， E(抽取层)\C(合并层)\R(报表层)\M(主数据层)
示例：Z1BI _E_FI_01（BW 系统数据每月自动增量加载）
中文描述：<公司>+<处理链内容描述>
Z1BI _E_FI_01（BW 系统数据每月自动增量加载）
3.20.2 处理链开始
格式： <所属处理链技术名称>_START
所属处理链技术名称： Z1BI _E_FI_01
示例：Z1BI _E_FI_01_START（立刻开始）
中文描述：<主键应用描述>
示例：Z1BI _E_FI_01_START（立刻开始）
3.21 Role（角色）
3.21.1 命名规则
格式： Z+<行业>+<业务模块>+_<业务描述>_+<流水号或范围描述>
解释：
行业：快消品SA，制造MM，能源NY，医疗MC
业务模块：按照ABAP的功能应用码区分或业务场景区分
业务描述：利润中心LRZX
流水号或范围描述：流水号：01，范围描述ALL
示例： ZSAFI_LRZX_01, ZSAFI_LRZX_ALL
中文描述：<公司>+-<限制范围描述>
示例： ZSAFI_LRZX_01：某某快消品集团利润中心权限
3.22 Authorization Object（授权对象）分析权限
3.22.1 命名规范
格式： Z+_<公司>+_<应用模块>+<信息对象>
解释：
信息对象： 使用信息对象的技术名称
编号:
示例： Z_0plant_01
中文描述：<公司>+-<限制范围描述>
3.23 传输请求
3.23.1 命名规范
BW模型采用ZBW包，BPC模型采用ZBPC
BW:
格式： ZBW_<请求包含内容>_<日期>
解释：
请求包含内容： 请求包含内容的概括
日期:如20180101
示例： ZBW_总账模型_20180101
中文描述：ZBW_<请求包含内容>_<日期>
示例： ZBW_总账模型_20180101
BPC:
格式： ZBPC_<请求包含内容>_<日期>
解释：
请求包含内容： 请求包含内容的概括
日期:如20180101
示例： ZBPC_总账模型_20180101
中文描述：ZBPC _<请求包含内容>_<日期>
示例： ZBPC _总账模型_20180101
扫一扫
1515
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
