1. 軟體詳細設計說明書
面向對象軟體設計說明書模板
1 概述
1.1 系統簡述
對系統要完成什麼，所面向的用戶以及系統運行的環境的簡短描述，這部分主要來源於需求說明書的開始部分。
1.2 軟體設計目標
這部分論述整個系統的設計目標，明確地說明哪些功能是系統決定實現而哪些時不準備實現的。同時，對於非功能性的需求例如性能、可用性等，亦需提及。需求規格說明書對於這部分的內容來說是很重要的參考，看看其中明確了的功能性以及非功能性的需求。
這部分必須說清楚設計的全貌如何，務必使讀者看後知道將實現的系統有什麼特點和功能。在隨後的文檔部分，將解釋設計是怎麼來實現這些的。
1.3 參考資料
列出本文檔中所引用的參考資料。（至少要引用需求規格說明書）
1.4 修訂版本記錄
列出本文檔修改的歷史紀錄。必須指明修改的內容、日期以及修改人。
2 術語表
對本文檔中所使用的各種術語進行說明。如果一些術語在需求規格說明書中已經說明過了，此處不用再重復，可以指引讀者參考需求說明。
3 用例
此處要求系統用用例圖表述（UML），對每個用例（正常處理的情況）要有中文敘述。
4 設計概述
4.1 簡述
這部分要求突出整個設計所採用的方法（是面向對象設計還是結構化設計）、系統的體系結構（例如客戶/伺服器結構）以及使用到的相應技術和工具（例如OMT、Rose）
4.2 系統結構設計
這部分要求提供高層系統結構的描述，使用方框圖來顯示主要的組件及組件間的交互。最好是把邏輯結構同物理結構分離，對前者進行描述。別忘了說明圖中用到的俗語和符號。
4.2.1 頂層系統結構
4.2.2 子系統1結構
4.2.3 子系統2結構
4.3 系統界面
各種提供給用戶的界面以及外部系統在此處要予以說明。如果在需求規格說明書中已經對用戶界面有了敘述，此處不用再重復，可以指引讀者參考需求說明。如果系統提供了對其它系統的介面，比如說從其它軟體系統導入/導出數據，必須在此說明。
4.4 約束和假定
描述系統設計中最主要的約束，這些是由客戶強制要求並在需求說明書寫明的。說明系統是如何來適應這些約束的。
另外如果本系統跟其它外部系統交互或者依賴其它外部系統提供一些功能輔助，那麼系統可能還受到其它的約束。這種情況下，要求清楚地描述與本系統有交互的軟體類型（比如某某某資料庫軟體，某某某EMail軟體）以及這樣導致的約束（比如只允許純文本的Email）。
實現的語言和平台也會對系統有約束，同樣在此予以說明。
對於因選擇具體的設計實現而導致對系統的約束，簡要地描述你的想法思路，經過怎麼樣的權衡，為什麼要採取這樣的設計等等。
5 對象模型
5.1 系統對象模型
提供整個系統的對象模型，如果模型過大，按照可行的標准把它劃分成小塊，例如可以把客戶端和伺服器端的對象模型分開成兩個圖表述。
對象圖應該包含什麼呢？
在其中應該包含所有的系統對象。這些對象都是從理解需求後得到的。要明確哪些應該、哪些不應該被放進圖中。
所有對象之間的關聯必須被確定並且必須指明聯系的基數（一對一、一對多還是多對多，0..1，*，1..*）。聚合和繼承關系必須清楚地確定下來。每個圖必須附有簡單的說明。
可能經過多次反復之後才能得到系統的正確的對象模型。
6 對象描述
在這個部分敘述每個對象的細節，它的屬性、它的方法。在這之前必須從邏輯上對對象進行組織。你可能需要用結構圖把對象按子系統劃分好。
為每個對象做一個條目。在系統對象模型中簡要的描述它的用途、約束（如只能有一個實例），列出它的屬性和方法。如果對象是存儲在持久的數據容器中，標明它是持久對象，否則說明它是個臨時對象（transient object）。
對每個對象的每個屬性詳細說明：名字、類型，如果屬性不是很直觀或者有約束（例如，每個對象的該屬性必須有一個唯一的值或者值域是有限正整數等）。
對每個對象的每個方法詳細說明：方法名，返回類型，返回值，參數，用途以及使用的演算法的簡要說明（如果不是特別簡單的話）。如果對變數或者返回值由什麼假定的話，Pre-conditions和Post-conditions必須在此說明。列出它或者被它調用的方法需要訪問或者修改的屬性。最後，提供可以驗證實現方法的測試案例。
6.1 子系統1中的對象
6.1.1 對象：對象1
用途：
約束：
持久性：
6.1.1.1 屬性描述：
1. 屬性：屬性1
類型：
描述：
約束：
2. 屬性：屬性2
6.1.1.2 方法描述：
1. 方法：方法1
返回類型：
參數：
返回值：
Pre-Condition：
Post-Condition：
讀取/修改的屬性：
調用的方法：
處理邏輯：
測試例：用什麼參數調用該方法，期望的輸出是什麼……
7 動態模型
這部分的作用是描述系統如何響應各種事件。例如，可以建立系統的行為模型。一般使用順序圖和狀態圖。
確定不同的場景（Scenario）是第一步，不需要確定所有可能的場景，但是必須至少要覆蓋典型的系統用例。不要自己去想當然地創造場景，通常的策略是描述那些客戶可以感受得到的場景。
7.1 場景（Scenarios）
對每個場景做一則條目，包括以下內容：
場景名：給它一個可以望文生義的名字
場景描述：簡要敘述場景是干什麼的以及發生的動作的順序。
順序圖：描述各種事件及事件發生的相對時間順序。
7.1.1 場景：場景1
描述：
動作1
動作2
7.2 狀態圖
這部分的內容包括系統動態模型重要的部分的狀態圖。可能你想為每個對象畫一個狀態圖，但事實上會導致太多不期望的細節信息，只需要確定系統中一些重要的對象並為之提供狀態圖即可。
7.2.1 狀態圖1：
8 非功能性需求
在這個部分，必須說明如何處理需求文檔中指定的非功能性需求。盡可能客觀地評估系統應付每一個非功能性的需求的能力程度。如果某些非功能性需求沒有完全在設計的系統中實現，請務必在此說明。另外，你也需要對系統將來的進化作一個估計並描述本設計如何使系統能夠適應這些可預見的變化。
9 輔助文檔
提供能幫助理解設計的相應文檔。
10 詞彙索引
文章錄入
2. 軟體開發中宿舍管理系統的資料庫設計說明書該怎麼寫
1.簡介（目的，參考術語、資料庫環境要求、資料庫命名規則）
2.結構設計（邏輯結構設計、物理結構設計（設計一覽表、具體的表信息（畫個表格寫上表名、列明、說明、類型、書否為空、約束條件）））
3.安全性設計
4.數據的優化 維護說明..
..
我有資料庫設計說明書
3. 求一份圖書管理系統的資料庫設計方案
1． 對圖書館的信息建幾個表，考慮表之間的關系。
2．系統功能的基本要求：
a) 對資料庫的編輯功能：對圖書館信息記錄的添加、修改、刪除。
b) 對圖書的統計（國內圖書、國外圖書、計算機圖書、外語圖書、中文圖等各類圖書的統計）。
c) 對圖書的查詢（按關鍵字查詢、模糊查詢等）；
d) 對報表的列印；
e) 界面友好。
1、概述
包括項目背景、編寫目的、軟體定義、開發環境等內容。
2、需求分析
問題陳述、需完成的功能。
用數據流圖、數據字典、判斷樹等完成。
3、資料庫概念設計
畫出ER模型圖
4、資料庫邏輯設計
把ER模型圖轉換為關系表。
描述每一個基本表關系。要求所有關系達到BCNF範式。
定義視圖、定義索引、主關鍵字、定義許可權。
5 物理設計
主要用到存取方法
6、結束語
寫出完成本課程設計的心得，領會資料庫理論與軟體開發實踐的關系。有哪些收獲。軟體還需要哪些改進。
設計結果：設計報告，源程序代碼。
4. 資料庫應用系統設計的四個層次分別包含的內容是什麼它們屬於哪個設計階段求詳細解答，跪謝～～
表示層
負責直接跟用戶進行交互，一般也就是指系統的界面，用於數據錄入，數據顯示等。意味著只做與外觀顯示相關的工作，不屬於他的工作不用做。
（概念設計）
業務邏輯層
用於做一些有效性驗證的工作，以更好地保證程序運行的健壯性。不允許指定的文本框中輸入空字元串，數據格式是否正確及數據類型驗證；用戶的許可權的合法性判斷等等
（邏輯設計）
數據訪問層
就是用於專門跟資料庫進行交互。執行數據的添加、刪除、修改和顯示等。所有的數據對象只在這一層被引用。
（邏輯設計）
數據持久層
數據的組織存儲等方面的設計
（物理設計階段）
來自川理-jax-朱哥哥的回答。
5. 資料庫設計說明書的檢查
·是否包含對本工程及資料庫設計說明書的背景說明。包括編寫目的．背景．定義．參考資料等。
·是否包含對外部設計的說明。包括標識符和狀態．使用它的程序、約定、專門指導、支持軟體等。審查全面性和業務符合性。
·是否包含對結構設計的說明。包含概念結構設計、邏輯結構設計、物理結構設計等。審查全面性和業務符合性。
·是否包含對運用設計的說明。包含數據字典設計、安全保密設計。審查全面性和業務符合性。
6. sql資料庫設計說明書
你要什麼樣的說明書？建模規范還是你自己建的資料庫的表關系什麼的詳細說明？……
7. php Moodle系統資料庫設計說明書
搜索開源網路教育平台
可以找到其他的。
8. 急！高分求做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語言進行程序設計時，盡量採取優化演算法。
總之，要提高資料庫的運行效率，必須從資料庫系統級優化、資料庫設計級優化、程序實現級優化，這三個層次上同時下功夫。
9. 資料庫設計說明書有沒有範文
正文
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安全保密設計
說明在資料庫的設計中，將如何通過區分不同的訪問者、不同的訪問類型和不同的數據對象，進行分別對待而獲得的資料庫安全保密的設計考慮。