CTGMBOSS EDAODS技术规范.doc

《CTGMBOSS EDAODS技术规范.doc》由会员分享，可在线阅读，更多相关《CTGMBOSS EDAODS技术规范.doc（78页珍藏版）》请在三一办公上搜索。

1、EDA-ODS ：技术规范 版本V1.0 2007年7月目 录1文档说明11.1编制说明11.2适用范围21.3起草单位21.4解释权21.5版权22系统技术架构32.1系统技术架构32.2系统技术特点42.2.1批量数据加载和实时数据更新并存42.2.2三范式模型、星型模型、宽表模型并存42.2.3细粒度数据和汇总数据并存42.2.4事务查询和统计查询的并存52.2.5数据保存周期介于生产系统和EDW之间52.3系统总体技术要求53系统功能框架73.1概述73.2数据整合域83.2.1ETL整合83.2.2数据更新配置113.3数据质量管理域123.3.1数据质量检查123.3.2数据质量执

2、行153.4数据共享域183.4.1共享配置管理183.4.2数据/服务提供183.4.3共享权限控制193.5数据应用域193.5.1数据查询193.5.2固定报表203.5.3计算应用203.5.4动态报表203.6公共管理域213.6.1系统管理213.6.2系统监控293.6.3元数据管理324系统技术要求344.1数据整合344.1.1技术要求354.1.2技术建议364.2数据存储364.2.1技术要求364.2.2技术建议384.3数据应用394.3.1技术要求394.3.2技术建议404.4数据共享404.4.1技术要求404.4.2技术建议414.5元数据管理414.5.1技

3、术要求414.5.2技术建议425系统实施425.1实施原则425.2实施建议445.2.1主要系统改造建议445.2.2流程和岗位调整建议465.2.3IT管控支撑建议465.3实施步骤465.3.1实施进度465.3.2实施步骤486系统部署506.1系统部署的参考因素506.2ODS系统部署模式506.2.1模式一：集团ODS省集中ODS516.2.2模式二：集团ODS省集中ODS本地运营数据平台536.3模式演进557附录557.1编制人员557.2ODS系统物理架构、硬件配置估算及硬件配置示例567.2.1系统物理架构图示例567.2.2系统硬件配置估算方法577.2.3系统存储规划

4、587.2.4硬件配置示例607.3第三方工具评价标准及产品比较627.3.1ETL工具627.3.2报表工具677.3.3元数据管理工具741 文档说明1.1 编制说明中国电信集团明确提出了客户品牌统领市场经营工作的要求，在市场经营的各项具体工作中细化和逐步落实客户化经营思路，适应以“产品”为中心向以“客户”为中心的转变，要求在市场经营的各项具体工作中细化和逐步落实客户化经营思路。市场的转型对于IT系统固化以客户为中心的市场计划、营销策划、销售、服务、统计分析等工作提出了更高的要求，需要相关流程的变更和优化，需要建立和应用360度客户统一视图信息，在各环节中应用客户统一视图信息，同时实现信息

5、在各渠道和前后端的进一步共享。在客户化流程的设计中我们发现客户服务和营销过程越来越依赖于频繁地查询集成的客户信息，这些都需要跨系统运营数据的支撑；同时，由于各系统数据标准不一致，存在同样信息在不同系统中取值不同的现象，带来了信息的不一致，无法取得一致的统计分析数据，不利于企业的精确化管理，给业务发展带来一定影响。中国电信ITSP1.0和CTG-MBOSS规范中提出的ODS（运营数据仓储）对于解决以上问题是及时和有效的。ODS是中国电信IT架构中的重要组成部分，在ITSP1.0和CTG-MBOSS中已经明确了其在企业信息化系统中的定位：即数据整合（承载客户统一视图）、数据共享、跨系统数据应用和数

6、据质量检查。随着CRM、计费、服务开通、资源等核心IT系统建设的逐步开展，尤其是CRM、计费省集中系统的逐步到位以及客户品牌统领市场经营工作对IT固化生产流程的迫切要求，使得ODS成为承载企业数据模型及数据标准，并据此整合各系统数据以实现企业跨系统数据共享，提供跨系统数据应用，提升数据质量的最好承载平台。因此，作为对中国电信CTG-MBOSS系列规范的必要补充，统一各省和系统集成商的认识，解决以上问题，我们制定了中国电信运营数据仓储（简称ODS）相关规范，主要包含CTG-MBOSS EDA-ODS：总体规范V1.0（以下简称ODS总体规范）和CTG-MBOSS EDA-ODS：技术规范V1.0

