某电气公司数据仓库的建设规划项目

《某电气公司数据仓库的建设规划项目》由会员分享，可在线阅读，更多相关《某电气公司数据仓库的建设规划项目（42页珍藏版）》请在装配图网上搜索。

1、.wd.某电气公司数据仓库建设规划工程方案建议书目 录第1章南车电气数据仓库建设工程介绍31.1.南车电气数据仓库建设工程的背景31.2.南车电气环境现状及需求分析41.2.1.工程目标4第2章南车电气数据仓库建设解决方案详述62.1.南车电气数据仓库建设整体方案说明62.1.1.方案概述62.1.2.系统逻辑架构72.1.3.系统硬件架构建议方案82.1.4.未来建设目标92.2.南车时代电气数据仓库平台建设132.2.1.数据仓库建设原那么132.2.2.数据仓库标准体系设计142.2.3.BW数据仓库构造定义172.2.4.数据仓库管理标准及命名标准202.3.南车时代电气BW数据仓库优

2、化方案312.4.数据展现层迁移方案322.5.主数据共享平台方案33第3章南车电气数据仓库建设工程实施方案353.1.南车电气数据仓库系统实施方案353.1.1.工作时间表预计353.2.培训方案393.2.1.培训类型403.2.2.培训课程403.3.容灾备份方案423.3.1.备份策略的定义433.3.2.备份窗口的选择433.3.3.灾难恢复的策略43第4章工程实施和管理提升方法464.1.工程实施和管理提升方法464.2.XX在南车电气工程中提供的管理提升和服务内容464.3.XX管理提升与 BI实施相结合的指导原那么474.4.XX管理提升与 BI 实施相结合的方法和步骤484.

3、4.1.现状调研和企业问题诊断484.4.2.未来业务流程和管理提升初步讨论484.4.3.建设 BI原型系统494.4.4.结合 BI进展未来业务流程和管理提升详细讨论和蓝图确认494.4.5.管理提升交付成果实例49第5章工程管理和质量保证515.1.工作方案管理515.2.沟通管理515.3.争议协调升级程序525.4.工程质量控制525.5.文档管理545.6.建议南车电气提供的保障措施555.7.验收标准及方案565.7.1.系统符合性565.7.2.系统质量565.7.3.交付文档57第1章 南车电气数据仓库建设工程介绍1.1. 南车电气数据仓库建设工程的背景南车时代电气始终坚持核

4、心技术向相关产业延伸的开展战略，不断稳固在轨道交通领域的行业地位，着力提升在电气传动和控制系统领域的专业地位，正树立起公司在电气传动和控制系统领域国际化专业供应商的新形象。为挖掘信息化系统价值，提升内部管理手段，公司于20102011年启动并初步建设了南车时代电气综合分析系统。该系统采用了SAP BW和EP的技术平台，实现了局部经营指标及报表需求，且于2014年从V7.0升级到V7.4版本。为优化各类应用系统间的借口，提高系统的安全性和可维护性，公司于2014年启动了ESB技术平台的预研工作，确立了以普元公司的Primeton ESB为技术平台建设公司的数据总线，局部系统间接口已经实现与ESB

5、的集成。1.2. 南车电气环境现状及需求分析公司为实现基于企业绩效管理的信息化系列重大需求，准备通过本工程做好数据仓库技术平台的规划及优化提升工作，确保数据仓库平台满足全面启动建设企业绩效管理系统的要求。本工程的工作任务包括数据仓库的建设规划、数据仓库的技术标准及性能优化、数据仓库与BO、EP的集成应用、数据仓库与ESB集成实现重要主数据的信息共享等四个方面。公司为实现企业绩效管理信息化的重大需求，籍由本工程做好数据仓库平台建设的规划，搭建起商务智能体系的整体技术架构并实现局部实例应用，满足全面启动企业绩效管理信息化的技术要求。同时，提出标准和优化提升既有的SAP BW数据仓库系统，使之成为企

6、业商务智能平台中运行良好的关键一环。为了解决本公司现有重要数据分布管理、穿插共享，无法保障数据及时性和准确性的弊端，公司拟将SAP BW建设成为未来的数据集成与共享中心，能够满足建设公司ESB平台的数据服务要求，实现重要主数据的归集与共享，提升数据交互性能和系统安全性。实现BW系统的规划与优化，搭建并应用BW+EP+BO的技术平台，建设重要主数据的集中存储机制，与ESB集成实现与试点目标系统主数据的同步。前瞻性，既表达在BW软硬件平台规划和建设思路上要考虑未来五年的开展需求，也表达在BW的ETL、部署、处理连、聚集、模型等数据仓库要素的设计标准上。1.2.1. 工程目标本期工程定位为规划奠基阶

7、段，需要全面系统的构建南车电气未来企业核心数据仓库的基础架构，该基础架构要具有完整性，能满足本期工程的需求，同时也要具有灵活性和可拓展性，能够满足未来企业开展而不断变化的需求。综上所述我们对于本次工程目标概括如下:1. 以BW作为数据仓库建设进展未来的整体规划，使之覆盖5年内含2015企业级中心数据仓库的技术框架、业务对象设计等需求，且至少满足未来2-3年内南车电气核心数据仓库的具体使用情况，满足其建设标准及管理标准，提高可读性、可扩展性、可维护性。规划内容包括数据整合ETL层、数据服务层、数据展现应用层的软硬件技术平台和服务内容，制定数据仓库的设计标准。2. 优化SAP BW的软硬件环境，标

