EDW-(DM数据仓库数据建模)模型设计课件

BI.Insurancei.DWMforP&C

模型设计说明BI.Insurancei.DWMforP&C模型设1日程为什么需要模型模型的组织结构模型实施方法模型设计策略Q&A|日程为什么需要模型|2日程为什么需要模型模型的组织结构模型实施方法模型设计策略Q&A|日程为什么需要模型|3EDW体系架构源系统层ETL层数据仓库层ETL层数据集市层应用层展现层手工数据外部数据数据仓库保险数据模型核心业务财务系统再保险系统人意险系统精算系统客户关系管理OCRM客户讯息ECIF业务量分析数据集市业务持续性分析数据集市ALM数据集市财务分析数据集市车险承保分析通用承保分析风险管理应用ALM应用财务分析应用aCRM数据集市aCRM报告大客户分析管理系统aCRM引擎数据挖掘引擎数据挖掘应用企业信息门户企业统一分析平台元数据库监管报表管理报表运营报表仪表盘随机查询多维分析“数据和信息集成平台”“统一的分析平台”“唯一的信息出口”EDW体系架构源系统层ETL层数据仓库层ETL层数据集市层应4为什么需要企业模型？数据集市之间数据一致性包含全部历史的核心数据一致的事实表和维度为什么需要企业模型？数据集市之间数据一致性包含全部历史的核心5EDW数据模型在项目实施中的作用DWM数据仓库模型BAM业务分析模型运营型业务系统数据仓库数据集市报表分析型应用XMLFileFlatFileInformixOracleSQLDB2BSA业务模版应用EDW数据模型在项目实施中的作用DWMBAM运营型业务系6日程为什么需要模型模型的组织结构模型实施方法模型设计策略Q&A|日程为什么需要模型|7模型总体结构－EM&DataMarts核心原子数据事实表和维度企业模型营销管理快速入门客户细分和管理保险盈利性分析潜在客户管理数据集市导出业务数据模型映射指标要素需求模型财务报表数据集市中介绩效分析数据集市健康险盈利性管理数据集市模型总体结构－EM&DataMarts核心原子数据事实表8DWM数据模型逻辑结构当事人营销和沟通组织产品协议保险标的交易渠道资源与理赔相关的活动及各理赔环节理赔保险公司的有形资产和无形资产信息与客户之间资金或非资金活动的信息与客户交易或接触的渠道信息任何市场化的产品或服务和客户之间为某种产品或服务而设定的协议信息被保险的标的物及标的物的相关信息个人或团体及其基本信息和相关信息为增加客户、保留客户、拓展业务而进行的策略、规划或促销事件分支机构、部门和职员的信息地理区域，物理的或电子的地址信息地理位置与当事人或协议相关的一系列事件事件DWM数据模型逻辑结构当事人营销和沟通组织产品协议保险标的9BI.Insurancei.DWMforP&C底层数据模型主题域说明：Agreement：保单、批单申请及管理；Claim：理赔FinancialTransaction：应收应付、实收实付以及交易关联Party：当事方，包括当事方的组织结构、角色结构及类型MoneyProvision：资金管理SpecificationAndProduct：规范及产品管理Place：地点Code：标准代码Activity：活动管理PhysicalObject：实物、标的管理BI.Insurancei.DWMforP&C底层数据10BI.Insurancei.DWM-AgreementBI.Insurancei.DWM-Agreement11BI.Insurancei.DWM-ClaimBI.Insurancei.DWM-Claim12BI.Insurancei.DWM-PhysicalObjectBI.Insurancei.DWM-PhysicalOb13日程为什么需要模型模型的组织结构模型实施方法模型设计策略Q&A|日程为什么需要模型|14表级映射字段映射实体、属性建模关联、属性建模SA建模需求划分多维建模使用模型、产生报表需求收集数据分析模型映射数据建模ETL前端提供需求及模版客户提供需求需求整理步骤：流程：产出：原则：需求文档：1.报表需求2.功能需求3.非功能需求1.目前的报表2.想做的报表3.想做的功能1.数据筛选清单2.数据源报告：3.数据质量分析报告4.代码清单Mapping文档：源-模型对应关系A筛选：去掉ETL需要而模型不需要的字段1.逻辑模型2.物理模型3

