mysql數據庫設計基本規範

一:表中應該避免可爲空的列;

二:表不應該有重複的值或者列;

三: 表中記錄應該有一個唯一的標識符
  在數據庫表設計的時候,數據庫管理員應該養成一個好習慣,用一個ID號來唯一的標識行記錄,而不要通過名字、編號等字段來對紀錄進行區分。每個表都應該有一個ID列,任何兩個記錄都不可以共享同一個ID值。另外,這個ID值最好有數據庫來進行自動管理,而不要把這個任務給前臺應用程序。否則的話,很容易產生ID值不統一的情況。
  另外,在數據庫設計的時候,最好還能夠加入行號。如在銷售訂單管理中,ID號是用戶不能夠維護的。但是,行號用戶就可以維護。如在銷售訂單的行中,用戶可以通過調整行號的大小來對訂單行進行排序。通常情況下,ID列是以1爲單位遞進的。但是,行號就要以10爲單位累進。如此,正常情況下,行號就以10、20、30依次擴展下去。若此時用戶需要把行號爲30的紀錄調到第一行顯示。此時,用戶在不能夠更改ID列的情況下,可以更改行號來實現。如可以把行號改爲1,在排序時就可以按行號來進行排序。如此的話,原來行號爲30的紀錄現在行號變爲了1,就可以在第一行中顯示。這是在實際應用程序設計中對ID列的一個有效補充。這個內容在教科書上是沒有的。需要在實際應用程序設計中,纔會掌握到這個技巧。

四:數據庫對象要有統一的前綴名
  一個比較複雜的應用系統,其對應的數據庫表往往以千計。若讓數據庫管理員看到對象名就瞭解這個數據庫對象所起的作用,恐怕會比較困難。而且在數據庫對象引用的時候,數據庫管理員也會爲不能迅速找到所需要的數據庫對象而頭疼。
  爲此,筆者建立,在開發數據庫之前,最好能夠花一定的時間,去制定一個數據庫對象的前綴命名規範。如筆者在數據庫設計時,喜歡跟前臺應用程序協商,確定合理的命名規範。筆者最常用的是根據前臺應用程序的模塊來定義後臺數據庫對象前綴名。如跟物料管理模塊相關的表可以用M爲前綴;而以訂單管理相關的,則可以利用C作爲前綴。具體採用什麼前綴可以以用戶的愛好而定義。但是,需要注意的是,這個命名規範應該在數據庫管理員與前臺應用程序開發者之間達成共識,並且嚴格按照這個命名規範來定義對象名。
  其次,表、視圖、函數等最好也有統一的前綴。如視圖可以用V爲前綴,而函數則可以利用F爲前綴。如此數據庫管理員無論是在日常管理還是對象引用的時候,都能夠在最短的時間內找到自己所需要的對象。

五:儘量只存儲單一實體類型的數據
  這裏將的實體類型跟數據類型不是一回事,要注意區分。這裏講的實體類型是指所需要描述對象的本身。筆者舉一個例子,估計大家就可以明白其中的內容了。如現在有一個圖書館裏系統,有圖書基本信息、作者信息兩個實體對象。若用戶要把這兩個實體對象信息放在同一張表中也是可以的。如可以把表設計成圖書名字、圖書作者等等。可是如此設計的話,會給後續的維護帶來不少的麻煩。
  如當後續有圖書出版時,則需要爲每次出版的圖書增加作者信息,這無疑會增加額外的存儲空間,也會增加記錄的長度。而且若作者的情況有所改變,如住址改變了以後,則還需要去更改每本書的記錄。若這個作者的圖書從數據庫中全部刪除之後,這個作者的信息也就蕩然無存了。很明顯,這不符合數據庫設計規範化的需求。
  遇到這種情況時,筆者建議可以把上面這張表分解成三種獨立的表,分別爲圖書基本信息表、作者基本信息表、圖書與作者對應表等等。如此設計以後,以上遇到的所有問題就都引刃而解了。

一、三大範式

1、第一範式:消除一個字段包含多個數據庫值,消除一個記錄包含重複的組(單獨的一列包含多個項目),即可滿足1NF。

2、第二範式:消除部分依賴性即可轉化爲2NF。部分依賴性表示一個記錄中包括的字段只依賴於主鍵的一部分。解決部分依賴性的最簡單方法是將複合主鍵分成兩部分,每一部分表示一個單獨的表。

3、第三範式:消除可傳遞依賴性即可滿足3NF。可傳遞依賴性表示記錄中至少一個值不依賴主鍵,而是依賴於這個記錄中的另一個字段。

4、數據庫規範化:

1NF:刪除重複的組,並確定一個主鍵或複合主鍵。

2NF:確定表處於1NF狀態,消除任何部分依賴性。

3NF:確定表處於2NF狀態,消除任何可傳遞依賴性。

5、連接數據庫中的表:大多數情況下,兩個表之間的連接是通過一個公共字段建立的。公共字段是兩個表中都存在的一個字段。許多情況下,公共字段是其中一個表的主鍵。外鍵一般出現在“多”端。

6、關係數據庫中不能存在多對多關係。用來消除多對多關係的最常用方法是通過添加橋接表來創建兩個一對多關係。

