資料庫設計與關系理論

❶ 資料庫概述里的資料庫結構的3級模式，與關系理論中的關系模式，是否指的一個東西

不是，三級模式是指，外模式，概念模式，內模式。用戶級對應外模式，概念級對應概念模式，物理級對應內模式。關系理論的關系模式是指二維表的設計。

❷ 什麼是資料庫的概念設計、邏輯設計、物理設計，以及三者的關系

1、概念設計：

對用戶要求描述的現實世界(可能是一個工廠、一個商場或者一個學校等)，通過對其中住處的分類、聚集和概括，建立抽象的概念數據模型。這個概念模型應反映現實世界各部門的信息結構、信息流動情況、信息間的互相制約關系以及各部門對信息儲存、查詢和加工的要求等。

所建立的模型應避開資料庫在計算機上的具體實現細節，用一種抽象的形式表示出來。以擴充的實體—（E-R模型）聯系模型方法為例，第一步先明確現實世界各部門所含的各種實體及其屬性、實體間的聯系以及對信息的制約條件等，從而給出各部門內所用信息的局部描述。第二步再將前面得到的多個用戶的局部視圖集成為一個全局視圖，即用戶要描述的現實世界的概念數據模型。

2、邏輯設計：

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

3、物理設計：

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

4、三者關系：

由上到下，先要概念設計，接著邏輯設計，再是物理設計，一級一級設計。三者一環扣住一環，缺一不可，概念設計是前提，邏輯設計是紐扣，將概念設計和物理設計緊密聯系起來，物理設計的結果就是傳說中的「物理資料庫」也就是最後的結果。三者密不可分，缺一不可。

(2)資料庫設計與關系理論擴展閱讀

資料庫設計的基本步驟：

1、需求分析階段：准確了解與分析用戶需求（包括數據與處理），是整個設計過程的基礎，是最困難、最耗費時間的一步。

2、概念結構設計階段：是整個資料庫設計的關鍵,通過對用戶的需求進行綜合、歸納與抽象，形成一個獨立於具體DBMS的概念模型。從實際到理論。

3、邏輯結構設計階段：將概念結構轉換為某個DBMS所支持的數據模型,對其進行優化。優化理論。

4、資料庫物理設計階段：為邏輯數據模型選取一個最適合應用環境的物理結構（包括存儲結構和存取方法）。選擇理論落腳點。

5、資料庫實施階段：運用DBMS提供的數據語言、工具及宿主語言，根據邏輯設計和物理設計的結果,建立資料庫，編制與調試應用程序，組織數據入庫，並進行試運行。理論應用於實踐。

6、資料庫運行和維護階段：資料庫應用系統經過試運行後即可投入正式運行。在資料庫系統運行過程中必須不斷地對其進行評價、調整與修改。理論指導實踐，反過來實踐修正理論。

主要特點：

1、 實現數據共享：資料庫伺服器數據共享包含所有用戶可同時存取資料庫中的數據，也包括用戶可以用各種方式通過介面使用資料庫，並提供數據共享。

2、 減少數據的冗餘度：同文件系統相比，由於資料庫實現了數據共享，從而避免了用戶各自建立應用文件。減少了大量重復數據，減少了數據冗餘，維護了數據的一致性。

3、數據的獨立性：數據的獨立性包括邏輯獨立性（資料庫中資料庫的 邏輯結構和 應用程序相互獨立）和物理獨立性（數據物理結構的變化不影響數據的邏輯結構）。

4、數據實現集中控制：文件管理方式中，數據處於一種分散的狀態，不同的用戶或同一用戶在不同處理中其文件之間毫無關系。利用資料庫可對數據進行集中控制和管理，並通過 數據模型表示各種數據的組織以及數據間的聯系。

5、數據一致性和可維護性，以確保數據的安全性和可靠性主要包括：安全性控制：以防止數據丟失、錯誤更新和越權使用；完整性控制：保證數據的正確性、有效性和相容性；並發控制：使在同一時間 周期內，允許對數據實現多路存取，又能防止用戶之間的不正常交互作用。

6、故障恢復：由資料庫管理系統提供一套方法，可及時發現故障和修復故障，從而防止數據被破壞。資料庫系統能盡快恢復資料庫系統運行時出現的故障，可能是物理上或是邏輯上的錯誤。比如對系統的誤操作造成的數據錯誤等。

❸ 《資料庫設計與關系理論》epub下載在線閱讀全文，求百度網盤雲資源

《資料庫設計與關系理論》（戴特）電子書網盤下載免費在線閱讀

資源鏈接：

鏈接：

書名：資料庫設計與關系理論

