一個關聯式資料庫由一組關係模式組成，一個關係由一組屬性名組成，關聯式資料庫設計就是如何把已給定的相互關聯的一組屬性名分組，並把每一組屬性名組織成關係的問題。

所謂規範化，就是用形式更為簡潔、結構更加規範的關係模式取代原有關係的過程。

實體間的聯絡有兩類：一類是實體與實體之間的聯絡；另一類是實體內部各屬性間的聯絡。

屬性間的聯絡可分為以下三類：

以職工模式為例：職工（職工號，姓名，職稱，部門）。如果該企業（或單位）中職工無重名，則屬性職工號與姓名之間是1∶1聯絡。一個職工號唯一地決定一個姓名，一個姓名也可決定唯一的職工號。

設X、Y是關係R的兩個屬性（集）。如果對於X中的任一具體值，Y中至多有一個值與之對應，且反之亦然，則稱X、Y兩屬性間是一對一聯絡。

在職工模式中，職工號和職稱間是一對多聯絡。一個職工號只對應一種職稱（如胡一民只能對應工程師），但一種職稱卻可對應多個職工號（如工程師可對應多名職工）。

設X、Y是關係R的兩個屬性（集）。如果對於X中的任一具體值，Y中至多有一個值與之對應，而Y中的一個值卻可以和X中的n個值相對應，則稱Y對X是一對多聯絡。

在職工模式中，職稱和部門之間是多對多聯絡。一種職稱可分佈在多個部門中（如每一個部門中均可有工程師），而一個部門中也可有多個職稱。

設X、Y是關係R的兩個屬性（集）。如果對於X中的任一具體值，Y中有m個值與之對應，而Y中的一個值也可以和X中的n個值相對應，則稱Y對X是多對多聯絡。

函式依賴是屬性之間的一種聯絡。假設給定一個屬性的值，就可以唯一確定（查到）另一個屬性的值。

定義：所謂函式依賴是指在關係R中，X、Y為R的兩個屬性或屬性組，如果對於R的任一關係r都存在：對於X的每一個具體值，Y都只有一個具體值與之對應，則稱屬性Y函式依賴於屬性X。或者說，屬性X函式決定屬性Y，記作XàY。其中X叫決定因素，Y叫被決定因素。當Y是X的子集時，稱為平凡函式依賴。由於平凡函式依賴總是成立的，因此，若不作特殊宣告，本書後面提到的函式依賴，都不包含平凡函式依賴。

此定義可簡單表述為：如果屬性X的值決定屬性Y的值，那麼屬性Y函式依賴於屬性X。

前面討論的屬性間的三種聯絡，並不是每一種聯絡中都存在函式依賴。

（1）如果兩屬性集X、Y 間是1∶ 1聯絡，則存在函式依賴：Xß>Y。

（2）如果兩屬性集X、Y間是m∶ 1聯絡，則存在函式依賴：XàY。

（3）如果兩屬性集X、Y間是m∶ n聯絡，則不存在函式依賴。

· 若候選碼多於一個，則選定其中的一個為主碼（PrimaryKey）；

· 包含在任一候選碼中的屬性，叫做主屬性（PrimeAttribute）；

· 不包含在任何候選碼中的屬性稱為非主屬性（NonprimeAttribute）或非碼屬性（Non KeyAttribute）；

· 關係模式中，最簡單的情況，單個屬性是碼，稱為單碼（SingleKey）；最極端的情況，整個屬性組是碼，稱為全碼（All Key）。

定義 設有兩個關係模式R和S，X是R的屬性或屬性組，並且X不是R的碼，但X是S的碼（或與S的碼意義相同），則稱X是R的外部碼（ForeignKey），簡稱外碼。

碼是由一個或多個屬性組成的可唯一標識元組的最小屬性組。碼在關係中總是唯一的，即碼函式決定關係中的其他屬性。因此，一個關係中，碼值總是唯一的（如果碼的值重複，則整個元組都會重複）。否則，違反實體完整性規則。

與碼的唯一性不同，在關係中，一個函式依賴的決定因素可能是唯一的，也可能不是唯一的。如果我們知道A決定B，且A和B在同一關係中，但我們仍無法知道A是否能決定除B以外的其他所有屬性，所以無法知道A在關係中是否是唯一的。