8、准BW数据仓库的技术架构、对象设计和管理方式，重新梳理及构建原BW系统中设计不合理的局部比方CUBE、Query等，提升BW的操作性能、优化Query等待时间，使之具备满足当前作为企业级中心数据仓库服务的条件。涉及的相关CUBE主要有总帐行工程、应收、应付、本钱、采购、库存、销售、考核指标等。3. 部署SAP BO集成EP作为新的数据展现应用层，将当前BW中的局部报表展现重构，以BO在原BW CUBE的基础上重新开发，形成SAP BW+BO+EP的商务智能技术平台构造，完成重要历史报表的迁移工作。4. 构建主数据共享平台，扩展数据仓库实现重要主数据归集和储存的业务应用，目前有物料、客户、供应商

9、、人员、岗位、组织机构、制造BOM、订单BOM七类核心业务系统中的主数据需要聚集到BW数据仓库，通过ETL手段完成SAP和非SAP系统的主数据抽取并且在BW中建模，最终实现将数据仓库作为ESB中核心业务系统重要主数据的存储与共享中心，提供相关主数据的接口以供ESB系统调用，以此实现重要主数据的跨平台同步。第2章 南车电气数据仓库建设解决方案详述2.1. 南车电气数据仓库建设整体方案说明2.1.1. 方案概述本期工程的专业定位是集团企业级核心数据仓库的建设，数据仓库架构的优化及标准体系的建设。XX软件系统以ROI(投资回报)为目标，以科技为手段，为南车电气未来的公司绩效管控和决策支持服务构建强壮

10、的基础。XX公司通过结合中国本地的人力资源和地利之先，综合国内外的先进管理思想和应用实践，愿为南车电气的事业锦上添花。针对上一章节中我们所理解归纳的南车电气本期工程的需求，本期工程是南车电气信息系统建设的核心局部，整合后的数据仓库将作为将来南车电气整个IT环境中的数据基础平台，建设完成后将为未来的南车电气企业绩效管理信息化系统做准备。数据仓库系统的建设有其顺序性，且需要大量时间。数据仓库系统建设过程中，将发现原有的营运系统在作业流程、数据质量、数据标准化的问题，基于此发现，将有助于对营运系统的缺陷进展修复。BI系统的建设是循序渐进不断完善的，是跟业务一起开展的。基于上述想法，数据仓库工程的实施

11、，当一期建设完成后，二期、三期将建设更为详细的企业各系统数据模型，增加新的源数据系统，扩展和完善数据主题域，新建更多主题数据集市，涵盖整个南车电气的业务范围。以SAP BW数据仓库平台为基础，构建未来企业级中心数据仓库，通过SAP BO平台重新进展报表前端展现层的开发，最后通过EP平台发布，形成SAP BW+BO+EP的商务智能技术平台构造。2.1.2. 系统逻辑架构 系统逻辑架构示意图 源系统说明本次工程的主要数据来源为SAP 系统和非SAP系统 数据处理层数据抽取层的目的是实现将数据源的数据经过抽取，转换后加载到数据管理层中，同时在这个过程中，需要进展任务的调度控制，任务出错处理以及数据质

12、量的检查。南车电气的工程数据主要通过BW中的ETL技术手段来实现抽取和汇总：1） SAP数据源通过BW标准的数据抽取方式；2） 非SAP系统建设数据库连接数据源oracle，同时考虑增量抽取机制。 数据管理层数据管理层以业务需求为驱动，根据业务不同的主题，建设多个主题模型。建模以维度建模方法论为指导，结合实际需求，考虑模型的灵活性，扩展性以及性能，为前端展现提供一致、高效的数据。 报表平台层报表平台采用业界最为优秀的SAP BO产品，可实现固定格式报表,动态报表,移动展现等多种报表。 报表展现层前端展现SAP EP门户集成BO报表来实现。2.1.3. 系统硬件架构建议方案本次工程至少需要有两套

13、环境：开发环境和生产环境，从逻辑上，两套环境必须分开，权限上必须进展区分。每套环境配置一样数量的服务器，安装一样的操作系统和应用软件，保证环境的一致性。开发的资源配置可低于生产环境。由于未来BW将作为南车核心数据仓库使用，众多核心的业务系统中的数据都需要抽取到BW数据库中，我们调研了一局部业务系统的数据总量及增量如下表所示系统名称当前数据量月增量数据SAP ERP2.1T4050GSAP CRM115.77G34GPLM710G2530G供应商门户电气加国变52.3G约0.8G供应商门户风电19.5G约0.1G供应商门户电动39.6G约40M费用管理系统35G1G1.5G投资管理系统46G预算

14、系统5.88G0.1G上述系统只是局部核心业务系统，其当前的数据总量为3个多T，未来5年的数据增量保守估计为610个T。而BW系统的数据 基本上为源系统数据量的1.52倍，也就是说在数据仓库服务器的存储设备上至少要准备20T以上才能满足未来5年内的业务需求。目前南车BW生产环境的数据库服务器存储空间较小，才不到2个T，而且已经使用了80%左右，所以我们建议在服务器存储空间上需要有较大的配置增加。服务器种类VCPU 虚拟CPU内存硬盘空间性能问题简述BW开发服务器(应用+数据库)420GC:50G;D:1500G操作响应慢EP开发服务器420GC:80G;D:300G操作响应慢BW生产服务器12