作者：戴特

出版社：東南大學出版社

出版年份：2013-1

頁數：260

內容簡介：

《資料庫設計與關系理論(影印版)(英文版)》的每一章都包含一組練習，它或者展示了如何把理論知識應用到實踐中，或者提供了更多的信息，或者要求你驗證一些簡單的理論結果。如果你非常熟悉資料庫的關系模式，並且你希望深入了解資料庫設計，那麼此書就完全適合你。

❹ .資料庫設計分為幾個階段,各階段的任務是什麼

按照規范的設計方法，一個完整的資料庫設計一般分為需求分析、概念結構設計、邏輯結構設計、資料庫物理設計、資料庫的實施、資料庫運行與維護六個階段：

各階段的任務如下：

1、需求分析：分析用戶的需求，包括數據、功能和性能需求；

拓展資料：

資料庫設計(Database Design)是指對於一個給定的應用環境，構造最優的資料庫模式，建立資料庫及其應用系統，使之能夠有效地存儲數據，滿足各種用戶的應用需求(信息要求和處理要求)。在資料庫領域內，常常把使用資料庫的各類系統統稱為資料庫應用系統。

資料庫設計是建立資料庫及其應用系統的技術，是信息系統開發和建設中的核心技術。由於資料庫應用系統的復雜性，為了支持相關程序運行，資料庫設計就變得異常復雜，因此最佳設計不可能一蹴而就，而只能是一種"反復探尋，逐步求精"的過程，也就是規劃和結構化資料庫中的數據對象以及這些數據對象之間關系的過程。

❺ 關系資料庫規范化理論的基礎和內容

一個關系資料庫模式由一組關系模式組成，一個關系模式由一組屬性名組成。關系資料庫設計，就是如何把已給定的相互關聯的一組屬性名分組，並把每一組屬性名組成關系的問題。然而，屬性的分組不是唯一的，不同的分組對應著不同的資料庫應用系統，它們的效率往往相差很遠。
為了使資料庫設計合理可靠，簡單實用，長期以來，形成了關系資料庫設計的理論——規范化理論。
6.1 關系規范化的作用
規范化，就是用形式更為簡潔，結構更加規范的關系模式取代原有關系模式的過程。
如果將兩個或兩個以上實體的數據存放在一個表裡，就會出現下列三個問題：
Ø 數據冗餘度大
Ø 插入異常
Ø 刪除異常
所謂數據冗餘，就是相同數據在資料庫中多次重復存放的現象。數據冗餘不僅會浪費存儲空間，而且可能造成數據的不一致性。
插入異常是指，當在不規范的數據表中插入數據時，由於實體完整性約束要求主碼不能為空的限制，而使有用數據無法插入的情況。
刪除異常是指，當不規范的數據表中某條需要刪除的元組中包含有一部分有用數據時，就會出現刪除困難。
（以P98工資表為例）
解決上述三個問題的方法，就是將不規范的關系分解成為多個關系，使得每個關系中只包含一個實體的數據。
（講例子解）
當然，改進後的關系模式也存在另一問題，當查詢職工工資時需要將兩個關系連接後方能查詢，而關系連接的代價也是很大的。
那麼，什麼樣的關系需要分解？分解關系模式的理論依據又是什麼？分解完後能否完全消除上述三個問題？回答這些問題需要理論指導。下面，將加以討論：

6.2 函數依賴

6.2.1屬性間關系

實體間的聯系有兩類：一類是實體與實體之間聯系；另一類是實體內部各屬性間的聯系。資料庫建模一章中討論的是前一類，在這里我們將學習第二類。

和第一類一樣，實體內部各屬性間的聯系也分為1:1、1:n和m:n三類：

例：職工（職工號，姓名，身份證號碼，職稱，部門）

1、 一對一關系（1:1）

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

如本例職工關系中職工號與身份證號碼之間就是一對一關系。

2、一對多關系（1:n）

設X、Y是關系R的兩個屬性（集）。如果對於X中的任一具體值，Y中可以找到多個值與之對應，而對於Y中的任一具體值，X中至多隻有一個值與之對應，則稱屬性X對Y是一對多關系。

如職工關系中職工號與職稱之間就是一對多的關系。

3、多對多關系（m:n）

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

例如，職工關系中，職稱與部門之間就是多對多的關系。

上述屬性間的三種關系，實際上是屬性值之間相互依賴與相互制約的反映，因而稱之為屬性間的數據依賴。

數據依賴共有三種：

Ø 函數依賴（Functional Dependency，FD）

Ø 多值依賴（Multivalued Dependency，MVD）

Ø 連接依賴（Join Dependency，JD）

