實驗題目

圖書管理系統的資料庫設計  

一、實驗目的

選用一種DBMS作為設計平臺，理解並應用課程中關於資料庫設計的相關理論，能按照資料庫設計步驟完成完整的資料庫設計，包括需求分析、概念設計、邏輯設計、物理設計和實施。同時能夠正確應用各個階段的典型工具進行表示。

二、裝置與環境

(1) 硬體裝置：PC機一臺

(2) 軟體環境：安裝Windows作業系統，安裝資料庫管理系統SQL Server2012等。

三、實驗內容

1.需求分析

針對圖書館的圖書管理系統資料庫設計，分別對圖書館的讀者、一般工作人員和部門負責人進行詳細地調研和分析，總結出如下的需求資訊:

（1）圖書館中的圖書具有書號、書名、作者、館藏冊數、在館冊數、價格、出版社及摘要等必要資訊。其中每種書具有唯一的書號，即一個書號對應一種書而不是一本書。書名可以重複，但如果只是兩本書重名，則這兩本書具有不同的書號。館藏冊數和在館冊數可以用於讓讀者判斷是否可以借，另外，館藏冊數必須要大於等於在館冊數。

（2）圖書館中的讀者具有卡號、姓名、性別、單位、型別、級別和在借冊數這些必要資訊。卡號用於唯一地標識讀者身份，每個讀者對應一個卡號，同樣每個卡號也不能對應多個讀者。型別這個屬性可以用於區分老師或是學生，區分他們的意義在於不同型別的讀者可同時借閱的書籍數大不相同。級別則可以體現讀者或者說是該卡號一共的借書量，每借一本書，讀者檔案中的級別屬性就應該有所增加，這樣圖書館的管理者就可以判斷出那些是活躍讀者，甚至可以對這些級別高的讀者作出相應的獎勵。

（3）從讀者的角度，可以查閱圖書館相應的圖書資料（也可以按要求查詢，如輸入一些關鍵字）以及每本書的在館冊數；同時可以檢視自己所借的圖書表及相應的圖書資訊；能判斷自己所借的一些書是否超期，若超期則自動顯示出所需的罰款金額。

（4）圖書館中的工作人員可以分為一般工作人員和部門負責人。部門負責人是從若干個一般工作人員中選出。

（5）一般工作人員是圖書館中最普通的工作人員，一般工作人員可以實現讀者的借書和還書操作；也可以實現在讀者交罰款之後取消罰款記錄。另外，一般工作人員在執行借書或還書操作時，應根據不同讀者型別的借書限制冊和還書日期等約束條件來實現。

（6）部門負責人是從一般工作人員中選出，擁有在整個圖書管理系統中最高的許可權。部門負責人可以檢視所有圖書的借閱情況，以及單本圖書被借的總次數和讀者中比較活躍的人（即讀者中級別這個屬性比較高的人）。

（7）圖書館中應當有書架，書架具有書架號和型別兩個屬性，不同的書架號對應的圖書型別也應該不同；另外還需要在圖書中增加存放位置這個屬性。

2.概念結構設計

各實體型及其屬性:

圖書這個實體型由書號、書名、作者、價格、出版社、摘要、館藏冊數、在館冊數、存放位置和被借次數這些屬性組成，其中書號這個屬性為主屬性。

讀者這個實體型由卡號、姓名、性別、單位、型別、級別和在借冊數這些屬性組成，其中卡號這個屬性為主屬性。

書架這個實體型由書架號和型別這兩個屬性組成，其中書架號這個屬性為主屬性，型別為本書架中存放書籍的型別，與之前讀者中的表示讀者身份的型別完全不同。

工作人員這個實體型由工作號，姓名，職務，工資這些屬性組成，其中工作號這個屬性為主屬性。

完整的E-R圖:

3.邏輯結構設計

(1)關係模式的設計與優化

  首先:將E-R圖中的4個實體型轉換成4個最基本的關係模式

Ⅰ、圖書（書號，書名，作者，價格，出版社，摘要，館藏冊數，在館冊數，存放位置，被借次數）

Ⅱ、讀者（卡號，姓名，性別，單位，型別，級別，在借冊數）

Ⅲ、書架（書架號，型別）

Ⅳ、工作人員（工作號，姓名，職務，工資）

  然後:將實體型之間的聯絡轉換成關係模式，因為是m:n聯絡，因此直接將與該聯絡相連的各實體的碼以及聯絡本身的屬性轉換為關係的屬性