15、30GC:100G,D:300G数据查询等待时间长BW生产数据库服务器1230GC:100G,D:1800G,D:400G数据查询等待时间长EP生产服务器1230GC:100G,D:1800G,D:400G数据查询等待时间长由上表中我们可以看到几乎每一台服务器都有不同程度的性能问题，但光看配置感觉在CPU和内存上并没有太大问题，所以我们的做法是在工程启动之后，将会派遣资深的SAP BASIS参谋对于相关系统的内存使用率、CPU使用情况、服务器资源分配是否合理等等情况进展评估，找准产生性能问题的原因之后，我们再进展相关的BW软硬件配置调整。2.1.4. 未来建设目标第一阶段目标：1. 数据获取：

16、将所有源系统数据通过ETL工具和BW数据抽取汇总到数据仓库；搭建智慧采集平台以录入的方式对业务系统中无法抽取的指标数据进展统一上报，使其汇总到数据仓库的接口表中存放重大任务、重点工作的进度、数据调整也将通过智慧采集平台来调整并保存到数据仓库之中。2. 指标管理：进展指标管理系统的初步建设，该系统主要功能为设置指标阀值、指标权重、指标字典、梳理指标归口关系，是一个管理维护整个指标体系的强大系统；由于涉及的功能较为复杂，我们会逐步完善充实该系统，本期的目标是该系统的初步建设，主要开发指标阀值、指标权重维护功能。3. 指标展现：我们在XX智慧决策平台上实现多个事业部和产业板块的绩效数据汇总和BSC指

17、标展现，同时还包括财务、运营、人事等方面的主题分析，主要内容为各类日常使用报表、管理驾驶舱以及绩效考核重大任务。阶段性成果：这一阶段的工作重点是XX智慧采集平台、XX智慧决策平台的建设以及这两个平台同南车时代电气原有的企业级数据仓库、报表平台相整合，同时做好数据仓库的数据梳理工作。当第一阶段顺利完成之后，将会形成一套完整的绩效管理系统和面向事业部及集团的BI系统，届时所有相关绩效考核的数据都可以顺利的进入数据仓库中，并进展正确的合并汇总。同时，对集团和事业部BI用户实现严格的权限划分，使不同管辖权限的用户看到不同的数据，为今后系统建设及扩展打下坚实基础。第二阶段目标：1. 深化主题：对一期已经

18、开发的主题分析、绩效指标进展更深入分析和展现，指标的监控及考核从一期的二级对象深入到三级对象中，各个BCS战略层面的进一步深化。2. 提升指标管理：完善指标管理系统的功能，在第二阶段中指标字典、指标归口关系设定等功能将陆续开发，最终使得整个指标管理平台可以完全满足整个系统指标管理维护的需要，使得未来的开发维护本钱大大降低。3. 完善BI平台建设：将一期已经得到的成果结合平衡计分卡的理念，将企业四个维度财务成果、内部管理、市场与客户、学习与开展的关键指标进展多角度探索分析；同时从一期的指标展现提升为数据分析，多维分析、预测分析等商务智能的王牌分析全面展开，为高层决策层与知识型管理者提供科学的决策

19、依据。阶段性成果：在这一阶段中，主要是对一期已经建设完成的较为全面的绩效管理系统的全面深化，包括预测分析、多维分析、各个主题分析的深入和系统功能的完善。在第一阶段，我们看到的是绩效指标的展现、监控，现在我们将可以根据更全面的数据定义各个单位个性化的指标，领导可以从指标的分析、预测，深入了解到每一个环节的问题，了解问题的原因，从好更好的帮助管理层了解如何让企业运作的更好。考虑到未来可能有的系统扩展和SAP ERP故障，XX智慧采集平台依旧在整个架构中扮演重要的角色，但是手工上报数据和自动上报数据将通过数据标签严格区分，以便事业部和集团清楚数据来源。第三阶段：随着数据仓库中越来越丰富的数据，南车电

20、气已经完全具备了大数据分析的能力，此时可以引入先进的数据分析软件如SAS等为集团BI系统进展更多的挖掘和分析，届时将实现一些高级别数据分析的需求和结果。例如，我们可以从风机运行时各部件传感器传回的大量秒级数据之中分析得到为什么这个型号的风机故障率会高故障主要集中在哪几个点当出现怎么样的数据参数波动时，风机的哪个部件有可能将会出问题从而做到设备的故障预测，减少设备的非方案性停机维护，增加客户的经济效益，提升客户的满意度。同时，随着技术的开展和实时数据及性能的需求，可以把原先的数据仓库替换成HANA产品，HANA强大的数据处理能力和系统实时性数据的展现可以通过关键指标体系，展示企业实时的运营状态，

