数据仓库建模技术

数据仓库系统是一个与企业同步发展的有机体,数据模型作为数据仓库的灵魂必须提供可扩展的能力,在进行数据模型设计时必须考虑未来的发展,更多的非核心业务数据可以方便的加入到数据仓库,而不需要对数据仓库中原有的系统进行大规模的修改。

一、数据仓库建模的原则
  模型是对现实事物的反映和抽象,它可以帮助我们更加清晰的了解客观世界。数据仓库建模在业务需求分析之后开始,是数据仓库构造工作正式开始的第一步,正确而完备的数据模型是用户业务需求的体现,是数据仓库项目成功与否最重要的技术因素。

金融企业的信息系统具有业务复杂、机构复杂、系统庞大的特点,因此金融行业数据仓库建模必须注意以下几个方面,
  —— 满足不同用户的需求
  金融行业的业务流程十分复杂,数据仓库系统涉及的业务用户众多,在进行数据模型设计的时候必须兼顾不同业务产品、不同业务部门、不同层次、不同级别用户的信息需求。
  数据仓库应该支持企业的各种业务,比如对财产保险行业应该考虑财产险、货物运输险、工程险、责任险等不同业务的特点;不同的业务部门对信息的需求各有不同,应考虑业务、市场、财务、管理等各个部门的需要;不同层次的组织所关心的信息不同,数据模型应支持地市公司、省公司和总公司的信息需求;金融企业是知识密集型的企业,知识密集型企业的显著特征是智能员工(Knowledge Worker)占企业员工的大多数,数据仓库必须支持所有相关智能型员工的信息需求,包括高层领导、基层领导和普通员工。
  —— 兼顾效率与数据粒度的需要
  数据粒度和查询效率从来都是矛盾的,细小的数据粒度可以保证信息访问的灵活性,但同时却降低了查询的效率并占用大量的存储空间,数据模型的设计必须在这矛盾的两者中取得平衡,优秀的数据模型设计既可以提供足够详细的数据支持又能够保证查询的效率。
  —— 支持需求的变化
  用户的信息需求随着市场的变化而变化,所以需求的变化只有在市场竞争停顿的时候才会停止,而且随着竞争的激化,需求变化会越来越频繁。数据模型的设计必须考虑如何适应和满足需求的变化。
  —— 避免对业务运营系统造成影响
  金融企业的数据仓库系统是一个每天都在长大的庞然大物,它的运行很容易占用很多的资源,比如网络资源、系统资源,在进行数据模型设计的时候也需要考虑如何减少对业务系统性能的影响。
  —— 考虑未来的可扩展性
  数据仓库系统是一个与企业同步发展的有机体,数据模型作为数据仓库的灵魂必须提供可扩展的能力,在进行数据模型设计时必须考虑未来的发展,更多的非核心业务数据如人事数据、市场数据、竞争对手数据等必须可以方便的加入到数据仓库,而不需要对数据仓库中原有的系统进行大规模的修改。

  二、数据模型的技术功能结构化分
  大规模的数据仓库系统特别是金融行业数据仓库的数据结构从技术角度划分应当包含三个部分,如下图所示,
  数据仓库建模技术(1)
  数据仓库数据模型的技术功能划分
  2.1 分段存储区(Staging Area)
  由于数据仓库中的数据结构和组织方式具有很大差异、所有原始业务系统的数据必须经过严格的抽取、映射和转换,数据的整合过程十分复杂,通常会耗费比较长的处理时间。如果从业务系统直接抽取数据到数据仓库,必定会占用许多业务系统的资源和时间,为了避免影响业务系统的运行,我们在数据模型的设计中引入分段存储区的概念。
  分段存储区(Staging Area)是为了保证数据移动的顺利进行而开设的阶段性数据存储空间,它是业务系统原始数据进入数据仓库前的缓存区。需要进入数据仓库的各个业务系统的数据首先直接快速传输到分段存储区,再从分段存储区经过清洗、转换、映射等复杂的数据移动处理转移到目标数据仓库中。从业务系统到分段存储区的数据传输,应尽量避免进行复杂的数据处理,以保证数据的快速导入而尽量减小对业务系统造成的压力。分段存储区的数据有关系数据库和文件两种不同存储方式,分别对应于不同运营系统的数据源。数据成功导入数据仓库之后,应清空分段存储区中的数据。
  在数据仓库系统的运行和使用过程中,分段存储区的作用主要体现在以下几个方面,
  • 可以减少对业务系统资源的占用,避免复杂数据转换对业务系统的影响
  • 根据经验,跨越网络特别是广域网络的数据库操作会大大降低数据处理的效率,而且处理的复杂程度越高,网络对处理效率的影响越严重,分段存储区可以大大加速数据仓库后台数据数据处理过程的实现;
  • 分段存储区作为数据缓存区,可以在一定程度上屏蔽业务系统变化对数据移动整合系统的影响
  • 如果在数据处理过程中发生系统故障,作为数据仓库系统的备份数据,可以直接从分段存储区进行数据仓库数据恢复,而不必要再从业务系统原始数据开始。
  2.2 基础数据仓库(BaseLine)
  基础数据仓库存储所有最详细的业务数据。该层数据直接来源于对分段存储区数据的清洗和加工,属于未经汇总的数据,但数据的组织方式可能已经完全不同于原始的业务系统。根据业务需求的不同,基础数据仓库的组织形式以三范式模型为主,在有的系统中也可能采用星型或雪花模型。
  通常在金融企业的数据仓库系统中,基础数据仓库数据包括未经汇总的客户交易数据,用户资料数据、客户服务数据等,此外一些相关数据如网络利用,竞争对手,成本投资数据也包括在内。由于基础数据仓库数据是对原始业务数据的原形再现,所以数据量会非常庞大,根据不同业务的需要数据保留的时间在6个月到两年不等。
  2.3 数据集市(Data Mart)
  根据业务需求将数据仓库数据分类成几个不同的数据集市,每个数据集市完成不同的分析和查询需求数据集市中的数据通常由基础数据仓库的详细数据聚合而来根据数据聚合程度的不同包含轻度聚合、中度聚合和高度聚合三种不同的层次。汇总的方式将依据数据量的大小和使用频度综合考虑。

