基本概念
寬表從字面意義上講就是字段比較多的資料庫表。通常是指業務主題相關的指標、維度、屬性關聯在一起的一張資料庫表。
由於把不同的內容都放在同一張表儲存，寬表已經不符合三正規化的模型設計規範，隨之帶來的主要壞處就是資料的大量冗餘，與之相對應的好處就是查詢效能的提高與便捷。
這種寬表的設計廣泛應用於資料探勘模型訓練前的資料準備，通過把相關字段放在同一張表中，可以大大提高資料探勘模型訓練過程中迭代計算時的效率問題。
資料倉儲應用中，寬表模型以結構簡單，模型容易理解，資料訪問效率等優勢，被業界廣泛採用。
所謂寬表就是，基於某個實體分析物件而建立的乙個邏輯資料體系，由實體的維度、描述資訊、以及基於這個實體一系列度量組成。
它是乙個邏輯的概念，在物理實現中不可能就針對乙個實體物件建立乙個大寬表。
因為這樣，對於，重新整理效率，容錯能力，擴充套件能力都是乙個很大的挑戰，如何設計和組織寬表的體系結構呢？
其實，我們回到軟體設計的基本思想-高內聚，低耦合。我們要從在業務、etl重新整理、指標屬性、資料**等角度，讓高度內聚的屬性、描述、度量放在乙個表中。
基本可以從兩個維度矩陣進行切割：
第一：按實體屬性可能涉及的業務範圍進行劃分
第二：按業務指標的歷史週期屬性進行劃分，在歷史週期上我們可以分為以下幾類：
1、當前使用者的基本屬性和維度，資料相對靜態，修改較少。統計的集合包括所有實體物件。
2、使用者在統計日發生的行為度量指標。這類資料可以根據行為的增量資料就是，統計集合僅僅是當前統計日發生過行為的實體物件。
3、使用者在最近乙個週期內的度量指標累計，它由統計日發生的行為度量指標在歷史上聚合而成。可以根據業務需要可以就是自然月，自然周。或是最近周、最近月移動聚合資料。它統計的集合是最近一段時間內發生過行為的實體物件。
4、根據使用者歷史行為而衍生出的度量維度以及使用者當前存量類指標（比如餘額，總的產品數，當前總的帳戶數）比如第一行為的時間，最後一次行為的時間，統計的集合包括所有發生過一次行為的實體物件。
這個問題相信糾結了很多從是資料庫開發、資料倉儲開發和後台開發人員；
單單考慮這個問題，難給出乙個絕對的答案；
本人從事資料倉儲開發工作到現在已經有一年半時間了，對於這個問題，我也曾經糾結過，但是是否有絕對的答案呢？
事實上任何東西都沒有絕對的說法。
需求
考慮這樣的乙個問題，乙個公司有這樣的乙個需求：
設計銷售領域的訂單事實表，該事實表應該包含哪些維度和度量？
事實表和維錶該分別如何去設計？
維度包括：銷售員、銷售員所屬部門、下訂單的時間；
度量：銷售量；
那麼，訂單事實表，其實就是乙個商品銷售的清單；
模型一依照這個思路，我們建立的第乙個模型可能是以下這樣的：
單單看上去，貌似是符合我們的問題的需要，而且符合資料庫的正規化設計：沒有冗餘字段；
但是情況真的就是這樣嗎？
答案是否定的，確實對於一般的oltp系統而言這樣的表設計確實減少了冗餘和，增刪改查等操作也很方便，但是往往對於我們的統計系統、olap、資料探勘而言，情況卻並非如此。
舉個例子：我們要統計每個部門各自的銷售量為多少？
那麼對於上表,sql是這樣的：
select a.
*,b.sid into
#dep_saleser from department a,saleser_dim b on a.dep_id = b.dep_id;
select
count(1
),a.dep_name from
#dep_saleser a,order_fact b on a.sid=b.sid group by a.dep_name;
對於這麼乙個簡單的需求已經要寫兩了sql去實現了，其實資料庫表模型的的設計是靈活的，我們完全可以根據我們的業務去設計我們的資料表；
考慮到部門和銷售員可以是同屬於銷售者這個維度，只是他們是有上下級別關係的那麼依照這個思路，我們的模型可以建立為下面這樣：
模型二那麼統計每個部門各自的銷售量，可以用如下sql去實現：
select count(1
),a.dep_name from saleser_dim a,order_fact b on a.sid=b.sid group by a.dep_name;
模型三考慮到要實現取數簡單，我們還可以想出另外一種方法：
模型三看上去好像不錯哦~~，取資料也就一句sql就搞掂了，但是卻是最最槽糕的情況，有可能乙個銷售員，前幾天登記的部門是a，但是其實他的所屬於的部門為b，那麼對於上面這個模型，我們得改動銷售員和訂單表；而對於上面的其他兩個模型都僅僅需要改動一張表就行了，造成查詢資料部一致往往也就是這種資料模型所造成的。
所謂的寬表就是字段比較多的表，包含的維度層次比較多，造成冗餘也比較多，毀正規化設計，但是利於取數統計，而窄表往往對於oltp比較合適，符合正規化設計原則
會簽 資料庫表設計 資料庫設計以及三大正規化
1 資料庫設計的流程 在資料庫設計的流程上，我們通常根據需求畫出資料的 er 圖。然後在通過 er 圖生成資料庫的建庫指令碼。er 圖 所謂的 er 圖就是資料庫關係圖。2 為什麼我們使用 er 圖來實現資料庫設計的設計呢?可見即可得，使用 er 圖可以通過圖形的方式展示表與表直接的關係 可以根據設...
資料庫表設計的三大正規化
關係表的規範化 規範化主要是決定關係表應該擁有哪些屬性，其目的是建立良好結構的關係表，去除關係表中的重複資料，去除關係表中的不一致的依賴性，避免在新增 刪除或者更新資料時造成錯誤或者資料不一致的異常情況。關係表的規範化首要工作是處理主鍵與屬性之間的 功能依賴 它是 正規化的基礎。第一正規化 1nf ...
資料庫表設計三大正規化原則
a 所有字段值都是不可分解的原子值 b 也就是說在乙個資料庫表中，乙個表中只能儲存一種資料，不可以把多種資料儲存在同一張資料庫表中 c 資料表中的每一列資料都和主鍵直接相關，而不能間接相關 1 第一正規化 確保每列保持原子性 第一正規化是最基本的正規化。如果資料庫表中的所有字段值都是不可分解的原子值...