BI.Insurancei.DWMforP&C

模型設(shè)計(jì)說(shuō)明BI.Insurancei.DWMforP&C模型設(shè)1日程為什么需要模型模型的組織結(jié)構(gòu)模型實(shí)施方法模型設(shè)計(jì)策略Q&A|日程為什么需要模型|2日程為什么需要模型模型的組織結(jié)構(gòu)模型實(shí)施方法模型設(shè)計(jì)策略Q&A|日程為什么需要模型|3EDW體系架構(gòu)源系統(tǒng)層ETL層數(shù)據(jù)倉(cāng)庫(kù)層ETL層數(shù)據(jù)集市層應(yīng)用層展現(xiàn)層手工數(shù)據(jù)外部數(shù)據(jù)數(shù)據(jù)倉(cāng)庫(kù)保險(xiǎn)數(shù)據(jù)模型核心業(yè)務(wù)財(cái)務(wù)系統(tǒng)再保險(xiǎn)系統(tǒng)人意險(xiǎn)系統(tǒng)精算系統(tǒng)客戶關(guān)系管理OCRM客戶訊息ECIF業(yè)務(wù)量分析數(shù)據(jù)集市業(yè)務(wù)持續(xù)性分析數(shù)據(jù)集市ALM數(shù)據(jù)集市財(cái)務(wù)分析數(shù)據(jù)集市車險(xiǎn)承保分析通用承保分析風(fēng)險(xiǎn)管理應(yīng)用ALM應(yīng)用財(cái)務(wù)分析應(yīng)用aCRM數(shù)據(jù)集市aCRM報(bào)告大客戶分析管理系統(tǒng)aCRM引擎數(shù)據(jù)挖掘引擎數(shù)據(jù)挖掘應(yīng)用企業(yè)信息門戶企業(yè)統(tǒng)一分析平臺(tái)元數(shù)據(jù)庫(kù)監(jiān)管報(bào)表管理報(bào)表運(yùn)營(yíng)報(bào)表儀表盤隨機(jī)查詢多維分析“數(shù)據(jù)和信息集成平臺(tái)”“統(tǒng)一的分析平臺(tái)”“唯一的信息出口”EDW體系架構(gòu)源系統(tǒng)層ETL層數(shù)據(jù)倉(cāng)庫(kù)層ETL層數(shù)據(jù)集市層應(yīng)4為什么需要企業(yè)模型？數(shù)據(jù)集市之間數(shù)據(jù)一致性包含全部歷史的核心數(shù)據(jù)一致的事實(shí)表和維度為什么需要企業(yè)模型？數(shù)據(jù)集市之間數(shù)據(jù)一致性包含全部歷史的核心5EDW數(shù)據(jù)模型在項(xiàng)目實(shí)施中的作用DWM數(shù)據(jù)倉(cāng)庫(kù)模型BAM業(yè)務(wù)分析模型運(yùn)營(yíng)型業(yè)務(wù)系統(tǒng)數(shù)據(jù)倉(cāng)庫(kù)數(shù)據(jù)集市報(bào)表分析型應(yīng)用XMLFileFlatFileInformixOracleSQLDB2BSA業(yè)務(wù)模版應(yīng)用EDW數(shù)據(jù)模型在項(xiàng)目實(shí)施中的作用DWMBAM運(yùn)營(yíng)型業(yè)務(wù)系6日程為什么需要模型模型的組織結(jié)構(gòu)模型實(shí)施方法模型設(shè)計(jì)策略Q&A|日程為什么需要模型|7模型總體結(jié)構(gòu)－EM&DataMarts核心原子數(shù)據(jù)事實(shí)表和維度企業(yè)模型營(yíng)銷管理快速入門客戶細(xì)分和管理保險(xiǎn)盈利性分析潛在客戶管理數(shù)據(jù)集市導(dǎo)出業(yè)務(wù)數(shù)據(jù)模型映射指標(biāo)要素需求模型財(cái)務(wù)報(bào)表數(shù)據(jù)集市中介績(jī)效分析數(shù)據(jù)集市健康險(xiǎn)盈利性管理數(shù)據(jù)集市模型總體結(jié)構(gòu)－EM&DataMarts核心原子數(shù)據(jù)事實(shí)表8DWM數(shù)據(jù)模型邏輯結(jié)構(gòu)當(dāng)事人營(yíng)銷和溝通組織產(chǎn)品協(xié)議保險(xiǎn)標(biāo)的交易渠道資源與理賠相關(guān)的活動(dòng)及各理賠環(huán)節(jié)理賠保險(xiǎn)公司的有形資產(chǎn)和無(wú)形資產(chǎn)信息與客戶之間資金或非資金活動(dòng)的信息與客戶交易或接觸的渠道信息任何市場(chǎng)化的產(chǎn)品或服務(wù)和客戶之間為某種產(chǎn)品或服務(wù)而設(shè)定的協(xié)議信息被保險(xiǎn)的標(biāo)的物及標(biāo)的物的相關(guān)信息個(gè)人或團(tuán)體及其基本信息和相關(guān)信息為增加客戶、保留客戶、拓展業(yè)務(wù)而進(jìn)行的策略、規(guī)劃或促銷事件分支機(jī)構(gòu)、部門和職員的信息地理區(qū)域，物理的或電子的地址信息地理位置與當(dāng)事人或協(xié)議相關(guān)的一系列事件事件DWM數(shù)據(jù)模型邏輯結(jié)構(gòu)當(dāng)事人營(yíng)銷和溝通組織產(chǎn)品協(xié)議保險(xiǎn)標(biāo)的9BI.Insurancei.DWMforP&C底層數(shù)據(jù)模型主題域說(shuō)明：Agreement：保單、批單申請(qǐng)及管理；Claim：理賠FinancialTransaction：應(yīng)收應(yīng)付、實(shí)收實(shí)付以及交易關(guān)聯(lián)Party：當(dāng)事方，包括當(dāng)事方的組織結(jié)構(gòu)、角色結(jié)構(gòu)及類型MoneyProvision：資金管理SpecificationAndProduct：規(guī)范及產(chǎn)品管理Place：地點(diǎn)Code：標(biāo)準(zhǔn)代碼Activity：活動(dòng)管理PhysicalObject：實(shí)物、標(biāo)的管理BI.Insurancei.DWMforP&C底層數(shù)據(jù)10BI.Insurancei.DWM-AgreementBI.Insurancei.DWM-Agreement11BI.Insurancei.DWM-ClaimBI.Insurancei.DWM-Claim12BI.Insurancei.DWM-PhysicalObjectBI.Insurancei.DWM-PhysicalOb13日程為什么需要模型模型的組織結(jié)構(gòu)模型實(shí)施方法模型設(shè)計(jì)策略Q&A|日程為什么需要模型|14表級(jí)映射字段映射實(shí)體、屬性建模關(guān)聯(lián)、屬性建模SA建模需求劃分多維建模使用模型、產(chǎn)生報(bào)表需求收集數(shù)據(jù)分析模型映射數(shù)據(jù)建模ETL前端提供需求及模版客戶提供需求需求整理步驟：流程：產(chǎn)出：原則：需求文檔：1.報(bào)表需求2.功能需求3.非功能需求1.目前的報(bào)表2.想做的報(bào)表3.想做的功能1.數(shù)據(jù)篩選清單2.數(shù)據(jù)源報(bào)告：3.數(shù)據(jù)質(zhì)量分析報(bào)告4.代碼清單Mapping文檔：源-模型對(duì)應(yīng)關(guān)系A(chǔ)篩選：去掉ETL需要而模型不需要的字段1.邏輯模型2.物理模型3

