曝光臺 注意防騙 網曝天貓店富美金盛家居專營店坑蒙拐騙欺詐消費者

10
圖 2.5 事件處理實體聯系簡圖
本階段設計出的ER 數據模型是聯系現實世界和計算機世界的一個信息表示
橋梁，它不但用于數據庫的后續設計(邏輯設計和物理設計)，而且也是與用戶交
流和數據庫移植的重要資料。
2.4 邏輯結構設計
數據庫邏輯結構設計階段的主要任務是將概念結構設計的結果(ER 模型)轉
換為某個DBMS 所支持的數據模型(例如關系模型), 并對其進行規范化和優化。
設計邏輯結構應該選擇最適于描述與表達相應概念結構的數據模型, 然后選擇
最合適的DBMS。目前，關系數據庫理論已經發展的十分成熟。大型關系數據庫
管理系統如ORACLE9i，DB2，SYBASE，SQL SERVER2000 等在各行業內應用廣泛，
這些系統具有管理方便、檢索速度快、存取效率高、安全性性好、存儲空間的
利用率高等優點，適合大規模數據的存儲和處理。所以在邏輯結構設計階段，
我們通常把ER 數據模型轉換成關系模型。
2.4.1 ER 模型轉換為關系模型
將ER 模型轉換為關系模型實際上就是將實體、實體的屬性和實體之間的聯
系都轉換為關系模式, 這種轉換一般遵循如下原則:
(1) 一個實體型轉換為一個關系模式。實體的屬性就是關系的屬性，實體的
碼就是關系的碼。
(2) 一個1: 1 聯系可以轉換為一個獨立的關系模式, 也可以與任意一端對
應的關系模式合并。
(3) 一個1: n 聯系可以轉換為一個獨立的關系模式, 也可以與n 端對應的
關系模式合并。如果轉換為一個獨立的關系模式, 則與該聯系相連的各實體的
11
碼以及聯系本身的屬性均轉換為關系的屬性, 而關系的碼為n 端實體的碼。
(4) 一個m: n 聯系轉換為一個關系模式。與該聯系相連的各實體的碼以及
聯系本身的屬性均轉換為關系的屬性。而關系的碼為各實體碼的組合。
(5) 三個或三個以上實體間的一個多元聯系轉換為一個關系模式。與該多元
聯系相連的各實體的碼以及聯系本身的屬性均轉換為關系的屬性。而關系的碼
為各實體碼的組合。
利用該轉換原則將(圖 2.4)所示的ER 模型轉換為關系模式，同時定義主鍵和
外鍵：
** 對救援小組進行編號并轉換
(1) 救援小組rg [小組編號，名稱，任務概述]
** 對資源進行分類并編號并轉換
(2) 資源類別rs [資源類別編號，資源類別名稱]
** 對救援單位進行轉換
(3) 救援單位ru [單位名，聯系人，聯系電話，移動電話，位置X，位置Y，
標志，備注] 說明：作為主鍵，單位名一定要寫詳細，如果需要就精確到部門。
標志：1-公司內部單位，2-協議救援單位，3-其他協助單位
** 救援單位和救援小組的關系
(4) 單位細節ug [細節編號，單位名，小組編號，備注] 說明：單位-小組聯
系表。
** 人員的具體情況
(5) 通訊錄al [ 人員ID 號，姓名，單位名，職務，辦公電話，移動電話，
住宅電話，備注] 說明：人員-單位聯系表。
** 小組的組成成員
(6) 小組成員gm [人員ID 號，小組編號，職別，角色，密碼] ID 號即是PK，
也是FK；取自[通訊錄表]，角色：1-管理員，0-普通用戶。
** 資源的具體描述
(7) 資源res [資源編號，資源名，規格型號，計量單位，用途，資源類別
編號] 說明：資源編號由系統自動生成。
** 各個單位所擁有的資源
(8) 資源分配ra [單位名，資源編號，可用數量，已派遣數量，備注] 單位
名，資源編號既是PK，又是FK。
注意：下劃線表示[主鍵]，曲線表示[外鍵]，粗下劃線表示[既是主鍵又是外
鍵]。一般而言，一個實體不能既無主鍵又無外鍵。在ER 圖中, 處于葉子部位
12
的實體, 可以定義主鍵，也可以不定義主鍵(因為它無子孫), 但必須要有外鍵
(因為它有父親)。主鍵與外鍵的設計，在全局數據庫的設計中，占有重要地位。
因為：主鍵是實體的高度抽象，主鍵與外鍵的配對，表示實體之間的連接。
同理也可以將(圖 2.5)示的ER 模型轉換為關系模式，這里不再贅述。
2.4.2 關系規范化與模式優化
關系規范化理論(范式理論)的目的就是要減少數據冗余、避免插入異常和刪
除異常、保證數據完整性和一致性。將ER 模型轉換成關系模型后，需要利用關
系規范化理論對關系模式進行初步優化，確定關系模式的等級，必要的情況下
對其進行合并或分解。就數據庫設計而言，基本表及其字段之間的關系, 應盡
量滿足第三范式。因此，在數據庫設計中，為了更好地應用三個范式，就必須
通俗地理解三個范式(通俗地理解是夠用的理解，并不是最科學最準確的理解)：
第一范式：1NF 是對屬性的原子性約束，要求屬性具有原子性，不可再分解；
第二范式：2NF 是對記錄的惟一性約束，要求記錄有惟一標識，即實體的惟
一性；
第三范式：3NF 是對字段冗余性的約束，即任何字段不能由其他字段派生出
來，它要求字段沒有冗余。
例如，我們利用規范化理論考察關系模式R1、R2、R3，就會發現它們都屬于
第三范式。這是因為我們在概念設計階段就是遵守的第三范式規則。
R1=救援單位[單位名，聯系人，聯系電話，位置X，位置Y，標志，備注]
R2=資源[資源編號，資源名，規格型號，計量單位，用途，資源類別]
R3=資源分配[單位名，資源編號，可用數量，已派遣數量，備注]
上文提到，基本表及其字段之間的關系, 應盡量滿足第三范式。但是，滿足
第三范式的數據庫設計，往往不是最好的設計。為了提高數據庫的運行效率，
常常需要降低范式標準，適當增加冗余，達到以空間換時間的目的。因此，在
保證關系模式滿足第三范式之后，仍然需要對關系模式進行進一步優化。
例如，對于關系模式R3=資源分配[單位名，資源編號，可用數量，已派遣數
量，備注]，根據系統設計需要，我們在關系表中增加一列”剩余數量”(剩余數量
=可用數量－已派遣數量)。這樣資源分配表(表 2.1)就不符合第三范式了，因為”
剩余數量”可以由”可用數量”減去”已派遣數量”得到，說明”剩余數量”是冗余字
　
中國航空網 www.k6050.com
航空翻譯 www.aviation.cn
本文鏈接地址：民用機場應急救援管理系統關鍵技術研究(4)