數據庫應用系統需求分析與規劃

第三章

數據庫應用系統的總體設計§1總體設計目標和任務§2總體設計的過程§3模塊化§4從數據流程圖導出結構圖§5數據庫概念結構設計§6數據庫邏輯結構設計§7數據庫設計的其它因素§8總體設計階段文檔返回§5數據庫概念結構設計

5.1數據庫設計過程5.2局部視圖設計5.3視圖的集成返回5.1數據庫設計過程返回根據用戶需求研制一個數據庫結構的過程稱為數據庫設計。上圖表示了數據庫設計過程的輸入和輸出。

數據庫設計員一般信息需求處理要求DBMS說明書操作系統和硬件配置數據庫結構應用程序指南數據庫設計過程的輸入和輸出一般信息需求包括數據庫系統的目的說明、數據元素的定義以及企業組織中數據元素的使用描述。這些要求并不只限于某些特殊用戶，因此，在這個基礎上進行的數據庫結構設計能適應應用上的變化。處理要求由三個部分組成：每個應用所要求的數據項、數據量（數據項的值的數量）和處理頻率。這三部分的每一部分對數據庫設計都是十分重要的。另外，在設計過程中還要使用一些其它信息，如DBMS說明書、操作系統和硬件環境說明等。當然，性能約束會對數據庫設計產生影響。通常把性能約束看作是需求的一部分。一些典型的約束是指：進行查詢的響應時間、系統破壞后的恢復時間以及對安全性和完整性的特殊要求等。數據庫設計過程得到的主要結果是完整的數據庫結構，以及應用程序員應該遵循的一些原則。返回數據庫設計的步驟

數據庫設計過程可分為若干階段或若干步驟：需求分析與數據分析

概念設計

邏輯設計

物理設計

返回物理結構邏輯結構概念結構需求說明與數據說明需求分析與數據分析概念設計邏輯設計物理設計需求分析與數據分析需求分析與數據分析（數據分析也可看作需求分析的一部分）是整個設計過程中最困難的一步。但是，因為以后的各個設計階段都依賴于這一步，所以它也是最重要的一步。這階段的主要任務是從所有數據庫用戶那里收集信息內容和處理要求。需求分析既要保證企業組織的信息流觀點的一致性，同時，也要保證用戶目標的一致性。返回概念設計概念設計是通過對用戶信息需求的綜合歸納，形成一個不依賴于DBMS的信息結構的設計。概念設計結果得到的是數據庫概念結構，或稱概念模型。由于它是從用戶世界的角度進行的一種描述，所以不依賴于任何DBMS或硬件環境。

返回邏輯設計邏輯設計得到的數據庫結構是DBMS可以處理的數據模型，通常用數據定義語言表示，我們稱它為數據庫邏輯結構。邏輯設計與概念設計不同，概念設計僅僅是對客觀世界的描述，與實現無關；而邏輯設計卻與實現有關，依賴于實現的基礎DBMS，所以有些書上把這一階段稱為實現設計。

返回物理設計物理設計是選擇物理數據庫結構，得到一個完整的、可實現的數據庫結構。

返回評審檢查應該注意，設計過程的每一階段的末尾，都要進行評審檢查。盡可能使設計錯誤在早期發現并在早期予以糾正。整個設計過程的各階段也不是完全“線性”發展的，而是迭代式的，逐步求精的，允許重復前面的步驟。

返回第一步第二步第三步第四步5.2局部視圖設計

在數據分析基礎上，可以使用E－R圖作為工具來進行視圖設計。所謂視圖是反映了某一用戶或某一類用戶對數據庫的要求；或者說，視圖是某用戶所看到的數據庫，因而視圖設計所得到的結果是單用戶的概念結構。視圖設計時，首先要在該用戶的應用領域內，確定實體、屬性（包括標識碼屬性及屬性間的數據依賴）和實體間的聯系。然后用E－R方法來描述所確定的實體、屬性和實體間聯系。返回實體和屬性是相對而言的，很難有截然的界限，某一事物，在一種應用環境中可能作為“屬性”出現；在另一種應用環境中可能作為“實體”出現。例如，飯店中的客房，在某種應用環境中，它只是作為“旅客住宿表”實體的一個屬性——住宿地點；而在另一種環境中，可能需要考慮客房的面積、設備、價格、當前狀態等性質，則它就作為實體出現了。一般來說，凡是能夠作為屬性的事物就盡量作為屬性對待，作為屬性的事物不能再具有需要描述的性質或與其它事物具有聯系。返回數據流程圖作為視圖設計的基礎數據流程圖及其有關的數據說明和處理說明可以作為視圖設計的基礎。后圖是一個數據流圖的例子，它描述了中小型飯店的散客入住流程。返回當散客要入住時，必須提交身份證和住宿登記單，在接到入住請求后，首先進行身份證檢驗，與公安部門協查名單存儲文件和黑名單存儲文件比較，進行身份證檢驗，一旦發現有問題，則通知安全保衛部處理，如果身份證檢驗沒有問題，則根據住宿登記單查看是否已訂房以及所有符合條件的客房的當前狀態和參考價格，這些可以從訂房委托書存儲文件和客房資料存儲文件得到，在分配適當的客房后將結果通知收銀員進行預付款收取，旅客登記單數據進入旅客登記存儲文件備查，旅客到達數據進入旅客到達單存儲文件通知有關人員，旅客分房數據通知客房部并進入客房資料存儲文件。返回該數據流圖其它部分的含義可以類似地解釋。圖中還畫了“旅客登記單”、“公安部門協查名單”、“黑名單”、“訂房委托書”、“客房資料”、“旅客到達單”等存儲數據，這些存儲數據都應有文檔進行說明，這里不再詳述。返回散客入住處理的數據流圖

