1.總覽數(shù)據(jù)庫的生命周期

1.1 需求分析階段

分析用戶需求，是整個數(shù)據(jù)庫設計的基礎。

階段產(chǎn)出：

①分析用戶活動，產(chǎn)生業(yè)務流程圖。

②確定系統(tǒng)范圍，產(chǎn)生系統(tǒng)關聯(lián)圖。

③分析用戶活動涉及的數(shù)據(jù)，產(chǎn)生數(shù)據(jù)流圖。

④分析系統(tǒng)數(shù)據(jù)，產(chǎn)生數(shù)據(jù)字典。數(shù)據(jù)字典包括數(shù)據(jù)項、數(shù)據(jù)結構、數(shù)據(jù)流、數(shù)據(jù)存儲和處理過程5個部分。

1.2 概念設計階段

通過對用戶需求的集成、歸納和抽象，形成一個獨立于數(shù)據(jù)庫管理系統(tǒng)的概念模型。

階段產(chǎn)出：

ER實體模型

1.3 邏輯設計階段

將概念結構轉換為DBMS支持的數(shù)據(jù)模型，將ER模型轉換為關系模型。

階段產(chǎn)出：

關系模型

1.4 物理設計階段

為關系模型選擇最適合應用程序環(huán)境的物理結構（包括存儲結構和存取方法）。

階段產(chǎn)出：

包括存儲結構和存取方法的物理結構

1.5 數(shù)據(jù)庫實現(xiàn)階段

根據(jù)邏輯設計和物理設計的階段產(chǎn)出，使用數(shù)據(jù)庫管理系統(tǒng)提供的數(shù)據(jù)語言、工具和主機語言，建立數(shù)據(jù)庫，編寫調試應用程序，組織數(shù)據(jù)倉庫，并進行試運行。

1.6 數(shù)據(jù)庫運營與維護

數(shù)據(jù)庫應用系統(tǒng)經(jīng)過試運行后即可投入正式運行。
在數(shù)據(jù)庫系統(tǒng)運行過程中必須不斷地對其進行評價、調整與修改。

2.邏輯設計階段

2.1?認識各種鍵\碼

首先得明白一點，鍵即是碼，如主鍵=主碼，外鍵=外碼等等，因此以下都稱為碼。

①候選碼：能夠唯一標識一條記錄的最小屬性集合，注意最小最小最小，并且一張表中候選碼不止一個。

②全碼：當表中所有的屬性共同構成一個候選碼時，這時稱該候選碼為全碼。

③主碼：從若干個候選碼中選擇一個為主碼，隨你喜好，但是最好符合人類閱讀習慣。

④外碼：將本表（表1）中的某屬性與另一張表（表2）中的主碼關聯(lián)在一起，則該屬性稱為外碼。并且要注意，在為表1添加外碼項數(shù)據(jù)時，添加的屬性值必須是表2主碼中屬性值里有的值。

2.2?將ER實體圖中每個強實體、弱實體的屬性分列

分列過程是為了使表逐一符合第一范式、第二范式、第三范式、BC范式、第四范式、第五范式。

一般數(shù)據(jù)庫設計只需符合第三范式就足夠了。

①第一范式（1NF）要求：關系模型表中每列都是最基本的數(shù)據(jù)項，不可再分，每列中不能出現(xiàn)兩個值。

②第二范式（2NF）要求：設置主碼，關系模型中不存在非主屬性對主碼的部分依賴。

問1：什么是非主屬性？

答1：非主屬性是相對于主屬性來定義的，是指該關系中不包含在任何一個候選碼中的屬性。

問2：什么是部分依賴？

答2：若關系中主碼為(a,b)，存在非主屬性c，函數(shù)依賴集中存在b一>c或a—>c，就稱c部分依賴于(a,b)。

③第三范式（3NF）要求：關系模型中不存在非主屬性對主碼的傳遞依賴。

問1：什么是傳遞依賴？??

答1：若關系中主碼為(a,b)，存在非主屬性c、d，函數(shù)依賴集中存在(a,b)—>c與c一>d，就稱d傳遞依賴于(a,b)。