7、（以下简称ODS技术规范）。ODS总体规范主要介绍了ODS系统建设驱动力、业务目标、系统目标、系统架构、系统边界及系统演进等方面的内容，明确指出了中国电信ODS系统的定位、功能及与其它周边系统的边界划分原则。ODS总体规范从定位和系统边界上指导各省ODS的建设。ODS技术规范主要介绍了ODS系统技术架构、功能框架、系统总体及各功能域各自的技术特点和技术要求以及ODS系统实施与系统部署等方面的内容。ODS技术规范从技术和实施角度指导各省ODS的建设。与此规范配套下发的还有中国电信EDM模型3.0，其中BSS部分设计了细化到具有物理模型特征的逻辑模型，此部分作为ODS规范的重要组成部分，直接作为O

8、DS整合层数据模型的实施要求。1.2 适用范围本规范适用的范围为中国电信集团公司。1.3 起草单位本规范起草单位为中国电信集团公司。（参加编写ODS技术规范的人员名单见附录一。）1.4 解释权本规范的解释权属于中国电信集团公司。1.5 版权本规范的版权属于中国电信集团公司。2 系统技术架构2.1 系统技术架构遵照CTG-MBOSS EDA-ODS：总体规范V1.0中对ODS的定位，ODS整合生产系统的运营数据，形成统一的企业运营数据。ODS系统一方面承担提供跨系统运营数据的共享职能，另一方面承担基于运营数据的查询、统计报表和批量计算功能，同时作为数据仓库的主要数据来源。ODS系统需实现的功能需

9、要由相应的技术架构实现支撑。ODS从周边的各生产系统包括CRM、计费、网上客服中心、10000号等系统通过ETL或EAI等技术将源数据抽取加载到系统中，通过对源数据的清洗、转换在ODS中形成遵循企业数据模型的统一基础数据，根据应用需要，ODS通过数据处理组件形成各类汇总数据。基于系统中整合与汇总好的数据，ODS系统上以B/S架构直接部署查询、报表等数据应用，ODS系统还可通过数据服务组件以文件、数据视图、数据服务等形式向外围的生产系统提供共享数据，与生产系统配合完成跨域应用支撑。ODS系统的技术架构如图2-1所示：图2-1 ODS技术架构图2.2 系统技术特点依照ODS系统的定位，ODS系统不

10、同于以事务处理为主的生产系统，也不同于以统计分析为主的数据仓库系统。系统需要支撑跨域数据查询功能，还需要支撑生产系统对一定周期内运营数据数据统计与计算功能。系统的定位决定了ODS系统具有与生产系统与数据仓库不同的技术特点：2.2.1 批量数据加载和实时数据更新并存ODS系统需要从源系统抽取加载计费清单等大批量运营数据，也需要从生产系统准实时同步客户、产品实例、账户等数据，并对ODS系统的数据同步更新。2.2.2 三范式模型、星型模型、宽表模型并存ODS系统抽取源系统数据到接口层，接口层数据和源系统数据采用相同的基于3NF的数据模型设计方法。ODS系统将来自各个业务系统的接口层数据进行数据整合处

11、理后进入整合数据层，为了加快外系统查询性能，整合数据层数据需要做部分反范式处理。整合层数据经过汇总和整理后，进入汇总数据层。汇总数据层主要面向报表应用，需要部分采用星型模型设计方法，对于部分复杂查询应用可以采用宽表设计模型。2.2.3 细粒度数据和汇总数据并存ODS系统主要为电信运营提供支撑，需要提供面向单个客户的查询和统计功能，因此需要保存单个客户、清单、帐单等细粒度数据；同时，ODS系统需要提供面向运营的报表型应用，也需要保存部分运营汇总数据。2.2.4 事务查询和统计查询的并存ODS系统需要提供对客户统一视图等个体数据的查询能力，同时需要提供基于渠道经理、地域等维度的汇总数据的统计查询应

12、用。2.2.5 数据保存周期介于生产系统和EDW之间生产系统不需要支撑大量的分析应用，所以只需要保存当前最新的业务数据；数据仓库需要提供经营决策分析功能，所以需要存储较长周期的业务数据。ODS系统结合了两者的特点，既需要提供准实时的运营数据的查询，也需要提供基于一定周期运营数据的统计报表和批量计算应用。因此，ODS系统的数据保存周期将介于生产系统和EDW之间。2.3 系统总体技术要求ODS系统是中国电信EDA架构中的重要组成部分，是生产系统和EDW系统中间的数据缓冲层，担负着客户统一视图、跨域数据共享、运营报表展示和查询统计等功能。从上节“系统总体技术特点”描述可以看出ODS系统兼有OLTP系