21、将采集到的数据形象化、直观化、具体化、时效化。让管理层随时可以观察到企业的运转状态，即使得到分析预测结果来辅助自己的决策，为战略层和管理层提供“一站式的决策支持。在这个阶段中，我们要更强化BI系统数据仓库架构，通过从业务系统抽取更多的明细数据以使集团BI系统可以分析到凭证级粒度，在这个基础之上我们可以为各个产业板块开发定制化的DataMart。这一阶段工作重点将会是如何做好HANA平台的替换以及如何运用数据分析软件做到BI系统的全面预测、深入的数据分析及多元化的报表展现。最终成果：南车时代电气BI系统通过整合各个事业部、分子公司、产业板块业务数据，将集团各层级管理人员关心的业务指标以驾驶舱、分

22、析报表等形式通过XX智慧决策平台的个性化展现， BI战略管理层通过这个平台可以一目了然地看清企业全貌和业务全貌，让企业管理者从各个方面多个个维度来了解自己的企业，为集团层面、事业部层面和分子公司管理层提供高效数据分析和决策支持。与此同时，通过大数据、数据分析等应用，逐步形成针对各产业板块的个性化的数据挖掘、数据预测，以提高对市场的洞察力、提升客户满意度、促进技术创新，最终达成提升企业市场竞争力，为企业创造更多的经济效益和社会效益。2.2. 南车时代电气数据仓库平台建设2.2.1. 数据仓库建设原那么数据仓库系统的建设不是一蹴而就的，是一个渐进和长期的过程，所以，XX公司在南车电气数据仓库建设工

23、程方案规划过程中，始终贯穿了以下原那么：l 先进性：采用业界领先的管理思想和技术手段构建数据仓库，保证信息化体系构造和数据仓库解决方案在业界处于领先地位；l 开放性：数据仓库系统模型采用国际统一标准进展建模，集成SAP ECC各模块数据，这些数据可供管理人员共同使用，支持多种数据源和第三方的分析与报告工具，支持数据的抽取和数据的分析，如能够提供对各种数据业务含义进展解释和方便的查询，为开发人员提供高效的外部接口。l 灵活性：数据仓库系统的模型需要能够依业务变化而调整，南车电气数据仓库系统从不同的角度对整个南车电气的生产情况和销售情况进展多维度、多角度、多指标的不同层次的分析，这样就确保了随着业

24、务的开展，可以很方便的在此基础上扩大更多的应用、主题，用户能够灵活地根据实际需要定制不同层次的分析。l 持续性：数据仓库系统提供了一个完善的数据平台，保存了大量的历史数据，具备极佳的扩展性，可以为今后可能出现的管理、决策支持系统提供数据支持。l 容灾性：数据仓库系统的3个重要元件，包括ODS、EDW、DM的系统平台架设于不同的数据库实例，此种设计确保系统因单个系统发生灾害时，减少系统恢复的时间，降低相应的损失。2.2.2. 数据仓库标准体系设计2.2.2.1 数据仓库目标分析数据的存储和管理是企业级数据仓库的核心内容之一，企业级数据仓库存储详细数据及必要的汇总数据,支持整个企业的业务分析和决策

25、。现有业务系统的数据被抽取、清理，并有效地集成到数据仓库中，并按照主题进展重新组织。数据仓库设计时应全面考虑，实施时可以先按照需求的轻重缓急选择局部业务主题，然后逐步扩展到涵盖全部业务。数据仓库管理的数据包含了集成之后的多年历史数据，数据量是巨大的。数据应被合理的规划、组织、存储，分片和索引，保证数据的管理和使用的高效性。按照企业建设数据“唯一事实的要求，数据仓库应为各级业务人员提供一致的信息视图。因而，整个企业应共享统一的数据存储模型。与这样的要求相匹配，企业数据仓库采用满足第三范式的标准化建模。标准化建模是一个剔除冗余并应用业务规那么的过程，它的目的是为了更好的理解和表达存在于数据元素之间

26、的依赖性和参与性。标准化的关系型数据通常能够给出准确和无歧异的答复。标准化建模的目的是建设企业级数据仓库的逻辑数据模型。逻辑数据模型是把业务需求，特别是对数据的需求，用标准化的ER模型和文字进展描述。它反映的是业务逻辑，因此它是数据库中立、技术无关的；同时，它应能涵盖业务需求的各方面，答复有关业务的所有合理问题。逻辑数据模型标识出业务管理领域中涉及的主题、实体、属性，及它们之间的关系。主题集中反映某方面业务内容，通常是同类或关联关系较为严密的实体的集合。实体是任何可以区分的人、地点、事情、事件或概念，信息围绕它来保存。属性是实体的特性或数据字段。对数据仓库需求进展分解，按业务主题进展组织，将业

27、务主题相关的数据组织成主题域，并对各指标进展分析。数据仓库目标分析后形成数据仓库目标说明书，其中详细说明包含的业务主题、业务主题域等内容。数据模型是数据仓库系统的关键局部，开发数据模型除了要描述企业现有的业务数据架构，还要满足企业未来业务扩展的需要，通过整体数据架构的搭建可以实现以下三个目标： 数据整合，建设业务数据构架，找出业务工程的相互关系，描绘企业的各个业务工程在现实中是如何被组合在一起的，创立出企业业务的整体性视图，基于业务数据架构创立企业数据模型，能够较好地保证数据模型的稳定性和有效性。 理解业务，不同部门用户对数据有着不同的理解，作为企业级的决策支持系统必须通过一定的手段把这些不一

