面向保險業的數據倉庫模型分析與設計

吳菊華，曹 強，莫 贊，孫德福

（1.廣東工業大學，廣東 廣州 510520； 2.裝甲兵裝備技術研究所，北京 100072）

一、引言

保險行業經過多年來的業務發展和信息系統建設，已建成包括承保系統、批改系統和理賠系統等在內的一系列信息系統，并積累了大量的歷史數據。如何充分利用這些數據并將其轉化為信息和知識，使得業務人員（包括管理者）能夠充分掌握和利用這些信息進行輔助決策，進而轉化成商機，一直是各保險公司所關注的問題。

商務智能是對商務信息的搜集、管理和分析的過程，目的是使企業的各級決策者獲得知識和洞察力，促使他們做出對企業更有利的決策，從而以最短的時間發現商業機會并捕捉商業機遇。通過商務智能技術，用戶可以更充分地了解他們的產品、服務和銷售趨勢。它提供了一個良好的方法，把分散的數據集成到一個數據倉庫系統中，利用OLAP技術和數據挖掘技術來幫助公司對業務進行分析，尋求業務規律，并為領導層提供決策支持。因此，商務智能走進保險行業，已成為一種趨勢和必然。

參考國內外銀行、金融、通信等行業所積累的商務智能實施經驗，可以看出國內保險行業對企業信息化的規劃發展在加速地進行中，這使其業務系統架構得到不斷地完善，與商務智能方案相關的硬件軟件及數據規模都得到更高層次的匹配，為商務智能的實施奠定了良好的基礎。但隨著業務需求的不斷變化和商務智能技術的發展，國內的保險行業需要對企業數據倉庫系統的設計進行更深層次的探討及落實。

數據倉庫是一個面向主題的、集成的、相對穩定的、反映歷史變化的數據集合，用于支持管理決策。由于數據倉庫系統涉及的業務用戶眾多，在進行數據模型設計的時候必須兼顧不同業務產品、不同業務部門、不同層次、不同級別用戶的信息需求，因此有必要首先對數據倉庫進行建模，基于企業的數據庫設計數據倉庫對于一個企業的戰略規劃具有重要意義。本文針對保險行業，以某人壽保險公司的客戶信息共享(ECIF)項目為背景，分析了商務智能技術在保險行業的應用，劃分了主題域并對該項目數據倉庫進行建模和指標測試，對于保險行業數據倉庫的構建具有一定參考價值。

二、保險業務系統

1.企業客戶信息整合概述

國內保險企業競爭的核心要素有兩個：產品與服務。但經過十幾年的發展，保險公司之間的競爭越來越激烈，產品趨向于同質化，服務不再單一化，保險企業為了適應新的業務需求，奪取更多的市場份額，對自身的業務系統都有不同層次的改進。隨著個人可支配收入的增長，個人對保險產品和服務多元化有了更高的要求，如何有效地利用已有客戶資源和開發新的客戶資源，成為了保險企業發展的重要問題。

ECIF是一個實時面向服務、提供全部客戶信息集合的聯機事務處理系統，它不僅可以提供客戶的靜態信息，也能夠提供實時、一致、完整的信息到現有的業務系統及將要成立的應用系統上。它實現了跨業務系統的客戶信息整合和客戶歸并識別，實現了對客戶整合信息的共享，也可以讓保險產品和服務渠道實現個性化。

2.保險業務系統特點

保險業務分析系統主要面向各分單位業務部門，為其提供統計分析和報表查詢功能。所以在其保險業務系統中的數據特點主要有：數據來源多、數據種類混雜、數據質量差。

（1）數據來源多

在保險業務系統中，每天都有來自投保人上億條新的數據記錄產生；每個省、市的管理信息系統及財務管理信息系統，每天在使用過程中產生大量數據，所以數據的來源非常多。保險業務系統除了信息管理外，還有分析和決策功能，需要從上述原始的、現實的數據中得出很多分析型的數據，以及額外市場調查總結的數據，所以在對其進行特征描述時往往牽扯到上千個狀態變量。然而傳統的處理方法是多系統進行降維或簡約化處理，這在一定程度上影響了最終結果的精度。