邏輯物理數(shù)據(jù)元素對(duì)照表設(shè)計(jì)文檔：1.Mapping流程圖2.數(shù)據(jù)元素Mapping文檔A：數(shù)據(jù)源報(bào)告：1.主要功能2.歷史數(shù)據(jù)情況3.與其它系統(tǒng)關(guān)系4.聯(lián)系人B：數(shù)據(jù)質(zhì)量報(bào)告：1.數(shù)據(jù)類型2.值分布3.關(guān)聯(lián)情況數(shù)據(jù)調(diào)查數(shù)據(jù)質(zhì)量分析代碼整理數(shù)據(jù)篩選B映射：1.映射到EM2.結(jié)合性能考慮3.結(jié)合實(shí)現(xiàn)考慮數(shù)據(jù)篩選：1.程序控制,計(jì)算,通訊,安全控制配置,日志2.匯總類結(jié)果一般不要3.可以由其它字段算出的字段一般不要4.從其它系統(tǒng)導(dǎo)入的數(shù)據(jù)不要.5.代碼表不要。6.單純的險(xiǎn)種定義信息不要，但是具體保單中涉及的險(xiǎn)種定義信息可以要。Mapping設(shè)計(jì)Mapping程序開(kāi)發(fā)測(cè)試數(shù)據(jù)加載1.多維模型設(shè)計(jì)文檔：維度指標(biāo)派生指標(biāo)2.需求-模型映射文檔3.報(bào)表樣張4.操作說(shuō)明數(shù)據(jù)篩選：1.表一級(jí)篩選2.字段級(jí)篩選數(shù)據(jù)篩選：1.模型的數(shù)據(jù)篩選2.ETL映射數(shù)據(jù)篩選EDW具體實(shí)施流程表級(jí)映射字段映射實(shí)體、屬性建模關(guān)聯(lián)、屬性建模SA建模需求劃分15日程為什么需要模型模型的組織結(jié)構(gòu)模型實(shí)施方法模型設(shè)計(jì)策略Q&A|日程為什么需要模型|16Hashcode問(wèn)題的提出:進(jìn)行增量加載時(shí)無(wú)法快速判斷對(duì)表的原有記錄是否新插入。例如：1.理賠案件發(fā)生的時(shí)候,增量文件會(huì)把保單數(shù)據(jù)也傳來(lái)2.保單增量過(guò)來(lái),可能只是投保人的信息改了,而目標(biāo)保單表所需信息并沒(méi)有改變解決方案：使用增量的比較字段生成Hashcode。在對(duì)表進(jìn)行增量加載時(shí)，對(duì)增量文件中的每一條記錄生成Hashcode將生成完的Hashcode與原表中同一anchorid并且最新的記錄的Hashcode進(jìn)行比較如果一致的話，即不動(dòng)作；如果不一致的話，即新插入。使用示例：在individualagreement表中使用各個(gè)需要保留歷史信息的字段生成hashcode。在增量加載時(shí)，使用業(yè)務(wù)增量文件中的字段生成hashcode。與Individualagreement表中同一agreementid的最新記錄的hashcode進(jìn)行比較。如果一致，即不動(dòng)作如果不一致，則插入新記錄。備注：relationship表是要根據(jù)業(yè)務(wù)去判斷是否關(guān)系已經(jīng)存在，然后，如果有其他屬性（如：Roleplayer-PhysicalobjectRlship.Usage），才需要用hashcode判別是否重復(fù)。|Hashcode問(wèn)題的提出:|17Hashcode字段組成規(guī)則帶anchor的實(shí)體帶status表的實(shí)體（Commercialagreement、Groupagreement、Individualagreement、Claimfolder、Elementaryclaim）除表的主鍵、typeid、Partitionkey、Status、Statusdate、Statusreason、Validfromdate、Validtodate、Effectivefromdate、Effectivetodate、Populationtimestamp之外的所有字段不帶status表的實(shí)體除表的主鍵、typeid、Partitionkey、Validfromdate、Validtodate、Effectivefromdate、Effectivetodate、Populationtimestamp之外的所有字段不帶anchor的實(shí)體原則上不需要保留歷史，一般執(zhí)行Update操作。如果有需要的，ETLMapping特別指明關(guān)聯(lián)實(shí)體對(duì)于需要保留歷史的關(guān)聯(lián)類型，除Identifier、Partitionkey、Natureid、Leftanchoridentifier、Rightanchoridentifier、Leftentityidentifier、Leftentitytypeid、Rightentityidentifier、Rightentitytypeid、Validfromdate、Validtodate、Effectivefromdate、Effectivetodate、Populationtimestamp之外的所有字段|Hashcode字段組成規(guī)則帶anchor的實(shí)體|18Partitionkey問(wèn)題的提出:在進(jìn)行多表關(guān)聯(lián)時(shí)，所涉及的關(guān)聯(lián)表行數(shù)巨大，關(guān)聯(lián)速度達(dá)不到要求。解決方案：在所有大表中建立Partitionkey,按照該鍵的鍵值對(duì)表進(jìn)行物理分區(qū)。Partitionkey從Partitionconfig表中獲得。分區(qū)策略是按照分公司進(jìn)行分區(qū)。使用示例：表A與表B進(jìn)行關(guān)聯(lián)時(shí)，如下進(jìn)行

