關系型數據庫邏輯結構設計的原則、方法與意義探析

摘要：文章從數據庫系統的邏輯結構設計的重要性切題，以關系型數據庫為例，闡明邏輯結構設計原則與方法，用實例回答了良好的邏輯結構設計所帶來的好處，最后進行總結，指出基本概念是關鍵，邏輯結構中的表盡量符合第三范式，表與表之間的聯系通過外鍵來表達。同時也要兼顧表的規范化及數據庫的性能，保證數據庫系統的穩定性、高可用。

關鍵詞：邏輯結構設計；函數依賴；關系規范化

中圖分類號：TP3 文獻標識碼：A

文章編號：1009-3044（2024）19-0084-03

數據庫系統設計的步驟主要包括需求分析、概念結構設計、邏輯結構設計以及數據庫的實施和維護。邏輯結構設計是關鍵環節之一，這個環節做好做實了，數據庫系統的穩定性、安全性、完整性和高性能才有基礎。

1 數據庫系統邏輯結構設計的重要性

數據庫系統設計的根本目的是滿足用戶收集、存儲、操作和管理數據的需要。數據庫系統的三個模式兩級映像保證了數據庫外模式的穩定性，既保證了數據的邏輯獨立性；也從底層保證了應用程序的穩定性，還保證了數據的物理獨立性。除非應用需求本身發生變化，否則應用程序一般不需要修改。

在數據庫系統的三級模式結構中，數據庫邏輯模式是數據庫的中心與關鍵，它獨立于數據庫的其他層次，因此設計數據庫模式結構時應首先確定數據庫的邏輯模式，進行邏輯結構設計。良好的數據庫系統的邏輯結構設計，可以節省數據的存儲空間，能夠保證數據的完整性，方便進行數據庫系統的開發。反之，會導致數據冗余、存儲空間浪費，數據更新、刪除和插入的異常。

2 數據庫系統的邏輯結構設計的原則

數據庫常見的數據模型有層次模型、網狀模型、關系模型、對象-關系模型等，關系模型是目前最重要的一種數據模型，關系數據庫就是采用關系模型作為數據的組織方式。關系模型源于數學，它把數據看成是二維表中的元素，而這個二維表在關系數據庫中就稱為關系。在關系數據庫中，記錄值僅構成關系，關系之間的聯系是靠語義相同的字段（稱為連接字段）值表達的[1]。理解關系和連接字段（即列）的思想在關系數據庫中是非常重要的。本文討論數據庫系統的邏輯結構設計就是以關系模型為例。

2.1 表設計原則

在關系型數據庫系統中的邏輯結構設計體現在二維表結構的設計，在設計時盡可能遵守第三范式標準的表設計原則，一個主題對應一張表，即一個表中只包含其本身的基本屬性。

之所以要盡可能遵守第三范式標準的表設計原則，是因為第一范式、第二范式都有可能存在數據冗余，如果存在數據冗余，就有可能引起操作異常，包括插入異常、刪除異常、更新異常。為了避免數據操作異常，我們一般把數據庫設計到第三范式，也就是說我們在一張表中不允許存在部分函數依賴和傳遞函數依賴：從第一范式規范到第二范式時消除了部分函數依賴；從第二范式規范到第三范式時消除了傳遞函數依賴，在規范化的過程中逐步消除了“不良”的函數依賴[2]。

表的規范化可以保證表內的字段都是最基本的要素，同時規范化這一措施也有助于消除數據中的數據冗余。規范化有好幾種形式：1NF、2NF、3NF、BCNF、4NF、5NF等。但3NF通常被認為在性能、擴展性和數據完整性方面達到了最佳平衡。而BCNF、4NF、5NF更多是作為數據理論研究。簡單來說，滿足3NF的表，有如下3個特點，表內的每一個值都只能被表達一次；表內的每一行都能被區分；每一個表都不包含其他表已經包含的非主關鍵字信息。

2.2 字段設計原則

在進行數據庫系統邏輯設計中，表中的字段設計在長度上要盡量充足，同時考慮未來發展。比如企業目前職工人數是數百人，則職工編號為3位數字，但考慮到今后企業有可能壯大到數千人，則可將職工編號設置為4位數字，這樣盡量滿足一段時間內企業發展的需求。給字段留足余量，將來無須重構整個數據庫就可以實現數據庫規模的增長了，增強了系統的靈活性[3]。

