我所遵守的11條資料庫設計準則,11條資料庫準則

來源:互聯網
上載者:User

我所遵守的11條資料庫設計準則,11條資料庫準則

前言:作者Shivprasad koirala,前微軟ASP/ASP.NET的MVC工程師,現於印度任CEO職位。學生初次翻譯,如有不妥,不吝賜教。


簡介

在你開始閱讀這篇文章之前,我要先告訴你我不算是資料庫設計方面的什麼大師。下面的11條準則,是我從項目、從我自身的經驗和我自己的理解和學習中得來的。我個人認為在資料庫設計方面運用這些準則能使我受益匪淺。我也歡迎任何批評與指點。

我之所以要寫這麼一篇詳盡的文章,是因為,許多開發人員設計資料庫的時候十分信奉“三個範式”(譯者註:而沒有結合實際情況)。他們認為三範式是資料庫設計的唯一真諦。隨著項目開發的不斷推進,持有這些想法的人會經常碰壁和遇上無窮無盡的麻煩。

如果你還不太瞭解什麼是範式,可以點擊這裡:3 normal forms: part1-part2-part3(譯者註:原文為yotube視頻,由於眾所周知的原因國內無法觀看,我已將原視頻分享到csdn下載區,下載免積分),這個教程將會手把手教你這三個範式。

“範式”是非常重要的準則,但是如果完全一味的遵守,不做絲毫改變的話,會讓你經常陷入麻煩之中。當我設計資料庫時,我將下面這11條重要的準則牢牢記在心中。準則1:應用的本質是什麼(OLTP還是OLAP)?

(譯者註:聯機交易處理或線上分析處理,即偏向於增刪改查還是偏向於資料分析)

當你開始設計資料庫的時候,所要做的第一件事是分析你設計的應用的本質,是事務型呢還是分析型呢。你會發現,許許多多的開發人員根本沒有考慮自己的應用到底是屬於哪種類型,而是全部按照“範式”的準則來設計,然後就碰上了各種各樣的效能和定製的問題。正如我所說,有兩種應用:基於事務型的和基於分析型的,那麼接下來讓我們瞭解一下這兩種類型具體是什麼。

事務型:這種類型的應用,終端使用者對增刪改查更為關注,比如,增加、讀取、更新和刪除記錄。對於這種類型的資料庫,正式來說我們稱呼為OLTP(譯者註:Online Transaction Processing,聯機交易處理)。

分析型:這種類型的應用,終端使用者更關注與對資料的分析、產生報告和對資料的預測等。這種類型的資料庫很少執行插入或是更新資料的操作。這種設計的主要意圖是以最快的速度從資料庫擷取資料,並進行分析。對於這種類型的資料庫,正式來說我們稱呼為OLAP(譯者註:Online Analytical Processing,線上分析處理)。

換句話說,如果你發現在資料庫上進行插入、更新或刪除更為重要,那你應該遵循標準的範式來設計,否則應該建立一個扁平非規範的資料庫結構。

展示了如何在左側姓名和地址表中運用非正常化設計思想,來建立右側的不遵守標準範式的扁平的非規範資料結構。

準則2:將你的資料劃分成若干邏輯片段,讓生活更美好

這條準則實際上就是第一範式。違背了這條準則的一個明顯特徵是,你的查詢語句中用了一大堆字串解析函數,如substring、charindex等。如果的卻是這樣,那麼你需要應用一下這條準則。

舉個例子,表中有個欄位是“Student Name”,如果你想要查詢名字中帶有"Koirala"而不帶有"Harisingh"的學生,你可以想象到時候你寫出來的查詢語句是什麼樣的。

所以一個更好的方案是將這個欄位分解成更詳細的邏輯片段,這樣我們就能寫出更乾淨,也更完美的查詢語句了。

準則3:不要過度使用準則2

開發人員們都是聰明人。如果你告訴了他們一個門路,那麼他們就總是使用這個方法。準則2用過頭會導致一些你根本不想要的結果。但是準則2本身是非常有用的。當你想著"把這玩意兒拆了"的時候,暫停一下,問問你自己,真有必要拆嗎?正如我剛才所說,拆分必須是邏輯性的。

舉個例子,你可以看到中有個電話號碼的欄位,你幾乎不會對號碼的ISD(International Subscriber Dialing,國際訂戶撥號)分別進行管理(除非哪個項目裡真有這個需求),所以就這麼把號碼放著顯然更明智。要是你真的把它們拆了,那到時候你就得面對一大堆的"拆分後遺症"了。

準則4:冗餘的不統一資料是你最大的敵人

小心冗餘資料,並重構它們。我並不擔心冗餘資料會佔用很多磁碟空間,我所擔心的是這些冗餘資料所造成的困惑與混亂。

比如說,在中,你會發現“5th Standard”和“Fifth standard”是一個意思,只不過描述的形式略微不同。你可能會解釋說,這些資料是之前有人亂錄入的,而且還沒有經過驗證。當你打算匯出一個報告的時候,對於這個欄位將產生兩份不一樣的報告,當使用者看到這樣的報告,他們恐怕就要在風中淩亂了。