逻辑物理数据元素对照表设计文档：1.Mapping流程图2.数据元素Mapping文档A：数据源报告：1.主要功能2.历史数据情况3.与其它系统关系4.联系人B：数据质量报告：1.数据类型2.值分布3.关联情况数据调查数据质量分析代码整理数据筛选B映射：1.映射到EM2.结合性能考虑3.结合实现考虑数据筛选：1.程序控制,计算,通讯,安全控制配置,日志2.汇总类结果一般不要3.可以由其它字段算出的字段一般不要4.从其它系统导入的数据不要.5.代码表不要。6.单纯的险种定义信息不要，但是具体保单中涉及的险种定义信息可以要。Mapping设计Mapping程序开发测试数据加载1.多维模型设计文档：维度指标派生指标2.需求-模型映射文档3.报表样张4.操作说明数据筛选：1.表一级筛选2.字段级筛选数据筛选：1.模型的数据筛选2.ETL映射数据筛选EDW具体实施流程表级映射字段映射实体、属性建模关联、属性建模SA建模需求划分15日程为什么需要模型模型的组织结构模型实施方法模型设计策略Q&A|日程为什么需要模型|16Hashcode问题的提出:进行增量加载时无法快速判断对表的原有记录是否新插入。例如：1.理赔案件发生的时候,增量文件会把保单数据也传来2.保单增量过来,可能只是投保人的信息改了,而目标保单表所需信息并没有改变解决方案：使用增量的比较字段生成Hashcode。在对表进行增量加载时，对增量文件中的每一条记录生成Hashcode将生成完的Hashcode与原表中同一anchorid并且最新的记录的Hashcode进行比较如果一致的话，即不动作；如果不一致的话，即新插入。使用示例：在individualagreement表中使用各个需要保留历史信息的字段生成hashcode。在增量加载时，使用业务增量文件中的字段生成hashcode。与Individualagreement表中同一agreementid的最新记录的hashcode进行比较。如果一致，即不动作如果不一致，则插入新记录。备注：relationship表是要根据业务去判断是否关系已经存在，然后，如果有其他属性（如：Roleplayer-PhysicalobjectRlship.Usage），才需要用hashcode判别是否重复。|Hashcode问题的提出:|17Hashcode字段组成规则带anchor的实体带status表的实体（Commercialagreement、Groupagreement、Individualagreement、Claimfolder、Elementaryclaim）除表的主键、typeid、Partitionkey、Status、Statusdate、Statusreason、Validfromdate、Validtodate、Effectivefromdate、Effectivetodate、Populationtimestamp之外的所有字段不带status表的实体除表的主键、typeid、Partitionkey、Validfromdate、Validtodate、Effectivefromdate、Effectivetodate、Populationtimestamp之外的所有字段不带anchor的实体原则上不需要保留历史，一般执行Update操作。如果有需要的，ETLMapping特别指明关联实体对于需要保留历史的关联类型，除Identifier、Partitionkey、Natureid、Leftanchoridentifier、Rightanchoridentifier、Leftentityidentifier、Leftentitytypeid、Rightentityidentifier、Rightentitytypeid、Validfromdate、Validtodate、Effectivefromdate、Effectivetodate、Populationtimestamp之外的所有字段|Hashcode字段组成规则带anchor的实体|18Partitionkey问题的提出:在进行多表关联时，所涉及的关联表行数巨大，关联速度达不到要求。解决方案：在所有大表中建立Partitionkey,按照该键的键值对表进行物理分区。Partitionkey从Partitionconfig表中获得。分区策略是按照分公司进行分区。使用示例：表A与表B进行关联时，如下进行

selectA.column1,B.column2fromA,BwhereA.foreign_key=B.Primary_keyandA.partition_keyin(selectStoragepartitionfromPartitionconfigwhereBranchcompanyid=xxxx) andB.partition_keyin(selectStoragepartitionfromPartitionconfigwhereBranchcompanyid=xxxxxxx)|Partitionkey问题的提出:|19|对保单和理赔状态的特殊处理问题的提出：保单在承保和保全的整个过程中状态变化比较多，如按照IIW的原有设计，保单表中的会有巨量的历史记录；理赔在报案、立案和估损的整个过程中状态变化较多，如按照IIW的原有设计，理赔表中会有很多的历史记录。解决方案：将保单的状态变化过程剥离出来单独建表，在该表中保留与保单的关联；当有新状态插入时，更新对应的保单表中的状态。将理赔的状态变化过程剥离出来单独建表，在该表中保留与理赔的关联；当有新状态插入时，更新对应的理赔表中的状态。使用示例：增加Commercialagreementstatus，Groupagreementstatus，Individualagreementstatus表，分别记录Commercialagreement,Groupagreement,Individualagreement的状态变化历史。当前面状态发生该变时，在status表中插入新记录，更新对于原表中的状态字段。|对保单和理赔状态的特殊处理问题的提出：20对保单和理赔状态的特殊处理示例|IndividualagreementIndividualagreementstatus对保单和理赔状态的特殊处理示例|Individu21Left/RightEntityIDinRelationshiporRoleEntity问题的提出在IIW中的不同subjectarea的实体关联通常是走关联实体的，例如：Physicalobject-AgreementRlship。在关联实体中是以anchorid进行连接的。在分析的时候，通常是应该按照当时的状况进行分析才有意义。由于EDW是保留历史信息的，同一个Physicalobject或Agreement会有多条记录，如何找到当时的记录，必须通过effectivefrom/todate的比对才能实现，这非常影响效率。解决方案在关联实体中增加Left/Rightentityidentifier，Left/RightentitytypeidLeft/Rightentitytypeid是指具体基础表的id号例如：Roadvehicle（2001260001）Left/Rightentityidentifier是指具体基础表中记录的主键id值例如：Roadvehicle中牌照号沪A－000001车辆的第一条记录的Roadvehicleid值适用范围：FSRolePhysicalobject-AgreementRlship|Left/RightEntityIDinRelati22SampleofLeft/RightEntityIDinRelationshiporRoleEntity|RoadvehicleIndividualagreementAgreementPhysicalobjectPhysicalobject–AgreementRlship被保标的SampleofLeft/RightEntityID23Partyroleinoperation/Internalperson问题的提出在业务中有很多操作员角色，只有工号、姓名信息，没有身份证等其他信息；一个操作员在一个业务流程中会同时扮演不同角色，如在A保单核保中他是录入人，在B保单核保中他是复核人或者可能出现在A保单核保中他既是录入人又是复核人解决方案建立Internalperson表保存业务员、公司管理人员的个人信息，这些信息质量较差建立Partyroleinoperation表保存操作员角色信息，每次都生成新记录。录单员冗余到保单中，理赔的操作员也冗余到claimfolder中|Roleplayer-ActivityRlshipPartyroleinoperation（Roleplayerid

