Mysql之數據庫設計規範

1. 三大範式
首先要明白」範式（NF）」是什麼意思。按照教材中的定義，範式是「符合某一種級別的關係模式的集合，表示一個關係內部各屬性之間的聯繫的合理化程度」。數據庫範式也分爲1NF，2NF，3NF，BCNF，4NF，5NF。通常在咱們設計關係型數據庫的時候，最多考慮到BCNF就夠。符合高一級範式的設計，一定符合低一級範式，例如符合2NF的關係模式，一定符合1NF。

1.1 第一範式
消除一個字段包含多個數據庫值，消除一個記錄包含重複的組（單獨的一列包含多個項目），便可知足1NF。符合1NF的關係中的每一個屬性都不可再分。以下表所示的狀況，就不符合1NF的要求。

 

實際上，1NF是全部關係型數據庫的最基本要求，你在關係型數據庫管理系統（RDBMS），例如SQL Server，Oracle，MySQL中建立數據表的時候，若是數據表的設計不符合這個最基本的要求，那麼操做必定是不能成功的。也就是說，只要在RDBMS中已經存在的數據表，必定是符合1NF的。
可是僅僅符合1NF的設計，仍然會存在數據冗餘過大，插入異常，刪除異常，修改異常的問題，例如對於表中的設計：

 

（1）每一名學生的學號、姓名、系名、系主任這些數據重複屢次。每一個系與對應的系主任的數據也重複屢次——數據冗餘過大 假如學校新建了一個系，可是暫時尚未招收任何學生（好比3月份就新建了，但要等到8月份才招生），那麼是沒法將系名與系主任的數據單獨地添加到數據表中去的——插入異常。
（2）假如將某個系中全部學生相關的記錄都刪除，那麼全部系與系主任的數據也就隨之消失了（一個系全部學生都沒有了，並不表示這個系就沒有了）。——刪除異常
（3）假如李小明轉系到法律系，那麼爲了保證數據庫中數據的一致性，須要修改三條記錄中系與系主任的數據。——修改異常。
（4）正由於僅符合1NF的數據庫設計存在着這樣那樣的問題，咱們須要提升設計標準，去掉致使上述四種問題的因素，使其符合更高一級的範式（2NF），這就是所謂的「規範化」。

1.2 第二範式
消除部分依賴性便可轉化爲2NF。部分依賴性表示一個記錄中包括的字段只依賴於主鍵的一部分。解決部分依賴性的最簡單方法是將複合主鍵分紅兩部分，每一部分表示一個單獨的表。其改進是，2NF在1NF的基礎之上，消除了非主屬性對於碼的部分函數依賴。接下來對這句話中涉及到的四個概念——「函數依賴」、「碼」、「非主屬性」、與「部分函數依賴」進行一下解釋。

1.2.1 函數依賴
咱們能夠這麼理解（但並非特別嚴格的定義）：若在一張表中，在屬性（或屬性組）X的值肯定的狀況下，一定能肯定屬性Y的值，那麼就能夠說Y函數依賴於X，寫做 X → Y。也就是說，在數據表中，不存在任意兩條記錄，它們在X屬性（或屬性組）上的值相同，而在Y屬性上的值不一樣。這也就是「函數依賴」名字的由來，相似於函數關係 y = f(x)，在x的值肯定的狀況下，y的值必定是肯定的。
例如，對於上例表中的數據，找不到任何一條記錄，它們的學號相同而對應的姓名不一樣。因此咱們能夠說姓名函數依賴於學號，寫做 學號 → 姓名。可是反過來，由於可能出現同名的學生，因此有可能不一樣的兩條學生記錄，它們在姓名上的值相同，但對應的學號不一樣，因此咱們不能說學號函數依賴於姓名。表中其餘的函數依賴關係還有如：系名 → 系主任 學號 → 系主任 （學號，課名） → 分數 但如下函數依賴關係則不成立：學號 → 課名 學號 → 分數 課名 → 系主任 （學號，課名） → 姓名。

1.2.2 碼
設 K 爲某表中的一個屬性或屬性組，若除 K 以外的全部屬性都徹底函數依賴於 K（這個「徹底」不要漏了），那麼咱們稱 K 爲候選碼，簡稱爲碼。在實際中咱們一般能夠理解爲：假如當 K 肯定的狀況下，該表除 K 以外的全部屬性的值也就隨之肯定，那麼 K 就是碼。一張表中能夠有超過一個碼。（實際應用中爲了方便，一般選擇其中的一個碼做爲主碼）

