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

BI.Insurancei.DWMforP&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ù)倉庫層ETL層數(shù)據(jù)集市層應(yīng)用層展現(xiàn)層手工數(shù)據(jù)外部數(shù)據(jù)數(shù)據(jù)倉庫保險(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)一分析平臺元數(shù)據(jù)庫監(jiān)管報(bào)表管理報(bào)表運(yùn)營報(bào)表儀表盤隨機(jī)查詢多維分析“數(shù)據(jù)和信息集成平臺”“統(tǒng)一的分析平臺”“唯一的信息出口”為什么需要企業(yè)模型？數(shù)據(jù)集市之間數(shù)據(jù)一致性包含全部歷史的核心數(shù)據(jù)一致的事實(shí)表和維度EDW數(shù)據(jù)模型在項(xiàng)目實(shí)施中的作用DWM數(shù)據(jù)倉庫模型BAM業(yè)務(wù)分析模型運(yùn)營型業(yè)務(wù)系統(tǒng)數(shù)據(jù)倉庫數(shù)據(jù)集市報(bào)表分析型應(yīng)用XMLFileFlatFileInformixOracleSQLDB2BSA業(yè)務(wù)模版應(yīng)用日程為什么需要模型模型的組織結(jié)構(gòu)模型實(shí)施方法模型設(shè)計(jì)策略Q&A|模型總體結(jié)構(gòu)－EM&DataMarts核心原子數(shù)據(jù)事實(shí)表和維度企業(yè)模型營銷管理快速入門客戶細(xì)分和管理保險(xiǎn)盈利性分析潛在客戶管理數(shù)據(jù)集市導(dǎo)出業(yè)務(wù)數(shù)據(jù)模型映射指標(biāo)要素需求模型財(cái)務(wù)報(bào)表數(shù)據(jù)集市中介績效分析數(shù)據(jù)集市健康險(xiǎn)盈利性管理數(shù)據(jù)集市DWM數(shù)據(jù)模型邏輯結(jié)構(gòu)當(dāng)事人營銷和溝通組織產(chǎn)品協(xié)議保險(xiǎn)標(biāo)的交易渠道資源與理賠相關(guān)的活動及各理賠環(huán)節(jié)理賠保險(xiǎn)公司的有形資產(chǎn)和無形資產(chǎn)信息與客戶之間資金或非資金活動的信息與客戶交易或接觸的渠道信息任何市場化的產(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)的一系列事件事件BI.Insurancei.DWMforP&C底層數(shù)據(jù)模型主題域說明：Agreement：保單、批單申請及管理；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：活動管理PhysicalObject：實(shí)物、標(biāo)的管理BI.Insurancei.DWM-AgreementBI.Insurancei.DWM-ClaimBI.Insurancei.DWM-PhysicalObject日程為什么需要模型模型的組織結(jié)構(gòu)模型實(shí)施方法模型設(shè)計(jì)策略Q&A|表級映射字段映射實(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文檔：源-模型對應(yīng)關(guān)系A(chǔ)篩選：去掉ETL需要而模型不需要的字段1.邏輯模型2.物理模型3

邏輯物理數(shù)據(jù)元素對照表設(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程序開發(fā)測試數(shù)據(jù)加載1.多維模型設(shè)計(jì)文檔：維度指標(biāo)派生指標(biāo)2.需求-模型映射文檔3.報(bào)表樣張4.操作說明數(shù)據(jù)篩選：1.表一級篩選2.字段級篩選數(shù)據(jù)篩選：1.模型的數(shù)據(jù)篩選2.ETL映射數(shù)據(jù)篩選EDW具體實(shí)施流程日程為什么需要模型模型的組織結(jié)構(gòu)模型實(shí)施方法模型設(shè)計(jì)策略Q&A|Hashcode問題的提出:進(jìn)行增量加載時(shí)無法快速判斷對表的原有記錄是否新插入。例如：1.理賠案件發(fā)生的時(shí)候,增量文件會把保單數(shù)據(jù)也傳來2.保單增量過來,可能只是投保人的信息改了,而目標(biāo)保單表所需信息并沒有改變解決方案：使用增量的比較字段生成Hashcode。在對表進(jìn)行增量加載時(shí)，對增量文件中的每一條記錄生成Hashcode將生成完的Hashcode與原表中同一anchorid并且最新的記錄的Hashcode進(jìn)行比較如果一致的話，即不動作；如果不一致的話，即新插入。使用示例：在individualagreement表中使用各個(gè)需要保留歷史信息的字段生成hashcode。在增量加載時(shí)，使用業(yè)務(wù)增量文件中的字段生成hashcode。與Individualagreement表中同一agreementid的最新記錄的hashcode進(jìn)行比較。如果一致，即不動作如果不一致，則插入新記錄。備注：relationship表是要根據(jù)業(yè)務(wù)去判斷是否關(guān)系已經(jīng)存在，然后，如果有其他屬性（如：Roleplayer-PhysicalobjectRlship.Usage），才需要用hashcode判別是否重復(fù)。|Hashcode字段組成規(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í)體對于需要保留歷史的關(guān)聯(lián)類型，除Identifier、Partitionkey、Natureid、Leftanchoridentifier、Rightanchoridentifier、Leftentityidentifier、Leftentitytypeid、Rightentityidentifier、Rightentitytypeid、Validfromdate、Validtodate、Effectivefromdate、Effectivetodate、Populationtimestamp之外的所有字段|Partitionkey問題的提出:在進(jìn)行多表關(guān)聯(lián)時(shí)，所涉及的關(guān)聯(lián)表行數(shù)巨大，關(guān)聯(lián)速度達(dá)不到要求。解決方案：在所有大表中建立Partitionkey,按照該鍵的鍵值對表進(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)||對保單和理賠狀態(tài)的特殊處理問題的提出：保單在承保和保全的整個(gè)過程中狀態(tài)變化比較多，如按照IIW的原有設(shè)計(jì)，保單表中的會有巨量的歷史記錄；理賠在報(bào)案、立案和估損的整個(gè)過程中狀態(tài)變化較多，如按照IIW的原有設(shè)計(jì)，理賠表中會有很多的歷史記錄。解決方案：將保單的狀態(tài)變化過程剝離出來單獨(dú)建表，在該表中保留與保單的關(guān)聯(lián)；當(dāng)有新狀態(tài)插入時(shí)，更新對應(yīng)的保單表中的狀態(tài)。將理賠的狀態(tài)變化過程剝離出來單獨(dú)建表，在該表中保留與理賠的關(guān)聯(lián)；當(dāng)有新狀態(tài)插入時(shí)，更新對應(yīng)的理賠表中的狀態(tài)。使用示例：增加Commercialagreementstatus，Groupagreementstatus，Individualagreementstatus表，分別記錄Commercialagreement,Groupagreement,Individualagreement的狀態(tài)變化歷史。當(dāng)前面狀態(tài)發(fā)生該變時(shí)，在status表中插入新記錄，更新對于原表中的狀態(tài)字段。對保單和理賠狀態(tài)的特殊處理示例|IndividualagreementIndividualagreementstatusLeft/RightEntityIDinRelationshiporRoleEntity問題的提出在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會有多條記錄，如何找到當(dāng)時(shí)的記錄，必須通過effectivefrom/todate的比對才能實(shí)現(xiàn)，這非常影響效率。解決方案在關(guān)聯(lián)實(shí)體中增加Left/Rightentityidentifier，Left/RightentitytypeidLeft/Rightentitytypeid是指具體基礎(chǔ)表的id號例如：Roadvehicle（2001260001）Left/Rightentityidentifier是指具體基礎(chǔ)表中記錄的主鍵id值例如：Roadvehicle中牌照號滬A－000001車輛的第一條記錄的Roadvehicleid值適用范圍：FSRolePhysicalobject-AgreementRlship|SampleofLeft/RightEntityIDinRelationshiporRoleEntity|RoadvehicleIndividualagreementAgreementPhysicalobjectPhysicalobject–AgreementRlship被保標(biāo)的Partyroleinoperation/Internalperson問題的提出在業(yè)務(wù)中有很多操作員角色，只有工號、姓名信息，沒有身份證等其他信息；一個(gè)操作員在一個(gè)業(yè)務(wù)流程中會同時(shí)扮演不同角色，如在A保單核保中他是錄入人，在B保單核保中他是復(fù)核人或者可能出現(xiàn)在A保單核保中他既是錄入人又是復(fù)核人解決方案建立Internalperson表保存業(yè)務(wù)員、公司管理人員的個(gè)人信息，這些信息質(zhì)量較差建立Partyroleinoperation表保存操作員角色信息，每次都生成新記錄。錄單員冗余到保單中，理賠的操作員也冗余到claimfolder中|Roleplayer-ActivityRlshipPartyroleinoperation（Roleplayerid

）InternalPerson（Roleplayerid）FinancialServicesRole關(guān)聯(lián)實(shí)體的版本問題由于關(guān)聯(lián)實(shí)體本身沒有對應(yīng)的anchor實(shí)體，不存在版本問題，但是關(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％|FinancialServicesRole問題的提出Person存放人的基本信息，Externalorganisation和Internalorganisation存放機(jī)構(gòu)的基本信息一個(gè)人和機(jī)構(gòu)在不同環(huán)境下分別扮演不同角色，所以FinancialServicesRole存放與保單（各種協(xié)議）相關(guān)的金融服務(wù)角色，如保單持有人，被保險(xiǎn)人，受益人等。Channelrole存放中介渠道角色信息，如營銷員、收展員在分析集市中需要獲取保單與業(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解決方案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）Currencycode問題的提出：在CPIC的實(shí)際業(yè)務(wù)中，可能出現(xiàn)多幣種，在統(tǒng)計(jì)中需要進(jìn)行多幣種的轉(zhuǎn)換。解決方案：在IIW模型中凡出現(xiàn)金額字段的表，都增加金額的幣種及對應(yīng)的RMB金額兩類字段。原字段存放原幣中金額，RMB金額存放折算成RMB的金額使用示例：Elementaryclaim表中增加Totalcostcurrency和TotalcostRMB字段備注：由于CPIC對多幣種金額的統(tǒng)計(jì)有多種統(tǒng)計(jì)方式，不全部是按照發(fā)生制來折算RMB的。因此，統(tǒng)計(jì)轉(zhuǎn)換金額到RMB的工作，留給統(tǒng)計(jì)部分執(zhí)行，在原子層不計(jì)算。幣種一定要填。|維度表的snapshot問題的提出在分析層中，常用的維度表如：保單、立案。分析常用的屬性是分散在各個(gè)表中的，如：保費(fèi)、保額在ParticularMoneyProvision中。分析時(shí)如果再通過關(guān)聯(lián)來找到這些信息，效率非常低。解決方案建立維度的snapshot表，將這些信息冗余存放在這些表中，每個(gè)月全量刷新一次。使用示例：ClaimfolderdimensionPolicydimensionElementaryclaimdimensionEventdimension|Commercialagreement/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ù)國內(nèi)系統(tǒng)的情況做了些調(diào)整，和機(jī)構(gòu)投保人（非個(gè)人）簽訂的個(gè)單也存放在此。投保單按保單處理，只是狀態(tài)是投保狀態(tài)|Groupagreement/Individualagreement在ETL時(shí)處理車險(xiǎn)系統(tǒng)保單進(jìn)入Individualagreement壽險(xiǎn)保單根據(jù)來源表，決定進(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|最新記錄標(biāo)志Effectivetodate=‘9999/12/3100:00:00’|公司的拆分合并，partitionkey的處理–1/4分公司的拆分合并，不需要程序考慮，發(fā)生后手工處理。公司合并舉例：原來有分公司A,分公司B,在2006/1/1分公司B合并到分公司A。|合并前PartitionconfigExternalorganisationIndividualagreement公司的拆分合并，partitionkey的處理–2/4公司合并舉例：原來有分公司A,分公司B,在2006/1/1分公司B合并到分公司A。|合并后PartitionconfigExternalorganisationIndividualagreementRoleplayerRlship公司的拆分合并，partitionkey的處理–3/4公司合并舉例：原來有分公司A,在2006/1/1分公司A,拆分成分公司A和分公司B。|拆分前PartitionconfigExternalorganisationIndividualagreement公司的拆分合并，partitionkey的處理–4/4公司合并舉例：原來有分公司A,在2006/1/1分公司A,拆分成分公司A和分公司B。|拆分后PartitionconfigExternalorganisationIndividualagreementRoleplayerRlship按照typeid分表將有些大表按照Typeid進(jìn)行拆分舉例：Individualagreement表按照保單和投保單拆成兩張表|歷史信息的處理對含有歷史記錄的大表，應(yīng)考慮將歷史記錄剝離出來單獨(dú)建表，即原表保留最新的信息，而在剝離出來的表中包含這些信息的變化歷史。舉例：

Individualagreement原來保留有保單的最新信息及這些信息的歷史變化記錄。這樣這張表就將很大，記錄數(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)。例如：sellingchannelroleid在individualagreement表中的冗余。否則，要走FSRole連接channelrole。盡可能減少關(guān)聯(lián)的層級。即減少不必要的關(guān)聯(lián)中間表例如：如保單的操作員直接建立到保單中，保單和理賠的科室、部門直接建立到保單和理賠中。備注：m:m的關(guān)系必須走關(guān)聯(lián)表。|模型優(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,|EDW和ODS的關(guān)系Person、Externalorganisation、FSRole（投保人/被保人）通過ODS產(chǎn)生由于加載順序的關(guān)系，保單表由業(yè)務(wù)系統(tǒng)產(chǎn)生，產(chǎn)生保單信息時(shí)，ODS數(shù)據(jù)還沒有加載。因此，Individualagreement中的Policyholderid、Groupagreement中的Policyholderorganisationid不冗余產(chǎn)生，而是通過FSRole走。|Id產(chǎn)生規(guī)則每個(gè)表單獨(dú)使用id序列建id序列表|Anchor表是否需要物理產(chǎn)生建物理產(chǎn)生Anchor表所有和Anchor直接外鍵關(guān)聯(lián)的typeid冗余|Person歸并決策Person，externalorganisation在EDW不再進(jìn)行歸并|Boolean0false1true|AtomicderiveddataAtomic層表中，有部分字段保存的是從其他表或字段中導(dǎo)出的數(shù)據(jù)，如：claimfolder中totalcost，是從internalclaimcost中統(tǒng)計(jì)來的。對于這部分字段，分為兩部分：目前analytical層或datamart用到的，需要處理暫時(shí)沒用的字段，暫不處理這部分字段的處理，在atomic產(chǎn)生完成后，產(chǎn)生analytical層前處理。|AtomicAnalytical12物理分表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)來源的：Premiumpayment賠款來源的：ClaimpaymentPaymentdue保費(fèi)來源:Premiumpaymentdue賠款來源:ClaimpaymentduePhysicalobjectOtherphysicalobjectGeneralcargo2000850001：Cargo

Machineitem2000850004：MachineStructureDwelling2000890001：Dwelling

Hotel2000890003:Hotel

Platform2000890004:Platform|備注：沒特別注明的其他類型的在原Entity中MoneyschedulerMoneyinscheduler用于連接對于保險(xiǎn)公司來說是進(jìn)來的錢的particularmoneyprovision/Financialtransaction，如：保費(fèi)、儲金（包括批增、批減）Moneyoutscheduler用于連接對于保險(xiǎn)公司來說是出去的錢的particularmoneyprovision/Financialtransaction，如：賠款、支付的養(yǎng)老金（包括攤回賠款）每個(gè)保單簽單產(chǎn)生一個(gè)Moneyinscheduler，保單不含批單的保額、保費(fèi)掛在該Moneyinscheduler下；每個(gè)批單單產(chǎn)生一個(gè)Moneyinscheduler，該批單對應(yīng)的保額、保費(fèi)變化掛在該Moneyinscheduler下。每個(gè)賠案產(chǎn)生一個(gè)Moneyoutscheduler，該賠案對應(yīng)的Particularmoneyprovision掛在該Moneyoutscheduler下。|關(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.活動地點(diǎn)Activity-PlaceRlship.Nature_id=

查勘地點(diǎn)2000030004

工程作業(yè)地域2000030005

建造地點(diǎn)2000030006

交船地點(diǎn)2000030007

直接挪到Particularactivity.活動地點(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)港

加代碼字段和名稱字段

如果有超過2個(gè)的中轉(zhuǎn)港，則走原有關(guān)聯(lián)表ActivityClaimcheckOperationroleplayerid執(zhí)行人ActivityClaimcheckReviewroleplayerid復(fù)核/審核人ActivityUnderwritigcheckOperationroleplayerid執(zhí)行人ActivityUnderwritigcheckReviewroleplayerid復(fù)核/審核人AgreementChangerequestOperationroleplayerid操作員代碼AgreementGroupagreementOperationroleplayerid原通過Financialservicerole關(guān)聯(lián)保單和Partyroleinoperation,現(xiàn)在直接將操作員id冗余進(jìn)Groupagreement表中AgreementGroupagreementDepartmentid保單部門，原先必須通過與Party主題關(guān)聯(lián)得到，現(xiàn)在增加冗余|關(guān)聯(lián)表冗余進(jìn)實(shí)體表中－2/2SubjectareaEntity加字段備注AgreementGroupagreementSectionid科室代碼，原先必須通過與Party主題關(guān)聯(lián)得到，現(xiàn)在增加冗余AgreementIndividualagreementOperationroleplayerid原通過Financialservicerole關(guān)聯(lián)保單和Partyroleinoperation,現(xiàn)在直接將操作員id冗余進(jìn)Individualagreement表中AgreementIndividualagreementDepartmentid保單部門，原先必須通過與Party主題關(guān)聯(lián)得到，現(xiàn)在增加冗余AgreementIndividualagreementSectionid科室代碼，原先必須通過與Party主題關(guān)聯(lián)得到，現(xiàn)在增加冗余AgreementIndividualagreementCommercialagreementid到commercialagreement的直接關(guān)聯(lián)FinancialtransactionPaymentAgreementrequestid批單號FinancialtransactionPaymentAgreementrequesttypeid批單表typeid類型FinancialtransactionPaymentdueAgreementrequestid批單號FinancialtransactionPaymentdueAgreementrequesttypeid批單表typeid類型PaymentPaymentPayment.Agreementid協(xié)議號PaymentPaymentPayment.Agreementtypeid協(xié)議類型PaymentPaymentduePaymentdue.Agreementid協(xié)議號PaymentPaymentduePaymentdue.Agreementtypeid協(xié)議類型PhysicalobjectPhysicalobject-Registrationrlshipship.船籍(代碼)船籍2000790001|Anchor的typeid冗余到外鍵關(guān)聯(lián)的表中-1/2AnchorEntity新增冗余字段AccountaccountentryaccounttypeidActivityMarketingobjectiveMarketingactivitytypeidActivityParticularmoneyprovisionactivitytypeidAgreementFinancialservicesroleContextfinancialservicesagreementtypeidAgreementStatementelementAgreementtypeidAgreementMoneyschedulerAgreementtypeidAgreementGenericmoneyprovisionAgreementtypeidAgreementParticularmoneyprovisionAgreementtypeidAgreementReinsurancefinancialentryAgreementtypeidAgreementReinsurancepremiumdetailAgreementtypeidAgreementClaimindemnitydetailAgreementtypeidClaimPartyroleinclaimContextclaimtypeidClaimClaimindemnitydetailClaimfolderanchortypeidClaimReinsuranceindemnitydetailClaimfolderanchortypeid|Anchor的typeid冗余到外鍵關(guān)聯(lián)的表中-2/2AnchorEntity新增冗余字段ClaimClaimindemnitydetailElementaryclaimanchortypeidClaimReinsuranceindemnitydetailElementaryclaimanchortypeidPartyAccountproviderAccountproviderroleplayertypeidPartyChannelroleplayeridChannelroleplayertypeidPartyCustomerCustomerroleplayertypeidPartyEmploymentroleEmploymentroleplayertypeidPartyFinancialservicesroleFinancialservicesroleplayertypeidPartyPartyroleinagreementrequestRequestpartyroleplayertypeidPartyPartyroleinclaimClaimpartyroleplayertypeidPartyPartyroleinlegalactionLegalactionpartyroleplayertypeidPartyProviderroleProviderroleplayertypeidPartyParticularmoneyprovisionMoneypayeetypeidPartyParticularmoneyprovisionMoneypayertypeidPhysicalobjectMarketableobjectTradeablephysicalobjecttypeid|Claim中涉及的各種金額存放規(guī)則－1/2|Claim中涉及的各種金額存放規(guī)則－2/2Particularmoneyprovision對應(yīng)賠案級，其中不存放金額，起關(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)是未決的）Inter