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