在進行數據庫系統邏輯設計中，還要考慮表字段的命名規范。字段的名稱要易于理解，便于閱讀，要有意義，不宜太長，要保證數據庫表中字段名沒有和保留字或者常用訪問方法沖突，否則在程序連接時會出錯，在用SELECT語句查詢時，會得到一大堆無用處的信息。還要注意的是：在命名字段并為其指定數據類型的時候，一定要在各個表中保證一致性；字段名都采用加上前綴的方式，如加上所屬表縮寫名的前綴，那么在編寫SQL表達式的時候會得到大大的簡化；對地址采用多個字段，可以提供更大的靈活性；有時在表中創建一個計算列（如成績總分），通過它可以自動地連接標準化的字段，這樣數據變動的時候，計算列也跟著變動，實現數據的自動更新。

進行數據庫邏輯設計時，還要有一種服務意識、大局意識，因為數據庫邏輯設計只是一個小小的環節，還有數據庫管理員、應用程序開發員等，最終用戶要使用數據庫系統，所以要考慮周全。

2.3 謹慎使用觸發器

觸發器在保證數據完整性及商業規則方面有積極作用，比如我們要限制不能將學生成績由不及格改成及格這樣復雜的業務規則，我們則用觸發器來實現。

但不當地使用觸發器時，它會帶來效率方面的問題。比如，我們用觸發器來限制學生的考試成績在0～150分。我們知道觸發器有兩種類型，一種是前觸發型，另一種是后觸發型。假設先使用了一個后觸發型觸發器來實現，那這個處理流程是這樣的：先完成數據的插入，再執行觸發器。在觸發器中判斷新插入的數據是否不在0～150分，如果不在，要作一個回滾roll?back的操作，把剛插入的數據撤銷。如果使用的是前觸發型觸發器，同樣假設是在一個插入操作上定義觸發器。執行插入操作時，系統它本身并不實際執行插入操作，而是去執行觸發器的代碼。當我們在觸發器當中發現新插入的成績滿足在0～150分時，再在觸發器當中寫一個重新插入這樣一條語句。

不管是后觸發型的觸發器作一個回滾rollback操作，還是前觸發型的觸發器再重新寫一遍插入操作，這些都比直接做插入操作多了一些額外的工作。因此不當使用觸發器會降低數據的操作效率。觸發器的功能通常可以用其他方式實現，如果我們定的是一個check約束，情況就不一樣了，數據庫管理系統首先會檢查我們的數據是否滿足我們的check約束的要求。如果不滿足，這個操作是不會執行的，這樣顯然比我們用觸發器的效率高很多。所以我們能夠用check約束或唯一值約束等完整性約束來實現這些約束，都不要使用觸發器來實現，只有他們實現不了的復雜約束和企業規則，才使用觸發器。

2.4 恰當使用視圖

視圖主要是為了在數據庫和應用程序代碼之間提供另一層抽象。我們知道數據庫系統是三級模式兩級映像的結構。三層模式是內模式、概念模式、外模式，視圖就對應到外模式。外模式是針對每一類用戶對信息的需求來設計的，因此我們在設計外模式的時候，實際上是可以滿足每一類用戶的信息需求的。

在定義視圖時，實際上它可以實現包含復雜查詢的語句。用戶需要查詢這些數據，如果我們定義好了視圖，在客戶端用戶中需要對這個視圖進行訪問就可以，不需要去編寫復雜的查詢語句。當然了我們通過視圖，通過外模式訪問數據，它最終都會轉換到內模式，對基本表的訪問。因此通過視圖訪問數據效率會有一些降低，但可以簡化客戶端的編程，可以封裝復雜的查詢，可以恰當地去使用視圖。

2.5 編寫設計文檔

對所有的設計都要編寫相應文檔，每一個設計階段都要產生一些文檔，便于后期維護和經驗總結。

3 數據庫系統邏輯結構設計的方法

3.1 數據冗余帶來的操作異常

數據庫設計是數據庫應用領域中的重要研究課題，其主要任務是創建滿足用戶需求且性能良好的數據庫模式。對于關系型數據庫設計確切地講其主要任務就是關系數據庫的邏輯設計問題：如何為數據庫應用系統設計合適的關系模式，應設計幾個關系模式，每個關系模式由哪些屬性組成等等。

某電子有限責任公司需要開發一個員工信息管理系統，現設計了一張員工信息表，表中有5項屬性（工號、工作車間、宿舍樓、零件號、工分），前提假設同一工作車間的員工住在同一棟宿舍樓里，一位員工可以加工不同的零件來取得工分。這個表的主鍵是（工號、零件號）。現有如下數據，見表1最初的員工信息表。