1.2.3 非主屬性
包含在任何一個碼中的屬性成爲主屬性。

1.3 第三範式
消除可傳遞依賴性便可知足3NF。可傳遞依賴性表示記錄中至少一個值不依賴主鍵，而是依賴於這個記錄中的另外一個字段。
符合3NF要求的數據庫設計，基本上解決了數據冗餘過大，插入異常，修改異常，刪除異常的問題。固然，在實際中，每每爲了性能上或者應對擴展的須要，常常 作到2NF或者1NF，可是做爲數據庫設計人員，至少應該知道，3NF的要求是怎樣的。

1.4 BCNF範式
要了解 BCNF 範式，那麼先看這樣一個問題：

以下：
某公司有若干個倉庫；
每一個倉庫只能有一名管理員，一名管理員只能在一個倉庫中工做；
一個倉庫中能夠存放多種物品，一種物品也能夠存放在不一樣的倉庫中。每種物品在每一個倉庫中都有對應的數量。

那麼關係模式 倉庫（倉庫名，管理員，物品名，數量） 屬於哪一級範式？答：已知函數依賴集：倉庫名 → 管理員，管理員 → 倉庫名，（倉庫名，物品名）→ 數量碼：（管理員，物品名），（倉庫名，物品名）主屬性：倉庫名、管理員、物品名， 非主屬性：數量，不存在非主屬性對碼的部分函數依賴和傳遞函數依賴。此關係模式屬於3NF。基於此關係模式的關係（具體的數據）可能如圖所示：

 

好，既然此關係模式已經屬於了 3NF，那麼這個關係模式是否存在問題呢？咱們來看如下幾種操做：先新增長一個倉庫，但還沒有存聽任何物品，是否能夠爲該倉庫指派管理員？——不能夠，由於物品名也是主屬性，根據實體完整性的要求，主屬性不能爲空。某倉庫被清空後，須要刪除全部與這個倉庫相關的物品存放記錄，會帶來什麼問題？——倉庫自己與管理員的信息也被隨之刪除了。若是某倉庫更換了管理員，會帶來什麼問題？——這個倉庫有幾條物品存放記錄，就要修改多少次管理員信息。
從這裏咱們能夠得出結論，在某些特殊狀況下，即便關係模式符合 3NF 的要求，仍然存在着插入異常，修改異常與刪除異常的問題，仍然不是 」好「 的設計。形成此問題的緣由：存在着主屬性對於碼的部分函數依賴與傳遞函數依賴。（在此例中就是存在主屬性【倉庫名】對於碼【（管理員，物品名）】的部分函數依賴。解決辦法就是要在 3NF 的基礎上消除主屬性對於碼的部分與傳遞函數依賴。倉庫（倉庫名，管理員）庫存（倉庫名，物品名，數量）這樣，以前的插入異常，修改異常與刪除異常的問題就被解決了。以上就是關於 BCNF 的解釋。
BCNF（Boyce-Codd Normal Form）能夠看做更好的3NF。在知足第二第三範式的狀況下，決定項內部也不能部分或傳遞依賴。簡單點看就是：箭頭左邊的必須是碼，不是碼的就不是BCNF。

2. 數據庫設計相關
2.1 數據規範化
關係模式知足的約束條件稱爲範式。範式由低到高分爲：1NF、2NF、3NF、BCNF、4NF、5NF。
規範化：就是指把一個低一級的關係模式分解爲高一級關係模式的過程。
規範化的基本思想：逐步消除不合適的函數依賴，使數據庫中的各個關係模式達到某種程度的分離。
函數依賴：通俗的說，就像自變量x肯定以後，相應的函數值f(x)也就惟一的肯定了同樣。
碼：給定一個碼能徹底決定一個元組。一個關係可能有多個碼，選其中一個作爲主碼。包含在任一碼中的屬性稱爲主屬性。不包含在任何碼中的屬性稱爲非主屬性。
第一範式（1NF）：若是關係中全部屬性的值域都是簡單域，其元素（屬性）不可再分，是屬性項不是屬性組，那麼關係模式屬於第一範式。這一限制是關係的基本性質，因此任何關係都必須知足第一範式。
第二範式（2NF）：若是一個範式屬於1NF，且全部的非主屬性都徹底的依賴主屬性，稱爲第二範式。能夠用分解的方法消除部分依賴的狀況，而使關係達到2NF的標準。方法是從現有關係中分解出新的關係表，使每一個表中全部的非關鍵字都徹底依賴於各自的主關鍵字。
(消除部分依賴)
第三範式（3NF）：若是一個關係屬於2NF，且每一個非主屬性不傳遞依賴於主屬性，這種關係是3NF。從2NF中消除傳遞依賴，就是3NF。
(消除部分傳遞依賴)
BC範式（BCNF）：不管2NF仍是3NF都沒有涉及主屬性間的函數依賴，因此有時仍會引發一些問題。
定義：若是關係模式屬於1NF，且每個函數依賴關係中的決定因素都包含碼，則關係知足BC範式。主屬性對不含他的碼徹底函數依賴，沒有屬性徹底函數依賴於一組非主屬性。
多值依賴和4NF：第四範式是BC範式的推廣。
定義：關係模式R