當一個關係中的所有分量都是不可分的資料項時，該關係是規範化的

關係按其規範化程度從低到高可分為5級正規化，分別稱為1NF、2NF、3NF（BCNF）、4NF、5NF。規範化程度較高者必是較低者的子集

1NF是規範化的最低要求，不滿足1NF的關係是非規範化關係

推論：如果關係模式R‑1NF，且它的每一個候選碼都是單碼，則R屬於2NF。

推論1 如果關係模式R屬於1NF，且它的每一個非主屬性既不部分依賴，也不傳遞依賴於任何候選碼，則R屬於3NF。

推論2 不存在非主屬性的關係模式一定為3NF。

定義 設關係模式R（U，F）屬於NF，若F的任一函式依賴XàY（Y不是X的子集）中X都包含了R的一個碼，則稱R屬於BCNF。

換言之，在關係模式R中，如果每一個決定因素都包含碼，則R屬於BCNF。

由BCNF的定義可以得到以下推論：如果R屬於BCNF，則

· R中所有非主屬性對每一個碼都是完全函式依賴；

· R中所有主屬性對每一個不包含它的碼，都是完全函式依賴；

· R中沒有任何屬性完全函式依賴於非碼的任何一組屬性。

定理：如果R屬於BCNF，則R屬於3NF一定成立。

一個關係模式如果達到了BCNF，那麼在函式依賴範圍內，它已實現了徹底的分離，消除了資料冗餘、插入和刪除異常。

定義 設R（U）是屬性集U上的一個關係模式，X、Y、Z是U的子集，且Z=U-X-Y。如果對R（U）的任一關係r，給定一對（x，z）值，都有一組Y值與之對應，這組Y值僅僅決定於x值而與z值無關。稱Y多值依賴於X，或X多值決定Y，記作XààY。

定義中如果Z為空集，則稱XààY為平凡的多值依賴，否則為非平凡多值依賴。

定義 如果關係模式R屬於1NF，對於R的每個非平凡的多值依賴XààY（Y不是X的子集），X含有碼，則稱R是第四正規化，即R屬於4NF。

一個關係模式如果屬於4NF，則一定屬於BCNF，但一個BCNF的關係模式不一定是4NF的，R中所有的非平凡多值依賴實際上是函式依賴。

關係規範化的目的是解決關係模式中存在的資料冗餘、插入和刪除異常、更新繁瑣等問題。其基本思想是消除資料依賴中的不合適部分，使各關係模式達到某種程度的分離，使一個關係描述一個概念、一個實體或實體間的一種聯絡。因此，規範化的實質是概念的單一化。

規範化的基本原則是：由低到高，逐步規範，權衡利弊，適可而止。通常，以滿足第三正規化為基本要求。

把一個非規範化的資料結構轉換成第三正規化，一般經過以下幾步：

（1）把該結構分解成若干個屬於第一正規化的關係。

（2）對那些存在組合碼，且有非主屬性部分函式依賴的關係必須繼續分解，使所得關係都屬於第二正規化。

（3）若關係中有非主屬性傳遞依賴於碼，則繼續分解之，使得關係都屬於第三正規化。

關係模式的規範化過程是通過投影分解實現的，即用投影運算把一個模式分解成若干個高一級的關係模式。這種投影分解不是唯一的。


四、資料庫設計
定義
(Database Design)是指根據使用者的需求，在某一具體的資料庫管理系統上，設計資料庫的結構和建立資料庫的過程。資料庫系統需要作業系統的支援。
資料庫設計是建立資料庫及其應用系統的技術，是資訊系統開發和建設中的核心技術。由於資料庫應用系統的複雜性，為了支援相關程式執行，資料庫設計就變得異常複雜，因此最佳設計不可能一蹴而就，而只能是一種“反覆探尋，逐步求精”的過程，也就是規劃和結構化資料庫中的資料物件以及這些資料物件之間關係的過程。

