BI.Insurance i.DWM for P&C 模型設(shè)計(jì)說明,日程,為什么需要模型 模型的組織結(jié)構(gòu) 模型實(shí)施方法 模型設(shè)計(jì)策略 Q & A,|,日程,為什么需要模型 模型的組織結(jié)構(gòu) 模型實(shí)施方法 模型設(shè)計(jì)策略 Q & A,|,EDW體系架構(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)” “唯一的信息出口”,為什么需要企業(yè)模型？,EDW 數(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)用,BSA 業(yè)務(wù)模版應(yīng)用,日程,為什么需要模型 模型的組織結(jié)構(gòu) 模型實(shí)施方法 模型設(shè)計(jì)策略 Q & A,|,模型總體結(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ù)集市,DWM 數(shù)據(jù)模型邏輯結(jié)構(gòu),BI.Insurance i.DWM for P&C,底層數(shù)據(jù)模型主題域說明： Agreement：保單、批單申請(qǐng)及管理； Claim：理賠 Financial Transaction：應(yīng)收應(yīng)付、實(shí)收實(shí)付以及交易關(guān)聯(lián) Party：當(dāng)事方，包括當(dāng)事方的組織結(jié)構(gòu)、角色結(jié)構(gòu)及類型 Money Provision：資金管理 Specification And Product：規(guī)范及產(chǎn)品管理 Place：地點(diǎn) Code：標(biāo)準(zhǔn)代碼 Activity：活動(dòng)管理 Physical Object：實(shí)物、標(biāo)的管理,BI.Insurance i.DWM-Agreement,BI.Insurance i.DWM-Claim,BI.Insurance i.DWM-Physical Object,日程,為什么需要模型 模型的組織結(jié)構(gòu) 模型實(shí)施方法 模型設(shè)計(jì)策略 Q & A,|,步驟：,流程：,產(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篩選： 去掉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)情況,B映射： 1.映射到EM 2.結(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)種定義信息可以要。,1.多維模型設(shè)計(jì)文檔： 維度 指標(biāo) 派生指標(biāo) 2.需求-模型映射文檔 3.報(bào)表樣張 4.操作說明,EDW具體實(shí)施流程,日程,為什么需要模型 模型的組織結(jié)構(gòu) 模型實(shí)施方法 模型設(shè)計(jì)策略 Q & A,|,Hash code,問題的提出: 進(jìn)行增量加載時(shí)無法快速判斷對(duì)表的原有記錄是否新插入。例如： 1. 理賠案件發(fā)生的時(shí)候,增量文件會(huì)把保單數(shù)據(jù)也傳來 2. 保單增量過來,可能只是投保人的信息改了,而目標(biāo)保單表所需信息并沒有改變 解決方案： 使用增量的比較字段生成 Hash code。在對(duì)表進(jìn)行增量加載時(shí)，對(duì)增量文件中的每一條記錄生成 Hash code 將生成完的 Hash code 與原表中同一anchor id并且最新的記錄的 Hash code 進(jìn)行比較 如果一致的話，即不動(dòng)作；如果不一致的話，即新插入。 使用示例： 在 individual agreement 表中使用各個(gè)需要保留歷史信息的字段生成 hash code。 在增量加載時(shí)，使用業(yè)務(wù)增量文件中的字段生成 hash code。 與 Individual agreement 表中同一agreement id的最新記錄的hash code 進(jìn)行比較。 如果一致，即不動(dòng)作 如果不一致，則插入新記錄。 備注： relationship表是要根據(jù)業(yè)務(wù)去判斷是否關(guān)系已經(jīng)存在，然后，如果有其他屬性（如：Role player - Physical object Rlship.Usage），才需要用hashcode判別是否重復(fù)。,|,Hash code字段組成規(guī)則,帶anchor的實(shí)體 帶status表的實(shí)體（Commercial agreement、Group agreement、Individual agreement、Claim folder、Elementary claim） 除表的主鍵、type id、Partition key、Status、Status date、Status reason、 Valid from date、Valid to date、Effective from date、Effective to date、 Population timestamp之外的所有字段 不帶status表的實(shí)體 除表的主鍵、 type id、 Partition key、 Valid from date、Valid to date、Effective from date、Effective to date、 Population timestamp之外的所有字段 不帶anchor的實(shí)體 原則上不需要保留歷史，一般執(zhí)行Update操作。如果有需要的，ETL Mapping特別指明 關(guān)聯(lián)實(shí)體 對(duì)于需要保留歷史的關(guān)聯(lián)類型，除Identifier、Partition key、Nature id、 Left anchor identifier、 Right anchor identifier、 Left entity identifier、Left entity type id、Right entity identifier、Right entity type id、Valid from date、Valid to date、Effective from date、Effective to date、Population timestamp之外的所有字段,|,Partition key,問題的提出: 在進(jìn)行多表關(guān)聯(lián)時(shí)，所涉及的關(guān)聯(lián)表行數(shù)巨大，關(guān)聯(lián)速度達(dá)不到要求。 解決方案：在所有大表中建立 Partition key, 按照該鍵的鍵值對(duì)表進(jìn)行物理分 區(qū)。Partition key 從Partition config 表中獲得。分區(qū)策略是 按照分公司進(jìn)行分區(qū)。 使用示例：表 A 與表 B 進(jìn)行關(guān)聯(lián)時(shí)，如下進(jìn)行 select A.column1, B.column2 from A, B where A.foreign_key=B.Primary_key and A.partition_key in (select Storage partition from Partition config where Branch company id=xxxx) and B.partition_key in (select Storage partition from Partition config where Branch company id=xxxxxxx),|,|,對(duì)保單和理賠狀態(tài)的特殊處理,問題的提出： 保單在承保和保全的整個(gè)過程中狀態(tài)變化比較多，如按照 IIW 的原有設(shè)計(jì)，保單表中的會(huì)有巨量的歷史記錄；理賠在報(bào)案、立案和估損的整個(gè)過程中狀態(tài)變化較多，如按照 IIW 的原有設(shè)計(jì)，理賠表中會(huì)有很多的歷史記錄。 解決方案： 將保單的狀態(tài)變化過程剝離出來單獨(dú)建表，在該表中保留與保單的關(guān)聯(lián)；當(dāng)有新狀態(tài)插入時(shí)，更新對(duì)應(yīng)的保單表中的狀態(tài)。 將理賠的狀態(tài)變化過程剝離出來單獨(dú)建表，在該表中保留與理賠的關(guān)聯(lián)；當(dāng)有新狀態(tài)插入時(shí)，更新對(duì)應(yīng)的理賠表中的狀態(tài)。 使用示例： 增加Commercial agreement status，Group agreement status，Individual agreement status 表，分別記錄 Commercial agreement , Group agreement ,Individual agreement 的狀態(tài)變化歷史。 當(dāng)前面狀態(tài)發(fā)生該變時(shí)，在status表中插入新記錄，更新對(duì)于原表中的狀態(tài)字段。,對(duì)保單和理賠狀態(tài)的特殊處理示例,|,Individual agreement,Individual agreement status,Left/Right Entity ID in Relationship or Role Entity,問題的提出 在IIW中的不同subject area的實(shí)體關(guān)聯(lián)通常是走關(guān)聯(lián)實(shí)體的，例如：Physical object - Agreement Rlship。在關(guān)聯(lián)實(shí)體中是以anchor id進(jìn)行連接的。在分析的時(shí)候，通常是應(yīng)該按照當(dāng)時(shí)的狀況進(jìn)行分析才有意義。由于EDW是保留歷史信息的，同一個(gè)Physical object或Agreement會(huì)有多條記錄，如何找到當(dāng)時(shí)的記錄，必須通過effective from/to date的比對(duì)才能實(shí)現(xiàn)，這非常影響效率。 解決方案 在關(guān)聯(lián)實(shí)體中增加Left/Right entity identifier，Left/Right entity type id Left/Right entity type id是指具體基礎(chǔ)表的id號(hào) 例如：Road vehicle（2001260001） Left/Right entity identifier是指具體基礎(chǔ)表中記錄的主鍵id值 例如： Road vehicle中牌照號(hào)滬A000001車輛的第一條記錄的Road vehicle id值 適用范圍： FS Role Physical object - Agreement Rlship,|,Sample of Left/Right Entity ID in Relationship or Role Entity,|,Road vehicle,Individual agreement,Agreement,Physical object,Physical object Agreement Rlship,被保標(biāo)的,Party role in operation/Internal person,問題的提出 在業(yè)務(wù)中有很多操作員角色，只有工號(hào)、姓名信息，沒有身份證等其他信息； 一個(gè)操作員在一個(gè)業(yè)務(wù)流程中會(huì)同時(shí)扮演不同角色，如在A保單核保中他是錄入人，在B保單核保中他是復(fù)核人或者可能出現(xiàn)在A保單核保中他既是錄入人又是復(fù)核人 解決方案 建立Internal person表保存業(yè)務(wù)員、公司管理人員的個(gè)人信息，這些信息質(zhì)量較差 建立Party role in operation表保存操作員角色信息，每次都生成新記錄。 錄單員冗余到保單中，理賠的操作員也冗余到claim folder中,|,關(guān)聯(lián)實(shí)體的版本問題,由于關(guān)聯(lián)實(shí)體本身沒有對(duì)應(yīng)的anchor實(shí)體，不存在版本問題，但是關(guān)聯(lián)存在有以下兩種變化情況。 人“王五”擁有一棟房屋，在2007/1/1賣掉了。 更新原有的Role player physical object Rlship記錄的 valid to date：if 源系統(tǒng)有系統(tǒng)更新日期，則更新日期1；else，則“2006/12/31” effective to date： “2006/12/31” 人“王五”擁有一棟房屋，在2007/1/1賣掉50的產(chǎn)權(quán)。 更新原有的Role player physical object Rlship記錄的 valid to date：if 源系統(tǒng)有系統(tǒng)更新日期，則更新日期1；else，則“2006/12/31” effective to date： “2006/12/31” （Ownership percentage： 100） 插入新的Role player physical object Rlship記錄 valid from date：if 源系統(tǒng)有系統(tǒng)更新日期，則更新日期1；else，則“2007/1/1” effective from date： “2007/1/1” Ownership percentage： 50,|,Financial Services Role,問題的提出 Person存放人的基本信息，External organisation和Internal organisation存放機(jī)構(gòu)的基本信息 一個(gè)人和機(jī)構(gòu)在不同環(huán)境下分別扮演不同角色，所以 Financial Services Role存放與保單（各種協(xié)議）相關(guān)的金融服務(wù)角色，如保單持有人，被保險(xiǎn)人，受益人等。 Channel role存放中介渠道角色信息，如營(yíng)銷員、收展員 在分析集市中需要獲取保單與業(yè)務(wù)員的關(guān)聯(lián)信息，IIW原連接方式如圖：,|,Financial Services Role （Financial services role player id）,Person （Role player id）,Channel role （Channel role player id）,優(yōu)點(diǎn)：結(jié)構(gòu)清晰統(tǒng)一 缺點(diǎn)：渠道角色信息關(guān)聯(lián)的太遠(yuǎn)，需要Financial Services Role+Channel role+Person，影響效率,Person （Role player id）,External organisation （Role player id）,Financial Services Role,解決方案 Financial Services Role用把basis role player type id確定應(yīng)連接Person 還是External organisation Financial Services Role用把basis role player id確定Person或External organisation中記錄的role player id Financial Services Role用把basis role player entity identifier確定Person或External organisation中記錄的person id或External organisation id 使用示例,|,Financial Services Role （Financial services role player id）,Person （Role player id）,Channel role （ Role player id Channel role player id）,Person （Role player id）,External organisation （Role player id）,Currency code,問題的提出： 在 CPIC 的實(shí)際業(yè)務(wù)中，可能出現(xiàn)多幣種，在統(tǒng)計(jì)中需要進(jìn)行多幣種的轉(zhuǎn)換。 解決方案： 在 IIW 模型中凡出現(xiàn)金額字段的表，都增加金額的幣種及對(duì)應(yīng)的 RMB 金額兩類字段。 原字段存放原幣中金額， RMB 金額存放折算成RMB的金額 使用示例： Elementary claim 表中增加 Total cost currency 和 Total cost RMB 字段 備注：由于CPIC對(duì)多幣種金額的統(tǒng)計(jì)有多種統(tǒng)計(jì)方式，不全部是按照發(fā)生制來折算RMB的。因此，統(tǒng)計(jì)轉(zhuǎn)換金額到RMB的工作，留給統(tǒng)計(jì)部分執(zhí)行，在原子層不計(jì)算。幣種一定要填。,|,維度表的snapshot,問題的提出 在分析層中，常用的維度表如：保單、立案。分析常用的屬性是分散在各個(gè)表中的，如：保費(fèi)、保額在Particular Money Provision中。分析時(shí)如果再通過關(guān)聯(lián)來找到這些信息，效率非常低。 解決方案 建立維度的snapshot表，將這些信息冗余存放在這些表中，每個(gè)月全量刷新一次。 使用示例： Claim folder dimension Policy dimension Elementary claim dimension Event dimension,|,Commercial agreement/Group agreement/Individual agreement的邊界區(qū)分,Commercial agreement 存放保險(xiǎn)公司和機(jī)構(gòu)投保人簽訂的關(guān)于承保要素約束的框架性協(xié)議；不是具體的保單。具體的保單要遵循該協(xié)議。 Group agreement 團(tuán)單 單位和保險(xiǎn)公司簽訂的保一組成員的保單，如：壽險(xiǎn)團(tuán)單、雇主責(zé)任險(xiǎn)、旅游責(zé)任險(xiǎn)。 如果源系統(tǒng)提供了每個(gè)被保人的投保情況，這些記錄在individual agreement（type id個(gè)人憑證）中的。如：雇主責(zé)任險(xiǎn)下每個(gè)人的投保份數(shù)。 Individual agreement 個(gè)單/個(gè)人憑證 備注：根據(jù)國(guó)內(nèi)系統(tǒng)的情況做了些調(diào)整，和機(jī)構(gòu)投保人（非個(gè)人）簽訂的個(gè)單也存放在此。 投保單按保單處理，只是狀態(tài)是投保狀態(tài),|,Group agreement/Individual agreement在ETL時(shí)處理,車險(xiǎn)系統(tǒng)保單 進(jìn)入Individual agreement 壽險(xiǎn)保單 根據(jù)來源表，決定進(jìn)入group agreement還是individual agreement CIBS(包括老系統(tǒng))和人意險(xiǎn)保單 根據(jù)Financial services product中的Individual insurance flag判斷 個(gè)險(xiǎn)，進(jìn)入Individual agreement 團(tuán)險(xiǎn)、個(gè)團(tuán)皆可，進(jìn)入group agreement,|,最新記錄標(biāo)志,Effective to date = 9999/12/31 00:00:00,|,公司的拆分合并，partition key的處理 1/4,分公司的拆分合并，不需要程序考慮，發(fā)生后手工處理。 公司合并 舉例：原來有分公司A,分公司B,在2006/1/1分公司B合并到分公司A。,|,合并前,Partition config,External organisation,Individual agreement,公司的拆分合并，partition key的處理 2/4,公司合并 舉例：原來有分公司A,分公司B,在2006/1/1分公司B合并到分公司A。,|,合并后,Partition config,External organisation,Individual agreement,Role player Rlship,公司的拆分合并，partition key的處理 3/4,公司合并 舉例：原來有分公司A, 在2006/1/1分公司A,拆分成分公司A和分公司B。,|,拆分前,Partition config,External organisation,Individual agreement,公司的拆分合并，partition key的處理 4/4,公司合并 舉例：原來有分公司A, 在2006/1/1分公司A,拆分成分公司A和分公司B。,|,拆分后,Partition config,External organisation,Individual agreement,Role player Rlship,按照type id分表,將有些大表按照 Type id 進(jìn)行拆分 舉例：Individual agreement 表按照保單和投保單拆成兩張表,|,歷史信息的處理,對(duì)含有歷史記錄的大表，應(yīng)考慮將歷史記錄剝離出來單獨(dú)建表，即原表保留最新的信息，而在剝離出來的表中包含這些信息的變化歷史。 舉例： Individual agreement 原來保留有保單的最新信息及這些信息的歷史變化記錄。這樣這張表就將很大，記錄數(shù)數(shù)以億計(jì)。目前將它拆成 2 個(gè)表： 表一，存放保單的最新信息，如最新狀態(tài)，最新確認(rèn)的起保日期等，同時(shí)保留每條記錄最新的刷新時(shí)間 表二，存放保單經(jīng)常變化的值的變化歷史，如：保單狀態(tài)的變化歷史 表三，存放保單所有歷史變化的信息,|,增加表的冗余字段,問題的提出：原有設(shè)計(jì)中，一條業(yè)務(wù)上具有完整意義的信息被拆分在多個(gè)表中，在生成分析層（或進(jìn)行分析時(shí)）又要將被拆分的信息通過多表關(guān)聯(lián)的方式關(guān)聯(lián)起來。 解決方案：在表中盡量增加冗余字段。要注意的是，冗余字段并非任意增加，而是要增加： 冗余關(guān)聯(lián)類型為m:1 的字段，如：保單的所屬分公司。 從業(yè)務(wù)上說，基本不變化的冗余字段,|,增加表與表之間的外鍵，減少走關(guān)聯(lián)表,問題的提出：原有設(shè)計(jì)中，一條業(yè)務(wù)上具有完整意義的信息被拆分在多個(gè)表中，在生成分析層（或進(jìn)行分析時(shí)）又要將被拆分的信息通過多表關(guān)聯(lián)的方式關(guān)聯(lián)起來。而這樣的關(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)。 例如：selling channel role id在individual agreement表中的冗余。否則，要走FS Role連接channel role。 盡可能減少關(guān)聯(lián)的層級(jí)。即減少不必要的關(guān)聯(lián)中間表 例如：如保單的操作員直接建立到保單中，保單和理賠的科室、部門直接建立到保單和理賠中。 備注：m:m的關(guān)系必須走關(guān)聯(lián)表。,|,模型優(yōu)化任務(wù)分配,Jeffrey: Activity, Reinsurance, Claim, Goal and need, Legal action, Physical object, Place, Registration, Specification and product, Standard text and communication, Technical entity, Type 王正茂: Account and fund, Actuarial statistics and index, Assessment and condition, Category, Contact point and preferences, Event, Financial account, Goal and need Ben: Agreement, Financial transaction, Money provision, Party,|,EDW和ODS的關(guān)系,Person、External organisation 、FS Role（投保人/被保人）通過ODS產(chǎn)生 由于加載順序的關(guān)系，保單表由業(yè)務(wù)系統(tǒng)產(chǎn)生，產(chǎn)生保單信息時(shí)，ODS數(shù)據(jù)還沒有加載。因此， Individual agreement中的Policyholder id、Group agreement中的Policyholder organisation id不冗余產(chǎn)生，而是通過FS Role走。,|,Id產(chǎn)生規(guī)則,每個(gè)表單獨(dú)使用id序列 建id序列表,|,Anchor表是否需要物理產(chǎn)生,建物理產(chǎn)生Anchor表 所有和Anchor直接外鍵關(guān)聯(lián)的type id冗余,|,Person歸并決策,Person，external organisation在EDW不再進(jìn)行歸并,|,Boolean,0 false 1 true,|,Atomic derived data,Atomic層表中，有部分字段保存的是從其他表或字段中導(dǎo)出的數(shù)據(jù)，如：claim folder中total cost，是從internal claim cost中統(tǒng)計(jì)來的。 對(duì)于這部分字段，分為兩部分： 目前analytical層或data mart用到的，需要處理 暫時(shí)沒用的字段，暫不處理 這部分字段的處理，在atomic產(chǎn)生完成后，產(chǎn)生analytical層前處理。,|,Atomic,Analytical,1,2,物理分表,|,備注：沒特別注明的其他類型的在原Entity中,Money scheduler,Money in scheduler 用于連接對(duì)于保險(xiǎn)公司來說是進(jìn)來的錢的particular money provision/Financial transaction，如：保費(fèi)、儲(chǔ)金（包括批增、批減） Money out scheduler 用于連接對(duì)于保險(xiǎn)公司來說是出去的錢的particular money provision/Financial transaction，如：賠款、支付的養(yǎng)老金（包括攤回賠款） 每個(gè)保單簽單產(chǎn)生一個(gè)Money in scheduler，保單不含批單的保額、保費(fèi)掛在該Money in scheduler下；每個(gè)批單單產(chǎn)生一個(gè)Money in scheduler，該批單對(duì)應(yīng)的保額、保費(fèi)變化掛在該Money in scheduler下。 每個(gè)賠案產(chǎn)生一個(gè)Money out scheduler，該賠案對(duì)應(yīng)的Particular money provision掛在該Money out scheduler下。,|,關(guān)聯(lián)表冗余進(jìn)實(shí)體表中 1/2,|,關(guān)聯(lián)表冗余進(jìn)實(shí)體表中 2/2,|,Anchor的type id冗余到外鍵關(guān)聯(lián)的表中 -1/2,|,Anchor的type id冗余到外鍵關(guān)聯(lián)的表中 -2/2,|,Claim中涉及的各種金額存放規(guī)則 1/2,|,Claim中涉及的各種金額存放規(guī)則 2/2,Particular money provision對(duì)應(yīng)賠案級(jí)，其中不存放金額，起關(guān)聯(lián)作用（Agreement id，Agreement type id，Money scheduler id，（Money payee id，Money payee type id，Money payer id，Money payer type id有則產(chǎn)生）。Money scheduler一個(gè)賠案產(chǎn)生一條記錄，該賠案下的Particular money provision都掛在這個(gè)Money scheduler下。 Claim offer可以存放多種offer，可以為服務(wù)、物品或金錢（包括狀態(tài)是未決的） Internal claim cost用于存放理算后的公司內(nèi)部發(fā)生的各種理賠費(fèi)用，如查勘費(fèi)、施救費(fèi)、律師費(fèi)等。 Internal claim cost通過Internal claim cost - Claim Rlship 與claim folder關(guān)聯(lián) 查勘表中記錄的明細(xì)費(fèi)用（如查勘費(fèi)、施救費(fèi)、律師費(fèi)等）放在Money provision part，通過Money provision cash flow到 Particular money provision中的activity id連接到查勘活動(dòng)中 Money provision part用于存放賠給客戶的賠款明細(xì)(包括狀態(tài)是未決的)、到賠付項(xiàng)目代碼級(jí)別。 Money provision cash flow用于存放子險(xiǎn)級(jí)合計(jì)的賠款金額,和claim offer對(duì)應(yīng) 放在Money provision cash flow和Money provision part中賠款的錢金額變化、 Money provision cash flow /Money provision part中賠款金額不保留版本，當(dāng)出現(xiàn)修改時(shí)直接修改這些表中的記錄 Claim Offer 中的賠款金額不保留歷史，將來如果業(yè)務(wù)需要，再做保留歷史處理 立案的估損/定損都放在Financial valuation中 估損/定損明細(xì)單獨(dú)建表,|,核保核賠在EDW模型中的處理,核保核賠本身是一個(gè)工作流程的活動(dòng)，每個(gè)核保核賠又細(xì)分成不同的步驟，如：收集單證，復(fù)核等活動(dòng)步驟。類似于IIW中的campaign，campaign cell和campaign step的關(guān)系。 在EDW中產(chǎn)險(xiǎn)使用underwriting check/claim check來存放核保核賠信息，主活動(dòng)和活動(dòng)步驟通過不同的type來區(qū)分。主活動(dòng)和活動(dòng)步驟通過underwriting check/claim check的自關(guān)聯(lián)實(shí)現(xiàn)。 每個(gè)主活動(dòng)只需要保留一條記錄，有變化update；因?yàn)槊總€(gè)具體的步驟包括了該活動(dòng)變化的信息。 對(duì)于一個(gè)投保單多次核保的情況，每個(gè)核保一個(gè)主活動(dòng)。,|,投保單/協(xié)議申請(qǐng)單的處理,以下投保單指：投保單或協(xié)議申請(qǐng)單 投保單作為保單的一個(gè)歷史狀態(tài)處理。 全量數(shù)據(jù)： 即使投保單已成為保單，也要插入一條投保單的記錄。Valid from date錄入日期，valid to date簽單日期。 Effective from date投保日期（如果沒有投保日期，同valid from date），Effective to date簽單日期。如果該投保單記錄的目標(biāo)表是individual agreement，則投保單的記錄直接插入individual agreement history。 如果投保單還沒有成為保單，投保單的Valid from date錄入日期，valid to date9999/12/31。 Effective from date投保日期（如果沒有投保日期，同valid from date），Effective to date 9999/12/31 。 增量數(shù)據(jù)： 如果投保單已經(jīng)變?yōu)楸瘟?，就作為保單的歷史記錄，新插入保單的記錄， 如果目標(biāo)表是individual agreement，則投保單的記錄挪到individual agreement history中。 如果目標(biāo)表是不是individual agreement，則投保單的記錄仍然在原表中。如：group agreement，commercial agreement。 投保單和保單共用同一個(gè)agreement id，type id分別為投保單、保單（團(tuán)單，個(gè)單，個(gè)單憑證等）。 投保單只保持一條記錄，最新狀況update該記錄。 備注：如果將來投保單數(shù)據(jù)太多，影響執(zhí)行效率，由其他程序定期執(zhí)行歸檔處理，將已成為保單的n年前的投保單數(shù)據(jù)歸檔。 有的系統(tǒng)投保單和保單是同一條記錄，有的系統(tǒng)投保單和保單是不同條記錄。在EDW中必須保持一致的處理方式。,|,批改申請(qǐng)單的處理,批改不記錄歷史，因此，批改申請(qǐng)和批改使用同一條記錄，有改變直接Update該記錄。 在change request中新增一個(gè)字段存放批改申請(qǐng)?zhí)枴?|,日程,為什么需要模型 模型的組織結(jié)構(gòu) 模型實(shí)施方法 模型設(shè)計(jì)策略 Q & A,|,日程,Thank you!,|,