selectA.column1,B.column2fromA,BwhereA.foreign_key=B.Primary_keyandA.partition_keyin(selectStoragepartitionfromPartitionconfigwhereBranchcompanyid=xxxx) andB.partition_keyin(selectStoragepartitionfromPartitionconfigwhereBranchcompanyid=xxxxxxx)|Partitionkey問(wèn)題的提出:|19|對(duì)保單和理賠狀態(tài)的特殊處理問(wèn)題的提出：保單在承保和保全的整個(gè)過(guò)程中狀態(tài)變化比較多，如按照IIW的原有設(shè)計(jì)，保單表中的會(huì)有巨量的歷史記錄；理賠在報(bào)案、立案和估損的整個(gè)過(guò)程中狀態(tài)變化較多，如按照IIW的原有設(shè)計(jì)，理賠表中會(huì)有很多的歷史記錄。解決方案：將保單的狀態(tài)變化過(guò)程剝離出來(lái)單獨(dú)建表，在該表中保留與保單的關(guān)聯(lián)；當(dāng)有新?tīng)顟B(tài)插入時(shí)，更新對(duì)應(yīng)的保單表中的狀態(tài)。將理賠的狀態(tài)變化過(guò)程剝離出來(lái)單獨(dú)建表，在該表中保留與理賠的關(guān)聯(lián)；當(dāng)有新?tīng)顟B(tài)插入時(shí)，更新對(duì)應(yīng)的理賠表中的狀態(tài)。使用示例：增加Commercialagreementstatus，Groupagreementstatus，Individualagreementstatus表，分別記錄Commercialagreement,Groupagreement,Individualagreement的狀態(tài)變化歷史。當(dāng)前面狀態(tài)發(fā)生該變時(shí)，在status表中插入新記錄，更新對(duì)于原表中的狀態(tài)字段。|對(duì)保單和理賠狀態(tài)的特殊處理問(wèn)題的提出：20對(duì)保單和理賠狀態(tài)的特殊處理示例|IndividualagreementIndividualagreementstatus對(duì)保單和理賠狀態(tài)的特殊處理示例|Individu21Left/RightEntityIDinRelationshiporRoleEntity問(wèn)題的提出在IIW中的不同subjectarea的實(shí)體關(guān)聯(lián)通常是走關(guān)聯(lián)實(shí)體的，例如：Physicalobject-AgreementRlship。在關(guān)聯(lián)實(shí)體中是以anchorid進(jìn)行連接的。在分析的時(shí)候，通常是應(yīng)該按照當(dāng)時(shí)的狀況進(jìn)行分析才有意義。由于EDW是保留歷史信息的，同一個(gè)Physicalobject或Agreement會(huì)有多條記錄，如何找到當(dāng)時(shí)的記錄，必須通過(guò)effectivefrom/todate的比對(duì)才能實(shí)現(xiàn)，這非常影響效率。解決方案在關(guān)聯(lián)實(shí)體中增加Left/Rightentityidentifier，Left/RightentitytypeidLeft/Rightentitytypeid是指具體基礎(chǔ)表的id號(hào)例如：Roadvehicle（2001260001）Left/Rightentityidentifier是指具體基礎(chǔ)表中記錄的主鍵id值例如：Roadvehicle中牌照號(hào)滬A－000001車輛的第一條記錄的Roadvehicleid值適用范圍：FSRolePhysicalobject-AgreementRlship|Left/RightEntityIDinRelati22SampleofLeft/RightEntityIDinRelationshiporRoleEntity|RoadvehicleIndividualagreementAgreementPhysicalobjectPhysicalobject–AgreementRlship被保標(biāo)的SampleofLeft/RightEntityID23Partyroleinoperation/Internalperson問(wèn)題的提出在業(yè)務(wù)中有很多操作員角色，只有工號(hào)、姓名信息，沒(méi)有身份證等其他信息；一個(gè)操作員在一個(gè)業(yè)務(wù)流程中會(huì)同時(shí)扮演不同角色，如在A保單核保中他是錄入人，在B保單核保中他是復(fù)核人或者可能出現(xiàn)在A保單核保中他既是錄入人又是復(fù)核人解決方案建立Internalperson表保存業(yè)務(wù)員、公司管理人員的個(gè)人信息，這些信息質(zhì)量較差建立Partyroleinoperation表保存操作員角色信息，每次都生成新記錄。錄單員冗余到保單中，理賠的操作員也冗余到claimfolder中|Roleplayer-ActivityRlshipPartyroleinoperation（Roleplayerid

）InternalPerson（Roleplayerid）FinancialServicesRolePartyroleinoperation/Intern24關(guān)聯(lián)實(shí)體的版本問(wèn)題由于關(guān)聯(lián)實(shí)體本身沒(méi)有對(duì)應(yīng)的anchor實(shí)體，不存在版本問(wèn)題，但是關(guān)聯(lián)存在有以下兩種變化情況。人“王五”擁有一棟房屋，在2007/1/1賣掉了。更新原有的Roleplayer－physicalobjectRlship記錄的

validtodate：if源系統(tǒng)有系統(tǒng)更新日期，則＝更新日期－1；else，則＝“2006/12/31” effectivetodate：＝“2006/12/31”人“王五”擁有一棟房屋，在2007/1/1賣掉50％的產(chǎn)權(quán)。更新原有的Roleplayer－physicalobjectRlship記錄的

validtodate：if源系統(tǒng)有系統(tǒng)更新日期，則＝更新日期－1；else，則＝“2006/12/31” effectivetodate：＝“2006/12/31”

（Ownershippercentage：＝100％）插入新的Roleplayer－physicalobjectRlship記錄

validfromdate：if源系統(tǒng)有系統(tǒng)更新日期，則＝更新日期－1；else，則＝“2007/1/1” effectivefromdate：＝“2007/1/1” Ownershippercentage：＝50％|關(guān)聯(lián)實(shí)體的版本問(wèn)題由于關(guān)聯(lián)實(shí)體本身沒(méi)有對(duì)應(yīng)的anchor實(shí)體25FinancialServicesRole問(wèn)題的提出Person存放人的基本信息，Externalorganisation和Internalorganisation存放機(jī)構(gòu)的基本信息一個(gè)人和機(jī)構(gòu)在不同環(huán)境下分別扮演不同角色，所以FinancialServicesRole存放與保單（各種協(xié)議）相關(guān)的金融服務(wù)角色，如保單持有人，被保險(xiǎn)人，受益人等。Channelrole存放中介渠道角色信息，如營(yíng)銷員、收展員在分析集市中需要獲取保單與業(yè)務(wù)員的關(guān)聯(lián)信息，IIW原連接方式如圖：|FinancialServicesRole（Financialservicesroleplayerid）Person（Roleplayerid）Channelrole（Channelroleplayerid）優(yōu)點(diǎn)：結(jié)構(gòu)清晰統(tǒng)一缺點(diǎn)：渠道角色信息關(guān)聯(lián)的太遠(yuǎn)，需要FinancialServicesRole+Channelrole+Person，影響效率

