寬表和窄表

寬表和窄表的建設(shè)該如何選擇？

這個(gè)問題相信糾結(jié)了很多從是數(shù)據(jù)庫(kù)開發(fā)、數(shù)據(jù)倉(cāng)庫(kù)開發(fā)和后臺(tái)開發(fā)人員；單單考慮這個(gè)問題，難給出一個(gè)絕對(duì)的答案；本人從事數(shù)據(jù)倉(cāng)庫(kù)開發(fā)工作到現(xiàn)在已經(jīng)有一年半時(shí)間了，對(duì)于這個(gè)問題，我也曾經(jīng)糾結(jié)過，但是是否有絕對(duì)的答案呢？事實(shí)上任何東西都沒有絕對(duì)的說法。

考慮這樣的一個(gè)問題，一個(gè)公司有這樣的一個(gè)需求：

設(shè)計(jì)銷售領(lǐng)域的訂單事實(shí)表，該事實(shí)表應(yīng)該包含哪些維度和度量？事實(shí)表和維表該分別如何去設(shè)計(jì)？

好了，我們把關(guān)鍵信息拿出來，首先我們要有維度包括：銷售員、銷售員所屬部門、下訂單的時(shí)間；度量：銷售量；

那么，訂單事實(shí)表，其實(shí)就是一個(gè)商品銷售的清單；

依照這個(gè)思路，我們建立的第一個(gè)模型可能是以下這樣的：

單單看上去，貌似是符合我們的問題的需要，而且符合數(shù)據(jù)庫(kù)的范式設(shè)計(jì)：沒有冗余字段；但是情況真的就是這樣嗎？

答案是否定的，確實(shí)對(duì)于一般的OLTP系統(tǒng)而言這樣的表設(shè)計(jì)確實(shí)減少了冗余和，增刪改查等操作也很方便，但是往往對(duì)于我們的統(tǒng)計(jì)系統(tǒng)、OLAP、數(shù)據(jù)挖掘而言，情況卻并非如此，舉個(gè)例子：我們要統(tǒng)計(jì)每個(gè)部門各自的銷售量為多少？那么對(duì)于上表,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;

對(duì)于這么一個(gè)簡(jiǎn)單的需求已經(jīng)要寫兩了sql去實(shí)現(xiàn)了，其實(shí)數(shù)據(jù)庫(kù)表模型的的設(shè)計(jì)是靈活的，我們完全可以根據(jù)我們的業(yè)務(wù)去設(shè)計(jì)我們的數(shù)據(jù)表；考慮到部門和銷售員可以是同屬于銷售者這個(gè)維度，只是他們是有上下級(jí)別關(guān)系的那么依照這個(gè)思路，我們的模型可以建立為下面這樣：

那么統(tǒng)計(jì)每個(gè)部門各自的銷售量，可以用如下sql去實(shí)現(xiàn)：

select count(1),a.dep_name from saleser_dim a,order_fact b

on a.sid=b.sid group by a.dep_name;

確實(shí)對(duì)于這個(gè)模型而言，有些情況下會(huì)出現(xiàn)冗余（填寫用戶，沒有填寫部門；填寫部門沒填寫用戶）；但是對(duì)于提取數(shù)統(tǒng)計(jì)的邏輯又相對(duì)來說要簡(jiǎn)單了好多；

考慮到要實(shí)現(xiàn)取數(shù)簡(jiǎn)單，我們還可以想出另外一種方法：

　　看上去好像不錯(cuò)哦~~，取數(shù)據(jù)也就一句sql就搞掂了，但是卻是最最槽糕的情況，有可能一個(gè)銷售員，前幾天登記的部門是a，但是其實(shí)他的所屬于的部門為b，那么對(duì)于上面這個(gè)模型，我們得改動(dòng)銷售員和訂單表；而對(duì)于上面的其他兩個(gè)模型都僅僅需要改動(dòng)一張表就行了，造成查詢數(shù)據(jù)部一致往往也就是這種數(shù)據(jù)模型所造成的。

    所謂的寬表就是字段比較多的表，包含的維度層次比較多，造成冗余也比較多，毀范式設(shè)計(jì)，但是利于取數(shù)統(tǒng)計(jì)，而窄表往往對(duì)于OLTP比較合適，符合范式設(shè)計(jì)原則；