EDW-(DM數(shù)據(jù)倉(cāng)庫(kù)數(shù)據(jù)建模)模型設(shè)計(jì)課件_第1頁(yè)
EDW-(DM數(shù)據(jù)倉(cāng)庫(kù)數(shù)據(jù)建模)模型設(shè)計(jì)課件_第2頁(yè)
EDW-(DM數(shù)據(jù)倉(cāng)庫(kù)數(shù)據(jù)建模)模型設(shè)計(jì)課件_第3頁(yè)
EDW-(DM數(shù)據(jù)倉(cāng)庫(kù)數(shù)據(jù)建模)模型設(shè)計(jì)課件_第4頁(yè)
EDW-(DM數(shù)據(jù)倉(cāng)庫(kù)數(shù)據(jù)建模)模型設(shè)計(jì)課件_第5頁(yè)
已閱讀5頁(yè),還剩115頁(yè)未讀 繼續(xù)免費(fèi)閱讀

下載本文檔

版權(quán)說(shuō)明:本文檔由用戶提供并上傳,收益歸屬內(nèi)容提供方,若內(nèi)容存在侵權(quán),請(qǐng)進(jìn)行舉報(bào)或認(rèn)領(lǐng)

文檔簡(jiǎn)介

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

溫馨提示

  • 1. 本站所有資源如無(wú)特殊說(shuō)明,都需要本地電腦安裝OFFICE2007和PDF閱讀器。圖紙軟件為CAD,CAXA,PROE,UG,SolidWorks等.壓縮文件請(qǐng)下載最新的WinRAR軟件解壓。
  • 2. 本站的文檔不包含任何第三方提供的附件圖紙等,如果需要附件,請(qǐng)聯(lián)系上傳者。文件的所有權(quán)益歸上傳用戶所有。
  • 3. 本站RAR壓縮包中若帶圖紙,網(wǎng)頁(yè)內(nèi)容里面會(huì)有圖紙預(yù)覽,若沒(méi)有圖紙預(yù)覽就沒(méi)有圖紙。
  • 4. 未經(jīng)權(quán)益所有人同意不得將文件中的內(nèi)容挪作商業(yè)或盈利用途。
  • 5. 人人文庫(kù)網(wǎng)僅提供信息存儲(chǔ)空間,僅對(duì)用戶上傳內(nèi)容的表現(xiàn)方式做保護(hù)處理,對(duì)用戶上傳分享的文檔內(nèi)容本身不做任何修改或編輯,并不能對(duì)任何下載內(nèi)容負(fù)責(zé)。
  • 6. 下載文件中如有侵權(quán)或不適當(dāng)內(nèi)容,請(qǐng)與我們聯(lián)系,我們立即糾正。
  • 7. 本站不保證下載資源的準(zhǔn)確性、安全性和完整性, 同時(shí)也不承擔(dān)用戶因使用這些下載資源對(duì)自己和他人造成任何形式的傷害或損失。

評(píng)論

0/150

提交評(píng)論