工程实践结题报告寿险行业数据平台项目设计与实现13版.docx

上传人:b****1 文档编号:2575919 上传时间:2023-05-04 格式:DOCX 页数:44 大小:1.46MB
下载 相关 举报
工程实践结题报告寿险行业数据平台项目设计与实现13版.docx_第1页
第1页 / 共44页
工程实践结题报告寿险行业数据平台项目设计与实现13版.docx_第2页
第2页 / 共44页
工程实践结题报告寿险行业数据平台项目设计与实现13版.docx_第3页
第3页 / 共44页
工程实践结题报告寿险行业数据平台项目设计与实现13版.docx_第4页
第4页 / 共44页
工程实践结题报告寿险行业数据平台项目设计与实现13版.docx_第5页
第5页 / 共44页
工程实践结题报告寿险行业数据平台项目设计与实现13版.docx_第6页
第6页 / 共44页
工程实践结题报告寿险行业数据平台项目设计与实现13版.docx_第7页
第7页 / 共44页
工程实践结题报告寿险行业数据平台项目设计与实现13版.docx_第8页
第8页 / 共44页
工程实践结题报告寿险行业数据平台项目设计与实现13版.docx_第9页
第9页 / 共44页
工程实践结题报告寿险行业数据平台项目设计与实现13版.docx_第10页
第10页 / 共44页
工程实践结题报告寿险行业数据平台项目设计与实现13版.docx_第11页
第11页 / 共44页
工程实践结题报告寿险行业数据平台项目设计与实现13版.docx_第12页
第12页 / 共44页
工程实践结题报告寿险行业数据平台项目设计与实现13版.docx_第13页
第13页 / 共44页
工程实践结题报告寿险行业数据平台项目设计与实现13版.docx_第14页
第14页 / 共44页
工程实践结题报告寿险行业数据平台项目设计与实现13版.docx_第15页
第15页 / 共44页
工程实践结题报告寿险行业数据平台项目设计与实现13版.docx_第16页
第16页 / 共44页
工程实践结题报告寿险行业数据平台项目设计与实现13版.docx_第17页
第17页 / 共44页
工程实践结题报告寿险行业数据平台项目设计与实现13版.docx_第18页
第18页 / 共44页
工程实践结题报告寿险行业数据平台项目设计与实现13版.docx_第19页
第19页 / 共44页
工程实践结题报告寿险行业数据平台项目设计与实现13版.docx_第20页
第20页 / 共44页
亲,该文档总共44页,到这儿已超出免费预览范围,如果喜欢就下载吧!
下载资源
资源描述

工程实践结题报告寿险行业数据平台项目设计与实现13版.docx

《工程实践结题报告寿险行业数据平台项目设计与实现13版.docx》由会员分享,可在线阅读,更多相关《工程实践结题报告寿险行业数据平台项目设计与实现13版.docx(44页珍藏版)》请在冰点文库上搜索。

工程实践结题报告寿险行业数据平台项目设计与实现13版.docx

工程实践结题报告寿险行业数据平台项目设计与实现13版

北京航空航天大学软件学院

 

工程实践结题报告

 

课题名称:

寿险行业数据平台项目设计与实现

姓名:

姚仁毅、刘换玲、陆俊、曲坤、张慧

组别:

9

学号:

GS1021A31、GS1021A89、GS1021A28、

GS1021A51、GS1021A46

专业方向:

IT项目管理与产业信息化

所属院系:

北京航空航天大学软件学院

指导老师:

宋友

实践起止时间:

年月至年月

摘要

随着保险公司业务的快速发展和业务领域的拓展,数据分析和基于数据精细化管理决策的需求日渐紧迫。

目前保险的企业数据是分散在各个信息系统中,缺乏统一的数据模型和面向主题的分析结构,造成数据分析提取周期长、分析不灵活,信息不统一的问题,存在紧迫的数据分析需求和较弱的数据基础环境之间的矛盾,通过数据仓库技术能够统一企业数据模型、统一数据标准,整合核心业务、客服、财务等系统中数据,构建企业级数据仓库,支持企业级的信息分析、提高企业的决策水平。