其中最重要的是函數依賴和多值依賴。

6.2.2 函數依賴

函數依賴，是屬性之間的一種聯系。在關系R中，X、Y為R的兩個屬性或屬性組，如果對於R的所有關系r 都存在：對於X的每一個具體值，Y都只有一個具體值與之對應，則稱屬性Y函數依賴於屬性X。或者說，屬性X函數決定屬性Y，記作X→Y。其中X叫作決定因素，Y叫作被決定因素。

上述定義，可簡言之：如果屬性X的值決定屬性Y的值，那麼屬性Y函數依賴於屬性X。換一種說法：如果知道X的值，就可以獲得Y的值，則可以說X決定Y。

若Y函數不依賴於X，記作：X→Y。

X Y

若X→Y，Y→X，記作：

前面學習的屬性間的三種關系，並不是每種關系中都存在著函數依賴。

u 如果X、Y間是1:1關系，則存在函數依賴 X←→Y

u 如果X、Y間是1:n關系，則存在函數依賴： X→Y或Y→X（多方為決定因素）

u 如果X、Y間是m:n關系，則不存在函數依賴。

注意，屬性間的函數依賴不是指R的某個或某些關系子集滿足上述限定條件，而是指R的一切關系子集都要滿足定義中的限定。只要有一個具體的關系r（R的一個關系子集）不滿足定義中的條件，就破壞了函數依賴，使函數依賴不成立。

這里的關系子集，指的是R的某一部分元組的集合，例如：地測學院的學生關系中只包含了地測學院學生的數據，所以它是長安大學學生關系的一個子集。

6.2.3 碼的定義

前面，我們對碼進行了直觀化的定義，下面用函數依賴的概念對碼作出較為精確的形式化的定義：

設K是關系模式R（U，F）中的屬性或屬性組，K』是K的任一子集。若K→U，而不存在K』→U，則K為R的候選碼（Candidate Key）

Ø 若候選碼多於一個，則選其中的一個為主碼（Primary Key）；

Ø 包含在任一候選碼中的屬性，叫做主屬性（Primary Attribute）；

Ø 不包含在任何碼中的屬性稱為非主屬性（Nonprime Attribute）或非碼屬性（Nonkey Attribute）

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

前面已多次遇到單碼的情況，下面是一個全碼的例子：

簽約（演員名，製片公司，電影名）

外碼：設有兩個關系R和S，X是R的屬性或屬性組，並且X不是R的碼，但X是S的碼（或與S的碼意義相同），則稱X是R的外部碼（Foreign Key），簡稱外碼或外鍵。

如：職工（職工號，姓名，性別，職稱，部門號）

部門（部門號，部門名，電話，負責人）

其中職工關系中的「部門號」就是職工關系的一個外碼。

在此需要注意，在定義中說X不是R的碼，並不是說X不是R的主屬性，X不是碼，但可以是碼的組成屬性，或者是任一候選碼中的一個主屬性。

如：學生（學生號，姓名，性別，年齡…）

課程（課程號，課程名，任課老師…）

選課（學生號，課程號，成績）

在選課關系中，（學生號，課程號）是該關系的碼，學生號、課程號又分別是組成主碼的屬性（但單獨不是碼），它們分別是學生關系和課程關系的主碼，所以是選課關系的兩個外碼。

關系間的聯系，可以通過同時存在於兩個或多個關系中的主碼和外碼的取值來建立。如要查詢某個職工所在部門的情況，只需查詢部門表中的部門號與該職工部門號相同的記錄即可。所以，主碼和外碼提供了一個表示關系間聯系的途徑。

6.2.4 函數依賴和碼的唯一性

由上述碼的形式化定義，我們可以說：碼是由一個或多個屬性組成的，可唯一標識元組的最小屬性組。

碼在關系中總是唯一的，即一個碼函數唯一地決定一行。如果碼的值重復，則整個元組都會重復。否則，違反了實體完整性規則。而元組的重復則表示存在兩個完全相同的實體，這顯然是不可能的，所以碼是不允許重復取值的。

所以，只有當某個屬性或屬性組能夠函數決定關系中的每一個其它的屬性，且該屬性組的任何一個真子集都做不到這一點時，該屬性或屬性組才是該關系的碼。

函數依賴是一個與數據有關的事物規則的概念。如果屬性B函數依賴於屬性A，那麼若知道了A的值，則完全可以找到B的值。這並非是可以由A的值計算出B的值，而是邏輯上只能存在一個B的值。

6.3 關系模式的規范化

一、非規范化的關系

當一個表中存在還可以再分的數據項時，這個表就是非規范化的表。非規范化表存在兩種情況：