返回住宿查詢結果檢驗結果住宿登記單有誤住宿數據住宿數據訂房數據住宿查詢身份證查詢黑名單數據協查名單數據住宿登記單身份證旅客登記存儲接待員安全保衛部收銀員客房部公安部門協查名單黑名單訂房委托書旅客到達單客房資料身份證檢驗住宿登記旅客安全通知來客通知身份證查詢結果通知數據應收預付款數據住宿數據住宿數據住宿數據客房數據確定實體、屬性和實體間的聯系在數據流圖基礎上我們可以作進一步的分析，以便確定所需的實體、屬性和實體間的聯系。以“住宿登記”為例，要完成這一步處理，必須涉及“旅客”實體、“客房”實體以及這兩實體間的“住宿”聯系，它們可以用E－R方法表示為圖（a）的形式。當然，旅客可能已經預訂了客房，因此又有“旅客”實體、“客房”實體以及這兩實體間的“預訂”聯系，如圖（b）所示。返回確定實體、屬性和實體間的聯系11旅客客房住宿(a)n1旅客客房預訂(b)返回視圖設計逐步地進行分析和綜合，對應于上述數據流圖所反映的應用領域，我們可以有下圖所示的視圖設計。其中每個實體所包含的屬性及其說明可以從已經建立的有關文檔中得到。返回視圖設計旅客客房住宿預訂公安部門協查人員黑名單對比對比返回5.3視圖的集成

各個視圖建立以后，需要對它們進行合并，集成為一個整體的數據概念結構。某一事物在不同視圖中作為實體所包含的內容可以是不同的。即實體所包含的屬性可以有區別。例如，一個飯店中的“客房”，在視圖中可以作為實體，但在前廳部的視圖中關心的是“是否已售”、“是否已預訂”等屬性，而在客房部的視圖中所關心的是“是否已打掃”等屬性，工程部的視圖中所關心的是“是否可用”等屬性。而合并以后，“客房”實體必須既包含“是否已售”、“是否已預訂”等屬性，又包括““是否已打掃””等屬性，還要包括“是否可用”等屬性。返回前廳部的視圖中“客房”實體

客房價格是否已售是否已預訂客房號返回客房部和工程部的視圖中“客房”實體······客房客房客房號是否已打掃客房號是否可用客房部的視圖工程部的視圖返回合并后的“客房”實體

客房···客房號價格是否已售是否已預訂是否已打掃是否可用返回聯系的合并

如果兩個實體之間，在一個視圖中存在著一種聯系，而在另一個視圖中存在著另一種聯系，那么在合并時，這兩種聯系都必須保留。例如，在一個飯店里“旅客”與“客房”之間存在著聯系，對處理預訂的人員來說，關心的是旅客“預訂”客房；而對處理入住的人員來說，關心的是旅客“住宿”客房；當然對整個飯店來說，“預訂”和“住宿”都需要關心。下圖顯示了這種合并的過程。合并后的E－R圖中，“旅客”與“客房”存在著“預訂”和“住宿”的雙重聯系。

返回聯系的合并

(a)處理預訂的人員視圖中旅客與客房的聯系11旅客客房住宿(b)處理入住的人員視圖中旅客與客房的聯系n1旅客客房預訂n111(c)合并后的雙重聯系旅客住宿預訂客房返回消除不一致性

在視圖合并過程中，必須消除不一致性和冗余。消除不一致性就得消除同名異義和同義異名。同名異義和同義異名現象可能發生在實體和聯系這一級，也可能發生在屬性這一級。如果同一事物在不同視圖中作為實體，而實體的名字又不一致，那么應該把名字統一，然后進行合并。如果不同事物在不同視圖中作為實體，而實體的名字卻相同，那么，必須重新命名加以區別。對于實體間的聯系也有類似的情況，需要進行類似的處理。在屬性一級，同名異義和同義異名更是經常發生。例如，飯店內客房的編號，在不同視圖中，可能會有“客房編號”、“客房代碼”、“客房編碼”、“客房號”等各種名字，也必須加以統一，消除不一致性。

返回消除冗余

在視圖合并時，可能存在冗余的數據和實體間冗余的聯系。所謂冗余的數據指可以由基本數據導出的數據；冗余的聯系是指可由基本聯系導出的聯系。冗余信息的存在會影響數據庫的完整性，給數據庫的管理增加困難，應當設法予以消除。

返回消除冗余要根據整體需求進行消除冗余的問題比較復雜，有些冗余信息的存在，雖然對數據庫的管理帶來不便，但卻對提高數據庫的效率性能有好處，因而在設計一個實用的數據庫過程中，視圖合并時，哪些冗余信息必須消除，哪些冗余信息允許存在，這要根據整體需求來確定。例如在一個企業的管理信息系統中，具有“臺帳”性質一類的數據往往是冗余的，它們一般不屬于基本數據，大多可以由具有“票據單證”性質一類的基本數據導出。例如，“庫存帳”是“臺帳”數據，可以由“入／出庫單”數據導出；“記帳憑證”數據也可以導出各種“臺帳”帳本數據。這些“臺帳”數據是否消除要視具體系統需求而定。實體間的聯系也有類似的情況。

返回驗證數據庫概念結構

視圖合并后形成了一個整體的數據庫概念結構，對該整體概念結構必須進