（2）數據種類混雜

保險業務系統本身是一個很復雜的業務系統，上層有公司領導，中間有車險、船舶險等事業部及總財務會計部和各個事業部的財務會計，下層又有基層員工及市場調查員等。最終為了達到保險業務系統最高贏利的目標，必須將不同職能，不同性質的上層、中層、下層控制管理得到的數據有機的結合起來，進行正確的處理和分析才能做到。

（3）數據質量差

在整個保險業務系統中，由于省、市各個下屬的管理系統記錄和采集的數據，最終都要匯總到總部。在此過程中就很容易出現不真實的數據、有誤差的數據、無價值的數據還有數據缺失等現象。這些質量不太高的數據會產生很多不確定的因素，從而給決策者帶來諸多不便。

三、數據倉庫建模

數據倉庫設計或建模主要包含四個核心步驟：需求分析、概念設計、邏輯設計和物理設計。關于數據倉庫的設計，不同的學者已在概念層、邏輯層和物理層提出了許多不同的技術。企業客戶信息整合是一個需要長時間規劃與建設才能完成的項目，需要保險企業的核心系統以及各個業務系統的配合才能完成。由于客戶信息整合涉及到很廣泛的業務系統范圍，又是整個保險企業的核心系統的基礎，所以為了讓ECIF的建設對現有的保險業務系統的工作的影響降到最低，該項目采取分期逐步實施建設的方式。

此次保險數據倉庫的建模是以“實現客戶信息的全方位共享與客戶分群，為公司的業務提供決策信息支持”為目的而進行的商務智能設計分析。項目的數據倉庫建模分為四部分：①需求分析，獲取項目需求；②概念模型的設計，統籌整個項目的設計框架；③邏輯模型的設計，設計此項目的指標計算邏輯思想和邏輯關聯；④物理模型的設計，實現概念模型的框架和邏輯模型的關聯。

1.需求分析

需求分析是用戶需求產生的，對系統服務或約束的描述，同時是以目標為導向。通常一個軟件系統的功能需求闡述了系統需要做什么，非功能需求是針對一些可觀察的質量屬性系統的運行情況，如性能、可重用性和可靠性等。目前該項目保險公司主要存在以下問題：客戶信息數據沒有企業級的統一編號來標識客戶，也沒有完整一致的客戶識別機制；不同系統只保留和使用本系統的客戶信息，系統之間沒有做到充分的客戶信息共享；現有壽險系統中同一個客戶在不同表格中存在不一致的版本，無法保證客戶體驗的一致性；在目前環境中，缺少完整的客戶信息，無法形成對客戶的整體評價；缺少統一的客戶價值評判標準，缺少對客戶風險等級進行有效評估的手段，因而無法實現差異化服務。鑒于以上問題，利用統一客戶視圖的方法，將各個系統的客戶信息整合，形成統一的客戶識別機制，將客戶信息歸并，形成客戶資源的信息共享。整合該保險公司客戶數據資源，建立客戶關鍵數據信息的標準化，進行關鍵數據信息的數據清理動作，制定客戶歸并的規則，進行客戶信息歸并，為業務部門提供360度客戶信息查詢及客戶清單的提取工作。為該保險公司實現客戶信息的全方位共享與深度分析加工，為公司的業務拓展、業務運營、管理決策、客戶服務提供強有力的信息支持。本項目客戶歸并方案是建立在相對優質的客戶數據質量基礎上，即數據的業務和技術屬性滿足數據標準的定義，對于不能滿足的數據要素則按無效的數據處理，不參與歸并。

2.概念模型設計

概念模型設計是為了給邏輯模型設計工作提供一個統籌的設計思路，并從業務邏輯上為后續的模型設計制定一個框架和為其提供指引。概念建模提供了對數據倉庫流程和架構各方面的抽象，旨在獲取實施問題的獨立性。概念建模是建立具有恰當記錄和滿足用戶需求數據庫的基礎。邏輯和物理建模的實體（或表）不能超出概念模型的范圍之外，并且不能破壞概念模型的業務邏輯結構。

