专利名称：多业务驱动共享框架模型设计方法
技术领域：
本发明属于电信行业的数据仓库领域，具体是一种主要服务对象为中国移动、中
国联通和中国电信等电信营运商的多业务驱动共享框架模型设计方法。
背景技术：
电信运营商的经营分析系统是以市场经营分析、决策支持以及一线营销服务支撑 为建设目的，以数据仓库为基础数据平台的企业级综合应用系统。数据仓库在整合电信运 营商相关业务源数据系统的基础上，为专业数据集市及分析统计、数据挖掘等应用提供基 础的数据支持，因此数据仓库是经营分析系统的基础。多业务驱动共享框架模型设计方法 以《中国移动省级NG1-BASS技术规范逻辑模型分册》为设计基础。目前的数据仓库都是以 接口层-存储层-中间层-结果层(也叫实施表层)为基准的架构。 数据仓库和数据集市建设的成功与否在很大程度上取决于是否有一个稳固、全面 和灵活的逻辑数据模型。逻辑数据模型是集成各种数据源系统的数据视图，是支撑各种分 析应用的基础，也是表达和沟通业务及其规则的媒介。逻辑数据模型设计是经营分析系统 数据仓库和数据集市建设中的重要一环，它不仅直接反映出业务部门的需求，同时对系统 实施有着重要的指导和规划作用。为了促进、指导和规范各省经营分析系统数据仓库及数 据集市的建设，加强经营分析系统的数据管理，构建统一的经营分析系统数据平台。
目前的模型存储层数据结构等同于原BOSS系统，中间层以用户资料规整和清单 资料汇总为主，其核心的几张中间表就是tp_CSt_uSrarCh_m0n， act表、神州行模拟出账和 欠费中间表等最基本的中间表。数据仓库只有存储层和中间层两层，70%以上的应用必须 关联存储层，这样导致在存储层(也就是说数据源)进行大的版本升级的时候，几乎所有的 应用都需要重新开发；同时，模型的设计和改进工作，只能散落在各个现场，现场的模型以 及数据流的水准完全决定于现场技术经理的水平，模型的稳定性不够。
发明内容
(l)发明目的 本发明目的基于同一运营商的不同厂商的生产系统，在后台快速和方便的搭建 数据仓库以及应用，解决各个省由于支撑系统和源数据的不同，而造成的系统后端整合的 代价问题。
(2)技术方案 本发明的技术方案多业务驱动共享框架模型设计方法，增加业务中心层的概念， 把业务口径和统计口径固化，多业务驱动共享框架模型是由结果层、业务中心层、基础中间 层和数据存储层组成，参见附图1。 数据存储层由生产系统以ETL的方式传递过来的接口，可以是文件接口或者是 消息接口。系统通过ETL的模式装载入数据仓库。数据存储层是数据仓库的基础，按照业 务要求的周期存放清单，营账等基础数据。
基础中间层对数据存储层做资料规整和汇总。过滤掉分析不需要的字段。该项 目在完成中间表逻辑模型和物理模型的设计的同时，标识出中间表的建议索引，标明每个 中间表的意图和功能，指明每个中间表的数据量级(以X倍用户数这样的指标体现)。基础 中间层是数据仓库数据清洗和整合的过程，是业务中间区的基础
具体来说 —种多业务驱动共享框架模型设计方法，是在接口层_存储层_中间层_结果层 的模型中，用业务中心层取代其中的中间层； 所述业务中心层的设计方法是业务紧耦合，数据松耦合； 所述业务紧耦合是指业务中心区的设计以客户的业务出发，建立包括客户行为 类，增值业务类，数据业务类，集团客户类和专题分析类的类； 所谓数据松耦合，就是把中心区和底层数据区隔开，在业务中心区中增加业务标 签和统计标签。 所述数据存储层，是由生产系统以ETL的方式传递过来的接口，生产系统通过ETL 的模式装载入数据仓库。 所述接口包括文件接口或消息接口。 是所述基础中间层，是对数据存储层做资料规整和汇总，过滤掉分析不需要的字 段。 在所述基础中间层设计中，在完成中间表逻辑模型和物理模型的设计同时，标识 出中间表的建议索引，标明每个中间表的意图和功能，指明每个中间表的数据量级，该数量 级是以X倍用户数这样的指标体现。 所述结果层保存的是事实表，存储的最终的报表和主题数据。 业务中心层是整个模型设计的创新点，其核心思想就是业务紧耦合，数据松耦合。 业务紧耦合的意思是业务中心区的设计以客户的业务出发，细分为客户行为类，增值业务 类，数据业务类，集团客户类，专题分析类等。所谓数据松耦合，就是把中心区和底层数据区 隔开，在业务中心区中增加业务标签和统计标签。这样的设计模式和方法的的目的在于能 够把底层数据不同，需求不同但业务相似的同一运营商的中间模型在业务中心区统一，最 终能够达到业务功能的快速部署的目的。 结果层保存的是事实表，存储的最终的报表和主题数据。事实表是数据仓库模型
的最终结果，报表和主题数据的保存周期按照业务部门的需求而定。
(3)有益效果 1支撑源数据不同的不同省份的同一运营商的相似应用 2能够快速的搭建数据仓库和应用 3能够做到统一开发，减少人力成本的投入 4 口径固化，减少开发人员出错的几率 5源系统的大规模升级，对数据仓库的影响弱化
图1.多业务驱动共享框架模型设计方法的模型架构
图2.按照本方法设计的业务框架模型
具体实施例方式
下面结合附图和实施例对本发明进一步说明。 多业务驱动共享框架模型设计方法，增加业务中心层的概念，把业务口径和统计 口径固化，多业务驱动共享框架模型是由结果层、业务中心层、基础中间层和数据存储层组 成，参见附图1。 数据存储层由生产系统以ETL的方式传递过来的接口，可以是文件接口或者是 消息接口。系统通过ETL的模式装载入数据仓库。数据存储层是数据仓库的基础，按照业 务要求的周期存放清单，营账等基础数据。 基础中间层对数据存储层做资料规整和汇总。过滤掉分析不需要的字段。该项 目在完成中间表逻辑模型和物理模型的设计的同时，标识出中间表的建议索引，标明每个 中间表的意图和功能，指明每个中间表的数据量级(以X倍用户数这样的指标体现)。基础 中间层是数据仓库数据清洗和整合的过程，是业务中间区的基础 业务中心层是整个模型设计的创新点，其核心思想就是业务紧耦合，数据松耦合。 业务紧耦合的意思是业务中心区的设计以客户的业务出发，细分为客户行为类，增值业务 类，数据业务类，集团客户类，专题分析类等。所谓数据松耦合，就是把中心区和底层数据区 隔开，在业务中心区中增加业务标签和统计标签。这样的设计模式和方法的的目的在于能 够把底层数据不同，需求不同但业务相似的同一运营商的中间模型在业务中心区统一，最 终能够达到业务功能的快速部署的目的。
结果层保存的是事实表，存储的最终的报表和主题数据。事实表是数据仓库模型
的最终结果，报表和主题数据的保存周期按照业务部门的需求而定。 本例的建设方法 步骤1)通过对通信运营商市场，集团，数据等业务部门的大规模的调研，确定关 键业务，并为每个大类下面的子业务设计开发业务视图。按照运营商的KPI指标，财务指 标，运营指标分业务分拣指标，并且划分到各个业务视图中。业务视图共包含客户行为类， 增值业务类，数据业务类，集团客户类，专题分析类等。 步骤2)通过对各个业务视图的评估，细化到用户级的中间表，原则上单个子业务 需要设计3种模型，日统计模型，周统计模型和月统计模型。把用户数这样的指标拆分成业 务标签，同时把业务量和收入类的指标拆分成统计指标。业务视图务必要做到统计口径的 标签化，从而分离数据和业务。图2就是一个典型的按照框架模型设计方法设计出来的中 心区模型。 步骤3)保存设计过程，并设计评审，实现基础中间层向业务中心区的代码，最终 业务中心区定型，提交报告。并提供模型培训，共享资料和文档，提升现场员工的对多业务 驱动共享框架模型设计方法的认知度和模型设计能力。以目前经营分析系统的指标和KPI 为基准客户需求建设业务中心区。要求做到数据流和模型的高相似度，并统一业务中心区。 在年中新的规范下发之后，模型小组就应该根据规范的要求，适时的修订自己的模型，增加 业务中心区的内容，修订数据流，同时，建议对规范中定义的复杂算法加以研究。
权利要求
一种多业务驱动共享框架模型设计方法，其特征是在接口层-存储层-中间层-结果层的模型中，用业务中心层取代其中的中间层；所述业务中心层的设计方法是业务紧耦合，数据松耦合；所述业务紧耦合是指业务中心区的设计以客户的业务出发，建立包括客户行为类，增值业务类，数据业务类，集团客户类和专题分析类的类；所谓数据松耦合，就是把中心区和底层数据区隔开，在业务中心区中增加业务标签和统计标签。
2. 根据权利要求1所述的多业务驱动共享框架模型设计方法，其特征是所述数据存储 层，是由生产系统以ETL的方式传递过来的接口 ，生产系统通过ETL的模式装载入数据仓库。
3. 根据权利要求2所述的多业务驱动共享框架模型设计方法，其特征是所述接口包括 文件接口或消息接口。
4. 根据权利要求1所述的多业务驱动共享框架模型设计方法，其特征是所述基础中间 层，是对数据存储层做资料规整和汇总，过滤掉分析不需要的字段。
5. 根据权利要求4所述的多业务驱动共享框架模型设计方法，其特征是在所述基础中 间层设计中，在完成中间表逻辑模型和物理模型的设计同时，标识出中间表的建议索引，标 明每个中间表的意图和功能，指明每个中间表的数据量级，该数量级是以X倍用户数这样 的指标体现。
6. 根据权利要求1所述的多业务驱动共享框架模型设计方法，其特征是所述结果层保 存的是事实表，存储的最终的报表和主题数据。
全文摘要
一种多业务驱动共享框架模型设计方法，采用业务紧耦合，数据松耦合的设计理念，重新设计运营商的数据仓库系统，把以前的数据存储层组成，中间层，结果层传统的三层设计架构解构。设计为是由结果层、业务中间层、基础中间层、数据存储层四层架构。其带在通信运营商数据仓库系统部署过程中的益处为支撑源数据不同的不同省份的同一运营商的相似应用；能够快速的搭建数据仓库和应用；能够做到统一开发，减少人力成本的投入；口径固化，减少开发人员出错的几率；源系统的大规模升级，对数据仓库的影响弱化。
文档编号H04W4/24GK101702798SQ20091021245
公开日2010年5月5日 申请日期2009年11月11日 优先权日2009年11月11日
发明者刘莺莺, 刘蕾, 夏宗阳, 孙力斌, 曹晓华, 李捷, 赵懿敏, 陈翔 申请人:南京联创科技集团股份有限公司