資料庫設計項目

A. 資料庫開發現在有什麼項目

資料庫開發是資料庫管理系統(DBMS)和資料庫應用軟體設計研發的總稱，數據運維、參與資料庫生產環境的問題優化和解決等方面的事宜。

一般資料庫開發要經過設計、開發資料庫系統和資料庫應用軟體，因此與軟體研發的過程一樣，會覆蓋需求、設計、編程和測試四個階段：

• 需求：深入調研用戶市場需求，認清項目的應用場景，解決的問題，性能指標等，需要與資料庫系統使用方反復溝通，確定具體的需求。

• 設計：根據收集整理的需求文檔設計資料庫系統軟體的模型和架構，劃分模塊分別進行概要和詳細設計。

• 編程：按照模塊分工和設計文檔，進行編碼和調試。

• 測試：將開發完成的資料庫系統交給測試人員進行測試，主要使用的測試方法有黑盒測試、白盒測試、壓力測試、性能測試等，測試全部通過後即可等待發布。

B. 資料庫設計

說起資料庫設計，相信大家都明白怎麼回事，但說起資料庫設計的重要性，我想大家也只是停留在概念上而已，到底如何重要？怎麼重要呢？今天就將我至今為止的理解向大家闡述下。
一個不良的資料庫設計，必然會造成很多問題，輕則增減欄位，重則系統無法運行。我先來說說資料庫設計不合理的表現吧：
1. 與需求不符
因為這個原因造成的改動量往往是最大。如果進入編碼階段的話，很可能會直接讓你崩潰掉。
2. 性能低下
含有大數據量的表之間的關聯過多；沒有合理的欄位設計來用於查詢而造成的SQL查詢語句很復雜；對於大數據量的表沒有採用有效的手段去處理；濫用視圖等。
3. 數據完整性喪失
含有主外鍵關系的表之間關聯欄位的設計方式不合理，造成更新與刪除操作後程序容易出錯或不完善；使用了已經刪除或丟失掉的數據。
4. 可擴展性性太差
表設計的與業務綁定的太緊密、單一，造成表的可拓展性、可修改性太差，無法新需求的要求。
5. 非必要數據冗餘量太大
沒用的垃圾數據存儲過多，不僅佔用資源，還影響查詢效率。
6. 不利於計算或統計
缺少必要的聯系性或統計性欄位或用於計算統計的欄位分散於多個表中，造成計算統計的步驟繁瑣，甚至無法計算統計。
7. 沒有詳盡的數據記錄信息
缺少必要的欄位，造成無法跟蹤數據變化、用戶操作，也無法進行數據分析。
8. 表之間的耦合性太大
多張表之間關聯的過於緊密，造成一張表發生變化而影響到其他表。
9. 欄位設計考慮不周
欄位長度過短或欄位類型過於明確，造成可發揮、可拓展的空間太小。
大多數的程序員對於軟體開發的出發點認識不是很明確，總是認為實現功能才是重要的，在簡單了解完基本需求後就急忙進入編碼階段，對於資料庫設計思考的比較少、比較簡單，大多設計都只停留在表面上，這往往是要命的，會為系統留下很多隱患。要麼是寫代碼開發過程中才發現問題，要麼就是系統上線運轉後沒多久就出現問題，還有可能給後期維護增加了很多工作量。如果到了那個時候再想修改資料庫設計或進行優化等同於推翻重來。
資料庫是整個軟體應用的根基，是軟體設計的起點，它起著決定性的質變作用，因此我們必須對資料庫設計高度重視起來，培養設計良好資料庫的習慣，是一個優秀的軟體設計師所必須具備的基本素質條件！
那麼我們要做到什麼程度才是對的呢？下面就說說資料庫設計的原則
1. 資料庫設計最起碼要佔用整個項目開發的40%以上的時間
資料庫是需求的直觀反應和表現，因此設計時必須要切實符合用戶的需求，要多次與用戶溝通交流來細化需求，將需求中的要求和每一次的變化都要一一體現在資料庫的設計當中。如果需求不明確，就要分析不確定的因素，設計表時就要事先預留出可變通的欄位，正所謂「有備無患」。
2. 資料庫設計不僅僅停留於頁面demo的表面
頁面內容所需要的欄位，在資料庫設計中只是一部分，還有系統運轉、模塊交互、中轉數據、表之間的聯系等等所需要的欄位，因此資料庫設計絕對不是簡單的基本數據存儲，還有邏輯數據存儲。
3. 資料庫設計完成後，項目80%的設計開發在你腦海中就已經完成了
每個欄位的設計都是有他必要的意義的，你在設計每一個欄位的同時，就應該已經想清楚程序中如何去運用這些欄位，多張表的聯系在程序中是如何體現的。換句話說，你完成資料庫設計後，程序中所有的實現思路和實現方式在你的腦海中就已經考慮過了。如果達不到這種程度，那當進入編碼階段後，才發現要運用的技術或實現的方式資料庫無法支持，這時再改動資料庫就會很麻煩，會造成一系列不可預測的問題。
4. 資料庫設計時就要考慮到效率和優化問題
一開始就要分析哪些表會存儲較多的數據量，對於數據量較大的表的設計往往是粗粒度的，也會冗餘一些必要的欄位，已達到盡量用最少的表、最弱的表關系去存儲海量的數據。並且在設計表時，一般都會對主鍵建立聚集索引，含有大數據量的表更是要建立索引以提供查詢性能。對於含有計算、數據交互、統計這類需求時，還要考慮是否有必要採用存儲過程。
5. 添加必要的（冗餘）欄位
像「創建時間」、「修改時間」、「備注」、「操作用戶IP」和一些用於其他需求（如統計）的欄位等，在每張表中必須都要有，不是說只有系統中用到的數據才會存到資料庫中，一些冗餘欄位是為了便於日後維護、分析、拓展而添加的，這點是非常重要的，比如黑客攻擊，篡改了數據，我們便就可以根據修改時間和操作用戶IP來查找定位。
6. 設計合理的表關聯
若多張表之間的關系復雜，建議採用第三張映射表來關聯維護兩張表之間的關系，以降低表之間的直接耦合度。若多張表涉及到大數據量的問題，表結構盡量簡單，關聯也要盡可能避免。
7. 設計表時不加主外鍵等約束性關聯，系統編碼階段完成後再添加約束性關聯
這樣做的目的是有利於團隊並行開發，減少編碼時所遇到的問題，表之間的關系靠程序來控制。編碼完成後再加關聯並進行測試。不過也有一些公司的做法是乾脆就不加表關聯。
8. 選擇合適的主鍵生成策略
主鍵生成策略大致可分：int自增長類型（identity、sequence）、手動增長類型（建立單獨一張表來維護）、手動維護類型（如userId）、字元串類型（uuid、guid）。int型的優點是使用簡單、效率高，但多表之間數據合並時就很容易出現問題，手動增長類型和字元串類型能很好解決多表數據合並的問題，但同樣也都有缺點：前者的缺點是增加了一次資料庫訪問來獲取主鍵，並且又多維護一張主鍵表，增加了復雜度；而後者是非常佔用存儲空間，且表關聯查詢的效率低下，索引的效率也不高，跟int類型正好相反。
終上所述，我們可見資料庫設計在整個軟體開發的起到的舉足輕重的作用，尤其是我說的設計原則的第一點，資料庫與需求是相輔相成的，我經常把軟體開發比作汽車製造。汽車製造會經過圖紙設計，模型製作，樣車製造，小批量試生產，最後是批量生產等步驟。整個過程環環相扣，後一過程是建立在前一過程正確的前提基礎之上的。如果在圖紙設計階段發現了一個紕漏，我們可以重新進行圖紙設計，如果到了樣車製造階段發現這個錯誤，那麼我們就要把從圖紙設計到樣車製造的階段重來，越到後面發現設計上的問題，所付出的代價越大，修改的難度也越大。
資料庫設計難度其實要比單純的技術實現的難很多，他充分體現了一個人的全局設計能力和掌控能力，所以在今後的項目中大家一定要著重培養這方面的能力，這里我將我的經驗分享給了大家，希望能對大家有所幫助。

