數據倉庫實踐系列課程第二課

衣帶漸寬終不悔，為伊消得人憔悴王國維在《人間詞話》說：“古今之成大事業、大學問者，必經過三種之境界：‘昨夜西風凋碧樹。獨上高樓，望盡天涯路’。此第一境也。‘衣帶漸寬終不悔，為伊消得人憔悴。’此第二境也。‘眾里尋他千百度，驀然回首，那人卻在，燈火闌珊處’。此第三境也。”

王國維認為治學第一境界：“昨夜西風凋碧樹。獨上高樓，望盡天涯路”，這詞句出晏殊的《蝶戀花》，原意是說，“我”上高樓眺望所見的更為蕭颯的秋景，西風黃葉，山闊水長，案書何達？在王國維此句中解成，做學問成大事業者，首先要有執著的追求，登高望遠，瞰察路徑，明確目標與方向，了解事物的概貌。

王的治學第二境界是說：“衣帶漸寬終不悔，為伊消得人憔悴。”這引用的是北宋柳永《蝶戀花》最后兩句詞，原詞是表現作者對愛的艱辛和愛的無悔。若把“伊”字理解為詞人所追求的理想和畢生從事的事業，亦無不可。王國維以此兩句來比喻成大事業、大學問者，不是輕而易舉，隨便可得的，必須堅定不移，經過一番辛勤勞動，廢寢忘食，孜孜以求，直至人瘦帶寬也不后悔。

王的治學第三境界是說：“眾里尋他千百度，驀然回首，那人卻在，燈火闌珊處。”是引用南宋辛棄疾《青玉案》詞中的最后四句。王國維以此詞最后的四句為“境界”之第三，即最終最高境界。要達到第三境界，必須有專注的精神，反復追尋、研究，下足功夫，自然會豁然貫通。課程安排（一）總學時：15學時，其中12學時理論，3學時聯系，課后作業估計有5學時（二）考核方法：平時考勤：30分理論答題：30分隨堂練習：20分課后作業：20分（三）教材《數據倉庫生命周期工具箱》kimball等著，清華大學出版社《數據倉庫工具箱》-維度建模權威指南，kimball等著，清華大學出版社（四）教學方法講師講解課程，布置家庭作業（利用網絡資源完成講師制定任務）；隨堂作業，現場完成作業結業考試，檢查教學成果綜合練習，提升學習成果目23456TeradataFS_LDM模型介紹IBMIIW模型介紹維度模型設計第三范式模型設計匯聚數據財富

挖掘潛力無限錄數據建模導論1SysbaseIWS模型介紹7案例-模型案例說明第5頁目錄IBM與聯動優勢公司項目機密II數據模型方法論I客戶洞察III數據模型建設路徑IV數據模型關鍵成果V項目交付件I數據模型概述數據建模導論-主要內容數據模型是對現實世界數據特征的抽象，搭建了從業務到應用的橋梁

業務數據根據信息需求抽象出邏輯數據，定義其描述、分類與關系業務人員提出業務需求，并描述業務需求所需的信息內容應用針對業務和數據特性組合應用架構，支撐實際業務應用CustomerDataProductDataAccountDataTransactionData業務人員技術人員數據建模基本概念定義重要的業務概念和彼此的關系，如客戶、供應商、合作伙伴、產品、合同、渠道、財務等。企業級概念數據模型關于整個企業需要信息的完整模型，包含了數據實體和實體間的關系、屬性、定義、描述和范例。企業級邏輯數據模型定義某系統重要的業務對象之間的本質聯系，包含了數據實體和實體間的關系、屬性、定義、描述和范例。可擴展為企業級數據模型。系統邏輯數據模型企業級邏輯數據模型（LDM）戰略規劃運營管理發展方向業務開拓企業級概念數據模型（CDM）業務需求系統邏輯數據模型（LDM）技術應用物理數據模型（PDM）數據模型在企業中的位置數據模型是從應用需求，數據定義到數據倉庫設計和建設的藍圖。通過數據關系展現業務過程，是將現實世界的業務概念與信息世界的數據應用相關聯的工具。是數據管理、數據分析和交流的重要手段。市場為導向客戶為中心效益為目標建立數據模型的重要意義9企業數據模型優化數據架構完善數據標準提升數據質量指導數據標準框架建設指導數據標準中信息屬性制定形成企業主題域數據模型根據數據主題調研數據分布，規劃可信數據源統一指導應用建設，增強數據一致性協助進行數據質量問題分析，發現問題原因建立數據模型的重要意義第10頁目錄IBM與聯動優勢公司項目機密II數據模型方法論I客戶洞察III數據模型建設路徑IV數據模型關鍵成果V項目交付件I數據模型概述數據建模導論-主要內容IBM數據模型方法論-五大層級、九大主題A：可以用九大數據概念來描述B：用層次化的概念術語來組織業務信息，采用業務人員熟悉的語言C：用ER圖描述業務信息，不考慮實施層面的約束，只維護邏輯視圖C‘用ER圖描述應用數據，考慮具體實施層面的約束，引入派生數據或去范式化的數據D：描述物理數據結構，考慮系統部署層面的約束ALevelBLevelCPrimeLevelDLevelCLevel參與人合約條件產品位置分類業務方向m事件資源項針對數據庫特性將數據邏輯物化為數據庫表，支撐實際應用根據數據實體描述、分類，抽取出數據邏輯，并利用ER圖描述其關系根據業務對象抽象出數據概念和數據實體，定義其描述、分類與關系數據模型建設思路數據需求概念數據模型（CDM）邏輯數據模型（LDM）根據業務對象抽象出數據概念和數據實體，定義其描述、分類與關系業務人員提出業務需求，并描述業務需求所需的數據內容根據數據實體描述、分類，抽取出數據邏輯，并利用ER圖描述其關系物理數據模型（PDM）針對數據庫特性將數據邏輯物化為數據庫表，支撐實際應用CustomerDataProductDataAccountDataTransactionData業務人員技術人員業務使用數據模型客戶信息數據模型財務管理數據模型……1、EDM實體模型4、PDM物理模型3、LDM邏輯模型2、CDM概念模型數據模型設計流程數據模型1,EDM層面的實體模型代表了對業務最重要的信息屬性，是建立基礎數據模型的基本流程。描述了最重要的業務概念和應用實體。2,CDM層面的數據模型其實是EDM的業務屬性描述，細化分解了EDM的具體定義和概念組合。3,LDM則是CDM的進一步解釋說明，描述了詳細的邏輯關系和相關屬性字段。4,PDM是在數據庫中的實體物理模型，包含了具體的表定義，模式定義等。數據模型建設原則以及相應決策點14正確性和完整性通用性可操作性數據模型應包含正確并且全面的業務概念，支持相關的業務活動。企業數據模型應支持業務規則的多變性，以最少的改動支持業務規則的變動。相應決策點企業數據模型應便于應用，可與日常操作和實例容易結合。決策點一：業務人員幫助提供和完善業務概念定義。決策點二：數據模型的詳細程度滿足數據分析要求相應決策點決策點三：關注數據的當前狀態。決策點四：各主題數據與數據間的關系盡量在父類建立，并通過關系類型的定義說明各類關系。相應決策點決策點五：從對象封裝角度看到的有共性的數據概念，可封裝成同一父類數據實體。前瞻性企業數據模型除了支持現有的業務與數據需求外，還應在一定程度上支持行業先進概念與企業未來的需求。相應決策點決策點六：借鑒參考模型決策點七：以融合前瞻性的業務需求作為數據模型的輸入關聯性模型中的數據與數據間應有關聯性。孤立的數據所體現的價值往往少于相關聯的數據，數據間的關聯性可加強數據用于未來分析的價值。相應決策點決策點八：數據實體的主鍵為無業務含義的代理標識，方便體現數據與數據間應有的關聯性。第15頁目錄IBM與聯動優勢公司項目機密II數據模型方法論I客戶洞察III數據模型建設路徑IV數據模型關鍵成果V項目交付件I數據模型概述數據建模導論-主要內容源系統入倉梳理數據中心應用需求業務應用需求源系統表級、字段級分析重要參考九大數據概念的分類、描述和關系映射篩選分析數據中心邏輯數據模型固定報表、管理駕駛艙、KPI需求源系統調研IBM參考模型七大主題：當事人產品渠道協議事件營銷財務數據中心LDM數據中心邏輯模型建設路徑數據模型主題視圖設計

