1引言 2
1.1編寫目的 2
1.2背景 2
1.3定義 2
1.4參考資料 2
2外部設計 2
2.1識別符號和狀態 2
2.2使用它的程式 3
2.3約定 3
2.4專門指導 3
2.5支援軟體 3
3結構設計 3
3.1概念結構設計 3
3.2邏輯結構設計 3
3.3物理結構設計 4
4運用設計 4
4.1資料字典設計 4
4.2安全保密設計 4
資料庫設計說明書
本資料庫設計說明書是針對於。
說明：a． 說明待開發的資料庫的名稱和使用此資料庫的軟體系統的名稱；
b． 列出該軟體系統開發專案的任務提出者、使用者以及將安裝該軟體和這個資料庫的計算站（中心）。
列出本檔案中用到的專門術語的定義、外文首字母組詞的原片語。
列出有關的參考資料：
a． 本專案的經核准的計畫任務書或合同、上級機關批文；
b． 屬於本專案的其他已發表的檔案；
c． 本檔案中各處引用到的檔案資料，包括所要用到的軟體開發標準。
列出這些檔案的標題、檔案編號、發表日期和出版單位，說明能夠取得這些檔案的**。
聯絡用途，詳細說明用於唯一地標識該資料庫的**、名稱或識別符號，附加的描述性資訊亦要給出。如果該資料庫屬於尚在實驗中、尚在測試中或是暫時使用的，則要說明這一特點及其有效時間範圍。
列出將要使用或訪問此資料庫的所有應用程式，對於這些應用程式的每乙個，給出它的名稱和版本號。
陳述乙個程式設計師或乙個系統分析員為了能使用此資料庫而需要了解的建立標號、標識的約定，例如用於標識資料庫的不同版本的約定和用於標識庫內各個文捲、、記錄、資料項的命名約定等。
向準備從事此資料庫的生成、從事此資料庫的測試、維護人員提供專門的指導，例如將被送入資料庫的資料的格式和標準、送入資料庫的操作規程和步驟，用於產生、修改、更新或使用這些資料文捲的操作指導。如果這些指導的內容篇幅很長，列出可參閱的檔案資料的名稱和章條。
簡單介紹同此資料庫直接有關的支援軟體，如資料庫管理系統、儲存定位程式和用於裝入、生成、修改、更新資料庫的程式等。說明這些軟體的名稱、版本號和主要功能特性，如所用資料模型的型別、允許的資料容量等。列出這些支援軟體的技術檔案的標題、編號及**。
1. 產品
● 系統採用了迴圈指標的方式設計了產品的基本資訊表：
其中：up_product_id是指上層的產品的編號：t_product中的product_id
產品類別反映了此產品或產品組（含下級產品）為主機類產品還是配角類產品或只是反映產品的大類，在軟體開發時如果上級產品組類別修改（主機或配件）了其產品組和其下級產品組的類別也要相應修改（建議使用觸發器）。對於產品組類別修改的大類產品則其下產品無需修改其產品類別。
● 產品配置表
產品配置表反映的是主機類產品的配置資訊，乙個主機類產品可以有多種的配置情況，系統設計時採用了主從表表，主表為t_product_conf，從表為t_product_conf_parts.
注：t_product_conf_parts可以是產品表中的任意產品包括主機，配件，也包括大類產品。
2. 組織架構
系統的組織架構有兩套,人事架構和工作構架。
人事構架：用於職工在公司的中的職位和上下級的關係，因此主要用於報銷系統中。
工作構架：是指職工在公司的工作中的實際的職位。主要用於銷售系統和管理系統中。
無論是人事架構還是工作架構系統都採用了迴圈指標的方式進行設計。
人事構架的表結構如下：
t_staf：是員工的基本資訊
t_oraganize_role：人事組織架構角色
t_staff_***anize_role：哪個員工在組織架構中角色所在的時間。（不容許乙個員工在同一時間內擁有多個角色，不容許乙個角色在乙個時間點上擁有多個員工）
工作架構的表結構如下：
t_role：工作架構
t_staff_***anize_role：哪個員工在工作架構中角色所在的時間。（容許乙個員工在同一段時間內擁有多個角色，但不容許乙個角色在乙個時間點上擁有多個員工）
t_role_geo：角色在指定的時間內負責的區域。
3. 公司情況
公司情況主要是指磅礴的總公司和各分公司的基本情況和相互的關係。
公司表包括：
t_***pany：公司的基本資訊表，其中公司類別反映的是總公司還是分公司
縮寫：為3位公司縮寫比填
t_department：部門資訊表
t_***pany_department_relation：反映的是公司和部門的關係表，即每個公司下面有哪些部門
t_***pany_product_relation：反映的是公司和產品的關係，即此公司可以銷售那些產品，在t_role中的角色可以選擇和查詢的產品。
4. 客戶資訊
客戶是指和公司銷售和維修有關的公司，表結構如下：
t_custom:客戶的基本資訊
t_custom_alias:和此客戶有關的其別名包括不同的帳號、位址等資訊
5. **商資訊
**商的基本資訊和**商產品的指導**
6. 合同
● 合同基本資訊表
合同編號：cont+3位公司縮寫+4位年+2位月+3位序號+』_』+2位修改次數
合同狀態： 1-儲存 2-提交 3-審批過程 4-審批通過 5-退回 6-取消 7-合同完成
合同型別：包括銷售合同，維修合同等。
角色編號：是指簽訂此合同的角色。
修改次數：是指每次銷售提交後被退回後修改的次數，同時系統要求能儲存每次修改的資料。
● 合同產品
合同產品為合同的基本內容，修改必須通過審批。
● 合同預計支付情況
由銷售填寫，同時可以在合同執行中進行修改。
● 合同預計發貨情況
由銷售填寫，同時可以在合同執行中進行修改。
● 合同實際支付情況
由公司財務人員填寫實際支付情況
7. 採購
● 採購申請單
t_apply_purchase:
申請型別：1-倉庫，2-備件自動產生，3-子公司向總公司申請，4-合同
合同號：只對於合同型別的申請
上級申請單編號：子公司向總公司申請單據時的總公司的申請單號。
說明把上述原始資料進行分解、合併後重新組織起來的資料庫全域性邏輯結構，包括所確定的關鍵字和屬性、重新確定的記錄結構和文捲結構、所建立的各個文捲之間的相互關係，形成本資料庫的資料庫管理員檢視。
建立系統程式設計師檢視，包括：
a． 資料在記憶體中的安排，包括對索引區、緩衝區的設計；
b． 所使用的外存裝置及外存空間的組織，包括索引區、資料塊的組織與劃分；
c． 訪問資料的方式方法。
對資料庫設計中涉及到的各種專案，如資料項、記錄、系、文捲、模式、子模式等一般要建立起資料字典，以說明它們的識別符號、同義名及有關資訊。在本節中要說明對此資料字典設計的基本考慮。
說明在資料庫的設計中，將如何通過區分不同的訪問者、不同的訪問型別和不同的資料物件，進行分別對待而獲得的資料庫安全保密的設計考慮。
超市銷售管理系統資料庫設計說明書
1引言 2 1.1編寫目的 2 1.2背景 2 1.3定義 2 1.4參考資料 2 2外部設計 2 2.1識別符號和狀態 2 2.2使用它的程式 3 2.3約定 3 2.4專門指導 3 2.5支援軟體 3 3結構設計 3 3.1概念結構設計 3 3.2邏輯結構設計 4 3.3物理結構設計 5 4運用...
超市管理系統資料庫設計說明書
1引言 2 1.1編寫目的 2 1.2背景 2 1.3定義 2 1.4參考資料 2 2外部設計 3 2.1識別符號和狀態 3 2.2使用它的程式 3 2.3約定 3 2.4專門指導 3 2.5支援軟體 3 3結構設計 4 3.1概念結構設計 4 3.2邏輯結構設計 5 3.3物理結構設計 5 4運用...
超市管理系統資料庫設計說明書
1引言1.1編寫目的 為了提高物資管理的水平和工作效率，盡可能杜絕商品流通中各環節中可能出現的資金流失不明現象，商品進銷存領域迫切需要引入資訊系統來加以管理。從該階段開發正式進入軟體的實際開發階段，本階段完成系統的大致設計並明確系統的資料結構與軟體結構。在軟體設計階段主要是把乙個軟體需求轉化為軟體表...