）InternalPerson（Roleplayerid）FinancialServicesRolePartyroleinoperation/Intern24关联实体的版本问题由于关联实体本身没有对应的anchor实体，不存在版本问题，但是关联存在有以下两种变化情况。人“王五”拥有一栋房屋，在2007/1/1卖掉了。更新原有的Roleplayer－physicalobjectRlship记录的

validtodate：if源系统有系统更新日期，则＝更新日期－1；else，则＝“2006/12/31” effectivetodate：＝“2006/12/31”人“王五”拥有一栋房屋，在2007/1/1卖掉50％的产权。更新原有的Roleplayer－physicalobjectRlship记录的

validtodate：if源系统有系统更新日期，则＝更新日期－1；else，则＝“2006/12/31” effectivetodate：＝“2006/12/31”

（Ownershippercentage：＝100％）插入新的Roleplayer－physicalobjectRlship记录

validfromdate：if源系统有系统更新日期，则＝更新日期－1；else，则＝“2007/1/1” effectivefromdate：＝“2007/1/1” Ownershippercentage：＝50％|关联实体的版本问题由于关联实体本身没有对应的anchor实体25FinancialServicesRole问题的提出Person存放人的基本信息，Externalorganisation和Internalorganisation存放机构的基本信息一个人和机构在不同环境下分别扮演不同角色，所以FinancialServicesRole存放与保单（各种协议）相关的金融服务角色，如保单持有人，被保险人，受益人等。Channelrole存放中介渠道角色信息，如营销员、收展员在分析集市中需要获取保单与业务员的关联信息，IIW原连接方式如图：|FinancialServicesRole（Financialservicesroleplayerid）Person（Roleplayerid）Channelrole（Channelroleplayerid）优点：结构清晰统一缺点：渠道角色信息关联的太远，需要FinancialServicesRole+Channelrole+Person，影响效率

Person（Roleplayerid）Externalorganisation（Roleplayerid）FinancialServicesRole问题的提出26FinancialServicesRole解决方案FinancialServicesRole用把basisroleplayertypeid确定应连接Person还是ExternalorganisationFinancialServicesRole用把basisroleplayerid确定Person或Externalorganisation中记录的roleplayeridFinancialServicesRole用把basisroleplayerentityidentifier确定Person或Externalorganisation中记录的personid或Externalorganisationid使用示例|FinancialServicesRole（Financialservicesroleplayerid）Person（Roleplayerid）Channelrole（RoleplayeridChannelroleplayerid）Person（Roleplayerid）Externalorganisation（Roleplayerid）FinancialServicesRole解决方案|27Currencycode问题的提出：在CPIC的实际业务中，可能出现多币种，在统计中需要进行多币种的转换。解决方案：在IIW模型中凡出现金额字段的表，都增加金额的币种及对应的RMB金额两类字段。原字段存放原币中金额，RMB金额存放折算成RMB的金额使用示例：Elementaryclaim表中增加Totalcostcurrency和TotalcostRMB字段备注：由于CPIC对多币种金额的统计有多种统计方式，不全部是按照发生制来折算RMB的。因此，统计转换金额到RMB的工作，留给统计部分执行，在原子层不计算。币种一定要填。|Currencycode问题的提出：|28维度表的snapshot问题的提出在分析层中，常用的维度表如：保单、立案。分析常用的属性是分散在各个表中的，如：保费、保额在ParticularMoneyProvision中。分析时如果再通过关联来找到这些信息，效率非常低。解决方案建立维度的snapshot表，将这些信息冗余存放在这些表中，每个月全量刷新一次。使用示例：ClaimfolderdimensionPolicydimensionElementaryclaimdimensionEventdimension|维度表的snapshot问题的提出|29Commercialagreement/Groupagreement/Individualagreement的边界区分Commercialagreement存放保险公司和机构投保人签订的关于承保要素约束的框架性协议；不是具体的保单。具体的保单要遵循该协议。Groupagreement团单单位和保险公司签订的保一组成员的保单，如：寿险团单、雇主责任险、旅游责任险。如果源系统提供了每个被保人的投保情况，这些记录在individualagreement（typeid＝个人凭证）中的。如：雇主责任险下每个人的投保份数。Individualagreement个单/个人凭证备注：根据国内系统的情况做了些调整，和机构投保人（非个人）签订的个单也存放在此。投保单按保单处理，只是状态是投保状态|Commercialagreement/Groupagr30Groupagreement/Individualagreement在ETL时处理车险系统保单进入Individualagreement寿险保单根据来源表，决定进入groupagreement还是individualagreementCIBS(包括老系统)和人意险保单根据Financialservicesproduct中的Individualinsuranceflag判断个险，进入Individualagreement团险、个团皆可，进入groupagreement|Groupagreement/Individualagr31最新记录标志Effectivetodate=‘9999/12/3100:00:00’|最新记录标志Effectivetodate=‘99932公司的拆分合并，partitionkey的处理–1/4分公司的拆分合并，不需要程序考虑，发生后手工处理。公司合并举例：原来有分公司A,分公司B,在2006/1/1分公司B合并到分公司A。|合并前PartitionconfigExternalorganisationIndividualagreement公司的拆分合并，partitionkey的处理–1/433公司的拆分合并，partitionkey的处理–2/4公司合并举例：原来有分公司A,分公司B,在2006/1/1分公司B合并到分公司A。|合并后PartitionconfigExternalorganisationIndividualagreementRoleplayerRlship公司的拆分合并，partitionkey的处理–2/434公司的拆分合并，partitionkey的处理–3/4公司合并举例：原来有分公司A,在2006/1/1分公司A,拆分成分公司A和分公司B。|拆分前PartitionconfigExternalorganisationIndividualagreement公司的拆分合并，partitionkey的处理–3/435公司的拆分合并，partitionkey的处理–4/4公司合并举例：原来有分公司A,在2006/1/1分公司A,拆分成分公司A和分公司B。|拆分后PartitionconfigExternalorganisationIndividualagreementRoleplayerRlship公司的拆分合并，partitionkey的处理–4/436按照typeid分表将有些大表按照Typeid进行拆分举例：Individualagreement表按照保单和投保单拆成两张表|按照typeid分表将有些大表按照Typeid进行拆37历史信息的处理对含有历史记录的大表，应考虑将历史记录剥离出来单独建表，即原表保留最新的信息，而在剥离出来的表中包含这些信息的变化历史。举例：