隨著模型設計工作的進行，模型中的實體會越來越多，因此需要根據不同的分類創建主題視圖，將實體進行歸納。通常每個主題主要包括如下主題視圖：存放該主題的關系實體，特別是和其他主題的關聯關系存放該主題中的重要歷史實體存放主題中核心實體的分類樹存放該主題的重要實體，能反應主題的大致內容概述分類關系重要歷史數據模型信息加工規則在邏輯模型設計時，我們需要將信息加工成子實體集、屬性、歷史表或關系表，加工規則如下：個人規則1：

加工成屬性學歷（大專，本科，研究生）個人規則2：

加工成子實體集研究生本科生大專生規則3：

加工成歷史表個人當事人學歷信息歷史學歷代碼表規則4：

加工成關系表個人當事人協議關系歷史協議數據模型信息加工原則加工成屬性規則1僅表達某一實體實例的組成要素信息，沒有更多的信息要表達，如商戶的商戶類型代碼處理成商戶實體的屬性，性別處理成人個人實體的屬性。加工成子實體集規則2每個分類項都有足夠的個性信息需要承載，而且分類項之間的特色和差異比較明顯，用子實體來描述各分類項。例如通過自然屬性的分類，建立個人子實體和機構子實體。加工成歷史表規則3某一實體關鍵屬性會發生變化，并需要追溯其歷史。則建立帶有拉鏈的歷史表承載變化的描述信息，如：“當事人狀態歷史”和“當事人狀態代碼表”，“當事人重要日期歷史”和“日期類型代碼表”。加工成關系表規則4關系表主要體現這7大主題之間的以及主題內部的關系，由業務規則和源系統兩方面的信息決定。如果主題之間或主題內部在業務規則上有約束或聯系存在，則需建立關系實體。例如：協議的開通與當事人和產品有關，則建立當事人協議關系，協議產品關系。而當事人與產品之間并強關聯性，則無需建立當事人產品關系。如果有分析需求，則通過當事人協議關系，協議產品關系，找到當事人產品關系。第20頁目錄IBM與聯動優勢公司項目機密II數據模型方法論I客戶洞察III數據模型建設路徑IV數據模型關鍵成果V項目交付件I數據模型概述數據建模導論-主要內容數據模型總體架構數據模型設計充分參考了源系統信息調研的結果和應用需求的反饋，在此基礎之上形成了LDM的5五大主題，包括：當事人、產品、協議、事件、渠道。新系統數據入倉后，再實現營銷和財務主題：數據模型主題描述-當事人當事人當事人是指UMPAY關注，并且需要記錄其信息的任何一個人或一組人。當事人主題可包含通過各種途徑和方式購買UMPAY產品、接受UMPAY服務來滿足其需求的個人或組織；和UMPAY有其他業務往來的對象；UMPAY出于營銷、管理等目的而需要分析的對象；也包含UMPAY內部的組織機構和員工。目前數據模型中，當事人主題包括UMPAY的用戶，商戶，合作伙伴，員工，內部機構等。當事人主題將針對這些對象存放其基本的屬性信息、聯系信息、鑒別信息、狀態信息等。分類視圖第一層：個人和機構。第二層：外部機構和內部機構，員工、用戶和合作方。第三層：通道用戶和自有用戶歷史視圖當事人名稱歷史當事人狀態歷史當事人重要日期歷史當事人等級歷史當事人鑒別信息歷史當事人限額歷史當事人地址歷史當事人余額歷史關系視圖當事人協議關系歷史當事人關系歷史渠道當事人關系歷史當事人業務線產品組關系歷史當事人主題視圖說明：灰色表示僅邏輯化處理的實體數據模型主題描述-產品產品主題