資料庫建設是硬體、軟體和幹件的結合
三分技術，七分管理，十二分基礎資料
技術與管理的介面稱之為“幹件”
資料庫設計應該與應用系統設計相結合
結構（資料）設計：設計資料庫框架或資料庫結構
行為（處理）設計：設計應用程式、事務處理等
結構和行為分離的設計
傳統的軟體工程忽視對應用中資料語義的分析和抽象，只要有可能就儘量推遲資料結構設計的決策。早期的資料庫設計致力於資料模型和建模方法研究，忽視了對行為的設計

資訊系統
(1)資料庫是資訊系統的核心和基礎，把資訊系統中大量的資料按一定的模型組織起來，提供儲存、維護、檢索資料的功能，使資訊系統可以方便、及時、準確地從資料庫中獲得所需的資訊。
(2)資料庫是資訊系統的各個部分能否緊密地結合在一起以及如何結合的關鍵所在。
(3)資料庫設計是資訊系統開發和建設的重要組成部分。
(4)資料庫設計人員應該具備的技術和知識：
資料庫的基本知識和資料庫設計技術
電腦科學的基礎知識和程式設計的方法和技巧
軟體工程的原理和方法
應用領域的知識


設計方法
手工試湊法
設計質量與設計人員的經驗和水平有直接關係
缺乏科學理論和工程方法的支援，工程的質量難以保證
資料庫執行一段時間後常常又不同程度地發現各種問題，增加了維護代價
規範設計法
基本思想：過程迭代和逐步求精
典型方法：
(1)新奧爾良（New Orleans）方法：將資料庫設計分為四個階段
S.B.Yao方法：將資料庫設計分為五個步驟
I.R.Palmer方法：把資料庫設計當成一步接一步的過程
(2)計算機輔助設計
ORACLEDesigner 2000
SYBASEPowerDesigner

步驟
需求分析
調查和分析使用者的業務活動和資料的使用情況，弄清所用資料的種類、範圍、數量以及它們在業務活動中交流的情況，確定使用者對資料庫系統的使用要求和各種約束條件等，形成使用者需求規約。
需求分析是在使用者調查的基礎上，通過分析，逐步明確使用者對系統的需求，包括資料需求和圍繞這些資料的業務處理需求。在需求分析中，通過自頂向下，逐步分解的方法分析系統，分析的結果採用資料流程圖(DFD)進行圖形化的描述。

概念設計
對使用者要求描述的現實世界(可能是一個工廠、一個商場或者一個學校等)，通過對其中諸處的分類、聚集和概括，建立抽象的概念資料模型。這個概念模型應反映現實世界各部門的資訊結構、資訊流動情況、資訊間的互相制約關係以及各部門對資訊儲存、查詢和加工的要求等。所建立的模型應避開資料庫在計算機上的具體實現細節，用一種抽象的形式表示出來。以擴充的實體—（E-R模型）聯絡模型方法為例，第一步先明確現實世界各部門所含的各種實體及其屬性、實體間的聯絡以及對資訊的制約條件等，從而給出各部門內所用資訊的區域性描述(在資料庫中稱為使用者的區域性檢視)。第二步再將前面得到的多個使用者的區域性檢視整合為一個全域性檢視，即使用者要描述的現實世界的概念資料模型。

邏輯設計
主要工作是將現實世界的概念資料模型設計成資料庫的一種邏輯模式，即適應於某種特定資料庫管理系統所支援的邏輯資料模式。與此同時，可能還需為各種資料處理應用領域產生相應的邏輯子模式。這一步設計的結果就是所謂“邏輯資料庫”。
oa工作流資料庫設計
oa工作流資料庫設計

物理設計
根據特定資料庫管理系統所提供的多種儲存結構和存取方法等依賴於具體計算機結構的各項物理設計措施，對具體的應用任務選定最合適的物理儲存結構(包括檔案型別、索引結構和資料的存放次序與位邏輯等)、存取方法和存取路徑等。這一步設計的結果就是所謂“物理資料庫”。

驗證設計
在上述設計的基礎上，收集資料並具體建立一個資料庫，執行一些典型的應用任務來驗證資料庫設計的正確性和合理性。一般，一個大型資料庫的設計過程往往需要經過多次迴圈反覆。當設計的某步發現問題時，可能就需要返回到前面去進行修改。因此，在做上述資料庫設計時就應考慮到今後修改設計的可能性和方便性。