Individualagreement原来保留有保单的最新信息及这些信息的历史变化记录。这样这张表就将很大，记录数数以亿计。目前将它拆成2个表：表一，存放保单的最新信息，如最新状态，最新确认的起保日期等，同时保留每条记录最新的刷新时间表二，存放保单经常变化的值的变化历史，如：保单状态的变化历史表三，存放保单所有历史变化的信息|历史信息的处理对含有历史记录的大表，应考虑将历史记录剥离出来38增加表的冗余字段问题的提出：原有设计中，一条业务上具有完整意义的信息被拆分在多个表中，在生成分析层（或进行分析时）又要将被拆分的信息通过多表关联的方式关联起来。解决方案：在表中尽量增加冗余字段。要注意的是，冗余字段并非任意增加，而是要增加：冗余关联类型为m:1的字段，如：保单的所属分公司。从业务上说，基本不变化的冗余字段|增加表的冗余字段问题的提出：原有设计中，一条业务上具有完整意39增加表与表之间的外键，减少走关联表问题的提出：原有设计中，一条业务上具有完整意义的信息被拆分在多个表中，在生成分析层（或进行分析时）又要将被拆分的信息通过多表关联的方式关联起来。而这样的关联可能要跨多个表。解决方案：增加有业务含义的信息之间的直接关联。即如两表的信息如果有业务关联，而在原有设计中这两表之间的关联要借助其他中间表的，应在此两表之间建立直接的关联。例如：sellingchannelroleid在individualagreement表中的冗余。否则，要走FSRole连接channelrole。尽可能减少关联的层级。即减少不必要的关联中间表例如：如保单的操作员直接建立到保单中，保单和理赔的科室、部门直接建立到保单和理赔中。备注：m:m的关系必须走关联表。|增加表与表之间的外键，减少走关联表问题的提出：原有设计中，一40模型优化任务分配Jeffrey:Activity,Reinsurance,Claim,Goalandneed,Legalaction,Physicalobject,Place,Registration,Specificationandproduct,Standardtextandcommunication,Technicalentity,Type王正茂:Accountandfund,Actuarialstatisticsandindex,Assessmentandcondition,Category,Contactpointandpreferences,Event,Financialaccount,GoalandneedBen:Agreement,Financialtransaction,Moneyprovision,Party,|模型优化任务分配Jeffrey:Activity,Rei41EDW和ODS的关系Person、Externalorganisation、FSRole（投保人/被保人）通过ODS产生由于加载顺序的关系，保单表由业务系统产生，产生保单信息时，ODS数据还没有加载。因此，Individualagreement中的Policyholderid、Groupagreement中的Policyholderorganisationid不冗余产生，而是通过FSRole走。|EDW和ODS的关系Person、Externalorga42Id产生规则每个表单独使用id序列建id序列表|Id产生规则每个表单独使用id序列|43Anchor表是否需要物理产生建物理产生Anchor表所有和Anchor直接外键关联的typeid冗余|Anchor表是否需要物理产生建物理产生Anchor表|44Person归并决策Person，externalorganisation在EDW不再进行归并|Person归并决策Person，externalorga45Boolean0false1true|Boolean0false|46AtomicderiveddataAtomic层表中，有部分字段保存的是从其他表或字段中导出的数据，如：claimfolder中totalcost，是从internalclaimcost中统计来的。对于这部分字段，分为两部分：目前analytical层或datamart用到的，需要处理暂时没用的字段，暂不处理这部分字段的处理，在atomic产生完成后，产生analytical层前处理。|AtomicAnalytical12AtomicderiveddataAtomic层表中，有47物理分表SubjectareaEntity分表ActivityParticularactivity治疗2000060002:PA_Medicaltreat