13、统和OLAP系统的双重特征，因此系统配置的软硬件需要兼顾到在线处理的性能和批量数据更新、汇总与查询的效率。另外作为中国电信IT支撑系统之一，系统的实现应参考国际标准NGOSS、国内ITSP、CTG-MBOSS等规范，并结合中国电信IT现状，采用先进可靠的设备和技术，确保系统的先进性和成熟性，保证投资的有效性和延续性。ODS总体技术需要注意以下几个方面：网络与硬件方面：1. 采用安全可靠的高速磁盘阵列设备，支持多机高可用群集系统，磁盘阵列与主机系统采用SAN方式连接；2. 采用高速可靠的网络设备，提供高速的I/O能力；3. 主机支持多机群集或海量并行处理技术，支持分区技术；4. 主机采用高可用性

14、(HA)和负载均衡的方式，防止单点故障，提高系统可用性和系统资源的使用率。软件方面：1. 选择对OLTP和OLAP应用都具备稳定处理性能的数据库引擎；2. 选择能对数据整合过程进行有效监控和管理的数据整合工具或技术；3. 数据质量管理是ODS系统承担的重要任务，ODS选择的数据质量管理工具或者自行开发的数据质量管理功能需要对进入ODS系统的数据实施全程闭环的数据质量审核和修正，提高中国电信运营数据质量；4. 选择提供各种接入方式的报表查询和统计分析功能的报表工具；5. 选择为业务处理、技术实现等环节提供清晰的系统导航功能的元数据管理工具，； 6. 采用能对系统内的软硬件节点进行监控和自动预警的

15、系统监控软件；7. 制定完善的备份与恢复策略，采用成熟的备份软硬件，提供快速备份与恢复功能；8. 由于ODS需同时满足前端应用的快速响应和后端数据的实时及批量更新，因此ODS的模型应该采用分层设计方法，兼容两类特征，其中ODS的整合层也会做适度的反范式处理来满足系统的建设要求；9. 为了满足数据的高速加载，系统需进行相关优化操作，优化数据抽取调度策略，避免CPU、Memory、IO等资源的争抢，设计良好的数据文件/表空间/数据表存储规划，保证数据在磁盘的优化分布；10. 对于数据共享层的访问应采用独立接口的原则，将ODS的数据封装为独立接口层提供外部访问，避免ODS系统数据模型直接暴露给外部系

16、统，提高数据安全性。3 系统功能框架3.1 概述为了在业务和IT之间形成统一完整的功能视图，基于中国电信ITSP应用系统目标架构的基础架构部分，继承中国电信CTGMBOSS的功能架构成果，以ODS系统三阶段业务支撑能力为目标，制定此功能框架，以明确界定ODS系统功能范围和层次，并作为ODS设计和规划系统的基础。本框架遵循CTG-MBOSS功能层次的划分标准，从系统服务对象和支撑对象的角度，将ODS划分为五大功能域：数据整合域、数据共享域、数据应用域、数据质量管理域、公共管理域，如图3-1所示：图3-1 ODS系统功能框架3.2 数据整合域数据整合域是ODS系统的关键部分，ODS通过多种技术准实

17、时或实时地从源系统中抽取数据，抽取过来的数据首先到达ODS的接口数据层进行预处理，然后经过转换等工作到达整合数据层，形成ODS的核心数据。整合层的数据通过整合、计算、汇总形成汇总层的数据。数据整合域功能主要包括ETL和数据更新配置两大部分。3.2.1 ETL整合3.2.1.1 数据抽取ODS从数据源系统获取数据，在实施时需要综合考虑业务需求、抽取效率、源系统代价等因素确定抽取策略，抽取策略包括抽取方式（增量、全量）、抽取时机、抽取周期等。 功能要求1. 支持增量、全量、异步和同步抽取方式；2. 支持多种不同系统平台和数据类型的数据抽取。包括各种关系型数据库系统、各种文件格式的源数据等。3.2.