关键词:

人寿保险,保险模型,数据仓库

表目录

图目录

第一章绪论

一.1.课题背景

过去二十多年,是信息化技术高速发展的时代。

信息化技术已经彻底地改变了金融机构的传统经营和管理模式。

可以这样说,决定金融机构业竞争胜负的主要因素已经不是高楼大厦、资金规模和机构网点,而是金融机构职员的高素质、知识化和信息化,未来的金融机构既不是劳动密集型产业,也不是资金密集型产业,而是知识加信息密集型产业。

所以说,国际先进金融机构的核心竞争力是现代金融管理和现代科学技术(尤其是信息技术)的结合。

但是,金融管理人员和信息技术人员在如何利用信息化技术提高金融机构经营和管理水平上存在着巨大的认知差异。

一般来说,金融管理人员对现代信息技术的了解程度不足以将信息化对提高金融机构管理水平产生的巨大效果发挥到最大;而信息技术人员对现代金融机构的管理和生产的了解是有限的。

其结果是,金融机构花费了许多不必要的投资进行了不能够满足金融机构管理人员需要的信息化建设,系统使用起来也比较复杂。

自1980年代以来,以美国华尔街为代表的西方金融机构(包括商业保险公司、保险公司和证券公司)进入了放松管制阶段,出现了残酷的竞争。

为了提高核心竞争力,美国金融机构吸引了大量来自全世界的各方面优秀人才,对美国金融业进行了延续至今的全面改革。

这些人才把金融管理的各个步骤尽可能细化,把金融管理理论、统计分析技术、数据管理技术、计算机技术等结合起来,发展了以客户为中心的各种精细化管理策略,广泛地建立了科学决策系统,全面进行智能化加自动化管理和生产。

一.2.问题分析

目前,国内寿险业发展趋势特点表现为:

1.寿险业依然持续快速增长,但整体规模与国民经济的发展对比仍然较小,发展水平还较低,保险密度和深度依然较小。

2.市场进一步开放,新公司不断增加,使竞争更加激烈。

3.保险集团公司逐步不断的增加,以及银行进入保险营销,使得金融混业经营局面已经逐步形成。

4.加入WTO以后,经济全球化的影响和新观念的引入,现代企业制度在中国的保险公司初步建立,保险监管体系不断健全。

保险业的改革进入了攻坚阶段。

体制创新任务艰巨,下一步的改革会触及更深层次的矛盾和问题。

5.产品体系逐步健全,新的业务增长点不断涌现。

但产品同质化程度仍然较高,导致公司之间过度的价格竞争。

6.我国寿险监管体系建设取得长足进步。

保险公司偿付能力不足的情况有了根本的改观。

但随着市场主体增加,业务范围扩大,以及资金运用渠道增加,保险业面临许多新的风险因素,防范风险的任务仍然十分艰巨。

经营管理跟不上业务的发展,现有的技术手段没办法准确评估业务的质量,特别是对于长期性的业务,以及过去“高息保单”利差损所留下的问题,都容易导致公司积累了巨大的财务风险。

而在业务发展中暴露出一些新的风险,比如当前宏观经济政策和货币市场、资本市场的变化都对保险资金运用产生了直接影响,都需要引起高度重视。

营销观念需要更新,服务质量极待提高。

由于缺乏规范的指引和管理,销售过程中的误导问题仍然存在;理赔环节不规范、不透明,拖赔和无理拒赔的现象时有发生,至使不少公司出现信誉危机。

产品的研发跟不上市场发展的需求,产品结构不尽合理。

自主创新能力不强,个性化的产品供给不足,而一般性产品供给过剩。

“想卖的卖不出去,想买的又买不着。

风险问题仍然突出。

化解过去“高息保单”利差损的任务仍然很重;个别保险公司偿付能力不足的问题需要尽快解决;业务发展中暴露出一些新的风险,比如当前宏观经济政策和货币市场、资本市场的变化都对保险资金运用产生了直接影响,需要引起高度重视。

因此,需要适时建设数据仓库系统。