查勘2000060004/回勘2000060005:PA_InvestigationAgreementCoveragecomponentCoveragecomponenthistoryIndividualagreementIndividualagreementhistoryClaimClaimfolder报案2000360001：CF_Reportcase

立案案卷2000360002：CF_files

赔案2000360004/追偿赔案2000360005:CF_indemnityMoneyprovisionMoneyschedulerMoneyin:Moneyinscheduler

Moneyout:Moneyoutscheduler

Moneyscheduler在物理层不使用Particularmoneyprovision保额:PMPinsuredamount保费:PMPpremiumPartyFinancialservicesrole2000660002投保人:FSRapplicator

2000660003被保人:FSRInsuredPaymentPayment保费来源的：Premiumpayment赔款来源的：ClaimpaymentPaymentdue保费来源:Premiumpaymentdue赔款来源:ClaimpaymentduePhysicalobjectOtherphysicalobjectGeneralcargo2000850001：Cargo

Machineitem2000850004：MachineStructureDwelling2000890001：Dwelling

Hotel2000890003:Hotel

Platform2000890004:Platform|备注：没特别注明的其他类型的在原Entity中物理分表SubjectareaEntity分表Activi48MoneyschedulerMoneyinscheduler用于连接对于保险公司来说是进来的钱的particularmoneyprovision/Financialtransaction，如：保费、储金（包括批增、批减）Moneyoutscheduler用于连接对于保险公司来说是出去的钱的particularmoneyprovision/Financialtransaction，如：赔款、支付的养老金（包括摊回赔款）每个保单签单产生一个Moneyinscheduler，保单不含批单的保额、保费挂在该Moneyinscheduler下；每个批单单产生一个Moneyinscheduler，该批单对应的保额、保费变化挂在该Moneyinscheduler下。每个赔案产生一个Moneyoutscheduler，该赔案对应的Particularmoneyprovision挂在该Moneyoutscheduler下。|MoneyschedulerMoneyinschedu49关联表冗余进实体表中－1/2SubjectareaEntity加字段备注ActivityActivity-PlaceRlshipclaimfolder.报案地点Activity-PlaceRlship.Nature_id=报案地点2000030003直接挪到claimfolder中ActivityActivity-PlaceRlshipParticularactivity.活动地点Activity-PlaceRlship.Nature_id=

查勘地点2000030004

工程作业地域2000030005

建造地点2000030006

交船地点2000030007

直接挪到Particularactivity.活动地点ActivityActivity-PlaceRlshipTransportation.启运港/Transportation.中转港1/Transportation.中转港2/Transportation.目的地Activity-PlaceRlship.Nature_id=

启运港2000030008

中转港2000030009

直接挪到Transportation.启运港/Transportation.中转港

加代码字段和名称字段