C. 項目管理系統資料庫設計

我告訴你過程：

設計思路：

1.需求分析：信息需求，處理需求，安全性和完整性要求。
2.確定需求的表。
3。確定所需的欄位：每個欄位直接和表的實體相關。以最小的邏輯單位存儲信息。表中的數據必須是原始數據。確定主關鍵字欄位。
4。確定關系。
5。設計求精

D. 如何設計資料庫

方法/步驟

• 常見資料庫設計

  

E. .資料庫設計分為幾個階段,各階段的任務是什麼

按照規范的設計方法，一個完整的資料庫設計一般分為需求分析、概念結構設計、邏輯結構設計、資料庫物理設計、資料庫的實施、資料庫運行與維護六個階段：

各階段的任務如下：

1、需求分析：分析用戶的需求，包括數據、功能和性能需求；

拓展資料：

資料庫設計(Database Design)是指對於一個給定的應用環境，構造最優的資料庫模式，建立資料庫及其應用系統，使之能夠有效地存儲數據，滿足各種用戶的應用需求(信息要求和處理要求)。在資料庫領域內，常常把使用資料庫的各類系統統稱為資料庫應用系統。

資料庫設計是建立資料庫及其應用系統的技術，是信息系統開發和建設中的核心技術。由於資料庫應用系統的復雜性，為了支持相關程序運行，資料庫設計就變得異常復雜，因此最佳設計不可能一蹴而就，而只能是一種"反復探尋，逐步求精"的過程，也就是規劃和結構化資料庫中的數據對象以及這些數據對象之間關系的過程。

F. 資料庫設計步驟求解