執行與維護設計
在資料庫系統正式投入執行的過程中，必須不斷地對其進行調整與修改。
資料庫設計步驟
資料庫設計步驟
至今，資料庫設計的很多工作仍需要人工來做，除了關係型資料庫已有一套較完整的資料正規化理論可用來部分地指導資料庫設計之外，尚缺乏一套完善的資料庫設計理論、方法和工具，以實現資料庫設計的自動化或互動式的半自動化設計。所以資料庫設計今後的研究發展方向是研究資料庫設計理論，尋求能夠更有效地表達語義關係的資料模型，為各階段的設計提供自動或半自動的設計工具和整合化的開發環境，使資料庫的設計更加工程化、更加規範化和更加方便易行，使得在資料庫的設計中充分體現軟體工程的先進思想和方法。

形成過程
1.需求分析階段：綜合各個使用者的應用需求(資料流程圖(DFD)
2.概念設計階段：形成獨立於機器特點，獨立於各個DBMS產品的概念模式(E-R圖)
3.邏輯設計階段：首先將E-R圖轉換成具體的資料庫產品支援的資料模型，如關係模型，形成資料庫邏輯模式；然後根據使用者處理的要求、安全性的考慮，在基本表的基礎上再建立必要的檢視(View)，形成資料的外模式
4.物理設計階段：根據DBMS特點和處理的需要，進行物理儲存安排，建立索引，形成資料庫內模式。

設計技巧
設計資料庫之前
（需求分析階段）
1) 理解客戶需求，詢問使用者如何看待未來需求變化。讓客戶解釋其需求，而且隨著開發的繼續，還要經常詢問客戶保證其需求仍然在開發的目的之中。
2) 瞭解企業業務可以在以後的開發階段節約大量的時間。
3) 重視輸入輸出。
在定義資料庫表和欄位需求（輸入）時，首先應檢查現有的或者已經設計出的報表、查詢和檢視（輸出）以決定為了支援這些輸出哪些是必要的表和欄位。
舉例：假如客戶需要一個報表按照郵政編碼排序、分段和求和，你要保證其中包括了單獨的郵政編碼欄位而不要把郵政編碼糅進地址欄位裡。
4) 建立資料字典和ER 圖表
ER 圖表和資料字典可以讓任何瞭解資料庫的人都明確如何從資料庫中獲得資料。ER圖對錶明表之間關係很有用，而資料字典則說明了每個欄位的用途以及任何可能存在的別名。對SQL表示式的文件化來說這是完全必要的。
5) 定義標準的物件命名規範
資料庫各種物件的命名必須規範。


