EDW-(DM數(shù)據(jù)倉庫數(shù)據(jù)建模)模型設計課件

BI.Insurancei.DWMforP&C

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

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

selectA.column1,B.column2fromA,BwhereA.foreign_key=B.Primary_keyandA.partition_keyin(selectStoragepartitionfromPartitionconfigwhereBranchcompanyid=xxxx) andB.partition_keyin(selectStoragepartitionfromPartitionconfigwhereBranchcompanyid=xxxxxxx)|Partitionkey問題的提出:|19|對保單和理賠狀態(tài)的特殊處理問題的提出：保單在承保和保全的整個過程中狀態(tài)變化比較多，如按照IIW的原有設計，保單表中的會有巨量的歷史記錄；理賠在報案、立案和估損的整個過程中狀態(tài)變化較多，如按照IIW的原有設計，理賠表中會有很多的歷史記錄。解決方案：將保單的狀態(tài)變化過程剝離出來單獨建表，在該表中保留與保單的關聯(lián)；當有新狀態(tài)插入時，更新對應的保單表中的狀態(tài)。將理賠的狀態(tài)變化過程剝離出來單獨建表，在該表中保留與理賠的關聯(lián)；當有新狀態(tài)插入時，更新對應的理賠表中的狀態(tài)。使用示例：增加Commercialagreementstatus，Groupagreementstatus，Individualagreementstatus表，分別記錄Commercialagreement,Groupagreement,Individualagreement的狀態(tài)變化歷史。當前面狀態(tài)發(fā)生該變時，在status表中插入新記錄，更新對于原表中的狀態(tài)字段。|對保單和理賠狀態(tài)的特殊處理問題的提出：20對保單和理賠狀態(tài)的特殊處理示例|IndividualagreementIndividualagreementstatus對保單和理賠狀態(tài)的特殊處理示例|Individu21Left/RightEntityIDinRelationshiporRoleEntity問題的提出在IIW中的不同subjectarea的實體關聯(lián)通常是走關聯(lián)實體的，例如：Physicalobject-AgreementRlship。在關聯(lián)實體中是以anchorid進行連接的。在分析的時候，通常是應該按照當時的狀況進行分析才有意義。由于EDW是保留歷史信息的，同一個Physicalobject或Agreement會有多條記錄，如何找到當時的記錄，必須通過effectivefrom/todate的比對才能實現(xiàn)，這非常影響效率。解決方案在關聯(lián)實體中增加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問題的提出在業(yè)務中有很多操作員角色，只有工號、姓名信息，沒有身份證等其他信息；一個操作員在一個業(yè)務流程中會同時扮演不同角色，如在A保單核保中他是錄入人，在B保單核保中他是復核人或者可能出現(xiàn)在A保單核保中他既是錄入人又是復核人解決方案建立Internalperson表保存業(yè)務員、公司管理人員的個人信息，這些信息質量較差建立Partyroleinoperation表保存操作員角色信息，每次都生成新記錄。錄單員冗余到保單中，理賠的操作員也冗余到claimfolder中|Roleplayer-ActivityRlshipPartyroleinoperation（Roleplayerid