資料庫設計步驟：1規劃 2需求分析 3概念設計 4邏輯結構設計 5資料庫的物理設計 6資料庫的實現 7資料庫的運行與維護
第一步，規劃。規劃階段的主要任務是進行建立資料庫的必要性及可行性分析。如系統調查（即對企業全面調查，畫出組織層次圖，以了企業組織結構），可行性分析，確定DBS（資料庫系統）的總目標和制定項目開發計劃。
第二步，需求分析。需求分析階段應該對系統的整個應用情況作全面的、詳細的調查，確定企業組織的目標，收集支持系統總的設計目標的基礎數據和對這些數據的要求，確定用戶的需求，並把這些要求寫成用戶和資料庫設計者都能夠接受的需求分析報告。這一階段的工作只要有，分析用戶活動，產生業務流程圖；確定系統范圍，產生體統范圍圖；分析用戶活動涉及的數據，產生數據流程圖；分析系統數據，產生數據字典。
第三步，概念設計。概念設計的目標是產生反應企業組織信息需求的資料庫概念結構,即設計出獨立與計算機硬體和DBMS（資料庫管理系統）的概念模式。E-R模型是主要設計工具。
第四步，邏輯結構設計。其目的是把概念設計階段設計好的全局E-R模式轉換成與選用的具體機器上的DBMS所支持的數據模型相符合的邏輯結構（包括資料庫模式和外模式）。
第五步，資料庫的物理設計。對於給定的數據模型選取一個最適合應用應用環境的物理結構的過程。資料庫的物理結構主要指資料庫的存儲記錄格式、存儲記錄安排和存取方法，完全依賴於給定的硬體環境赫爾資料庫產品。
第六步，資料庫的實現。該階段主要有3項工作：1建立實際資料庫結構 2裝入試驗數據對應用程序進行調試 3裝入實際數據，進入試運行狀態。
第七步，資料庫的運行與維護。資料庫系統的正式運行，標志著資料庫設計與應用開發工作的結束和維護階段的開始，該階段有4項任務：1維護資料庫的安全性與完整性 2監測並改善資料庫運行性能 3根據用戶要求對資料庫現有功能進行擴充 4及時改正運行中發現的系統錯誤。
其實裡麵包含有其他的知識，我沒列出來，例如E-R圖繪制方法，SQL，還有會涉及關鍵字，外鍵，視圖，表，模式等，如果是想自學的話，我推薦一本書《資料庫原理及應用》，這是我學資料庫時的教材，有疑問，可以hi我，我盡我所能回答你吧。

G. 資料庫課程設計實例

資料庫課程設計

題目：小型超市管理系統
1、項目計劃
1.1系統開發目的
（1）大大提高超市的運作效率；
（2）通過全面的信息採集和處理，輔助提高超市的決策水平；
（3）使用本系統，可以迅速提升超市的管理水平，為降低經營成本， 提高效益，增強超市擴張力， 提供有效的技術保障。
1.2背景說明
21世紀，超市的競爭也進入到了一個全新的領域，競爭已不再是規模的競爭，而是技術的競爭、管理的競爭、人才的競爭。技術的提升和管理的升級是超市業的競爭核心。零售領域目前呈多元發展趨勢，多種業態：超市、倉儲店、便利店、特許加盟店、專賣店、貨倉等相互並存。如何在激烈的競爭中擴大銷售額、降低經營成本、擴大經營規模，成為超市營業者努力追求的目標。
1.3項目確立
針對超市的特點，為了幫助超市解決現在面臨的問題，提高小型超市的競爭力，我們將開發以下系統：前台POS銷售系統、後台管理系統，其中這兩個子系統又包含其它一些子功能。
1.4應用范圍
本系統適應於各種小型的超市。
1.5 定義
（1）商品條形碼：每種商品具有唯一的條形碼，對於某些價格一樣的商品，可以使用自定義條形碼。
（2）交易清單：包括交易的流水賬號、每類商品的商品名、數量、該類商品的總金額、交易的時間、負責本次收銀的員工號。
（3）商品積壓：在一定時期內，遠無法完成銷售計劃的商品會造成積壓。
（4）促銷：在一定時期內，某些商品會按低於原價的促銷價格銷售。
庫存告警提示：當商品的庫存數量低於庫存報警數量時發出提示。
（5）盤點：計算出庫存、銷售額、盈利等經營指標。
1.6 參考資料
《資料庫原理及設計》 陶宏才編 清華大學出版社
《SQL Server 2000 實用教程》范立南編 清華大學出版社
《SQL Server 2000 編程員指南》李香敏編 北京希望電子出版社
《輕松搞定 SQL Server 2000 程序設計》Rebecca M.Riordan編
《軟體工程規范》Watts S.Humphrey編 清華大學出版社
《軟體工程理論與實踐》 Shari Lawrence Pfleeger編 清華大學出版社
《軟體需求分析》 Swapna Kishore編 機械工業出版社
《軟體工程思想》 林銳編

2、邏輯分析與詳細分析
2.1系統功能
（1）、零售前台（POS）管理系統，本系統必須具有以下功能：
 商品錄入：根據超巿業務特點制定相關功能，可以通過輸入唯一編號、掃描條形碼、商品名稱等來實現精確或模糊的商品掃描錄入。該掃描錄入方法可以充分保證各種電腦操作水平層次的人員均能准確快速地進行商品掃描錄入。
 收銀業務：通過掃描條形碼或者直接輸入商品名稱（對於同類多件商品採用一次錄入加數量的方式）自動計算本次交易的總金額。在顧客付款後，自動計算找零，同時列印交易清單（包括交易的流水賬號、每類商品的商品名、數量、該類商品的總金額、交易的時間、負責本次收銀的員工號）。如果顧客是本店會員並持有本人會員卡，則在交易前先掃描會員卡，並對所購物品全部實行95折優惠，並將所購物品的總金額累計到該會員的總消費金額中。 會員卡的有效期限為一年，滿一年未續卡者，該會員卡將被注銷。
 安全性：OS登陸、退出、換班與操作鎖定等許可權驗證保護；斷電自動保護最大限度防止意外及惡意非法操作。
 獨立作業：有的斷網收銀即在網路伺服器斷開或網路不通的情況下，收銀機仍能正常作業