表和欄位的設計
（資料庫邏輯設計）
表設計原則
1) 標準化和規範化
資料的標準化有助於消除資料庫中的資料冗餘。標準化有好幾種形式，但Third Normal Form（3NF）通常被認為在效能、擴充套件性和資料完整性方面達到了最好平衡。簡單來說，遵守3NF 標準的資料庫的表設計原則是：“One Fact in One Place”即某個表只包括其本身基本的屬性，當不是它們本身所具有的屬性時需進行分解。表之間的關係通過外來鍵相連線。它具有以下特點：有一組表專門存放通過鍵連線起來的關聯資料。
舉例：某個存放客戶及其有關定單的3NF資料庫就可能有兩個表：Customer 和Order。Order 表不包含定單關聯客戶的任何資訊，但表內會存放一個鍵值，該鍵指向Customer 表裡包含該客戶資訊的那一行。
事實上，為了效率的緣故，對錶不進行標準化有時也是必要的。
2) 資料驅動
採用資料驅動而非硬編碼的方式，許多策略變更和維護都會方便得多，大大增強系統的靈活性和擴充套件性。
舉例，假如使用者介面要訪問外部資料來源（檔案、XML 文件、其他資料庫等），不妨把相應的連線和路徑資訊儲存在使用者介面支援表裡。還有，如果使用者介面執行工作流之類的任務（傳送郵件、列印信箋、修改記錄狀態等），那麼產生工作流的資料也可以存放在資料庫裡。角色許可權管理也可以通過資料驅動來完成。事實上，如果過程是資料驅動的，你就可以把相當大的責任推給使用者，由使用者來維護自己的工作流過程。
3) 考慮各種變化
在設計資料庫的時候考慮到哪些資料欄位將來可能會發生變更。
舉例，姓氏就是如此（注意是西方人的姓氏，比如女性結婚後從夫姓等）。所以，在建立系統儲存客戶資訊時，在單獨的一個資料表裡儲存姓氏欄位，而且還附加起始日和終止日等欄位，這樣就可以跟蹤這一資料條目的變化。
4) 每個表中都應該新增的3 個有用的欄位
dRecordCreationDate，在VB 下預設是Now()，而在SQL Server 　· 下預設為GETDATE()
sRecordCreator，在SQL Server 下預設為NOT NULL DEFAULT 　· USER
nRecordVersion，記錄的版本標記；有助於準確說明記錄中出現null 資料或者丟失資料的原因 　·
5) 對地址和電話採用多個欄位
描述街道地址就短短一行記錄是不夠的。 Address_Line1、Address_Line2 和Address_Line3 可以提供更大的靈活性。還有，電話號碼和郵件地址最好擁有自己的資料表，其間具有自身的型別和標記類別。
6) 使用角色實體定義屬於某類別的列
在需要對屬於特定類別或者具有特定角色的事物做定義時，可以用角色實體來建立特定的時間關聯關係，從而可以實現自我文件化。
舉例：用PERSON 實體和PERSON_TYPE 實體來描述人員。比方說，當John Smith, Engineer 提升為John Smith, Director 乃至最後爬到John Smith, CIO 的高位，而所有你要做的不過是改變兩個表PERSON 和PERSON_TYPE 之間關係的鍵值，同時增加一個日期/時間欄位來知道變化是何時發生的。這樣，你的PERSON_TYPE 表就包含了所有PERSON 的可能型別，比如Associate、Engineer、Director、CIO 或者CEO 等。還有個替代辦法就是改變PERSON 記錄來反映新頭銜的變化，不過這樣一來在時間上無法跟蹤個人所處位置的具體時間。
7) 選擇數字型別和文字型別儘量充足
在SQL 中使用smallint 和tinyint 型別要特別小心。比如，假如想看看月銷售總額，總額欄位型別是smallint，那麼，如果總額超過了$32,767 就不能進行計算操作了。
而ID 型別的文字欄位，比如客戶ID 或定單號等等都應該設定得比一般想象更大。假設客戶ID 為10 位數長。那你應該把資料庫表欄位的長度設為12 或者13 個字元長。但這額外佔據的空間卻無需將來重構整個資料庫就可以實現資料庫規模的增長了。
8) 增加刪除標記欄位
在表中包含一個“刪除標記”欄位，這樣就可以把行標記為刪除。在關聯式資料庫裡不要單獨刪除某一行；最好採用清除資料程式而且要仔細維護索引整體性。


選擇鍵和索引
（資料庫邏輯設計）
鍵選擇原則：
1) 鍵設計4 原則為
關聯欄位建立外來鍵。
所有的鍵都必須唯一。
避免使用複合鍵。
外來鍵總是關聯唯一的鍵欄位。
2) 使用系統生成的主鍵
設計資料庫的時候採用系統生成的鍵作為主鍵，那麼實際控制了資料庫的索引完整性。這樣，資料庫和非人工機制就有效地控制了對儲存資料中每一行的訪問。採用系統生成鍵作為主鍵還有一個優點：當擁有一致的鍵結構時，(不讓主鍵具有可更新性)
在確定採用什麼欄位作為表的鍵的時候，可一定要小心使用者將要編輯的欄位。通常的情況下不要選擇使用者可編輯的欄位作為鍵。
4) 可選鍵有時可做主鍵
把可選鍵進一步用做主鍵，可以擁有建立強大索引的能力。