其主要功能是帮助寿险公司及时、准确、全面和有针对性地为各层管理者和客户经理提供用于管理和生产的各种决策信息。

第二章

需求分析

二.1.需求总体描述

随着业务不断发展,业务系统和应用系统逐渐丰富,不仅包括渠道数据,还包括各险种的数据以及财务、客户、业务、资产数据等;虽然各业务部门为了日常运营需要基本上有各自的报表系统来支持,但依然面临各种问题。

主要面临的问题是:

1、全公司没有针对经营分析设定统一指标要求,没有标准化的定义,因此,各部门提供的运营报表数据很难从为公司经营决策提供有效的指导;

2、公司的经营决策分析指标,有些涉及到跨部门、跨系统的支持,在没有统一平台、数据没有按照统一口径获取情况下,造成某些经营决策分析指标的缺失

3、公司的经营业绩每天都会发生变化,迅速而又准确的提供这些指标数据,对于业务分散、系统各自独立来说,都是很困难的事情。

通过对寿险数据仓库系统平台建设需求的深刻理解,将从多角度、多步骤量身定做一套完整的、循序渐进的数据仓库解决方案,并且该方案建立在公司资源最大化利用的前提下,而且也广泛吸纳、整合了国内外先进的数据仓库建设经验,最终建立一个统一的数据仓库平台。

二.2.功能性需求

二.2.1.建立统一的指标体系

经营管理指标是寿险公司用以评估日常经营情况的重要依据。

由于岗位职能、业务目标的不同,使得公司范围内各层次用户分析、管理角度存在差异,例如,对于同样反映业务增长的数量指标,业务管理人员习惯从单证件数上来观察,而精算人员习惯上从责任数量上来观察,这种差异直接导致了“签单数量”与“签单承保数量”的分化。

类似情况的积累,通常会在公司范围内产生大量的歧义指标和不一致的统计标准。

数据仓库的建立客观上需要跨越各部门的纵向划分,制定全公司统一的经营管理指标体系。

二.2.2.建立统一数据与信息访问平台

本系统最终将建成数据收集、数据存储、数据利用一体化的统一数据平台,为寿险数据仓库应用以及其它数据应用系统提供数据支持,建设目标上应该达到以下要求。

有效集成和整合寿险各业务系统的数据,建立中央、集成的企业级数据平台。

遵循“统一规划、统一数据标准、统一数据模型、统一技术标准,分布实施开发”的原则,逐步建立人寿的数据标准、数据管理和数据质量体系,提升人寿整体信息资源管理和应用能力。

保留历史数据,支持寿险长期性的趋势分析和战略决策,建立业务单一视图,为业务运作提供洞察力。

从整体上对数据仓库平台进行全方位规划和设计,建立数据仓库开发、实施方案,建立人寿具有先进性、灵活性和可扩展性的企业级数据仓库的总体结构。

同时制定系统运营维护策略。

建立标准的、企业级的寿险BI应用架构和体系。

二.2.3.基于数据仓库建立统一应用分析平台

建立寿险统一数据仓库分析平台是本项目的另一个重要目标。

建立业务分析能力和客户统一视图,同时为领导提供经营指标快报和决策仪表盘等,具体包括:

(一)管理层报表

向公司决策管理层提供形象化的图形展示页面,包括计划达成地图分析、仪表盘、指标预警、业绩快报等。

该页面可以直观的展现决策管理层所关心的关键业务数据及变化情况,便于管理层掌控公司整体运营状况,提供决策信息依据。

(二)部门统计报表

根据各业务部门对统计数据的需求,为业务部门提供统计报表,反映运营情况、业绩情况、人力情况等关键信息,报表涉及业务部门关心的KPI指标。

(三)部门主题分析

通过建立数据模型,根据业务部门关注的指标和维度集合,提供OLAP多维分析功能,多维分析包括保费收入分析、保单分析、赔付分析、利润及成本分析、代理机构及代理人分析、客户组成分析、销售分析及客户服务分析等功能。

(四)部门明细报表

