【正文】 示實體，帶陰影的實體表示表。圖35 所示矩形表示的設備實體，圖36 所示矩形表示設備表，鑰匙標記表示的是表的鍵。圖35 設備實體Flgure 35 EqulPment entlty 圖36 設備表Flgure 36 EqulPment table 圖34 所示的數(shù)據(jù)模型中所有的實體，均按照這種方式轉(zhuǎn)變?yōu)楸恚D(zhuǎn)換后的所有表如附錄一所示。 主關鍵字的選擇選擇主關鍵字非常重要。DBMS 利用主關鍵字優(yōu)化表的搜索和排序，還有一些DBMS 產(chǎn)品利用它來組織表的存儲。理想的主關鍵字的特點是短的、數(shù)字型的。本文中，有的表的主關鍵字滿足理想關關鍵字字的特點，有的表則不滿足理想關關鍵字字的特點，本文所有表的主鍵全部采用強制關鍵字。強制關關鍵字字是DBMS 維護的標記唯一行的列。在表中的值是唯一的，并且是永遠不會改變的。當添加行時，自動為強制關關鍵字字生成一個值；當一行刪除時，這個值被刪除。強制第三章系統(tǒng)數(shù)據(jù)庫設計關關鍵字字是最好的主關鍵字，因為它滿足理想主關鍵字應有的特點。除了上述優(yōu)點，強制關關鍵字字還可以簡化關于最小粒度的操作。如附錄二所示，由于聯(lián)系人、點檢項目、借閱、資料、報價和班次實體是ID 依賴實體，故其轉(zhuǎn)換表采用強制關鍵字后，其父實體轉(zhuǎn)換表的相應關鍵字要去除。聯(lián)系人表去除了供貨商名稱屬性；點檢項目表去除了設備編號屬性；借閱表去除了設備編號和資料名稱屬性；報價表去除了供貨商名稱、生產(chǎn)廠家名稱和備件型號屬性；班次表去除了設備編號屬性；資料表去除了設備編號屬性。 明確候選關鍵字下一步是明確候選關鍵字。候選關鍵字是可選的標識符，用來標識表中行的唯一性，所以，對于有候選關鍵字的表，要設置候選關鍵字。設置候選關鍵字后的表如附錄三所示。在ERWin 中，使用術語alternate key ( AK ）來表示候選關鍵字。標記AKh . m 表示第n 個候選關鍵字的第m 列。 明確列的屬性數(shù)據(jù)庫設計除了以上步驟外，下一步是明確列的屬性。有四個屬性：Null status 、data type de ］認lltvahie 和dataconstraint 。因表的數(shù)量很多，為避免文章冗長，此處僅以個別表為例，來說明列屬性的設置。1 ) Null 3atus Null StatuS 表示這一列是否允許null 值出現(xiàn)。一般情況下，如果選擇NULL ，則允許出現(xiàn)null 值；選擇NOT NULL 則不允許出現(xiàn)nun 值。設備表的Null Statils 屬性設置如圖37 所示：圖37 顯示設備表中每個列的Null Status 取值Figure 37 Show Null Status ofeachrow inequlPmenttable 2 ) D 擻a Type 下一步是設置每一列的數(shù)據(jù)類型。設備表每一列的數(shù)據(jù)類型如圖38 所示。圖38 顯示設備表的數(shù)據(jù)類型Flgure 38 Sh 倆the datatype ofequlPmenttable 第三章系統(tǒng)數(shù)據(jù)庫設計3 ) Default Value Defauk 磕hie （默認值）是當DBMS 創(chuàng)建一個新的行時，為某些列自動設定的值?？梢栽O定常數(shù)，也可以是一個函數(shù)結果?？梢允褂媒９ぞ邅碛涗浤J值，但通常寫在一個另外的文件中，表17 就是使用這種方式記錄了設備表的默認值。表17 設備表默認值Table 17 The defaUlt vahie ofequlPmenttable 4 ) Data Constraint 數(shù)據(jù)限制（Data constramt ）用來限制數(shù)據(jù)的取值。有幾種類型。域限制（Domain constraint ) 限制只可以取被允許的幾個值。范圍限制（Domain constramt ）限定只可以取某個范圍內(nèi)的值。Intrare 妞ion constraint 通過和一張表中的其他列比較來進行限制。Interre 妞ion constraint 通過與別的表中的列比較來進行限制。限于篇幅，這里僅簡單介紹部門表的部門名稱列的數(shù)據(jù)限制。部門名稱只可以?。邸_發(fā)部’, ‘技術部’, ‘銷售部’, ‘金工車間’, ‘飯金車間’, ‘電控車間’, ‘儲運部’, ‘生產(chǎn)部’, ‘供應部’, ‘設備部’, ‘財務部’, ‘企管部’, ‘檢驗部’, ‘工程部’1 。它屬于域限制。5 規(guī)范性驗證創(chuàng)建表的最后一步是進行規(guī)范性驗證。當根據(jù)表單或報表來設計數(shù)據(jù)模型時，設計出的實體通常是規(guī)范的，因為表單或報表的結構往往反映了用戶對數(shù)據(jù)的理解。但仍應該對表進行驗證。應考慮所有的表是否滿足BCNF 范式以及是否所有的多值依賴都被消除了。如果不滿足則應該對表進行規(guī)范化。經(jīng)驗證，本系統(tǒng)所有的表均滿足要求。3 . 3 . 2 外鍵設計表示子類型聯(lián)系的方法是將超類型表的主鍵放入子類型表中，并且使其成為子類型表的主鍵。圖39 所示的是：人員和操作人員、干部、維修人員、管理人員、點檢人員的聯(lián)系。其余子類型聯(lián)系類似，不做敖述。表列默認值設備表設備ID 強制關鍵字設備表設備編號000 一000 設備表設備名稱新設備名稱設備表設備型號Newtype 設備表制造商新制造商第三章系統(tǒng)數(shù)據(jù)庫設計圖39 把人員表的健放入其子類型表中Flgure 39 Put empfoyee table 39。 5 key into its son type table 1 : N 強實體聯(lián)系表示1 : N 強實體聯(lián)系的方法是把對應“1 ”的那端的表的鍵放到對應“N ”的那一端的表中。圖40 所示的是：操作人員和維修工作票的聯(lián)系，其余1 : N 強實體聯(lián)系類似，不做敖述。圖40 把操作人員表的健放到維修工作票表中Flgure 40 Put operator table 39。 5 key into mamtenance paper table N : M 強實體聯(lián)系表示N : M 強實體聯(lián)系的一般的方法是：建立一張交關系表，將兩個強實體表的主鍵放入其中。這張交關系表只包含外鍵，不包含用戶數(shù)據(jù)。因為交關系表的列都對應其他表的主鍵，它總是ID 依賴于它的兩個父表。圖41 所示的是：設備和備件聯(lián)系，其余N : M 強實體聯(lián)系類似，不做敖述。第三章系統(tǒng)數(shù)據(jù)庫設計圖41 把設備和備件的健放到交關系表中Flgure 41 Put sparepart andequlPmenttable 39。 skeyintoequlPment _ sparepartinttable 有關弱實體的聯(lián)系弱實體但不是ID 依賴實體的表聯(lián)系，是將兩個實體都看作強實體，將父表的鍵放入子表中。同時，要注明在數(shù)據(jù)庫程序編寫時，必須保證在插入一個子實體前，先插入一個父實體；并且，在刪除一個父實體時，必須刪除所有和它相關的子實體。圖42 所示的是：設備表和維修工作票表聯(lián)系，其余有關弱實體的聯(lián)系類似，不做敖述。圖42 把設備表的健放到維修工作票表中Flgure 42 Put equlPment table 39。 5 key into maintenance paper table 可以用兩種方法來表示1 : 1 強實體聯(lián)系：把第一張表的主鍵作為外鍵放到第二張表中或者把第二張表的主鍵作為外鍵放到第一張表中。1 ）采購申請和采購訂單聯(lián)系第三章系統(tǒng)數(shù)據(jù)庫設計采購申請實體和采購訂單實體是1 : 1 聯(lián)系，所以將采購申請編號放入采購訂單表或者將訂單編號放入采購申請表，均是可行的。但是，考慮到在實際的應用中，需要通過采購申請表進行查詢，然后用得到的采購申請ID 在采購訂單表中查找具體的信息，故將采購申請ID 作為外鍵放入采購訂單表中。另外，對于這個設計有一個限制：因為聯(lián)系是Ll 的，所以外鍵只可以出現(xiàn)一次。為了在DBMS 中反映這種唯一性，把采購訂單表的外鍵采購申請ID 定義成候選鍵。這樣做容易引起誤會，因為邏輯上，采購申請ID 并不是采購訂單的候選鍵。這里僅僅利用候選鍵的唯一性來保證聯(lián)系是Ll 的。采購申請和采購訂單的聯(lián)系如圖43 所示。圖43 把采購申請表的鍵放到采購訂單表中Figure 43 Put stock application table 39。 5 key into order form table 2 ）報價和采購申請聯(lián)系在實際的應用中，需要通過報價表進行查詢，然后用得到的報價ID 在采購申請表中查找具體的信息，故將報價作為外健放入采購申請表中。同理，為了在DBMS 中反映這種唯一性，故把采購申請表的外健定義為候選健，報價和采購申請的聯(lián)系如圖44 所示。圖44 把報價表的鍵放到采購申請表中Flgure 44 Put quotation table 39。 5 key into stock application table 6 系統(tǒng)所有表的聯(lián)系至此，我們已將系統(tǒng)中所有的表之間的聯(lián)系建立完畢，如圖45 所示。第三章系統(tǒng)數(shù)據(jù)庫設計圖45 所有表的聯(lián)系F 運ure 45 The relation ofallthetable 第三章系統(tǒng)數(shù)據(jù)庫設計3 . 3 . 3 最小粒度的設計把數(shù)據(jù)模型轉(zhuǎn)化成數(shù)據(jù)庫設計的最后一步是設計如何來保證最小粒度。聯(lián)系可以有四種類型的最小粒度：O : O , M : O , O : M , M : M 。就保證最小粒度而言，對于O : O 聯(lián)系，不需要任何而外的動作。剩下的三種聯(lián)系在數(shù)據(jù)庫的插入、更新和刪除時都會產(chǎn)生約束口6 ｝。表18 和表19 總結了用于保證最小粒度所需要的動作。表18 顯示了當父記錄必需時（M : O , M : M 聯(lián)系）所需要的動作。表19 顯示了當子記錄必需時（O : M , M : M 聯(lián)系）所需要的動作。這里，術語“動作”表示保證最小粒度的動作。表18 父記錄必需時的動作Table 18 The 留tion whenfatllerrecordisn 氏essary 表19 子記錄必需時的動作Table 19 The 留tion when son record isn 氏essary 父記錄必需時的動作當父記錄必需時，需要保證子表中的每條記錄都有一個有效的、非空的外鍵。為了達到這個目的，必須限制對父記錄的主鍵的更新和和刪除操作，以及對子記錄的外鍵的創(chuàng)建和更改操作。首先考慮父記錄。父記錄必需父表中的動作子表中的動作InSCrt 沒有動作卜獲得父記錄卜禁止更改鍵或外鍵》 更改子表中的外鍵以匹配新的值（級聯(lián)更新）卜禁止如果新的外鍵值和父表中的某個主鍵匹配，則允許dCletC 》 冊紐除子記錄（級聯(lián)刪除）》 禁止沒有動作子記錄必需父表中的動作子表中的動作InSCrt 》 獲得一個子記錄》 禁止沒有動作更改鍵或外鍵》 更改（至少一個）子記錄的外鍵卜禁止卜如果不是最后一個，則允許》 否則，找一個新的替代品或禁止dCletC 沒有動作卜如果不是最后一個則允許卜否則，找一個新的替代品或禁止第三章系統(tǒng)數(shù)據(jù)庫設計根據(jù)表18 ，當父表中要創(chuàng)建一個新的記錄時，沒有任何限制。因為這時子表中沒有任何記錄依賴于這條記錄。然而，考慮如果改變一個已存在的父記錄的主鍵。如果這條記錄有子記錄，則這些子記錄的外鍵和現(xiàn)在這條父記錄的主鍵相匹配。如果這條父記錄的主鍵被改變，則所有這些子記錄將變成“孤兒”；它們的外鍵將不再匹配父記錄。為了阻止“孤兒”的產(chǎn)生，或者父記錄改變時子記錄的外鍵也同時改變，或者禁止父記錄的主鍵改變。父記錄主鍵的改變造成子記錄外鍵改變的策略稱為級聯(lián)更新。最后，考慮刪除一條父記錄的情況。如果這條記錄有子記錄，如果這個刪除被允許，則它的子記錄將變成“孤兒”。因此，當這種刪除發(fā)生時，或者它的子記錄也被刪除；或者禁止父記錄的刪除。刪除父記錄使得子記錄被刪除的策略稱為級聯(lián)刪除。通常，對于強實體之間的聯(lián)系不會選擇級聯(lián)刪除，應該禁止這個刪除發(fā)生。為了刪除一條父記錄，應該先把它的子記錄分配一個新的外鍵值，然后再刪除這條父記錄。另一方面，對于弱實體總是應該選擇級聯(lián)刪除。 父記錄必需時子表中的動作考慮子表中的動作。如果父記錄是必需的，當一個新的子記錄被創(chuàng)建時，這條記錄必須有一個有效的外鍵值。通常有一個默認的策略來為新的子記錄分配父記錄。當在子表中創(chuàng)建一條新的記錄時，將其外鍵設置成一個默認值。關于改變外鍵的值，新的值必須和父表中某條記錄的主鍵相匹配。如果不這么做，這一改變將被禁止。通常，當父表使用強制關鍵字時，涉及更新的動作有所不同。對于父表，由于強制關鍵字不允許被改變，因此不會有更新操作發(fā)生。對于子表，如果子記錄改變到一個新的父記錄，則更新是被允許的。因此，對于父表，可以不考慮更新操作；對于子表，必須考慮。如果子記錄是必需的，則子表中的刪除沒有任何限制。 子記錄必需時的動作當子記錄必需時，我們需要保證任何時候父表中的記錄都必須有至少一條子記錄。而為了保證子記錄必需，必需計數(shù)父記錄擁有的子記錄個數(shù)。這個區(qū)別使我們要編寫額外的代碼。如果子記錄必需，我們不能創(chuàng)建沒有子記錄的父記錄。這意味著或者要在子表中選一條記錄，把它的外鍵改成父表中新記錄的主鍵；或者在子表中創(chuàng)建一條新記錄，它的外鍵等于父表中新記錄的主鍵。如果這兩個動作都不允許，則父表中新的插入動作將禁止。表19 第一行總結了這條規(guī)則。如果子記錄必需，為了更改父表中某條記錄的主鍵，或者至少它的一個子記錄的外鍵也做相應更改，或者這個更新操作被禁止。這個限制不應用于含有強制關鍵字的父表，因為它的主鍵不會被更新。最后，如果子記錄必需，父表要刪除某條記錄時，不需要任何動作。第三章系統(tǒng)數(shù)據(jù)庫設計如表19 所示，子記錄必需時，子表中插入記錄不需要任何額外的動作。然而，更新子記錄的外鍵時會有限制。如果更新的子記錄是它的父記錄的唯一一條子記錄時，這個更新將不允許發(fā)生。如果在這種情況下進行了更新，則它的父記錄就不再有子記錄，這是不允許的。因此，必須編寫一個過程來計算當前父記錄的子記錄數(shù)。如果計數(shù)大于1 ，更新被允許，否則被禁止