資料庫設計例子
A. 資料庫設計問題(業務審批流程)
1、用戶表
用戶ID
用戶角色（1：業務員，2：經理，3：總經理，4：總裁。。。）
用戶姓名
2、客戶表
客戶ID
客戶名稱
3、業務員客戶表
用戶ID（其實就是用戶表裡的用戶角色為業務員的用戶）
客戶ID
4、業務員移交客戶申請表
申請人用戶ID
申請移交的客戶ID
審批狀態（0：審批中，1：已審批。。。。）
移交後用戶ID
5、請假表
用戶ID
請假開始時間
請假結束時間
請假類別（1：事假、2：病假、3：婚假。。。。。）
審批狀態（0：審批中，1：已審批。。。。）
6、周報表
用戶ID
周報月份
審批狀態（0：臨時保存，1：已提交，2：經理已審批，3：總經理已審批。。。。）
其實具體控制，你要在程序里進行流程式控制制，並沒有你說的那種自動控制，不過這樣的表結構設計是可以滿足你後期不用再動資料庫，只用修改業務流程即可
B. 請大夥給我解釋一下資料庫設計的基本原則！
資料庫設計的三範式所謂範式，是關系型資料庫關系模式規范化的標准，從規范化的寬松到嚴格，分別為不同的範式，通常使用的有第一範式、第二範式、第三範式及BC範式等。範式是建立在函數依賴基礎上的。
函數依賴
定義：設有關系模式R(U)，X和Y是屬性集U的子集，函數依賴是形為X→Y的一個命題，對任意R中兩個元組t和s，都有t[X]=s[X]蘊涵t[Y]=s[Y]，那麼FD X→Y在關系模式R(U)中成立。X→Y讀作『X函數決定Y』，或『Y函數依賴於X』。通俗的講，如果一個表中某一個欄位Y的值是由另外一個欄位或一組欄位X的值來確定的，就稱為Y函數依賴於X。函數依賴應該是通過理解數據項和企業的規則來決定的，根據表的內容得出的函數依賴可能是不正確的。
第一範式（1NF）
定義：如果關系模式R的每個關系r的屬性都是不可分的數據項，那麼就稱R是第一範式的模式。
簡單的說，每一個屬性都是原子項，不可分割。1NF是關系模式應具備的最起碼的條件，如果資料庫設計不能滿足第一範式，就不稱為關系型資料庫。關系資料庫設計研究的關系規范化是在1NF之上進行的。
第二範式（2NF）
定義：如果關系模式R是1NF，且每個非主屬性完全函數依賴於候選鍵，那麼就稱R是第二範式。
簡單的說，第二範式要滿足以下的條件：首先要滿足第一範式，其次每個非主屬性要完全函數依賴與候選鍵，或者是主鍵。也就是說，每個非主屬性是由整個主鍵函數決定的，而不能由主鍵的一部分來決定。舉個例子：
有股票日行情表的主鍵是股 票代碼和交易日期組成。非主屬性中有收盤價和成交量等，都是由主鍵，即股票代碼和交易日期函數決定的，單獨的股票代碼或者交易日期都不能函數決定這些非主 屬性。如果這個表中有非主屬性股票簡稱，則股票簡稱是可以由股票代碼來函數決定的，這樣股票簡稱這個非主屬性就不是完全函數依賴於候選鍵，這樣的設計就不 滿足第二範式。
第三範式（3NF）
定義：如果關系模式R是2NF，且關系模式R（U，F）中的所有非主屬性對任何候選關鍵字都不存在傳遞依賴，則稱關系R是屬於第三範式。
簡單的說，第三範式要滿足以下的條件：首先要滿足第二範式，其次非主屬性之間不存在函數依賴。由於滿足了第二範式，表示每個非主屬性都函數依賴於主鍵。如果非主屬性之間存在了函數依賴，就會存在傳遞依賴，這樣就不滿足第三範式。
舉 個例子：在股票基本情況表中，主鍵是股票代碼，有非主屬性所屬一級行業和所屬二級行業。根據業務規則，所屬二級行業能夠函數決定所屬一級行業，這就表示存 在這樣一種關系：股票代碼函數決定所屬二級行業，所屬二級行業函數決定所屬一級行業，這就形成了傳遞依賴，這樣的設計就不符合第三範式。不過在實際運用 中，為查詢和使用的方便，有時也會違反第三範式。如上例，如果沒有所屬一級行業的屬性，需要查詢所屬一級行業的相關股票，需要查詢時使用函數來從二級行業 中函數生成所屬一級行業，使用性能上會受影響。所以通常會加上所屬一級行業的屬性。
BC範式（BCNF）
BC範式是第三範式的增強版，不過也有人說是直接從1NF發展過來的，即每個屬性，包括主屬性或非主屬性，都完全依賴於候選鍵，並且不存在傳遞依賴情況。
C. 資料庫課程設計實例
資料庫課程設計
題目：小型超市管理系統
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、小結
和傳統管理模式相比較，使用本系統，毫無疑問會大大提高超市的運作效率，輔助提高超市的決策水平，管理水平，為降低經營成本， 提高效益，減少差錯，節省人力，減少顧客購物時間，增加客流量，提高顧客滿意度，增強超市擴張能力， 提供有效的技術保障。
由於開發者能力有限，加上時間倉促，本系統難免會出現一些不足之處，例如：
本系統只適合小型超市使用，不能適合中大型超市使用；
超市管理系統涉及范圍寬，要解決的問題多，功能復雜，實現困難，但由於限於時間，本系統只能做出其中的一部分功能；
對於以上出現的問題，我們深表歉意，如發現還有其它問題，希望老師批評指正。
D. 急！高分求做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語言進行程序設計時，盡量採取優化演算法。
總之，要提高資料庫的運行效率，必須從資料庫系統級優化、資料庫設計級優化、程序實現級優化，這三個層次上同時下功夫。
E. 資料庫如何設計
資料庫設計的基本步驟
按照規范設計的方法，考慮資料庫及其應用系統開發全過程，將資料庫設計分為以下6個階段
1.需求分析
2.概念結構設計
3.邏輯結構設計
4.物理結構設計
5.資料庫實施
6.資料庫的運行和維護
資料庫設計通常分為6個階段1分析用戶的需求，包括數據、功能和性能需求；2概念結構設計：主要採用E-R模型進行設計，包括畫E-R圖；3邏輯結構設計：通過將轉換成表，實現從E-R模型到關系模型的轉換；4：主要是為所設計的資料庫選擇合適的和存取路徑；5資料庫的實施：包括編程、測試和試運行；6資料庫運行與維護：系統的運行與資料庫的日常維護。）,主要討論其中的第3個階段,即邏輯設計。
在資料庫設計過程中，需求分析和概念設計可以獨立於任何資料庫管理系統進行，邏輯設計和物理設計與選用的DAMS密切相關。
1.需求分析階段（常用自頂向下）
進行資料庫設計首先必須准確了解和分析用戶需求（包括數據與處理）。需求分析是整個設計過程的基礎，也是最困難，最耗時的一步。需求分析是否做得充分和准確，決定了在其上構建資料庫大廈的速度與質量。需求分析做的不好，會導致整個資料庫設計返工重做。
需求分析的任務，是通過詳細調查現實世界要處理的對象，充分了解原系統工作概況，明確用戶的各種需求，然後在此基礎上確定新的系統功能，新系統還得充分考慮今後可能的擴充與改變，不僅僅能夠按當前應用需求來設計。
調查的重點是，數據與處理。達到信息要求，處理要求，安全性和完整性要求。
分析方法常用SA(Structured Analysis) 結構化分析方法，SA方法從最上層的系統組織結構入手，採用自頂向下，逐層分解的方式分析系統。
數據流圖表達了數據和處理過程的關系，在SA方法中，處理過程的處理邏輯常常藉助判定表或判定樹來描述。在處理功能逐步分解的同事，系統中的數據也逐級分解，形成若干層次的數據流圖。系統中的數據則藉助數據字典（data dictionary，DD）來描述。數據字典是系統中各類數據描述的集合，數據字典通常包括數據項，數據結構，數據流，數據存儲，和處理過程5個階段。
2.概念結構設計階段（常用自底向上）
概念結構設計是整個資料庫設計的關鍵，它通過對用戶需求進行綜合，歸納與抽象，形成了一個獨立於具體DBMS的概念模型。
設計概念結構通常有四類方法：
自頂向下。即首先定義全局概念結構的框架，再逐步細化。
自底向上。即首先定義各局部應用的概念結構，然後再將他們集成起來，得到全局概念結構。
逐步擴張。首先定義最重要的核心概念結構，然後向外擴張，以滾雪球的方式逐步生成其他的概念結構，直至總體概念結構。
混合策略。即自頂向下和自底向上相結合。
- 需要注意：
- ● 在確定支持數據時，請一定要參考你之前所確定的宏觀行為，以清楚如何利用這些數據。
- ● 比如，如果你知道你需要所有員工的按姓氏排序的列表，確保你將支持數據分解為名字與姓氏，這比簡單地提供一個名字會更好。
- ● 你所選擇的名稱最好保持一致性。這將更易於維護資料庫，也更易於閱讀所輸出的報表。
- ● 比如，如果你在某些地方用了一個縮寫名稱Emp_status，你就不應該在另外一個地方使用全名(Empolyee_ID)。相反，這些名稱應當是Emp_status及Emp_id。
- ● 數據是否與正確的table相對應無關緊要，你可以根據自己的喜好來定。在下節中，你會通過測試對此作出判斷。
3.邏輯結構設計階段（E-R圖）
邏輯結構設計是將概念結構轉換為某個DBMS所支持的數據模型，並將進行優化。
在這階段，E-R圖顯得異常重要。大家要學會各個實體定義的屬性來畫出總體的E-R圖。
各分E-R圖之間的沖突主要有三類：屬性沖突，命名沖突，和結構沖突。
E-R圖向關系模型的轉換，要解決的問題是如何將實體性和實體間的聯系轉換為關系模式，如何確定這些關系模式的屬性和碼。
4.物理設計階段
物理設計是為邏輯數據結構模型選取一個最適合應用環境的物理結構（包括存儲結構和存取方法）。
首先要對運行的事務詳細分析，獲得選擇物理資料庫設計所需要的參數，其次，要充分了解所用的RDBMS的內部特徵，特別是系統提供的存取方法和存儲結構。
常用的存取方法有三類：1.索引方法，目前主要是B+樹索引方法。2.聚簇方法（Clustering）方法。3.是HASH方法。
5.資料庫實施階段
資料庫實施階段，設計人員運營DBMS提供的資料庫語言（如sql）及其宿主語言，根據邏輯設計和物理設計的結果建立資料庫，編制和調試應用程序，組織數據入庫，並進行試運行。
6.資料庫運行和維護階段
資料庫應用系統經過試運行後，即可投入正式運行，在資料庫系統運行過程中必須不斷地對其進行評價，調整，修改。
資料庫設計5步驟
Five Steps to design the Database
1.確定entities及relationships
a)明確宏觀行為。資料庫是用來做什麼的？比如，管理雇員的信息。
b)確定entities。對於一系列的行為，確定所管理信息所涉及到的主題范圍。這將變成table。比如，僱用員工，指定具體部門，確定技能等級。
c)確定relationships。分析行為，確定tables之間有何種關系。比如，部門與雇員之間存在一種關系。給這種關系命名。
d)細化行為。從宏觀行為開始，現在仔細檢查這些行為，看有哪些行為能轉為微觀行為。比如，管理雇員的信息可細化為：
· 增加新員工
· 修改存在員工信息
· 刪除調走的員工
e)確定業務規則。分析業務規則，確定你要採取哪種。比如，可能有這樣一種規則，一個部門有且只能有一個部門領導。這些規則將被設計到資料庫的結構中。
====================================================================
範例：
ACME是一個小公司，在5個地方都設有辦事處。當前，有75名員工。公司准備快速擴大規模，劃分了9個部門，每個部門都有其領導。
為有助於尋求新的員工，人事部門規劃了68種技能，為將來人事管理作好准備。員工被招進時，每一種技能的專業等級都被確定。
定義宏觀行為
一些ACME公司的宏觀行為包括：
● 招聘員工
● 解僱員工
● 管理員工個人信息
● 管理公司所需的技能信息
● 管理哪位員工有哪些技能
● 管理部門信息
● 管理辦事處信息
確定entities及relationships
我們可以確定要存放信息的主題領域(表)及其關系，並創建一個基於宏觀行為及描述的圖表。
我們用方框來代表table，用菱形代表relationship。我們可以確定哪些relationship是一對多，一對一，及多對多。
這是一個E-R草圖，以後會細化。
細化宏觀行為
以下微觀行為基於上面宏觀行為而形成：
● 增加或刪除一個員工
● 增加或刪除一個辦事處
● 列出一個部門中的所有員工
● 增加一項技能
● 增加一個員工的一項技能
● 確定一個員工的技能
● 確定一個員工每項技能的等級
● 確定所有擁有相同等級的某項技能的員工
● 修改員工的技能等級
這些微觀行為可用來確定需要哪些table或relationship。
確定業務規則
業務規則常用於確定一對多，一對一，及多對多關系。
相關的業務規則可能有：
● 現在有5個辦事處；最多允許擴展到10個。
● 員工可以改變部門或辦事處
● 每個部門有一個部門領導
● 每個辦事處至多有3個電話號碼
● 每個電話號碼有一個或多個擴展
● 員工被招進時，每一種技能的專業等級都被確定。
● 每位員工擁有3到20個技能
● 某位員工可能被安排在一個辦事處，也可能不安排辦事處。
2.確定所需數據
要確定所需數據：
a)確定支持數據
b)列出所要跟蹤的所有數據。描述table(主題)的數據回答這些問題：誰，什麼，哪裡，何時，以及為什麼
c)為每個table建立數據
d)列出每個table目前看起來合適的可用數據
e)為每個relationship設置數據
f)如果有，為每個relationship列出適用的數據
確定支持數據
你所確定的支持數據將會成為table中的欄位名。比如，下列數據將適用於表Employee，表Skill，表Expert In。
Employee
Skill
Expert In
ID
ID
Level
Last Name
Name
Date acquired
First Name
Description
Department
Office
Address
如果將這些數據畫成圖表，就像：
3.標准化數據
標准化是你用以消除數據冗餘及確保數據與正確的table或relationship相關聯的一系列測試。共有5個測試。本節中，我們將討論經常使用的3個。
關於標准化測試的更多信息，請參考有關資料庫設計的書籍。
標准化格式
標准化格式是標准化數據的常用測試方式。你的數據通過第一遍測試後，就被認為是達到第一標准化格式；通過第二遍測試，達到第二標准化格式；通過第三遍測試，達到第三標准化格式。
如何標准格式：
1． 列出數據
2． 為每個表確定至少一個鍵。每個表必須有一個主鍵。
3． 確定relationships的鍵。relationships的鍵是連接兩個表的鍵。
4． 檢查支持數據列表中的計算數據。計算數據通常不保存在資料庫中。
5． 將數據放在第一遍的標准化格式中：
6． 從tables及relationships除去重復的數據。
7． 以你所除去數據創建一個或更多的tables及relationships。
8． 將數據放在第二遍的標准化格式中：
9． 用多於一個以上的鍵確定tables及relationships。
10． 除去只依賴於鍵一部分的數據。
11． 以你所除去數據創建一個或更多的tables及relationships。
12． 將數據放在第三遍的標准化格式中：
13． 除去那些依賴於tables或relationships中其他數據，並且不是鍵的數據。
14． 以你所除去數據創建一個或更多的tables及relationships。
數據與鍵
在你開始標准化（測試數據）前，簡單地列出數據，並為每張表確定一個唯一的主鍵。這個鍵可以由一個欄位或幾個欄位（連鎖鍵）組成。
主鍵是一張表中唯一區分各行的一組欄位。Employee表的主鍵是Employee ID欄位。Works In relationship中的主鍵包括Office Code及Employee ID欄位。給資料庫中每一relationship給出一個鍵，從其所連接的每一個table中抽取其鍵產生。
RelationShip
Key
Office
*Office code
Office address
Phone number
Works in
*Office code
*Employee ID
Department
*Department ID
Department name
Heads
*Department ID
*Employee ID
Assoc with
*Department ID
*EmployeeID
Skill
*Skill ID
Skill name
Skill description
Expert In
*Skill ID
*Employee ID
Skill level
Date acquired
Employee
*Employee ID
Last Name
First Name
Social security number
Employee street
Employee city
Employee state
Employee phone
Date of birth
將數據放在第一遍的標准化格式中
● 除去重復的組
● 要測試第一遍標准化格式，除去重復的組，並將它們放進他們各自的一張表中。
● 在下面的例子中，Phone Number可以重復。（一個工作人員可以有多於一個的電話號碼。）將重復的組除去，創建一個名為Telephone的新表。在Telephone與Office創建一個名為Associated With的relationship。
將數據放在第二遍的標准化格式中
● 除去那些不依賴於整個鍵的數據。
● 只看那些有一個以上鍵的tables及relationships。要測試第二遍標准化格式，除去那些不依賴於整個鍵的任何數據（組成鍵的所有欄位）。
● 在此例中，原Employee表有一個由兩個欄位組成的鍵。一些數據不依賴於整個鍵；例如，department name只依賴於其中一個鍵（Department ID）。因此，Department ID，其他Employee數據並不依賴於它，應移至一個名為Department的新表中，並為Employee及Department建立一個名為Assigned To的relationship。
將數據放在第三遍的標准化格式中
● 除去那些不直接依賴於鍵的數據。
● 要測試第三遍標准化格式，除去那些不是直接依賴於鍵，而是依賴於其他數據的數據。
● 在此例中，原Employee表有依賴於其鍵（Employee ID）的數據。然而，office location及office phone依賴於其他欄位，即Office Code。它們不直接依賴於Employee ID鍵。將這組數據，包括Office Code，移至一個名為Office的新表中，並為Employee及Office建立一個名為Works In的relationship。
4.考量關系
當你完成標准化進程後，你的設計已經差不多完成了。你所需要做的，就是考量關系。
考量帶有數據的關系
你的一些relationship可能集含有數據。這經常發生在多對多的關系中。
遇到這種情況，將relationship轉化為一個table。relationship的鍵依舊成為table中的鍵。
考量沒有數據的關系
要實現沒有數據的關系，你需要定義外部鍵。外部鍵是含有另外一個表中主鍵的一個或多個欄位。外部鍵使你能同時連接多表數據。
有一些基本原則能幫助你決定將這些鍵放在哪裡：
一對多在一對多關系中，「一」中的主鍵放在「多」中。此例中，外部鍵放在Employee表中。
一對一在一對一關系中，外部鍵可以放進任一表中。如果必須要放在某一邊，而不能放在另一邊，應該放在必須的一邊。此例中，外部鍵（Head ID）在Department表中，因為這是必需的。
多對多在多對多關系中，用兩個外部鍵來創建一個新表。已存的舊表通過這個新表來發生聯系。
5.檢驗設計
在你完成設計之前，你需要確保它滿足你的需要。檢查你在一開始時所定義的行為，確認你可以獲取行為所需要的所有數據：
● 你能找到一個路徑來等到你所需要的所有信息嗎？
● 設計是否滿足了你的需要？
● 所有需要的數據都可用嗎？
如果你對以上的問題都回答是，你已經差不多完成設計了。
最終設計
最終設計看起來就像這樣：
設計資料庫的表屬性
資料庫設計需要確定有什麼表，每張表有什麼欄位。此節討論如何指定各欄位的屬性。
對於每一欄位，你必須決定欄位名，數據類型及大小，是否允許NULL值，以及你是否希望資料庫限制欄位中所允許的值。
選擇欄位名
欄位名可以是字母、數字或符號的任意組合。然而，如果欄位名包括了字母、數字或下劃線、或並不以字母打頭，或者它是個關鍵字（詳見關鍵字表），那麼當使用欄位名稱時，必須用雙引號括起來。
為欄位選擇數據類型
SQL Anywhere支持的數據類型包括：
整數（int, integer, smallint）
小數（decimal, numeric）
浮點數（float, double）
字元型（char, varchar, long varchar）
二進制數據類型（binary, long binary）
日期/時間類型（date, time, timestamp）
用戶自定義類型
關於數據類型的內容，請參見「SQL Anywhere數據類型」一節。欄位的數據類型影響欄位的最大尺寸。例如，如果你指定SMALLINT，此欄位可以容納32,767的整數。INTEGER可以容納2,147,483,647的整數。對CHAR來講，欄位的最大值必須指定。
長二進制的數據類型可用來在資料庫中保存例如圖像(如點陣圖)或者文字編輯文檔。這些類型的信息通常被稱為二進制大型對象，或者BLOBS。
關於每一數據類型的完整描述，見「SQL Anywhere數據類型」。
F. 資料庫具體應用的實例有哪些
資料庫的應用領域
1、多媒體資料庫： 這類資料庫主要存儲與多媒體相關的數據，如聲音、圖像和視頻等數據。多媒體數據最大的特點是數據連續，而且數據量比較大，存儲需要的空間較大。
2、移動資料庫： 該類資料庫是在移動計算機系統上發展起來的，如筆記本電腦、掌上計算機等。該資料庫最大的特點是通過無線數字通信網路傳輸的。移動資料庫可以隨時隨地地獲取和訪問數據，為一些商務應用和一些緊急情況帶來了很大的便利。
3、空間資料庫： 這類資料庫目前發展比較迅速。它主要包括地理信息資料庫（又稱為地理信息系統，即GIS）和計算機輔助設計（CAD）資料庫。其中地理信息資料庫一般存儲與地圖相關的信息數據；計算機輔助設計資料庫一般存儲設計信息的空間資料庫，如機械、集成電路以及電子設備設計圖等。
4、信息檢索系統： 信息檢索就是根據用戶輸入的信息，從資料庫中查找相關的文檔或信息，並把查找的信息反饋給用戶。信息檢索領域和資料庫是同步發展的，它是一種典型的聯機文檔管理系統或者聯機圖書目錄。
5、分布式信息檢索： 這類資料庫是隨著Internet的發展而產生的資料庫。它一般用於網際網路及遠距離計算機網路系統中。特別是隨著電子商務的發展，這類資料庫發展更加迅猛。
許多網路用戶（如個人、公司或企業等）在自己的計算機中存儲信息，同時希望通過網路使用發送電子郵件、文件傳輸、遠程登錄方式和別人共享這些信息。分布式信息檢索滿足了這一要求。
6、專家決策系統： 專家決策系統也是資料庫應用的一部分。由於越來越多的數據可以聯機獲取，特別是企業通過這些數據可以對企業的發展作出更好的決策，以使企業更好地運行。由於人工智慧的發展，使得專家決策系統的應用更加廣泛。
(6)資料庫設計例子擴展閱讀
對資料庫系統的基本要求是：
①能夠保證數據的獨立性。數據和程序相互獨立有利於加快軟體開發速度，節省開發費用。
②冗餘數據少，數據共享程度高。
③系統的用戶介面簡單，用戶容易掌握，使用方便。
④能夠確保系統運行可靠，出現故障時能迅速排除；能夠保護數據不受非受權者訪問或破壞；能夠防止錯誤數據的產生，一旦產生也能及時發現。
⑤有重新組織數據的能力，能改變數據的存儲結構或數據存儲位置，以適應用戶操作特性的變化，改善由於頻繁插入、刪除操作造成的數據組織零亂和時空性能變壞的狀況。
⑥具有可修改性和可擴充性。
⑦能夠充分描述數據間的內在聯系。
G. 怎樣建立一個小型資料庫
什麼類型的項目使用資料庫：
對於Java：小型的話就是MySQL了，關於他的學習可以從網上搜集資源的。SQLServer的也可以。如果是大型資料庫的時候採用 Oracle。
先討論好你的項目需求，做好分析後，設計資料庫（database,table，關系等）。
H. 資料庫設計中為什麼進行分類編碼設計分類的方法是什麼
分類演算法要解決的問題
在網站建設中，分類演算法的應用非常的普遍。在設計一個電子商店時，要涉及到商品分類；在設計發布系統時，要涉及到欄目或者頻道分類；在設計軟體下載這樣的程序時，要涉及到軟體的分類；如此等等。可以說，分類是一個很普遍的問題。
我常常面試一些程序員，而且我幾乎毫無例外地要問他們一些關於分類演算法的問題。下面的舉幾個我常常詢問的問題。你認為你可以很輕松地回答么？
1、分類演算法常常表現為樹的表示和遍歷問題。那麼，請問：如果用資料庫中的一個Table來表達樹型分類，應該有幾個欄位？
2、如何快速地從這個Table恢復出一棵樹？
3、如何判斷某個分類是否是另一個分類的子類？
4、如何查找某個分類的所有產品？
5、如何生成分類所在的路徑。
6、如何新增分類？
在不限制分類的級數和每級分類的個數時，這些問題並不是可以輕松回答的。本文試圖解決這些問題。
分類的數據結構
我們知道：分類的數據結構實際上是一棵樹。在《數據結構》課程中，大家可能學過Tree的演算法。由於在網站建設中我們大量使用資料庫，所以我們將從Tree在資料庫中的存儲談起。
為簡化問題，我們假設每個節點只需要保留Name這一個信息。我們需要為每個節點編號。編號的方法有很多種。在資料庫中常用的就是自動編號。這在Access、SQL Server、Oracle中都是這樣。假設編號欄位為ID。
為了表示某個節點ID1是另外一個節點ID2的父節點，我們需要在資料庫中再保留一個欄位，說明這個分類是屬於哪個節點的兒子。把這個欄位取名為FatherID。如這里的ID2，其FatherID就是ID1。
這樣，我們就得到了分類Catalog的數據表定義：
Create Table [Catalog](
[ID] [int] NOT NULL,
[Name] [nvarchar](50) NOT NULL,
[FatherID] [int] NOT NULL
);
約定：我們約定用-1作為最上面一層分類的父親編碼。編號為-1的分類。這是一個虛擬的分類。它在資料庫中沒有記錄。
如何恢復出一棵樹
上面的Catalog定義的最大優勢，就在於用它可以輕松地恢復出一棵樹?分類樹。為了更清楚地展示演算法，我們先考慮一個簡單的問題：怎樣顯示某個分類的下一級分類。我們知道，要查詢某個分類FID的下一級分類，SQL語句非常簡單：
select Name from catalog where FatherID=FID
顯示這些類別時，我們可以這樣：
<%
REM oConn---資料庫連接，調用GetChildren時已經打開
REM FID-----當前分類的編號
Function GetChildren(oConn,FID)
strSQL = "select ID,Name from catalog where FatherID="&FID
set rsCatalog = oConn.Execute(strSQL)
%>
<UL>
<%
Do while not rsCatalog.Eof
%>
<LI><%=rsCatalog("Name")%>
<%
Loop
%>
</UL>
<%
rsCatalog.Close
End Function
%>
現在我們來看看如何顯示FID下的所有分類。這需要用到遞歸演算法。我們只需要在GetChildren函數中簡單地對所有ID進行調用：GetChildren(oConn,Catalog(「ID」))就可以了。
<%
REM oConn---資料庫連接，已經打開
REM FID-----當前分類的編號
Function GetChildren(oConn,FID)
strSQL = "select Name from catalog where FatherID="&FID
set rsCatalog = oConn.Execute(strSQL)
%>
<UL>
<%
Do while not rsCatalog.Eof
%>
<LI><%=rsCatalog("Name")%>
<%=GetChildren(oConn,Catalog("ID"))%>
<%
Loop
%>
</UL>
<%
rsCatalog.Close
End Function
%>
修改後的GetChildren就可以完成顯示FID分類的所有子分類的任務。要顯示所有的分類，只需要如此調用就可以了：
<%
REM strConn--連接資料庫的字元串，請根據情況修改
set oConn = Server.CreateObject("ADODB.Connection")
oConn.Open strConn
=GetChildren(oConn,-1)
oConn.Close
%>
如何查找某個分類的所有產品
現在來解決我們在前面提出的第四個問題。第三個問題留作習題。我們假設產品的數據表如下定義：
Create Table Proct(
[ID] [int] NOT NULL,
[Name] [nvchar] NOT NULL,
[FatherID] [int] NOT NULL
);
其中，ID是產品的編號，Name是產品的名稱，而FatherID是產品所屬的分類。對第四個問題，很容易想到的辦法是：先找到這個分類FID的所有子類，然後查詢所有子類下的所有產品。實現這個演算法實際上很復雜。代碼大致如下：
<%
Function GetAllID(oConn,FID)
Dim strTemp
If FID=-1 then
strTemp = ""
else
strTemp =","
end if
strSQL = "select Name from catalog where FatherID="&FID
set rsCatalog = oConn.Execute(strSQL)
Do while not rsCatalog.Eof
strTemp=strTemp&rsCatalog("ID")&
GetAllID(oConn,Catalog("ID")) REM 遞歸調用
Loop
rsCatalog.Close
GetAllID = strTemp
End Function
REM strConn--連接資料庫的字元串，請根據情況修改
set oConn = Server.CreateObject("ADODB.Connection")
oConn.Open strConn
FID = Request.QueryString("FID")
strSQL = "select top 100 * from Proct
where FatherID in ("&GetAllID(oConn,FID)&")"
set rsProct=oConn.Execute(strSQL)
%>
<UL><%
Do while not rsProct.EOF
%>
<LI><%=rsProct("Name")%>
<%
Loop
%>
</UL>
<%rsProct.Close
oConn.Close
%>
這個演算法有很多缺點。試列舉幾個如下：
1、 由於我們需要查詢FID下的所有分類，當分類非常多時，演算法將非常地不經濟，而且，由於要構造一個很大的strSQL，試想如果有1000個分類，這個strSQL將很大，能否執行就是一個問題。
2、 我們知道，在SQL中使用In子句的效率是非常低的。這個演算法不可避免地要使用In子句，效率很低。
我發現80%以上的程序員鍾愛這樣的演算法，並在很多系統中大量地使用。細心的程序員會發現他們寫出了很慢的程序，但苦於找不到原因。他們反復地檢查SQL的執行效率，提高機器的檔次，但效率的增加很少。
最根本的問題就出在這個演算法本身。演算法定了，能夠再優化的機會就不多了。我們下面來介紹一種演算法，效率將是上面演算法的10倍以上。
分類編碼演算法
問題就出在前面我們採用了順序編碼，這是一種最簡單的編碼方法。大家知道，簡單並不意味著效率。實際上，編碼科學是程序員必修的課程。下面，我們通過設計一種編碼演算法，使分類的編號ID中同時包含了其父類的信息。一個五級分類的例子如下：
此例中，用32(4+7+7+7+7)位整數來編碼，其中，第一級分類有4位，可以表達16種分類。第二級到第五級分類分別有7位，可以表達128個子分類。
顯然，如果我們得到一個編碼為 1092787200 的分類，我們就知道：由於其編碼為
0100 0001001 0001010 0111000 0000000
所以它是第四級分類。其父類的二進制編碼是0100 0001001 0001010 0000000 0000000，十進制編號為1092780032。依次我們還可以知道，其父類的父類編碼是0100 0001001 0000000 0000000 0000000，其父類的父類的父類編碼是0100 0000000 0000000 0000000 0000000。
現在我們在一般的情況下來討論類別編碼問題。設類別的層次為k，第i層的編碼位數為Ni， 那麼總的編碼位數為N(N1+N2+..+Nk)。我們就得到任何一個類別的編碼形式如下：
2^(N-(N1+N2+…+Ni))*j + 父類編碼
其中，i表示第i層，j表示當前層的第j個分類。這樣我們就把任何分類的編碼分成了兩個部分，其中一部分是它的層編碼，一部分是它的父類編碼。由下面公式定一的k個編碼我們稱為特徵碼：（因為i可以取k個值，所以有k個）
2^N-2^(N-(N1+N2+…+Ni))
對於任何給定的類別ID，如果我們把ID和k個特徵碼「相與」，得到的非0編碼，就是其所有父類的編碼！
位編碼演算法
對任何順序編碼的Catalog表，我們可以設計一個位編碼演算法，將所有的類別編碼規格化為位編碼。在具體實現時，我們先創建一個臨時表：
Create TempCatalog(
[OldID] [int] NOT NULL,
[NewID] [int] NOT NULL,
[OldFatherID] [int] NOT NULL,
[NewFatherID] [int] NOT NULL
);
在這個表中，我們保留所有原來的類別編號OldID和其父類編號OldFatherID，以及重新計算的滿足位編碼要求的相應編號NewID、NewFatherID。
程序如下：
<%
REM oConn---資料庫連接，已經打開
REM OldFather---原來的父類編號
REM NewFather---新的父類編號
REM N---編碼總位數
REM Ni--每一級的編碼位數數組
REM Level--當前的級數
sub FormatAllID(oConn,OldFather,NewFather,N,Nm,Ni byref,Level)
strSQL = "select CatalogID ,
FatherID from Catalog where FatherID=" & OldFather
set rsCatalog=oConn.Execute( strSQL )
j = 1
do while not rsCatalog.EOF
i = 2 ^(N - Nm) * j
if Level then i= i + NewFather
OldCatalog = rsCatalog("CatalogID")
NewCatalog = i
REM 寫入臨時表:
strSQL = "Insert into TempCatalog (OldCatalogID ,
NewCatalogID , OldFatherID , NewFatherID)"
strSQL = strSQL & " values(" & OldCatalog & " ,
" & NewCatalog & " , " & OldFather & " , " & NewFather & ")"
Conn.Execute strSQL
REM 遞歸調用FormatAllID:
Nm = Nm + Ni(Level+1)
FormatAllID oConn,OldCatalog , NewCatalog ,N,Nm,Ni,Level + 1
rsCatalog.MoveNext
j = j+1
loop
rsCatalog.Close
end sub
%>
調用這個演算法的一個例子如下：
<%
REM 定義編碼參數，其中N為總位數，Ni為每一級的位數。
Dim N,Ni(5)
Ni(1) = 4
N = Ni(1)
for i=2 to 5
Ni(i) = 7
N = N + Ni(i)
next
REM 打開資料庫，創建臨時表:
strSQL = "Create TempCatalog( [OldID]
[int] NOT NULL, [NewID] [int] NOT NULL,
[OldFatherID] [int] NOT NULL, [NewFatherID] [int] NOT NULL);"
Set Conn = Server.CreateObject("ADODB.Connection")
Conn.Open Application("strConn")
Conn.Execute strSQL
REM 調用規格化常式:
FormatAllID Conn,-1,-1,N,Ni(1),Ni,0
REM ---------------------------------------------
REM 在此處更新所有相關表的類別編碼為新的編碼即可。
REM ----------------------------------------------
REM 關閉資料庫:
strSQL= "drop table TempCatalog;"
Conn.Execute strSQL
Conn.Close
%>
第四個問題
現在我們回頭看看第四個問題：怎樣得到某個分類下的所有產品。由於採用了位編碼，現在問題變得很簡單。我們很容易推算：某個產品屬於某個類別的條件是Proct.FatherID&（Catalog.ID的特徵碼）=Catalog.ID。其中「&」代表位與演算法。這在SQL Server中是直接支持的。
舉例來說：產品所屬的類別為：1092787200，而當前類別為1092780032。當前類別對應的特徵值為：4294950912，由於1092787200&4294950912=8537400，所以這個產品屬於分類8537400。
我們前面已經給出了計算特徵碼的公式。特徵碼並不多，而且很容易計算，可以考慮在Global.asa中Application_OnStart時間觸發時計算出來，存放在Application(「Mark」)數組中。
當然，有了特徵碼，我們還可以得到更加有效率的演算法。我們知道，雖然我們採用了位編碼，實際上還是一種順序編碼的方法。表現出第I級的分類編碼肯定比第I+1級分類的編碼要小。根據這個特點，我們還可以由FID得到兩個特徵碼，其中一個是本級位特徵碼FID0，一個是上級位特徵碼FID1。而產品屬於某個分類FID的充分必要條件是：
Proct.FatherID>FID0 and Proct.FatherID<FID1
下面的程序顯示分類FID下的所有產品。由於數據表Proct已經對FatherID進行索引，故查詢速度極快：
<%
REM oConn---資料庫連接，已經打開
REM FID---當前分類
REM FIDMark---特徵值數組，典型的情況下為Application(「Mark」)
REM k---數組元素個數，也是分類的級數
Sub GetAllProct(oConn,FID,FIDMark byref,k)
' 根據FID計算出特徵值FID0,FID1
for i=k to 1
if (FID and FIDMark = FID ) then exit
next
strSQL = "select Name from Proct where FatherID>
"FIDMark(i)&" and FatherID<"FIDMark(i-1)
set rsProct=oConn.Execute(strSQL)%>
<UL><%
Do While Not rsProct.Eof%>
<LI><%=rsProct("Name")
Loop%>
</UL><%
rsProct.Close
End Sub
%>
關於第5個問題、第6個問題，就留作習題吧。有了上面的位編碼，一切都應該迎刃而解。