为各业务部门提供所需要的明细报表数据,如保单明细、应收明细、理赔明细等明细报表。

(五)分公司及分支机构报表

专门为满足分公司统计需求,为分公司提供数据服务而开发的报表。

二.3.非功能性需求

二.3.1.扩展性方面

具有极强的易用性以及快速开发能力,通过各种向导式界面、联机帮助、提示窗口等,定义各种复杂报表,并随着应用的不断变化可重复对报表定义进行修改。

满足今后多元化经营中的新增功能需要;

提供丰富的函数,支持自由扩展,便于二次开发。

支持大数据量、多用户并发数据访问。

适应公司分支机构的各种结构变化,并能从数据提供与管理等各方面满足变化后的统计分析需求;

随着系统容量的扩充,硬件平台的改变应不涉及系统代码的改变;

系统必须拥有统一的快速开发平台或工具。

二.3.2.灵活性方面

满足信息设施和应用系统架构的要求;

基于组件的架构;

组件的功能或特性可以通过参数配置来改变,实施周期短,见效快,避免对购买的软件包做大量的二次开发。

系统的功能、流程和核算方式可以根据管理要求发生变化,这些改变不应牵涉到系统程序代码的调整。

系统要能够提供灵活的方式,通过系统参数的设置和调整实现。

二.3.3.安全性方面

用户认证;

数据访问控制;

操作员账号管理。

权限可控制到具体应用报表和数据层面。

二.3.4.用户界面方面

维持统一的外观;界面元素的位置合理,主次分明,便于操作;所有用户的界面直观明了,大多数情况下所有重要操作都需要再次确认才能实现;提供集成的(与界面集成)和附加的(联机帮助)帮助;所有用户界面应提供及时提示信息、预警信息和出错信息,通俗易懂,简单明了;对数据操作过程中出现的系统错误,提供详细的错误信息和良好的技术跟踪手段;用户查询界面需考虑输出数据到其他的应用程序,如Execel、Word等;大部分用户界面应具备结果打印功能,且打印格式美观;分析报表设计的需求:

迅速高效地生成报表;用户可以自定义报表版式;通过统计分析功能在用户端实现复杂交互功能,包括计算,筛选和排序;能保存预先设计的报表模板常规和预先设计报表使用。

报表输出的需求:

报表需提供预览功能;能输出各种格式,如HTML,Excel等;能同时分发报表到多种媒体,如E-Mail,打印机等;打印功能支持灵活的纸张定义及缩印功能。

支持浏览器模式,能通过广域网远程操作。

第三章

系统设计

三.1.目标

在基础数据平台和数据应用分析平台基础上,对客户、保单、产品、渠道、组织、事件和营销活动等各个方面进行业务分析,实现对外营销与对内管理的双重目的。

引入全球领先的技术和产品,整合寿险现有的各种渠道,实现统一的寿险数据仓库平台,提高自动化营销能力,和对高端客户的服务能力,能够实现一致性的信息和服务的业务流程。

三.2.技术架构

本方案主要用到了Informatica、Cognos等关键技术,下面对主要使用技术做一个概述性的说明。

三.2.1.Informatica

Informatica产品支持数据集成周期的各个阶段。

Informatica产品提供一套无缝集成的工具,该工具建立在基于面向服务的体系结构(SOA)的统一数据集成平台上。

该平台包括通用的数据访问和元数据服务、数据服务、基础架构服务和数据集成服务。

一、PowerCenter

各种规模的公司都可以访问、发现并集成任何业务系统中各种格式的数据,并可以任意的速度在企业范围内传递数据。

PowerCenter是统一的企业数据集成平台,解决了使问题复杂化的各种挑战。

例如,可以帮助用户从原有系统中移植数据、整合各种应用程序实例或同步多个业务系统中的数据。

PowerCenter可帮助企业从其所有数据中获取商业价值,从而使他们可以降低IT成本和复杂度、简化业务运营和流程并且增加收入。

PowerCenter是Informatica核心产品,是专注于ETL领域的产品,是世界级的企业数据集成平台,它在ETL领域中无论是执行能力还是战略远见方面都是佼佼者。