(2)、後台管理系統，本系統必須具備以下功能
 進貨管理： 根據銷售情況及庫存情況，自動制定進貨計劃（亦可手工制定修改），可以避免盲目進貨造成商品積壓。 按計劃單有選擇性地進行自動入庫登記。 綜合查詢列印計劃進貨與入庫記錄及金額。
 銷售管理： 商品正常銷售、促銷與限量、限期及禁止銷售控制。 綜合查詢各種銷售明細記錄、各地收銀員收銀記錄以及交結賬情況等。 按多種方式統計生成銷售排行榜，靈活察看和列印商品銷售日、月、年報表。
 庫存管理： 綜合查詢庫存明細記錄。 庫存狀態自動告警提示。如庫存過剩、少貨、缺貨等。軟體為您預警，避免庫存商品積壓損失和缺貨。 庫存自動盤點計算。
 人員管理： 員工、會員、供貨商、廠商等基本信息登記管理。 員工操作許可權管理。 客戶銷售許可權管理。

（3）系統結構
系統總體結構

模塊子系統結構

功能描述：商品錄入子系統要求能快速錄入商品，因此必須支持條形碼掃描。

功能描述：收銀業務子系統能計算交易總額，列印交易清單，並根據會員卡打折。

功能描述：進貨管理子系統可以根據庫存自動指定進貨計劃，進貨時自動等級，以及提供查詢和列印計劃進貨與入庫記錄的功能。

功能描述：銷售管理子系統可以控制某商品是否允許銷售，查詢每種商品的銷售情況並產生年、月、日報表，同時可以生成銷售排行榜。

功能描述：庫存管理子系統提供查詢庫存明細記錄的基本功能，並根據庫存的狀態報警，以及自動盤點計算。

功能描述：人員管理子系統提供基本信息登記管理，員工操作許可權管理，客戶銷售許可權管理的功能。
2.2、流程圖
前台管理系統

頂層DFD圖

第0層DFD圖

第1層DFD圖

2.3、戶類型與職能
（1）、員工（營業員）：
 通過商品條形碼掃描輸入商品到購買清單
 操作軟體計算交易總金額
 操作軟體輸出交易清單
 對會員進行會員卡掃描以便打折
（2）、：超市經理
 操作軟體錄入商品，供貨商，廠商
 操作軟體制定進貨計劃
 查詢列印計劃進貨與入庫記錄
 操作軟體控制商品銷售與否
 查詢列印銷售情況
 操作軟體生成銷售排行榜
 查詢庫存明細記錄
 根據軟體發出的庫存告警進行入貨
 操作軟體進行盤點計算
（3）、總經理：
 基本信息登記管理
 員工操作許可權管理
 客戶銷售許可權管理
2.4、統開發步驟
 確定參與者和相關的用況
 為每個用況設計過程
 建立順序圖，確定每個腳本中對象的協作
 創建類，確定腳本中的對象
 設計, 編碼, 測試, 集成類
 為過程編寫系統測試案例
 運行測試案例，檢驗系統
2.5、系統環境需求
 系統模式

本系統採用C/S模式作為開發模式
 硬體環境
伺服器端：
高性能的計算機一台，
普通的雙絞線作為連接。
客戶端： 普通的計算機或者工作站，
普通的雙絞線作為連接。
 軟體環境
伺服器端：安裝SQL Server 2000的伺服器版本，
安裝windows 2000伺服器版本，
配置了諾頓等必須的防毒軟體。
客戶端： 安裝SQL Server2000的伺服器版本，
安裝了VB等可視化開發工具軟體，
安裝windows2000伺服器版本。

2.6、系統安全問題
信息系統盡管功能強大，技術先進，但由於受到自身體系結構，設計思路以及運行機制等限制，也隱含許多不安全因素。常見因素有：數據的輸入，輸出，存取與備份，源程序以及應用軟體，資料庫，操作系統等漏洞或缺陷，硬體，通信部分的漏洞，企業內部人員的因素，病毒，「黑客」等因素。因此，為使本系統能夠真正安全，可靠，穩定地工作，必須考慮如下問題：為保證安全，不致使系統遭到意外事故的損害，系統因該能防止火，盜或其他形式的人為破壞。
 系統要能重建
 系統應該是可審查的
 系統應能進行有效控制，抗干擾能力強
 系統使用者的使用許可權是可識別的