28、致的理解定义出来，支持性元数据的使用就是解决这一问题的主要手段。 数据分析，业务上经常遇到同一指标在不同报表里得到的值不一致，有些不一致是为人所知的，有些不一致却没有人清楚，通过对数据的分析和了解，使不一致变得明显而可操作，是数据模型建设的主要目标之一。通过元数据的使用，记录数据的加工规那么及使用环境，可以让使用者清楚地知道差异的原因，从而正确使用这些数据。控制好建模范围和周期将直接关系到工程的进展，最好的方法是利用已有的各类业务需求、报表需求及查询需求，借助建模人员本身的业务经历及与各部门业务人员的沟通，将获得的需求片断有机地组织成一个完整的目标区域，在区域范围内开展建模工作。2.2.2.2

29、 数据仓库逻辑模型数据仓库逻辑模型设计要进展的工作主要有： 分析主题域，确定当前要装载的主题； 确定粒度层次划分； 确定数据分割策略； 关系模式定义； 记录系统定义。逻辑模型设计的成果是，对每个当前要装载的主题的逻辑实现进展定义，并将相关内容记录在数据仓库的元数据中，包括： （1） 适当的粒度划分；（2） 合理的数据分割策略；（3） 适当的表划分；（4） 定义适宜的数据来源等。2.2.2.3 数据仓库物理模型数据仓库物理模型所做的工作是确定数据的存储构造，确定索引策略，确定数据存放位置，确定存储分配。确定数据仓库实现的物理模型，要求设计人员必须做到以下几方面： 要全面了解所选用的数据库管理系统

30、，特别是存储构造和存取方法。 了解数据环境、数据的使用频度、使用方式、数据规模以及响应时间要求等，这些是对时间和空间效率进展平衡和优化的重要依据。 了解外部存储设备的特性，如分块原那么，块大小的规定，设备的I/O特性等。2.2.3. BW数据仓库构造定义2.2.3.1 数据抽取层 数据抽取层是面向业务主题划分的一组数据模型，用于从每个源系统中抽取必需的数据。该层数据对接BW底层与其他业务系统数据，同时仅对该层数据进展 基本的清理，以保存业务系统原始数据。BW系统使用信息包完成对业务源系统的抽取工作，主要抽取SAP ECC、PLM、报价系统、预算系统等核心系统以及外部文本的数据，根据的具体情况，

31、可以将各业务系统数据源信息包分为以下几类：l 系统历史交易数据初始化信息包；l 系统增量交易数据抽取信息包；l 系统全量交易数据抽取信息包。为了将数据从各源系统顺利抽取至BW系统，需要进展以下工作：l 配置BW与各源系统的接口连接；l 复制各业务源系统的数据源；l 创立各数据源的初始化、全量、增量信息包；l SAP ECC系统LO数据源的初始化，删除，填充设置表；l 执行信息包，装载数据至PSA；l 创立信息包到数据抽取层DSO转换及DTP；l 将数据从PSA加载至数据抽取层DSO。2.2.3.2 数据逻辑层数据合并层是面向客户业务操作将抽取层数据进展初步的清洗和整理，将数据抽取层中数据按照业

32、务规那么集成、整合的过程，在此模型上执行粒度较细的查询分析。该层模型的集成、整合工作主要分为以下两大类：l 不同业务系统间模型合并数据抽取层中来自不同业务系统的模型数据，按照业务规那么创立模型转换，进展数据合并。该过程要注意来自异构业务系统的数据格式、关联关系。根据实际需要新增数据映射关系表，以保证数据合并。l 同一业务系统内模型合并数据抽取层中来自同一业务系统的模型数据，按照业务内容及逻辑规那么创立模型转换， 进展数据合并。以上合并过程，最终都通过数据传输流程DTP进展数据加载，将数据抽取层转换、加载至数据逻辑层，DTP默认加载方式为增量加载。2.2.3.3 数据分析层数据分析层是面向高层战

33、略分析将数据合并层的业务数据统一汇总到数据分析层，提供综合决策数据支撑。该层模型的设计原那么是以最终分析为准，根据分析规那么创立转换，将数据指标按照多维度组织，同时衍生出计算后分析指标，通过数据传输流程DTP将数据加载至数据分析层。2.2.3.4 ETL过程BW系统集成了对各种源系统进展数据抽取、数据转换及加载到数据仓库的各种功能，并提供简单的图形化操作界面，可以通过简单的拖动实现数据源的建设、数据的抽取，可以定义数据转换的规那么及加载方式、时间等。上图即为BW数据仓库ETL的流程，使用信息包InfoPackage将数据从源系统抽取至BW底层PSA，通过一系列的转换Transformation

34、和数据传输流程DTP将PSA中数据逐层加载至数据抽取层、数据合并层及分析层相应的模型中。2.2.3.5 数据存储BW数据仓库中，数据存储采用的分层设计方法，即上文所划分的数据抽取层、数据合并层、数据分析层。在这样的设计中，数据是真正物理存储于各层模型中。数据在流经各层时，从性能与准确性方面考虑，使用全量或增量。2.2.3.6 分析层数据分析层提供应商务用户一个专业的数据视图，提供多样展示数据必需的功能。选择分析工具集来满足数据展示的需求信息。这个工具的具体信息在软件和硬件层里详细的描述。属性描述主要功能此层给出了支持商务用户信息需求的功能内在关系l 数据存储层l 数据处理l 安全与保密l 系统