Ø 表中具有組合數據項（P102表6-4）

Ø 表中具有多值數據項（P103表6-5）

例：

職工號
姓名
工資

基本工資
職務工資
工齡工資

1002
張三
1000
800
200

職工號
姓名
職稱
系名
系辦地址
學歷
畢業年份

001
張三
教授
計算機
1305
大學

研究生
1963

1982

那麼什麼是規范化關系呢？

當一個關系中的所有分量都是不可再分的數據項時，該關系是規范化的。即當表中不存在組合數據項和多值數據項，只存在不可分的數據項時，這個表是規范化的。

二維表按其規范化程度從低到高可分為5級範式（Normal Form），分別稱為1NF、2NF、3NF（BCNF）、4NF、5NF。規范化程度較高者必是較低者的子集，即：

1NF 2NF 3NF BCNF 4NF 5NF

二、第一範式（1NF）

定義1：如果關系模式R中不包含多值屬性，則R滿足第一範式（First Normal Form），記作：

R∈1NF

1NF是對關系的最低要求，不滿足1NF的關系是非規范化的關系。

非規范化關系轉化為規范化關系1NF方法很簡單，只要上表分別從橫向、縱向展開即可。如下表：

職工號
姓名
基本工資
職務工資
工齡工資

1002
張三
1000
800
200

1005
李四
1200
900
150

職工號
姓名
職稱
系名
系辦地址
學歷
畢業年份

1002
張三
教授
計算機
1305
大學
1963

1002
張三
教授
計算機
1305
研究生
1982

1005
李四
講師
信電
2206
大學
1989

上表雖然符合1NF，但仍是有問題的關系，表中存在大量的數據冗餘和潛在的數據更新異常。原因是（職工號，學歷）是右表的碼，但姓名、職稱、系名、系辦地址卻與學歷無關，只與碼的一部分有關。所以上表還需進一步地規范化。

三、第二範式（2NF）

定義1：設X、Y是關系R的兩個不同的屬性或屬性組，且X → Y。如果存在X的某一個真子集X』，使X』 → Y成立，則稱Y部分函數依賴於X，記作：X P→ Y（Partial）。反之，則稱Y完全函數依賴於X，記作：X F→ Y （Full）

定義2：如果一個關系 R∈1NF，且它的所有非主屬性都完全函數依賴於R的任一候選碼，則R屬於第二範式，記作：R∈2NF。

說明：上述定義中所謂的候選碼也包括主碼，因為碼首先應是候選碼，才可以被指定為碼。

例如關系模式：

職工（職工號，姓名，職稱，項目號，項目名稱，項目角色）中

（職工號，項目號）是該關系的碼，而職工號→姓名、職工號→職稱、項目號→項目名稱…

所以（職工號，項目號）P→ 職稱、（職工號，項目號）P→ 項目名稱

故上述職工關系不符合第二範式要求。它存在三個問題：插入異常、刪除異常和修改異常。

其中修改異常是這樣的，當職工關系中項目名稱發生變化時，由於參與該項目的人員很多，每人一條記錄，要修改項目信息，就得對每一個參加該項目的人員信息進行修改，加大了工作量，還有可能發生遺漏，存在著數據一致性被破壞的可能。

可把上述職工關系分解成如下三個關系：

職工（職工號，姓名，職稱）

參與項目（職工號，項目號，項目角色）

項目（項目號，項目名稱）

上述三個關系都符合定義2的要求，所以都符合2NF

推論：如果關系模式R∈1NF，且它的每一個候選碼都是單碼，則R∈2NF

符合第二範式的關系模式仍可能存在數據冗餘、更新異常等問題。如關系

職工信息（職工號，姓名，職稱，系名，系辦地址）

雖然也符合2NF，但當某個系中有100名職工時，元組中的系辦地址就要重復100次，存在著較高的數據冗餘。原因是關系中，系辦地址不是直接函數依賴於職工號，而是因為職工號函數決定系名，而系名函數決定系辦地址，才使得系辦地址函數依賴於職工號，這種依賴是一個傳遞依賴的過程。

所以，上述職工信息的關系模式還需要進一步的規范化。

四、第三範式（3NF）

定義1：在關系R中，X、Y、Z是R的三個不同的屬性或屬性組，如果X→Y，Y→Z， 但Y→X，且Y不是X的子集，則稱Z傳遞函數依賴於X。

定義2：如果關系模式R∈2NF，且它的每一個非主屬性都不傳遞依賴於任何候選碼，則稱R是第三範式，記作：R∈3NF

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

推論2：不存非主屬性的關系模式一定為3NF