18、1.2 数据映射源系统数据通过整合从源系统进入到ODS，ODS再提供给外部系统使用时，数据的格式和定义都有不同程度的变化，因此需要在数据整合过程中通过数据映射方式进行转换，数据映射主要定义数据结构、数据定义方面的映射关系。功能要求1. 提供图形化可操作数据映射界面；2. 提供多种关系的数据映射方式，如一对一、一对多、多对一、多对多。3.2.1.3 数据转换数据转换包括格式和类型转换、数据翻译、数据匹配、数据聚合以及其他复杂计算等。多数情况下，数据源到ODS之间主要的转换是格式转换、数据翻译、数据匹配，而数据聚合以及其他复杂计算主要在数据汇总时出现。功能要求1. 支持在不同业务系统之间数据转换。

19、2. 支持不同的数据源系统平台。3. 支持数据的定义、数据结构和错误数据的转换处理。3.2.1.4 数据检查对于文件接口的数据的检查，主要从接口数据的完整性、及时性和正确性三个方面进行检查，系统根据接收文件的时间、入库是否异常等角度进行分析；对于业务应用系统的数据库接口，系统主要从接口的及时性和一致性方面进行检查，通过比较源系统的相关指标，分析数据的可信度。功能要求1. 支持接口文件检查，包括文件名、记录数、实体完整性检查等；2. 支持接口数据检查，包括数据类型、实体完整性等。3.2.1.5 数据加载数据加载是指将抽取转换后的数据加载到ODS中，包括数据行加载和数据块加载。在综合考虑效率和业务

20、实现等因素基础上确定数据加载周期和数据追加策略。功能要求1. 支持批量数据的数据库直接加载；2. 支持多个数据库连接，能够进行大量数据的并行加载；3. 支持自动与手工预加载的流程。当日常数据加载出错，一般采用人工干预的方式来进行，这时需提供一个数据重新接收、加载的操作界面；4. 支持多种加载数据的方式，如直接追加、全部覆盖、更新追加。3.2.1.6 异常控制主要通过计数统计数平衡、拒绝数据量等方便评估数据复制、ETL的具体运行情况，以发现数据整合过程中有关数据的问题，并进行必要的处理。功能要求1. 支持校验点。当外部数据记录特别庞大时，如果因为某种原因发生故障中断后，可以从最近的校验点开始处恢

21、复处理；2. 支持外部数据记录的错误限制定义，同时将发生错误的数据记录输出。3.2.1.7 作业管理ETL作业管理主要包括初始化作业、日常ETL作业、日常复制作业、异常处理作业等，同时要求对并发作业、高负载作业有良好的管理。对于基于ODS的某些特定应用，如数据质量检查和稽核，应该考虑采用统一的作业控制工具进行作业调度和管理。 功能要求1. 提供图形化可操作任务调度与管理配置界面；2. 支持任务属性配置，可以对各项任务的属性进行配置，并保存在后台配置文件中，以备任务调度按序执行；3. 支持总任务的调度，使其按照设置条件自动按序执行任务；4. 支持分任务的调度，可按照任务类型、时间、区域等按照各自

22、设置好的条件进行任务的调度；5. 支持任务的回退，需要对某几项任务进行重新调度时，可以将任务回退到需要重新调度的周期。3.2.2 数据更新配置需要整合的源系统比较多，其中系统架构、数据提供能力、以及提供的源数据使用要求各有不同，因此在数据更新功能方面需要提供灵活的配置能力，提高数据整合的效率和便利。3.2.2.1 更新规则配置提供多种数据更新规则，根据规则特点和业务需要，进行更新规则的配置。功能要求1. 提供图形化的操作配置界面；2. 支持按照源数据的生产特性进行有针对性地规则配置。3.2.2.2 更新方式配置提供多种数据更新实现方式，并且针对不同的数据源系统和不同的数据需要，进行更新方式的配

23、置。功能要求1. 提供图形化的操作配置界面；2. 支持直接追加方式；3. 支持全部覆盖方式；4. 支持更新追加方式。3.2.2.3 更新频度配置在确定更新方式之后，同样需要提供更新方式的频度配置能力，需要从数据源系统的生产压力、系统架构等方面来考虑频度。功能要求1. 提供图形化的操作配置界面；2. 提供不同级别的数据更新频度，如秒级、分钟级、小时级、天或更长时间（包括周和月）。3.3 数据质量管理域数据质量管理域的功能是为了解决目前普遍的数据质量顽疾，通过建立数据质量管理组织机构，制定质量管理规范，确定相应的工作流程方法，并在系统中实现质量检查、修正、考核功能，形成数据质量修正闭环的机制，确保