概念模型設計能界定保險決策支持設計的邊界，并確定主要主題域及其內容。概念模型必須針對保險的業務需求及其業務之間的關系進行高度概況，把相關業務對象進行歸類，對其業務進行劃分主題。按照保險業務決策支持的設計需求，確定以下八大主題構成：①客戶基本信息；②客戶地址信息；③保險分析統計信息；④客戶溝通信息；⑤關系信息；⑥產品關聯信息；⑦財務、風險信息；⑧事件信息。

保險的模型設計必須保證其業務完整性，以確保保險業務上涵蓋保險客戶關系管理業務領域的各個環節，因此數據倉庫概念模型設計必須保證業務完整性、數據集成性、可擴展性、數據可用性、標準與規范和性能，具體如圖1所示。其中業務完整性是確保保險業務上涵蓋保險客戶關系管理業務領域的各個環節，如客戶獲取、接觸、信息登記、產品與服務等，并考慮與主流保險模型框架結構兼容和面向業務的商務智能應用體系。數據倉庫建模時必須要首先建立模型的標準與規范，包括建模基本規范、編碼規則、業務對象類型、枚舉類型標準、命名規范。數據可用性是整合所有源系統的數據后，需考慮數據的可用性和安全性得到保證，及其在未來數據增加的增量策略的實現，包括數據安全和存儲策略、數據的生命周期和數據的可維護性。數據性能是整合多個源系統，數據量增大后，還必須保證其ETL的性能和其業務系統查詢的性能。

圖1 概念模型設計原則圖

3.邏輯模型設計

邏輯設計依據概念架構在邏輯模型上創建一個對應的邏輯架構。邏輯建模是數據倉庫實施中的重要一環，因為它能直接反映出業務部門的需求，同時對系統的物理實施有著重要的指導作用。從概念模型八個主題域中分別選擇了客戶基本信息主題、保險分析統計信息主題和產品關聯信息優先進行分析。這三個關鍵分析主題將其余的主題有機的關聯在一起。基于保險ECIF系統的邏輯架構如圖2所示。

圖2 ECIF客戶信息共享邏輯架構

此邏輯架構的構建思想是：首先從保險公司的生產數據倉庫ECIF中抽取必要的數據庫表構成I層數據；然后用I層數據結合客戶信息系統CIF的數據來歸并成中間數據層，中間層數據根據需求分析來取數做規整，劃分指標，無匯總操作；然后在中間數據層的基礎上進行指標計算，做聚合操作成為匯總數據層；再在匯總數據層數據基礎上劃分出5類子寬表：有效產品數據寬表、賬戶數據寬表、歷史產品數據寬表、支出及貢獻度寬表、復合指標寬表，以得出需求指標；最后，寬表匯總所有的客戶分群基礎數據，用來支持最后的查詢和決策。為了實現上述功能匯總，邏輯設計必須有的一項重要功能是客戶的識別與歸并。在業務數據中，重復的客戶在數據庫中有各自的分開記錄，有多個客戶號，因此，為了完整保留業務系統的客戶信息，在進行客戶歸并時只需要確定數據的有效性。歸并只是生成與應用系統無關的客戶歸并號，因此對應用系統沒有影響。歸并客戶號的客戶數據的運用可以選擇查詢第一有效客戶，也可以列出所有歸并過的客戶用于人工判斷，這是進行客戶分群的一個重要模塊，對模型的影響主要在主鍵策略的制定問題上，因此設定的歸并客戶號均為主鍵。

4.物理模型設計

在數據倉庫的物理模型設計中，主要解決數據的存儲結構、數據的索引策略和數據的存儲優化分配等。但在物理模型設計中，還必須充分考慮到決策分析的需要。“維度建模”是組織和配置數據的主要過程，Kimball提出的維度建模在數據倉庫和商務智能應用中廣為接受的一種方法，許多從業者和學者都意識到在商務智能工具中使用到的數據必須以簡潔有效為基礎，通過多維建模標準化將數據轉換為由維度和事實表組成的多維模型已經得到了廣泛應用。所以，在物理模型設計中采用了多維數據模型，數據以多維形式組織和存儲，更加有利于OLAP和數據挖掘分析。