Person（Roleplayerid）Externalorganisation（Roleplayerid）FinancialServicesRole問(wèn)題的提出26FinancialServicesRole解決方案FinancialServicesRole用把basisroleplayertypeid確定應(yīng)連接Person還是ExternalorganisationFinancialServicesRole用把basisroleplayerid確定Person或Externalorganisation中記錄的roleplayeridFinancialServicesRole用把basisroleplayerentityidentifier確定Person或Externalorganisation中記錄的personid或Externalorganisationid使用示例|FinancialServicesRole（Financialservicesroleplayerid）Person（Roleplayerid）Channelrole（RoleplayeridChannelroleplayerid）Person（Roleplayerid）Externalorganisation（Roleplayerid）FinancialServicesRole解決方案|27Currencycode問(wèn)題的提出：在CPIC的實(shí)際業(yè)務(wù)中，可能出現(xiàn)多幣種，在統(tǒng)計(jì)中需要進(jìn)行多幣種的轉(zhuǎn)換。解決方案：在IIW模型中凡出現(xiàn)金額字段的表，都增加金額的幣種及對(duì)應(yīng)的RMB金額兩類字段。原字段存放原幣中金額，RMB金額存放折算成RMB的金額使用示例：Elementaryclaim表中增加Totalcostcurrency和TotalcostRMB字段備注：由于CPIC對(duì)多幣種金額的統(tǒng)計(jì)有多種統(tǒng)計(jì)方式，不全部是按照發(fā)生制來(lái)折算RMB的。因此，統(tǒng)計(jì)轉(zhuǎn)換金額到RMB的工作，留給統(tǒng)計(jì)部分執(zhí)行，在原子層不計(jì)算。幣種一定要填。|Currencycode問(wèn)題的提出：|28維度表的snapshot問(wèn)題的提出在分析層中，常用的維度表如：保單、立案。分析常用的屬性是分散在各個(gè)表中的，如：保費(fèi)、保額在ParticularMoneyProvision中。分析時(shí)如果再通過(guò)關(guān)聯(lián)來(lái)找到這些信息，效率非常低。解決方案建立維度的snapshot表，將這些信息冗余存放在這些表中，每個(gè)月全量刷新一次。使用示例：ClaimfolderdimensionPolicydimensionElementaryclaimdimensionEventdimension|維度表的snapshot問(wèn)題的提出|29Commercialagreement/Groupagreement/Individualagreement的邊界區(qū)分Commercialagreement存放保險(xiǎn)公司和機(jī)構(gòu)投保人簽訂的關(guān)于承保要素約束的框架性協(xié)議；不是具體的保單。具體的保單要遵循該協(xié)議。Groupagreement團(tuán)單單位和保險(xiǎn)公司簽訂的保一組成員的保單，如：壽險(xiǎn)團(tuán)單、雇主責(zé)任險(xiǎn)、旅游責(zé)任險(xiǎn)。如果源系統(tǒng)提供了每個(gè)被保人的投保情況，這些記錄在individualagreement（typeid＝個(gè)人憑證）中的。如：雇主責(zé)任險(xiǎn)下每個(gè)人的投保份數(shù)。Individualagreement個(gè)單/個(gè)人憑證備注：根據(jù)國(guó)內(nèi)系統(tǒng)的情況做了些調(diào)整，和機(jī)構(gòu)投保人（非個(gè)人）簽訂的個(gè)單也存放在此。投保單按保單處理，只是狀態(tài)是投保狀態(tài)|Commercialagreement/Groupagr30Groupagreement/Individualagreement在ETL時(shí)處理車險(xiǎn)系統(tǒng)保單進(jìn)入Individualagreement壽險(xiǎn)保單根據(jù)來(lái)源表，決定進(jìn)入groupagreement還是individualagreementCIBS(包括老系統(tǒng))和人意險(xiǎn)保單根據(jù)Financialservicesproduct中的Individualinsuranceflag判斷個(gè)險(xiǎn)，進(jìn)入Individualagreement團(tuán)險(xiǎn)、個(gè)團(tuán)皆可，進(jìn)入groupagreement|Groupagreement/Individualagr31最新記錄標(biāo)志Effectivetodate=‘9999/12/3100:00:00’|最新記錄標(biāo)志Effectivetodate=‘99932公司的拆分合并，partitionkey的處理–1/4分公司的拆分合并，不需要程序考慮，發(fā)生后手工處理。公司合并舉例：原來(lái)有分公司A,分公司B,在2006/1/1分公司B合并到分公司A。|合并前PartitionconfigExternalorganisationIndividualagreement公司的拆分合并，partitionkey的處理–1/433公司的拆分合并，partitionkey的處理–2/4公司合并舉例：原來(lái)有分公司A,分公司B,在2006/1/1分公司B合并到分公司A。|合并后PartitionconfigExternalorganisationIndividualagreementRoleplayerRlship公司的拆分合并，partitionkey的處理–2/434公司的拆分合并，partitionkey的處理–3/4公司合并舉例：原來(lái)有分公司A,在2006/1/1分公司A,拆分成分公司A和分公司B。|拆分前PartitionconfigExternalorganisationIndividualagreement公司的拆分合并，partitionkey的處理–3/435公司的拆分合并，partitionkey的處理–4/4公司合并舉例：原來(lái)有分公司A,在2006/1/1分公司A,拆分成分公司A和分公司B。|拆分后PartitionconfigExternalorganisationIndividualagreementRoleplayerRlship公司的拆分合并，partitionkey的處理–4/436按照typeid分表將有些大表按照Typeid進(jìn)行拆分舉例：Individualagreement表按照保單和投保單拆成兩張表|按照typeid分表將有些大表按照Typeid進(jìn)行拆37歷史信息的處理對(duì)含有歷史記錄的大表，應(yīng)考慮將歷史記錄剝離出來(lái)單獨(dú)建表，即原表保留最新的信息，而在剝離出來(lái)的表中包含這些信息的變化歷史。舉例：

Individualagreement原來(lái)保留有保單的最新信息及這些信息的歷史變化記錄。這樣這張表就將很大，記錄數(shù)數(shù)以億計(jì)。目前將它拆成2個(gè)表：表一，存放保單的最新信息，如最新?tīng)顟B(tài)，最新確認(rèn)的起保日期等，同時(shí)保留每條記錄最新的刷新時(shí)間表二，存放保單經(jīng)常變化的值的變化歷史，如：保單狀態(tài)的變化歷史表三，存放保單所有歷史變化的信息|歷史信息的處理對(duì)含有歷史記錄的大表，應(yīng)考慮將歷史記錄剝離出來(lái)38增加表的冗余字段問(wèn)題的提出：原有設(shè)計(jì)中，一條業(yè)務(wù)上具有完整意義的信息被拆分在多個(gè)表中，在生成分析層（或進(jìn)行分析時(shí)）又要將被拆分的信息通過(guò)多表關(guān)聯(lián)的方式關(guān)聯(lián)起來(lái)。解決方案：在表中盡量增加冗余字段。要注意的是，冗余字段并非任意增加，而是要增加：冗余關(guān)聯(lián)類型為m:1的字段，如：保單的所屬分公司。從業(yè)務(wù)上說(shuō)，基本不變化的冗余字段|增加表的冗余字段問(wèn)題的提出：原有設(shè)計(jì)中，一條業(yè)務(wù)上具有完整意39增加表與表之間的外鍵，減少走關(guān)聯(lián)表問(wèn)題的提出：原有設(shè)計(jì)中，一條業(yè)務(wù)上具有完整意義的信息被拆分在多個(gè)表中，在生成分析層（或進(jìn)行分析時(shí)）又要將被拆分的信息通過(guò)多表關(guān)聯(lián)的方式關(guān)聯(lián)起來(lái)。而這樣的關(guān)聯(lián)可能要跨多個(gè)表。解決方案：增加有業(yè)務(wù)含義的信息之間的直接關(guān)聯(lián)。即如兩表的信息如果有業(yè)務(wù)關(guān)聯(lián)，而在原有設(shè)計(jì)中這兩表之間的關(guān)聯(lián)要借助其他中間表的，應(yīng)在此兩表之間建立直接的關(guān)聯(lián)。例如：sellingchannelroleid在individualagreement表中的冗余。否則，要走FSRole連接channelrole。盡可能減少關(guān)聯(lián)的層級(jí)。即減少不必要的關(guān)聯(lián)中間表例如：如保單的操作員直接建立到保單中，保單和理賠的科室、部門直接建立到保單和理賠中。備注：m:m的關(guān)系必須走關(guān)聯(lián)表。|增加表與表之間的外鍵，減少走關(guān)聯(lián)表問(wèn)題的提出：原有設(shè)計(jì)中，一40模型優(yōu)化任務(wù)分配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,|模型優(yōu)化任務(wù)分配Jeffrey:Activity,Rei41EDW和ODS的關(guān)系Person、Externalorganisation、FSRole（投保人/被保人）通過(guò)ODS產(chǎn)生由于加載順序的關(guān)系，保單表由業(yè)務(wù)系統(tǒng)產(chǎn)生，產(chǎn)生保單信息時(shí)，ODS數(shù)據(jù)還沒(méi)有加載。因此，Individualagreement中的Policyholderid、Groupagreement中的Policyholderorganisationid不冗余產(chǎn)生，而是通過(guò)FSRole走。|EDW和ODS的關(guān)系Person、Externalorga42Id產(chǎn)生規(guī)則每個(gè)表單獨(dú)使用id序列建id序列表|Id產(chǎn)生規(guī)則每個(gè)表單獨(dú)使用id序列|43Anchor表是否需要物理產(chǎn)生建物理產(chǎn)生Anchor表所有和Anchor直接外鍵關(guān)聯(lián)的typeid冗余|Anchor表是否需要物理產(chǎn)生建物理產(chǎn)生Anchor表|44Person歸并決策Person，externalorganisation在EDW不再進(jìn)行歸并|Person歸并決策Person，externalorga45Boolean0false1true|Boolean0false|46AtomicderiveddataAtomic層表中，有部分字段保存的是從其他表或字段中導(dǎo)出的數(shù)據(jù)，如：claimfolder中totalcost，是從internalclaimcost中統(tǒng)計(jì)來(lái)的。對(duì)于這部分字段，分為兩部分：目前analytical層或datamart用到的，需要處理暫時(shí)沒(méi)用的字段，暫不處理這部分字段的處理，在atomic產(chǎn)生完成后，產(chǎn)生analytical層前處理。|AtomicAnalytical12AtomicderiveddataAtomic層表中，有47物理分表SubjectareaEntity分表ActivityParticularactivity治療2000060002:PA_Medicaltreat