3、基於UML的建模
3.1語義規則
用例模型（use cases view）（用例視圖）的基本組成部件是用例（use case）、角色(actor)和系統(system)。用例用於描述系統的功能，也就是從外部用戶的角度觀察，系統應支持哪些功能，幫助分析人員理解系統的行為，它是對系統功能的宏觀描述，一個完整的系統中通常包含若干個用例，每個用例具體說明應完成的功能，代表系統的所有基本功能（集）。角色是與系統進行交互的外部實體，它可以是系統用戶，也可以是其它系統或硬體設備，總之，凡是需要與系統交互的任何東西都可以稱作角色。系統的邊界線以內的區域（即用例的活動區域）則抽象表示系統能夠實現的所有基本功能。在一個基本功能（集）已經實現的系統中，系統運轉的大致過程是：外部角色先初始化用例，然後用例執行其所代表的功能，執行完後用例便給角色返回一些值，這個值可以是角色需要的來自系統中的任何東西。
UML：是一種標準的圖形化建模語言，它是面向對象分析與設計的一種標准表示；它不是一種可視化的程序設計語言而是一種可視化的建模語言；不是工具或知識庫的規格說明而是一種建模語言規格說明是一種表示的標准；不是過程也不是方法但允許任何一種過程和方法使用它。

用例（use case）：

參與者（actor）：

3.2、UML模型
3.21、系統UML模型

3.22、子系統UML模型
（1）零售前台（POS）管理系統用例視圖

（2）後台管理系統用例視圖

3.3、系統實現圖

4、超市銷售系統概念設計文檔
（1）、系統ER圖

（2）、系統ER圖說明
1) 商店中的所有用戶（員工）可以銷售多種商品，每種商品可由不同用戶（員工）銷售；
2) 每個顧客可以購買多種商品，不同商品可由不同顧客購買；
3) 每個供貨商可以供應多種不同商品，每種商品可由多個供應商供應。
（3）、視圖設計
1) 交易視圖(v_Dealing)——用於查詢交易情況的視圖；
2) 計劃進貨視圖(v_PlanStock)——用於查詢進貨計劃的視圖；
3) 銷售視圖(v_Sale)——用於查詢銷售明細記錄的視圖；
4) 入庫視圖(v_Stock)——用於查詢入庫情況的視圖。
5、邏輯設計文檔
（1）、系統關系模型
a) 商品信息表（商品編號，商品名稱，價格，條形碼，促銷價格，促銷起日期，促銷止日期，允許打折，庫存數量，庫存報警數量，計劃進貨數，允許銷售，廠商編號，供貨商編號）
b) 用戶表（用戶編號，用戶名稱，用戶密碼，用戶類型）
c) 會員表（會員編號，會員卡號，累積消費金額，注冊日期）
d) 銷售表（銷售編號，商品編號，銷售數量，銷售金額，銷售日期）
e) 交易表（交易編號，用戶名稱，交易金額，會員卡號，交易日期）
f) 進貨入庫表（入庫編號，入庫商品編號，入庫數量，單額，總額，入庫日期，計劃進貨日期，入庫狀態）
g) 供貨商表（供貨商編號，供貨商名稱，供貨商地址，供貨商電話）
h) 廠商表（廠商編號，廠商名稱，廠商地址，廠商電話）

（2）、系統資料庫表結構
資料庫表索引
表名 中文名
MerchInfo 商品信息表
User 用戶表
Menber 會員表
Sale 銷售表
Dealing 交易表
Stock 進貨入庫表
Provide 供貨商表
Factory 廠商表

商品信息表(MerchInfo)
欄位名 欄位類型 長度 主/外鍵 欄位值約束 對應中文名
MerchID int 4 P Not null 商品編號
MerchName Varchar 50 Not null 商品名稱
MerchPrice Money 4 Not null 價格
MerchNum Int 4 Not null 庫存數量
CautionNum Int 4 Not null 庫存報警數量
PlanNum Int 4 null 計劃進貨數
BarCode Varchar 50 Not null 條形碼
SalesProPrice Money 4 促銷價格
SalesProDateS Datetime 8 促銷起日期
SalesProDateE Datetime 8 促銷止日期
AllowAbate Int 4 Not null 允許打折
AllowSale Int 4 Not null 允許銷售
FactoryID Varchar 10 F Not null 廠商編號
ProvideID Varchar 10 F Not null 供貨商編號

用戶表(User)
欄位名 欄位類型 長度 主/外鍵 欄位值約束 對應中文名
UserID varchar 10 P Not null 用戶編號
UserName Varchar 25 Not null 用戶名稱
UserPW Varchar 50 Not null 用戶密碼
UserStyle Int 4 Not null 用戶類型

會員表(Menber)
欄位名 欄位類型 長度 主/外鍵 欄位值約束 對應中文名
MemberID Varchar 10 P Not null 會員編號
MemberCard Varchar 20 Not null 會員卡號
TotalCost Money 4 Not null 累積消費金額
RegDate Datetime 8 Not null 注冊日期

銷售表(Sale)
欄位名 欄位類型 長度 主/外鍵 欄位值約束 對應中文名
SaleID Varchar 10 P Not null 銷售編號
MerChID Varchar 10 F Not null 商品編號
SaleDate Datetime 8 Not null 銷售日期
SaleNum Int 4 Not null 銷售數量
SalePrice Money 4 Not null 銷售單額

交易表(Dealing)
欄位名 欄位類型 長度 主/外鍵 欄位值約束 對應中文名
DealingID Varchar 10 P Not null 交易編號
DealingPrice Money 4 Not null 交易金額
DealingDate Money 4 Not null 交易日期
MemberID Varchar 10 會員卡號
UserName Varchar 10 F Not null 用戶名稱