24、数据质量问题由发散状态转为收敛状态，并随着时间的积累逐步逼近真实状态。数据质量问题不可能在一夜之间解决，突击检查只能短期内改善数据质量，彻底的解决方式是将其作为一项日常的工作由固定的组织机构来执行。3.3.1 数据质量检查数据质量检查是对数据本身执行合法性等方面检查的过程，主要通过设置业务逻辑规则来实现对数据属性、数据属性关系、数据表关系的检查。3.3.1.1 单系统数据质量检查ODS和各个业务源系统形成闭环的数据管理流程，保障源系统数据质量的改进，ODS需要提供对各源系统数据进行数据质量检查功能，例如：对客户名称进行检查、帐户名称检查、用户名称检查、客户地址检查、身份证号码检查等等。 功能要

25、求1. 支持对质量检查的规则进行配置，支持按照不同源业务系统进行配置；2. 提供按照数据质量规则进行数据检查功能；3. 提供数据检查结果展示功能；4. 提供数据检查结果分析统计功能。3.3.1.2 跨系统数据质量检查ODS在整合不同生产系统的数据的过程中，可对不同系统之间的相同属性数据进行一致性进行检查，实现跨系统数据质量检查：功能要求1. 提供对一致性的检查规则进行配置；2. 提供按照数据一致性检查规则进行数据质量检查功能；3. 提供数据检查结果展示功能；4. 提供数据检查结果进行分析统计功能；3.3.1.3 数据质量预警告警当发现数据质量问题，需要及时地将质量问题形成报告，提供相应的预告警

26、信息，便于针对这些预告警信息进行处理。功能要求1. 支持对一定时间段内的数据质量告警/预警信息进行列表显示；2. 告警/预警信息应包括数据质量审核问题单相关信息；3. 针对每条数据质量检查规则可以设置是否作为告警/预警信息出现在告警/预警界面。3.3.1.4 数据质量评估分析数据质量评估分析是指通过配置数据质量问题分析解决过程中的各项考核指标，对数据质量问题处理情况进行分析，使管理层能以直观（报表查询界面）的方式了解通过ODS系统发现的数据质量问题的解决情况并对质量问题的各个岗位进行考核。功能要求1. 支持总量评估功能，以报告模式对连续几个周期（或某个固定周期）的需要评估总量的数据质量检查/稽

27、核报告（可配置），统计各类错误数，从总体上对数据质量的收敛度进行评估；2. 支持源系统数据质量问题评估功能，以报告模式提供按源系统汇总连续几个周期（或某个固定周期）的各数据质量问题报告，统计各类错误，对各源系统的质量的收敛度进行评估；3. 支持专项数据质量问题评估功能，根据连续几个周期（或某个固定周期）的质量问题报告，以报告模式对重点关注的质量专题，制定专题规则进行分析并对结果予以评估。3.3.1.5 业务规则检查源系统数据质量表现出来的问题，可能是业务规则设置、业务理解或实现的问题，那么对这些问题的修正，需要源系统修改业务处理规则。系统通过提供业务规则检查功能，发现数据质量问题，对该问题进行

28、解决。功能要求1. 支持业务规则设定，能够随着业务的发展进行扩展；2. 支持按照业务规则对数据进行检查，并能够生成检查报告；3.3.1.6 数据阀值监控数据阀值监控是指数据在ETL处理过程中，对于抽取、转换、加载、汇总等环节提供阀值监控功能；提供环节和数据处理方式的不同设定阀值功能，同时根据设定阀值进行监控，并显示监控信息。 功能要求1. 支持数据阀值的设定，阀值的触发点可以设置到不同的环节，或者不同的数据处理方式；2. 支持阀值触发点的扩充，以适应监控的需求扩展；3. 支持阀值的动态监控，能够实时地显示监控报告。3.3.2 数据质量执行3.3.2.1 规则调度策略规则通过规则调度引擎来调度执

29、行，调度引擎可以是ETL工具，也可以是工作流产品或者单独开发的程序，根据规则特点和业务需要，配置对规则的调度策略。规则调度策略：事件策略、时间策略、频度策略、控制顺序策略等。功能要求1. 支持事件策略：只有当某事件发生时才会调度执行某规则。比如ETL过程对文件检查规则、记录检查规则的设定。2. 支持时间策略：某些规则执行耗时长，资源占用量大，可以考虑安排特殊事件予以调度执行；3. 支持频度策略：重要数据重要业务检查内容，可以安排频度较高的调用；4. 支持控制顺序策略：某些规则之间具有调用的先后顺序，故需要预先设定。3.3.2.2 规则执行日志对规则执行结果必须通过日志、报告予以详尽记录。规则执