查勘2000060004/回勘2000060005:PA_InvestigationAgreementCoveragecomponentCoveragecomponenthistoryIndividualagreementIndividualagreementhistoryClaimClaimfolder報(bào)案2000360001：CF_Reportcase

立案案卷2000360002：CF_files

賠案2000360004/追償賠案2000360005:CF_indemnityMoneyprovisionMoneyschedulerMoneyin:Moneyinscheduler

Moneyout:Moneyoutscheduler

Moneyscheduler在物理層不使用Particularmoneyprovision保額:PMPinsuredamount保費(fèi):PMPpremiumPartyFinancialservicesrole2000660002投保人:FSRapplicator

2000660003被保人:FSRInsuredPaymentPayment保費(fèi)來(lái)源的：Premiumpayment賠款來(lái)源的：ClaimpaymentPaymentdue保費(fèi)來(lái)源:Premiumpaymentdue賠款來(lái)源:ClaimpaymentduePhysicalobjectOtherphysicalobjectGeneralcargo2000850001：Cargo

Machineitem2000850004：MachineStructureDwelling2000890001：Dwelling

Hotel2000890003:Hotel

Platform2000890004:Platform|備注：沒(méi)特別注明的其他類型的在原Entity中物理分表SubjectareaEntity分表Activi48MoneyschedulerMoneyinscheduler用于連接對(duì)于保險(xiǎn)公司來(lái)說(shuō)是進(jìn)來(lái)的錢的particularmoneyprovision/Financialtransaction，如：保費(fèi)、儲(chǔ)金（包括批增、批減）Moneyoutscheduler用于連接對(duì)于保險(xiǎn)公司來(lái)說(shuō)是出去的錢的particularmoneyprovision/Financialtransaction，如：賠款、支付的養(yǎng)老金（包括攤回賠款）每個(gè)保單簽單產(chǎn)生一個(gè)Moneyinscheduler，保單不含批單的保額、保費(fèi)掛在該Moneyinscheduler下；每個(gè)批單單產(chǎn)生一個(gè)Moneyinscheduler，該批單對(duì)應(yīng)的保額、保費(fèi)變化掛在該Moneyinscheduler下。每個(gè)賠案產(chǎn)生一個(gè)Moneyoutscheduler，該賠案對(duì)應(yīng)的Particularmoneyprovision掛在該Moneyoutscheduler下。|MoneyschedulerMoneyinschedu49關(guān)聯(lián)表冗余進(jìn)實(shí)體表中－1/2SubjectareaEntity加字段備注ActivityActivity-PlaceRlshipclaimfolder.報(bào)案地點(diǎn)Activity-PlaceRlship.Nature_id=報(bào)案地點(diǎn)2000030003直接挪到claimfolder中ActivityActivity-PlaceRlshipParticularactivity.活動(dòng)地點(diǎn)Activity-PlaceRlship.Nature_id=

查勘地點(diǎn)2000030004

工程作業(yè)地域2000030005

建造地點(diǎn)2000030006

交船地點(diǎn)2000030007

直接挪到Particularactivity.活動(dòng)地點(diǎn)ActivityActivity-PlaceRlshipTransportation.啟運(yùn)港/Transportation.中轉(zhuǎn)港1/Transportation.中轉(zhuǎn)港2/Transportation.目的地Activity-PlaceRlship.Nature_id=

啟運(yùn)港2000030008

中轉(zhuǎn)港2000030009

直接挪到Transportation.啟運(yùn)港/Transportation.中轉(zhuǎn)港

加代碼字段和名稱字段