五、改進的3NF——BCNF（Boyee－Codd Normal Form）

定義：設關系模式R（U，F）∈1NF，若F的任一函數依賴X→Y（Y X）中X都包含了R的一個碼，則稱R∈BCNF。

換言之，在關系模式R中，如果每一個函數依賴的決定因素都包含碼，則R∈BCNF

推論：如果R∈BCNF，則：

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

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

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

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

證明：（結合傳遞依賴的定義，用反證法）

注意：當R∈3NF時，R未必屬於BCNF。因為3NF比BCNF放寬了一個限制，它允許決定因素不包含碼。例如：

通訊（城市名，街道名，郵政編碼）中：

F＝｛（城市名，街道名）→郵政編碼，郵政編碼→城市名｝

非主屬性郵政編碼完全函數依賴於碼，且無傳遞依賴，故屬於3NF，但郵政編碼也是一個決定因素，而且它沒有包含碼，所以該關系不屬於BCNF。

又如：

Teaching（Student，Teacher，Course） 簡記為Teaching（S，T，C）

規定：一個教師只能教一門課，每門課程可由多個教師講授；學生一旦選定某門課程，教師就相應地固定。

F＝｛T→C，（S，C）→T,(S，T) →C｝

該關系的候選碼是（S，C）和（S，T），因此，三個屬性都是主屬性，由於不存在非主屬性，該關系一定是3NF。但由於決定因素T沒包含碼，故它不是BCNF。

關系模式Teaching仍然存在著數據冗餘問題，因為存在著主屬性對碼的部分函數依賴問題。

確切地表示：F＝｛T→C，（S，C）P→T,(S，T) P→C｝

所以Teaching關系可以分解為以下兩個BCNF關系模式：

Teacher（Teacher，Course） Student（Student，Teacher）

3NF的「不徹底」性，表現在可能存在主屬性對碼的部分依賴和傳遞依賴。

一個關系模式如果達到了BCNF，那麼，在函數依賴范圍內，它就已經實現了徹底的分離，消除了數據冗餘、插入和刪除異常。
6.4 多值依賴和第四範式

一、多值依賴（Multivalued Dependency）

課程C
教員T
參考書B

物理
李勇
普通物理學

物理
李勇
光學原理

物理
李勇
物理習題集

物理
王軍
普通物理學

物理
王軍
光學原理

物理
王軍
物理習題集

數學
李勇
數學分析

數學
李勇
微分方程

數學
李勇
高等代數

數學
張平
數學分析

數學
張平
微分方程

數學
張平
高等代數

計算數學
張平
數學分析

計算數學
張平
計算數學

計算數學
周峰
數學分析

計算數學
周峰
計算數學

課程C
教員T
參考書B

物理
李勇

王軍
普通物理學

光學原理

物理習題集

數學
李勇

張平
數學分析

微分方程

高等代數

計算數學
張平

周峰
數學分析

計算數學

例：學校中某一門課程由多個教員講授，他們使用相同的一套參考書，每個教員可以講授多門課程，每種參考書可以供多門課程使用。下列是用一個非規范化的表來表示教員T，課程C和參考書B之間的關系。

把上表變換成一張規范化的二維表Teaching，如右表

關系模式Teaching（C，T，B）的碼是（C，T，B），即All－Key。因而Teaching∈BCNF。按照上述語義規定，當某門課程增加一名講課教員時，就要向Teaching表中增加與相應參考書等數目的元組。同樣，某門課程要去掉一本參考書時，則必須刪除相應數目的元組。

對數據的增、刪、改很不方便，數據的冗餘也十分明顯。如果仔細考察這類關系模式，會發現它具有一種稱之為多值依賴的數據依賴關系。

定義：設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。――

例如，在關系模式Teaching中，對於一個（C，B）值（物理，普通物理學），有一組T值｛李勇，王軍｝，而這組值僅僅決定於課程C上的值（物理）。即對於另一個（物理，光學原理），它對應的T值仍然是｛李勇，王軍｝，所以T的值與B的值無關，僅決定於C的值，即C→→T 。

多值依賴的另一個等價的形式化定義為：

設關系模式R（U），X、Y、Z是U的子集，Z＝U-X-Y，r是R的任意一個關系，t1、t2是r的任意兩個元組。如果t1[X]=t2[X]，並在r中存在兩個元組t3、t4，使得：

t3[X]=t4[X]=t1[X]

t3[Y]=t1[Y]，t3[Z]=t2[Z]，

t4[Y]=t2[Y]，t4[Z]=t1[Z]

成立，則X→→Y。