PowerCenter功能强大,支持各种数据源和目标系统,强大的转换、清洗与维护功能,灵活的作业调度,让企业在较短的时间内高质量的完成项目。

尤其在海量数据处理、多线程并发处理、负载均衡等方面表现出良好的性能。

使用PowerCenter,企业能够通过“一次建立,任意部署”的方法从事多个不同的集成项目。

Informatica独特的、以元数据为核心的架构体系,可以轻松的收集、管理、浏览元数据,受到全球遍及电信、金融、制造、零售、医疗等领域用户的好评与认可。

PowerCenter是基于引擎和元数据驱动的体系架构,体系架构如下:

二、PowerExchange

可以简化数据集成,甚至是最复杂的数据源的数据集成,可以按需访问所有的关键企业数据系统(包括基于大型机、中等范围和文件的系统)中的数据。

PowerExchange无需手动为数据抽取计划编码便可为人们和流程所用,是实现数据实时同步的主要工具之一。

三.2.2.Cognos

IBMCognos作为业界领先、全面、成熟的解决方案,能够高质量的实现决策支持平台相关功能需求,其灵活性又能保证解决方案不仅能应用在现阶段的项目中,还能够随着应用规模的扩大而进行动态适配。

IBMCognosBI平台满足大型企业使用商业智能的所有条件:

考虑到了所有用户的多种信息需求,降低了维护成本,并且无需复制现有基础架构即可利用现有资产。

IBMCognosBI平台是行业领导者支持开发的,采用了开放式的数据战略,提供了一个易于部署、使用和整合BI解决方案的理想基础。

CognosOLAPServer是Cognos提供的企业级OLAP服务器,它将从各类数据源(数据库、数据仓库、平面文件)中精心筛选出来的“黄金”数据创建成称为PowerCubes的多维数据立方体。

立方体是按探察业务的OLAP多维因素分析模型的设计创建,通过对多维数据立方体的OLAP分析,用户可以辨明趋势、跟踪业务运作、创建高效的统计汇总报表。

CognosQueryStudio查询功能提供给用户自助式的即席查询功能,用户可以按照自己的需要通过鼠标拖拽的方式查询自己关心的内容,设置查询条件,设置过滤,定义格式,套用模版,通过自助式的查询,大大提高了用户得到个性化信息的速度。

用户的操作可以完全基于业务的逻辑,而不需要理解复杂的数据库结构,SQL语法等。

用户的操作过程基本上不需要培训。

同时查询的结果可以方便的生成HTML、PDF甚至是XML等多种输出格式,提供给用户最全面的数据查询和即席报表展现功能。

同时通过简单的点击鼠标的操作就可以将个性化的查询就行保存和共享。

真正实现了用户的自助操作,用户使用起来得心应手。

CognosReportStudio提供了专业的报表功能,报表支持多页设计,支持多查询,每个查询支持多数据源。

报表的制作,发布,共享,权限控制等都是采用没有插件的纯浏览器方式。

用户只需要在浏览器中通过简单的鼠标拖拽,属性设置等操作就能进行各种报表的制作,如列表,交叉表,图表,财务报表,地图报表,仪表盘报表,KPI报表,甚至是中国式的复杂嵌套表头的非平衡报表都可以直接通过鼠标拖拽的方式实现。

还能够进行交叉表中点的公式定义。

整个过程不需要编写程序。

强大的报表制作和展示功能能够制作/展示任何形式的报表,其纯粹的Web界面使用方式又使得部署成本和管理成本降到最低。

ReportStudio还提供了HTML、PDF甚至是XML等多种输出格式,提供给用户最全面报表功能。

Cognos具有丰富的图形展现形式,支持如柱图、线图、面积图、组合图、雷达图、气泡图、饼图、仪表盘、地图、Microchart等,并且图形都可以选择普通二维和3D图形进行展现。

图形之间可以通过Cognos的穿透钻取来进行图形-图形,图形-数据表格之间的联动分析功能。

三.3.逻辑架构

图1方案架构图