入庫紀錄表(Stock)
欄位名 欄位類型 長度 主/外鍵 欄位值約束 對應中文名
StockID Varchar 10 P Not null 入庫編號
MerchID Varchar 10 F Not null 入庫商品編號
MerchNum Int 4 Not null 入庫數量
MerchPrice Money 4 Not null 單額
TotalPrice Money 4 Not null 總額
StockDate Datetime 8 Datetime 入庫日期
PlanDate Datetime 8 Datetime 計劃進貨日期
StockState Int 4 Not null 入庫狀態

供貨商表(Provide)
欄位名 欄位類型 長度 主/外鍵 欄位值約束 對應中文名
ProvideID varchar 10 P Not null 供貨商編號
ProvideName Varchar 50 Not null 供貨商名稱
ProvideAddress Varchar 250 供貨商地址
ProvidePhone Varchar 25 供貨商電話

廠商表(Provide)
欄位名 欄位類型 長度 主/外鍵 欄位值約束 對應中文名
FactoryID varchar 10 P Not null 廠商編號
FactoryName Varchar 50 Not null 廠商名稱
FactoryAddress Varchar 250 廠商地址
FactoryPhone Varchar 25 廠商電話
6、物理設計文檔
/*----------創建資料庫----------*/
create database SuperMarketdb
on primary
(
name=SuperMarketdb,
filename='C:\Program Files\Microsoft SQL Server\MSSQL\Data\SuperMarketdb.mdf',
size=100MB,
maxsize=200MB,
filegrowth=20MB
)
log on
(
name=SuperMarketlog,
filename='C:\Program Files\Microsoft SQL Server\MSSQL\Data\SuperMarketdb.ldf',
size=60MB,
maxsize=200MB,
filegrowth=20MB
)
go

/*----------創建基本表----------*/
use [SuperMarketdb]
go
/*創建交易表*/
CREATE TABLE Dealing (
DealingID int identity(1,1) Primary key ,
DealingDate datetime NOT NULL ,
DealingPrice money NOT NULL ,
UserName varchar(25) NULL ,
MemberCard varchar(20) NULL
)
GO
/*創建廠商表*/
CREATE TABLE Factory (
FactoryID varchar(10) Primary key ,
FactoryName varchar(50) NOT NULL ,
FactoryAddress varchar(250) NULL ,
FactoryPhone varchar(50) NULL
)
GO
/*創建會員表*/
CREATE TABLE Member (
MemberID varchar(10) Primary key ,
MemberCard varchar(20) NOT NULL ,
TotalCost money NOT NULL ,
RegDate datetime NOT NULL
)
GO
/*創建商品信息表*/
CREATE TABLE MerchInfo (
MerchID int identity(1,1) Primary key ,
MerchName varchar(50) Unique NOT NULL ,
MerchPrice money NOT NULL ,
MerchNum int NOT NULL ,
CautionNum int NOT NULL ,
PlanNum int NOT NULL ,
BarCode varchar(20) Unique NOT NULL ,
SalesProPrice money NULL ,
SalesProDateS datetime NULL ,
SalesProDateE datetime NULL ,
AllowAbate int NOT NULL ,
AllowSale int NOT NULL ,
FactoryID int NOT NULL ,
ProvideID int NOT NULL
)
GO
/*創建供應商表*/
CREATE TABLE Provide (
ProvideID varchar(10) Primary key ,
ProvideName varchar(50) NOT NULL ,
ProvideAddress varchar(250) NULL ,
ProvidePhone varchar(25) NULL
)
GO
/*創建銷售表*/
CREATE TABLE Sale (
SaleID int identity(1,1) Primary key ,
MerChID int NOT NULL ,
SaleDate datetime NOT NULL ,
SaleNum int NOT NULL,
SalePrice money NOT NULL
)
GO
/*創建入庫表*/
CREATE TABLE Stock (
StockID int identity(1,1) Primary key ,
MerchID int NOT NULL ,
MerchNum int NOT NULL ,
MerchPrice money NULL ,
TotalPrice money NULL ,
PlanDate datetime NULL ,
StockDate datetime NULL,
StockState int NOT NULL
)
GO
/*創建用戶表*/
CREATE TABLE User (
UserID varchar(10) Primary key ,
UserName varchar(25) NOT NULL ,
UserPW varchar(50) NOT NULL ,
UserStyle int NOT NULL ,
)
GO

/*----------創建表間約束----------*/
/*商品信息表中廠商編號、供應商編號分別與廠商表、供應商表之間的外鍵約束*/
ALTER TABLE MerchInfo ADD
CONSTRAINT [FK_MerchInfo_Factory] FOREIGN KEY
(
[FactoryID]
) REFERENCES Factory (
[FactoryID]
),
CONSTRAINT [FK_MerchInfo_Provide] FOREIGN KEY
(
[ProvideID]
) REFERENCES Provide (
[ProvideID]
)
GO
/*銷售表中商品編號與商品信息表之間的外鍵約束*/
ALTER TABLE Sale ADD
CONSTRAINT [FK_Sale_MerchInfo] FOREIGN KEY
(
[MerChID]
) REFERENCES MerchInfo (
[MerchID]
) ON DELETE CASCADE
GO
/*入庫表中商品編號與商品信息表之間的外鍵約束*/
ALTER TABLE Stock ADD
CONSTRAINT [FK_Stock_MerchInfo] FOREIGN KEY
(
[MerchID]
) REFERENCES MerchInfo (
[MerchID]
) ON DELETE CASCADE
GO