產品是指提供給市場，能滿足客戶的某種需求，可從中賺取實際或潛在收益的各種貨物（有形）與服務（無形）。UMAPY的產品是指UMAPY獨立開發的或基于商戶的商品而衍生出來，用于向客戶（用戶）提供，滿足用戶需求的，并為UMAPY帶來收益的產品。該主題記錄了產品的名稱，價格，付費方式以及產品源于商戶的信息。商戶的商品是UMPAY產品的衍生基礎，因此也屬產品主題范疇，但僅作為商品存放，而不作為產品。即商品不是UMPAY的產品，而是產品的重要組成部分。例如金山殺毒軟件是金山公司這一商戶的商品，而“通過北京移動話費購買金山公司的金山殺毒軟件”則是UMPAY的產品。分類視圖第一層：支付產品和業務產品。第二層：業務產品分科技產品和電商產品第三層：按業務線分為通信賬戶產品、EPS產品等歷史視圖產品狀態歷史產品名稱歷史產品價格歷史關系視圖協議產品關系歷史產品渠道關系歷史產品產品組關系歷史產品主題視圖數據模型主題描述-協議協議主題協議是兩個或兩個以上當事人之間潛在或實際的約定，協議正式提供并確認與協議目的相關的規則和義務。協議主題包含了當事人之間達成的合約，這些合約可以是文本的也可以是電子的。通常情況下協議的子類是按照協議性質用途劃分，主要包括：（1）產品協議，即：識別兩個當事人之間關于產品購買的協議。該協議明確其中一方自另一方取得產品使用權，一個產品可對應多個產品協議。（2）合作協議，即：企業和其他機構之間的合作項目簽訂的協議。（3）雇傭合同，即指企業雇傭員工的協議。UMPAY的數據模型中，目前協議主題僅是關于產品的協議，包含客戶（用戶）在購買產品時與UMPAY達成的各種合約，例如：包月服務協議、公共事業繳費協議、空充業務協議等。該主題記錄了協議生效日期，有效期，涉及金額等信息。分類視圖第一層：支付協議和業務協議。第二層：按業務線分為包月協議、資金歸集協議等歷史視圖協議狀態歷史協議重要日期歷史協議金額歷史關系視圖協議產品關系歷史協議渠道關系歷史協議關系歷史當事人協議關系歷史協議主題視圖數據模型主題描述-渠道渠道主題渠道指在多個當事人之間為了特定目的傳遞信息或產品的通道，渠道是直接或間接進行產品服務、客戶溝通、產品銷售的途徑。渠道主題包含了業務開展過程中的各種關注的接觸渠道信息。UMPAY的接觸渠道可以是產品的銷售渠道、可以是業務辦理過程中的接入渠道也可以是某業務的支付渠道。用戶通過這些渠道獲取產品信息、進行業務交易。支付渠道主要記錄各業務條線在進行支付時使用的渠道，例如：IPS，嗖付工行網銀，手機銀行卡工行網銀，北京移動等；接入渠道主要是從技術的口徑定義的發生一筆業務時的接入渠道，例如：發生一筆手機繳話費業務時，其接入渠道可以來自網銀，IVR或UMPAY統一分配的短信渠道；銷售渠道主要指UMPAY將產品掛接在某WEB頁面上供客戶瀏覽購買用的URL地址。分類視圖支付渠道、接入渠道和銷售渠道歷史視圖渠道狀態歷史關系視圖協議渠道關系歷史渠道當事人關系歷史產品渠道關系歷史渠道主題視圖數據模型主題描述-事件事件主題事件是指業務運營過程中希望記錄的已發生或將發生的事情。事件主題包含了UMPAY關注的活動明細信息，例如：UMPAY在業務開展過程中的支付行為、客戶購買產品時下訂單進行交易，UMPAY與商戶或銀行的對賬活動。每一個活動記錄將包括涉及的當事人、發生的時間、交易的產品和使用的支付渠道，以及涉及的金額等重要信息。分類視圖訂單交易支付退款對賬差錯其他（風控、客服、OA）事件主題視圖第32頁目錄IBM與聯動優勢公司項目機密II數據模型方法論I客戶洞察III數據模型建設路徑IV數據模型關鍵成果V項目交付件I數據模型概述數據建模導論-主要內容數據模型設計項目最終成果文檔序號文檔名稱用途描述1UMP_EDW_LDM.erwin展現邏輯數據模型視圖2UMP_LDM_翻譯.xls實體和屬性的翻譯3UMP_EDW_代碼表加載.xls需要硬編碼的代碼表梳理4UMP_EDW表和字段級分析_XX系統_.xlsx源系統入倉調研和映射信息5UMP_數據模型設計規范.doc數據模型設計規范描述6UMP_EDW邏輯數據模型設計說明書_總冊.doc邏輯數據模型的總體架構、原則7UMP_EDW邏輯數據模型設計說明書_XX分冊.doc詳細闡述各主題的設計思想和內容目23456TeradataFS_LDM模型介紹IBMIIW模型介紹維度模型設計第三范式模型設計匯聚數據財富

挖掘潛力無限錄數據建模導論1SysbaseIWS模型介紹7案例-模型案例說明35TeradataFS-LDM介紹主要內容邏輯數據模型基本概念NCR

FS-LDM

LDM定制化工作步驟36數據倉庫數據倉庫與數據庫的區別數據庫系統（生產系統）：面向應用、事務驅動的實時性高數據檢索量少只存當前數據數據倉庫系統（決策系統）：面向主題、分析和決策實時性要求不是特別高數據檢索量大存儲大量的歷史數據和當前數據以銀行為例儲蓄客戶對公信用卡其他產品渠道交易機構37數據倉庫系統數據流規劃ETL服務器數據清洗／轉換／加載文本文件儲蓄信用卡對公總帳數據源面向應用3NF數據集市DataMart最終用戶銀行邏輯數據模型保留詳細交易數據面向主題3NF建模LDMLDM面向分析主題匯總數據StarSchema建模數據倉庫38數據組織的基礎與目標保留詳細交易數據數據一次導入，多次使用保證數據的一致性數據跨業務系統和業務平臺集成銀行所有的數據業務用戶對數據有一致的、統一的理解邏輯數據模型（LDM）39用圖形的方式展現業務規則由一系列表和實體詳細描述組成數據倉庫組織數據的方法是IT人員和業務人員溝通的工具獨立于技術邏輯數據模型基本概念邏輯數據模型是用來發現、記錄和溝通業務,展現業務規則的詳細“藍圖”。40客戶/團體(party)PartyId(PK)______________PartyNameEventId(PK)__________________TransactionTypeTransactionAmountAccountId(FK)交易/事件(event)帳戶(ACCOUNT)AccountId(PK)__________________AccountTypeAccountOpenDateAccountCloseDateisholderofhasactivityof業務規則:

一個客戶擁有一個或多個帳戶

一個帳戶可能被一個或多個客戶持有.

一個帳戶可能與一個或多個交易／事件相關一個交易事件只涉及一個帳戶P實體(Entity)

關系(Relationship)屬性(Attributes)主鍵(KeyAttribute)邏輯數據模型舉例1:MN:M41LDM的益處是當前和未來數據的集成藍圖是實現業務智能(BusinessIntelligence)的基礎用統一的邏輯語言描述業務系統的規則能更好的控制數據冗余便于開發人員和業務人員進行業務溝通能約束數據倉庫開發處理流程的行為規范，為數據倉庫的開發提供一種穩定的、長期的、可靠的和精確的技術準則。

是物理數據庫設計的基礎42LDM設計方法與原則LDM建模方法第三范式（3NF）星型結構（StarSchema）雪花狀結構（SnowflakeSchema）LDM設計原則采用第三范式（3NF）設計利用業界已成功的模型－NCRFS-LDM3NF基礎數據模型StarSchema匯總數據/已知應用模型Snowflake星型結構的演變43TeradataFS-LDM介紹主要內容邏輯數據模型基本概念NCR

FS-LDM

LDM定制化工作步驟44NCR

FS-LDM全球二百多家金融機構經驗的總結描述了銀行的各類業務以及這些業務之間的關系，通過定義實體、實體的屬性以及實體之間的關系來描述具體的銀行業務邏輯蘊含了現代商業銀行分析決策和客戶關系管理的各個方面是滿足第三范式（3NF）的數據模型高起點，縮短周期、降低風險、節約投資NCR金融業邏輯數據模型45NCRFS-LDM產品研發歷程1996199719981999200020012/96–研發開始4/96–產品驗證9/96–第一個客戶

2/00-獲得專利!12/00–版本4.0

-保險業務增強

-電子商務(點擊流分析)

-隱私功能(choice/consent)

-提供ImageMark接口2001版本5.0:

-商業銀行業務增強

-經紀/投資業務增強

-信用卡業務增強2002/2003:

-集團壽險

-健康險

-數據管理20028/97–版本1.0–銀行業務–服務支持12/98–版本2.0–功能增強–行為分析模型–服務支持5/99–版本2.111/99–版本3.0–增加保險業務–多幣種支持–貢獻度分析數據模型