如果有超过2个的中转港，则走原有关联表ActivityClaimcheckOperationroleplayerid执行人ActivityClaimcheckReviewroleplayerid复核/审核人ActivityUnderwritigcheckOperationroleplayerid执行人ActivityUnderwritigcheckReviewroleplayerid复核/审核人AgreementChangerequestOperationroleplayerid操作员代码AgreementGroupagreementOperationroleplayerid原通过Financialservicerole关联保单和Partyroleinoperation,现在直接将操作员id冗余进Groupagreement表中AgreementGroupagreementDepartmentid保单部门，原先必须通过与Party主题关联得到，现在增加冗余|关联表冗余进实体表中－1/2SubjectareaEnt50关联表冗余进实体表中－2/2SubjectareaEntity加字段备注AgreementGroupagreementSectionid科室代码，原先必须通过与Party主题关联得到，现在增加冗余AgreementIndividualagreementOperationroleplayerid原通过Financialservicerole关联保单和Partyroleinoperation,现在直接将操作员id冗余进Individualagreement表中AgreementIndividualagreementDepartmentid保单部门，原先必须通过与Party主题关联得到，现在增加冗余AgreementIndividualagreementSectionid科室代码，原先必须通过与Party主题关联得到，现在增加冗余AgreementIndividualagreementCommercialagreementid到commercialagreement的直接关联FinancialtransactionPaymentAgreementrequestid批单号FinancialtransactionPaymentAgreementrequesttypeid批单表typeid类型FinancialtransactionPaymentdueAgreementrequestid批单号FinancialtransactionPaymentdueAgreementrequesttypeid批单表typeid类型PaymentPaymentPayment.Agreementid协议号PaymentPaymentPayment.Agreementtypeid协议类型PaymentPaymentduePaymentdue.Agreementid协议号PaymentPaymentduePaymentdue.Agreementtypeid协议类型PhysicalobjectPhysicalobject-Registrationrlshipship.船籍(代码)船籍2000790001|关联表冗余进实体表中－2/2SubjectareaEnt51Anchor的typeid冗余到外键关联的表中-1/2AnchorEntity新增冗余字段AccountaccountentryaccounttypeidActivityMarketingobjectiveMarketingactivitytypeidActivityParticularmoneyprovisionactivitytypeidAgreementFinancialservicesroleContextfinancialservicesagreementtypeidAgreementStatementelementAgreementtypeidAgreementMoneyschedulerAgreementtypeidAgreementGenericmoneyprovisionAgreementtypeidAgreementParticularmoneyprovisionAgreementtypeidAgreementReinsurancefinancialentryAgreementtypeidAgreementReinsurancepremiumdetailAgreementtypeidAgreementClaimindemnitydetailAgreementtypeidClaimPartyroleinclaimContextclaimtypeidClaimClaimindemnitydetailClaimfolderanchortypeidClaimReinsuranceindemnitydetailClaimfolderanchortypeid|Anchor的typeid冗余到外键关联的表中-1/2A52Anchor的typeid冗余到外键关联的表中-2/2AnchorEntity新增冗余字段ClaimClaimindemnitydetailElementaryclaimanchortypeidClaimReinsuranceindemnitydetailElementaryclaimanchortypeidPartyAccountproviderAccountproviderroleplayertypeidPartyChannelroleplayeridChannelroleplayertypeidPartyCustomerCustomerroleplayertypeidPartyEmploymentroleEmploymentroleplayertypeidPartyFinancialservicesroleFinancialservicesroleplayertypeidPartyPartyroleinagreementrequestRequestpartyroleplayertypeidPartyPartyroleinclaimClaimpartyroleplayertypeidPartyPartyroleinlegalactionLegalactionpartyroleplayertypeidPartyProviderroleProviderroleplayertypeidPartyParticularmoneyprovisionMoneypayeetypeidPartyParticularmoneyprovisionMoneypayertypeidPhysicalobjectMarketableobjectTradeablephysicalobjecttypeid|Anchor的typeid冗余到外键关联的表中-2/2A53Claim中涉及的各种金额存放规则－1/2|Claim中涉及的各种金额存放规则－1/2|54Claim中涉及的各种金额存放规则－2/2Particularmoneyprovision对应赔案级，其中不存放金额，起关联作用（Agreementid，Agreementtypeid，Moneyschedulerid，（Moneypayeeid，Moneypayeetypeid，Moneypayerid，Moneypayertypeid有则产生））。Moneyscheduler一个赔案产生一条记录，该赔案下的Particularmoneyprovision都挂在这个Moneyscheduler下。Claimoffer可以存放多种offer，可以为服务、物品或金钱（包括状态是未决的）Internalclaimcost用于存放理算后的公司内部发生的各种理赔费用，如查勘费、施救费、律师费等。Internalclaimcost通过Internalclaimcost-ClaimRlship与claimfolder关联查勘表中记录的明细费用（如查勘费、施救费、律师费等）放在Moneyprovisionpart，通过Moneyprovisioncashflow到Particularmoneyprovision中的activityid连接到查勘活动中Moneyprovisionpart用于存放赔给客户的赔款明细(包括状态是未决的)、到赔付项目代码级别。Moneyprovisioncashflow用于存放子险级合计的赔款金额,和claimoffer对应放在Moneyprovisioncashflow和Moneyprovisionpart中赔款的钱金额变化、Moneyprovisioncashflow/Moneyprovisionpart中赔款金额不保留版本，当出现修改时直接修改这些表中的记录ClaimOffer中的赔款金额不保留历史，将来如果业务需要，再做保留历史处理立案的估损/定损都放在Financialvaluation中估损/定损明细单独建表|Claim中涉及的各种金额存放规则－2/2Particul55核保核赔在EDW模型中的处理核保核赔本身是一个工作流程的活动，每个核保核赔又细分成不同的步骤，如：收集单证，复核等活动步骤。类似于IIW中的campaign，campaigncell和campaignstep的关系。在EDW中产险使用underwritingcheck/claimcheck来存放核保核赔信息，主活动和活动步骤通过不同的type来区分。主活动和活动步骤通过underwritingcheck/claimcheck的自关联实现。每个主活动只需要保留一条记录，有变化update；因为每个具体的步骤包括了该活动变化的信息。对于一个投保单多次核保的情况，每个核保一个主活动。|核保核赔在EDW模型中的处理核保核赔本身是一个工作流程的活动56投保单/协议申请单的处理以下投保单指：投保单或协议申请单投保单作为保单的一个历史状态处理。全量数据：即使投保单已成为保单，也要插入一条投保单的记录。Validfromdate＝录入日期，validtodate＝签单日期。Effectivefromdate＝投保日期（如果没有投保日期，同validfromdate），Effectivetodate＝签单日期。如果该投保单记录的目标表是individualagreement，则投保单的记录直接插入individualagreementhistory。如果投保单还没有成为保单，投保单的Validfromdate＝录入日期，validtodate＝9999/12/31。Effectivefromdate＝投保日期（如果没有投保日期，同validfromdate），Effectivetodate＝9999/12/31。增量数据：如果投保单已经变为保单了，就作为保单的历史记录，新插入保单的记录，如果目标表是individualagreement，则投保单的记录挪到individualagreementhistory中。如果目标表是不是individualagreement，则投保单的记录仍然在原表中。如：groupagreement，commercialagreement。投保单和保单共用同一个agreementid，typeid分别为投保单、保单（团单，个单，个单凭证等）。投保单只保持一条记录，最新状况update该记录。备注：如果将来投保单数据太多，影响执行效率，由其他程序定期执行归档处理，将已成为保单的n年前的投保单数据归档。有的系统投保单和保单是同一条记录，有的系统投保单和保单是不同条记录。在EDW中必须保持一致的处理方式。|投保单/协议申请单的处理以下投保单指：投保单或协议申请单57批改申请单的处理批改不记录历史，因此，批改申请和批改使用同一条记录，有改变直接Update该记录。在changerequest中新增一个字段存放批改申请号。|批改申请单的处理批改不记录历史，因此，批改申请和批改使用同一58日程为什么需要模型模型的组织结构模型实施方法模型设计策略Q&A|日程为什么需要模型|59日程Thankyou!|日程Thankyou!|60BI.Insurancei.DWMforP&C