二、數據庫設計相關
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<U,F>屬於1NF,若對任意多值依賴X??Y。X必包含R的主鍵,則稱R是第四範式。
多值依賴:對列A中的一個值,不論列C取什麼值,總有一組確定的列B的值。所以有A??B。如果A包含關係R的主鍵,則關係R滿足4NF。可以採用分解法消除不滿足4NF的多值依賴。
規範化設計帶來的性能問題在實際應用中可能令人無法想象。如果出現這種情況,就要進行非規範化處理。由於非規範化必然導致冗餘,佔用更多的存儲空間,因此需要對性能和空間的考慮進行平衡。常用方法有冗餘屬性,合併表等等。

?

2.數據庫設計

常用方法:

(1)基於3NF的數據庫設計方法:

在需求分析的基礎上,識別並確認數據庫模式中的全部屬性和屬性間的依賴,將他們組織成一個單一的關係模式,然後再分析模式中不符合3NF的約束條件,用投影和連接的辦法將其分解,使其達到3NF。

(2)LRA方法:邏輯記錄存取法。

(3)基於實體聯繫(E-R)的數據庫設計方法。

(4)基於視圖概念的數據庫設計方法。

(5)面向對象的關係數據庫設計方法。

通常將數據庫設計分爲需求分析、概念結構設計、邏輯結構設計和數據庫物理設計4個階段。

?

概念結構設計常用的方法是實體分析法、屬性綜合法。

二元聯繫的類型與定義:二元聯繫指兩個實體之間的聯繫。分爲一對一、一對多、多對多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種信息。

扇形陷阱:指由一個實體引出的兩種不同類型的扇形聯繫,形成雙扇形結構。

3.數據庫物理設計:

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

?

三、模式

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

1、概念模式:

只涉及行的描述,不涉及具體的值。概念模式的一個具體值稱爲模式的一個實例,同一模式可以有很多實例。概念模式反映的是數據庫的結構及其聯繫,所以是相對穩定的。而實例反映的是數據庫某一時刻的狀態,所以是相對變動的。

概念模式不僅要描述記錄類型,還要描述記錄間的聯繫、操作、數據的完整性、安全性。但概念模式不涉及存儲結構、訪問技術等細節。

(注:可理解爲系統表部分)

2、外模式:

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

(注:可理解爲用戶表部分)

3、內模式:

也稱存儲模式,是數據庫物理結構和存儲方式的描述,是數據在數據庫內部的表示方式。定義所有內部記錄的類型、索引、文件的組織方式。記錄的存儲方式是順序存儲、B樹存儲、Hash方法存儲等。

?

兩級映像:模式/內模式映像、外模式/模式映像。

?

實體與記錄:實體表示客觀存在,能區別的事物。記錄是字段的有序集合,一般一條記錄描述一個實體。

屬性與字段:屬性描述實體某方面的特性,字段標記實體屬性的命名單位。

碼與記錄碼:碼是唯一能區分實體的屬性或屬性集,記錄碼是唯一標識文件中的每條記錄的字段或字段集。

實體集與文件:實體集是具有共同特性的實體的集合。文件是同一類記錄的彙集。

實體型與記錄型:實體型是屬性的集合,記錄型是記錄的結構定義。

?

數據模型三要素:

數據庫結構的基礎是數據模型,是用來描述數據的一組概念和定義。

數據模型三要素是數據結構、數據操作、數據的約束條件。

?

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支持三級模式結構:視圖對應外模式,基本表對應模式,存儲文件對應內模式。

?

索引:

數據庫中索引與書籍中索引類似,利用索引可以快速查找整本書信息,無需閱讀整本書。

數據庫索引可以使數據庫程序無需對整個表進行掃描,就可以在其中找到所需數據。

?

索引分爲:

聚集索引和非聚集索引。

聚集索引是指索引表中索引項的順序與表中記錄的物理順序一致的索引。

?

視圖創建遵循如下規定:

(1)子查詢不允許有order by和distinct語句。

(2)with check option表示對update、insert、delete操作時保證更新、插入或刪除的行滿足視圖定義的謂詞條件(即滿足子查詢中的where後的條件表達式)。

(3)組成視圖的屬性列名或者全部省略或者全部指定。如果省略屬性列名,則隱含視圖由SELECT子查詢目標列的主屬性組成。

?

SQL的訪問控制:數據庫控制是控制用戶的存儲權限,由DBA來決定。

通過GRANT和REVORK將授權通知系統,並存入數據字典。

?

四、規範化

規範化:將關係模式從低一級範式轉化成高一級範式的過程。

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是關係模式最高的規範化程度。

?

五、事務管理

事務有4個特性ACID。

原子性(A):要麼全做,要麼全不做。

一致性(C):一個事務獨立執行的結果,將保持數據的一致性,即數據不會因爲數據的執行而遭受破壞。

隔離性(I):一個事務的執行不能被其它事物干擾。

持久性(D):一個事物一旦提交,對數據庫的改變必須是永久的。

SQL中事物定義語句有3條:

BEGIN TRANSACTION:事務開始。

COMMIT:事務提交。

ROLLBACK:事務回滾。

?

六、併發控制
併發控制主要技術是封鎖,主要包含:排他鎖(簡稱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授權的用戶在創建新關係後自動獲得該關係上的所有權限。

 

發表評論
所有評論
還沒有人評論,想成為第一個評論的人麼? 請在上方評論欄輸入並且點擊發布.
相關文章