35、管理l 软件和硬件l 元数据l 连接2.2.3.7 主数据按照需求应用的需要，主数据首先进入到抽取层DSO中。抽取层、合并层使用DSO存放数据，分析层一般使用DSO存放数据，但亦有使用特性存放主数据，如与时间相关的主数据。2.2.3.8 交易数据交易数据的DSO中，必须记录每笔业务数据的业务产生的时间戳或者日期，且需要明细到凭证级。Cube中仅存放汇总后的业务数据且此类数据是已经经过逻辑处理的。2.2.4. 数据仓库管理标准及命名标准2.2.4.1 命名规那么设计原那么层次常用名作用4Outbound Data Layer (ODL)数据集市接口层通过Open Hub、BAPI、RFC等方式向

36、系统外的应用程序提供数据的接口层。3Reporting Data Layer (RDL) 报表层报表层，主要由立方体、多信息提供者、虚拟信息提供者构成。以业务需求和性能为首要考虑因素进展最终输出模型维度设计。2Consolidation Data Layer (CDL) 逻辑合并层逻辑处理层，实现报表逻辑，储存逻辑处理完的数据。1Inbound Data Layer (IDL)原始数据层全量保存来自数据源的数据，是以后假设干年所有报表需求的数据基础，保证一期上线以后，后面假设干年对数据的需求不会导致ERP停机抽取。此层数据未经过转换和数据粒度处理，全部采用覆盖模式的ODS构成，局部业务模块可以

37、采用写优化ODS。0Persistent Staging Area (PSA) 缓存层数据缓存层，与数据源对应，占用BW数据库磁盘空间最大比例，每三到六个月定期清理一次。2.2.4.2 BW系统开发对象通用编码2.2.4.2.1 ，代表源系统，按以下标准编码。全称适用于信息区域的命名，缩写适用于其他开发对象的命名。SAP系统按09数字顺序编码：全称缩写含义SD11SD1SAP ERPSD22SD2SAP CRM以下顺序编码以下顺序编码非SAP系统按AZ字母顺序编码：2.2.4.2.2 ，根据南车管理现状，代表经营中心，按以下标准编码：全称为经营中心全称或者惯用称呼的每个字的拼音首字母。缩写为以

38、下字母编码。全称适用于信息区域的命名，缩写适用于其他开发对象的命名。全称缩写含义NCJT_注：下划线南车集团适用于集团层面或多经营中心，无法具体到某个经营中心的命名FYGLXTA费用管理系统YSXTB预算系统.C.D.E.以下顺序编码2.2.4.2.3 ，代表模型层次，按以下标准编码。全称适用于信息区域的命名，缩写适用于其他开发对象的命名。全称缩写含义IDLI原始数据层CDLC逻辑合并层RDLR报表层ODLO数据集市接口层IBJB特征信息区域2.2.4.2.4 ，代表数据主题，按以下标准编码。无缩写及全称的区分。除了以下常用缩写，其他的内容可以根据缩写决定，并及时更新到该标准中。命名主类命名子

39、类主题含义FI财务含财务通用，或无法归集到子类的AP应付AR应收CO管理会计GL总账PA盈利分析SD销售及分销含销售通用，或无法归集到子类的SO订单PO采购单DN发货单SP装运单BL发票MM库存PP生产2.2.4.3 南车BW系统开发对象命名标准2.2.4.3.1 Info Area1. 最多30个字符。2. 以Z_ SINOCHEM_开头。3. 第一层。注：此层已建设，无需重建。Z_SINOCHEM_LAYERED_DESIGNLSA模型设计4. 第二层：根据模型架构层次创立。注：此层已建设，无需重建。Z_SINOCHEM_LAYER_IDL原始数据层Z_SINOCHEM_LAYER_CDL

40、逻辑合并层Z_SINOCHEM_LAYER_RDL报表层Z_SINOCHEM_LAYER_ODL数据集市接口层Z_SINOCHEM_LAYER_IBJ特征信息区域5. 第三层及往下层，分IDL，CDL及RDL，这两种情况，适用不同的命名标准。注：从此层开场，按照编码标准和工程需求，进展创立。 如为IDL层i. 第三层首先按模型层次及源系统创立，命名标准是：Z_SINOCHEM_LAYER_参见3.2.4.2.3。参见3.2.4.2.1。例如：Z_SINOCHEM_LAYER_IDL_SD1集团SD1原始数据层Z_SINOCHEM_LAYER_IDL_FILE各类文本ii. 除文本之外的第四层，

41、根据需要按照数据主题域区分，即。Z_SINOCHEM_LAYER_见3.2.4.2.4。例如：Z_SINOCHEM_LAYER_IDL_SD1_SDZ_SINOCHEM_LAYER_IDL_KTDB_PPiii. 文本向下第四及第五层，根据需要，首先按照经营中心，然后按照主题域区分。第四层，编码标准如下：Z_SINOCHEM_LAYER_见3.2.4.2.2。例如：Z_SINOCHEM_LAYER_IDL_FILE_SYZXZ_SINOCHEM_LAYER_IDL_FILE_ZHJT第五层，编码标准如下：Z_SINOCHEM_LAYER_见3.2.4.2.4。见3.2.4.2.2。例如：Z_S