模型设计说明BI.Insurancei.DWMforP&C模型设61日程为什么需要模型模型的组织结构模型实施方法模型设计策略Q&A|日程为什么需要模型|62日程为什么需要模型模型的组织结构模型实施方法模型设计策略Q&A|日程为什么需要模型|63EDW体系架构源系统层ETL层数据仓库层ETL层数据集市层应用层展现层手工数据外部数据数据仓库保险数据模型核心业务财务系统再保险系统人意险系统精算系统客户关系管理OCRM客户讯息ECIF业务量分析数据集市业务持续性分析数据集市ALM数据集市财务分析数据集市车险承保分析通用承保分析风险管理应用ALM应用财务分析应用aCRM数据集市aCRM报告大客户分析管理系统aCRM引擎数据挖掘引擎数据挖掘应用企业信息门户企业统一分析平台元数据库监管报表管理报表运营报表仪表盘随机查询多维分析“数据和信息集成平台”“统一的分析平台”“唯一的信息出口”EDW体系架构源系统层ETL层数据仓库层ETL层数据集市层应64为什么需要企业模型？数据集市之间数据一致性包含全部历史的核心数据一致的事实表和维度为什么需要企业模型？数据集市之间数据一致性包含全部历史的核心65EDW数据模型在项目实施中的作用DWM数据仓库模型BAM业务分析模型运营型业务系统数据仓库数据集市报表分析型应用XMLFileFlatFileInformixOracleSQLDB2BSA业务模版应用EDW数据模型在项目实施中的作用DWMBAM运营型业务系66日程为什么需要模型模型的组织结构模型实施方法模型设计策略Q&A|日程为什么需要模型|67模型总体结构－EM&DataMarts核心原子数据事实表和维度企业模型营销管理快速入门客户细分和管理保险盈利性分析潜在客户管理数据集市导出业务数据模型映射指标要素需求模型财务报表数据集市中介绩效分析数据集市健康险盈利性管理数据集市模型总体结构－EM&DataMarts核心原子数据事实表68DWM数据模型逻辑结构当事人营销和沟通组织产品协议保险标的交易渠道资源与理赔相关的活动及各理赔环节理赔保险公司的有形资产和无形资产信息与客户之间资金或非资金活动的信息与客户交易或接触的渠道信息任何市场化的产品或服务和客户之间为某种产品或服务而设定的协议信息被保险的标的物及标的物的相关信息个人或团体及其基本信息和相关信息为增加客户、保留客户、拓展业务而进行的策略、规划或促销事件分支机构、部门和职员的信息地理区域，物理的或电子的地址信息地理位置与当事人或协议相关的一系列事件事件DWM数据模型逻辑结构当事人营销和沟通组织产品协议保险标的69BI.Insurancei.DWMforP&C底层数据模型主题域说明：Agreement：保单、批单申请及管理；Claim：理赔FinancialTransaction：应收应付、实收实付以及交易关联Party：当事方，包括当事方的组织结构、角色结构及类型MoneyProvision：资金管理SpecificationAndProduct：规范及产品管理Place：地点Code：标准代码Activity：活动管理PhysicalObject：实物、标的管理BI.Insurancei.DWMforP&C底层数据70BI.Insurancei.DWM-AgreementBI.Insurancei.DWM-Agreement71BI.Insurancei.DWM-ClaimBI.Insurancei.DWM-Claim72BI.Insurancei.DWM-PhysicalObjectBI.Insurancei.DWM-PhysicalOb73日程为什么需要模型模型的组织结构模型实施方法模型设计策略Q&A|日程为什么需要模型|74表级映射字段映射实体、属性建模关联、属性建模SA建模需求划分多维建模使用模型、产生报表需求收集数据分析模型映射数据建模ETL前端提供需求及模版客户提供需求需求整理步骤：流程：产出：原则：需求文档：1.报表需求2.功能需求3.非功能需求1.目前的报表2.想做的报表3.想做的功能1.数据筛选清单2.数据源报告：3.数据质量分析报告4.代码清单Mapping文档：源-模型对应关系A筛选：去掉ETL需要而模型不需要的字段1.逻辑模型2.物理模型3