一个完整的数据仓库系统解决方案,包括:

数据源层、ETL层、数据服务层、BI应用层、中间服务层、访问控制层和最终用户层。

贯穿整个过程包括元数据管理体系和安全管理体系。

在上述技术体系结构中采用多层、可扩展框架结构,具有高度的扩展能力和方便的系统开发和维护性能,符合目前流行的多层应用结构,适合数据仓库多阶段、多层次的应用特点。

三.4.功能设计

三.4.1.指标体系

含有寿险相关指标400多个,维度70多个,在具体的应用中,可根据客户需求,选择对应主题模型中的指标、维度,进行数据卡片细化。

从而进行具体物理模型的客户化实施。

图2寿险指标体系

为了更好的说明分析模型视图的具体应用,选取承保分析举例说明分析模型中指标与维度的使用。

表1维度指标说明

维度

统计时间(天、月、年、可选时间)、管理机构(到4级)、机构负责人、销售机构(区部组)、代理人、职务职级、险种、保费性质(趸交/首年首期/首年续期/续年)、产品类型(健康险/寿险/意外险)、产品细分(普通/分红)、产品责任性质(定期/意外/重大疾病等)、产品保障年期(一年期及一年期以上/一年期以上)、产品长短期(长期险/短期险/极短险)、主附险标识(主险/附加险)、投保单号、保单号、交费方式(现金/转账等)、交费频率(期交/趸交)、业务性质(契约/保全等)、业务行为(契约-首期保费收入/保全-协议退保等)、交费年期、保障年期、保费收入口径(业务/财务/所有)

指标

规模保费、标准保费、标准件数、保障+A&H单规模保费、保障+A&H单标准保费、保障+A&H单标准件数、标保保障+A&H标保占比、行业标保、新业务价值、寿险规模保费、寿险标准保费、寿险件数、件均标保、寿险件均标保、月标保计划、月标保计划达成率、年标保计划、年标保计划达成率、月标保达成率排名、年标保达成率排名、13个月保费继续率、综合契撤率

说明

计划值要求外部导入

1、维度分析:

按照目前需求,我们把现有需求中的维度要求归纳为几类:

机构类:

管理机构、销售机构

代理人类:

职级

险种类:

产品类型、产品细分、责任性质、长短线类别

业务行为:

契约、保全等

年期类:

保障年期、保险年期

其他:

结合维度视图分析

图3维度说明图

2、指标分析:

根据需求对指标项的要求,结合指标模型,我们按照客户需求选择两个主题:

新契约与续期。

应用视图如下:

图4指标说明图1

图5指标说明图2

三.4.2.数据与信息访问平台

数据源

数据源指存储于寿险各系统中的数据及外部数据,包括核心业务系统数据、财务系统和收付系统数据以及从其他各个方面得到的外部输入数据。

数据仓库将整合来自于这些系统的数据,形成寿险全公司范围的统一的、一致的基础数据集,并提供给不同的应用主题形成数据集市。

由于各种原因,不同的源系统的体系架构、开发平台、接口技术等存在很大差别,不同系统的数据定义、标准也存在很大的差异;另外由于业务的不断变化,历史数据与当前数据之间的含义也可能存在不同,因此数据整合必须充分考虑源系统在技术和数据方面存在的差异。

从数据仓库各主题数据需求总体来看,未来企业数据仓库的数据源将包括大部分已经投入使用的系统,另外部分数据将可能来自手工数据或外部数据源。

另外,数据源源自于寿险的各个相关系统,由于各种各样的原因,其数据质量都不尽如人意。

在这种情况下,需要针对不同的情况,采用各种改善数据质量的方法,包括在数据抽取、清洗、转换过程中对数据的加工处理,甚至采取一些人工处理的手段,以保证数据仓库中数据的质量,从而保证建立在数据仓库之上的应用的结果质量。

操作数据镜像ODS区

操作数据镜像ODS区,存储和管理来自源数据系统的数据,数据未经整合,其数据模型同源系统数据结构。