-新巴塞爾協議支持46NCRFS-LDM八大主題地理位置地理區域，物理的或電子的地址.團體(Party)個人或團體機構事件一種資金或非資金的活動，可能需要也可能不需要銀行與客戶的直接接觸內部組織金融機構的分支機構及業務單元帳戶金融機構和客戶之間為某種產品或金融服務而設置的一種約定產品任何市場化的產品或服務，包括這些產品的條款和條件行銷活動為增加客戶、保留客戶、拓展業務而進行的策略、規劃或促銷事件渠道銀行同客戶交互或接觸的各種渠道47isdomiciledat/isvehicleformanages/managedbyoffersorservices/isofferedorservicedbyisdeliveredvia/isvehicleformaybea/isaZisinvolvedwith/involvestargets/istargetedbytargets/istargetforistargetfor/targetscanbecontactedat/iscontactforismarketedby/marketsisvehiclefor/isconductedviahasactivityof/involvesrepresents/isrepresentedbyusesormanages/isusedormanagedby團體

帳戶

事件渠道行銷活動地理位置

內部組織產品

Note:Notallrelationships

areshownNCRCONFIDENTIAL(RESTRICTED)FS-LDMRelease4.0主題之間的關系說明48FS-LDM10MajorSubjectAreasProductEventAgreementChannelPartyPartyAssetFinanceLocationCampaignInternalOrganization491.團體(Party)主題是客戶概念的外延可以是一個銀行外部或內部的組織機構可以是一個具備相同目的的個體組合，例如協會、社會團體、家庭、親友團、同學會等。Party的定義：

PARTY是指任意的個人或團體的金融業服務對象。比如：客戶、潛在客戶、國內組織、汽車商人、競爭者、雇員、分行、部門等等。501.Party主題的主要特點包括多種類型的個人和組織（客戶、潛在客戶、同業競爭者、特約商戶等）提供party之間的任意關系（父子關系、雇主與雇員關系、夫妻關系、雇員與分行的關系等）包括家庭關系、市場分類和人口統計特征。與其他主題的密切關聯

Party團體個人法人機構內部組織機構社團雇員家庭金融機構511.Party主題的主要實體521.國內銀行客戶分類示例個人組織個人個體工商戶企業法人公司類客戶房貸類客戶金融機構類客戶非法人單位事業單位及社會團體政府機關軍隊/武警53

包括產品和產品特性，通過產品特性來反映產品的特有屬性。產品特性包括利率、期限、數量、費用等。

可以包括競爭對手的產品或服務2.產品(Product)主題產品的定義：

PRODUCT是指銀行提供給金融服務對象的、市場化的、所有的產品和服務，包括這些產品的條款和條件。542.產品主題的主要特征可以組合成各種套裝產品產品與條款和條件相關聯產品及其特征可以按照內部管理的需要進行分組產品與其他主題都有關聯為了滿足市場銷售的需要，產品可以組合打包。為了滿足銀行內部的管理需求，產品也可以按照不同的方法進行分組。總的說來，產品有以下幾個特征:552.產品主題視圖產品特性描述成本利潤條款分類產品組產品包描述利率費用數量期限分類團體渠道關聯特性組特性間關系關聯地域產品特性相關信息562.產品主題主要實體572.國內銀行產品分類示例產品類存款貸款信用卡服務類委托及代理資金類（同業拆借）投資類其它表外業務產品包個人住房組合貸款本、外幣活期一本通境外籌資轉貸債務重組非產品類聯名卡／加油IC卡企業終端托收承付。。。583.帳戶(Account)主題帳戶的定義：

帳戶是金融機構與客戶之間針對某種特定產品或服務而簽立的契約關系帳戶的實質是一種合約（Contract）。銀行提供了某種產品（Product）或某種服務（Service），并給出了這種產品或服務的報價（Quotation），客戶（Customer）經過申請（Application）和還價（Bargain）后接受了該種產品或服務，這時，銀行就同客戶達成了一個協議（Agreement），這個協議就是帳戶。59包括多種類型帳戶，例如儲蓄帳戶、支票帳戶、定期存款帳戶、退休基金帳戶、貸款帳戶、信用卡帳戶、保險帳戶等。和其他主題都有關聯3.帳戶主題的主要特征帳戶這種客戶和金融機構之間的合約可能是面向利息的（貸款和存款等金融產品），也可能是面向費用的(保險箱，投資，保險等金融服務)。603.帳戶(Account)分類帳戶存款帳戶流動帳戶貸款帳戶定期活期定期活期金融帳戶投資帳戶保險箱帳戶613.帳戶主題的主要實體623.國內銀行帳戶分類示例帳戶外部帳內部帳資金帳戶投資帳戶虛擬帳戶存款帳戶貸款帳戶流動帳戶活期活期定期定期保證類結算類咨詢類保管類整整、整零、零整、存本取息、教育儲蓄、華僑等活期、定活、協定存款、通知存款當承兌匯票、信用證、保函等信用卡發放還款貸款展期以貸還貸額度貸款非表外代貸種63是party主題的子類型金融機構的分支機構及業務單元可以是正式組織：分行、分支機構、部門也可以是非正式組織：銷售區域、團隊等4.內部組織主題內部組織的定義：

是指金融機構的內部組織和業務單元，包括：分行、呼叫中心、銷售區域、團隊等等。同時，能夠建立各組織單元之間的關系。644.內部組織主題主要特征包括所有的組織類型以及它們的相互關系提供層次和矩陣結構

和當事人、渠道、地理位置、產品、帳戶、事件、行銷活動等主題有關聯

分行1分行2分行4地理位置1地理位置2銀行分行3市場區域1市場區域265“交易”概念的外延事件可能與帳戶相關，也可能與帳戶無關。事件可能與資金相關，也可能與資金無關。5.事件(Event)主題事件的定義：

事件（EVENT）是一種資金或非資金的活動，可能需要也可能不需要銀行與客戶的直接接觸，它記錄了詳細的行為和交易數據。包括存款、提款、付款、信用/借記卡年費、利息和費用、投訴、產品查詢、地址查詢、余額查詢、市場調查、網上交易等。665.事件主題主要特征包含資金或非資金事件由銀行或客戶發起若干客戶事件可以組成一個事務事件有相關的交易代碼與其他主題有密切關聯

67聯系事件客戶或潛在客戶，與金融機構或金融機構的商戶之間的各種聯系行為。（如客戶投訴）金融事件任何與資金相關的事件。（如取款）帳戶事件任何與帳戶相關的事件。（如帳戶凍結、解凍等）5.事件分類方法685.事件主題主要實體696.地理位置(Location)主題

包括地理區域及它們之間的聯系。地址可以是物理地址（如城市、街道等），也可以是電話號碼或電子郵件地址等。地理位置的定義：

地理位置(Location)是指金融機構希望關注或考察的任何地理區域和地址。如國家、省份、城市、縣、鄉村等。70是金融機構用以獲取客戶、保持客戶、爭取潛在客戶所使用的市場行為。是金融機構的產品和市場形象對客戶有組織的展示包括非行銷的一些市場行為，如對欺詐的偵測與防范等7.行銷活動(Campaign)主題行銷活動的定義：