物理模型設計中，另外一個重要的功能是將邏輯模型設計中的客戶歸并號進行物理歸并。把業務數據中的多個重復客戶記錄在CIF中物理歸并為一個客戶記錄，需要實現CIF客戶與業務系統客戶的映射，客戶歸并時必須提供覆蓋規則，也就是說客戶屬性的有效性原則必須非常明確，因此也有可能造成部分有效數據的丟失，CIF模型必須保留歸并歷史，否則很難實現數據回溯和再歸并。成功進行物理歸并后，客戶數據的查詢使用就更簡潔和清晰。

通過歸并客戶號整合客戶在不同源系統的數據，實現了不同信息系統的客戶信息的全方位共享。在整合了不同信息系統的客戶信息后，再設計一個中間層，中間層中設計的表的主要作用是從歸并后的客戶信息中獲取數據，將一個表細分為幾個小表，以利于后面的數據匯總計算，例如：將首年保費表“FYP表”細分為“FYP表-細到險種”和“FYP表-細到保單”。在進行了必要拆分后，再對拆分進行必要的指標匯總計算，匯總層的每一個指標都必須從保險業務中進行詳細的了解，設計出字段算法，例如：計算意外傷害賬戶（主險）的APE情況，則必須從“FYP表-細到險種”的表中計算險種為意外傷害險種和該意外傷害險是主險的FYP的和。在匯總層的計算后，將其匯總的指標再進行關聯劃分出5類子寬表：有效產品數據寬表、賬戶數據款表、歷史產品數據寬表、支出及貢獻度寬表、復合指標寬表，以得出需求指標，求出所需指標的數據，最后將數據匯總到寬表，被報表直接引用。設計完ETL數據的邏輯關聯后，還需設計其調度關聯。因為有些表是引用不同層的表，所以如果要加載數據，必須先調度優先級高的數據表，設計出可并行運行的存儲過程架構，再進行層層調度抽取數據，滿足調度需求。

四、數據倉庫指標測試

在客戶信息整合共享項目中，通過UAT測試確保基于邏輯模型設計的數據倉庫有效，并確保該保險項目的各個指標符合最終用戶的使用需求，達到質量標準，能夠正式投入生產使用。在測試過程中，基于項目前期所確定的功能和數據需求，解決測試所發現的系統錯誤、功能缺陷、理解差異等各個方面的問題，最大程度地使系統能夠在計劃的時間內達到需求，確保系統在投入正式運行后正確、可靠、平穩的運行，有效支持業務運作。

測試將驗證指標正確性和指標數據正確性。其中指標定義正確性指的是確定本期項目指標定義是否按照項目需求已確認的指標定義；指標數據準確性是確定本期項目指標計算結果是否符合保險公司實際的業務結果。

根據本期項目的需求范圍和項目實際開發情況，測試范圍將涵蓋本項目所實現的指標。由于本期項目涉及的指標有300余項，如果每個指標都需要詳細UAT測試，需要很大的人力、時間、設備等資源。鑒于目前項目資源情況，建議按一定的優先順序，選取某指標進行UAT測試。被選取進行UAT測試的指標，一般為重要性的指標，包含基本指標，特別是某些衍生指標的父指標；保險業務上經常使用的指標；報表、分析等經常使用的指標等。本次測試選取以下指

標作為UAT測試對象，如表1所示。

表1 UAT指標

本次測試主要以靜態數據為基礎，測試期間數據庫中的數據不能擅自刪除、更改、插入，如有需要刪除、更改、插入操作，則需要經過測試組、業務組的影響評估，確定對測試結果無影響的，可指定相關人員進行相應操作，否則，任何人都不允許對測試數據做更改。為保證測試的可性行和準確性，UAT案例連接的數據源和測試環境的數據源是一致的，否則兩邊的結果將沒有可比性，整個測試的正確性將無法得到保障。