30、行日志是质量管理文档化的一部分，主要记录异常数据的状况，这些异常数据是质量分析的主要依据。通过规则执行日志，可以把握数据质量宏观、微观、收敛性等各方面情况。比如宏观上，了解数据质量汇总后的状况；微观上，清楚每一个质量问题涉及的记录；质量收敛性方面，把握前后两次检查稽核中错误重复出现的记录数、新增错误数、已改正错误数，以及错误发展的趋势状况。功能要求1. 支持定义错误类型和错误代码：通过错误分类和错误代码，可以更好地描述和理解错误；2. 支持定义源表与目标表映射关系：定义源系统表与ODS系统目标表之间的映射关系，便于跟踪错误；3. 支持定义满足日志记录的错误表群：每个错误必须能记录到记录级，并且

31、能详尽记录稽核时间、批次等信息。如：执行批次表、错误汇总表、错误记录表、错误比对表等；4. 支持记录每次规则执行的汇总信息，作为稽核报告的数据基础：规则执行结束后，适时对执行结果进行汇总记录，并形成对应执行报告。规则的每次执行，都必须有详尽的记录，必须满足对执行结果的分析。3.3.2.3 异常通知机制异常通知机制是指对于数据在处理过程中，对于抽取、转换、加载、汇总等各个环节中产生的异常进行通知功能。功能要求1. 支持处理多种异常的触发方式，主要包括数据异常、操作异常等；2. 支持多种异常通知方式：支持通过浏览器方式显示异常信息，支持通过邮件方式发送异常信息，支持通过短信方式发送异常信息。3.3

32、.2.4 异常数据报告异常数据报告是指对于数据在ETL处理过程中，对于抽取、整合、加载、汇总等各个环节中产生的异常数据提供分类统计功能。功能要求1. 支持按照产品、业务、时间等多个维度进行异常数据分类统计和分析；2. 支持按照产品、业务、时间等多个维度进行异常数据分类展现功能。3.3.2.5 质量管理流程数据质量管理总体上来说，是遵循发现问题、分析问题、制定解决方案、解决问题的闭环循环过程。逐步地提高数据质量。功能要求1. 要求提供流程工具来支持质量管理流程的实现；2. 支持质量管理流程模板的制定，能够按照质量问题分类、源系统等属性进行配置；3. 支持数据质量管理流程闭环，保证各种质量问题有对

33、应的处理机制；4. ODS系统发现数据质量问题后，需要向源系统提供异常数据清单；5. 支持质量问题发现、分析、解决、确认的持续改进过程；6. 提供各个环节的监控和操作功能。3.3.2.6 规则库管理规则库是一系列规则的集合，每一个规则的制定都是为了完成一个特定的数据稽核/检查任务，通过执行规则可以找出数据质量存在的问题。规则根据需要而制定，既可以是技术规则，也可以是业务规则；既可以针对数据总量（总量级规则），也可以针对具体记录（记录级规则）。功能要求1. 支持在统一的模块中，能够实现多种业务规则、技术规则的配置；2. 支持规则的版本管理。3.3.2.7 数据修正考核数据问题是指数据记录个体的问

34、题，是由于历史原因、操作失误、或信息不全等导致的，如： 不正确数据：数据无效或错误，违反数据约束规则、业务规则等； 不完整数据：某些信息缺失或未填充，虽然不影响源系统正常运转，但这些信息的缺失会影响ODS的数据整合； 不一致数据：源系统彼此间信息存在冲突和差异，或者同一源系统内部的冗余信息之间存在冲突。数据问题需在源系统中对问题数据进行补录、修改，数据问题修正后就能得到改进，避免重复发生，可提升源系统的数据质量。ODS能够对源系统数据修正情况进行考核。功能要求1. 支持对不同源系统数据问题修正率的分析与展示。3.4 数据共享域数据共享域的功能是基于数据整合域所形成的统一数据视图，通过集中的数据

35、/服务提供功能，为各业务应用系统提供非自有数据的共享，优化目前各业务应用系统间网状的数据流转方式，简化数据共享逻辑，降低数据不一致的风险。数据共享域的功能包括共享配置管理、数据/服务提供和共享权限控制。3.4.1 共享配置管理共享配置管理对共享数据的内容和共享接口规则进行配置。功能要求1. 支持对使用共享数据的系统范围进行配置，定制对其他系统提供的接口数据的数据结构和语义描述；2. 支持对共享数据访问频率和访问允许时间段进行配置管理；3. 支持对数据直接提供、数据服务提供、界面集成等各种共享数据的发布方式的配置管理。3.4.2 数据/服务提供ODS系统能够通过数据文件、数据库物理共享、接口表、