行銷活動是銀行對客戶開展的一系列的促銷事件以及相應的策略和規劃活動的組合。717.行銷活動主題的主要特征包括從策略到執行的多層次的市場活動。大型的或有目標的活動與成本、收入、日期等有關與其他主題關聯行銷策略行銷事件市場計劃產品定位地理位置選擇渠道選擇行銷渠道行銷收益組織機構客戶回應廣告投入和實施面向公眾的行銷事件面向目標市場的行銷事件分類行銷活動主題視圖72渠道（CHANNEL）是銀行與客戶進行交互和接觸的手段和方法，通過它客戶與金融機構發生交易并交流很多的信息。8.渠道(Channel)主題渠道一般包括:ATM、分行柜臺、電話、POS、呼叫中心、電視、廣播、報紙、網絡、信件等。738.渠道主題的主要特征包括多種類型，只要是銀行與客戶的聯系工具都可以成為一個渠道。能夠考察渠道的分布和使用情況。和其他主題密切關聯。748.渠道主題的主要實體758.國內銀行渠道分類示例有形渠道柜臺,ATM,POS…虛擬化渠道手機銀行、網上銀行…企業客戶終端系統大眾媒體一對一營銷渠道

Email,Mail…76其他相關內容還有其它的相關內容：帳戶申請（application）

包括帳戶的申請條件和過程產品報價（quotation）

金融機構針對客戶對某種特定產品的報價，同時作為帳戶申請的限制條件。隱私（privacy） Party不愿公開的一些信息

77NCRFS-LDM小結FS-LDM集成了國際先進銀行科學的、先進的管理經驗，可以幫助建行加快與國際商業銀行接軌。FS-LDM具有很大的可擴展性和靈活性。FS-LDM對數據倉庫的物理數據模型（PDM）的設計具有指導作用，可以最大程度的縮短開發周期。78TeradataFS-LDM介紹主要內容邏輯數據模型基本概念NCR

FS-LDM

LDM定制化工作步驟79NCR邏輯數據模型客戶化方法論FS－LDM介紹客戶化研討講解模板產品當事人協議事件渠道內部機構應用驗證數據驗證合理性驗證規范驗證客戶化FS-LDM前期準備項目組交流研討分析源系統統一業務定義模型驗證組建團隊收集資料確定范圍介紹源業務系統分析整理數據結構分析樣本數據框架設計模型詳細設計完善和回顧80NCR邏輯數據模型客戶化方法論FS－LDM介紹客戶化研討講解模板產品當事人協議事件渠道內部機構應用驗證數據驗證合理性驗證規范驗證客戶化FS-LDM前期準備項目組交流研討分析源系統統一業務定義模型驗證組建團隊收集資料確定范圍介紹源業務系統分析整理數據結構分析樣本數據框架設計模型詳細設計完善和回顧81準備工作1—組建團隊

銀行領導

NCR領導應用小組NCR人員

銀行人員數據建模小組

NCR人員(2~4)銀行人員(2~4)項目總監

銀行項目經理

NCR項目經理項目經理

資深業務顧問資深系統架構師

資深模型顧問資深技術顧問NCR專家顧問組

業務專家管理分析人員資深技術人員銀行后援支持組技術人員：熟悉業務系統溝通能力強理解數據業務人員：熟悉業務規則掌握實際運作確認規范和定義數據規范小組NCR人員(1~2)

銀行人員(2~3)ETL小組NCR人員

銀行人員黃色部分是在數據倉庫項目組中和LDM建設相關的人員82準備工作2—收集資料系統介紹包括系統架構、主要設計思想以及和其他系統的關系等。系統數據字典有完整的數據字典（含字段說明）供分析用。樣本數據驗證重要的、復雜的業務規則，幫助分析數據的使用規則。如果涉及到多個系統，應該保證各系統數據之間的同步性。83準備工作3—確定范圍數據源范圍客戶化工作會涉及幾個源業務系統？樣本數據會選擇多少機構、多長時間的數據？提交物客戶化工作結束之后的提交物主要包括哪些？84準備工作—提交物源業務系統介紹材料

樣本數據報送表組織架構建議和分工85NCR邏輯數據模型客戶化方法論FS－LDM介紹客戶化研討講解模板產品當事人協議事件渠道內部機構應用驗證數據驗證合理性驗證規范驗證客戶化FS-LDM前期準備項目組交流研討分析源系統統一業務定義模型驗證組建團隊收集資料確定范圍介紹源業務系統分析整理數據結構分析樣本數據框架設計模型詳細設計完善和回顧86項目組交流研討NCRFS-LDM產品培訓

NCR資深建模專家就FS-LDM進行詳細的介紹，主要包括數據模型的一些基本概念、常用的建模方法、FS-LDM各主題的定義和主要內容、關鍵實體和屬性描述等。客戶化研討幫助項目組所有成員清楚地了解客戶化過程，明確小組的工作方式和主要工作目標、任務，并且共同制定詳細工作方式，才能夠保證后續工作的順利展開。就術語達成共識確定LDM定位和作用確定實施策略制定詳細工作方式87交流研討—提交物培訓材料

學習資料88NCR邏輯數據模型客戶化方法論FS－LDM介紹客戶化研討講解模板產品當事人協議事件渠道內部機構應用驗證數據驗證合理性驗證規范驗證客戶化FS-LDM前期準備項目組交流研討分析源系統統一業務定義模型驗證組建團隊收集資料確定范圍介紹源業務系統分析整理數據結構分析樣本數據框架設計模型詳細設計完善和回顧89分析源系統清晰了解現狀為客戶化提供基礎介紹源業務系統系統架構/設計思想業務功能/重要流程系統定位和其他系統的關系分析整理數據結構了解每個表的用途分析每個字段的含義整理數據結構歸納分類數據表分析樣本數據分析數據的填寫規則驗證業務規則查詢某種規律關鍵點：有效的問題反饋機制完備的數據資料和文檔90源業務系統分析—提交物源業務系統介紹數據結構整理數據字典整理數據表分類問題跟蹤表91NCR邏輯數據模型客戶化方法論FS－LDM介紹客戶化研討講解模板產品當事人協議事件渠道內部機構應用驗證數據驗證合理性驗證規范驗證客戶化FS-LDM前期準備項目組交流研討分析源系統統一業務定義模型驗證組建團隊收集資料確定范圍介紹源業務系統分析整理數據結構分析樣本數據框架設計模型詳細設計完善和回顧92客戶化模型1—框架設計基于NCR的FS-LDM，根據所設定的目標和數據范圍，確定需要建設的主題范圍，構建LDM的原型框架。LDM原型框架決定數據倉庫的數據組織原則和基本形式，也決定了數據倉庫的應用范圍和應用模式。 藍本93客戶化模型2—模型詳細設計以上工作須有業務人員和熟悉業務系統的技術人員的參與和配合基于LDM原型框架，進行各主題的詳細設計，主要任務包括：－創建各主題的實體和屬性，并進行盡可能詳細、準確的定義和說明；－建立各實體間的關系；盡可能準確地體現業務規則；－建立主題之間的關聯，參照業務需求對實體和屬性進行調整。設計過程中也需要對相關代碼表進行整理，建立主外鍵關系；94客戶化模型2—統一業務定義在詳細了解FS-LDM的基礎上，通過對源系統相關信息的了解和整理工作，IT人員和業務人員應該對一些重要的業務元素統一定義，包括：產品渠道當事人協議事件……及時確認！95客戶化模型3—完善和回顧（1）與熟悉業務系統的技術人員進行交流和探討：—是否正確理解了原業務系統的數據

—是否有重要的數據被遺漏—實體之間的關系是否正確（2）與業務專家進行模型的回顧和檢討：