在数据质量问题比较严重的行业,我们一般建议在EDW范围内保存一份完整的镜像数据,隔离源系统和数据仓库之间的数据质量问,数据质量问题发生后,我们可以清晰定位是数据源的数据质量问题还是数据仓库内部处理产生的数据质量问题。

操作数据镜像ODS区存在的另外一个理由是部分应用(例如:

审计、稽核)需要原始的明细操作数据。

数据仓库范围内的数据分析结果(例如客户分析评级数据)如果需要向其他系统提供访问服务,一般也回写到本区域再向外提供访问服务。

数据整合区

数据整合区,存储整合后的数据,并为访问用户提供数据服务,数据仓库中的数据按照数据模型分主题进行组织和存放,包括当期的和较长时间的历史数据。

数据整合层的核心是企业级数据模型的规划和设计,是所有应用的基础。

寿险数据仓库项目的数据模型设计,将基于成熟的保险数据模型,将寿险全公司的业务数据进行整合、组织、重构和存放,保证了业务分析应用和管理报表需求的需要,系统设计考虑到满足未来业务系统及其他系统的数据扩展性要求。

数据整合层中的数据将遵循企业数据仓库数据的管理规范来组织和设计,包括满足涵盖企业范围的业务数据规范的基础数据模型、整合数据层和基于共享维和共享事实表的通用分析模型。

数据集市

数据集市设计用途是要满足特定的目的,同时具有查询、分析和报表功能。

这与企业数据仓库截然不同,设计时企业数据仓库在信息内容与结构方面尽可能拥有开放性与灵活性。

数据集市有以下特征:

为特定用途而设计——数据集市设计的目的,是支持特定用户对数据子集的特定范围的查询。

它以用户所要求的方式提供企业数据仓库的细节汇总。

优化——数据集市为了支持特定工具的访问而优化。

根据工具、根据企业数据仓库提供的信息子集来设计数据集市,而不是让用户直接访问企业数据仓库中的大型数据库,这可以改善数据集市的性能。

虚拟或物理数据集市——数据集市可以是物理的实现,也可以是企业数据仓库表的各种视图。

使用视图(虚拟数据集市)可以避免存储数据的多个副本,简化了数据管理。

数据集市,即DataMart,指面向专项应用领域的分析主题。

DataMart可以是通过OLAP技术,利用数据仓库的数据根据用户需求建立的多维分析模型(多维立方体),模型以特定的方式存储,大大提高了前端查询访问的效率,用户能方便地实现灵活、动态、快速、多角度、多层次地分析企业数据。

同时,DataMart也可以通过定制灵活的OLTP查询来了解明细数据。

ETL服务层

数据抽取、转换和加载是将数据从数据源整合到数据整合层和数据集市的过程。

抽取是指识别最佳的数据源,并从中获得所需的数据。

它是将数据导入数据整合层的第一步。

抽取意味着读取并理解源数据,并复制数据整合层所需要的部分。

转换泛指使数据整合层数据适合于终端使用的过程。

这一过程包括那些将源数据格式变为目标数据库格式的模块。

一般而言,转换包括映射、清洗、汇总、重排和排序等步骤。

在企业数据仓库系统架构中,包括两个部分的ETL过程:

从源系统到数据整合层的ETL过程和从数据整合层到各数据集市之间的ETL过程。

从源系统到数据整合层之间的ETL将需要完成对源数据的清洗和整合,最终在数据整合层中形成企业范围内的统一的、一致的数据集;从数据整合层到各数据集市之间的ETL过程主要是根据不同主题数据集市分析的需要,从数据整合层中提取数据经过转换生成主题特定的数据集。

标准的ETL流程分为5个大的步骤,通过对数据的加载、清洗、整合、处理、汇总等处理,把数据加载到寿险的数据整合层模型和数据集市模型,实现强大的信息查询和报表分析。

图6ETL流程图

三.4.3.应用

展开阅读全文
相关资源
猜你喜欢
相关搜索
资源标签

当前位置:首页 > 人文社科 > 法律资料

copyright@ 2008-2023 冰点文库 网站版权所有

经营许可证编号:鄂ICP备19020893号-2