一個解決辦法就是,把這些資料移到一個新表中,然後原來的表以引用的方式使用這些資料。中你可以看到,我建立了一個新的叫做"Standards"的表,然後用一個外鍵將這兩個表串連起來。

準則5:小心那些用分隔字元分開的資料

第一範式的第二條內容規定了一個位置上不能存多個值。就是一個存了多個值的例子。仔細觀察"Syllabus"欄位就會發現,我們塞了太多的資料到這個欄位中了。這種欄位我們成為"重複的群組",如果我們要操作這些資料,不僅查詢語句會寫的很複雜(且不論對錯),而且我很懷疑這種查詢的效率。


這種某些列裡塞了很多資料的欄位,要特別小心的對待,一個比較好的解決辦法是:將這些欄位移到不同的表中,然後將它們用外鍵相連,以便於從邏輯和操作上更好的進行管理。


我們需要遵守第一範式的第二條規定:一個位置不能儲存多個值。從中可以看到,我建立了一個獨立的"syllabus"表,然後與主表建立了多對多的關聯。

用這種方法的話,主表中的"syllabus"欄位不再塞入一大堆用分隔字元分開的資料了。邏輯上易於理解,操作性也更強。

準則6:小心部分依賴


小心那些部分依賴於主鍵的欄位,例如中的主鍵是Roll Number和Standard。現在來看看“syllabus”,這個欄位與standard欄位相關聯,而不直接與Student(“Roll Number”欄位)相關聯。

“syllabus”欄位與學生正在學習的"standard"欄位相關聯,而沒有直接和學生關聯。那麼明天我想要更新“syllabus”的時候,我就必須把所有與之相關的"Student"欄位也更新掉。老兄,這是個辛苦的體力活,而且還毫無邏輯!所以更有意義的做法是將"syllabus"欄位單獨拉出來然後與"Standard"通過外部索引鍵關聯。

你可以看到我是如何將"syllabus"欄位拉出來然後與“Standards”相聯絡。

這條準則其實就是第二範式本身:所有的屬性必須做到全部依賴,不應該有欄位是部分依賴主鍵的。

準則7:仔細地選擇衍生的資料行

如果你設計的是OLTP型資料庫,即事務型資料庫,避免衍生的資料行將會是很明智的,除非對這一塊內容的效能有高要求。但是對於需要大量求和與計算的OLAP資料庫,即AnalyticDB,這些衍生的資料行就顯得很有必要而且能使資料庫效能更加優越。

中你可以看到,Average依賴Total Marks和Total Subject來計算,這就是資料冗餘的表現之一。所以碰到這種派生於其他列的欄位,要好好想一想,這個欄位真的需要嗎?

這條準則正如第三範式所說:欄位不能依賴於任何非主鍵欄位。我個人認為不要盲目遵循第三範式,要視情況而定。存在冗餘的資料並不總是壞事。如果這些冗餘資料是通過計算得來的,看情況來決定要不要遵守第三範式。

準則8:如果效能才是關鍵,那就不要非常嚴格地避免冗餘資料


不要把"避免一切冗餘資料"當成一條死命令。如果對效能的要求很高,就考慮一下非標準化吧。遵守標準的話,你經常需要使用join命令來串連很多個表格,但在非標準化中,通過設定一些冗餘資訊,就沒那麼多join命令了,所以效能會好得多。

準則9:多維度資料是一種完全不同的野獸

使用OLAP(分析型)資料庫的項目主要處理的是多維資料。舉例來說的話你可以看一下,你想要得到每個國家的銷量,每個顧客的銷量和其他資料。簡單來說,你所關注的銷量是三個維度資料的交集。


這種情況下,設計成一個維度將會更好。簡單來說,你可以建立一個擁有"sales amount"欄位的銷量表(它為中心表),然後設定一些外鍵來和其他的一維表相關聯。


準則10:集中化鍵值表的設計

我經常會碰到鍵值表。鍵值表的意思是,它儲存著鍵和和與這個鍵相對應的資料(譯者註:就像資料結構中的map的用法一樣,是一種結構相當簡單的表)。舉例來說,下表你可以看到有一個Currency 表和Country表,仔細觀察就會發現,實際上這兩張表中只有一個鍵和一個對應值而已。


對於這種類型的資料表,建立一個集中化的表然後設立一個"Type"欄位來區分。這會使你的資料庫工作的更好。

準則11:對於多級資料要引用自身的主鍵,或是設立外鍵

我也會經常會碰到多集資料的情況,考慮一個多級的銷售方案,一個銷售人員旗下可以有很多個銷售人員。在這種情況下,引用自身的主鍵或是設立外鍵都會協助你達到想要的效果。


這篇文章並不是讓你不要遵守標準範式,而是讓你不要盲目遵守,你要首先考慮的是項目的屬性和你要處理什麼類型的資料。


下面是一個用簡單的學校表來手把手解釋三個標準範式的視頻(譯者註:與上文中的“3 normal forms”為同一個視頻,下載過的讀者可不必重複下載)

