1. 程式人生 > >Mysql之資料庫設計規範

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 概念結構設計

概念結構設計常用的方法是實體分析法、屬性綜合法。
二元聯絡的型別與定義:二元聯絡指兩個實體之間的聯絡。分為一對一、一對多、多對多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:1:N、1:M:N和R:M:N
同一實體集內的二元聯絡:
同一實體集內的各實體之間也存在1: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授權的使用者在建立新關係後自動獲得該關係上的所有許可權。