42、INOCHEM_LAYER_IDL_FILE_SYZX_YZZ_SINOCHEM_LAYER_IDL_FILE_ZHJT_YS CDL和RDL层i. 首先按经营中心创立，命名标准是：Z_SINOCHEM_LAYER_参见3.2.4.2.3。见3.2.4.2.2。例如：Z_SINOCHEM_LAYER_CDL_ZHJTZ_SINOCHEM_LAYER_CDL_SYZXZ_SINOCHEM_LAYER_CDL_ZHGJii. CDL和RDL层，继续下分时，按主题域创立，命名标准是：Z_SINOCHEM_LAYER_参见3.2.4.2.3。见3.2.4.2.2。见3.2.4.2.4。例如：Z_SIN

43、OCHEM_LAYER_CDL_XTGS_FIZ_SINOCHEM_LAYER_CDL_HFZX_SD2.2.4.3.2 ODS1. 最多8个字符。2. 以Z开头。注：如果以“Z开头的编码已全部被占用，才可“Y。此条适用于所有以“Z开头的命名规那么，下面不再特殊注明。例如：ZI1SOS01SD1的IDL层订单ODSY I1SOS01某某中心的整合订单ODS3. ODS必须根据它的作用分配到指定的层次，如IDL，CDL，RDL。4. 命名原那么：ZS ，见3.2.4.2.3。 ，见3.2.4.2.4。 ，2位数字编码。 ，分如下两种情况，分别适用不同的编码规那么：i. 如模型属于IDL层，那么代

44、表源系统编号，即，见2.1。例如：ZI1SOS01SD1的IDL层订单ODSZI2SOS01SD2的IDL层订单ODSii. 如模型属于CDL或那么RDL层，那么代表经营中心，即，见2.2。例如：ZC_SOS01ZCASOS012.2.4.3.3 Cube1. 最多8个字符2. 以Z开头3. Cube必须分配到RDL层次4. 命名原那么：ZRC ，见3.2.4.2.3。 ，见3.2.4.2.4。 ，2位数字编码。例如：ZRLGLC01财务公司收入分析CubeZR_GLC01集团的收入分析Cube2.2.4.3.4 MultiProvider1. 最多8个字符2. 以ZR开头3. 必须分配到RD

45、L层次5. 命名原那么：ZRM ，见3.2.4.2.3。 ，见3.2.4.2.4。 ，2位数字编码。例如：ZRLGLM01财务公司收入分析CubeZR_GLM01集团的收入分析Cube2.2.4.3.5 Aggregates1. 命名原那么：_AGGR ：所属Info Cube的技术名称 ，2位数字编码。例如：例如：ZRLGLC01_AGGR01ZR_GLC01_AGGR012. 描述原那么：把累计的特征列出，用 “/隔开.例如：Material/Plant/MonthPlant/Material/Component/Month2.2.4.3.6 InfoObject Catalogs1. 最

46、多30个字符2. 以Z开头3. Cube必须分配到RDL层次4. 命名原那么：Z_ ：所属Info Area的技术名称 CH：特征 KF：Key Figure2.2.4.3.7 Info-Object命名规那么： Z_变量字段长度说明Function Area2见3.2.4.2.4Name5自定义名称局部参照R3字段名例如：ZFI_BANK银行。2.2.4.3.8 Hierarchy 为系统标准的来自BI Content中的信息对象建设Hierarchy时，按以下命名规那么：命名规那么： Z_H_变量字段长度说明InfoObject7NN2当前编号 (标号从 01开场)Date6有效起始日期Y

47、YMMDD注意：如果长度不够，可以将缩写。例如：为0Company建设Hierarchy时，命名为：ZCompany_H01_031121。也可缩写为ZCC_H01_031121。 为自定义的信息对象建设Hierarchy时，按以下命名规那么：命名规那么： Z_H_变量字段长度说明InfoObject7见3.2.4.3.7NN2当前编号 (标号从 01开场)Date6有效起始日期YYMMDD注意：如果长度不够，可以将缩写。例如：ZFI_BANK_H01_031121。2.2.4.3.9 Query 工程组内部命名规那么：命名规那么： _QVariableLengthCommentMultiPr

48、ovider8Multiprovider的全名NNN3三位数字，从001开场 其他用户或者其他用途创立命名规那么例如，培训、测试用途：命名规那么： _Q变量字段长度说明Function Area2见模块 命名规那么Business Area4同R3系统NNN3当前编号 (标号从 001开场)例如：ZT_FI_XXXX_Q00012.2.4.3.10 Struture命名规那么： _S变量字段长度说明MultiProvider见Cube命名规那么NNN3当前编号 (标号从 001开场)例如：ZR_SDC01_S0012.2.4.3.11 Bex Variable1. 最多8个字符2. 命名原那么

49、：Z_ P：单值 I：范围 H：层次 N：层次节点 T：文本变量 F：公式变量 NNN：3位数字编码2.2.4.3.12 Calculated Key Figure1. 最多30个字符2. 命名原那么：_CKVariableLengthCommentInfo Cube8Cube全名_CK2固定NNN3三位数字，从001开场2.2.4.3.13 Restricted Key Figure1. 最多30个字符2. 命名原那么：_RKVariableLengthCommentInfo Cube8Cube全名_RK2固定NNN3三位数字，从001开场2.2.4.3.14 Data-Source/Inf