36、视图、数据高级复制等技术手段向外部系统直接提供数据。功能要求1. 支持通过服务调用实现跨平台应用程序之间的应用到应用(A2A)集成。包括应用程序接口(APIs)、Java远端方法调用(RMI)、面向消息的中间件以及Web服务等多种技术手段；2. 要求提供数据服务定义、数据服务目录、服务参数定义的功能；3. 支持业务应用系统直接集成ODS系统的界面，以建立一些跨系统的综合应用。在界面构件的合理规划和设计下，通过界面集成可以提高开发部署效率、提高构件的重用性、有利于系统的健壮性和稳定性。3.4.3 共享权限控制作为企业运营数据的共享中心，ODS的数据具有一致性和完整性的特点，但是，不同的业务应用系

37、统所需访问的数据内容不同，这就要求根据共享数据的CRUD矩阵，控制各个业务应用系统对共享数据的访问权限。功能要求1. 支持共享域中提供的数据和数据服务的授权访问机制，支持对用户/角色权限的定制和对数据/数据服务的使用权限的限制；2. 支持访问的日志记录机制。3.5 数据应用域数据应用域通过基于ODS中整合好的运营数据，提供查询、固定报表、动态报表和批量计算等应用。3.5.1 数据查询数据查询是一种条件不固定、不可预见、格式灵活的动态查询功能，是按需查询，与预定义的常用查询相对。用户可以选择任意维度（一或多个）进行查询，它的使用人员无需了解数据库和SQL，只需通过系统提供的各种向导式界面和联机帮

38、助，按照业务逻辑规则即可快速、简洁的定义查询需求，系统自动完成连接操作、条件定义等SQL定义操作。功能要求1. 支持客户统一视图查询功能；2. 等。3.5.2 固定报表固定报表是基于指标型的报表，对于实时性要求高的报表采用即时生成的模式，而对于实时性要求不高的报表，基于性能影响和资源开销两方面的考虑，应采用后台通过作业的方式先自动生成，在需要时可以立即展现结果。报表展现应支持多种图表方式，如饼图、柱图、线图等；支持报表数据导出为其他文件类型，如EXCEL、CSV、XML、PDF、WEB存档文件等；支持报表精确打印控制。功能要求1. 支持客户品牌统计；2. 企业数据应用门户的部分报表；3. 支持

39、KPI考核固定报表。4. 等。3.5.3 计算应用ODS整合了来自各系统的数据，因此可以支撑跨系统的数据计算方面的业务要求。但是ODS不参与业务方面的功能提供，而是专注于数据方面的计算过程。 功能要求1. 支持客户评价的计算；2. 支持客户品牌的标签；3. 支持代理商等级计算；4. 支持代理商佣金计算；5. 等。3.5.4 动态报表基于ODS跨系统的数据，可以利用报表工具对数据进行各主题性的统计。功能要求1. 报表参数化的定制，针对报表主题可以进行指定条件的内容定制，使管理人员能根据自己的需要生成各种报表，提高应用支撑的灵活性；2. 支持市场计划类的统计与监控；3. 支持营销类活动统计；4.

40、支持商机类分析统计与监控；5. 支持订单统计与监控；6. 支持销售活动统计；7. 支持KPI考核与监控；8. 支持合作伙伴考评；9. 支持客户用户数、产品使用量、业务收入、欠费、竞争统计；10. 等。3.6 公共管理域公共管理域是属于系统公用的功能，作为其他功能模块的支撑。包括三块功能：1. 系统管理：系统管理是为保证ODS系统正常运行所需要的基本功能，主要包括系统用户管理、角色管理、权限管理、组织管理、备份与恢复、系统日志管理等方面。2. 系统监控：系统监控提供一种通用的机制与服务，监视组成系统各部件的运行状态，当发生异常时能够主动地向特定目标通知异常。3. 元数据管理：ODS元数据管理为用