換句話說：如果X→→Y在R（U）中成立，則只要在R的任一關系r中存在兩個元組t1、t2在X屬性上的值相等，則交換這兩個元組在Y（或Z）上的值後得到的兩個新元組t3、t4也必是關系r中的元組。

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

多值依賴具有如下性質：

1. 對稱性：若X→→Y，則X→→Z，其中Z＝U-X-Y

2. 傳遞性：若X→→Y，Y→→Z，則X→→Z-Y

3. 若X→→Y，X→→Z，則X→→YZ

4. 若X→→Y，X→→Z，則X→→Y∩Z

5. 若X→→Y，X→→Z，則X→→Y-Z，X→→Z-Y

多值依賴與函數依賴相比，具有下面兩個基本區別：

（1）多值依賴的有效性與屬性集的范圍有關

若X→→Y在U上成立，則在V（XY V U）上一定成立；反之則不然，即X→→Y在V(V U)上成立，在U上並不一定成立。這是因為多值依賴的定義中不僅涉及屬性組X、Y，而且涉及U中的其餘屬性Z（Z＝U-X-Y）。

一般地說，在R（U）上若有X→→Y在V（V U）上成立，則稱X→→Y為R（U）的嵌入型多值依賴。

而在關系模式R（U）中函數依賴X→Y的有效性，僅決定於X和Y這兩個屬性集的值。只要在R（U）的任何一個關系r中，元組在X和Y上的值使得X→Y成立，則X→Y在任何屬性集V（XY V U）上也成立。

（2）若函數依賴X→Y在R（U）上成立，則對於任何Y』 Y 均有X→Y』 成立。而多值依賴X→→Y若在R（U）上成立，卻不能斷言對於任何Y』 Y有X→→Y』 成立。

多值依賴的約束規則：在具有多值依賴的關系中，如果隨便刪去一個元組，就會破壞其對稱性，那麼，為了保持多值依賴關系中的「多值依賴」性，就必須刪去另外的相關元組以維持其對稱性。這就是多值依賴的約束規則。目前的RDBMS尚不具有維護這種約束的能力，需要程序員在編程中實現。

函數依賴可看成是多值依賴的特例，即函數依賴一定是多值依賴。而多值依賴則不一定就有函數依賴。

二、第四範式（4NF）

定義：如果關系模式R∈1NF，對於R的每個非平凡的多值依賴X→→Y（Y X），X含有碼，則稱R是第四範式，即R∈4NF

課程C
教員T
參考書B

物理
李勇
普通物理學

物理
李勇
光學原理

物理
李勇
物理習題集

物理
王軍
普通物理學

物理
王軍
光學原理

物理
王軍
物理習題集

數學
李勇
數學分析

數學
李勇
微分方程

數學
李勇
高等代數

數學
張平
數學分析

數學
張平
微分方程

數學
張平
高等代數

計算數學
張平
數學分析

計算數學
張平
計算數學

計算數學
周峰
數學分析

計算數學
周峰
計算數學

Teaching關系

關系模式R∈4NF時，R中所有的非平凡多值依賴實際上就是函數依賴。因為每一個決定因素中都含有碼，所以R一定屬於BCNF。

4NF實際上就是限制關系模式的屬性間不允許有非平凡，而且非函數依賴的多值依賴存在。反過來說，4NF所允許的非平凡多值依賴實際上是函數依賴。

例題中的Teaching關系屬於BCNF，但它不屬於4NF。因為它的碼是（C，T，B），關系中存在非平凡多值依賴C→→T ，C→→B，但C不包含碼，而只是碼的一部分。

課程C
參考書B

物理
普通物理學

物理
光學原理

物理
物理習題集

數學
數學分析

數學
微分方程

數學
高等代數

計算數學
數學分析

計算數學
計算數學

CB關系

課程C
教員T

物理
李勇

物理
王軍

數學
李勇

數學
張平

計算數學
張平

計算數學
周峰

CT關系

要使Teaching關系符合4NF，必須將其分解為CT（C，T）和CB（C，B）兩個關系模式。如右表：

從表中顯而易見，符合BCNF的關系Teaching仍然存在著數據冗餘，而分解後的關系CT和CB中只有平凡多值依賴，所以符合4NF，它們已經消除了數據冗餘。可以說：BCNF是在只有函數依賴的關系模式中，規范化程度最高的範式，而4NF是在有多值依賴的關系模式中，規范化程度最高的範式。

如果關系模式中存在連接依賴，即便它符合4NF，仍有可能遇到數據冗餘及更新異常等問題。所以對於達到4NF的關系模式，還需要消除其中可能存在的連接依賴，才可以進一步達到5NF的關系模式。