逻辑物理数据元素对照表设计文档：1.Mapping流程图2.数据元素Mapping文档A：数据源报告：1.主要功能2.历史数据情况3.与其它系统关系4.联系人B：数据质量报告：1.数据类型2.值分布3.关联情况数据调查数据质量分析代码整理数据筛选B映射：1.映射到EM2.结合性能考虑3.结合实现考虑数据筛选：1.程序控制,计算,通讯,安全控制配置,日志2.汇总类结果一般不要3.可以由其它字段算出的字段一般不要4.从其它系统导入的数据不要.5.代码表不要。6.单纯的险种定义信息不要，但是具体保单中涉及的险种定义信息可以要。Mapping设计Mapping程序开发测试数据加载1.多维模型设计文档：维度指标派生指标2.需求-模型映射文档3.报表样张4.操作说明数据筛选：1.表一级筛选2.字段级筛选数据筛选：1.模型的数据筛选2.ETL映射数据筛选EDW具体实施流程表级映射字段映射实体、属性建模关联、属性建模SA建模需求划分75日程为什么需要模型模型的组织结构模型实施方法模型设计策略Q&A|日程为什么需要模型|76Hashcode问题的提出:进行增量加载时无法快速判断对表的原有记录是否新插入。例如：1.理赔案件发生的时候,增量文件会把保单数据也传来2.保单增量过来,可能只是投保人的信息改了,而目标保单表所需信息并没有改变解决方案：使用增量的比较字段生成Hashcode。在对表进行增量加载时，对增量文件中的每一条记录生成Hashcode将生成完的Hashcode与原表中同一anchorid并且最新的记录的Hashcode进行比较如果一致的话，即不动作；如果不一致的话，即新插入。使用示例：在individualagreement表中使用各个需要保留历史信息的字段生成hashcode。在增量加载时，使用业务增量文件中的字段生成hashcode。与Individualagreement表中同一agreementid的最新记录的hashcode进行比较。如果一致，即不动作如果不一致，则插入新记录。备注：relationship表是要根据业务去判断是否关系已经存在，然后，如果有其他属性（如：Roleplayer-PhysicalobjectRlship.Usage），才需要用hashcode判别是否重复。|Hashcode问题的提出:|77Hashcode字段组成规则带anchor的实体带status表的实体（Commercialagreement、Groupagreement、Individualagreement、Claimfolder、Elementaryclaim）除表的主键、typeid、Partitionkey、Status、Statusdate、Statusreason、Validfromdate、Validtodate、Effectivefromdate、Effectivetodate、Populationtimestamp之外的所有字段不带status表的实体除表的主键、typeid、Partitionkey、Validfromdate、Validtodate、Effectivefromdate、Effectivetodate、Populationtimestamp之外的所有字段不带anchor的实体原则上不需要保留历史，一般执行Update操作。如果有需要的，ETLMapping特别指明关联实体对于需要保留历史的关联类型，除Identifier、Partitionkey、Natureid、Leftanchoridentifier、Rightanchoridentifier、Leftentityidentifier、Leftentitytypeid、Rightentityidentifier、Rightentitytypeid、Validfromdate、Validtodate、Effectivefromdate、Effectivetodate、Populationtimestamp之外的所有字段|Hashcode字段组成规则带anchor的实体|78Partitionkey问题的提出:在进行多表关联时，所涉及的关联表行数巨大，关联速度达不到要求。解决方案：在所有大表中建立Partitionkey,按照该键的键值对表进行物理分区。Partitionkey从Partitionconfig表中获得。分区策略是按照分公司进行分区。使用示例：表A与表B进行关联时，如下进行

selectA.column1,B.column2fromA,BwhereA.foreign_key=B.Primary_keyandA.partition_keyin(selectStoragepartitionfromPartitionconfigwhereBranchcompanyid=xxxx) andB.partition_keyin(selectStoragepartitionfromPartitionconfigwhereBranchcompanyid=xxxxxxx)|Partitionkey问题的提出:|79|对保单和理赔状态的特殊处理问题的提出：保单在承保和保全的整个过程中状态变化比较多，如按照IIW的原有设计，保单表中的会有巨量的历史记录；理赔在报案、立案和估损的整个过程中状态变化较多，如按照IIW的原有设计，理赔表中会有很多的历史记录。解决方案：将保单的状态变化过程剥离出来单独建表，在该表中保留与保单的关联；当有新状态插入时，更新对应的保单表中的状态。将理赔的状态变化过程剥离出来单独建表，在该表中保留与理赔的关联；当有新状态插入时，更新对应的理赔表中的状态。使用示例：增加Commercialagreementstatus，Groupagreementstatus，Individualagreementstatus表，分别记录Commercialagreement,Groupagreement,Individualagreement