推薦最好的軟體分析設計網站：
「erp系統分析論壇」"（擺渡搜索）
涉及： ERP解決方案||需求分析||業務建模||系統分析||信息監理；有大量的免費ERP軟體資料，還有交易區，提供資源買賣市場；
------ [總設計師] 咨詢團 ------
② 誰能給我一份關於資料庫系統設計的實例，謝謝了
假設你是一家百貨公司電腦部的開發人員，某天老闆要求你為公司開發一套網上電子商務平台，該百貨公司有數千種商品出售，不過目前僅打算先在網上銷售數十種方便運輸的商品，當然，以後可能會陸續在該電子商務平台上增加新的商品出售。現在開始進行該平台資料庫的商品信息表的設計。每種出售的商品都會有相同的屬性，如商品編號，商品名稱，商品所屬類別，相關信息，供貨廠商，內含件數，庫存，進貨價，銷售價，優惠價。你很快就設計出4個表：商品類型表(Wares_type)，供貨廠商表(Wares_provider)，商品信息表 (Wares_info)：
商品類型表(Wares_type)
名稱 類型 約束條件 說明
type_id int 無重復 類別標識，主鍵
type_name char(50) 不允許為空 類型名稱，不允許重復
type_father int 不允許為空 該類別的父類別標識，如果是頂節點的話設定為某個唯一值
type_layer char(6) 限定3層,初始值為000000 類別的先序遍歷，主要為減少檢索資料庫的次數
供貨廠商表(Wares_provider)
名稱 類型 約束條件 說明
provider_id int 無重復 供貨商標識，主鍵
provider_name char(100) 不允許為空 供貨商名稱
商品信息表(Wares_info)
名稱 類型 約束條件 說明
wares_id int 無重復 商品標識，主鍵
wares_name char(100) 不允許為空 商品名稱
wares_type int 不允許為空 商品類型標識，和Wares_type.type_id關聯
wares_info char(200) 允許為空 相關信息
provider int 不允許為空 供貨廠商標識，和Wares_provider.provider_id關聯
setnum int 初始值為1 內含件數，默認為1
stock int 初始值為0 庫存，默認為0
buy_price money 不允許為空 進貨價
sell_price money 不允許為空 銷售價
discount money 不允許為空 優惠價
你拿著這3個表給老闆檢查，老闆希望能夠再添加一個商品圖片的欄位，不過只有一部分商品有圖片。OK，你在商品信息表(Wares_info)中增加了一個haspic的BOOL型欄位，然後再建了一個新表——商品圖片表(Wares_pic)：
商品圖片表(Wares_pic)
名稱 類型 約束條件 說明
pic_id int 無重復 商品圖片標識，主鍵
wares_id int 不允許為空 所屬商品標識，和Wares_info.wares_id關聯
pic_address char(200) 不允許為空 圖片存放路徑
程序開發完成後，完全滿足老闆目前的要求，於是正式啟用。一段時間後，老闆打算在這套平台上推出新的商品銷售，其中，某類商品全部都需添加「長度」的屬性。第一輪折騰來了……當然，你按照添加商品圖片表的老方法，在商品信息表(Wares_info)中增加了一個haslength的BOOL型欄位，又建了一個新表——商品長度表(Wares_length)：
商品長度表(Wares_length)
名稱 類型 約束條件 說明
length_id int 無重復 商品圖片標識，主鍵
wares_id int 不允許為空 所屬商品標識，和Wares_info.wares_id關聯
length char(20) 不允許為空 商品長度說明
剛剛改完沒多久，老闆又打算上一批新的商品，這次某類商品全部需要添加「寬度」的屬性。你咬了咬牙，又照方抓葯，添加了商品寬度表 (Wares_width)。又過了一段時間，老闆新上的商品中有一些需要添加「高度」的屬性，你是不是開始覺得你所設計的資料庫按照這種方式增長下去，很快就能變成一個迷宮呢？那麼，有沒有什麼辦法遏制這種不可預見性，但卻類似重復的資料庫膨脹呢？我在閱讀《敏捷軟體開發：原則、模式與實踐》中發現作者舉過類似的例子：7.3 「Copy」程序。其中，我非常贊同敏捷軟體開發這個觀點：在最初幾乎不進行預先設計，但是一旦需求發生變化，此時作為一名追求卓越的程序員，應該從頭審查整個架構設計，在此次修改中設計出能夠滿足日後類似修改的系統架構。下面是我在需要添加「長度」的屬性時所提供的修改方案：
去掉商品信息表(Wares_info)中的haspic欄位，添加商品額外屬性表(Wares_ex_property)和商品額外信息表(Wares_ex_info)2個表來完成添加新屬性的功能。
商品額外屬性表(Wares_ex_property)
名稱 類型 約束條件 說明
ex_pid int 無重復 商品額外屬性標識，主鍵
p_name char(20) 不允許為空 額外屬性名稱
商品額外信息表(Wares_ex_info)
名稱 類型 約束條件 說明
ex_iid int 無重復 商品額外信息標識，主鍵
wares_id int 不允許為空 所屬商品標識，和Wares_info.wares_id關聯
property_id int 不允許為空 商品額外屬性標識，和Wares_ex_property.ex_pid關聯
property_value char(200) 不允許為空 商品額外屬性值
在商品額外屬性表(Wares_ex_property)中添加2條記錄：
ex_pid p_name
1 商品圖片
2 商品長度
再在整個電子商務平台的後台管理功能中追加一項商品額外屬性管理的功能，以後添加新的商品時出現新的屬性，只需利用該功能往商品額外屬性表 (Wares_ex_property)中添加一條記錄即可。不要害怕變化，被第一顆子彈擊中並不是壞事，壞的是被相同軌道飛來的第二顆、第三顆子彈擊中。第一顆子彈來得越早，所受的傷越重，之後的抵抗力也越強8)
來自：http://blog.csdn.net/jerry1089/archive/2009/11/10/4792176.aspx
你看看吧。
資料庫設計大概分一下幾步
：
1.需求分析
2.概念結構設計
3.邏輯結構設計
4.物理結構設計
5.資料庫設施
6.資料庫的運行和維護
③ 資料庫設計案例分析
加到200分吧，我幫你
④ 怎樣設計高性能的資料庫
考察現有環境
在設計一個新資料庫時，你不但應該仔細研究業務需求而且還要考察現有的系統。大多數資料庫項目都不是從頭開始建立的；通常，機構內總會存在用來滿足特定需求的現有系統（可能沒有實現自動計算）。顯然，現有系統並不完美，否則你就不必再建立新系統了。但是對舊系統的研究可以讓你發現一些可能會忽略的細微問題。一般來說，考察現有系統對你絕對有好處。
定義標準的對象命名規范
一定要定義資料庫對象的命名規范。對資料庫表來說，從項目一開始就要確定表名是採用復數還是單數形式。此外還要給表的別名定義簡單規則（比方說，如果表名是一個單詞，別名就取單詞的前 4 個字母；如果表名是兩個單詞，就各取兩個單詞的前兩個字母組成 4 個字母長的別名；如果表的名字由 3 個單片語成，你不妨從頭兩個單詞中各取一個然後從最後一個單詞中再取出兩個字母，結果還是組成 4 字母長的別名，其餘依次類推）對工作用表來說，表名可以加上前綴 WORK_ 後面附上採用該表的應用程序的名字。表內的列[欄位]要針對鍵採用一整套設計規則。比如，如果鍵是數字類型，你可以用 _N 作為後綴；如果是字元類型則可以採用 _C 後綴。對列[欄位]名應該採用標準的前綴和後綴。再如，假如你的表裡有好多「money」欄位，你不妨給每個列[欄位]增加一個 _M 後綴。還有，日期列[欄位]最好以 D_ 作為名字打頭。
檢查表名、報表名和查詢名之間的命名規范。你可能會很快就被這些不同的資料庫要素的名稱搞糊塗了。假如你堅持統一地命名這些資料庫的不同組成部分，至少你應該在這些對象名字的開頭用 Table、Query 或者 Report 等前綴加以區別。
如果採用了 Microsoft Access，你可以用 qry、rpt、tbl 和 mod 等符號來標識對象（比如 tbl_Employees）。我在和 SQL Server 打交道的時候還用過 tbl 來索引表，但我用 sp_company （現在用 sp_feft_）標識存儲過程，因為在有的時候如果我發現了更好的處理辦法往往會保存好幾個拷貝。我在實現 SQL Server 2000 時用 udf_ （或者類似的標記）標識我編寫的函數。
工欲善其事, 必先利其器
採用理想的資料庫設計工具，比如：SyBase 公司的 PowerDesign，她支持 PB、VB、Delphe 等語言，通過 ODBC 可以連接市面上流行的 30 多個資料庫，包括 dBase、FoxPro、VFP、SQL Server 等，今後有機會我將著重介紹 PowerDesign 的使用。
獲取數據模式資源手冊
正在尋求示例模式的人可以閱讀《數據模式資源手冊》一書，該書由 Len Silverston、W. H. Inmon 和 Kent Graziano 編寫，是一本值得擁有的最佳數據建模圖書。該書包括的章節涵蓋多種數據領域，比如人員、機構和工作效能等。其他的你還可以參考相關書籍。
暢想未來，但不可忘了過去的教訓
我發現詢問用戶如何看待未來需求變化非常有用。這樣做可以達到兩個目的：首先，你可以清楚地了解應用設計在哪個地方應該更具靈活性以及如何避免性能瓶頸；其次，你知道發生事先沒有確定的需求變更時用戶將和你一樣感到吃驚。
一定要記住過去的經驗教訓！我們開發人員還應該通過分享自己的體會和經驗互相幫助。即使用戶認為他們再也不需要什麼支持了，我們也應該對他們進行這方面的教育，我們都曾經面臨過這樣的時刻「當初要是這么做了該多好..」。
在物理實踐之前進行邏輯設計
在深入物理設計之前要先進行邏輯設計。隨著大量的 CASE 工具不斷涌現出來，你的設計也可以達到相當高的邏輯水準，你通常可以從整體上更好地了解資料庫設計所需要的方方面面。
了解你的業務
在你百分百地確定系統從客戶角度滿足其需求之前不要在你的 ER（實體關系）模式中加入哪怕一個數據表（怎麼，你還沒有模式？那請你參看技巧 9）。了解你的企業業務可以在以後的開發階段節約大量的時間。一旦你明確了業務需求，你就可以自己做出許多決策了。
一旦你認為你已經明確了業務內容，你最好同客戶進行一次系統的交流。採用客戶的術語並且向他們解釋你所想到的和你所聽到的。同時還應該用可能、將會和必須等詞彙表達出系統的關系基數。這樣你就可以讓你的客戶糾正你自己的理解然後做好下一步的 ER 設計。
創建數據字典和 ER 圖表
一定要花點時間創建 ER 圖表和數據字典。其中至少應該包含每個欄位的數據類型和在每個表內的主外鍵。創建 ER 圖表和數據字典確實有點費時但對其他開發人員要了解整個設計卻是完全必要的。越早創建越能有助於避免今後面臨的可能混亂，從而可以讓任何了解資料庫的人都明確如何從資料庫中獲得數據。
有一份諸如 ER 圖表等最新文檔其重要性如何強調都不過分，這對表明表之間關系很有用，而數據字典則說明了每個欄位的用途以及任何可能存在的別名。對 SQL 表達式的文檔化來說這是完全必要的。
創建模式
一張圖表勝過千言萬語：開發人員不僅要閱讀和實現它，而且還要用它來幫助自己和用戶對話。模式有助於提高協作效能，這樣在先期的資料庫設計中幾乎不可能出現大的問題。模式不必弄的很復雜；甚至可以簡單到手寫在一張紙上就可以了。只是要保證其上的邏輯關系今後能產生效益。
從輸入輸出下手
在定義資料庫表和欄位需求（輸入）時，首先應檢查現有的或者已經設計出的報表、查詢和視圖（輸出）以決定為了支持這些輸出哪些是必要的表和欄位。舉個簡單的例子：假如客戶需要一個報表按照郵政編碼排序、分段和求和，你要保證其中包括了單獨的郵政編碼欄位而不要把郵政編碼糅進地址欄位里。
報表技巧
要了解用戶通常是如何報告數據的：批處理還是在線提交報表？時間間隔是每天、每周、每月、每個季度還是每年？如果需要的話還可以考慮創建總結表。系統生成的主鍵在報表中很難管理。用戶在具有系統生成主鍵的表內用副鍵進行檢索往往會返回許多重復數據。這樣的檢索性能比較低而且容易引起混亂。
理解客戶需求
看起來這應該是顯而易見的事，但需求就是來自客戶（這里要從內部和外部客戶的角度考慮）。不要依賴用戶寫下來的需求，真正的需求在客戶的腦袋裡。你要讓客戶解釋其需求，而且隨著開發的繼續，還要經常詢問客戶保證其需求仍然在開發的目的之中。一個不變的真理是：「只有我看見了我才知道我想要的是什麼」必然會導致大量的返工，因為資料庫沒有達到客戶從來沒有寫下來的需求標准。而更糟的是你對他們需求的解釋只屬於你自己，而且可能是完全錯誤的。
其餘四部分待續...
⑤ 資料庫課程設計實例
資料庫課程設計
題目：小型超市管理系統
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、小結
和傳統管理模式相比較，使用本系統，毫無疑問會大大提高超市的運作效率，輔助提高超市的決策水平，管理水平，為降低經營成本， 提高效益，減少差錯，節省人力，減少顧客購物時間，增加客流量，提高顧客滿意度，增強超市擴張能力， 提供有效的技術保障。
由於開發者能力有限，加上時間倉促，本系統難免會出現一些不足之處，例如：
本系統只適合小型超市使用，不能適合中大型超市使用；
超市管理系統涉及范圍寬，要解決的問題多，功能復雜，實現困難，但由於限於時間，本系統只能做出其中的一部分功能；
對於以上出現的問題，我們深表歉意，如發現還有其它問題，希望老師批評指正。
請採納。
⑥ sql資料庫設計實例
資料庫技術是信息資源開發、管理和服務的最有效的手段。隨著計算機技術、通信技術和網路技術的發展，資料庫的應用范圍越來越廣泛，已滲透到社會的各個領域。從小型的單項事務處理系統到大型復雜的信息系統大都採用先進的資料庫技術來保持系統數據的整體性、完整性和共享性。目前，資料庫的建設規模、資料庫信息的大小和使用頻度已成為衡量一個國家或地區信息化程度的重要標識之一。 資料庫設計時間里資料庫及其應用系統的技術，是信息系統開發和建設中的核心技術，具體說，資料庫設計是指對於一個給定的應用環境，構造最優的資料庫模式，建立資料庫及其應用系統，使之能夠有效地存儲數據，滿足各種用戶的應用需求（信息要求和處理要去）。 在資料庫領域內，使用資料庫的各類系統通常被稱為資料庫應用系統。資料庫技術和產品是計算機領域中最為活躍的部分之一，資料庫技術與產品的發展總是與計算機技術的發展密切相關，從主機到現在的Internet/Intranet及網路計算。資料庫總是站在技術的最前沿。 本系統採用了SQL SERVER 2008資料庫作為後台資料庫,SQL SERVER 2008是一個真正的多用戶、多線程SQL資料庫伺服器。 3.2 庫表概要設計 共分為以下四個資料庫表： (1) 用戶登陸信息表: Logintable (2) 客戶資料表：nomalpeopletable (3) 員工信息表: workpeopletable (4) 購買商品表：ordertable (5) 全國城市表：Citytable (6) 食品信息表：Goodstable Logintable（登錄驗證表） 列名 數據類型 是否可以為空 備注 controllerId int 不 管理員工號 Password nvarchar(50) 不 登錄密碼 Type Int 不 1為普通管理員；2為高級管理員 Clienttable（客戶信息表） 列名 數據類型 是否可以為空 備注 clientName nvarchar(50) 不 客戶名稱 clientOriginId Int 不 客戶來源(外鍵對應controllertable中，controllerId) clientSort nvarchar(50) 不 客戶類別（可選內容為工程商、代理商、工程甲方） clientCity nvarchar(50) 不 所在區域（可選框，全國的各個城市） clientPhone nvarchar(50) 不 聯系電話 clientprincipal nvarchar(50) 不 聯系人 clientMobile nvarchar(50) 可以 手機 clientAddress nvarchar(50) 不 聯系地址 controllertable（員工信息表） 列名 數據類型 是否可以為空 備注 controllerId int 不 管理員工號，隨機數 name nvarchar(50) 不 員工姓名 sex Char 不 員工性別 study Char 不 員工學歷 worktime nvarchar(50) 不 從業時間 purchasetable（客戶購買商品表） 列名 數據類型 是否可以為空 備注 Id Int 不 主鍵自增 clientName nvarchar(50) 不 企業名稱 Money Money 不 購買金額 Time nvarchar(50) 不 購買時間 controllerId Int 不 （所屬管理員）外鍵對應controllertable中，controllerId Text nvarchar(50) 不 產品名稱 citytable（全國城市表） 列名 數據類型 是否可以為空 備注 Id Int 不 主鍵自增 City nvarchar(50) 不 城市名（如：安徽合肥） goodsTable（物品信息表） 列名 數據類型 是否可以為空 備注 Id Int 不 主鍵自增 Shopname nvarchar(50) 不 物品名稱 unitprice Money 不 物品單價 不懂問我！我很在行的！~
⑦ 舉例說明資料庫設計步驟
1. 找出你要設計的資料庫裡面的實體，也就是對象，必須要有自己的屬性（特徵）；例如：課程和學生2. 指出唯一確定實體的屬性，如：一個學號唯一確定一個學生。3. 找出實體和實體之間的選課關系，就是所謂的一對多，多對一還是多對多。例如：一個學生選多門課程，一門課程為多個同學選擇。4。 初步形成一張關系表。如上所述。課程表（課程號（主鍵），課程名）學生表（學號（主鍵），姓名）成績表（學號，課程號（學號和課程號同時作為主鍵），成績） 不知你看懂沒？？ 可加我QQ 470285010 註明來意。我可以給你講解。
⑧ 誰有access資料庫設計實例！！！有的發我啊
1，範式
7大範式：1NF, 2NF,3NF,BCNF,4NF,5NF,6NF
什麼叫normalization？Denormalization?
Normalization是資料庫規范化，denormalization是資料庫逆規范化。
在設計和操作維護資料庫時，關鍵的步驟就是要確保數據正確地分布到資料庫的表中。使用正確的數據結構，不僅便於對資料庫進行相應的存取操作，而且可以極大地簡化應用程序的其他內容（查詢、窗體、報表、代碼等）。正確進行表設計的正式名稱就是"資料庫規范化"。目的：減少資料庫中數據冗餘，增進數據的一致性。
範式概念：
1）1NF：目標就是表中每列都不可分割；
2）2NF：目標就是表中的每行都是有標識的。前提是滿足了1NF. 當關鍵字為單field時，一定滿足2NF。當關鍵字為組合field時（即超過一個field）,不能存在組合關鍵字中有某個欄位能夠決定非關鍵欄位的某部分。非主field非部分依賴於主field，即非關鍵欄位必須完全依賴於一組 組合關鍵字，而不是組合關鍵字的某一部分。
3）3NF：目標是一個table裡面所有的列不依賴於另外一個table裡面非關鍵的列。前提是滿足了2NF，不存在某個非關鍵欄位決定另外一個非關鍵欄位。即：不存在傳遞依賴（關鍵字x->非關鍵屬性y->非關鍵屬性z）
4）BCNF：前提是滿足了2NF，不存在某個非關鍵欄位決定另外一個非關鍵欄位。也不存在某個關鍵欄位決定另外一個關鍵欄位。即：在3NF基礎上，加上約束：不存在某個關鍵欄位決定另外一個關鍵欄位。
1 第一範式（1NF）
在任何一個關系資料庫中，第一範式（1NF）是對關系模式的基本要求，不滿足第一範式（1NF）的資料庫就不是關系資料庫。所謂第一範式（1NF）是指資料庫表的每一列都是不可分割的基本數據項，同一列中不能有多個值，即實體中的某個屬性不能有多個值或者不能有重復的屬性。如果出現重復的屬性，就可能需要定義一個新的實體，新的實體由重復的屬性構成，新實體與原實體之間為一對多關系。在第一範式（1NF）中表的每一行只包含一個實例的信息。例如，對於圖3-2 中的員工信息表，不能將員工信息都放在一列中顯示，也不能將其中的兩列或多列在一列中顯示；員工信息表的每一行只表示一個員工的信息，一個員工的信息在表中只出現一次。簡而言之，第一範式就是無重復的列。
2 第二範式（2NF）
第二範式（2NF）是在第一範式（1NF）的基礎上建立起來的，即滿足第二範式（2NF）必須先滿足第一範式（1NF）。第二範式（2NF）要求資料庫表中的每個實例或行必須可以被惟一地區分。為實現區分通常需要為表加上一個列，以存儲各個實例的惟一標識。如圖3-2 員工信息表中加上了員工編號（emp_id）列，因為每個員工的員工編號是惟一的，因此每個員工可以被惟一區分。這個惟一屬性列被稱為主關鍵字或主鍵、主碼。第二範式（2NF）要求實體的屬性完全依賴於主關鍵字。所謂完全依賴是指不能存在僅依賴主關鍵字一部分的屬性，如果存在，那麼這個屬性和主關鍵字的這一部分應該分離出來形成一個新的實體，新實體與原實體之間是一對多的關系。為實現區分通常需要為表加上一個列，以存儲各個實例的惟一標識。簡而言之，第二範式就是非主屬性非部分依賴於主關鍵字。
3 第三範式（3NF）
滿足第三範式（3NF）必須先滿足第二範式（2NF）。簡而言之，第三範式（3NF）要求一個資料庫表中不包含已在其它表中已包含的非主關鍵字信息。例如，存在一個部門信息表，其中每個部門有部門編號（dept_id）、部門名稱、部門簡介等信息。那麼在圖3-2的員工信息表中列出部門編號後就不能再將部門名稱、部門簡介等與部門有關的信息再加入員工信息表中。如果不存在部門信息表，則根據第三範式（3NF）也應該構建它，否則就會有大量的數據冗餘。簡而言之，第三範式就是屬性不依賴於其它非主屬性。
例子：
第一範式（1NF）：資料庫表中的欄位都是單一屬性的，不可再分。這個單一屬性由基本類型構成，包括整型、實數、字元型、邏輯型、日期型等。
例如，如下的資料庫表是符合第一範式的：欄位1 欄位2 欄位3 欄位4
而這樣的資料庫表是不符合第一範式的：欄位1 欄位2 欄位3 欄位4 欄位31欄位32
很顯然，在當前的任何關系資料庫管理系統（S）中，傻瓜也不可能做出不符合第一範式的資料庫，因為這些S不允許你把資料庫表的一列再分成二列或多列。因此，你想在現有的S中設計出不符合第一範式的資料庫都是不可能的。
第二範式（2NF）：資料庫表中不存在非關鍵欄位對任一候選關鍵欄位的部分函數依賴（部分函數依賴指的是存在組合關鍵字中的某些欄位決定非關鍵欄位的情況），也即所有非關鍵欄位都完全依賴於任意一組候選關鍵字。
假定選課關系表為Ss(學號, 姓名, 年齡, 課程名稱, 成績, 學分)，關鍵字為組合關鍵字(學號, 課程名稱)，因為存在如下決定關系：
(學號, 課程名稱) → (姓名, 年齡, 成績, 學分)
這個資料庫表不滿足第二範式，因為存在如下決定關系：
(課程名稱) → (學分)
(學號) → (姓名, 年齡)
即存在組合關鍵字中的欄位決定非關鍵字的情況。
由於不符合2NF，這個選課關系表會存在如下問題：1) 數據冗餘：同一門課程由n個學生選修，"學分"就重復n-1次；同一個學生選修了門課程，姓名和年齡就重復了-1次。2) 更新異常：若調整了某門課程的學分，數據表中所有行的"學分"值都要更新，否則會出現同一門課程學分不同的情況。3) 插入異常：假設要開設一門新的課程，暫時還沒有人選修。由於還沒有"學號"關鍵字，課程名稱和學分也無法記錄入資料庫。4) 刪除異常：假設一批學生已經完成課程的選修，這些選修記錄就應該從資料庫表中刪除。但是，與此同時，課程名稱和學分信息也被刪除了。很顯然，這也會導致插入異常。
把選課關系表Ss改為如下三個表：
學生：Sn(學號, 姓名, 年齡)；
課程：s(課程名稱, 學分)；
選課關系：Ss(學號, 課程名稱, 成績)。
這樣的資料庫表是符合第二範式的，消除了數據冗餘、更新異常、插入異常和刪除異常。
另外，所有單關鍵字的資料庫表都符合第二範式，因為不可能存在組合關鍵字。
第三範式（3NF）：在第二範式的基礎上，數據表中如果不存在非關鍵欄位對任一候選關鍵欄位的傳遞函數依賴則符合第三範式。所謂傳遞函數依賴，指的是如果存在"A → → "的決定關系，則傳遞函數依賴於A。因此，滿足第三範式的資料庫表應該不存在如下依賴關系：關鍵欄位 → 非關鍵欄位x → 非關鍵欄位y
假定學生關系表為Sn(學號, 姓名, 年齡, 所在[]學院[], 學院地點, 學院電話)，關鍵字為單一關鍵字"學號"，因為存在如下決定關系：
(學號) → (姓名, 年齡, 所在[]學院[], 學院[]地點, []學院[]電話)
這個資料庫是符合2NF的，但是不符合3NF，因為存在如下決定關系：
(學號) → (所在[]學院[]) → ([]學院[]地點, []學院[]電話)
即存在非關鍵欄位"[]學院[]地點"、"[]學院[]電話"對關鍵欄位"學號"的傳遞函數依賴。
它也會存在數據冗餘、更新異常、插入異常和刪除異常的情況，讀者可自行分析得知。
把學生關系表分為如下兩個表：
學生：(學號, 姓名, 年齡, 所在[]學院[])；
[]學院[]：([]學院[], 地點, 電話)。
這樣的資料庫表是符合第三範式的，消除了數據冗餘、更新異常、插入異常和刪除異常。
鮑依斯-科得範式（BCNF）：在第三範式的基礎上，資料庫表中如果不存在任何欄位對任一候選關鍵欄位的傳遞函數依賴則符合BCNF.
假設倉庫管理關系表為Ssanag(倉庫, 存儲物品, 管理員, 數量)，且有一個管理員只在一個倉庫工作；一個倉庫可以存儲多種物品。這個資料庫表中存在如下決定關系：
(倉庫, 存儲物品) →(管理員, 數量)
(管理員, 存儲物品) → (倉庫, 數量)
所以，(倉庫, 存儲物品)和(管理員, 存儲物品)都是Ssanag的候選關鍵字，表中的唯一非關鍵欄位為數量，它是符合第三範式的。但是，由於存在如下決定關系：
(倉庫) → (管理員)
(管理員) → (倉庫)
即存在關鍵欄位決定關鍵欄位的情況，所以其不符合BCNF範式。它會出現如下異常情況：1) 刪除異常：當倉庫被清空後，所有"存儲物品"和"數量"信息被刪除的同時，"倉庫"和"管理員"信息也被刪除了。2) 插入異常：當倉庫沒有存儲任何物品時，無法給倉庫分配管理員。3) 更新異常：如果倉庫換了管理員，則表中所有行的管理員都要修改。
把倉庫管理關系表分解為二個關系表：
倉庫管理：Ssanag(倉庫, 管理員)；
倉庫：Ss(倉庫, 存儲物品, 數量)。
這樣的資料庫表是符合BCNF範式的，消除了刪除異常、插入異常和更新異常。
簡言之資料庫五大範式：
第一範式：對於表中的每一行，必須且僅僅有唯一的行值.在一行中的每一列僅有唯一的值並且具有原子性.
（第一範式是通過把重復的組放到每個獨立的表中，把這些表通過一對多關聯聯系起來這種方式來消除重復組的）
第二範式：第二範式要求非主鍵列是主鍵的子集，非主鍵列活動必須完全依賴整個主鍵。主鍵必須有唯一性的元素,一個主鍵可以由一個或更多的組成唯一值的列組成。一旦創建，主鍵無法改變，外鍵關聯一個表的主鍵。主外鍵關聯意味著一對多的關系.（第二範式處理冗餘數據的刪除問題。當某張表中的信息依賴於該表中其它的不是主鍵部分的列的時候，通常會違反第二範式）
第三範式：第三範式要求非主鍵列互不依賴.（第三範式規則查找以消除沒有直接依賴於第一範式和第二範式形成的表的主鍵的屬性。我們為沒有與表的主鍵關聯的所有信息建立了一張新表。每張新表保存了來自源表的信息和它們所依賴的主鍵）
第四範式：第四範式禁止主鍵列和非主鍵列一對多關系不受約束
第五範式：第五範式將表分割成盡可能小的塊，為了排除在表中所有的冗餘。
⑨ 求SQL資料庫設計實例
我有畢業設計全套
學生成績管理系統，8個表，java+ sql server 2000 的
rmb 200 或者 給我魔獸點卡G幣。。。哈哈哈