前言：數據集市的目標
數據集市，是數據倉庫 ADM 層最主要的數據形態，應用在特定業務場景的高度匯總數據，支持特定人員或部門進行數據分析、統計、決策等行為。（數據倉庫分層架構及建設思路可查閱作者的《淺談銀行數據倉庫的構建之路》）概念理解起來不難，難在如何制定數據集市的落地方式，這時必須結果導向，從實現目標進行反推。
數據集市的目標
從概念可以了解，數據集市是應用在特定業務場景的，專門支持特定人員或部門的數據集，所以數據集市的首要目標是滿足特定人員或部門提出的業務場景。比如報表集市，業務人員要求的是按照需求文檔開發出固定報表查詢即可，可是開發團隊卻開發出一張張大寬表給業務人員進行自助查詢，希望業務人員通過大寬表就可以隨時設計出自己想要的報表，最終業務人員願意買賬嗎？
數據集市是以實現特定人員或部門提出的特定業務場景為目標進行設計。
數據集市的模型數量有標准要求嗎？
別人家一個數據集市少則十幾個模型，多則上百個模型，是否模型數量達到一定程度才能稱為數據集市？還是從目標出發，數據集市是為了實現特定業務場景而設計，而業務場景也是有大小之分的。小的業務場景可能一張報表就可以實現，比如 2020 年度單位存款基礎數據報送要求，大的業務場景確實需要上百個模型來支持，比如零售管理部的營銷分析集市。無論是一張報表還是上百個模型，都屬於實現了特定業務場景的數據集市。當然，數據集市過小，比如上述的一張報表，會合並到大的數據集市中，比如報表集市，為了更好實現維護與管理。
數據集市的模型數量沒有標准要求，關鍵是能否實現目標。
數據集市的建模方式有標准要求嗎？
目前主流的標准建模方式有三類：
1） 星型模型
最常用的建模方式，模型由一個事實表與一組維表連接而成，維表只能與事實表關聯，維表間不能關聯，猶如被多個衛星環繞核心行星的系統，所以稱為星型模型。
2） 雪花模型
雪花模型同樣由一個事實表與一組維表連接而成，對比星型模型，雪花模型的維表是由大維表與小維表連接而成，這樣大維表與小維表之間又形成一個星型模型。一個大的星型模型里面嵌套小的星型模型，形狀猶如一片完整的雪花四周由小雪花連接而成，所以稱為雪花模型。雪花模型實際是星型模型的范式建模形態，把維表拆分成三范式避免數據冗余。實際上適量的數據冗余對數據倉庫而言是允許的（數據集市也是一種數據冗余），但維表過於范式設計會增加使用的難度，所以一般很少使用雪花模型建模。
3） 星座模型
數據集市模型一般由多個事實表與一組維表連接而成的，事實表之間不能直接連接，但可以通過維表進行連接，而一個維表可以被多個事實表連接，其形狀猶如由多個行星系統組成的星系，所以稱為星座模型。星座模型屬於星型模型的擴展，更符合數據集市的建模思路，同樣屬於最常用的建模方式。
所以數據集市是否必須按照某類標准方式設計模型呢？也不一定，只要數據集市能滿足特定業務場景所需，哪怕由一組事實表模型組成也是允許的。實際上，為了提高數據的使用性，數據集市也會出現分層模型設計，第二章“數據集市建模思路”會進行詳細介紹。
數據集市不必拘泥於標准建模方式，關鍵是能否實現目標。
數據集市建模思路
以下從一個監管報送項目的數據集市建模實踐來逐步闡述數據集市建模思路。
需求分析
數據集市的目標是實現特定業務場景的數據集，所以設計數據集市模型前必須清晰了解需求的內容與意圖。監管報送項目的需求一般都比較清晰，因為監管部門下發的報送要求文檔一般會把統計項的報送口徑和規范要求寫得盡量清晰，減少雙方關於需求內容的反復溝通。而對於分析型需求，比如營銷集市或風險集市，業務人員可能都不清楚自己想要什么，更不要說在需求文檔上寫得清晰。針對這類需求，一般要從業務場景入手去提煉業務人員的真實需求。未來分享營銷集市建模實踐時會詳細介紹。
這個監管報送項目包含了同業、單位、個人客戶的存款、貸款、擔保、債券等主題的數據報送，在這里挑選單位、個人客戶的貸款部分來講述建模實踐。該部分的需求如下所示（為了信息保密，本文內容與實際需求會存在一定差異）：
從需求內容可分析出數據集市需包含單位貸款客戶信息、個人貸款客戶信息、單位貸款的機構、余額、發生額及賬戶信息，個人貸款的機構、余額、發生額及賬戶信息。這個分析結果會對后續的數據建模起到關鍵性的作用。
從共性角度設計數據集市的分層
根據需求分析結果，可以發現除了單位貸款與個人貸款的發生額，其他信息都可以歸納為單位/個人貸款客戶信息、單位/個人貸款賬戶信息（機構信息和余額可以歸納到賬戶信息內），具體為：
從模型內容可以看出兩點：
1） 共性模型雖然屬於原子粒度數據，但也經過了特定條件所篩選的數據集，所以數據集市應按實際場景盡量減少多余的數據；
2） 共性模型必須包含應用模型所需的所有數據，未來應用模型需要擴展屬性，且擴展屬性可從共性模型取數時，必須先擴展共性模型，再擴展應用模型。
具體模型如下圖所示：
對所需的共性元素構建數據集市的共性模型，有利於數據的共享用以快速構建相關應用，也在數據集市與主題模型層之間再構建一層緩沖層，鞏固應用的穩定性。
從產品角度設計數據集市的主題
數據模型設計完成后，建議划分相應主題對模型進行分類存放，有利於模型的識別及擴展。由於業務場景習慣以產品為維度進行數據展示，所以從產品角度划分數據集市主題更符合業務場景。比如上述的共性模型可划分客戶和貸款兩個主題，具體如下：
未來要擴展存款數據模型時，新增存款主題 FBDS_DEP 存款數據模型即可，而且整個數據模型也會顯得十分清晰。
具體模型如下圖所示：
對數據集市模型進行主題分類，有利於模型的識別及擴展，建議從產品的角度划分數據集市的模型主題。
從目標角度設計數據集市的對象
共性模型為應用模型提供數據預計算及復用，但一般共性模型並不能被應用系統直接使用，所以還必須生成目標數據提供應用系統使用。結合共性模型與應用模型，數據集市的對象為：
最終模型如下圖所示：
總結：不追求完美建模
從上述監管報送項目的建模實踐，可基本了解數據集市的建模思路，數據模型也隨着設計的步伐逐漸浮現。模型設計完畢是否代表整個旅程已經結束了呢？恰恰相反，模型設計完畢只是運營維護的開始。
有些童鞋設計模型時想要追求完美，期望能設計出兼容未來需求的數據模型，但這個想法是正確的嗎？比如上述監管報送項目的數據集市模型能設計出一款通用的數據模型，兼容貸款、存款、擔保、債券等所有的數據嗎？答案是，可能可以，但難度極高，且由於模型過度整合會導致使用者閱讀及使用起來極度困難。所以，對數據模型進行整合時，必須圍繞“共性”兩字進行設計，且划分多主題進行表達，才能實現清晰的數據集市數據模型。
數據集市數據模型后續維護應如何進行呢？這里先不展開來講，舉個具體的例子提示一下，未來增加存款數據模型時，必定包含存款客戶數據這一塊，那么存款客戶數據應該與貸款客戶數據整合為一個模型嗎？假如整合，貸款客戶與存款客戶可能存在較大差異，整合程度不高，最終使用模型時需消耗大量系統資源進行篩選關聯；假如不整合，貸款客戶與存款客戶之間又存在冗余數據，導致相同的客戶數據重復加工。所以，整合與拆分的權衡，還是在於能否達成目標與系統資源的支持程度。
數據集市數據建模切忌追求完美，應圍繞着目標，不斷迭代優化到能靈活運用即可。