測試結果初步得出結論，該保險項目的各個指標基本符合最終用戶的使用需求，達到質量標準，符合指標上線運行使用。

五、結論

基于商務智能的保險決策支持設計是一項綜合性技術和解決方案，它為保險企業進行全局范圍的復雜數據分析，戰略決策和趨勢分析提供數據分析支持，項目的實施給該公司帶來了很多變化：

第一，從公司內部業務環境上看，項目實施之前存在數據未統一管理、客戶信息彼此間沒有聯系和信息缺乏全方位共享等問題，而在項目實施之后，加強了資源的有效整合，提高了公司運行效率。

第二，業務系統交互密集，導致數據量龐大且復雜度高，業務系統并不是單一地處理數據，在處理每一單承保信息時，就需要經過審計、反洗錢系統，向保監會上報等手續，當數據量很龐大時，信息的不準確性則會大大影響整體的工作。項目的實施支撐了不同業務系統的數據集成，不同業務系統客戶信息的共享。

第三，項目實現了客戶信息的全方位共享與深度分析加工，為企業的業務拓展、業務運營、管理決策、客戶服務提供強有力的信息支持，通過ECIF平臺整合公司客戶數據資源。

文章主要分析了數據倉庫的建模和指標測試，并且基于該模型設計的“基于ECIF實現客戶信息共享”的項目已經在該保險公司正式上線使用，據使用后的反饋結果顯示，該系統很好地解決了數據源孤立，信息分散利用率低的問題，系統運行速度和數據分析能力得到了極大的改進，在一定程度上提高了該保險公司的運作效率和業績。該模型的建模原則和模型設計對于保險行業數據倉庫應用具有一定的借鑒作用。

[1]Clark T D，Jones M C，Armstrong C P.The dynamic structure of management support systems：theory development，research focus and direction[J].Mis Quarterly，2007，31(3)：579-615.

[2]Elbashir M Z，Collier P A，Sutton S G.The role of organizational absorptive capacity in strategic use of business intelligence to support integrated management control systems[J].The Accounting Review，2011，86(1)：155-184.

[3]Ranjan J.Business intelligence：Concepts，components，techniques and benefits[J].Journal of Theoretical and Applied Information Technology，2009，9(1)：60-70.

[4]Rouibah K，Ould-ali S.PUZZLE：a concept and prototype for linking business intelligence to business strategy[J].The Journal of Strategic Information Systems，2002，11(2)：133-152.

[5]Zhenming X，Mia Z，Xiaodan J.Business intelligence-a case study in life insurance industry[C].Proceedings of the e-Business Engineering，2005 ICEBE 2005 IEEE International Conference，2005：12-18.

[6]Chaudhuri S，Dayal U，Narasayya V.An overview of business intelligence technology[J].Communications of the ACM，2011，54(8)：88-98.

[7]陳鴻雁.商務智能在保險數據分析和決策支持中的設計與實現 [J].計算機系統應用，2010，19(11):139-142.

[8]Lahrmann G，Marx F，Winter R，et al.Business intelligence maturity：Development and evaluation of a theoretical model[C].Proceedings of the System Sciences(HICSS)，Hawaii International Conference on.IEEE，2011.

[9]夏國恩，金煒東，張葛祥.商務智能在中國的現狀和發展研究[J].科技進步與對策，2006，14(1)：88-90.

[10]楊杉，何躍.數據倉庫和數據挖掘技術在保險公司中的應用[J].計算機技術與發展，2011，21(6)：157-160.

[11]馬鳴，趙軼超.實時商務智能的框架及其技術分析 [J].計算機應用與軟件，2009，26(10)：130-132.

[12]Inmon W H.Building the data warehouse[M].J.Wiley，2002.

[13]Jindal R，Taneja S.Comparative study of data warehouse design approaches：a survey[J].International Journal of Database Management Systems，2012，4(1)：33-45.

[14]Giorgini P，Rizzi S，Garzetti M.Goal-oriented requirement analysis for data warehouse design [C].Proceedings of the 8th ACM international workshop on Data warehousing and OLAP.ACM.