—是否能夠幫助實現業務需求—是否能夠很容易地理解—重要的業務規則是否得以體現

—回答、解決問題是否方便（3）對數據主題、實體、屬性進行確認和完善；可能需要多次的討論和交流96客戶化模型—提交物概念模型框架模型模型命名規范客戶化后LDM問題跟蹤表97NCR邏輯數據模型客戶化方法論FS－LDM介紹客戶化研討講解模板產品當事人協議事件渠道內部機構應用驗證數據驗證合理性驗證規范驗證客戶化FS-LDM前期準備項目組交流研討分析源系統統一業務定義模型驗證組建團隊收集資料確定范圍介紹源業務系統分析整理數據結構分析樣本數據框架設計模型詳細設計完善和回顧98模型的驗證技術角度：

—是否符合建模規范

—是否有足夠的文檔支持業務角度：

—選取不同的業務需求，從不同的角度對模型進行驗證；

—通過應用需求驗證，評估數據組織的合理性；驗證和評估結果將成為調整、完善模型的依據。99客戶化模型—提交物模型驗證文檔驗證后LDM

模型說明文檔100NCR邏輯數據模型客戶化方法論FS－LDM介紹客戶化研討講解模板產品當事人協議事件渠道內部機構應用驗證數據驗證合理性驗證規范驗證客戶化FS-LDM前期準備項目組交流研討分析源系統統一業務定義模型驗證組建團隊收集資料確定范圍介紹源業務系統分析整理數據結構分析樣本數據框架設計模型詳細設計完善和回顧101模型的實施確定數據類型，建立PDM；進行數據映射；制定抽取策略；轉入ETL工作開發基礎應用；進行用戶培訓和推廣；制定下階段工作目標和范圍；102一個好的LDM應該是……中性的，共享的：不針對某個特別的應用而設計；靈活的，可擴展的：能以第三范式存放最詳盡的數據，業務發生變化時易于擴展，適應復雜的實際業務情況；穩定的，經得起考驗的：能夠在很長時間內保持穩定性，回答不斷產生、不斷變化且無法預先定義的業務問題；規范的，易懂的：使用業務語言進行模型設計，易于讓業務人員理解和使用，有助于IT和業務部門人員的溝通；103成功關鍵要素對源業務系統的了解完備的文檔/數據資料學習溝通能力有效的問題解決機制和確認機制目23456TeradataFS_LDM模型介紹IBMIIW模型介紹維度模型設計第三范式模型設計匯聚數據財富

挖掘潛力無限錄數據建模導論1SysbaseIWS模型介紹7案例-模型案例說明什么是IIW模型？IAA/IIW的保險業務數據模型(BDM)提供企業級的、通用和靈活的保險業務模型，而且保證業務人員可以方便使用。它獨立于具體的保險業務和保險機構，通過模型的本地化和客戶化，來滿足某個具體的保險企業的使用。這些業務數據模型也與技術手段相脫離，專注為業務建模和業務分析提供一個穩定可用的基礎平臺。BDM由主題區域（SubjectArea）組成，主題區域分為2類，一類是：主視圖（MainView），主要表示屬于該主題區域的類（Type）、屬性（Attribute）以及它們的關系；另一類是：外視圖（ExternalView）主要表示和其他主題區域的關系。主視圖-主題內部關系，外視圖-多個主題間的關系IIW主題區域介紹（1）賬戶和資金（Account&Fund）包括能夠支持保險公司構建運營上需要的各種賬戶。賬戶種類包括客戶賬戶、準備金賬戶和資金。

活動（Activity）活動模塊對被建模的保險公司有關的利益方的各種不同的活動給出了定義，特別是在承保和理賠管理領域里的一些活動。在承保過程中，被建模的保險公司需要對基于被保險人在職業和個人生活兩方面從事的相關活動了解存在的風險。例如，一個保險公司可以決定不為某一行業承保，或不為某些愛好承保，或因增加的風險而要求更多的保險費。在理賠管理過程中，被建模的保險公司需要了解引起賠案的損失事件的背景環境。活動應描述不同的當事方在損失事件發生時的活動。這些活動的有效性將根據保險合同中所規定的條款而定，如果該條件不符合保險合同的規定，賠償將不予以支付

評估與狀況（AssessmentandCondition）包括情況、醫療情況、物品情況、地點情況、社交活動情況、經濟的評估和用于市場分析的評分。

業務模型對象(BusinessModelObject)定義了在BDM所有對象的共同的特征。

類別(Catagory)將對象按照給定的條件組織在一起的結構。

IIW主題區域介紹（2）理賠（Claim）對相關保單提出支付受益的申請。

聯系點和偏好（ContactPoint&Preference）包括了地址、電話號碼、電子郵件地址和優先選擇的聯系點。

事件（Event）包括危險的自然現象或在理賠中典型的事故。

財務處理（FinancialTransaction）包括應付款項和支付（進或出）。

資金計劃與管理（MoneyProvision）在合同上商定的或在理賠結算中所涉及的單次或多次付款計劃。

當事方（Party）包括了人、機構組織、角色和當事方的名稱。

地點（Place）是地理位置的細分，例如街道、城市、省和被國家認為是有特別的風險的或有市場吸引力的。

IIW主題區域介紹（3）

注冊信息（Registration）當事方在官方的登記或其他業務上的實情。例如，社會保障號、護照、車輛標識號、產品注冊號。

規范，產品和協議（Specification,Product&Agreement）包括保險公司銷售產品的規范，各種保險公司和客戶或業務伙伴簽定的協議。

標準文本和通訊（StandardTextandCommunication）包括了預先定義了的文檔規格書、一般文檔和與客戶聯系的記錄。

類型（Type）一個相互排它的分類方法，將對象的性質歸類到一個類（class）。IIW模型圖標說明基本實體：在類型層次結構中的根類型(例如：一個基本實體不依賴于其層次結構中更高層的類型)兩個基本實體的關聯。一個關聯實體可以有一個或多個種類實體在類型層次結構中高層類型的子類。在該層次結構中，類型間相互不重疊。關聯實體的子類。它的名稱表示了關聯的種類。帳戶（Account）是帳戶和基金主題區域的基本實體，貨幣資金帳戶實體的子類負債帳戶是子類實體；帳戶關聯實體（AccountRlship）表示了各帳戶之間關聯關系的抽象實體，帳戶分配實體（AccountAllocation）是帳戶金融資產關聯實體（account-financialassetrlship）的子類實體。相關文檔介紹，詳見附件目23456TeradataFS_LDM模型介紹IBMIIW模型介紹維度模型設計第三范式模型設計匯聚數據財富