如果有超過(guò)2個(gè)的中轉(zhuǎn)港，則走原有關(guān)聯(lián)表ActivityClaimcheckOperationroleplayerid執(zhí)行人ActivityClaimcheckReviewroleplayerid復(fù)核/審核人ActivityUnderwritigcheckOperationroleplayerid執(zhí)行人ActivityUnderwritigcheckReviewroleplayerid復(fù)核/審核人AgreementChangerequestOperationroleplayerid操作員代碼AgreementGroupagreementOperationroleplayerid原通過(guò)Financialservicerole關(guān)聯(lián)保單和Partyroleinoperation,現(xiàn)在直接將操作員id冗余進(jìn)Groupagreement表中AgreementGroupagreementDepartmentid保單部門，原先必須通過(guò)與Party主題關(guān)聯(lián)得到，現(xiàn)在增加冗余|關(guān)聯(lián)表冗余進(jìn)實(shí)體表中－1/2SubjectareaEnt50關(guān)聯(lián)表冗余進(jìn)實(shí)體表中－2/2SubjectareaEntity加字段備注AgreementGroupagreementSectionid科室代碼，原先必須通過(guò)與Party主題關(guān)聯(lián)得到，現(xiàn)在增加冗余AgreementIndividualagreementOperationroleplayerid原通過(guò)Financialservicerole關(guān)聯(lián)保單和Partyroleinoperation,現(xiàn)在直接將操作員id冗余進(jìn)Individualagreement表中AgreementIndividualagreementDepartmentid保單部門，原先必須通過(guò)與Party主題關(guān)聯(lián)得到，現(xiàn)在增加冗余AgreementIndividualagreementSectionid科室代碼，原先必須通過(guò)與Party主題關(guān)聯(lián)得到，現(xiàn)在增加冗余AgreementIndividualagreementCommercialagreementid到commercialagreement的直接關(guān)聯(lián)FinancialtransactionPaymentAgreementrequestid批單號(hào)FinancialtransactionPaymentAgreementrequesttypeid批單表typeid類型FinancialtransactionPaymentdueAgreementrequestid批單號(hào)FinancialtransactionPaymentdueAgreementrequesttypeid批單表typeid類型PaymentPaymentPayment.Agreementid協(xié)議號(hào)PaymentPaymentPayment.Agreementtypeid協(xié)議類型PaymentPaymentduePaymentdue.Agreementid協(xié)議號(hào)PaymentPaymentduePaymentdue.Agreementtypeid協(xié)議類型PhysicalobjectPhysicalobject-Registrationrlshipship.船籍(代碼)船籍2000790001|關(guān)聯(lián)表冗余進(jìn)實(shí)體表中－2/2SubjectareaEnt51Anchor的typeid冗余到外鍵關(guān)聯(lián)的表中-1/2AnchorEntity新增冗余字段AccountaccountentryaccounttypeidActivityMarketingobjectiveMarketingactivitytypeidActivityParticularmoneyprovisionactivitytypeidAgreementFinancialservicesroleContextfinancialservicesagreementtypeidAgreementStatementelementAgreementtypeidAgreementMoneyschedulerAgreementtypeidAgreementGenericmoneyprovisionAgreementtypeidAgreementParticularmoneyprovisionAgreementtypeidAgreementReinsurancefinancialentryAgreementtypeidAgreementReinsurancepremiumdetailAgreementtypeidAgreementClaimindemnitydetailAgreementtypeidClaimPartyroleinclaimContextclaimtypeidClaimClaimindemnitydetailClaimfolderanchortypeidClaimReinsuranceindemnitydetailClaimfolderanchortypeid|Anchor的typeid冗余到外鍵關(guān)聯(lián)的表中-1/2A52Anchor的typeid冗余到外鍵關(guān)聯(lián)的表中-2/2AnchorEntity新增冗余字段ClaimClaimindemnitydetailElementaryclaimanchortypeidClaimReinsuranceindemnitydetailElementaryclaimanchortypeidPartyAccountproviderAccountproviderroleplayertypeidPartyChannelroleplayeridChannelroleplayertypeidPartyCustomerCustomerroleplayertypeidPartyEmploymentroleEmploymentroleplayertypeidPartyFinancialservicesroleFinancialservicesroleplayertypeidPartyPartyroleinagreementrequestRequestpartyroleplayertypeidPartyPartyroleinclaimClaimpartyroleplayertypeidPartyPartyroleinlegalactionLegalactionpartyroleplayertypeidPartyProviderroleProviderroleplayertypeidPartyParticularmoneyprovisionMoneypayeetypeidPartyParticularmoneyprovisionMoneypayertypeidPhysicalobjectMarketableobjectTradeablephysicalobjecttypeid|Anchor的typeid冗余到外鍵關(guān)聯(lián)的表中-2/2A53Claim中涉及的各種金額存放規(guī)則－1/2|Claim中涉及的各種金額存放規(guī)則－1/2|54Claim中涉及的各種金額存放規(guī)則－2/2Particularmoneyprovision對(duì)應(yīng)賠案級(jí)，其中不存放金額，起關(guān)聯(lián)作用（Agreementid，Agreementtypeid，Moneyschedulerid，（Moneypayeeid，Moneypayeetypeid，Moneypayerid，Moneypayertypeid有則產(chǎn)生））。Moneyscheduler一個(gè)賠案產(chǎn)生一條記錄，該賠案下的Particularmoneyprovision都掛在這個(gè)Moneyscheduler下。Claimoffer可以存放多種offer，可以為服務(wù)、物品或金錢（包括狀態(tài)是未決的）Internalclaimcost用于存放理算后的公司內(nèi)部發(fā)生的各種理賠費(fèi)用，如查勘費(fèi)、施救費(fèi)、律師費(fèi)等。Internalclaimcost通過(guò)Internalclaimcost-ClaimRlship與claimfolder關(guān)聯(lián)查勘表中記錄的明細(xì)費(fèi)用（如查勘費(fèi)、施救費(fèi)、律師費(fèi)等）放在Moneyprovisionpart，通過(guò)Moneyprovisioncashflow到Particularmoneyprovision中的activityid連接到查勘活動(dòng)中Moneyprovisionpart用于存放賠給客戶的賠款明細(xì)(包括狀態(tài)是未決的)、到賠付項(xiàng)目代碼級(jí)別。Moneyprovisioncashflow用于存放子險(xiǎn)級(jí)合計(jì)的賠款金額,和claimoffer對(duì)應(yīng)放在Moneyprovisioncashflow和Moneyprovisionpart中賠款的錢金額變化、Moneyprovisioncashflow/Moneyprovisionpart中賠款金額不保留版本，當(dāng)出現(xiàn)修改時(shí)直接修改這些表中的記錄ClaimOffer中的賠款金額不保留歷史，將來(lái)如果業(yè)務(wù)需要，再做保留歷史處理立案的估損/定損都放在Financialvaluation中估損/定損明細(xì)單獨(dú)建表|Claim中涉及的各種金額存放規(guī)則－2/2Particul55核保核賠在EDW模型中的處理核保核賠本身是一個(gè)工作流程的活動(dòng)，每個(gè)核保核賠又細(xì)分成不同的步驟，如：收集單證，復(fù)核等活動(dòng)步驟。類似于IIW中的campaign，campaigncell和campaignstep的關(guān)系。在EDW中產(chǎn)險(xiǎn)使用underwritingcheck/claimcheck來(lái)存放核保核賠信息，主活動(dòng)和活動(dòng)步驟通過(guò)不同的type來(lái)區(qū)分。主活動(dòng)和活動(dòng)步驟通過(guò)underwritingcheck/claimcheck的自關(guān)聯(lián)實(shí)現(xiàn)。每個(gè)主活動(dòng)只需要保留一條記錄，有變化update；因?yàn)槊總€(gè)具體的步驟包括了該活動(dòng)變化的信息。對(duì)于一個(gè)投保單多次核保的情況，每個(gè)核保一個(gè)主活動(dòng)。|核保核賠在EDW模型中的處理核保核賠本身是一個(gè)工作流程的活動(dòng)56投保單/協(xié)議申請(qǐng)單的處理以下投保單指：投保單或協(xié)議申請(qǐng)單投保單作為保單的一個(gè)歷史狀態(tài)處理。全量數(shù)據(jù)：即使投保單已成為保單，也要插入一條投保單的記錄。Validfromdate＝錄入日期，validtodate＝簽單日期。Effectivefromdate＝投保日期（如果沒(méi)有投保日期，同validfromdate），Effectivetodate＝簽單日期。如果該投保單記錄的目標(biāo)表是individualagreement，則投保單的記錄直接插入individualagreementhistory。如果投保單還沒(méi)有成為保單，投保單的Validfromdate＝錄入日期，validtodate＝9999/12/31。Effectivefromdate＝投保日期（如果沒(méi)有投保日期，同validfromdate），Effectivetodate＝9999/12/31。增量數(shù)據(jù)：如果投保單已經(jīng)變?yōu)楸瘟耍妥鳛楸蔚臍v史記錄，新插入保單的記錄，如果目標(biāo)表是individualagreement，則投保單的記錄挪到individualagreementhistory中。如果目標(biāo)表是不是individualagreement，則投保單的記錄仍然在原表中。如：groupagreement，commercialagreement。投保單和保單共用同一個(gè)agreementid，typeid分別為投保單、保單（團(tuán)單，個(gè)單，個(gè)單憑證等）。投保單只保持一條記錄，最新?tīng)顩rupdate該記錄。備注：如果將來(lái)投保單數(shù)據(jù)太多，影響執(zhí)行效率，由其他程序定期執(zhí)行歸檔處理，將已成為保單的n年前的投保單數(shù)據(jù)歸檔。有的系統(tǒng)投保單和保單是同一條記錄，有的系統(tǒng)投保單和保單是不同條記錄。在EDW中必須保持一致的處理方式。|投保單/協(xié)議申請(qǐng)單的處理以下投保單指：投保單或協(xié)議申請(qǐng)單57批改申請(qǐng)單的處理批改不記錄歷史，因此，批改申請(qǐng)和批改使用同一條記錄，有改變直接Update該記錄。在changerequest中新增一個(gè)字段存放批改申請(qǐng)?zhí)枴批改申請(qǐng)單的處理批改不記錄歷史，因此，批改申請(qǐng)和批改使用同一58日程為什么需要模型模型的組織結(jié)構(gòu)模型實(shí)施方法模型設(shè)計(jì)策略Q&A|日程為什么需要模型|59日程Thankyou!|日程Thankyou!|60BI.Insurancei.DWMforP&C