④BC范式（BCNF）要求：關系模型中不存在任何屬性（包括主屬性）對主碼的傳遞依賴與部分依賴。

⑤第四、第五范式不介紹，將關系模型分太多列屬性反而會降低向數(shù)據(jù)庫中添加\刪除數(shù)據(jù)的效率。

2.3 例題

下表捕獲了有關電子商務書店的以下事實：名為EmpName、ID為EmpID的員工已在ShippedDate日期將訂單（訂單號為OrderNo）發(fā)送到地址ShipToAddr。裝運的跟蹤號為TrackingNum。TrackingNum由提貨的快遞公司提供。書店只使用一家快遞公司。請注意，單個訂單可以根據(jù)所訂購項目的可用性分為多個裝運。只有一名員工處理一批貨物。但是，如果訂單分多次發(fā)貨，則多個員工可以處理訂單。

（以上為翻譯，原題：The following table captures the following fact about an E-Commerce bookstore: the employee whose name is EmpName and whose ID is EmpID has shipped the order (whose Order Number is OrderNo) to the address ShipToAddr on the date ShippedDate. The tracking number for the shipment is TrackingNum. The TrackingNum is provided by the courier company that picks up the shipment. The bookstore uses only one courier company. Note that a single order could be split up into multiple shipments based on the availability of the ordered items. Only one employee handles a shipment. However, multiple employees could handle an order if the order is shipped in multiple shipments.）

1.列出主鍵。

2.列出所有FD。

3.列出所有更新異常并提供每個異常的示例。

4.這種關系的范式是什么？解釋一下。

5.逐步對其應用規(guī)范化，使關系達到3NF。也就是說，如果關系是非規(guī)范化的，則將其轉換為第一個范式，然后將剛剛創(chuàng)建的第一個范式轉換為第二個范式，然后將第二個范式轉換為第三個范式。

答：

1.列出主鍵：TrackingNum.

2.列出所有FD.。
EmpID->EmpName
OrderNo->ShipToAddr,ShippedDate
TrackingNum->EmpID,OrderNo

3.列出所有更新異常并提供每個異常的示例。
插入異常：在插入新的訂單數(shù)據(jù)時還必須插入員工的數(shù)據(jù)（如插入訂單223信息時還需插入ID為1234，名為Joe的員工信息）
刪除異常：在刪除訂單224時還必須刪除ID為2134，名為Jones的員工信息。
更新異常：用戶在更改訂單223的地址時還需要更新224的地址。

4.這種關系的范式是什么？解釋一下。
符合第二范式
數(shù)據(jù)庫表的每一列(即每個屬性)都是不可分割的基本數(shù)據(jù)項，同一列中沒有多個值，即實體中的某個屬性沒有多個值。故符合第一范式。
數(shù)據(jù)庫表中的屬性不存在非主屬性對主碼的部分依賴，故符合第二范式。
數(shù)據(jù)庫表中的關系還存在非主屬性對主碼的傳遞依賴，不符合第三范式。
綜上，表處于第二范式階段。

5.逐步對其應用規(guī)范化，使關系達到3NF。也就是說，如果關系是非規(guī)范化的，則將其轉換為第一個范式，然后將剛剛創(chuàng)建的第一個范式轉換為第二個范式，然后將第二個范式轉換為第三個范式。
依據(jù)現(xiàn)有的FDs將表拆分成三個表
1.Employee(EmpID,EmpName)
????????primary key:EmpID
????????FDs:EmpID->EmpName
2.Order(OrderNo,ShipToAddr,ShippedDate)
????????primary key:OrderNo
????????FDs:OrderNo->ShipToAddr
????????????????OrderNo->ShippedDate
3.Shipment(TrackingNum,EmpID,OrderNo)
????????primary key:TrackingNum
????????FDs:TrrackingNum->OrderNo
????????????????TrackingNum->EmpID
以上三個關系模式中都沒有非主屬性對主碼的傳遞依賴，故符合第三范式。

總結

以上是生活随笔為你收集整理的数据库之逻辑设计阶段（候选码、主码、外码、范式…）的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內容還不錯，歡迎將生活随笔推薦給好友。