我們來分析一下這個表的數據，看看可有數據冗余的情況，如有，在數據冗余的情況下，會出現哪些操作異常。

從行的角度來看，前面4 行數據實際上是描述QC1910001這位員工的。之所以出現了4次，是因為他后面選的加工零件有4種。從列的角度來看，前兩列描述的是這位員工在哪個車間工作這個主題，第二列與第三列描述的是這個車間的員工住在哪棟宿舍樓這個主題。這兩個主題由于與后面所選的加工零件合在一張表進行描述，所以被重復描述了多遍，有數據冗余的情況。

在有數據冗余的情況，它帶來的最直觀的問題是造成存儲空間的浪費。除了存儲空間的浪費，還會帶來不好的后果，就是操作異常。

1） 數據插入異常

假設公司的規模不斷擴大，現要新增一個車間：工作車間4，也分配了這個車間的員工住在4號樓。但目前還沒開始招收員工，因此還沒有工號與零件號的數據，而（工號、零件號）是這張表的主鍵，我們知道要插入一行數據，主鍵為空是插入不了的。這樣新增的這個車間的信息就插不進去了。所以說數據冗余有可能造成數據插入異常。

2） 數據更新異常

假設公司新蓋了宿舍樓，現要把車間1的員工搬到新蓋的宿舍樓：新1號樓。按常理來說，要更改這樣一個主題，只要更改一次就夠了。但對于我們這個設計方法，在這張表中就要更改6次。那由小及大，如果這個車間1的員工是100人，那起碼得更改100次。這就造成了時間的浪費，效率的低下，出錯的可能。所以說數據冗余有可能造成數據更新異常。

3） 數據刪除異常

假設有員工只加工一種型號的零件，現公司不再加工這個零件了，要把這行數據刪除。那么刪除掉這行信息，同時也就把這位員工的其他基本信息一并刪除了。可見，多個主題合在一起，放在同一張表中進行描述的這種設計方法，有可能造成數據刪除異常。

顯然，好的數據庫邏輯結構設計很重要。不僅避免了空間的浪費，也避免了數據操作異常，還能提高效率，能夠保證數據的完整性，方便進行數據庫系統的開發[4]。

3.2 數據庫邏輯結構設計的規范化

進行數據庫邏輯結構設計，要遵循關系規范化理論，要理解函數依賴與范式間的內在關系。某電子有限責任公司這張員工信息表不是一個好的關系模式，只有通過模式分解，把這個關系模式分解成更高級別的兩個或是多個關系模式，在分解的過程中消除那些“不良”的函數依賴，從而獲得良好的關系模式。

1） 消除部分函數依賴，規范化到第二范式

我們知道，不包含非原子項屬性的關系是第一范式的關系。也只有滿足第一范式的表，我們在關系模式的數據庫中才能去存儲。員工信息表（工號、工作車間、宿舍樓、零件號、工分）都是原子項屬性，所以它是第一范式的關系。

在員工信息表當中，（工號、零件號）是主鍵，而工作車間完全函數依賴于工號，這樣就存在工作車間部分函數依賴于主鍵。同時存在數據冗余，操作異常的情況。因此，我們用分解的方法，把這張表規范化到第二范式，消除部分函數依賴。

首先，用組成主鍵的屬性集合的每一個子集，作為主鍵構成關系表。在這，我們得到主鍵的3個子集分別為：工號，零件號，（工號、零件號）。

再者，將依賴于不同主鍵的屬性放置到相應的關系表中。得到3張表：（工號、工作車間、宿舍樓）；（工號、零件號、工分）；（零件號）。

最后，去掉只由主鍵的子集構成的關系表。

這樣就把員工信息表規范化到第二范式了，得到兩張表。（工號、工作車間、宿舍樓）；（工號、零件號、工分）。

已規范化到第二范式的關系表，再看表2的工作車間與宿舍樓這兩列數據，還是存在數據冗余的情況。有數據冗余就可能存在數據操作異常。因此，繼續向第三范式進行規范化。

2） 消除傳遞函數依賴，規范化到第三范式

在（工號、工作車間、宿舍樓）這張第二范式的關系表中，工作車間完全函數依賴于工號，宿舍樓又完全函數依賴于工作車間，因此，宿舍樓傳遞函數依賴于工號，并且有數據冗余的情況。繼續用分解的方法，把這張表規范化到第三范式，消除傳遞函數依賴。