模型設(shè)計(jì)說(shuō)明BI.Insurancei.DWMforP&C模型設(shè)61日程為什么需要模型模型的組織結(jié)構(gòu)模型實(shí)施方法模型設(shè)計(jì)策略Q&A|日程為什么需要模型|62日程為什么需要模型模型的組織結(jié)構(gòu)模型實(shí)施方法模型設(shè)計(jì)策略Q&A|日程為什么需要模型|63EDW體系架構(gòu)源系統(tǒng)層ETL層數(shù)據(jù)倉(cāng)庫(kù)層ETL層數(shù)據(jù)集市層應(yīng)用層展現(xiàn)層手工數(shù)據(jù)外部數(shù)據(jù)數(shù)據(jù)倉(cāng)庫(kù)保險(xiǎn)數(shù)據(jù)模型核心業(yè)務(wù)財(cái)務(wù)系統(tǒng)再保險(xiǎn)系統(tǒng)人意險(xiǎn)系統(tǒng)精算系統(tǒng)客戶關(guān)系管理OCRM客戶訊息ECIF業(yè)務(wù)量分析數(shù)據(jù)集市業(yè)務(wù)持續(xù)性分析數(shù)據(jù)集市ALM數(shù)據(jù)集市財(cái)務(wù)分析數(shù)據(jù)集市車險(xiǎn)承保分析通用承保分析風(fēng)險(xiǎn)管理應(yīng)用ALM應(yīng)用財(cái)務(wù)分析應(yīng)用aCRM數(shù)據(jù)集市aCRM報(bào)告大客戶分析管理系統(tǒng)aCRM引擎數(shù)據(jù)挖掘引擎數(shù)據(jù)挖掘應(yīng)用企業(yè)信息門戶企業(yè)統(tǒng)一分析平臺(tái)元數(shù)據(jù)庫(kù)監(jiān)管報(bào)表管理報(bào)表運(yùn)營(yíng)報(bào)表儀表盤隨機(jī)查詢多維分析“數(shù)據(jù)和信息集成平臺(tái)”“統(tǒng)一的分析平臺(tái)”“唯一的信息出口”EDW體系架構(gòu)源系統(tǒng)層ETL層數(shù)據(jù)倉(cāng)庫(kù)層ETL層數(shù)據(jù)集市層應(yīng)64為什么需要企業(yè)模型？數(shù)據(jù)集市之間數(shù)據(jù)一致性包含全部歷史的核心數(shù)據(jù)一致的事實(shí)表和維度為什么需要企業(yè)模型？數(shù)據(jù)集市之間數(shù)據(jù)一致性包含全部歷史的核心65EDW數(shù)據(jù)模型在項(xiàng)目實(shí)施中的作用DWM數(shù)據(jù)倉(cāng)庫(kù)模型BAM業(yè)務(wù)分析模型運(yùn)營(yíng)型業(yè)務(wù)系統(tǒng)數(shù)據(jù)倉(cāng)庫(kù)數(shù)據(jù)集市報(bào)表分析型應(yīng)用XMLFileFlatFileInformixOracleSQLDB2BSA業(yè)務(wù)模版應(yīng)用EDW數(shù)據(jù)模型在項(xiàng)目實(shí)施中的作用DWMBAM運(yùn)營(yíng)型業(yè)務(wù)系66日程為什么需要模型模型的組織結(jié)構(gòu)模型實(shí)施方法模型設(shè)計(jì)策略Q&A|日程為什么需要模型|67模型總體結(jié)構(gòu)－EM&DataMarts核心原子數(shù)據(jù)事實(shí)表和維度企業(yè)模型營(yíng)銷管理快速入門客戶細(xì)分和管理保險(xiǎn)盈利性分析潛在客戶管理數(shù)據(jù)集市導(dǎo)出業(yè)務(wù)數(shù)據(jù)模型映射指標(biāo)要素需求模型財(cái)務(wù)報(bào)表數(shù)據(jù)集市中介績(jī)效分析數(shù)據(jù)集市健康險(xiǎn)盈利性管理數(shù)據(jù)集市模型總體結(jié)構(gòu)－EM&DataMarts核心原子數(shù)據(jù)事實(shí)表68DWM數(shù)據(jù)模型邏輯結(jié)構(gòu)當(dāng)事人營(yíng)銷和溝通組織產(chǎn)品協(xié)議保險(xiǎn)標(biāo)的交易渠道資源與理賠相關(guān)的活動(dòng)及各理賠環(huán)節(jié)理賠保險(xiǎn)公司的有形資產(chǎn)和無(wú)形資產(chǎn)信息與客戶之間資金或非資金活動(dòng)的信息與客戶交易或接觸的渠道信息任何市場(chǎng)化的產(chǎn)品或服務(wù)和客戶之間為某種產(chǎn)品或服務(wù)而設(shè)定的協(xié)議信息被保險(xiǎn)的標(biāo)的物及標(biāo)的物的相關(guān)信息個(gè)人或團(tuán)體及其基本信息和相關(guān)信息為增加客戶、保留客戶、拓展業(yè)務(wù)而進(jìn)行的策略、規(guī)劃或促銷事件分支機(jī)構(gòu)、部門和職員的信息地理區(qū)域，物理的或電子的地址信息地理位置與當(dāng)事人或協(xié)議相關(guān)的一系列事件事件DWM數(shù)據(jù)模型邏輯結(jié)構(gòu)當(dāng)事人營(yíng)銷和溝通組織產(chǎn)品協(xié)議保險(xiǎn)標(biāo)的69BI.Insurancei.DWMforP&C底層數(shù)據(jù)模型主題域說(shuō)明：Agreement：保單、批單申請(qǐng)及管理；Claim：理賠FinancialTransaction：應(yīng)收應(yīng)付、實(shí)收實(shí)付以及交易關(guān)聯(lián)Party：當(dāng)事方，包括當(dāng)事方的組織結(jié)構(gòu)、角色結(jié)構(gòu)及類型MoneyProvision：資金管理SpecificationAndProduct：規(guī)范及產(chǎn)品管理Place：地點(diǎn)Code：標(biāo)準(zhǔn)代碼Activity：活動(dòng)管理PhysicalObject：實(shí)物、標(biāo)的管理BI.Insurancei.DWMforP&C底層數(shù)據(jù)70BI.Insurancei.DWM-AgreementBI.Insurancei.DWM-Agreement71BI.Insurancei.DWM-ClaimBI.Insurancei.DWM-Claim72BI.Insurancei.DWM-PhysicalObjectBI.Insurancei.DWM-PhysicalOb73日程為什么需要模型模型的組織結(jié)構(gòu)模型實(shí)施方法模型設(shè)計(jì)策略Q&A|日程為什么需要模型|74表級(jí)映射字段映射實(shí)體、屬性建模關(guān)聯(lián)、屬性建模SA建模需求劃分多維建模使用模型、產(chǎn)生報(bào)表需求收集數(shù)據(jù)分析模型映射數(shù)據(jù)建模ETL前端提供需求及模版客戶提供需求需求整理步驟：流程：產(chǎn)出：原則：需求文檔：1.報(bào)表需求2.功能需求3.非功能需求1.目前的報(bào)表2.想做的報(bào)表3.想做的功能1.數(shù)據(jù)篩選清單2.數(shù)據(jù)源報(bào)告：3.數(shù)據(jù)質(zhì)量分析報(bào)告4.代碼清單Mapping文檔：源-模型對(duì)應(yīng)關(guān)系A(chǔ)篩選：去掉ETL需要而模型不需要的字段1.邏輯模型2.物理模型3

