1、數據庫設計的三大范式，轉載地址：http://www.cnblogs.com/linjiqin/archive/2012/04/01/2428695.html

為了建立冗余較小、結構合理的數據庫，設計數據庫時必須遵循一定的規則。在關系型數據庫中這種規則就稱為范式。范式是符合某一種設計要求的總結。要想設計一個結構合理的關系型數據庫，必須滿足一定的范式。 ? ? ? ? ? ? ?

在實際開發中最為常見的設計范式有三個：

1．第一范式(確保每列保持原子性)

第一范式是最基本的范式。如果數據庫表中的所有字段值都是不可分解的原子值，就說明該數據庫表滿足了第一范式。

第一范式的合理遵循需要根據系統的實際需求來定。比如某些數據庫系統中需要用到“地址”這個屬性，本來直接將“地址”屬性設計成一個數據庫表的字段就行。但是如果系統經常會訪問“地址”屬性中的“城市”部分，那么就非要將“地址”這個屬性重新拆分為省份、城市、詳細地址等多個部分進行存儲，這樣在對地址中某一部分操作的時候將非常方便。這樣設計才算滿足了數據庫的第一范式，如下表所示。

上表所示的用戶信息遵循了第一范式的要求，這樣在對用戶使用城市進行分類的時候就非常方便，也提高了數據庫的性能。

???????????? ???

2．第二范式(確保表中的每列都和主鍵相關)

第二范式在第一范式的基礎之上更進一層。第二范式需要確保數據庫表中的每一列都和主鍵相關，而不能只與主鍵的某一部分相關（主要針對聯合主鍵而言）。也就是說在一個數據庫表中，一個表中只能保存一種數據，不可以把多種數據保存在同一張數據庫表中。

比如要設計一個訂單信息表，因為訂單中可能會有多種商品，所以要將訂單編號和商品編號作為數據庫表的聯合主鍵，如下表所示。

?訂單信息表

這樣就產生一個問題：這個表中是以訂單編號和商品編號作為聯合主鍵。這樣在該表中商品名稱、單位、商品價格等信息不與該表的主鍵相關，而僅僅是與商品編號相關。所以在這里違反了第二范式的設計原則。

而如果把這個訂單信息表進行拆分，把商品信息分離到另一個表中，把訂單項目表也分離到另一個表中，就非常完美了。如下所示。

這樣設計，在很大程度上減小了數據庫的冗余。如果要獲取訂單的商品信息，使用商品編號到商品信息表中查詢即可。

?????????????????

3．第三范式(確保每列都和主鍵列直接相關,而不是間接相關)

第三范式需要確保數據表中的每一列數據都和主鍵直接相關，而不能間接相關。

比如在設計一個訂單數據表的時候，可以將客戶編號作為一個外鍵和訂單表建立相應的關系。而不可以在訂單表中添加關于客戶其它信息（比如姓名、所屬公司等）的字段。如下面這兩個表所示的設計就是一個滿足第三范式的數據庫表。

這樣在查詢訂單信息的時候，就可以使用客戶編號來引用客戶信息表中的記錄，也不必在訂單信息表中多次輸入客戶信息的內容，減小了數據冗余。

2、寬表窄表理解，轉載地址：http://www.cnblogs.com/super-d2/p/3384938.html

寬表和窄表的建設該如何選擇？

這個問題相信糾結了很多從是數據庫開發、數據倉庫開發和后臺開發人員；單單考慮這個問題，難給出一個絕對的答案；本人從事數據倉庫開發工作到現在已經有一年半時間了，對于這個問題，我也曾經糾結過，但是是否有絕對的答案呢？事實上任何東西都沒有絕對的說法。

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

設計銷售領域的訂單事實表，該事實表應該包含哪些維度和度量？事實表和維表該分別如何去設計？

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

那么，訂單事實表，其實就是一個商品銷售的清單；

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

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

答案是否定的，確實對于一般的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比較合適，符合范式設計原則；

3、從這兩篇文章的說明，個人理解為寬表還是傾向于破壞第二范式，而實際上冗余既取決于設計，也取決于實際數據的管理。

總結

以上是生活随笔為你收集整理的(转载)数据库范式及宽表窄表理解的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。