首先，對于不是候選鍵的每個決定因子，從關系模式中刪去依賴于它的所有屬性。在此表中，工作車間決定宿舍樓，工作車間這個決定因子并不是一個候選鍵，因此，把依賴于它的屬性宿舍樓刪去。

再者，新建一個關系模式，新關系模式中包含在原關系模式中所有依賴于該決定因子的屬性。那么新關系模式為（宿舍樓）。

最后，將決定因子作為新關系模式的主鍵。那么新關系模式為（工作車間、宿舍樓）。

這樣，我們就把（工號、工作車間、宿舍樓）這張第二范式的關系表分解為兩張第三范式的表（工號、工作車間），（工作車間、宿舍樓）。分解到第三范式了，這兩張表基本上不存在數據冗余，沒有數據冗余，也就基本上消除了操作異常。

3） 設置外鍵，保持表間的聯系，保證數據的完整性

經過規范化，最終把員工信息表分解成了三個第三范式的關系表：

form1（工號、工作車間），工號是主鍵，工作車間為引用form2的外鍵。

form2（工作車間、宿舍樓），工作車間是主鍵，沒有外鍵。

form3（工號、零件號、工分），（工號、零件號）是主鍵，工號為引用form1的外鍵。

表之間的關系是通過外鍵來連接的。原來在一張表中的數據，為了保證數據庫的性能，通過分解的方法變成了多張表，規范化到了第三范式，為了保持表中原數據間的聯系，我們可以通過設計外鍵的方法保持表間的聯系，保持數據的依賴關系。例如，在前面的表中，定義form3表當中的工號當作外鍵，它參照form1表中的工號，這樣可以保證進行零件加工的員工是在form1表中登記在冊的員工。這樣也就保證了這兩張表數據間的關聯關系。

關系規范化的方法是進行模式分解，但分解后產生的關系模式應與原關系模式等價，不能表面上消除了操作異常現象，卻留下了其他的問題。為此，模式分解還要注意兩點：一是模式分解具有無損連接性；二是模式分解能夠保持函數依賴。

4） 堅持標準化的設計理念

在表設計原則中，應盡量遵守第三范式的標準，更高層次的標準也有，但更高標準不一定更好。事實上，對某些項目而言，甚至就連3NF都可能給數據庫引入太高的復雜性。有時為了提高運行效率，就得適當保留冗余數據，對表不進行標準化有時也是必要的，非標準化與加速訪問之間的妥協是有一定意義的，但絕不能把數據表的非標準化當作理所當然的設計理念[5]。適當保留冗余數據，具體做法是增加字段，但這具體的操作不過是一種派生，所以標準化的設計理念是要堅持的，從根本上保證數據庫系統的高性能、高可用。

4 數據庫系統邏輯結構設計的意義

數據庫系統邏輯結構設計的意義在于為數據庫系統的穩定性、安全性、完整性和高性能提供支撐。數據庫系統邏輯結構設計是數據庫設計的“綱”。在數據庫系統的三級模式中，邏輯模式是數據庫系統的中間層，是對數據庫中的全體數據的描述，是所有用戶的公共數據視圖。“壹引其綱，萬目皆張”，設計出良好的邏輯模式，不僅能節省數據的存儲空間，而且方便數據庫應用系統的開發，還能保證數據的完整性等。

數據庫系統的設計往往工作量比較大，過程復雜，綜合性強，涉及面廣，要確切表達用戶的需求，構造最優的數據庫模式，因此要努力把數據庫設計和系統其他成分的設計緊密結合，把數據和處理的需求、分析、抽象、設計和實現在各個階段同時進行，相互參照，相互融合。

參考文獻：

[1] 王珊，薩師煊.數據庫系統概論[M].5版.北京：高等教育出版社，2014.

[2] 丁智斌，石浩磊.關系數據庫設計與規范化[J].計算機與數字工程，2005，33（2）：114-116.

[3] 舒思思.淺談圖書管理系統的設計[J].湖北科技學院學報，2013，33（2）：159-160.

[4] 郭文明.數據庫運維[M].北京：國家開放大學出版社，2019.

[5] 陶勇，丁維明.數據庫中規范化與反規范化設計的比較與分析[J].計算機技術與發展，2006，16（4）：107-109，121.

【通聯編輯：朱寶貴】