挖掘潛力無限錄數據建模導論1SysbaseIWS模型介紹7案例-模型案例說明113IWS數據模型說明——主題核心主題：LifePolicyEventLifeClaimTransactions關鍵度量主題：LifePolicyKeyMeasuresLifePolicyCostsKeyMeasuresLifeAgencyChannelKeyMeasuresLifeAgentChannelKeyMeasuresLifeProductCostsKeyMeasuresLifeUnderwritingCostsKeyMeasuresLifeClaimSummary（實際上也是KeyMeasures）其他應用主題視圖：LifeQuotations&ProposalsLifeNewBusiness114LifePolicyKeyMeasuresLifeInsuredParticipantProfileLifeInsuredParticipantProfileLifePolicyEvent115LifeAgencyChannelKeyMeasuresInsuranceAgencyProfileLifeAgentChannelKeyMeasuresInsuranceAgentProfile116LifeInsuranceProductLifeProductCostsKeyMeasures通過分析，IWS模型主要由四類實體構成：概貌類表：存儲實體歷史信息；事件類表：存儲明細交易信息；匯總類表：存儲不同視角指標匯總信息，粒度一般到保單、責任或者代理人（機構）；公用維度表：分為有業務含義的實體快照信息、或基礎公共信息；CustomerProfileInsuranceAgency代理機構Geography位置Demography人口統計特征BehaviorScores行為FinancialScores財務Product產品Psychographics購買特征（消費行為）SinceDate相關行為開始日期BeginDate初始日期EndDate結束日期Assets資產Policy保單PolicyRating相關費率PolicyLifeCyclestatus保單狀態ApplicationDate申請PaymentCat支付InsuredParticipantLifePolicyKeyMeasureMaturityDate到期/滿期日期DeterminationDate其他重要日期Currency貨幣IWS數據模型說明——保單關鍵度量子模型個險業務分析-核心表結構示例IWS_TK(1)數據模型是一個簡化版本的IWS模型，具體來說：（1）沒有概貌類表，不存儲歷史信息，多簡化為維度表，如保單、客戶、代理人；（2）僅包含核心的保單事件表，對于理賠沒有做相關事件表（3）沒有KPI度量表，只有幾個匯總表，粒度與IWS度量表相比較，粒度較粗，且針對需求設計，多以窄表的形式呈現；A表存儲的內容主題相關性不足，難以理解；（4）實際應用中，派生出多個F表，分別用于保全、承保分析或統計使用；業務應用需求源系統表級、字段級分析；主要分析現有模型數據質量，聽取用戶修改意見邏輯分類，各主題功能定位映射篩選分析數據倉庫邏輯數據模型固定報表、管理駕駛艙、KPI需求源系統調研IWS參考模型LifeAgencyChannelKeyMeasuresLifeAgentChannelKeyMeasuresLifeCustomerKeyMeasuresLifeClaimSummaryLifeClaimTransactionsLifePolicyEventLifePolicyCostsKeyMeasuresLifePolicyKeyMeasuresLifeUnderwritingCostsKeyMeasuresLifeProductCostsKeyMeasuresIWS_TK_LDM數據倉庫CSL邏輯模型建設路徑整理出需求中涉及的指標和維度矩陣；分析這些指標歸屬的主題；分析現有模型核心表字段，將其數據質量差、含義不明確、字段借用、含義與字段名稱錯誤等問題找出來，予以調整；分析核心表功能定位，收集IT多年來對這些表的修改意見；了解IWS模型設計思想，并以此為藍圖，客戶化泰康的數據模型；對于老BI客戶化不足之處進行擴充與完善；數據模型主題描述-保單事件保單事件存儲交易級別明細數據；粒度可以到保單、責任、渠道、代理人、中支；事件范圍涵蓋了新契約、承保、核保、保全、理賠、代理人職級變動等信息；寬表結構，不同事件都有部分字段空值，以存儲空間換后續的處理效率；且便于運維管理；該表是計算指標最為核心的基礎表；由于不存儲歷史信息，概貌表簡化為常規維度表；歷史信息的snap表以較多的存儲空間換來了歷史信息，指標計算與etl加工較為方便，二期繼續保留；數據模型主題描述-關鍵指標度量保單關鍵指標度量一般存儲粒度比保單事件稍粗，不到交易層面；根據實際需求情況，保單關鍵指標度量存儲不同粒度指標匯總信息；只存儲本月或者本日數據，一般不做MTD或者YTD，這些指標將在集市層中計算，ETL加工復雜度降低，且ETL處理效率會得到很大提高；老BI中的A表一般不再使用（除了個別復雜的指標，如繼續率），涉及指標將分拆到語義層和集市層處理；產品、客戶、代理人、代理機構涉及關鍵指標度量存儲的粒度與各主題相關，粒度相對來，很細，足夠常規報表統計需求；本期項目中，諸多指標，將根據指標主題性質，進行歸來，納入到不同主題的關鍵指標度量表中；這些關鍵指標度量表作用就是將常規指標提供計算，并存儲下來，供集市層指標簡單匯總使用；應用中，若干需要查詢細粒度的指標數據，可以直接查詢這些度量表度量表粒度相比事件表，一般要稍粗一些保單事件示例：模型基本結構解析1221.公共維度3.保單事件擴展、屬性2.保單事件日期4.保單基礎指標5.保單擴展維度數據模型信息加工原則核心維表處理規則規則1核對維度表在多處使用，且影響范圍較廣，因此不做大的改動，對于其中含義不明的字段、沒有什么用處的字段、空值較多的字段進行排查，必要時可以核對多個維度表；核心保單事件表處理規則規則2該表示IWS模型的精髓，將保險業務進行簡單的逆范式處理，存儲保單各類操作事件，該表不做大的改變，繼續沿用這一框架；檢查個別字段數據質量問題MQT表、其他F表處理規則規則3根據IWS模型的涉及初衷，建立的某個主題的細粒度度量表，存儲相關業務指標；指標的來源基于本期需求，同時根據經驗，派生出一些中間指標，用于計算更為復雜的指標；主題的劃分參考IWS，根據實際需要進行裁剪；公共類表處理規則規則4對于機構、產品、日期、月份、渠道處理規則，沿用以前的源表；個別字段進行去除，派生價值版塊中涉及的一些公共維度，數據來源于D表，做新的報表時，使用同類的V88，這樣結構清晰，D表用于CSL，V88統一用于集市；CSL層相關問題124CSL層在數據架構中是如何定位的？主要解決什么樣的問題？公共維度和指標的單一視圖，解決：a、指標維度的一致性；b、提高應用開發和響應效率；通用語義層細化到交易號粒度，與EDW的主要區別有哪些？在EDW中，沒有維度和指標的概念，主要職責是合理地組織標準化數據；在CSL中，公共維度和指標按照保險核心價值鏈進行主題分類組織，這些維度和指標按照統一的算法邏輯進行標準化實現和數據加載；通用語義層的設計思路和步驟是什么？你們后邊打算怎么做這一塊的工作？設計思路：基于保險核心價值鏈的維度總線架構模型，數據粒度到交易號，建立模型之間的簡單關聯關系；通用語義層設計基本依據：I、基于保險核心價值鏈分析和應用需求分析的公共維度和基礎指標構成的維度指標矩陣；II、基于事件梳理和對象梳理，構造業務對象標準維、事務粒度事實表、累計快照事實表、交易行為事實表等；客戶化的策略和步驟，見CSL客戶化方法論CSL層相關問題（續）125通用語義層對于一些復雜的特殊指標是如何考慮的，如已賺保費、滿期賠付率、未決賠款等？對于復雜的特殊指標，建立公共匯總集市，如已賺保費、未決賠款、滿期賠付率等，為相關應用提供一致的指標數據如何在后期的開發和運維過程中持續發展和完善通用語義層？堅持發展和完善通用語義層的基本原則；制定模型升級維護管理辦法；專人管理模型升級維護；對于新增的公共維度和基礎指標，分析與現有主題、維度、指標之間的關系，對于相同主題和粒度的，擴展現有模型；如果現有模型無法合理容納，考慮建立新的主題模型；目23456TeradataFS_LDM模型介紹IBMIIW模型介紹維度模型設計第三范式模型設計匯聚數據財富