2.2 數據庫設計
2.2.1 經常使用方法：
(1)基於3NF的數據庫設計方法：
在需求分析的基礎上，識別並確認數據庫模式中的所有屬性和屬性間的依賴，將他們組織成一個單一的關係模式，而後再分析模式中不符合3NF的約束條件，用投影和鏈接的辦法將其分解，使其達到3NF。
(2)LRA方法：邏輯記錄存取法。
(3)基於實體聯繫（E-R）的數據庫設計方法。
(4)基於視圖概念的數據庫設計方法。
(5)面向對象的關係數據庫設計方法。
一般將數據庫設計分爲需求分析、概念結構設計、邏輯結構設計和數據庫物理設計4個階段。

2.2.2 概念結構設計
概念結構設計經常使用的方法是實體分析法、屬性綜合法。
二元聯繫的類型與定義：二元聯繫指兩個實體之間的聯繫。分爲一對1、一對多、多對多3種。
（1）一對一聯繫：對於實體集A中的每個實體，實體集B中至多有一個實體與之聯繫。
（2）一對多聯繫：對於實體集A中的每個實體，實體集B有n個實體（n>=0）與之聯繫，反之對於實體集B中的每個實體，實體集A至多隻有一個實體與之聯繫。則實體集A與實體集B有一對多關係，記爲1:n。
（3）多對多聯繫：若對於實體集A中的每個實體，實體集B有n個實體（n>=0）與之聯繫。反過來，對於實體集B中的每個實體，實體集A有m個實體（m>=0）與之聯繫。則實體集A與實體集B具備多對多聯繫，記爲m:n。
消除冗餘聯繫：若出現兩個或兩個以上的聯繫表示的是同一律念，則存在着冗餘的聯繫，具備冗餘聯繫的E-R模型轉換爲關係模型可能會獲得非規範化的關係，所以必須予以消除。
警戒鏈接陷阱：
鏈接陷阱是一種存在語義缺陷的聯繫結構，分爲扇形陷阱、斷層陷阱、深層扇形陷阱3種信息。
扇形陷阱：指由一個實體引出的兩種不一樣類型的扇形聯繫，造成雙扇形結構。

2.2.3.數據庫物理設計
利用已肯定的邏輯結構及DBMS提供的方法、技術。已較優的存儲結構、數據存儲路徑、合理的數據存儲位置及存儲分配，設計一個高效可實現的物理數據庫結構。

3. 模式
數據庫三級模式結構：這是數據庫管理系統內部的系統結構。

3.1 概念模式
只涉及行的描述，不涉及具體的值。概念模式的一個具體值稱爲模式的一個實例，同一模式能夠有不少實例。概念模式反映的是數據庫的結構及其聯繫，因此是相對穩定的。而實例反映的是數據庫某一時刻的狀態，因此是相對變更的。
概念模式不只要描述記錄類型，還要描述記錄間的聯繫、操做、數據的完整性、安全性。但概念模式不涉及存儲結構、訪問技術等細節。

3.2 外模式
也稱用戶模式或子模式。是用戶與數據庫系統的接口，是用戶用到的那部分記錄的描述。由若干外部記錄組成，用戶使用DML（數據操做語言）操做外模式的外部記錄。

3.3 內模式
也稱存儲模式，是數據庫物理結構和存儲方式的描述，是數據在數據庫內部的表示方式。定義全部內部記錄的類型、索引、文件的組織方式。記錄的存儲方式是順序存儲、B樹存儲、Hash方法存儲等。
兩級映像：模式/內模式映像、外模式/模式映像。
實體與記錄：實體表示客觀存在，能區別的事物。記錄是字段的有序集合，通常一條記錄描述一個實體。
屬性與字段：屬性描述實體某方面的特性，字段標記實體屬性的命名單位。
碼與記錄碼：碼是惟一能區分實體的屬性或屬性集，記錄碼是惟一標識文件中的每條記錄的字段或字段集。
實體集與文件：實體集是具備共同特性的實體的集合。文件是同一類記錄的聚集。
實體型與記錄型：實體型是屬性的集合，記錄型是記錄的結構定義。

