系統資料庫設計說明書
『壹』 資料庫設計說明書的內容
資料庫設計說明書的編制目的是對資料庫中使用的所有標識、邏輯結構和物敬衫理結構做出亮侍腔具體的設談和計規定。
『貳』 簡述系統設計說明書的內容。
系統設計說明書的內容應當包含七個方面。
(1)控制結構圖及派返每一模塊的詳細說明。
(2)資料庫設計說明。
(3)計算機和網路系統配置說神頌明。
(4)代碼設計說明。
(5)用戶界面設計說明。
(6)計算機處理過程說明。
(7)實施費用估計塵瞎飢。
『叄』 基於asp,access資料庫的圖書管理系統需求規格說明書
摘要 介紹了信息中心圖書管理系統資料庫的設計。該系統是運行在學校內的圖書管理系統,實現了圖書資料的計算機管理和圖書查詢功能。
關鍵詞 圖書 網路 管理系統 資料庫
1 引言
一直以來人們使用傳統的人工方式管理圖書館的日常工作,對於圖書館的借書和還書過程,想必大家都已很熟悉。在計算機尚未在圖書館廣泛使用之前,借書和還書過程主要依靠手工。一個最典型的手工處理還書過程就是:讀者將要借的書和借閱證交給工作人員,工作人員將每本書上附帶的描述書的信息的卡片和讀者的借閱證放在一個小格欄里,並在借閱證和每本書貼的借閱條上填寫借閱信息。這樣借書過程就完成了。還書時,讀者將要還的書交給工作人員,工作人員根據圖書信息找到相應的書卡和借閱證,並填好相應的還書信息,這樣還書過程就完成了。
以上所描述的手工過程的不足之處顯而易見,首先處理借書、還書業務流程的效率很低,其次處理能力比較低,一段時間內,所能服務的讀者人數是有限的。利用計算機來處理這些流程無疑會極大程度地提高效率和處理能力。我們將會看到排隊等候借書、還書的隊伍不再那麼長,工作人員出錯的概率也小了,讀者可以花更多的時間在選擇書和看書上。
為方便對圖書館書籍、讀者資料、借還書等進行高效的管理,特編寫該程序以提高圖書館的管理效率。使用該程序之後,工作人員可以查詢某位讀者、某種圖書的借閱情況,還可以對當前圖書借閱情況進行一些統計,給出統計表格,以便全面掌握圖書的流通情況。
本次作業設計題目:「圖書管理系統」主要目的是利用資料庫軟體編制一個管理軟體,用以實現圖書、讀者以及日常工作等多項管理。同時對整個系統的分析、設計過程給出一個完整論證。
圖書管理系統是一種基於集中統一規劃的資料庫數據管理新模式。在對圖書、讀者的管理,其實是對圖書、讀者數據的管理。本系統的建成無疑會為管理者對圖書管理系統提供極大的幫助。
2 系統設計
2.1 系統指導思想和建設目標
2.1.1 系統指導思想
立足於校園實際,著眼於未來發展,建成符合標准化協議、通用性較強、實用的系統,以提高圖書信息的現代化管理水平,實現信息資源的共享。
2.1.1 系統建設目標
(1)要解決的問題:(以某學校為參照) 隨著辦公自動化水平的不斷提高,現在學校管理學生信息也逐步從手工轉到計算機自動化信息處理階段。設計蠢慶一個功能完整或扒、操作簡便、界面友好的學生信息管理系統已經是勢在必行的了。衫檔昌
(2)系統開發的目的:提高圖書管理工作的效率,減少相關人員的工作量,使學校的圖書管理工作真正做到科學、合理的規劃,系統、高效的實施。
(3)系統名稱:圖書管理系統
2.2 總體功能設計
系統要能實現如下功能:
l 登錄系統:注銷用戶、系統退出。
l 管理:用戶管理、圖書管理、讀者管理、借閱管理。
l 查詢:圖書查詢、讀者查詢、借閱查詢。
l 報表列印:所有圖書、借出圖書、庫存圖書、所有讀者。
l 幫助:使用說明、關於。
3 資料庫設計
3.1 資料庫系統的選擇
本系統是一個中小型管理系統,運行環境是Windows2000 server,因此使用Windows環境下最容易使用且功能還可以的Microsoft Access 2000 作為後台的資料庫系統。
3.2 需求分析
圖3 圖書流通數據流圖
1.2
判斷能
否借書
索書
信息
讀 者
1.2
辦理借
書手續
讀者信息
查詢結果
借書申請
被借圖書
借書結果
借書信息
被借圖書復本量
(b) 借書
借閱
3
讀者
1
圖書
5
1.1
圖書
查詢
借書信息
查詢
4
判斷
2
判斷結果
索書
信息
圖書信息
讀 者
1
借書
2
還書
讀 者
申請借書
還書申請
借書結果
還書結果
(a) 頂層數據流圖
3
辦借
書證
讀者信息
辦證信息
需求分析是資料庫設計首先要做的工作,通過需求分析,我們作出了圖書管理系統的各層數據流圖,圖3是圖書流通數據流圖(圖中省略了「還書」和「辦理借書證」的數據流圖)。
在數據流圖的基礎上,定義數據字典。數據字典是關於資料庫中數據的描述,它的作用是在軟體分析和設計過程中為有關人員提供關於數據描述信息的查詢,以保證數據的一致性。下面在圖3的基礎上舉例說明數據字典的定義。
圖3中涉及很多數據項,其中數據項「讀者編號」可以描述如下:
數據項名:讀者編號
別名:讀者條碼
含義:唯一標識每個讀者
類型:字元型
取值范圍:00000000至99999999
取值含義:順序編號
「讀者」一個數據結構,它可以描述如下:
數據結構名:讀者
含義說明:是圖書管理系統的數據結構之一,定義了一個讀者的有關信息
組成:讀者編號,姓名,性別,單位
數據流「借閱記錄」可描述如下:
數據流名:借閱記錄
說明:讀者的借書記錄
數據來源:辦理借閱手續
數據去向:借閱
數據結構:讀者編號、圖書館藏號、借閱日期
數據存儲「借閱」可以描述如下:
數據存儲名:借閱
說明:記錄讀者的借書情況
流出數據流:借閱記錄
流入數據流:借閱記錄
數據描述:讀者編號、圖書館藏號、借閱日期
數據量:每年5000條以上
存取方式:隨機存取
處理過程「判斷能否借書」可描述如下:
處理過程「判斷能否借書」
說明:根據讀者的已借書情況可被借圖書的館藏情況判斷讀者能否借書
輸入:借閱記錄、讀者信息、被借圖書信息
輸出:能否借書的標志
處理:讀者提出借書請求後,先判斷該讀者以前的借書量是否達到了10本,如果達到了10本,則不能再借書,如果沒有達到10本,則再判斷讀者要借的圖書的可借量是否為0,如果不為0,則該書可以借出。
3.3 資料庫設計
在圖書管理系統中,資料庫設計占重要位置,資料庫設計質量的優劣,可直接影響到資料庫數據的冗餘度、數據的一致性、數據丟失等問題。下面就系統資料庫規范化設計進行說明。
3.3.1 資料庫設計的理論指導
資料庫設計的理論指導是範式理論,其主要內容如下:
1)如果關系模式R,其所有的域為單純域則稱R是規范化的關系,或稱第一範式 (1NF)
2)如果關系模式R為第一範式,且每個非主屬性完全函數依賴於碼,則模式R為第二範式(2NF)。
3) 如果關系模式R為第二範式,且每個非主屬性非傳遞依賴於碼,則稱關系模式R為第三範式(3NF)。
4)關系模式R為第一範式,滿足函數依賴集合F,X和A均為R的屬性集合,且X不包含A,如果R滿足X->A且X必包含R的碼,稱關系模式R為BCNF範式。
3.3.2 資料庫設計
圖書管理系統資料庫常常要設計含有如下數據項:借書證號、姓名、單位、館藏號(館藏號為每本書上的條形碼號)、書名、分類號、作者、價格等。如何進行模式的設計呢?下面以圖書流通模塊所涉及的資料庫為例來說明。
圖 書
讀 者
借閱
m
n
借閱時間
館藏號
書名
分類號
作者
價格
借書證號
姓名
性別
圖4 圖書流通的E-R圖
屬於
單 位
1
n
單位名稱
單位編號
先設計圖書流通的實體-關系圖(E-R圖)。E-R圖由3個相關聯的部分構成,即實體、實體與實體之間的關系以及實體和關系的屬性。圖書流通過程中實體「圖書」與「讀者」之間的關系是借閱和被借閱的關系,實體「讀者」與「單位」之間的關系是屬於和被屬於的關系,「圖書」的屬性有「館藏號」、「書名」、「分類號」、「作者」、「價格」,「讀者」的屬性有「借書證號」、「姓名」、「性別」,「單位」的屬性有「單位編號」和「單位名稱」,「借閱」屬性「借書日期」,由此得出E-R圖如圖4。
從圖中可以知道:
①「借書證號」是唯一的,所以「借書證號」決定「姓名」,每位讀者應只屬於一個性別,所以「借書證號」也決定「性別」;
②「館藏號」是唯一的,所以「館藏號」決定「書名」、「分類號」、「作者」、「價格」;
③ 「單位編號」是唯一的,所以「單位編號」決定「單位名稱」;
④ 每位讀者在一個時間只能借一本書,所以「借書證號」 +「館藏號」決定「借閱時間」。
如果將這些數據項置於一個關系模式中,根據範式理論,該關系模式屬於1NF(第一範式),它存在刪除異常和冗餘等問題,不是理想的模式,因此要把它分解成滿足3NF或BCNF的關系模式。根據範式理論和E-R圖轉換成關系模型的規則,上面的E-R圖可轉換為4個關系模式:①圖書(館藏號、書名、分類號、作者、價格);②讀者(借書證號、姓名、性別、單位編號);③借閱(借書證號、館藏號、借閱時間),④單位(單位編碼、單位名稱),其中打下劃線的為碼,這樣就解決了插入、刪除和數據冗餘等問題。
我們對數據的結構進行詳細的分析,按照上述的設計思想,共設計了讀者表,書目表,館藏表,流通表等百餘張數據表,然後創建視圖和存儲過程。下面舉例說明:
讀者表:借書證號、姓名、單位、讀者類別、職稱等欄位;
書目表:館藏號、ISBN、題名、作者、出版社、復本數、語種、文獻類型、版次等欄位;
館藏表:館藏號、索書號、分類號、種次號、館藏位置、單價、出版日期等欄位;
流通表:借書證號、館藏號、借期、還期、續借、應還期、操作員等欄位;
借閱規則表:讀者類別編碼、圖書類別編碼、限借冊數、每期天數、續借天數、過期日期、罰金等欄位。
讀者類別表:讀者類別編碼、讀者類別等欄位。
圖書類別表:圖書類別編碼、圖書類別等欄位。
3.4 資料庫索引
建立索引是加快查詢速度的有效手段,資料庫的每一個表建立了主鍵,主鍵由一個或幾個欄位組成,每一個表都按主鍵建立了索引,部分表為了滿足查詢和排序的需要,除建立主索引外,還建立了次索引。例如在查詢時要用到「館藏號」、「作者」、「題名」等條件來查找圖書,因此,在書目表上除了對主鍵「館藏號」建立了主索引外,也對「作者」、「書名」等建立了次索引。
3.5 視圖
視圖是從一個或幾個基本表導出的表,它是定義在基本表之上的,它是一個虛表,資料庫中只存放視圖的定義,而不存放視圖對應的數據,數據仍然存放在原來的基本表中。通過定義視圖,可以使用戶眼中的資料庫結構簡單、清晰,並可以簡化用戶的數據查詢操作。由於本系統數據表較多,表中的欄位多,為了簡化對表的操作,我們創建了圖書_按書名查詢、期刊_按刊名查詢、期刊_按編輯部查詢、借閱規則查詢、待還書查詢、超期記錄查詢等30餘個視圖。
3.6 存儲過程
存儲過程是一段經過編譯的程序代碼,存放在資料庫伺服器端。通過調用適當的存儲過程,可在伺服器端處理大量數據,再將處理結果送到客戶端。這樣可減少數據在網路上的傳送,消除網路阻塞現象;例如:要查詢某條記錄,若該記錄在表中的順序號是10000,不採用存儲過程,伺服器將從1至於10000條記錄數據逐條送至客戶端,採用存儲過程後,由於過程是經過編譯的並且是在本地,不需要通過網路,因此能很快查出所需記錄並將結果送到客戶端,大大減少了網上數據傳輸量。存儲過程另一好處是可供不同的開發工具調用,如PB、VB、ASP、Delphi等開發工具均可調用。在流通模塊和WEB查詢模塊上均有圖書檢索功能,實際上調用同一存儲過程完成的。本系統建立了60多個存儲過程,實現諸如借還書處理、新書入庫統計、編目入館藏、讀者統計、生成索書號等功能。
3.7 資料庫調用
採用ODBC介面實現資料庫的調用,採用ADO介面調用。
4 條形碼的使用
條形碼具有唯一性和一次輸入後就可反復使用的優點,利用條形碼技術作為信息快速輸入的手段可迅速且不易發生錯誤地處理圖書管理業務。本系統使用條形碼作為圖書和讀者的標識,實現標識的唯一性。
使用條碼後,能夠使圖書管理工作更加簡單、快捷、不易出錯。例如,當一本書具有唯一條形碼標識,每位讀者也具有唯一條形碼標識時,圖書的借閱、查詢就十分便捷了。應用條形碼取代了以往填寫書袋卡、借書證,核對借閱時間等繁瑣的手工勞動。讀者在借書時只要將借書證給工作人員,工作人員只需登錄借書系統,用條形碼閱讀器掃描讀者借書證上的條形碼,屏幕就會顯示出該讀者的信息,包括讀者姓名、單位、可借幾本書、已借幾本書、是否過期、有無罰款等。如可以借書,工作人員只需用條形碼閱讀器掃描該讀者所需借的書上的條形碼符號後,該書的書名和條形碼等信息都從資料庫中調出顯示在屏幕上,自動記錄在該讀者的借閱檔案中,借書工作即告完成。一般借一本書僅需 1至 2秒鍾。操作完後,計算機自動地將該借閱者和借閱的圖書號碼輸入對應資料庫中,並自動提示借閱期限。
參考文獻
[1] 王珊著、資料庫系統原理教程,清華大學出版社,2002.1
[2] 齊治昌等著、軟體工程,高等教育出版社,2002.1
[3] 網路資源
『肆』 資料庫設計說明書中的數據字典應該如何編寫啊
正文
1 引言
1.1編寫目的
說明編寫這份資料庫設計說明書的目的,指出預期的讀者。
1.2背景
說明:
a.說明待開發的資料庫的名稱和使用此資料庫的軟體系統的名稱;
b.列出該軟體系統開發項目的任務提出者、用戶以及將安裝該軟體和這個資料庫的計算站(中心)。
1.3定義
列出本文件中用到的專門術語的定義、外文首字母組詞的原片語。
1.4參考資料
列出有關的參考資料:
a.本項目的經核準的計劃任務書或合同、上級機關批文;
b.屬於本項目的其他已發表的文件;
c.本文件中各處引用到的文件資料,包括所要用到的軟體開發標准。
列出這些文件的標題、文件編號、發表日期和出版單位,說明能夠取得這些文件的來源。
2 外部設計
2.1標識符和狀態
聯系用途,詳細說明用於唯一地標識該資料庫的代碼、名稱或標識符,附加的描述性信息亦要給出。如果該資料庫屬於尚在實驗中、尚在測試中或是暫時使用的,則要說明這一特點及其有效時間范圍。
2.2使用它的程序
列出將要使用或訪問此資料庫的所有應用程序,對於這些應用程序的每一個,給出它的名稱和版本號。
2.3約定
陳述一個程序員或一個系統分析員為了能使用此資料庫而需要了解的建立標號、標識的約定,例如 用於標識資料庫的不同版本的約定和用於標識庫內各個文卷、、記錄、數據項的命名約定等。
2.4專門指導
向准備從事此資料庫的生成、從事此資料庫的測試、維護人員提供專門的指導,例如將被送入數據 庫的數據的格式和標准、送入資料庫的操作規程和步驟,用於產生、修改、更新或使用這些數據文卷的操 作指導。 如果這些指導的內容篇幅很長,列出可參閱的文件資料的名稱和章條。
2.5支持軟體
簡單介紹同此資料庫直接有關的支持軟體,如資料庫管理系統、存儲定位程序和用於裝入、生成、修 改、更新資料庫的程序等。說明這些軟體的名稱、版本號和主要功能特性,如所用數據模型的類型、允許 的數據容量等。列出這些支持軟體的技術文件的標題、編號及來源。
3 結構設計
3.1概念結構設計
說明本資料庫將反映的現實世界中的實體、屬性和它們之間的關系等的原始數據形式,包括各數據項、記錄、系、文卷的標識符、定義、類型、度量單位和值域,建立本資料庫的每一幅用戶視圖。
3.2邏輯結構設計
說明把上述原始數據進行分解、合並後重新組織起來的資料庫全局邏輯結構,包括所確定的關鍵字和屬性、重新確定的記錄結構和文卷結構、所建立的各個文卷之間的相互關系,形成本資料庫的資料庫管理員視圖。
3.3物理結構設計
建立系統程序員視圖,包括:
a.數據在內存中的安排,包括對索引區、緩沖區的設計;
b.所使用的外存設備及外存空間的組織,包括索引區、數據塊的組織與劃分;
c.訪問數據的方式方法。
4 運用設計
4.1數據字典設計
對資料庫設計中涉及到的各種項目,如數據項、記錄、系、文卷、模式、子模式等一般要建立起數據字典,以說明它們的標識符、同義名及有關信息。在本節中要說明對此數據字典設計的基本考慮。
4.2安全保密設計
說明在資料庫的設計中,將如何通過區分不同的訪問者、不同的訪問類型和不同的數據對象,進行分別對待而獲得的資料庫安全保密的設計考慮。
『伍』 急!高分求做SQL Server資料庫設計【達人請進】
下述十四個技巧,是許多人在大量的資料庫分析與設計實踐中,逐步總結出來的。對於這些經驗的運用,讀者不能生幫硬套,死記硬背,而要消化理解,實事求是,靈活掌握。並逐步做到:在應用中發展,在發展中應用。
1. 原始單據與實體之間的關系
可以是一對一、一對多、多對多的關系。在一般情況下,它們是一對一的關系:即一張原始單據對應且只對應一個實體。在特殊情況下,它們可能是一對多或多對一的關系,即一張原始單證對應多個實體,或多張原始單證對應一個實體。這里的實體可以理解為基本表。明確這種對應關系後,對我們設計錄入界面大有好處。
〖例1〗:一份員工履歷資料,在人力資源信息系統中,就對應三個基本表:員工基本情況表、社會關系表、工作簡歷表。這就是「一張原始單證對應多個實體」的典型例子。
2. 主鍵與外鍵
一般而言,一個實體不能既無主鍵又無外鍵。在E?R 圖中, 處於葉子部位的實體, 可以定義主鍵,也可以不定義主鍵(因為它無子孫), 但必須要有外鍵(因為它有父親)。
主鍵與外鍵的設計,在全局資料庫的設計中,佔有重要地位。當全局資料庫的設計完成以後,有個美國資料庫設計專家說:「鍵,到處都是鍵,除了鍵之外,什麼也沒有」,這就是他的資料庫設計經驗之談,也反映了他對信息系統核心(數據模型)的高度抽象思想。因為:主鍵是實體的高度抽象,主鍵與外鍵的配對,表示實體之間的連接。
3. 基本表的性質
基本表與中間表、臨時表不同,因為它具有如下四個特性:
(1) 原子性。基本表中的欄位是不可再分解的。
(2) 原始性。基本表中的記錄是原始數據(基礎數據)的記錄。
(3) 演繹性。由基本表與代碼表中的數據,可以派生出所有的輸出數據。
(4) 穩定性。基本表的結構是相對穩定的,表中的記錄是要長期保存的。
理解基本表的性質後,在設計資料庫時,就能將基本表與中間表、臨時表區分開來。
4. 範式標准
基本表及其欄位之間的關系, 應盡量滿足第三範式。但是,滿足第三範式的資料庫設計,往往不是最好的設計。為了提高資料庫的運行效率,常常需要降低範式標准:適當增加冗餘,達到以空間換時間的目的。
〖例2〗:有一張存放商品的基本表,如表1所示。「金額」這個欄位的存在,表明該表的設計不滿足第三範式,因為「金額」可以由「單價」乘以「數量」得到,說明「金額」是冗餘欄位。但是,增加「金額」這個冗餘欄位,可以提高查詢統計的速度,這就是以空間換時間的作法。
在Rose 2002中,規定列有兩種類型:數據列和計算列。「金額」這樣的列被稱為「計算列」,而「單價」和「數量」這樣的列被稱為「數據列」。
表1 商品表的表結構
商品名稱 商品型號 單價 數量 金額
電視機 29? 2,500 40 100,000
5. 通俗地理解三個範式
通俗地理解三個範式,對於資料庫設計大有好處。在資料庫設計中,為了更好地應用三個範式,就必須通俗地理解三個範式(通俗地理解是夠用的理解,並不是最科學最准確的理解):
第一範式:1NF是對屬性的原子性約束,要求屬性具有原子性,不可再分解;
第二範式:2NF是對記錄的惟一性約束,要求記錄有惟一標識,即實體的惟一性;
第三範式:3NF是對欄位冗餘性的約束,即任何欄位不能由其他欄位派生出來,它要求欄位沒有冗餘.
沒有冗餘的資料庫設計可以做到。但是,沒有冗餘的資料庫未必是最好的資料庫,有時為了提高運行效率,就必須降低範式標准,適當保留冗餘數據。具體做法是:在概念數據模型設計時遵守第三範式,降低範式標準的工作放到物理數據模型設計時考慮。降低範式就是增加欄位,允許冗餘。
6. 要善於識別與正確處理多對多的關系
若兩個實體之間存在多對多的關系,則應消除這種關系。消除的辦法是,在兩者之間增加第三個實體。這樣,原來一個多對多的關系,現在變為兩個一對多的關系。要將原來兩個實體的屬性合理地分配到三個實體中去。這里的第三個實體,實質上是一個較復雜的關系,它對應一張基本表。一般來講,資料庫設計工具不能識別多對多的關系,但能處理多對多的關系。
〖例3〗:在「圖書館信息系統」中,「圖書」是一個實體,「讀者」也是一個實體。這兩個實體之間的關系,是一個典型的多對多關系:一本圖書在不同時間可以被多個讀者借閱,一個讀者又可以借多本圖書。為此,要在二者之間增加第三個實體,該實體取名為「借還書」,它的屬性為:借還時間、借還標志(0 表示借書,1表示還書),另外,它還應該有兩個外鍵(「圖書」的主鍵,「讀者」的主鍵),使它能與「圖書」和「讀者」連接。
7. 主鍵PK的取值方法
PK是供程序員使用的表間連接工具,可以是一無物理意義的數字串, 由程序自動加1來實現。也可以是有物理意義的欄位名或欄位名的組合。不過前者比後者好。當PK是欄位名的組合時,建議欄位的個數不要太多,多了不但索引佔用空間大,而且速度也慢。
8. 正確認識數據冗餘
主鍵與外鍵在多表中的重復出現, 不屬於數據冗餘,這個概念必須清楚,事實上有許多人還不清楚。非鍵欄位的重復出現, 才是數據冗餘!而且是一種低級冗餘,即重復性的冗餘。高級冗餘不是欄位的重復出現,而是欄位的派生出現。
〖例4〗:商品中的「單價、數量、金額」三個欄位,「金額」就是由「單價」乘以「數量」派生出來的,它就是冗餘,而且是一種高級冗餘。冗餘的目的是為了提高處理速度。只有低級冗餘才會增加數據的不一致性,因為同一數據,可能從不同時間、地點、角色上多次錄入。因此,我們提倡高級冗餘(派生性冗餘),反對低級冗餘(重復性冗餘)。
9. E--R圖沒有標准答案
信息系統的E--R圖沒有標准答案,因為它的設計與畫法不是惟一的,只要它覆蓋了系統需求的業務范圍和功能內容,就是可行的。反之要修改E-- R圖。盡管它沒有惟一的標准答案,並不意味著可以隨意設計。好的E?R圖的標準是:結構清晰、關聯簡潔、實體個數適中、屬性分配合理、沒有低級冗餘。
10. 視圖技術在資料庫設計中很有用
與基本表、代碼表、中間表不同,視圖是一種虛表,它依賴數據源的實表而存在。視圖是供程序員使用資料庫的一個窗口,是基表數據綜合的一種形式, 是數據處理的一種方法,是用戶數據保密的一種手段。為了進行復雜處理、提高運算速度和節省存儲空間, 視圖的定義深度一般不得超過三層。若三層視圖仍不夠用, 則應在視圖上定義臨時表, 在臨時表上再定義視圖。這樣反復交迭定義, 視圖的深度就不受限制了。
對於某些與國家政治、經濟、技術、軍事和安全利益有關的信息系統,視圖的作用更加重要。這些系統的基本表完成物理設計之後,立即在基本表上建立第一層視圖,這層視圖的個數和結構,與基本表的個數和結構是完全相同。並且規定,所有的程序員,一律只准在視圖上操作。只有資料庫管理員,帶著多個人員共同掌握的「安全鑰匙」,才能直接在基本表上操作。請讀者想想:這是為什麼?
11. 中間表、報表和臨時表
中間表是存放統計數據的表,它是為數據倉庫、輸出報表或查詢結果而設計的,有時它沒有主鍵與外鍵(數據倉庫除外)。臨時表是程序員個人設計的,存放臨時記錄,為個人所用。基表和中間表由DBA維護,臨時表由程序員自己用程序自動維護。
12. 完整性約束表現在三個方面
域的完整性:用Check來實現約束,在資料庫設計工具中,對欄位的取值范圍進行定義時,有一個Check按鈕,通過它定義欄位的值城。參照完整性:用PK、FK、表級觸發器來實現。用戶定義完整性:它是一些業務規則,用存儲過程和觸發器來實現。
13. 防止資料庫設計打補丁的方法是「三少原則」
(1) 一個資料庫中表的個數越少越好。只有表的個數少了,才能說明系統的E--R圖少而精,去掉了重復的多餘的實體,形成了對客觀世界的高度抽象,進行了系統的數據集成,防止了打補丁式的設計;
(2) 一個表中組合主鍵的欄位個數越少越好。因為主鍵的作用,一是建主鍵索引,二是做為子表的外鍵,所以組合主鍵的欄位個數少了,不僅節省了運行時間,而且節省了索引存儲空間;
(3) 一個表中的欄位個數越少越好。只有欄位的個數少了,才能說明在系統中不存在數據重復,且很少有數據冗餘,更重要的是督促讀者學會「列變行」,這樣就防止了將子表中的欄位拉入到主表中去,在主表中留下許多空餘的欄位。所謂「列變行」,就是將主表中的一部分內容拉出去,另外單獨建一個子表。這個方法很簡單,有的人就是不習慣、不採納、不執行。
資料庫設計的實用原則是:在數據冗餘和處理速度之間找到合適的平衡點。「三少」是一個整體概念,綜合觀點,不能孤立某一個原則。該原則是相對的,不是絕對的。「三多」原則肯定是錯誤的。試想:若覆蓋系統同樣的功能,一百個實體(共一千個屬性) 的E--R圖,肯定比二百個實體(共二千個屬性) 的E--R圖,要好得多。
提倡「三少」原則,是叫讀者學會利用資料庫設計技術進行系統的數據集成。數據集成的步驟是將文件系統集成為應用資料庫,將應用資料庫集成為主題資料庫,將主題資料庫集成為全局綜合資料庫。集成的程度越高,數據共享性就越強,信息孤島現象就越少,整個企業信息系統的全局E?R圖中實體的個數、主鍵的個數、屬性的個數就會越少。
提倡「三少」原則的目的,是防止讀者利用打補丁技術,不斷地對資料庫進行增刪改,使企業資料庫變成了隨意設計資料庫表的「垃圾堆」,或資料庫表的「大雜院」,最後造成資料庫中的基本表、代碼表、中間表、臨時表雜亂無章,不計其數,導致企事業單位的信息系統無法維護而癱瘓。
「三多」原則任何人都可以做到,該原則是「打補丁方法」設計資料庫的歪理學說。「三少」原則是少而精的原則,它要求有較高的資料庫設計技巧與藝術,不是任何人都能做到的,因為該原則是杜絕用「打補丁方法」設計資料庫的理論依據。
14. 提高資料庫運行效率的辦法
在給定的系統硬體和系統軟體條件下,提高資料庫系統的運行效率的辦法是:
(1) 在資料庫物理設計時,降低範式,增加冗餘, 少用觸發器, 多用存儲過程。
(2) 當計算非常復雜、而且記錄條數非常巨大時(例如一千萬條),復雜計算要先在資料庫外面,以文件系統方式用C++語言計算處理完成之後,最後才入庫追加到表中去。這是電信計費系統設計的經驗。
(3) 發現某個表的記錄太多,例如超過一千萬條,則要對該表進行水平分割。水平分割的做法是,以該表主鍵PK的某個值為界線,將該表的記錄水平分割為兩個表。若發現某個表的欄位太多,例如超過八十個,則垂直分割該表,將原來的一個表分解為兩個表。
(4) 對資料庫管理系統DBMS進行系統優化,即優化各種系統參數,如緩沖區個數。
(5) 在使用面向數據的SQL語言進行程序設計時,盡量採取優化演算法。
總之,要提高資料庫的運行效率,必須從資料庫系統級優化、資料庫設計級優化、程序實現級優化,這三個層次上同時下功夫。
『陸』 資料庫設計說明書的介紹
資料庫設計說明書是對旦氏於設計中的資料庫的所有標識.歷並邏輯結構和物理結構做出具體的設計規定。肢遲跡
『柒』 求一份圖書管理系統的資料庫設計方案
1. 對圖書館的信息建幾個表,考慮表之間的關系。
2.系統功能的基本要求:
a) 對資料庫的編輯功能:對圖書館信息記錄的添加、修改、刪除。
b) 對圖書的統計(國內圖書、國外圖書、計算機圖書、外語圖書、中文圖等各類圖書的統計)。
c) 對圖書的查詢(按關鍵字查詢、模糊查詢等);
d) 對報表的列印;
e) 界面友好。
1、概述
包括項目背景、編寫目的、軟體定義、開發環境等內容。
2、需求分析
問題陳述、需完成的功能。
用數據流圖、數據字典、判斷樹等完成。
3、資料庫概念設計
畫出ER模型圖
4、資料庫邏輯設計
把ER模型圖轉換為關系表。
描述每一個基本表關系。要求所有關系達到BCNF範式。
定義視圖、定義索引、主關鍵字、定義許可權。
5 物理設計
主要用到存取方法
6、結束語
寫出完成本課程設計的心得,領會資料庫理論與軟體開發實踐的關系。有哪些收獲。軟體還需要哪些改進。
設計結果:設計報告,源程序代碼。
『捌』 乙太網、視圖、黑盒測試,軟體完成提交什麼文檔給客戶
乙太網、視圖、黑盒測試,軟體完成提交文檔給客戶如下所示
1.需求分析說明書
2.系統詳細設計說斗凳明書空顫旅
3.系統資料庫設計說明書
4.系統測試報告
5.系統使用說明洞鍵書
6.系統質量驗收評定等
『玖』 資料庫設計說明書,由誰編寫,寫給誰看
開發團隊
如果你們對於資料庫和應用程序的開發有分工的話,那麼所有關於資料庫方面的都有資料庫那邊的人寫,如春弊行果沒有分工,就你們自己寫
存檔的目的一個是便於團隊之間的溝通,再一個就是方便事後對程序或者數卜則據庫進行修正升級等, 會有一定記錄來告訴你資料庫中各個表欄位等都是什麼含義,以及他們之間的關系, 尤其對一些年久失扒嘩修的應用程序來說,就不用全部看代碼了