關於連接依賴和5NF的內容，已超出了本課程教學大綱的要求，在此不再介紹。

❻ 關系資料庫設計理論主要包括幾個方面的內容,其中起核心作用的是什麼

關系資料庫設計理論主要包括三個方面內容,其中起核心作用的是數據依賴。

❼ 資料庫設計中，關系模式的規范化理論是應用在什麼階段

資料庫 data base 為滿足某一部門中多個用戶多種應用的需要，按照一定的數據模型在計算機系統中組織、存儲和使用的互相聯系的數據集合。 帶有資料庫的計算機系統，除具備一般的硬體、軟體外，必須有用以存儲大量數據的直接存取存儲設備、管理並...

❽ SQL關系資料庫設計理論中提到的超健和候選鍵的概念怎麼理解，很抽象。

超鍵就是指一組欄位可以唯一確定一條數據，而候選鍵是最簡潔的超鍵，也就是只有必要欄位，
舉例來說明，假如有一個班級，班級中沒有同名的學生，有如下一張表。
std_id last_name first_name gender score
10001 張 三 男 85
10002 李 四 男 86
10005 妹 子 女 95
10006 李 三 男 88
這張表裡，因為我們前面說到這個班級里沒有同名的學生。
因此last_name+first_name就是一個超鍵，因為可以唯一確定一行數據，同時也是一個候選鍵，因為這兩個欄位去掉任何一個都不再能唯一確定一行數據。
更明顯的區別在於，last_name+first_name+gender還是一個超鍵，但是已經不再是候選鍵了，因為在確定唯一一條數據的時候，gender不是必要的欄位。
也就是說候選鍵是可以唯一確定一條數據的必要欄位的最小集合，而候選鍵加上任何的額外欄位都是超鍵。
在上面的例子中，std_id自己就是一個候選鍵，std_id+任何額外的欄位都是候選鍵。
同時從習慣而言，一般會把這種std_id欄位定義為主鍵，主鍵並不一定只是一個欄位，如果我們上面的表增加一列班級id(class_id)，同時加入每個班級中的std_id都是從10001開始的話，我們就可以用class_id+std_id來作為主鍵。
自己的理解，希望可以幫到題主。

❾ 在關系資料庫設計理論中,起核心作用的是什麼