）InternalPerson（Roleplayerid）FinancialServicesRolePartyroleinoperation/Intern24關聯(lián)實體的版本問題由于關聯(lián)實體本身沒有對應的anchor實體，不存在版本問題，但是關聯(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)權。更新原有的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％|關聯(lián)實體的版本問題由于關聯(lián)實體本身沒有對應的anchor實體25FinancialServicesRole問題的提出Person存放人的基本信息，Externalorganisation和Internalorganisation存放機構的基本信息一個人和機構在不同環(huán)境下分別扮演不同角色，所以FinancialServicesRole存放與保單（各種協(xié)議）相關的金融服務角色，如保單持有人，被保險人，受益人等。Channelrole存放中介渠道角色信息，如營銷員、收展員在分析集市中需要獲取保單與業(yè)務員的關聯(lián)信息，IIW原連接方式如圖：|FinancialServicesRole（Financialservicesroleplayerid）Person（Roleplayerid）Channelrole（Channelroleplayerid）優(yōu)點：結構清晰統(tǒng)一缺點：渠道角色信息關聯(lián)的太遠，需要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的實際業(yè)務中，可能出現(xiàn)多幣種，在統(tǒng)計中需要進行多幣種的轉換。解決方案：在IIW模型中凡出現(xiàn)金額字段的表，都增加金額的幣種及對應的RMB金額兩類字段。原字段存放原幣中金額，RMB金額存放折算成RMB的金額使用示例：Elementaryclaim表中增加Totalcostcurrency和TotalcostRMB字段備注：由于CPIC對多幣種金額的統(tǒng)計有多種統(tǒng)計方式，不全部是按照發(fā)生制來折算RMB的。因此，統(tǒng)計轉換金額到RMB的工作，留給統(tǒng)計部分執(zhí)行，在原子層不計算。幣種一定要填。|Currencycode問題的提出：|28維度表的snapshot問題的提出在分析層中，常用的維度表如：保單、立案。分析常用的屬性是分散在各個表中的，如：保費、保額在ParticularMoneyProvision中。分析時如果再通過關聯(lián)來找到這些信息，效率非常低。解決方案建立維度的snapshot表，將這些信息冗余存放在這些表中，每個月全量刷新一次。使用示例：ClaimfolderdimensionPolicydimensionElementaryclaimdimensionEventdimension|維度表的snapshot問題的提出|29Commercialagreement/Groupagreement/Individualagreement的邊界區(qū)分Commercialagreement存放保險公司和機構投保人簽訂的關于承保要素約束的框架性協(xié)議；不是具體的保單。具體的保單要遵循該協(xié)議。Groupagreement團單單位和保險公司簽訂的保一組成員的保單，如：壽險團單、雇主責任險、旅游責任險。如果源系統(tǒng)提供了每個被保人的投保情況，這些記錄在individualagreement（typeid＝個人憑證）中的。如：雇主責任險下每個人的投保份數(shù)。Individualagreement個單/個人憑證備注：根據(jù)國內系統(tǒng)的情況做了些調整，和機構投保人（非個人）簽訂的個單也存放在此。投保單按保單處理，只是狀態(tài)是投保狀態(tài)|Commercialagreement/Groupagr30Groupagreement/Individualagreement在ETL時處理車險系統(tǒng)保單進入Individualagreement壽險保單根據(jù)來源表，決定進入groupagreement還是individualagreementCIBS(包括老系統(tǒng))和人意險保單根據(jù)Financialservicesproduct中的Individualinsuranceflag判斷個險，進入Individualagreement團險、個團皆可，進入groupagreement|Groupagreement/Individualagr31最新記錄標志Effectivetodate=‘9999/12/3100:00:00’|最新記錄標志Effectivetodate=‘99932公司的拆分合并，partitionkey的處理–1/4分公司的拆分合并，不需要程序考慮，發(fā)生后手工處理。公司合并舉例：原來有分公司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原來保留有保單的最新信息及這些信息的歷史變化記錄。這樣這張表就將很大，記錄數(shù)數(shù)以億計。目前將它拆成2個表：表一，存放保單的最新信息，如最新狀態(tài)，最新確認的起保日期等，同時保留每條記錄最新的刷新時間表二，存放保單經(jīng)常變化的值的變化歷史，如：保單狀態(tài)的變化歷史表三，存放保單所有歷史變化的信息|歷史信息的處理對含有歷史記錄的大表，應考慮將歷史記錄剝離出來38增加表的冗余字段問題的提出：原有設計中，一條業(yè)務上具有完整意義的信息被拆分在多個表中，在生成分析層（或進行分析時）又要將被拆分的信息通過多表關聯(lián)的方式關聯(lián)起來。解決方案：在表中盡量增加冗余字段。要注意的是，冗余字段并非任意增加，而是要增加：冗余關聯(lián)類型為m:1的字段，如：保單的所屬分公司。從業(yè)務上說，基本不變化的冗余字段|增加表的冗余字段問題的提出：原有設計中，一條業(yè)務上具有完整意39增加表與表之間的外鍵，減少走關聯(lián)表問題的提出：原有設計中，一條業(yè)務上具有完整意義的信息被拆分在多個表中，在生成分析層（或進行分析時）又要將被拆分的信息通過多表關聯(lián)的方式關聯(lián)起來。而這樣的關聯(lián)可能要跨多個表。解決方案：增加有業(yè)務含義的信息之間的直接關聯(lián)。即如兩表的信息如果有業(yè)務關聯(lián)，而在原有設計中這兩表之間的關聯(lián)要借助其他中間表的，應在此兩表之間建立直接的關聯(lián)。例如：sellingchannelroleid在individualagreement表中的冗余。否則，要走FSRole連接channelrole。盡可能減少關聯(lián)的層級。即減少不必要的關聯(lián)中間表例如：如保單的操作員直接建立到保單中，保單和理賠的科室、部門直接建立到保單和理賠中。備注：m:m的關系必須走關聯(lián)表。|增加表與表之間的外鍵，減少走關聯(lián)表問題的提出：原有設計中，一40模型優(yōu)化任務分配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)化任務分配Jeffrey:Activity,Rei41EDW和ODS的關系Person、Externalorganisation、FSRole（投保人/被保人）通過ODS產(chǎn)生由于加載順序的關系，保單表由業(yè)務系統(tǒng)產(chǎn)生，產(chǎn)生保單信息時，ODS數(shù)據(jù)還沒有加載。因此，Individualagreement中的Policyholderid、Groupagreement中的Policyholderorganisationid不冗余產(chǎn)生，而是通過FSRole走。|EDW和ODS的關系Person、Externalorga42Id產(chǎn)生規(guī)則每個表單獨使用id序列建id序列表|Id產(chǎn)生規(guī)則每個表單獨使用id序列|43Anchor表是否需要物理產(chǎn)生建物理產(chǎn)生Anchor表所有和Anchor直接外鍵關聯(lián)的typeid冗余|Anchor表是否需要物理產(chǎn)生建物理產(chǎn)生Anchor表|44Person歸并決策Person，externalorganisation在EDW不再進行歸并|Person歸并決策Person，externalorga45Boolean0false1true|Boolean0false|46AtomicderiveddataAtomic層表中，有部分字段保存的是從其他表或字段中導出的數(shù)據(jù)，如：claimfolder中totalcost，是從internalclaimcost中統(tǒng)計來的。對于這部分字段，分為兩部分：目前analytical層或datamart用到的，需要處理暫時沒用的字段，暫不處理這部分字段的處理，在atomic產(chǎn)生完成后，產(chǎn)生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，如：賠款、支付的養(yǎng)老金（包括攤回賠款）每個保單簽單產(chǎn)生一個Moneyinscheduler，保單不含批單的保額、保費掛在該Moneyinscheduler下；每個批單單產(chǎn)生一個Moneyinscheduler，該批單對應的保額、保費變化掛在該Moneyinscheduler下。每個賠案產(chǎn)生一個Moneyoutscheduler，該賠案對應的Particularmoneyprovision掛在該Moneyoutscheduler下。|MoneyschedulerMoneyinschedu49關聯(lián)表冗余進實體表中－1/2SubjectareaEntity加字段備注ActivityActivity-PlaceRlshipclaimfolder.報案地點Activity-PlaceRlship.Nature_id=報案地點2000030003直接挪到claimfolder中ActivityActivity-PlaceRlshipParticularactivity.活動地點Activity-PlaceRlship.Nature_id=

查勘地點2000030004

工程作業(yè)地域2000030005

建造地點2000030006

交船地點2000030007

直接挪到Particularactivity.活動地點ActivityActivity-PlaceRlshipTransportation.啟運港/Transportation.中轉港1/Transportation.中轉港2/Transportation.目的地Activity-PlaceRlship.Nature_id=

啟運港2000030008

中轉港2000030009

直接挪到Transportation.啟運港/Transportation.中轉港

加代碼字段和名稱字段

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

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

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

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