/*----------創建索引----------*/
/*在交易表上建立一個以交易編號、交易日期為索引項的非聚集索引*/
CREATE nonclustered INDEX IX_Dealing ON Dealing(DealingID, DealingDate)
GO
/*在商品信息表上建立一個以商品編號為索引項的非聚集索引*/
CREATE nonclustered INDEX IX_MerchInfo ON MerchInfo(MerchID)
GO
/*在銷售表上建立一個以銷售編號、銷售日期為索引項的非聚集索引*/
CREATE nonclustered INDEX IX_Sale ON Sale(SaleID, SaleDate)
GO
/*在入庫表上建立一個以入庫編號、入庫日期、商品編號為索引項的非聚集索引*/
CREATE nonclustered INDEX IX_Stock ON Stock(StockID, StockDate, MerchID)
GO

/*----------創建視圖----------*/
/*創建用於查詢交易情況的視圖*/
CREATE VIEW v_Dealing
AS
SELECT DealingDate as 交易日期,
UserName as 員工名稱,
MemberCard as 會員卡號,
DealingPrice as 交易金額
FROM Dealing
GO
/*創建用於查詢進貨計劃的視圖*/
CREATE VIEW v_PlanStock
AS
SELECT Stock.StockID as SID,
MerchInfo.MerchName as 商品名稱,
MerchInfo.BarCode as 條形碼,
Factory.FactoryName as 廠商,
Provide.ProvideName as 供貨商,
Stock.MerchNum as 計劃進貨數量,
Stock.PlanDate as 計劃進貨日期
FROM Stock,MerchInfo,Provide,Factory
Where Stock.MerchID = MerchInfo.MerchID
and Provide.ProvideID=MerchInfo.ProvideID
and Factory.FactoryID=MerchInfo.FactoryID
and Stock.StockState=0
GO
/*創建用於查詢銷售明細記錄的視圖*/
CREATE VIEW v_Sale
AS
SELECT MerchInfo.MerchName as 商品名稱,
MerchInfo.BarCode as 條形碼,
MerchInfo.MerchPrice as 商品價格,
Sale.SalePrice as 銷售價格,
Sale.SaleNum as 銷售數量,
Sale.SaleDate as 銷售日期
FROM Sale INNER JOIN
MerchInfo ON Sale.MerChID = MerchInfo.MerchID
GO
/*創建用於查詢入庫情況的視圖*/
CREATE VIEW v_Stock
AS
SELECT MerchInfo.MerchName as 商品名稱,
MerchInfo.BarCode as 條形碼,
Factory.FactoryName as 廠商,
Provide.ProvideName as 供貨商,
Stock.MerchPrice as 入庫價格,
Stock.MerchNum as 入庫數量,
Stock.TotalPrice as 入庫總額,
Stock.StockDate as 入庫日期
FROM Stock,MerchInfo,Provide,Factory
Where Stock.MerchID = MerchInfo.MerchID
and Provide.ProvideID=MerchInfo.ProvideID
and Factory.FactoryID=MerchInfo.FactoryID
and Stock.StockState=1
GO

7、小結
和傳統管理模式相比較，使用本系統，毫無疑問會大大提高超市的運作效率，輔助提高超市的決策水平，管理水平，為降低經營成本， 提高效益，減少差錯，節省人力，減少顧客購物時間，增加客流量，提高顧客滿意度，增強超市擴張能力， 提供有效的技術保障。
由於開發者能力有限，加上時間倉促，本系統難免會出現一些不足之處，例如：
 本系統只適合小型超市使用，不能適合中大型超市使用；
 超市管理系統涉及范圍寬，要解決的問題多，功能復雜，實現困難，但由於限於時間，本系統只能做出其中的一部分功能；
對於以上出現的問題，我們深表歉意，如發現還有其它問題，希望老師批評指正。
請採納。

H. 說明在設計資料庫表時你是如何考慮的

資料庫是整個軟體應用的根基，是軟體設計的起點，它起著決定性的質變作用，因此我們必須對資料庫設計高度重視起來，培養設計良好資料庫的習慣，是一個優秀的軟體設計師所必須具備的基本素質條件！ 那麼我們要做到什麼程度才是對的呢？下面就說說資料庫設計的原則： （1）、資料庫設計最起碼要佔用整個項目開發的40%以上的時間