SQL Server -- Can you explain First,Second and Third normal form in SQL server [part1]

SQL Server -- Can you explain First,Second and Third normal form in SQL server [part2]

SQL Server -- Can you explain First,Second and Third normal form in SQL server [part3]

(全文完)


原文來自:http://www.codeproject.com/Articles/359654/11-important-database-designing-rules-which-I-foll


大夥給我解釋一下資料庫設計的基本原則

資料庫設計的三範式所謂範式,是關係型資料庫關係模式正常化的標準,從正常化的寬鬆到嚴格,分別為不同的範式,通常使用的有第一範式、第二範式、第三範式及BC範式等。範式是建立在函數依賴基礎上的。

函數依賴

定義:設有關係模式R(U),X和Y是屬性集U的子集,函數依賴是形為X→Y的一個命題,對任意R中兩個元組t和s,都有t[X]=s[X]蘊涵t[Y]=s[Y],那麼FD X→Y在關係模式R(U)中成立。X→Y讀作‘X函數決定Y’,或‘Y函數依賴於X’。通俗的講,如果一個表中某一個欄位Y的值是由另外一個欄位或一組欄位X的值來確定的,就稱為Y函數依賴於X。函數依賴應該是通過理解資料項目和企業的規則來決定的,根據表的內容得出的函數依賴可能是不正確的。

第一範式(1NF)

定義:如果關係模式R的每個關係r的屬性都是不可分的資料項目,那麼就稱R是第一範式的模式。
  簡單的說,每一個屬性都是原子項,不可分割。1NF是關係模式應具備的最起碼的條件,如果資料庫設計不能滿足第一範式,就不稱為關係型資料庫。關聯式資料庫設計研究的關係正常化是在1NF之上進行的。

第二範式(2NF)

定義:如果關係模式R是1NF,且每個非主屬性完全函數依賴於候選索引鍵,那麼就稱R是第二範式。
簡單的說,第二範式要滿足以下的條件:首先要滿足第一範式,其次每個非主屬性要完全函數依賴與候選索引鍵,或者是主鍵。也就是說,每個非主屬性是由整個主鍵函數決定的,而不能由主鍵的一部分來決定。舉個例子:
  有股票日行情表的主鍵是股 票代碼和交易日期組成。非主屬性中有收盤價和成交量等,都是由主鍵,即股票代號和交易日期函數決定的,單獨的股票代號或者交易日期都不能函數決定這些非主 屬性。如果這個表中有非主屬性股票簡稱,則股票簡稱是可以由股票代號來函數決定的,這樣股票簡稱這個非主屬性就不是完全函數依賴於候選索引鍵,這樣的設計就不 滿足第二範式。

第三範式(3NF)
定義:如果關係模式R是2NF,且關係模式R(U,F)中的所有非主屬性對任何候選關鍵字都不存在傳遞依賴,則稱關係R是屬於第三範式。
簡單的說,第三範式要滿足以下的條件:首先要滿足第二範式,其次非主屬性之間不存在函數依賴。由於滿足了第二範式,表示每個非主屬性都函數依賴於主鍵。如果非主屬性之間存在了函數依賴,就會存在傳遞依賴,這樣就不滿足第三範式。
舉 個例子:在股票基本情況表中,主鍵是股票代號,有非主屬性所屬一級行業和所屬二級行業。根據商務規則,所屬二級行業能夠函數決定所屬一級行業,這就表示存 在這樣一種關係:股票代號函數決定所屬二級行業,所屬二級行業函數決定所屬一級行業,這就形成了傳遞依賴,這樣的設計就不符合第三範式。不過在實際運用 中,為查詢和使用的方便,有時也會違反第三範式。如上例,如果沒有所屬一級行業的屬性,需要查詢所屬一級行業的相關股票,需要查詢時使用函數來從二級行業 中函數產生所屬一級行業,使用效能上會受影響。所以通常會加上所屬一級行業的屬性。

BC範式(BCNF)

BC範式是第三範式的增強版,不過也有人說是直接從1NF發展過來的,即每個屬性,包括主屬性或非主屬性,都完全依賴於候選索引鍵,並且不存在傳遞依賴情況。
 
設計一個關聯式資料庫遵守什原則

指導方針一:在事務中盡量使得訪問的紀錄最小。
指導方針二:保持事務儘可能的簡潔。
一是在同一個事務中不要加入過多的修改或者刪除語句。
二是在更新時,若一次性更新的語句比較多,最好能夠選擇合適的時候更新
指導方針三:不要在交易處理期間要求使用者輸入
指導方針四:在瀏覽資料時,盡量不要開啟事務。
 

相關文章

A Free Trial That Lets You Build Big!

Start building with 50+ products and up to 12 months usage for Elastic Compute Service

  • Sales Support

    1 on 1 presale consultation

  • After-Sales Support

    24/7 Technical Support 6 Free Tickets per Quarter Faster Response

  • Alibaba Cloud offers highly flexible support services tailored to meet your exact needs.