數(shù)據(jù)庫應用系統(tǒng)3-5

數(shù)據(jù)庫應用系統(tǒng)需求分析與規(guī)劃

第三章

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

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

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

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

概念設計

邏輯設計

物理設計

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

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

返回物理設計物理設計是選擇物理數(shù)據(jù)庫結構，得到一個完整的、可實現(xiàn)的數(shù)據(jù)庫結構。

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

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

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

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

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

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

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

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

返回聯(lián)系的合并

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

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

返回消除冗余

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

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

返回驗證數(shù)據(jù)庫概念結構

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