41、户正确理解和操作数据提供支撑，它贯穿ODS系统构建、运行和维护的整个生命周期。3.6.1 系统管理ODS系统管理主要包括系统用户管理、权限管理、角色管理等，确保ODS系统能够安全有序地运行。3.6.1.1 系统用户管理用户是指授权访问ODS系统的使用者。用户管理用来记录用户相关信息，如账户、密码等。用户要拥有对某个主题的操作权限，必须通过角色去关联。1. 用户名称（ID）在全企业唯一，缺省为员工工号；2. 用户的初始密码由安全管理员设置，统一在系统管理的个人资料录入中完成；3. 安全管理员能够修改用户的密码，统一在系统管理的个人资料修改中完成；4. 各级管理员在本人权限范围内能够对用户进行增加

42、、删除、修改等操作；5. 各级管理员在本人权限范围内能够对用户密码进行修改；6. 用户缺省能够修改本人的密码；用户首次登录后，系统提示用户必须进行密码的修改；7. 对密码的要求： ；u 长度要求：6=密码长度=16；u 字符要求：数字、大小写字母、标点符号；u 复杂性要求：不能包含用户名（不区分大小写）；密码字符必须含有数字、大写字母、小写字母、标点符号四种中的三种字符；u 变更要求：新密码不得与最近使用的两个密码相同，密码更改的时限可由系统安全管理员设置（缺省：90天）；u 对密码的加密要求：应采用不可逆的加密算法，密码应以密文方式存入数据库；密码应以密文方式在网上传输。8. 可以对用户进行

43、查询统计。3.6.1.2 角色管理角色就是系统中的一组权限的集合。系统管理员定义系统中的角色、角色适用的部门类型、功能权限集，以方便管理人员对员工进行权限分配。系统中的每个具有合法使用权限的用户都会被分配一个或数个角色，它是使用权限的基本单位，拥有一定数量的权限，通过角色赋予用户权限。角色管理的基本操作：进行系统管理员身份认证后，授予用户相应的角色；修改用户的角色，相关的操作结果存入用户_角色表中；也可以增加角色，相关的操作结果存入角色表中。1. 创建角色：当用户所需的角色不在系统原有角色中时，可由系统管理员创建新的角色，以满足用户的需要；2. 授予用户角色：当用户建立好后，要给用户授予适当的

44、角色获取一定的权限；3. 修改用户角色：可以对用户的角色进行重新分配，即修改。角色具有以下主要属性：u 编号：在系统中唯一；u 名称：在系统中唯一；u 注释：描述角色信息。4. 可以删除角色；5. 可以根据角色进行查询统计。3.6.1.3 权限管理权限指访问ODS系统的用户根据角色获得对系统某些功能的操作，例如读、写、修改和删除等功能。授权管理的基本操作：进行系统管理员身份认证后，为角色分配相应的权限，修改角色的权限等操作，相关的操作结果存入角色_权限表中；并可以在模块对象发生变化后，创建对象权限，相关的操作结果存入权限表中。1. 能够创建对象权限：当增加系统对象时，应创建该对象的权限；2.

45、能够分配角色权限：给不同的角色分配相应的权限；3. 能够修改角色权限：根据需要，可以修改角色的权限；4. 权限设置必须由被授权的系统管理员完成，管理员不能设置大于自身权限的权限；权限管理采用分级的管理方式。上一级可以设置下一级的管理权限；5. 权限具有以下主要属性：u 编号，在系统中唯一；u 名称，在系统中唯一；u 注释，描述权限信息。6. 权限、角色、用户之间具有如下关系：1）用户与角色的多对多关系一个用户可以隶属于多个角色，一个角色组也可拥有多个用户，用户角色就是用来描述它们之间隶属关系的对象。用户通过角色关联所拥有对某种资源的权限。2）权限与角色的多对多关系权限是一个二元组关系，包括对象

46、和对对象的操作。对象包括用户操作的系统模块和数据对象，通过权限与角色的关系来设定角色操作对象的权限。一个角色可以拥有多个权限，同样一个权限可分配给多个角色。3.6.1.4 组织管理组织机构包括省、市、县（区）各级各类部门、班、组等。组织管理完成对其按组织结构进行统一编码和维护。1. 系统按照组织结构对省、市、县（区）各级各类部门、班、组等进行统一编码，按人员的组织结构从上往下进行管理，具体编码方式和位长可根据实际情况进行编排；2. 具有相应权限的用户可对省、市、县（区）各级各类部门、班、组等进行编码并进行增加、修改、删除等操作，并对上下级关系等进行增加、修改、删除；3. 系统支持组织机构的树状层次管理，一个组织机构可以有多个子节点；4. 可以对编码和组织结构进行查询统计。3.