主數據區域中保留了數據倉庫的所有基礎數據及歷史數據，是數據倉庫中最重要的數據區域之一，那主數據區域中主要分為近源模型區和整合（主題）模型區。上一節講到了模型的設計流程如下圖所示。那近源模型層的設計在第2.3和3這兩個步驟中相對簡化，模型表設計的結構同源系統的表結構，字段也一一映射即可。那下面以整合（主題）模型的設計步驟來進行介紹:
整合（主題）模型層主要按主題進行數據整合，以第3范式為主進行表設計，有以下優點：
（1）主題模型從全行角度對客戶、產品、交易、賬戶等進行分類梳理，獲得全行業務數據視圖；
（2）數據模型比較穩定，只要業務實體關系沒有大的變化，不會因為源系統替換或升級導致整合模型出現大的變動。對於數據使用系統和集市來說比較穩定。
（3）模型靈活易擴展，在增加功能的時可擴展模型，不需要重構數據模型，不影響已有數據實體。
當然主題模型梳理設計比較耗費人力，同時規則需要全行認可，需要由一個管理全行數據的業務部門來統籌，可以和數據治理項目一起進行，將數據治理的數據標准等成果在數據倉庫主題模型進行落地。
1、主題模型設計步驟
1.1系統調研及篩選
(1）前期調研與資料收集：調研全行或全公司的系統，從架構、業務數據及流程方面概略了解系統，需要和架構師、各系統負責人進行前期調研溝通，獲取系統說明書、表結構、主要流程說明等資料。
（2）系統級篩選：確定需要入數據倉庫的系統范圍，篩選條件主要考慮系統是否自己產生業務數據或者是業務流程中的一個部分，另外也考慮以下幾方面：
1）系統是否很快會被其他系統替代，是的話需要考慮對接新系統；
2）系統數據結構現階段是否穩定，業務是否有大改造，是的話可以考慮改造完接入；
3）系統與其他系統的關系，是否關聯系統也需要入倉；
4）分布式系統是否數據結構統一，業務全流程包括哪些系統；
5）純外購系統是否能夠得到提供商的支持，因為需要供應商配合調研和分析；
（3）系統講解及整理：
確定入倉的系統后需要與系統負責人進行深入的調研和數據分析，主要步驟包括：
1）系統整體調研：包括系統整理介紹、系統在行內的架構定位、主要功能、和其它系統的上下文關系、以及重要的業務流程和業務規則，同時也要了解系統夜間的切日和日終處理情況，便於后續系統數據采集，那最后產出物為詳細的《XX系統調研報告》，同時也需要獲取源系統的數據庫設計文檔及數據字典，建立和源系統調研問題跟進機制。
1.2確定入倉表及字段
（1）系統數據表篩選映射、代碼整理：
根據系統數據字典中的表清單進行各個表的功能、數據進行梳理，並確定是否入主數據區（入倉），同時對於確定入倉的表進行主題模型映射和代碼字段的整理。那對於表是否入倉主要了解表中數據的業務含義，同時盡量保留粒度比較細的數據。那對於以下情況的表可以不進行入倉：
1）系統控制類和業務流程控制類表：如系統中的序號生成器、系統開門時間、批處理控制表、數據包接收和拆分的記錄；
2）為未來業務拓展預留的表：部分業務系統設計了一些目前尚未開展的業務數據表；未來的業務規則和處理流程存在不確定性，因此暫不入倉。可以在未來進行擴展和補充；
3）中間表和臨時表：在源業務系統中記錄業務操作中間狀態的表；
4）統計和報表類數據：部分系統中有大量的統計或報表類數據，可以使用入倉的明細數據在明確的邏輯和規則下自行進行加工；
5）數據備份表：一般情況下，數據備份表不入倉；
那本步驟產出結果為《XX系統表清單分析》及《XX系統代碼整理》，以下參考模板：
（2）字段級篩選映射
該步驟主要分析，逐一調研分析數據庫表中每個欄位的業務含義，向業務及源系統人員了解並使用樣本數據確認數據質量和數據信息，並確定是否入整合模型。一般近源模型層除了敏感字段、二進制字段外會全部入倉，整合模型除了這兩類還會進行篩選，一般以下類型字段也不進入整合模型：
1）無分析意義的字段：加載時間戳，密碼
2）業務系統操作流程相關字段：下一打印行數，當前頁號，帳頁打印標志、批處理標志,
3）中間計算結果字段：積數，本月累計積數，本期累計貸方發生額
4）未啟用字段：預留字符，預留數值、全空值字段
5）長文本信息，需要明確業務上不使用的舍棄：備注，經辦人，批准人
6）冗余字段：活期賬戶中的客戶名稱，行業類型，經濟性質
那對確定入倉的字段需要進行數據范圍以及關聯字段（主外鍵）分析，看是否符合調研信息，對異常數據需要進行跟進分析，確定原因。這部分工作需要源系統人員在生產環境配合跑驗證SQL。最終產出物為《XX系統字段分析》、《XX系統字段數據質量調研》。
1.3邏輯模型設計
邏輯數據模型（Logical Data Model）是一種圖形的展現方式，采用面向主題的方法有效組織來源多樣的各種業務數據，全面反映銀行復雜的業務規則，它使用統一的邏輯語言描述銀行業務，通過實體和關系勾勒出企業的數據藍圖。有實體、屬性、關系概念，每個主題都是由多個表來實現的，表之間依靠主題的公共碼鍵聯系在一起，形成一個完整的主題。邏輯模型設計工具有商用的EWIN、POWERDESIGN等，目前開源的也有些，但功能和體驗稍差些。
那邏輯模型設計可以由2種路徑，一是銀行根據以往的業務經驗提煉本行業務的關鍵主題，設計出本行的概念模型；二是依托成熟產品進行客戶化，即根據一些數據模型實施公司的產品針對本行實際數據情況進行適應。許多行使用第二種方式，速度較快，項目風險小。那基於已有成熟產品的方案在項目初期就需要選擇好模型產品，一般可以調研其它行的模型落地情況，在我國銀行落地實施較多的產品一般成熟度較高，適用性也經得起實戰。那邏輯模型的客戶化主要有以下步驟：
（1）業務定義整合：主要包括客戶識別、產品定義、內部機構等。客戶識別整合即整合各系統客戶信息，定義唯一客戶號，識別同一客戶。產品定義即在全行角度設置一套產品樹並賦予唯一編號，內部機構也是確定一套內部機構，同時各系統的產品、內部機構都能映射到全行定義的產品和內部機構中。
（2）確定各主題准入、分類、數據整合、歷史處理的主題設計原則，比如客戶分類包括對公、對私、同業等，歷史數據采用拉鏈方式；
（3）基於字段級映射的產出，根據主題設計原則再次檢視各主題梳理入倉字段的所屬主題以及模型中的實體關系是否和源系統實體關系一致，然后將字段映射或新增到現有的主題基礎模型中。
（4）代碼整合：需要根據入倉的代碼字段整合一套數倉的標准代碼，並確定各系統代碼字段映射到數倉標准代碼的規則。一般這個工作也是數據治理數據標准的部分內容，最好先確定全行數據標准，以它作為數倉的代碼標准基礎並進行補充。
（5）模型評估和驗證：通過REVIEW會議由各主題設計人員進行主題設計的講解，由模型組人員進行模型架構、業務規則、實體關系等方面進行評審，修正。模型的驗證是一個持續的過程，特別是在提供數據給應用系統以及數據集市后，還會發現設計的問題，因此需要定期總結和優化。
下一章中也將重點介紹主題模型各主題的數據和設計中的關注點。
1.4物理模型設計
邏輯模型適用於多個數據庫實現，也就是可以有多個物理模型。物理模型設計主要將邏輯模型轉化成可具體實施的數據表及關系並優化應用設計，優化存儲以及提高數據訪問效率，主要考慮點有：
（1）考慮刪除沒有數據來源的實體和屬性，增加公共字段如數據新增和修改日期。
（2）考慮刪除只有主鍵的實體，對於表較少的表或主題考慮合並到其它表或主題中，如渠道主題表和字段較少，可以考慮合並。
（3）選擇和調整主索引和分區字段，使數據均勻分布，提高性能。
（4）對重要主題域的關鍵實體給予更多關注，一般客戶、協議、事件會占用80%的數據空間，需要重點關注這幾個主題的設計，如對事件表和近源層對應源表變化不大，可按視圖實現，節省空間。
（5）根據應用需求和關鍵字段適當增加關鍵的冗余字段（反范式），提高數據訪問效率，比如在客戶主表、協議主表增加常用查詢字段的冗余可以減少關聯，提高效率。
（6）考慮大表的分拆和多表的合並，提高效率。
（7）確定字段的英文命名和數據類型，按命名規范對模型字段、索引、表等進行命名。特別對於字段長度和精度，物理模型中的字段設計比源系統要長，需要考慮后續的擴展，因為源系統經常會增加字段長度或精度，在物理模型中需要提前考慮，以免后續影響數據使用系統。
（8）分區、壓縮和其它類索引：需要對常用的查詢字段或條件建立索引，提高查詢效率。
基於邏輯模型生成的物理表，並考慮上述優化點，可以得到最終的數據倉庫主題模型的物理模型並進行后續維護優化。