CRM系統(tǒng)：CRM 中的數(shù)據(jù)倉庫技術研究
CRM 中的數(shù)據(jù)倉庫技術研究
雷 蘊
摘 要：介紹了客戶關系管理（CRM）以及數(shù)據(jù)倉庫技術，著重分析了CRM 中的數(shù)據(jù)倉庫技術，對數(shù)據(jù)轉移和數(shù)
據(jù)的存儲與管理的改進及其在CRM 中的應用作了深入的探討和研究。
關鍵詞：客戶關系管理（CRM） 數(shù)據(jù)倉庫 數(shù)據(jù)轉移 數(shù)據(jù)粒度 數(shù)據(jù)分割
中圖分類號：TP311 文獻標識碼：A 文章編號：1006-7973（2007）03-0138-02
一、CRM 對數(shù)據(jù)倉庫技術的需求
1．動態(tài)、整合的客戶數(shù)據(jù)管理和查詢功能
客戶關系管理系統(tǒng)中的客戶信息必須是動態(tài)的、整合的。
動態(tài)需求方面，客戶數(shù)據(jù)倉庫能夠實時地向客戶關系管理系
統(tǒng)提供客戶的基本資料和歷史交易行為等信息，并在客戶每
次交易完成后，補充新的信息；整合需求方面，綜合、統(tǒng)一
客戶管理系統(tǒng)中客戶數(shù)據(jù)的客戶信息數(shù)據(jù)倉庫，可以使各業(yè)
務部門權限的不同實施信息查詢和更新功能。
2．客戶購買行為參考功能
客戶信息數(shù)據(jù)倉庫可以使企業(yè)的每一個服務人員在向客
戶提供產(chǎn)品和服務的時候，都能清楚客戶的習慣購買行為，
從而提供更具針對性的個性化服務。例如，聯(lián)系中心能夠根
據(jù)客戶最后一次的選擇和購買記錄，以及他們最近一次與客
戶交流獲得的有關信息，向客戶推薦不同的產(chǎn)品和服務。
3．客戶流失警告功能
對于企業(yè)來說，留住一個客戶的費用大約是發(fā)展一個新
客戶的費用的6 倍之多。通過對客戶信息數(shù)據(jù)倉庫中客戶歷
史交易行為的觀察和分析，可以警示客戶異常購買的行力。
例如，某個客戶的購買周期和購買量出現(xiàn)顯著萎縮變化時，
都是潛在客戶流失的跡象。
二、CRM 中的數(shù)據(jù)倉庫技術
1．數(shù)據(jù)轉移
數(shù)據(jù)轉移是一個較為復雜的過程，它包括數(shù)據(jù)的抽取、
轉換和裝載(ETL)。
（1）數(shù)據(jù)抽取（Data Extraction）
數(shù)據(jù)抽取就是根據(jù)CRM 數(shù)據(jù)倉庫系統(tǒng)數(shù)據(jù)模型的需求，
從相應的業(yè)務系統(tǒng)、外數(shù)據(jù)源等中抽取需要的數(shù)據(jù)。抽取出
來的數(shù)據(jù)可能需要經(jīng)過轉換，采取同步或異步的方式加載到
CRM 數(shù)據(jù)倉庫系統(tǒng)中。根據(jù)抽取的源數(shù)據(jù)形式，選擇數(shù)據(jù)抽
取接口的原則建議為以下幾點：
① 對于數(shù)據(jù)形式為關系型數(shù)據(jù)庫的系統(tǒng)，建議采用
ODBC、OLEDB 或專用數(shù)據(jù)庫驅動接口方式；
② 對于數(shù)據(jù)形式是文件方式的源數(shù)據(jù)，則一般直接進入
轉換和加載流程；
③ 對于業(yè)務系統(tǒng)性能要求較高，業(yè)務量大，不能影響系
統(tǒng)性能的系統(tǒng)，一般應當采用高性能的數(shù)據(jù)抽取接口，比如：
專用數(shù)據(jù)庫驅動接口、OLEDB 接口等；
④ 對于數(shù)據(jù)量特別大的業(yè)務系統(tǒng)數(shù)據(jù)的抽取，必須采用
高效率的數(shù)據(jù)接口，比如專用的API 接口，進行編程。
數(shù)據(jù)的抽取必須能夠充分滿足CRM 數(shù)據(jù)倉庫系統(tǒng)分析
及決策支持的需要，同時必須保證不能影響業(yè)務系統(tǒng)的性能，
所以進行數(shù)據(jù)抽取時必須充分考慮這些因素，制定相應的策
略。
（2）數(shù)據(jù)轉換（ Data Transformation）
數(shù)據(jù)轉換是指對從業(yè)務系統(tǒng)中抽取的源數(shù)據(jù)根據(jù)CRM
數(shù)據(jù)倉庫系統(tǒng)模型的要求，進行數(shù)據(jù)的轉換、清洗、拆分、
匯總等處理，保證數(shù)據(jù)按要求裝入CRM 數(shù)據(jù)倉庫。
根據(jù)實際情況，數(shù)據(jù)轉換工作一般會在以下幾個環(huán)節(jié)中
具體實現(xiàn)：
① 在抽取過程中進行數(shù)據(jù)處理；
② 使用異步數(shù)據(jù)加載，以文件的方式處理；
③ 在數(shù)據(jù)加載過程中進行數(shù)據(jù)處理；
④ 進入數(shù)據(jù)倉庫以后再進行數(shù)據(jù)處理；
采用在數(shù)據(jù)抽取過程中進行數(shù)據(jù)轉換時，必須考慮抽取
的性能以及對業(yè)務系統(tǒng)性能的影響；采用異步數(shù)據(jù)加載需要
以文件方式處理時，必須充分考慮中間磁盤的存儲量以及
ETL 整個流程的協(xié)調(diào)性工作和大量的非SQL 語句的編程；
采用在數(shù)據(jù)加載過程中進行數(shù)據(jù)轉換時，必須考慮加載性能；
采用先將數(shù)據(jù)裝載到CRM 數(shù)據(jù)倉庫后再處理時，必須考慮
CRM 數(shù)據(jù)倉庫引擎的海量數(shù)據(jù)處理能力。
（3）數(shù)據(jù)加載（Data Loading）
數(shù)據(jù)加載就是將從源業(yè)務系統(tǒng)中抽取、轉換后的數(shù)據(jù)加
載到CRM 數(shù)據(jù)倉庫系統(tǒng)中。一般來講，不同的數(shù)據(jù)倉庫提
供廠商，都會有自己的數(shù)據(jù)加載工具以及深入編程的API 接
口。對于用戶而言，需要重點考察的是數(shù)據(jù)加載工具的加載
性能。
數(shù)據(jù)加載策略主要包括兩方面的內(nèi)容：加載周期和數(shù)據(jù)
追加策略。加載周期是指多長時間從業(yè)務系統(tǒng)中抽取并向
CRM 數(shù)據(jù)倉庫中加載一次數(shù)據(jù)。數(shù)據(jù)追加策略是指數(shù)據(jù)每次
是如何向CRM 數(shù)據(jù)倉庫系統(tǒng)中追加的。
根據(jù)CRM 系統(tǒng)所需業(yè)務數(shù)據(jù)的實際情況，建議對不同
業(yè)務系統(tǒng)采用不同的加載周期，但必須保持同一時間業(yè)務數(shù)
據(jù)的完整性。數(shù)據(jù)的追加策略可以根據(jù)數(shù)據(jù)的抽取策略以及
業(yè)務規(guī)則來確定，一般建議采用三種類型：直接追加、全部
覆蓋、更新追加。
2．數(shù)據(jù)的存儲和管理
數(shù)據(jù)倉庫的真正關鍵技術是數(shù)據(jù)的存儲和管理。大量數(shù)
據(jù)的存儲和管理是數(shù)據(jù)倉庫最重要的技術需求。管理大量數(shù)
據(jù)的方法可以通過尋址、索引、數(shù)據(jù)的外延和有效的溢出管
理。在建造CRM 數(shù)據(jù)倉庫時，理想的情況是假定其能夠滿
足處理大量數(shù)據(jù)的需求。對于CRM 中數(shù)據(jù)倉庫數(shù)據(jù)的存儲
和管理，可以從數(shù)據(jù)的粒度、數(shù)據(jù)分割和數(shù)據(jù)組織方面來研
究。這里重點討論CRM 中數(shù)據(jù)倉庫的數(shù)據(jù)粒度和數(shù)據(jù)分割。
（1）數(shù)據(jù)粒度
粒度問題是設計CRM 數(shù)據(jù)倉庫的一個最重要方面。粒
度是指CRM 數(shù)據(jù)倉庫的數(shù)據(jù)單位中保存數(shù)據(jù)的細化或綜合
程度的級別。細化程度越高，粒度級就越小；相反，細化程
度越低，粒度級就越大。
如果CRM 數(shù)據(jù)倉庫的空間很有限的話(數(shù)據(jù)量總是
CRM 數(shù)據(jù)倉庫中的首要問題)，用高粒度級表示數(shù)據(jù)將比用
低粒度級表示數(shù)據(jù)的效率要高得多。高粒度級不僅只需要少
得多的字節(jié)存放數(shù)據(jù)，而且只需要較少的索引項。然而數(shù)據(jù)
量大小和原始空間問題不是僅有的應考慮的問題。為了訪問
大量數(shù)據(jù)，其處理能力的大小同樣也是應考慮的一個因素。
所以，在CRM 數(shù)據(jù)倉庫中數(shù)據(jù)壓縮非常有用。當數(shù)據(jù)被壓
縮后就會大大節(jié)省所用的DASD 存儲空間，節(jié)省所需的索引
項，以及節(jié)省處理數(shù)據(jù)的處理器資源。但是，當提高數(shù)據(jù)粒
度級時，數(shù)據(jù)所能回答查詢的能力就會隨之降低。換句話說，
在一個很低的粒度級上你實際可以回答任何問題，但在高粒
度級上，數(shù)據(jù)所能處理的問題的數(shù)量是有限的。如果在高粒
度級上包括了足夠的細節(jié)，則使用高粒度級數(shù)據(jù)的效率將會
高得多。
在管理數(shù)據(jù)的粒度問題中，粒度的權衡是首要的，大多
數(shù)據(jù)組織的最佳解決辦法是采用多重粒度級的形式。在設計
和構造CRM 數(shù)據(jù)倉庫之初就必須仔細考慮這種權衡。當一
個企業(yè)或組織的CRM 數(shù)據(jù)倉庫中擁有大量數(shù)據(jù)時，在CRM
數(shù)據(jù)倉庫的細節(jié)部分考慮雙重(或多重)粒度級是很有意義的。
事實上，需要多個粒度級而不是一個粒度級的需求，是因為
粒度級設計采用雙重級別應該是幾乎每個機構默認的選擇。
鑒于費用、效率、訪問便利和能夠回答任何可以回答的查詢
的能力，數(shù)據(jù)雙重粒度級是大多數(shù)機構建造CRM 數(shù)據(jù)倉庫
細節(jié)級的最好選擇。只有當一個機構的CRM 數(shù)據(jù)倉庫環(huán)境
中只有相對較少的數(shù)據(jù)時，才應嘗試采用數(shù)據(jù)粒度的單一級
別。
數(shù)據(jù)倉庫中往往存在著多個主題，而用戶對這些主題的
訪問頻率是不同的，就是對屬于同一主題的綜合數(shù)據(jù)，用戶
查詢的概率也不盡相同，因此在這種多重粒度的數(shù)據(jù)倉庫中，
不需要將所有綜合數(shù)據(jù)都放在CRM 數(shù)據(jù)倉庫中，可以把在
一段時間內(nèi)訪問頻率相對較低的這部分綜合數(shù)據(jù)調(diào)出數(shù)據(jù)倉
庫，將其釋放的空間供當前被訪問的綜合數(shù)據(jù)使用。
綜合上述的論述，給出一種數(shù)據(jù)粒度的劃分方法：
① 按數(shù)據(jù)的歷史時序劃分粒度級別，數(shù)據(jù)存貯時間越
久，數(shù)據(jù)匯總粒度級別越高；
② 在粒度級別不同的數(shù)據(jù)間．給出緩沖區(qū)，在緩沖區(qū)內(nèi)
保存同一數(shù)據(jù)的兩種存貯粒度類型，用以回答不同問題；
③ 緩沖區(qū)內(nèi)數(shù)據(jù)按使用頻度決定新的粒度變換．變換閾
值由領域專家給定；
④ 變換粒度的使用頻度閾值的有效性．決定于領域專家
給定的較大的正整數(shù)值，該值取決于專家經(jīng)驗。
（2）數(shù)據(jù)分割
分割是CRM 數(shù)據(jù)倉庫中數(shù)據(jù)的第二個主要的設計問題
(在粒度問題之后)。數(shù)據(jù)分割是指把數(shù)據(jù)分散到各自的物理單
元中去，它們能獨立地處理。在CRM 數(shù)據(jù)倉庫環(huán)境中，問
題不是要不要對當前細節(jié)數(shù)據(jù)進行分割，而是怎樣對當前細
節(jié)數(shù)據(jù)進行分割。對當前細節(jié)數(shù)據(jù)進行分割的總體目的是把
數(shù)據(jù)劃分成小的物理單元。小的物理單元能為操作者和設計
者在管理數(shù)據(jù)時提供比對大的物理單元更大的靈活性。
CRM 數(shù)據(jù)倉庫開發(fā)人員面臨的主要問題之一是在系統(tǒng)
層上還是在應用層上對數(shù)據(jù)進行分割。通常，在應用層上分
割CRM 數(shù)據(jù)倉庫的數(shù)據(jù)是很有意義的。這是有某些重要原
因的，最重要的是在應用層上每年的數(shù)據(jù)可以有不同的定義。
2002 年和2003 年的數(shù)據(jù)定義，可以相同也可以不相同。
CRM 數(shù)據(jù)倉庫中數(shù)據(jù)的性質(zhì)是長期數(shù)據(jù)積累的結果。當數(shù)據(jù)
在系統(tǒng)層上分割時，DBMS 不可避免地希望只有一種數(shù)據(jù)定
義。假定CRM 數(shù)據(jù)倉庫中保存的數(shù)據(jù)時間較長(如達到十
年)，而且數(shù)據(jù)定義經(jīng)常變化，讓DBMS 或操作系統(tǒng)去管理
一個本該只有一種數(shù)據(jù)定義的系統(tǒng)將是毫無意義的。在應用
層上管理數(shù)據(jù)分割的另一重要特點是它能從一個處理集轉移
到另一個處理集而沒有損失。在CRM 數(shù)據(jù)倉庫環(huán)境中，當
工作負載和數(shù)據(jù)量成為真正的負擔時，這種特點就是一種真
正的優(yōu)點。
三、結束語
全球信息化的普及使得企業(yè)CRM 所采集的數(shù)據(jù)量會更
加龐大，因此數(shù)據(jù)倉庫技術的引入可以說是一個根本上的解
決方案，可以為企業(yè)爭取更多的客戶份額，使之在激烈的市
場競爭中立于不敗之地。可以預見，隨著數(shù)據(jù)倉庫技術的進
一步成熟，CRM 也會越來越完善，必將發(fā)揮重要的作用。
參考文獻
[1] 羅納德.S.史威福特.客戶關系管理.楊東龍，姚成龍，黃
燕譯.中國經(jīng)濟出版社.2002.3.
[2] 宋擒豹，楊向榮，沈均毅.數(shù)據(jù)倉庫技術研究.計算機工
程.2002.28.1：125~127.
[3] 熊忠陽，張玉芳，吳中福.數(shù)據(jù)倉庫數(shù)據(jù)加載技術.重慶大
學學報.2002.25.2：106~108.
[4] Alex Berson.構建面向CRM 的數(shù)據(jù)挖掘應用.賀奇，鄭巖
譯.人民郵電出版社.2001.8.
強力推薦：
天柏客戶關系管理系統(tǒng)
天柏