3.4 數據模型三要素
數據庫結構的基礎是數據模型，是用來描述數據的一組概念和定義。
數據模型三要素是數據結構、數據操做、數據的約束條件。
E-R模型：是實體-聯繫模型的簡稱。所採用的3個主要概念是實體、聯繫、屬性。
實體：現實世界中能夠區別其它對象的物體或事件。
聯繫：實體的聯繫分爲實體內部的聯繫和實體與實體之間的聯繫。
兩個不一樣實體之間的聯繫：
（1）一對一：指實體集E1中的一個實體最多隻與實體集E2中的一個實體相聯繫。（1:1）
（2）一對多：表示實體集E1中的一個實體可與實體集E2中的多個實體相聯繫。（1:N）
（3）多對多：表示實體集中E1中的多個實體可與實體集E2中的多個實體相聯繫。（M:N）
兩個以上不一樣實體集的聯繫：
兩個以上不一樣實體集之間存在1：1：一、1：1：N、1：M：N和R：M：N
同一實體集內的二元聯繫：
同一實體集內的各實體之間也存在1：一、1：N和M：N的聯繫。
屬性是實體某方面的特性。
派生屬性能夠從其它屬性得來，例如：參加工做時間和工做年限，工做年限能夠從當前時間和參加工做時間獲得，這裏工做年限就是一個派生屬性。
概念模型中最經常使用的方法是實體-聯繫法，簡稱E-R方法。
擴充的E-R模型：
弱實體：這種實體對另外一些實體有着很強的依賴關係，即一個實體的存在必須以另外一個實體爲前提。例如職工與家眷的關係。
特殊化：一個實體集能夠按照某種特徵區分爲幾個子實體。例如：學生實體集能夠分爲研究生、本科生、大專生。咱們稱這種過程爲特殊化，反之叫廣泛化。
層次模型：採用樹形結構表示數據與數據之間的聯繫。
網狀模型：採用網狀結構表示數據與數據之間的聯繫。
關係模型：在關係模型中以表格結構表達實體集，以及實體集之間的聯繫。
關係代數：
笛卡爾積：D1={0，1}、D2={a，b}。D1*D2={0,a}{0,b}{1,a}{1,b}。
關係的3種類型：
基本關係：實際存在的表，是實際存儲數據的邏輯表示。
查詢表：查詢結果對應的表。
視圖表：由基本表或其它視圖表導出的表，因爲它自己不獨立存儲在數據庫中。數據庫只存放它的定義，因此常稱爲虛表。
完整性約束：
完整性規則提供了一種手段來保證受權用戶對數據庫操做修改時不會破壞數據的一致性。
關係的完整性分爲3類：
（1）實體完整性：規定基本關係R的主屬性A不能取空值。
（2）參照完整性：在關係模型中實體與實體間的聯繫是用關係來描述的。這樣天然就存在着關係與關係間的引用。
（3）用戶定義完整性：反映某一具體應用所涉及的數據必須知足的語義要求，由應用環境決定。
5種基本的關係代數運算：並、差、廣義笛卡爾積、投影、選擇。
擴展關係運算：交、鏈接、除、廣義投影、外鏈接。
SQL支持三級模式結構：視圖對應外模式，基本表對應模式，存儲文件對應內模式。

3.4 索引
數據庫中索引與書籍中索引相似，利用索引能夠快速查找整本書信息，無需閱讀整本書。
數據庫索引可使數據庫程序無需對整個表進行掃描，就能夠在其中找到所需數據。
索引分爲：
彙集索引和非彙集索引。
彙集索引是指索引表中索引項的順序與表中記錄的物理順序一致的索引。
視圖建立遵循以下規定：
（1）子查詢不容許有order by和distinct語句。
（2）with check option表示對update、insert、delete操做時保證更新、插入或刪除的行知足視圖定義的謂詞條件（即知足子查詢中的where後的條件表達式）。
（3）組成視圖的屬性列名或者所有省略或者所有指定。若是省略屬性列名，則隱含視圖由SELECT子查詢目標列的主屬性組成。
SQL的訪問控制：數據庫控制是控制用戶的存儲權限,由DBA來決定。
經過GRANT和REVORK將受權通知系統，並存入數據字典。