索引使用原則：
索引是從資料庫中獲取資料的最高效方式之一。95%的資料庫效能問題都可以採用索引技術得到解決。
1) 邏輯主鍵使用唯一的成組索引，對系統鍵（作為儲存過程）採用唯一的非成組索引，對任何外來鍵列採用非成組索引。考慮資料庫的空間有多大，表如何進行訪問，還有這些訪問是否主要用作讀寫。
2) 大多數資料庫都索引自動建立的主鍵欄位，但是可別忘了索引外來鍵，它們也是經常使用的鍵，比如執行查詢顯示主表和所有關聯表的某條記錄就用得上。
3) 不要索引memo/note 欄位，不要索引大型欄位（有很多字元），這樣作會讓索引佔用太多的儲存空間。
4) 不要索引常用的小型表
不要為小型資料表設定任何鍵，假如它們經常有插入和刪除操作就更別這樣作了。對這些插入和刪除操作的索引維護可能比掃描表空間消耗更多的時間。

資料完整性設計
（資料庫邏輯設計）
1) 完整性實現機制：
實體完整性：主鍵
參照完整性：
父表中刪除資料：級聯刪除；受限刪除；置空值
父表中插入資料：受限插入；遞迴插入
父表中更新資料：級聯更新；受限更新；置空值
DBMS對參照完整性可以有兩種方法實現：外來鍵實現機制（約束規則）和觸發器實現機制
使用者定義完整性：
NOT NULL；CHECK；觸發器
2) 用約束而非商務規則強制資料完整性
採用資料庫系統實現資料的完整性。這不但包括通過標準化實現的完整性而且還包括資料的功能性。在寫資料的時候還可以增加觸發器來保證資料的正確性。不要依賴於商務層保證資料完整性；它不能保證表之間（外來鍵）的完整性所以不能強加於其他完整性規則之上。
3) 強制指示完整性
在有害資料進入資料庫之前將其剔除。啟用資料庫系統的指示完整性特性。這樣可以保持資料的清潔而能迫使開發人員投入更多的時間處理錯誤條件。
4) 使用查詢控制資料完整性
控制資料完整性的最佳方式就是限制使用者的選擇。只要有可能都應該提供給使用者一個清晰的價值列表供其選擇。這樣將減少鍵入程式碼的錯誤和誤解同時提供資料的一致性。某些公共資料特別適合查詢：國家程式碼、狀態程式碼等。
5) 採用檢視
為了在資料庫和應用程式程式碼之間提供另一層抽象，可以為應用程式建立專門的檢視而不必非要應用程式直接訪問資料表。這樣做還等於在處理資料庫變更時給你提供了更多的自由。

其他設計技巧
1) 避免使用觸發器
觸發器的功能通常可以用其他方式實現。在除錯程式時觸發器可能成為干擾。假如你確實需要採用觸發器，你最好集中對它文件化。
2) 使用常用英語（或者其他任何語言）而不要使用編碼
在建立下拉選單、列表、報表時最好按照英語名排序。假如需要編碼，可以在編碼旁附上使用者知道的英語。
3) 儲存常用資訊
讓一個表專門存放一般資料庫資訊非常有用。在這個表裡存放資料庫當前版本、檢查/修復（對 Access）、關聯設計文件的名稱、客戶等資訊。這樣可以實現一種簡單機制跟蹤資料庫，當客戶抱怨他們的資料庫沒有達到希望的要求而與你聯絡時，這樣做對非客戶機/伺服器環境特別有用。
4) 包含版本機制
在資料庫中引入版本控制機制來確定使用中的資料庫的版本。時間一長，使用者的需求總是會改變的。最終可能會要求修改資料庫結構。把版本資訊直接存放到資料庫中更為方便。
5) 編制文件
採用給表、列、觸發器等加註釋的資料庫工具。對開發、支援和跟蹤修改非常有用。
對資料庫文件化，或者在資料庫自身的內部或者單獨建立文件。這樣，當過了一年多時間後再回過頭來做第2 個版本，犯錯的機會將大大減少。
6) 測試、測試、反覆測試
建立或者修訂資料庫之後，必須用使用者新輸入的資料測試資料欄位。最重要的是，讓使用者進行測試並且同使用者一道保證選擇的資料型別滿足商業要求。測試需要在把新資料庫投入實際服務之前完成。
7) 檢查設計
在開發期間檢查資料庫設計的常用技術是通過其所支援的應用程式原型檢查資料庫。換句話說，針對每一種最終表達資料的原型應用，保證你檢查了資料模型並且檢視如何取出資料。