邏輯物理數(shù)據(jù)元素對(duì)照表設(shè)計(jì)文檔：1.Mapping流程圖2.數(shù)據(jù)元素Mapping文檔A：數(shù)據(jù)源報(bào)告：1.主要功能2.歷史數(shù)據(jù)情況3.與其它系統(tǒng)關(guān)系4.聯(lián)系人B：數(shù)據(jù)質(zhì)量報(bào)告：1.數(shù)據(jù)類型2.值分布3.關(guān)聯(lián)情況數(shù)據(jù)調(diào)查數(shù)據(jù)質(zhì)量分析代碼整理數(shù)據(jù)篩選B映射：1.映射到EM2.結(jié)合性能考慮3.結(jié)合實(shí)現(xiàn)考慮數(shù)據(jù)篩選：1.程序控制,計(jì)算,通訊,安全控制配置,日志2.匯總類結(jié)果一般不要3.可以由其它字段算出的字段一般不要4.從其它系統(tǒng)導(dǎo)入的數(shù)據(jù)不要.5.代碼表不要。6.單純的險(xiǎn)種定義信息不要，但是具體保單中涉及的險(xiǎn)種定義信息可以要。Mapping設(shè)計(jì)Mapping程序開(kāi)發(fā)測(cè)試數(shù)據(jù)加載1.多維模型設(shè)計(jì)文檔：維度指標(biāo)派生指標(biāo)2.需求-模型映射文檔3.報(bào)表樣張4.操作說(shuō)明數(shù)據(jù)篩選：1.表一級(jí)篩選2.字段級(jí)篩選數(shù)據(jù)篩選：1.模型的數(shù)據(jù)篩選2.ETL映射數(shù)據(jù)篩選EDW具體實(shí)施流程表級(jí)映射字段映射實(shí)體、屬性建模關(guān)聯(lián)、屬性建模SA建模需求劃分75日程為什么需要模型模型的組織結(jié)構(gòu)模型實(shí)施方法模型設(shè)計(jì)策略Q&A|日程為什么需要模型|76Hashcode問(wèn)題的提出:進(jìn)行增量加載時(shí)無(wú)法快速判斷對(duì)表的原有記錄是否新插入。例如：1.理賠案件發(fā)生的時(shí)候,增量文件會(huì)把保單數(shù)據(jù)也傳來(lái)2.保單增量過(guò)來(lái),可能只是投保人的信息改了,而目標(biāo)保單表所需信息并沒(méi)有改變解決方案：使用增量的比較字段生成Hashcode。在對(duì)表進(jìn)行增量加載時(shí)，對(duì)增量文件中的每一條記錄生成Hashcode將生成完的Hashcode與原表中同一anchorid并且最新的記錄的Hashcode進(jìn)行比較如果一致的話，即不動(dòng)作；如果不一致的話，即新插入。使用示例：在individualagreement表中使用各個(gè)需要保留歷史信息的字段生成hashcode。在增量加載時(shí)，使用業(yè)務(wù)增量文件中的字段生成hashcode。與Individualagreement表中同一agreementid的最新記錄的hashcode進(jìn)行比較。如果一致，即不動(dòng)作如果不一致，則插入新記錄。備注：relationship表是要根據(jù)業(yè)務(wù)去判斷是否關(guān)系已經(jīng)存在，然后，如果有其他屬性（如：Roleplayer-PhysicalobjectRlship.Usage），才需要用hashcode判別是否重復(fù)。|Hashcode問(wèn)題的提出:|77Hashcode字段組成規(guī)則帶anchor的實(shí)體帶status表的實(shí)體（Commercialagreement、Groupagreement、Individualagreement、Claimfolder、Elementaryclaim）除表的主鍵、typeid、Partitionkey、Status、Statusdate、Statusreason、Validfromdate、Validtodate、Effectivefromdate、Effectivetodate、Populationtimestamp之外的所有字段不帶status表的實(shí)體除表的主鍵、typeid、Partitionkey、Validfromdate、Validtodate、Effectivefromdate、Effectivetodate、Populationtimestamp之外的所有字段不帶anchor的實(shí)體原則上不需要保留歷史，一般執(zhí)行Update操作。如果有需要的，ETLMapping特別指明關(guān)聯(lián)實(shí)體對(duì)于需要保留歷史的關(guān)聯(lián)類型，除Identifier、Partitionkey、Natureid、Leftanchoridentifier、Rightanchoridentifier、Leftentityidentifier、Leftentitytypeid、Rightentityidentifier、Rightentitytypeid、Validfromdate、Validtodate、Effectivefromdate、Effectivetodate、Populationtimestamp之外的所有字段|Hashcode字段組成規(guī)則帶anchor的實(shí)體|78Partitionkey問(wèn)題的提出:在進(jìn)行多表關(guān)聯(lián)時(shí)，所涉及的關(guān)聯(lián)表行數(shù)巨大，關(guān)聯(lián)速度達(dá)不到要求。解決方案：在所有大表中建立Partitionkey,按照該鍵的鍵值對(duì)表進(jìn)行物理分區(qū)。Partitionkey從Partitionconfig表中獲得。分區(qū)策略是按照分公司進(jìn)行分區(qū)。使用示例：表A與表B進(jìn)行關(guān)聯(lián)時(shí)，如下進(jìn)行

selectA.column1,B.column2fromA,BwhereA.foreign_key=B.Primary_keyandA.partition_keyin(selectStoragepartitionfromPartitionconfigwhereBranchcompanyid=xxxx) andB.partition_keyin(selectStoragepartitionfromPartitionconfigwhereBranchcompanyid=xxxxxxx)|Partitionkey問(wèn)題的提出:|79|對(duì)保單和理賠狀態(tài)的特殊處理問(wèn)題的提出：保單在承保和保全的整個(gè)過(guò)程中狀態(tài)變化比較多，如按照IIW的原有設(shè)計(jì)，保單表中的會(huì)有巨量的歷史記錄；理賠在報(bào)案、立案和估損的整個(gè)過(guò)程中狀態(tài)變化較多，如按照IIW的原有設(shè)計(jì)，理賠表中會(huì)有很多的歷史記錄。解決方案：將保單的狀態(tài)變化過(guò)程剝離出來(lái)單獨(dú)建表，在該表中保留與保單的關(guān)聯(lián)；當(dāng)有新?tīng)顟B(tài)插入時(shí)，更新對(duì)應(yīng)的保單表中的狀態(tài)。將理賠的狀態(tài)變化過(guò)程剝離出來(lái)單獨(dú)建表，在該表中保留與理賠的關(guān)聯(lián)；當(dāng)有新?tīng)顟B(tài)插入時(shí)，更新對(duì)應(yīng)的理賠表中的狀態(tài)。使用示例：增加Commercialagreementstatus，Groupagreementstatus，Individualagreementstatus表，分別記錄Commercialagreement,Groupagreement,Individualagreement