三、概念模型
  数据模型设计的第一步是对用户需求的归纳,需要综合考虑业务划分和用户组织两方面的问题,在明确需求的基础上,可以进行逻辑数据模型的设计,大致需要经过分为三个步骤,高层模型设计即概念模型设计,确定数据仓库的主要主题及相互关系;中层模型设计明确各主题域的实体;底层模型设计明确各个实体的属性。本章以国内某财产保险公司的业务为例介绍财产保险行业的数据仓库建模。
  3.1 财产保险业务与公司组织机构
  下图是国内财产保险公司的主要组织机构,
   数据仓库建模技术(2)(图一)

国内财产保险经营的主要保险业务如下,
  • 机动车辆保险
  • 家庭财产保险
  • 企业财产保险
  • 建筑安装工程保险
  • 货物运输保险
  • 船舶保险
  • 航空航天保险
  • 其它保险
  3.2 数据仓库概念模型
  目前保费收入还是国内财产保险企业的主要利润来源,在激烈的市场竞争中客户是竞争的焦点,在数据仓库中客户信息占有极为重要的地位;围绕着客户资料信息,客户的投保记录、索赔记录都具有极高的分析价值;另外合作伙伴对保险业务的开拓也具有重要地位,如保险代理人、经纪人等中介公司的相关信息。
  3.2.1 基础数据仓库
  基础数据仓库用以存储详细的业务数据,采取以客户信息为中心,各个业务环节数据为基础的中心-发散型结构,系统面向经营分析,以经营业务数据为主,如下图所示,
   数据仓库建模技术(2)(图二)
  3.2.1.1 基础数据仓库概念模型介绍
  —— 客户资料
  负责存储用户的详细资料,主要的客户属性包括,客户ID、用户第一次投保时间、资料更新时间、业务类型、用户特征属性、用户类型、缴费情况、投保情况、信用情况、保费收入水平等等。客户资料主题的数据主要针对企业用户和大客户,在可能的情况下,尽量体现客户间的关系,比如某一家庭财险用户隶属于某一企业客户。客户资料数据体现最新的客户状态。客户资料永久在线保存,当客户资料发生变化时,旧的客户信息被转移到客户历史资料库中。在每一个客户的生命周期中,客户资料随时可能发生变化,客户历史资料数据详尽的记录每一次变化的细节,为以后客户信用评估和用户行为分析需求提供依据,客户历史资料永久在线保存。
  —— 客户投保记录
  以详细的保单数据为主,体现在某一时间段内客户的投保情况。由于数据量比较庞大,客户投保记录一般在数据仓库中在线保存两年,最长不超过五年。投保记录是业务分析最重要的数据基础,必要的时候,投保记录可以为很多业务提供数据支持,比如大客户管理等。
  —— 客户缴费记录
  记录用户投保后保费的缴纳情况,从中可以了解保险公司与每一个客户在不同业务的应收情况。是对业务发展的重要衡量依据,也是对客户群进行细分的重要指标。不同保险企业对缴费记录在线保存的时限要求不同,一般在一年以上,五年以下。
  —— 客户索赔记录
  客户索赔记录是过去客户每次索赔的详细记录,比如索赔金额、时间、保单号、立案号、险种、索赔清单、索赔单证、事故描述等,索赔记录是客户行为模式的重要组成,也是反欺诈分析、客户流失分析的重要依据。
  —— 客户赔付记录
  记录保险公司对每一个客户的每一笔赔付,主要的信息包括赔付时间、立案号、赔案号、单证、赔付计算情况、损失原因、赔付金额、是否通融赔付、通融赔付的原因和通融赔付金额等,与索赔记录相结合,可以了解保险公司对客户索赔的反应时间和处理速度
  —— 客户退保/退费记录
  了解用户退保和退费的情况,每一笔退保/退费的原因、时间、保单号、金额等等
  —— 中介信息
  描述中介公司的类型,比如经纪人、兼职代理人或专业代理人,各中介公司的业务量、保险公司之处的中介费用等等。
  3.2.1.2 基础数据仓库概念模型的实现
  概念模型的意义在于体现用户的需求和基本的数据组织结构,在实际的设计过程中,可能需要根据实际的业务情况进行模型的拆分。比如客户资料模型,针对不同客户的情况拆分成企业客户、个人客户、集团个人客户;投保记录模型,根据不同的业务拆分成车险投保记录、财产险投保记录、运输险投保记录、船舶险投保记录等,
   数据仓库建模技术(2)(图三)
  根据不同业务情况设计业务主题
  3.2.2 数据集市
  详细业务数据是数据仓库的基础,但对于金融企业来说,对业务发展宏观情况的把握是比详细的客户分析更为迫切的需求。所以在初期任何金融行业数据仓库的应用都以对聚合数据的分析为主。聚合数据存储在数据集市中,数据集市的数据直接通过查询工具提供给最终用户,所以数据集市的设计直接关系到数据仓库应用的成败。现阶段,我国大多数金融数据仓库系统正处于初始阶段,其主要功能需求是了解各省分公司、子公司和各项业务的发展和运营情况,因此数据集市的设计是数据模型设计最重要的环节。数据集市的数据结构可以按照数据粒度和数据所体现的业务范围划分。
  3.2.2.1 按照数据粒度划分
  数据集市按照数据粒度的大小可以划分为三个部分,轻度汇总、中度汇总、高度汇总,汇总程度越高,数据粒度越大,数据在线保留时间越长,所体现的业务事实越宏观,如下图所示,
   数据仓库建模技术(2)(图四)
  按照数据粒度划分的数据集市结构
  轻度汇总数据可以支持很多对客户个体的业务分析,比如从基础数据仓库投保记录汇总生成每个用户一段时间的投保情况;中度汇总数据在业务分析中经常被用到,大多数情况用于对宏观客户群体的业务分析,比如制定保费政策时,可以通过中度汇总数据了解不同险种不同时间的发展和收益情况;高度汇总数据用于了解保险公司业务整体的运营和发展情况。在实际的设计中,可以根据用户需求决定针对不同的业务采用不同的数据粒度。
  3.2.2.2 按照业务划分
  按照业务进行数据集市结构的划分,可以把数据集市从总体上分为两个模块,综合业务分析模块和独立业务分析模块,如下图,
   数据仓库建模技术(2)(图五)
  按照业务划分的数据集市结构
  —— 综合业务分析
  综合业务分析主要面向保险公司整体业务的分析,从综合业务分析可以了解保险公司的用户构成情况、中介发展情况、业务收入情况、赔付情况、共保/分保、客户服务、保费收入情况和竞争对手发展情况,从综合业务模块可以了解各个业务的总体发展情况,但由于各个业务属性的差异,详细的业务分析必须进入独立业务分析模块。
  —— 独立业务分析
  财产保险各业务、各险种的业务特点具有极大差异,对不同险种业务人员所关心的信息也不尽相同,所以各个业务在独立业务分析模块构成不同的分析主题;除此之外对有共性的业务进行综合构成综合的业务分析主题,比如个人大客户分析、企业客户业务分析就是把相关的业务主题进行综合的结果。