資料庫是需求的直觀反應和表現，因此設計時必須要切實符合用戶的需求，要多次與用戶溝通交流來細化需求，將需求中的要求和每一次的變化都要一一體現在資料庫的設計當中。如果需求不明確，就要分析不確定的因素，設計表時就要事先預留出可變通的欄位，正所謂「有備無患」。 （2）、資料庫設計不僅僅停留於頁面demo的表面 頁面內容所需要的欄位，在資料庫設計中只是一部分，還有系統運轉、模塊交互、中轉數據、表之間的聯系等等所需要的欄位，因此資料庫設計絕對不是簡單的基本數據存儲，還有邏輯數據存儲。 （3）、資料庫設計完成後，項目80%的設計開發在你腦海中就已經完成了 每個欄位的設計都是有他必要的意義的，你在設計每一個欄位的同時，就應該已經想清楚程序中如何去運用這些欄位，多張表的聯系在程序中是如何體現的。換句話說，你完成資料庫設計後，程序中所有的實現思路和實現方式在你的腦海中就已經考慮過了。如果達不到這種程度，那當進入編碼階段後，才發現要運用的技術或實現的方式資料庫無法支持，這時再改動資料庫就會很麻煩，會造成一系列不可預測的問題。 （4）、資料庫設計時就要考慮到效率和優化問題 一開始就要分析哪些表會存儲較多的數據量，對於數據量較大的表的設計往往是粗粒度的，也會冗餘一些必要的欄位，已達到盡量用最少的表、最弱的表關系去存儲海量的數據。並且在設計表時，一般都會對主鍵建立聚集索引，含有大數據量的表更是要建立索引以提供查詢性能。對於含有計算、數據交互、統計這類需求時，還要考慮是否有必要採用存儲過程。 （5）、添加必要的（冗餘）欄位 像「創建時間」、「修改時間」、「備注」、「操作用戶IP」和一些用於其他需求（如統計）的欄位等，在每張表中必須都要有，不是說只有系統中用到的數據才會存到資料庫中，一些冗餘欄位是為了便於日後維護、分析、拓展而添加的，這點是非常重要的，比如黑客攻擊，篡改了數據，我們便就可以根據修改時間和操作用戶IP來查找定位。 （6）、設計合理的表關聯 若多張表之間的關系復雜，建議採用第三張映射表來關聯維護兩張表之間的關系，以降低表之間的直接耦合度。若多張表涉及到大數據量的問題，表結構盡量簡單，關聯也要盡可能避免。 （7）、設計表時不加主外鍵等約束性關聯，系統編碼階段完成後再添加約束性關聯 這樣做的目的是有利於團隊並行開發，減少編碼時所遇到的問題，表之間的關系靠程序來控制。編碼完成後再加關聯並進行測試。不過也有一些公司的做法是乾脆就不加表關聯。 （8）、選擇合適的主鍵生成策略

I. 資料庫設計主要包括哪幾部分，分別包括哪些內容

資料庫設計主要包括需求分析、概念結構設計、邏輯結構設計、物理結構設計、資料庫的實施和資料庫的運行和維護，具體內容如下：

1、需求分析

內容：調查和分析用戶的業務活動和數據的使用情況，弄清所用數據的種類、范圍、數量以及它們在業務活動中交流的情況，確定用戶對資料庫系統的使用要求和各種約束條件等，形成用戶需求規約。

2、概念設計

內容：對用戶要求描述的現實世界，通過對其中諸處的分類、聚集和概括，建立抽象的概念數據模型。這個概念模型應反映現實世界各部門的信息結構、信息流動情況、信息間的互相制約關系以及各部門對信息儲存、查詢和加工的要求等。

3、邏輯設計

內容：主要工作是將現實世界的概念數據模型設計成資料庫的一種邏輯模式，即適應於某種特定資料庫管理系統所支持的邏輯數據模式。與此同時，可能還需為各種數據處理應用領域產生相應的邏輯子模式。這一步設計的結果就是所謂「邏輯資料庫」。

4、物理設計

內容：根據特定資料庫管理系統所提供的多種存儲結構和存取方法等依賴於具體計算機結構的各項物理設計措施，對具體的應用任務選定最合適的物理存儲結構(包括文件類型、索引結構和數據的存放次序與位邏輯等)、存取方法和存取路徑等。

5、驗證設計

內容：收集數據並具體建立一個資料庫，運行一些典型的應用任務來驗證資料庫設計的正確性和合理性。一般，一個大型資料庫的設計過程往往需要經過多次循環反復。當設計的某步發現問題時，可能就需要返回到前面去進行修改。

6、運行與維護設計

內容：在資料庫系統正式投入運行的過程中，必須不斷地對其進行調整與修改。除了關系型資料庫已有一套較完整的數據範式理論可用來部分地指導資料庫設計之外，尚缺乏一套完善的資料庫設計理論、方法和工具，以實現資料庫設計的自動化或互動式的半自動化設計。

(9)資料庫設計項目擴展閱讀：

重要性

1、有利於資源節約

對計算機軟體資料庫設計加以重視不僅可減少軟體後期的維修，達到節約人力與物力的目的，同時還有利於軟體功能的高效發揮。

2、有利於軟體運行速度的提高

高水平的資料庫設計可滿足不同計算機軟體系統對於運行速度的需求，而且還可充分發揮並實現系統功能。計算機軟體性能提高後，系統發出的運行指令在為用戶提供信息時也將更加快速有效，軟體運行速度自然得以提高。

3、有利於軟體故障的減少

加強資料庫設計可有效減少軟體故障的發生幾率，推動計算機軟體功能的實現。

J. 資料庫設計的基本步驟

資料庫設計的基本步驟如下：

1、安裝並打開MySQL WorkBench軟體以後，在軟體的左側邊欄有三個選項，分別是對應「連接資料庫」、「設計資料庫」、「遷移資料庫」的功能。這類選擇第二項，設計資料庫，點擊右邊的「＋」號，創建models。