50、oSource 由标准BI Content激活生成的DS或者IS，使用系统自动生成的名字，勿需改名字。 由于客户定制需要，由BW参谋新建的非系统标准BI Content的DS或者IS，请按照以下方式命名：命名规那么： Z_变量字段长度说明Function Area2见3.2.4.2.4M/T1M：代表主数据T：代表业务数据NN2当前编号 (标号从 01开场)2.2.4.3.15 Info-Package命名规那么： _变量字段长度说明DataSource见 Datasource 命名规那么Update1F：Full-UpdateD：Delta-UpdateI：Delta-Initial例如：0

51、FI_GL_4_D2.2.4.3.16 Process chain1. 命名原那么：ZPC_例如：ZPC_IM_TRAN_WKZPC_MAT_ATTR_DL2.2.4.4 BW系统权限命名规那么角色2.2.4.4.1 singlerole命名规那么：_变量字段长度说明Site3见3.2.4.2.1.业务代码OBJECT49权限对象名称或模型名称NR4可选对于模型的角色可以为空，权限对象下的具体付值例如：为南车建设公司代码上的权限对象，可以命名为：ZS_CMP_XXXX。2.2.4.4.2 commonrole命名规那么： _变量字段长度说明Site3见3.2.4.2.1 业务代码OBJECT4

52、9权限对象名称或模型名称NR4可选对于模型的角色可以为空，权限对象下的具体付值2.3. 南车时代电气BW数据仓库优化方案目前南车电气的BW系统设计较不标准，很多可用标准方式进展CUBE开发的模块也用了ABAP程序来进展实现，从中我们找出了很多可以优化的点，通过我们对于南车电梯BW系统现状的调研之后，我们给南车提供如下BW优化建议方案：1. 现系统模型命名没有明确的标准，考虑确定明确的命名标准以便于后续的系统管理，及后续开发工程对原有模型能有比较清楚的了解。涉及范围包括信息范围、自定义数据源、信息源、信息对象、模型、处理链、OPEN HUB、APD、QUERY、程序、函数等等2. 现系统区域划分

53、较乱，考虑划分出比较标准明确的区域。比方分主数据区域、业务数据区域、业务数据区域还可分为数据抽取层、转换层、合并层、展现层等等。3. 考虑系统资源的合理安排及日常数据加载的监控，考虑处理链调度时间的安排、监控、各环节数据加载顺序及方式的调整等等。4. 现BW数据源大多为3.5数据源、信息源、传输规那么、更新规那么，考虑转换为7.0数据源及转换，方便以后的运维管理及系统新功能的应用。5. CUBE层面未做聚集、压缩、分区等处理以及CUBE维度的设置比方“行工程维“高基数维等方面的考量。6. 系统里存在冗余模型及报表可考虑清理优化系统空间；系统可规那么清理机制，比方定期清理PSA数据、ChangL

54、og数据等等。7. 主要的库存相关模型考虑优化，现大多数通过SE38程序实现，考虑是否可用标准模型替换重构，例如涉及的程序有：ZTBW001、ZTBW003、ZTBW004、ZTBW005、ZTBW006、ZTBW007、ZTBW008、ZTBW010、ZTBW031、ZTBW032、ZTBW033等，另外，以上程序里大局部功能是通过调用现有模型的query通过一定逻辑处理再存入到另一模型，此局部功能完全可以用BW的APD的标准功能替代实现，更方便后续的维护及管理。8. 经落实系统中还存在抽取HR系统人员信息的程序ZTBW016，此程序将人员信息数据从HR系统抽取到BW系统中的二维表中，再按人

55、员级别发邮件给相关用户，现程序可能存在些问题，为方便以后的管理及操作，此程序可以用BW连接数据库作为数据源的标准方式替换。2.4. 数据展现层迁移方案当完成BW优化升级的工作之后，我们即将着手部署SAP BO集成EP门户作为新的数据展现应用层。首先我们会对该54张报表的业务逻辑进展梳理，了解业务之后将进展面向未来的数据展现层报表构造设计，使得迁移到BO设计环境的报表符合未来的报表设计标准，实现现阶段报表查询转线的 基本应用。本期工程需做迁移的报表共54张。在优化好BW环境并且重构局部CUBE的基础之上，我们将当前BW中的相关Query的展现重构，以BO为设计平台，在原BW CUBE上重新开发，同时将开发好的新报表集成到EP门户中，最终形成SAP BW+BO+EP的商务智能技术平台构造，完成重要历史报表的迁移工作。2.5. 主数据共享平台方案主数据源系统目标系统物料ERP、PLMSPM制造BOMERP、PLMSPM客户ERPECM供应商ERPECM人员HCMSPM岗位HCMSPM组织机构HCMSPM订单BOMERP只抽取从上表中我们可以发现本期工程中需要进展系统主数据共享的一共分为8个主数据指标、一个SAP系统和4套非SAP系统。首先BW的抽取方式可分为两种：1. 对SAP ERP系统采用BW标准的抽取方式