Ⅰ、借閱（書號，卡號，借書時間，還書時間）

  最後，根據實際的需要將關係模式進行合理的優化

Ⅰ、圖書（書號，書名，作者，價格，出版社，摘要，館藏冊數，在館冊數，存放位置，被借次數）

因為只有一個候選碼（書號），因此不存在非主屬性部分依賴的情況；另外，由於除了候選碼以外的所有非主屬性每一個都是隻有通過候選碼推出，因此，不存在傳遞依賴，而且因為候選碼書號是唯一的決定因素，所以該關係模式不僅滿足3NF，也滿足BCNF。

Ⅱ、讀者（卡號，姓名，性別，單位，型別，級別，在借冊數）

因為只有一個候選碼（卡號），因此該關係模式中也不存在非主屬性部分依賴的情況；另外，由於除了候選碼以外的所有非主屬性每一個都是隻有通過候選碼推出，因此，也不存在傳遞依賴，而且因為候選碼卡號是唯一的決定因素，所以該關係模式也滿足BCNF。

Ⅲ、型別（型別，借書時間，最多在借冊數）

與上一個關係模式相同，由於只有一個候選碼（型別），因此該關係模式中也不存在非主屬性部分依賴的情況；另外，由於除了候選碼以外的所有非主屬性每一個都是隻有通過候選碼推出，因此，也不存在傳遞依賴，而且因為候選碼型別是唯一的決定因素，所以該關係模式也滿足BCNF。

Ⅳ、正借閱（書號，卡號，借書時間，應還時間，還書時間，罰款金額）

這個關係模式中含有一個候選碼，但包含三個主屬性（書號、卡號和借書時間），由於主屬性借書時間可以直接推出應還時間，因此在該關係模式中存在著非主屬性部分依賴，所以該關係模式只能滿足2NF。

Ⅴ、已還（書號，卡號，借書時間，還書時間）

這個關係模式中含有一個候選碼，也包含三個主屬性（書號、卡號和借書時間），但該關係模式中不存在應還時間，還書時間這個屬性只能通過三個主屬性唯一確定，因此該關係模式中也不存在非主屬性部分依賴的情況；另外，由於非主屬性只有通過候選碼推出，因此，也不存在傳遞依賴，而且因為候選碼是唯一的決定因素，所以該關係模式也滿足BCNF。

Ⅵ、書架（書架號，型別）

因為只有一個候選碼（書架號），因此該關係模式中也不存在非主屬性部分依賴的情況；另外，由於除了候選碼以外的所有非主屬性只有一個，也就是型別，只有通過候選碼推出，因此，也不存在傳遞依賴，而且因為候選碼書架號是唯一的決定因素，所以該關係模式也滿足BCNF。

Ⅶ、工作人員（工作號，姓名，職務，工資）

與上一個關係模式相同，該關係模式只有一個候選碼（工作號），因此該關係模式中也不存在非主屬性部分依賴的情況；另外，由於除了候選碼以外的所有非主屬性每一個都是隻有通過候選碼推出，因此，也不存在傳遞依賴，而且因為候選碼工作號是唯一的決定因素，所以該關係模式也滿足BCNF。

(2)設計合適的檢視

  首先，由於所需要檢視該資料庫的人員分為讀者、一般工作人員和部門負責人。而這三種人員在不同情況下需要看到的資訊不同，因此需要根據這三種不同的人員建立所需要的不同檢視。

對於讀者而言:

Ⅰ、讀者在需要借書時只需要看到書號、書名、作者、價格、出版社、摘要、館藏冊數和存放位置，可以建立一個檢視。

Ⅱ、當讀者需要檢視自己的資訊時，可以檢視讀者表的的全部資訊以及型別表中  的最多在借冊數，以便於知道自己還能借幾本書，這也需要建立一個檢視。

Ⅲ、當讀者需要檢視自己借書的情況時，需要從正借閱表中檢視與自己卡號相同的借書資訊與超期資訊，需要建立一個檢視。

Ⅳ、當讀者需要檢視自己超期借閱的情況時，需要從正借閱表中檢視與自己卡號相同並且超期的借書資訊，因此需要建立一個檢視。

對於一般工作人員而言:

Ⅰ、當一般工作人員需要檢視自己的資訊時，只需要檢視工作人員表中的前三項即可，不能檢視工資這一項。

對於部門負責人而言:

Ⅰ、部門負責人除了可以檢視所有資訊外，還可以專門建立一個檢視以方便檢視圖書的借閱情況以及每本書的借閱次數。

Ⅱ、當部門負責人想檢視圖書館比較活躍的讀者時還可以專門建立一個級別>30的讀者情況檢視。

4.物理設計

系統已經有的索引: 在建立自定義的索引之前，系統會自動建立一些索引，在建表時，如果設立了主鍵，則系統會自動根據該主鍵建立一個索引，如下圖:

另外，如果表中帶有UNIQUE型別的列，則系統也會自動建立一個以UNIQUE型別的列為標準建立一個索引。

  自定義索引:

    首先，需要在borrowed表中建立一個索引，可以按學號來排序，因為當工作人員或者部門負責人想要查詢某個讀者的所有借書記錄時，如果所有學號按序排列，查詢速度會比之前有所增加。

然後，需要在borrowing表中建立一個索引，也是按學號來排序，因為當工作人員或者部門負責人想要查詢某個讀者當前正在借閱的所有借書記錄時，如果所有學號按序排列，查詢速度會比之前有所增加。

        最後，還需要在Reader表中建立一個索引，按照型別來排序，當部門負責人查詢級別大於某個值或者比較活躍的讀者時，查詢速度會有所提升。

5.資料庫的實現

(1)建立庫、表

Ⅰ、資料庫的建立

在建立資料庫的同時，一定要同時建立日誌檔案。日誌檔案檔案與資料庫檔案存放在一起的好處在於能夠方便查詢，但其弊端在於如果該磁碟發生損壞，則無法進行恢復，因此最好在使用時將其存放到不同的磁碟。

Ⅱ、Reader表的建立

實體完整性:Reader表中以卡號為主鍵，在對錶進行更新操作時，關係資料庫管理系統將按照實體完整性規則對相應屬性自動進行檢查，包括是否唯一以及該屬性值是否為空。

參照完整性:Reader表中的型別這個屬性是根據typed表中的型別而得，因此需要建立一個外來鍵，使Reader表中的型別能夠依賴於typed表中的型別。

自定義完整性: Reader表中的姓名定義為NOT NULL，當輸入資料時，必須要輸入姓名，使之不能為空，否則這條記錄將會沒有意義。另外，Reader表中性別這個屬性只能從“男”或者“女”中選擇，若輸入其他的值，關係資料庫管理系統將會報錯。

Ⅲ、borrowing表的建立

實體完整性: borrowing表中以書號、卡號和借書時間一起作為主鍵，在對錶進行更新操作時，關係資料庫管理系統將按照實體完整性規則對相應屬性自動進行檢查，包括是否唯一以及該屬性值是否為空。

參照完整性: borrowing表中的書號這個屬性是根據Book表中的書號而得，若Book表中不存在某個書號，則borrowing表中也不能有這個書號，否則該書號將變得沒有意義，因此需要建立一個外來鍵，使borrowing表中的書號能夠依賴於Book表中的書號。另外，borrowing表中的卡號這個屬性是根據Reader表中的卡號而得，若Reader表中不存在某個卡號，則borrowing表中也不能有這個卡號，否則該卡號也將變得沒有意義，因此需要建立一個外來鍵，使borrowing表中的卡號能夠依賴於Reader表中的卡號。

(2)建立使用者

建立角色:

Ⅰ、建立一個讀者的角色

併為其授權，使之只被允許檢視reader_borrow、reader_self、reader_borrowing和reader_overborrow這四個檢視。

Ⅱ、建立一個一般工作人員的角色

併為其授權，使之被授權允許檢視和修改Book、Reader、borrowing和bookshelf這四個表。

但是要注意的是，出於安全考慮，一般工作人員應該只被允許檢視borrowed表和worker_self檢視，這樣一般工作人員就不能夠修改自己的職務以及已經還的書的資訊。

Ⅲ、建立一個部門負責人的角色

併為其授權，使之被授權允許對所有表進行所有操作。

建立使用者:

Ⅰ、建立一個登入名u1

Ⅱ、在u1下建立一個使用者user1，並使之加入角色“讀者”

Ⅲ、建立一個登入名u2

