關係型資料庫設計要領，網友：我不會……
「來源： ｜全棧開發者社群 ID：quanzhankaifazhe」
點選上方
[
全棧開發者社群
]
→
右上角
[...]
→
[設為
星標
]
點選領取全棧資料：全棧資料
摘要
本文討論關係資料庫設計相關的一些內容，涉及關係模型，表結構設計等內容，以學生選修課程講述設計過程，在儘量講清楚設計要領的前提下，簡化設計內容。
本文基於MySQL資料庫為基礎，適合有一定關係型資料庫基礎的人閱讀。
實體-關係模型（E-R）
首先搞清楚什麼是E-R資料模型？它有什麼用？
E-R模型在將現實世界中事實的含義和相互關聯對映到概念模式方面非常有用，因此，許多資料庫設計工具都利用了E-R模型的概念。E-R模型所採用的三個主要概念是：實體集、關係集和屬性。
實體：實體是世界中可以區別於其他物件的“事件”或者“物體”，例如，學校裡的每個學生、學生選修的每門課程等都是一個實體。
屬性：屬性是實體集中每個成員具有的描述性性質。例如，學生的姓名，學號等。
實體集：實體集就是就有相同型別及屬性的實體集合，比如，學校裡的所有學生，學生選修的所有課程等。
關係：關係是多個實體間的相互關聯。例如，小明選修語文課程。
關係集：關係集是同類關係的集合。例如，所用學生選修課程的集合。
既然知道了E-R資料模型的作用，下面就讓我們來畫出學生選修課程的E-R圖吧。
其中，（學號，姓名，年齡，性別）為學生的屬性，（成績）為選修關係的屬性，（課程號，課程名，學分）為課程的屬性。學生和課程之間的關係是多對多，即一個學生可以選擇多門課程，一門課程可以被多個學生選修。
關係表設計
從上面的E-R圖，我們一眼就能看出他們之間的聯絡，那該如何設計關係模式呢？
我們要知道，關係資料庫設計的目的是為了生成一組關係模式，使我們能夠既不必儲存不必要的冗餘資訊，又能方便地獲取資訊。為了是我們方便的達到這個目的，正規化設計應運而生。
Boyce-Codd正規化
我們所知道的令人滿意的正規化之一是Boyce-Codd正規化（BCNF）。如果對F+中所有形如 α→β 的函式依賴，其中 αR 且 βR，下面的定義至少有一個成立：
α→β 是平凡函式依賴（即 β α）。（一般來說，平凡函式依賴並沒有討論意義，討論的都是非平凡函式依賴，即 β α 的情況）
α 是模式R的超碼。
考慮如下關係模式及其相應的函式依賴：
學生 = （學號，姓名，年齡，性別）
學號 → 姓名 年齡 性別
課程 = （課程號，課程名，學分）
課程號 → 課程名 學分
選修 = （學號，課程號，成績）
學號 課程號 → 成績
以上模式均屬於BCNF。就拿第一組關係模式來說，學生上僅有的非平凡函式依賴，箭頭左側是學號，學號是該模式的一個候選碼（候選碼屬於超碼的子集），沒有破壞BCNF的定義。
其實並不是每個BCNF都能保持函式依賴的，例如：
Banker-schema = （branch-name，customer-name，banker-name）
它表示的是一個客戶在某一分支機構有一個銀行賬戶負責人。它要求滿足的函式依賴集F為
banker-name → branch-name
branch-name customer-name → banker-name
顯然，Banker-schema不屬於BCNF，因為 banker-name 不是超碼。
我們可以將它分解得到如下的BCNF：
Banker-branch-schema = （banker-name，branch-name）
Customer-banker-schema = （customer-name，banker-name）
分解後的模式只保持了banker-name → branch-name，而branch-name customer-name → banker-name的依賴沒有保持。
第三正規化
當我們不能同時滿足以下三個設計目標：
BCNF。
無損連線。
保持函式依賴。
我們可以放棄BCNF而接受相對較弱的第三正規化（3NF）。因為3NF總能找到無損連線並保持依賴的分解。
具有函式依賴即F的關係模式R屬於3NF，只要F+中所有形如 α→β 的函式依賴，其中 αR 且 βR，下面的定義至少有一個成立：
α→β 是平凡函式依賴（即 β α）。
α 是模式R的超碼。
β - α 中的每個屬性 A 都包含在R的候選碼中。
回到Banker-schema的例子中，我們已經看到了沒能將該關係模式轉化成BCNF而又保持依賴和無損連線的分解，但改模式屬於3NF。在Banker-schema中，候選碼是{branch-name，customer-name}，所以Banker-schema上不包含候選碼的就只有banker-name。
而形如 α → banker-name 的非平凡函式依賴都是以{branch-name，customer-name}作為 α 的一部分。由於{branch-name，customer-name}是候選碼，所以符合3NF的定義。
每個BCNF都屬於3NF，因為BCNF的約束比3NF更嚴格。
儲存引擎的選擇
關係模式一但確定，基本的資料庫表結構就確定了，接下來就是表結構的詳細設計了，這裡先從儲存引擎開始，MySQL提供的各種儲存引擎都是根據不同的用例設計的。
下表概述了MySQL提供的一些儲存引擎。
最常用的兩種儲存引擎：MyISAM和InnoDB。
MyISAM：MySQL 5。5。5以前，MyISAM作為MySQL的預設儲存引擎。
InnoDB：MySQL 5。5。5以後，InnoDB作為MySQL的預設儲存引擎。
如何選擇？
選擇標準： 根據應用特點選擇合適的儲存引擎，對於複雜的應用系統可以根據實際情況選擇多種儲存引擎進行組合。但是要知道組合使用的缺點：
InnoDB和非InnoDB儲存引擎的組合對比，僅使用InnoDB儲存引擎可以簡化備份和恢復操作。MySQL Enterprise Backup對使用InnoDB儲存引擎的所有表進行熱備份。對於使用MyISAM或其他非InnoDB儲存引擎的表，它會執行“熱”備份，資料庫會繼續執行，但這些表在備份時不能修改。
下面是常用儲存引擎的適用環境：
InnoDB：事務型業務場景首選。
MyISAM：非事務型的大多數業務場景。
Memory：資料儲存到記憶體中，能提供極速的訪問速度。（個人覺得可以使用Redis等NoSQL資料庫代替）
字符集選擇
儲存引擎之後就是確定字符集，字符集的選擇十分重要，不管是MySQL還是Oracle，如果在資料庫建立階段沒有正確選擇字符集，那麼在後期需要更換字符集的時候將要付出高昂的代價。
如何選擇？
建議在能夠完全滿足應用當下和未來幾年發展的前提下，儘量使用小的字符集。應為更小的字符集意味著能夠節省空間、減少網路傳輸位元組數，同時由於儲存空間小間接的提升了系統的效能。
不同的資料庫有不同的字符集應用級別，分別為伺服器級別、庫級別、表級別、欄位級別，通常推薦使用庫級別或者表級別。因為庫級別或者表級別在保有靈活性的同時，兼顧資料間字符集的統一，這可以給開發省去很多處理字符集的麻煩。
資料型別的選擇
選擇原則
前提：使用合適的儲存引擎。
選擇原則：為了獲得最佳的儲存，您應該在所有情況下嘗試使用最精確的型別。
固定長度和可變長度
char 與 varchar
下面這個例子說明二者的區別：
請注意上表中最後一行的值只適用不使用嚴格模式時；如果 MySQL 執行在嚴格模式，超過列 長度的值不儲存，並且會出現錯誤。
從 CHAR（4）和 VARCHAR（4）列檢索的值並不總是相同，因為檢索時從 CHAR 列刪除了尾部的空 格。透過下面的例子說明該差別：
mysql> CREATETABLE vc （v VARCHAR（4）， c CHAR（4））；
Query OK， 0 rows affected （0。01 sec）
mysql> INSERTINTO vc VALUES （‘ab ’， ‘ab ’）；
Query OK， 1 row affected （0。00 sec）
mysql> SELECTCONCAT（‘（’， v， ‘）’）， CONCAT（‘（’， c， ‘）’） FROM vc；
+——————————-+——————————-+
| CONCAT（‘（’， v， ‘）’） | CONCAT（‘（’， c， ‘）’） |
+——————————-+——————————-+
| （ab ） | （ab） |
+——————————-+——————————-+
1 row in set （0。06 sec）
對於InnoDB資料表，內部的行格式沒有區分固定長度和可變長度列，所有資料化行都使用指向資料列值的頭指標，因此在本質上，使用固定長度的CHAR列不一定比使用可變長度的VARCHAR列要好。
因為，主要的效能因數是資料行使用的儲存總量。對於佔用空間來說，CHAR總是大於等於VARCHAR，所以，使用VARCHAR來最小化行資料的儲存總量，進而減少磁碟I/O頻率。
text 和 blob
在使用text或者blob型別的欄位是需要注意一下幾點，以便獲得更好的效能：
執行大量的刪除和更新操作後，會留下很”空洞“，需要定期optimize table進行碎片整理；
避免查詢大型的text和blob。查詢大型的text和blob會使一頁能裝下的資料量減少，增加磁碟I/O壓力。
把text和blob分離到單獨的表中。這會把原來表中的資料列轉變為更短的固定長度的資料行格式，這個十分有用。
浮點數和定點數
在MySQL中float、double是浮點數，decimal是定點數。
浮點數優勢：在長度一定的情況下，浮點數能表示更大的資料範圍。
浮點數缺點：精度問題。
友情提醒：在有關金錢交易方面浮點數慎用！！！
整數
MySQL支援SQL標準整數型別INTEGER（或INT）和SMALLINT。作為標準的擴充套件，MySQL還支援整數型別TINYINT、MEDIUMINT和BIGINT。下表顯示了每個整數型別所需的儲存空間和範圍。
索引設計
設計原則
搜尋的索引列，不一定是所要選擇的列。最適合索引的列是出現在 WHERE 子 句中的列，或連線子句中指定的列，而不是出現在 SELECT 關鍵字後的選擇列表中的列。
使用惟一索引。對於惟一值的列，索引的效果最好，而具有多個 重複值的列，其索引效果最差。
使用短索引。如果對字串列進行索引，應該指定一個字首長度 。例如，如果有一個 CHAR（200） 列，如果在前 10 個或 20 個字元內，多數值是惟一的， 那麼就不要對整個列進行索引。
利用最左字首。每個額外的索 引都要佔用額外的磁碟空間，並降低寫操作的效能。
不要過度索引。
考慮在列上進行的比較型別。如果是在列上做函式運算，對其進行索引將毫無意義。
示例
針對上面提到的學生選課E-R圖，給出設計結果和說明：
表1-1 學生資訊表（Student）
表1-2 課程資訊表（Course）
表1-3 選課成績表（SC）
Student中姓名的長度是40，這裡把外國人也考慮進來了；
Student中性別定義成列舉，主要是列舉意義簡明；
Student中沒有存年齡，而儲存的出生日期，是因為年齡並不是一成不變的，並且能夠通過出生日期正確計算。
SC中成績使用的是double而不採用decimal，主要是因為成績並不需要那麼高的精確度。
SC中（sno，cno）作為聯合主鍵而不是獨立主鍵，由於現階段markdown無法合拼行，所以無法編輯。
參考
（美）Abraham Silberschatz等。資料庫系統概念。北京：機械工業出版社，2012
MySQL 5。7 Reference Manual
［eimhe。com］網易技術部的MySQL中文資料。
覺得本文對你有幫助？請分享給更多人