挖掘潛力無限錄數據建模導論1SysbaseIWS模型介紹7案例-模型案例說明內容提綱內容演講人備注第一部分：通用語義層概述Ⅰ：回顧以往數據倉庫模型設計思路Ⅱ：什么是通用語義層Ⅲ：通用語義層能解決什么問題Ⅳ：通用語義層有哪些特點第二部分：如何設計通用語義層第三部分：項目案例說明內容提綱內容演講人備注第一部分：通用語義層概述Ⅰ：回顧以往數據倉庫模型設計思路Ⅱ：什么是通用語義層Ⅲ：通用語義層能解決什么問題Ⅳ：通用語義層有哪些特點第二部分：如何設計通用語義層第三部分：項目案例說明

回顧數據倉庫數據架構演變過程1.0實施方法特點：源數據一般直接抽取到緩沖層，緩沖層邏輯上在細分為全量區、增量區；基于緩沖層（當時叫ODS層）加工數據集市，集市分為明細匯總表、高粒度的匯總表；用戶應用多集中在報表統計；個險銀保團險電銷財務接口文件緩沖層，（ODS）個險、銀保、團險、財務、電銷等數據集市（DM）明細匯總表，高度匯總表固定報表靈活查詢多維分析1.5實施方法特點：緩沖層與數據集市模型設計思路與以往類似；整合層，參考了IBM的IIW、TD的FS_LDM模型，進行客戶化；或者據此設計公司內部的企業模型；用戶應用多樣化，充分利用BI工具分析功能；管理駕駛艙實際上是儀表盤+固定報表個險銀保團險電銷財務接口文件緩沖層，（ODS）個險、銀保、團險、財務、電銷等數據集市（DM）明細匯總表DM1，高度匯總表DM2固定報表靈活查詢多維分析整合層（DW）統一建模管理駕駛艙

IIIIVⅤ增量信息難以捕獲，造成模型設計難以保存歷史，造成了模型設計有些“四不象”，實際上并沒有學習到行業模型的精髓項目困難、困惑項目實施過程中遇到的困難、困惑ETL過程設計簡單，代理主鍵的使用、更新與維護混亂數據集市一般根據應用來設計，集市表成“碎片”，且指標多次重復計算，集市之間存在誤差（可能因為維度、指標口徑不明確、加工頻度、刷新頻度、腳本錯誤等）數據集市根據實際需要分為明細匯總表、輕粒度匯總表、高度匯總表，至于為何這么分，并沒有講出所以然來III整合層按照范式的要求進行存儲，在計算集市時，非常的不方便，效率低下，因此常將一些常見的維度信息關聯好，存儲起來，集市計算時使用以往數據倉庫類項目模型設計成果示例當事人事件協議集市模型，這里甚至沒有分層困惑~！當前，數據倉庫最佳實踐之數據架構2.0實施方法特點：總結以往項目經驗，規劃出較為實用的一層，通用語義層，將基礎指標的計算、維度梳理預處理，將多表關聯處理成冗余的寬表，解決實際問題；提煉建模方法論，指導項目實際操作；少走彎路。個險銀保團險電銷財務接口文件緩沖層，（緩沖區、轉換映射區、基礎數據區）個險、銀保、團險、財務、電銷等數據集市（DM）分主題匯總（考慮復用）、特定應用匯總固定報表靈活查詢多維分析通用語義層（存儲明細數據、可多次復用的數據，解決維度與指標一致性的問題）管理駕駛艙制式報告動態報表資產接口文件內容提綱內容演講人備注第一部分：通用語義層概述Ⅰ：回顧以往數據倉庫模型設計思路Ⅱ：什么是通用語義層Ⅲ：通用語義層能解決什么問題Ⅳ：通用語義層有哪些特點第二部分：如何設計通用語義層第三部分：項目案例說明通用語義層起源與BO通用語義層（CommonSemanticLayer），檢稱CSL，最早起源與BO，目的在于讓業務用戶能夠通過自己的業務術語，自由安全的訪問、分析以及分享信息的技術，其特點是：業務用戶自主操作提高用戶對于各種企業數據的操作體驗提供一致可信的數據，確保同一業務術語的引用能夠貫穿整個企業讓所有的商務智能工具都可以使用（只能用于BO）讓信息部門可以控制和確保信息訪問的安全性通用語義層帶來的價值簡潔一致的用戶體驗，讓業務用戶可以簡便的訪問企業內的數據；減少企業的培訓成本；保障業務用戶始終使用可信的信息業務用戶自創式創建各種商務智能的內容可重用的查詢、計算、參數、過濾條件、值列表簡化用戶使用為普通用戶提供了一個簡化的界面，訪問復雜的企業數據降低BI項目的投入成本，保護現有IT數據投資擴展現有的BI平臺的安全模式支持多數據源的語義層，提高服務質量支持完整BI項目生命周期，項目開發、測試、投產語義層與數據源的變化相同步支持和擴展數據庫的安全性預定義的可重用的查詢、參數、過濾、計算、值列表等給業務用戶帶來的價值給IT用戶帶來的價值可理解性差語義層過于復雜，難以理解，尤其是新老人員交替，溝通成本很高可復用性差語義層的設計成果不能在多個BI工具中使用，過于依賴BI工具.重用程度不高可擴展性差語義層的擴展于與分拆影響較大，難以后期維護，為了降低影響范圍，大多是在原來基礎上，新增其他功能，致其復雜度越來越高；BO中的通用語義層實踐中遇到了一系列的問題如何解決這些問題呢？即能夠享有通用語義層帶來的價值，又能夠規避這些問題。經過敏思苦想、群策群力，終于有了答案。。。。敏思苦想群策群力奔走相告豁然開朗使用ETL的方式，將BO中的語義層搬到數據庫中，簡化加工邏輯、提供可擴展性和可復用性現在，我們來重新定義通用語義層通用語義層模型設計基于業務（如保險）核心價值鏈上的核心業務對象和業務事件，采用維度總線架構思想來構建；業務對象通常用維度實現，業務事件通常用事實表實現，按照事實表的不同類型分為：累計快照事實表、周期快照事實表、交易基礎事實表。通用語義模型設計面向管理決策和經營分析，是公共維度和共性基礎指標的實現載體，支持80%以上的共性應用需求；通用語義模型設計采用維度化的逆范式設計模式，通常采用以下策略：預連接處理：按照總線架構維度和事實表的要求，將分散在多張相關實體表的數據屬性進行預連接操作，使相關的維度盡可能組織在特定的維表或者事實表，如保單維、保單責任維、代理人維、客戶維、賠案維等；預計算處理：按照總線架構維度和事實表的要求，對事實表中的基礎指標進行加工計算，保證基礎指標邏輯加工的“GoldenCopy”，如保單事件、核保事件、保全事件、查勘事件、理賠事件等；匯總處理：針對共性的復雜指標，按