資料庫 data base 為滿足某一部門中多個用戶多種應用的需要，按照一定的數據模型在計算機系統中組織、存儲和使用的互相聯系的數據集合。 帶有資料庫的計算機系統，除具備一般的硬體、軟體外，必須有用以存儲大量數據的直接存取存儲設備、管理並控制資料庫的軟體——資料庫管理系統(DBMS)、管理資料庫的人員——資料庫管理員 (DBA)。這樣的數據、硬體、軟體和管理人員的總體構成資料庫系統。資料庫僅是資料庫系統的一個組成部分。 資料庫系統的功能和特徵 資料庫系統由文卷系統發展而來。與文卷系統相比，這種系統具有數據、體系和控制三個方面的主要特徵。 數據特徵 在文卷系統中雖然程序與數據之間可用存取方法進行轉換,但文卷還是與應用程序對應的,即數據仍面向應用。每一應用各自建立自己的一組文卷。不同的應用若涉及相同的數據，則這些數據分別納入各自的文卷之中。文卷的各種記錄之間沒有建立聯系，因而數據冗餘度大。增加新的應用，必須同時增加新的文卷。因此，文卷系統中的文卷是無結構的、不易擴充的信息集合。資料庫則不僅描述數據本身，而且描述數據之間的聯系。它的數據結構反映了某一部門的整體信息結構，數據冗餘度小、易於擴充新的應用，因而是面向數據總體結構的信息集合，可為多個用戶共享。 體系特徵 一切數據都有邏輯和物理兩個側面。在資料庫系統中，數據邏輯結構的描述稱為邏輯模式。邏輯模式又分為描述全局邏輯結構的全局模式(簡稱模式)和描述某些應用所涉及的局部邏輯結構的子模式。數據物理結構的描述稱為存儲模式。這兩種模式總稱為資料庫模式。 資料庫系統中，用戶根據子模式編製程序。子模式與模式模式與存儲模式之間有軟體進行映射。因此,程序與數據之間具有兩級獨立性：物理獨立性和邏輯獨立性。數據的存儲模式改變，而模式可以不改變，因而不必改寫應用程序,這稱為物理獨立性。模式改變時,子模式可能不改變，也就不必改寫應用程序，這稱為邏輯獨立性。由於資料庫系統具備比較高的程序與數據的獨立性，可以使程序員在編制應用程序時集中精力考慮演算法邏輯，不必過問物理細節，而且可以大大減少應用程序維護的工作量。 控制特徵 資料庫數據數量龐大，結構復雜，又為多個用戶所共享。因此，必須由資料庫管理系統在定義、建立、運行以及維護時進行統一管理和控制，以保證資料庫數據的安全性、完整性和並發操作的一致性。此外，還必須有資料庫管理員專門負責對資料庫的管理、控制監督和改進。 由於資料庫系統具有上述特徵，它的出現使信息系統的研製從圍繞加工數據的程序為中心，轉變到圍繞共享的資料庫來進行。這便於數據的集中管理，有利於應用程序的研製和維護。數據減少了冗餘度和提高了相容性，從而提高了作出決策的相容性。因此，大型復雜的信息系統大多以資料庫為核心，資料庫系統在計算機應用中起著越來越重要的作用。 研究課題 資料庫研究的課題，主要涉及三個領域。 資料庫管理系統軟體的研製 DBMS是資料庫系統的基礎。研製DBMS的基本目標，是擴大功能，提高性能和可用性，從而提高用戶的生產率。70年代以來，研製的重點是探索關系資料庫管理系統的設計，內容包括關系數據語言、查詢優化、並發控制和系統性能等。另一類課題是對DBMS標准化的研究，即研究一個統一的DBMS體系結構的規范。 資料庫設計 這是在計算機系統具有的資料庫管理系統的基礎上，按照應用要求以及計算機系統所提供的數據模型和功能，設計一個結構良好、使用方便、效率較高的，以資料庫為核心的應用信息系統。這一領域主要的研究課題，是資料庫設計方法學和設計工具的探索。例如，運用軟體工程的方法和工具指導資料庫設計；研究資料庫設計各個階段中完備的方法和工具；以關系資料庫的規范化理論為指南進行資料庫邏輯設計等。 資料庫理論 主要研究關系資料庫理論。關系資料庫理論研究的意義，一方面在於它為資料庫學科奠定了理論基礎;另一方面它為資料庫設計提供了判別標准,從而成為資料庫設計的有力指南。研究的主要內容是關系的規范化理論。關系規范化理論已應用於資料庫設計的各個階段。 發展 資料庫技術是計算機科學中發展最快的領域之一，新的領域越來越多。 分布式資料庫系統 隨著70年代後期分布計算機系統的發展，相應地研究成功分布式資料庫系統。分布式資料庫系統是一個在邏輯上完整，而在物理上分散在若乾颱互相連接的結點機上的資料庫系統。它既具有分布性又具有資料庫

❿ 如何進行資料庫的設計

資料庫設計(Database Design)是指對於一個給定的應用環境，構造最優的資料庫模式，建立資料庫及其應用系統，使之能夠有效地存儲數據，滿足各種用戶的應用需求（信息要求和處理要求）。

在資料庫領域內，常常把使用資料庫的各類系統統稱為資料庫應用系統。

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

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

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

四、資料庫設計的基本步驟
資料庫設計的過程(六個階段)
1.需求分析階段
准確了解與分析用戶需求（包括數據與處理）
是整個設計過程的基礎，是最困難、最耗費時間的一步
2.概念結構設計階段
是整個資料庫設計的關鍵
通過對用戶需求進行綜合、歸納與抽象，形成一個獨立於具體DBMS的概念模型
3.邏輯結構設計階段
將概念結構轉換為某個DBMS所支持的數據模型
對其進行優化
4.資料庫物理設計階段
為邏輯數據模型選取一個最適合應用環境的物理結構（包括存儲結構和存取方法）
5.資料庫實施階段
運用DBMS提供的數據語言、工具及宿主語言，根據邏輯設計和物理設計的結果
建立資料庫，編制與調試應用程序，組織數據入庫，並進行試運行
6.資料庫運行和維護階段
資料庫應用系統經過試運行後即可投入正式運行。
在資料庫系統運行過程中必須不斷地對其進行評價、調整與修改
設計特點:
在設計過程中把資料庫的設計和對資料庫中數據處理的設計緊密結合起來將這兩個方面的需求分析、抽象、設計、實現在各個階段同時進行，相互參照，相互補充，以完善兩方面的設計

設計過程各個階段的設計描述：
如圖：

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

六、資料庫設計技巧

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

2. 表和欄位的設計（資料庫邏輯設計）
表設計原則
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) 增加刪除標記欄位
在表中包含一個「刪除標記」欄位，這樣就可以把行標記為刪除。在關系資料庫里不要單獨刪除某一行；最好採用清除數據程序而且要仔細維護索引整體性。

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

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

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

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