簡介
Rule 1:- What is the Nature of the application(OLTP or OLAP)?
Rule 2:- Break your data in to logical pieces, make life simpler
Rule 3:- Do not get overdosed with rule 2
Rule 4:- Treat duplicate non-uniform data as your biggest enemy
Rule 5:- Watch for data separated by separators.
Rule 6:- Watch for partial dependencies.
Rule 7:- Choose derived columns preciously
Rule 8:- Do not be hard on avoidingredundancy, if performance is the key
Rule 9:- Multidimensional data is a different beast altogether
Rule 10:- Centralize name value table design
Rule 11:- For unlimited hierarchical data self-reference PK and FK
在您開始閱讀這篇文章之前，我得明确地告訴您，我并不是一個資料庫設計領域的大師。以下列出的 11 點是我對自己在平時項目實踐和閱讀中學習到的經驗總結出來的個人見解。我個人認為它們對我的資料庫設計提供了很大的幫助。實屬一家之言，歡迎拍磚 : )
我之是以寫下這篇這麼完整的文章是因為，很多開發者一參與到資料庫設計，就會很自然地把 “三範式” 當作銀彈一樣來使用。他們往往認為遵循這個規範就是資料庫設計的唯一标準。由于這種心态，他們往往盡管一路碰壁也會堅持把項目做下去。
如果你對 “三範式” 不清楚，請點選這裡（FQ）一步一步的了解什麼是“三範式”。
大家都說标準規範是重要的指導方針并且也這麼做着，但是把它當作石頭上的一塊标記來記着（死記硬背）還是會帶來麻煩的。以下 11 點是我在資料庫設計時最優先考慮的規則。
規則 1：弄清楚将要開發的應用程式是什麼性質的（OLTP 還是 OPAP）？
當你要開始設計一個資料庫的時候，你應該首先要分析出你為之設計的應用程式是什麼類型的，它是 “事務處理型”（Transactional） 的還是 “分析型” （Analytical）的？你會發現許多開發人員采用标準化做法去設計資料庫，而不考慮目标程式是什麼類型的，這樣做出來的程式很快就會陷入性能、客戶定制化的問題當中。正如前面所說的，這裡有兩種應用程式類型， “基于事務處理” 和 “基于分析”，下面讓我們來了解一下這兩種類型究竟說的是什麼意思。
事務處理型：這種類型的應用程式，你的最終使用者更關注資料的增查改删（CRUD，Creating/Reading/Updating/Deleting）。這種類型更加官方的叫法是 “OLTP” 。
分析型：這種類型的應用程式，你的最終使用者更關注資料分析、報表、趨勢預測等等功能。這一類的資料庫的 “插入” 和 “更新” 操作相對來說是比較少的。它們主要的目的是更加快速地查詢、分析資料。這種類型更加官方的叫法是 “OLAP” 。
那麼換句話說，如果你認為插入、更新、删除資料這些操作在你的程式中更為突出的話，那就設計一個規範化的表否則的話就去建立一個扁平的、不規範化的資料庫結構。
以下這個簡單的圖表顯示了像左邊 Names 和 Address 這樣的簡單規範化的表，怎麼通過應用不規範化結構來建立一個扁平的表結構。
規則 2：将你的資料按照邏輯意義分成不同的塊，讓事情做起來更簡單
這個規則其實就是 “三範式” 中的第一範式。違反這條規則的一個标志就是，你的查詢使用了很多字元串解析函數
例如 substring、charindex 等等。若真如此，那就需要應用這條規則了。
比如你看到的下面圖檔上有一個有學生名字的表，如果你想要查詢學生名字中包含“Koirala”，但不包含“Harisingh”的記錄，你可以想象一下你将會得到什麼樣的結果。
是以更好的做法是将這個字段拆分為更深層次的邏輯分塊，以便我們的表資料寫起來更幹淨，以及優化查詢。
規則 3：不要過度使用 “規則 2”
開發者都是一群很可愛的生物。如果你告訴他們這是一條解決問題的正路，他們就會一直這麼做下去，做到過了頭導緻了一些不必要的後果。這也可以應用于我們剛剛在前面提到的規則2。當你考慮字段分解時，先暫停一下，并且問問你自己是否真的需要這麼做。正如所說的，分解應該是要符合邏輯的。
例如，你可以看到電話号碼這個字段，你很少會把電話号碼的 ISD 代碼單獨分開來操作（除非你的應用程式要求這麼做）。是以一個很明智的決定就是讓它保持原樣，否則這會帶來更多的問題。
規則 4：把重複、不統一的資料當成你最大的敵人來對待
集中那些重複的資料然後重構它們。我個人更加擔心的是這些重複資料帶來的混亂而不是它們占用了多少磁盤空間。
例如下面這個圖表，你可以看到 “5th Standard” 和 “Fifth standard” 是一樣的意思，它們是重複資料。現在你可能會說是由于那些錄入者錄入了這些重複的資料或者是差勁的驗證程式沒有攔住，讓這些重複的資料進入到了你的系統。現在，如果你想導出一份将原本在使用者眼裡十分困惑的資料顯示為不同實體資料的報告，該怎麼做呢？
解決方法之一是将這些資料完整地移到另外一個主表，然後通過外鍵引用過來。在下面這個圖表中你可以看到我們是如何建立一個名為 “Standards”（課程級别） 的主表，然後同樣地使用簡單的外鍵連接配接過去。
規則 5：當心被分隔符分割的資料，它們違反了“字段不可再分”
前面的規則 2 即“第一範式”說的是避免 “重複組” 。下面這個圖表作為其中的一個例子解釋了 “重複組”是什麼樣子的。如果你仔細的觀察 syllabus（課程） 這個字段，會發現在這一個字段裡實在是填充了太多的資料了。像這些字段就被稱為 “重複組” 了。如果我們又得必須使用這些資料，那麼這些查詢将會十分複雜并且我也懷疑這些查詢會有性能問題。
這些被塞滿了分隔符的資料列需要特别注意，并且一個較好的辦法是将這些字段移到另外一個表中，使用外鍵連接配接過去，同樣地以便于更好的管理。
那麼，讓我們現在就應用規則2（第一範式） “避免重複組” 吧。你可以看到上面這個圖表，我建立了一個單獨的 syllabus（課程） 表，然後使用 “多對多” 關系将它與 subject（科目） 表關聯起來。
通過這個方法，主表（student 表）的 syllabus（課程） 字段就不再有重複資料和分隔符了。
規則 6：當心那些僅僅部分依賴主鍵的列
留心注意那些僅僅部分依賴主鍵的列。例如上面這個圖表，我們可以看到這個表的主鍵是 Roll No.+Standard。現在請仔細觀察 syllabus 字段，可以看到 syllabus（課程） 字段僅僅關聯（依賴） Standard（課程級别） 字段而不是直接地關聯（依賴）某個學生（Roll No. 字段）。
Syllabus（課程） 字段關聯的是學生正在學習的哪個課程級别（Standard 字段）而不是直接關聯到學生本身。那如果明天我們要更新教學大綱（課程）的話還要痛苦地為每個同學也修改一下，這明顯是不符合邏輯的（不正常的做法）。更有意義的做法是将這些字段從這個表移到另外一個表，然後将它們與 Standard（課程級别）表關聯起來。
你可以看到我們是如何移動 syllabus（課程）字段并且同樣地附上 Standard 表。
這條規則隻不過是 “三範式” 裡的 “第二範式”：“所有字段都必須完整地依賴主鍵而不是部分依賴”。
規則 7：仔細地選擇派生列
如果你正在開發一個 OLTP 型的應用程式，那強制不去使用派生字段會是一個很好的思路，除非有迫切的性能要求，比如經常需要求和、計算的 **OLAP **程式，為了性能，這些派生字段就有必要存在了。
通過上面的這個圖表，你可以看到 Average 字段是如何依賴 Marks 和 Subjects 字段的。這也是備援的一種形式。是以對于這樣的由其他字段得到的字段，需要思考一下它們是否真的有必要存在。
這個規則也被稱為 “三範式” 裡的第三條：“不應該有依賴于非主鍵的列” 。 我的個人看法是不要盲目地運用這條規則，應該要看實際情況，備援資料并不總是壞的。如果備援資料是計算出來的，看看實際情況再來決定是否應用這第三範式。
規則 8：如果性能是關鍵，不要固執地去避免備援
不要把 “避免備援” 當作是一條絕對的規則去遵循。如果對性能有迫切的需求，考慮一下打破正常。正常情況下你需要做多個表的連接配接操作，而在非正常的情況下這樣的多表連接配接是會大大地降低性能的。
規則 9：多元資料是各種不同資料的聚合
** OLAP **項目主要是解決多元資料問題。比如你可以看看下面這個圖表，你會想拿到每個國家、每個顧客、每段時期的銷售額情況。簡單的說你正在看的銷售額資料包含了三個次元的交叉。
為這種情況做一個實際的設計是一個更好的辦法。簡單的說，你可以建立一個簡單的主要銷售表，它包含了銷售額字段，通過外鍵将其他所有不同次元的表連接配接起來。
規則 10：将那些具有“名值表”特點的表統一起來設計
很多次我都遇到過這種 “名值表” 。 “名值表” 意味着它有一些鍵，這些鍵被其他資料關聯着。比如下面這個圖表，你可以看到我們有 Currency（貨币型）和 Country（國家）這兩張表。如果你仔細觀察你會發現實際上這些表都隻有鍵和值。
對于這種表，建立一個主要的表，通過一個 Type（類型）字段來區分不同的資料将會更有意義。
規則 11：無限分級結構的資料，引用自己的主鍵作為外鍵
我們會經常碰到一些無限父子分級結構的資料（樹形結構？）。例如考慮一個多級銷售方案的情況，一個銷售人員之下可以有多個銷售人員。注意到都是 “銷售人員” 。也就是說資料本身都是一種。但是層級不同。這時候我們可以引用自己的主鍵作為外鍵來表達這種層級關系，進而達成目的。
這篇文章的用意不是叫大家不要遵循範式，而是叫大家不要盲目地遵循範式。根據你的項目性質和需要處理的資料類型來做出正确的選擇。
轉自：http://kb.cnblogs.com/page/138526/
英文原文:http://www.c-sharpcorner.com/UploadFile/shivprasadk/11-important-database-designing-rules/