四、发展与扩充
  数据仓库数据模型的设计在满足目前业务需求的基础上,必须考虑未来的业务情况和需求,需要认真考虑两方面的问题,
  • 适应未来业务需求和技术环境的改变
  • 数据仓库本身涉及业务范围的扩展
  4.1 适应未来的变化
  分段式数据仓库结构可以大大提升数据仓库适应变化的能力。在未来可能对数据仓库产生影响的变化无外乎两种,
  • 业务需求的变化引致对信息需求的变化
  • 技术环境的变化
  4.1.1 适应业务需求的变化
  用户需求的变化根据变化的程度和对数据仓库系统的影响被分为两个不同的层次,
  —— 可自适应的变化
  即信息的需求虽然有所变化,但利用已经存储在数据集市中的数据仍然可以支持,需要改变的只是数据访问和信息展现的方式,这不需要对数据仓库的数据结构进行修改就可以实现,在进行数据模型设计时,在保证查询效率的前提下,要尽量使各个业务主题可以满足最多的信息需求。
  —— 需要调整的变化
  即数据集市的数据虽然无法满足信息的需求,但可以从基础数据仓库中的数据获得,针对这样的变化有两种处理方法,
  • 如果这个变化只是偶尔出现,可以直接从基础数据仓库的数据中进行数据的查询和分析,这样可能会牺牲一些性能,但不需对数据仓库的结构和数据模型进行修改
  • 另一种方法是针对以后将频繁使用的新业务需求,可以采取修改现行数据集市和建立新的数据集市的方法实现,由于数据集市只是对基础数据仓库中相关的详细数据进行聚合,所以只需要很小的工作量就可以调整数据仓库实现新的需求。
  4.1.2 适应技术环境的变化
  技术环境的变化也是比较普遍出现的变化,比如业务系统的升级或迁移,可能对数据仓库的结构造成较大影响,分段存储区和基础数据仓库的使用,把这种风险降到最小。
  分段存储区是业务数据进入数据仓库之前的缓存区,复杂的数据转换、清洗工作在分段存储区进入基础数据仓库时实现。当业务系统的数据结构发生变化时,可以利用从业务系统到分段存储区的数据抽取操作把这些变化与数据清洗转换操作隔离即在对新的业务系统进行数据抽取操作时,进行适当的数据结构转换,使分段存储区中的数据与原来保持一致,避免对数据仓库的数据结构和主要的后台处理程序造成影响。从业务系统到分段存储区的数据抽取程序只需十分简单的修改就可以实现需要的功能。
  4.1.3 元数据管理的意义
  元数据管理系统可以大大提高数据仓库系统适应变化的能力。元数据记录数据仓库过程中设计的业务规则、数据结构、数据移动规则等,一旦上述某一点发生变化,可以通过元数据管理工具,进行影响分析,定位需要修改的目的。

原文地址:https://www.cnblogs.com/HondaHsu/p/1178512.html