Ⅳ、在u2下建立一個使用者user2，並使之加入角色“一般工作人員”

Ⅴ、建立一個登入名u3

Ⅵ、在u3下建立一個使用者user3，並使之加入角色“一般工作人員”

(3)資料庫程式設計

Ⅰ、建立一個用於判斷的觸發器T1，當向Book表中輸入資料時，對館藏冊數和在館冊數進行判斷，使館藏冊數不能小於在館冊數，若輸入的資料不符合條件，則進行報錯並回滾。

Ⅱ、建立一個用於判斷的觸發器T2，當向Reader表中輸入資料時，對在借冊數和最大在借冊數進行判斷，使在借冊數不能大於最大在借冊數，若輸入或者修改的資料不符合條件，則進行報錯並回滾。

Ⅲ、建立一個用於修改資料的觸發器T3，當向borrowing表中輸入資料時，對Reader表的在借冊數屬性和Book表的被借冊數屬性進行同步修改，使之能夠動態地隨著borrowing表中的輸入而增加。

 Ⅳ、建立一個用於修改資料的觸發器T4，當在borrowing表中刪除資料時，對Reader表的在借冊數屬性進行同步修改，使之能夠動態地隨著borrowing表中的刪除而減少，也對Book表的在館冊數屬性進行同步修改，使之能夠動態地隨著borrowing表中的刪除而增加。

Ⅴ、建立一個用於修改資料的觸發器T5，當在borrowing表中插入資料時，對borrowed表的各屬性進行同步的插入操作，使之能夠動態地隨著borrowing表中的輸入而輸入。

Ⅵ、建立一個用於修改資料的觸發器T6，當在borrowing表中修改資料時，對borrowed表的各屬性進行同步的修改操作，使之能夠動態地隨著borrowing表中的修還而修改。另外，在修改完之後進行判斷，若是修改了還書時間（即工作人員進行還書操作），則在borrowing中刪除掉這條資料。因為之前已經在borrowed表中做了備份，因此此舉能夠減少常用表borrowing中的資料，提高查詢效率，而資料多的borrowed表則為不常用表。

     Ⅶ、建立一個用於修改資料的觸發器T7，當在borrowing表中插入資料時，對borrowing表的應還時間屬性進行同步的修改操作，使之能夠動態地隨著borrowing表中的結束時間改變而改變。

Ⅷ、建立一個用於修改資料的觸發器T8，當在borrowing表中插入或修改資料時，對borrowing表的罰款金額屬性進行同步的計算並修改操作，使之能夠動態地隨著borrowing表中的時間改變而改變。觸發器中會進行判斷，當獲取到的當前時間>圖書的應還時間時，觸發器生效進會進行計算，並將計算得到的罰款金額數值更新到borrowing表中的對應位置。

四、實驗結果及分析

通過本次實驗我學習到了建立一個數據庫系統具體需要做些什麼，之前老師在上課時曾談到過建立一個數據庫系統需要經歷需求分析階段、概念結構分析階段、邏輯結構分析階段、物理結構分析階段、資料庫實施階段和資料庫執行維護階段，我們只是從理論的角度對其進行了解，而這次大作業卻讓我切切實實感受到了這個流程的重要性，雖然我們並沒有經歷資料庫執行維護階段，但也知道了無論少了這些步驟的任何部分，資料庫系統的建立就無從談起。

另外，本次實驗也額外讓我感受到了資料庫恢復技術有多重要。由於一些私人原因，我在完成本次實驗的過程中，資料發生了丟失，之前對資料庫以及資料庫中的資料做的所有操作都不翼而飛。如果那時我能夠對資料庫系統做好備份，甚至是將資料庫系統和它的日誌檔案分開存放，那麼這些事情就不會發生，我也不會面臨著重做的命運。而這也警告了我無論多小的一個數據庫，都一定要做好備份，並將資料庫系統和它的日誌檔案分開存放。

最後，由於時間原因本次實驗的成果僅僅只是用到了一些複雜的觸發器，並沒有涉及到資料儲存或者動態SQL，雖然功能都已經實現，但是程式碼都比較冗長，有很多地方完全可以更加簡單，而且效果更好。除此之外，如果能用VB語言寫一個外部程式與之對應，那麼整個資料庫系統也會變得更加美觀並符合實際。這就是本資料庫所能拓展的方向，我將會在實驗結束後繼續進行開發。