4. 規範化
規範化：將關係模式從低一級範式轉化成高一級範式的過程。
5NF包含於4NF包含於BCNF包含於3NF包含於2NF包含於1NF。
1NF定義：關係模式R中的每一個份量是不可再分的數據項，則關係模式R屬於第一範式。1NF冗餘度大、引發修改的不一致性、插入及刪除異常。
2NF定義：若關係模式屬於1NF，且每一個非主屬性徹底依賴於碼，則關係模式屬於2NF。即1NF消除了非主屬性對碼的部分函數依賴。
3NF定義：2NF消除了非主屬性對碼的傳遞函數依賴，則稱3NF。3NF的模式必是2NF的模式。產生冗餘和異常的兩個重要緣由是部分函數依賴和傳遞依賴。
BCNF（巴科斯範式）：即3NF消除了主屬性對碼的部分和傳遞依賴，稱爲BCNF。
4NF：4NF是限制關係模式的屬性間不容許有非平凡且非函數依賴的多值依賴。
若是隻考慮函數依賴，BCNF是關係模式最高的規範化程度。若是考慮多值依賴，4NF是關係模式最高的規範化程度。

5. 事務管理
事務有4個特性ACID。
原子性（A）：要麼全作，要麼全不作。
一致性（C）：一個事務獨立執行的結果，將保持數據的一致性，即數據不會由於數據的執行而遭受破壞。
隔離性（I）：一個事務的執行不能被其它事物干擾。
持久性（D）：一個事物一旦提交，對數據庫的改變必須是永久的。
SQL中事物定義語句有3條：
BEGIN TRANSACTION：事務開始。
COMMIT：事務提交。
ROLLBACK：事務回滾。

6. 併發控制
併發控制主要技術是封鎖，主要包含：排他鎖（簡稱X鎖或寫鎖）、共享鎖（簡稱S鎖或讀鎖）。
排他鎖：若事務T對數據對象A加上X鎖，則只容許T讀取和修改A。其它事務不能對A加任何鎖，直到T釋放鎖。
共享鎖：若事務T對數據對象A加上S鎖，則只容許T讀取A，但不能修改A。其它事務只能再對A加S鎖。保證其它事務能夠讀取A，但在T釋放A上的S鎖前不能修改A。
三級封鎖協議：
一級封鎖協議：事務在修改數據前必須先對其加X鎖，直到事務結束才釋放（結束包括commit或rollback）。一級封鎖協議解決丟失更新的問題。
二級封鎖協議：在一級協議的基礎上，加上事務在讀數據以前必須加S鎖，讀完後便可釋放S鎖。二級封鎖協議解決讀髒數據的問題。由於讀完後即釋放，因此不能保證可重複讀。
三級封鎖協議：在一級協議的基礎上，加上事務在讀數據以前必須加S鎖，直到事務結束時釋放S鎖。除了防止丟失更新、讀髒數據的問題，還進一步防止不可重複讀。
活鎖和死鎖：
活鎖：當事務T1封鎖數據R，事務T2請求數據R因而T2等待。T1釋放了R上的封鎖，系統首先批准了T3的請求，T2繼續等待，以後系統批准了T4的請求……依此類推，T2可能永久等待。這種現象稱爲活鎖。
死鎖：是指兩個以上事務分別請求封鎖對方已經封鎖的數據，致使長期等待而沒法繼續進行下去的現象叫死鎖。
併發調用可串行性：
多個事務併發執行，當且僅當其結果與某一次序串行地執行它們時的結果相同，咱們稱這種調度是可串行化調度。
給定一個併發調度，當且僅當它是可串行化的才認爲是正確調度。
兩段封鎖協議：指全部事務必須分爲兩個階段對數據項加鎖和解鎖。
第一階段是得到封鎖：事務能夠得到任何數據項上的任何類型的鎖，但不能釋放。
第二階段是釋放封鎖：事務能夠釋聽任何數據項上的任何類型的鎖，但不能申請。
事務是不能嵌套的，由於這違背了事務的原子性。事務是不能嵌套是指當且僅當當前沒有事務在運行時，程序才能執行BEGIN TRANSACTION操做。
經過Resource受權來控制建立新關係的能力，具備Resource受權的用戶在建立新關係後自動得到該關係上的全部權限。

做者：小潭漁
原文：https://blog.csdn.net/uftjtt/article/details/80475432

僅做學習和交流