㈠ 資料庫課程設計實例
資料庫課程設計
題目：小型超市管理系統
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、小結
和傳統管理模式相比較，使用本系統，毫無疑問會大大提高超市的運作效率，輔助提高超市的決策水平，管理水平，為降低經營成本， 提高效益，減少差錯，節省人力，減少顧客購物時間，增加客流量，提高顧客滿意度，增強超市擴張能力， 提供有效的技術保障。
由於開發者能力有限，加上時間倉促，本系統難免會出現一些不足之處，例如：
本系統只適合小型超市使用，不能適合中大型超市使用；
超市管理系統涉及范圍寬，要解決的問題多，功能復雜，實現困難，但由於限於時間，本系統只能做出其中的一部分功能；
對於以上出現的問題，我們深表歉意，如發現還有其它問題，希望老師批評指正。
請採納。
㈡ 資料庫索引的操作案例
最普通的情況，是為出現在where子句的欄位建一個索引。為方便講述，先建立一個如下的表。
CREATE TABLE mytable(
idserial primary key,
category_id int not null default0,
user_id int not null default0,
adddate int not null default0
);
如果在查詢時常用類似以下的語句：
SELECT * FROM mytable WHERE category_id=1;
最直接的應對之道，是為category_id建立一個簡單的索引：
CREATE INDEX mytable_categoryid ON mytable (category_id);
OK.如果有不止一個選擇條件呢？例如：
SELECT * FROM mytable WHERE category_id=1 AND user_id=2;
第一反應可能是，再給user_id建立一個索引。不好，這不是一個最佳的方法。可以建立多重的索引。
CREATE INDEX mytable_categoryid_userid ON mytable(category_id,user_id);
注意到在命名時的習慣了嗎？使用表名_欄位1名_欄位2名的方式。很快就會知道為什麼這樣做了。
現在已經為適當的欄位建立了索引，不過，還是有點不放心吧，可能會問，資料庫會真正用到這些索引嗎？測試一下就OK，對於大多數的資料庫來說，這是很容易的，只要使用EXPLAIN命令：
EXPLAIN
SELECT * FROM mytable
WHERE category_id=1 AND user_id=2;
This is what Postgres 7.1 returns (exactlyasI expected)
NOTICE:QUERY PLAN:
Index Scan using mytable_categoryid_userid on
mytable(cost=0.00..2.02 rows=1 width=16)
EXPLAIN
以上是postgres的數據，可以看到該資料庫在查詢的時候使用了一個索引（一個好開始），而且它使用的是創建的第二個索引。看到上面命名的好處了吧，馬上知道它使用適當的索引了。
接著，來個稍微復雜一點的，如果有個ORDERBY 子句呢？不管你信不信，大多數的資料庫在使用orderby的時候，都將會從索引中受益。
SELECT * FROM mytable
WHERE category_id=1 AND user_id=2
ORDER BY adddate DESC;
很簡單，就像為where子句中的欄位建立一個索引一樣，也為ORDER BY的子句中的欄位建立一個索引：
CREATE INDEX mytable_categoryid_userid_adddate ON mytable (category_id,user_id,adddate);
注意:mytable_categoryid_userid_adddate將會被截短為mytable_categoryid_userid_addda
CREATE
EXPLAIN SELECT * FROM mytable
WHERE category_id=1 AND user_id=2
ORDER BY adddate DESC;
NOTICE:QUERY PLAN:
Sort(cost=2.03..2.03 rows=1 width=16)
->Index Scanusing mytable_categoryid_userid_addda
on mytable(cost=0.00..2.02 rows=1 width=16)
EXPLAIN
看看EXPLAIN的輸出，資料庫多做了一個沒有要求的排序，這下知道性能如何受損了吧，看來對於資料庫的自身運作是有點過於樂觀了，那麼，給資料庫多一點提示吧。
為了跳過排序這一步，並不需要其它另外的索引，只要將查詢語句稍微改一下。這里用的是postgres，將給該資料庫一個額外的提示--在ORDER BY語句中，加入where語句中的欄位。這只是一個技術上的處理，並不是必須的，因為實際上在另外兩個欄位上，並不會有任何的排序操作，不過如果加入，postgres將會知道哪些是它應該做的。
EXPLAIN SELECT * FROM mytable
WHERE category_id=1 AND user_id=2
ORDER BY category_id DESC,user_id DESC,adddate DESC;
NOTICE:QUERY PLAN:
Index Scan Backward using
mytable_categoryid_userid_addda on mytable(cost=0.00..2.02 rows=1 width=16)
EXPLAIN
現在使用料想的索引了，而且它還挺聰明，知道可以從索引後面開始讀，從而避免了任何的排序。
以上說得細了一點，不過如果資料庫非常巨大，並且每日的頁面請求達上百萬算，想會獲益良多的。不過，如果要做更為復雜的查詢呢，例如將多張表結合起來查詢，特別是where限制字句中的欄位是來自不止一個表格時，應該怎樣處理呢？通常都盡量避免這種做法，因為這樣資料庫要將各個表中的東西都結合起來，然後再排除那些不合適的行，搞不好開銷會很大。
如果不能避免，應該查看每張要結合起來的表，並且使用以上的策略來建立索引，然後再用EXPLAIN命令驗證一下是否使用了料想中的索引。如果是的話，就OK。不是的話，可能要建立臨時的表來將他們結合在一起，並且使用適當的索引。
要注意的是，建立太多的索引將會影響更新和插入的速度，因為它需要同樣更新每個索引文件。對於一個經常需要更新和插入的表格，就沒有必要為一個很少使用的where字句單獨建立索引了，對於比較小的表，排序的開銷不會很大，也沒有必要建立另外的索引。
以上介紹的只是一些十分基本的東西，其實裡面的學問也不少，單憑EXPLAIN是不能判定該方法是否就是最優化的，每個資料庫都有自己的一些優化器，雖然可能還不太完善，但是它們都會在查詢時對比過哪種方式較快，在某些情況下，建立索引的話也未必會快，例如索引放在一個不連續的存儲空間時，這會增加讀磁碟的負擔，因此，哪個是最優，應該通過實際的使用環境來檢驗。
在剛開始的時候，如果表不大，沒有必要作索引，意見是在需要的時候才作索引，也可用一些命令來優化表，例如MySQL可用OPTIMIZETABLE。
㈢ 資料庫設計案例分析
加到200分吧，我幫你
㈣ [高等院校校園一卡通系統資料庫設計概要]完整的資料庫設計案例
摘 要以懷化職業技術學院為對象,結合學習借鑒先進國家院校的數字校園集成的豐富經驗,概括了適合本院的「一卡通」資料庫的設計。 關鍵詞一卡通;資料庫;設計 中圖分類號TP3 文獻標識碼A文章編號1673-9671-(2010)041-0016-01
1資料庫系統架構
「校園一卡通」系統的網路結構分為兩層。第一層為以資料庫伺服器為中心的區域網的分布式結構。第二層為以第一層區域網的網路工作站作為控制主機的485通訊網路結構,該層網路控制各個IC卡收費終端。我們將以SQLSERVER2000為平台建立資料庫,有利於保證數據安全,有良好的擴展功能,而且可支持多種應用程序語言如VB、VC和Delphi等高級語言。
1.1資料庫系統設計
資料庫是一種存儲數據並對數據進行操作的工具。資料庫的作用在於組織和表達信息,簡而言之,資料庫就是信息的集合。計算機的資料庫可以分為兩類:非關系資料庫(flat-file)和關系資料庫(relational)。關系資料庫中包含了多個數據表的信息,資料庫含有各個不同部分的術語,象記錄、域等。
1.2系統功能分析
根據各個功能的子系統模塊設置和分析,認為以下的模塊設計圖(圖1)適合我院的基本需求。校園內已經完全具備了基礎的計算機硬體條件,許多設備只需做升級或改動就可,隨著需求的增加,可以在此基礎上擴充介面,十分方便。
1.3系統功能模塊的設計
對各項功能進行集中、分塊,按照結構化程序設計的要求,分析得到系統功能模塊圖(圖2)。
1.4資料庫設計
設計資料庫系統時應該首先了解用戶(師生)各方面的需求,包括現有的以及將姿胡悄來可能增加的需求。作為「校園一卡通」系統會隨著硬體安裝場所的變動做改動,需要很大的擴展性。用戶的需求具體體現在各種信息的提供、保存、更新和查詢,這就要求資料庫結構能充分滿足各種信息的輸入輸出。收集基本數據、數據結構以及數據處理的流程,組成一份詳盡的數據字典。有了資料庫結構、數據項和數據流程,我們就可以進行下面的資料庫設計。得到數據項和數據結構以後,就可以設計出用戶需求的各種實體,以及它們之間的關系,為後面的邏輯結構設計打下基礎。實體是通過相互的作用形成數據的流動。現在需要將現行相關的資料庫概念結構化轉化為SQL Server2000資料庫系統所支持的實際數據模型,也就是資料庫的邏輯結構。在上面的實體以及實體之間關系的基礎上,形成資料庫中的表格以及各個表格之間的關系。
經過前面的需求分析和概念結構設計以後,得到資料庫的邏輯結構。現在就可以在SQLserver2000資料庫系統中實現該邏輯結構.這就是利用sqlserver2000資料庫系統中的sql查詢分析器實現的。
2資料庫的配置
「校園一卡通」需要眾多的數據,如學生信息數據、教師信息數據、消費數據等等。在此我們是以sqlserver2000作為資料庫平台的。
2.1客戶端程序實現
客戶端以高級語言開發,運行於區域網中的各個客戶機上,提供用戶登錄、各據的輸入與維護、查詢列印、提示等功能。客戶端軟體做毀以相應的數據組件通過TCP/IP協議訪問伺服器數據。任何用戶只跡渣要擁有給定的許可權都可以通過網路操縱和查詢伺服器數據。
當SQL語句在查詢分析器執行後,將自動產生需要的所有表格。有關資料庫結構的所有後台工作已經完成。現在將通過相關的信息管理系統中各功能模塊的實現,使用高級語言來編寫資料庫系統的客戶端程序。
2.2資料庫的配置管理
採用流行的SQLServer2000+Windows2003server的資料庫伺服器配置,系統數據及邏輯駐留在SQLServer資料庫中,SQLServer2000以伺服器的形式運行於Windows2003server之上,無用戶界面,集中存儲與管理系統數據。各客戶端可使用windowsXP以上系統建立。SQLServer2000具有很好的安全性,可設定訪問許可權,數據得導入導出極為方便。我們將使用SQL Server2000管理資料庫。這里將以一個管理員(DBA)的身份來闡述資料庫管理任務。除了檢查伺服器配置和備份資料庫以外,作為DBA,還要執行很多其他任務。必須保證伺服器平穩運行和資料庫是快而有效的。
SQL Server2000有很好的安全性模型,這使我們能夠定義各種安全措施,包括從限制級資料庫的訪問許可權到限制對表中某一列的訪問。在SQL Server2000中可以可以限制客戶端用戶的基本許可權,也可以設置系統管理員的最高許可權。
在校園一卡通系統中需要對各個用戶設置許可權。在資料庫中定義的每一個用戶都屬於Public角色。Public角色除了具有允許用戶連接資料庫的許可權外幾乎沒有其他許可權。
在日常的資料庫運行中,我們需要按時的盡心資料庫的備份,保存數據的安全和完整性,這些工作SQL Server2000都提供了方便。除此以外,可以利用SQL Server2000的許多工具進行管理,十分便利,詳細步驟可以參照多種介紹SQL Server2000的書籍資料。
參考文獻
[1]王珊,陳紅.資料庫系統原理教程[M].北京:清華大學出版社,2000,7.
[2]Rob Hawthorne,袁鵬飛編譯.SQL SERVER 2000資料庫開發從零開始[M].北京:人民郵電出版社.2001,6.
[3]譚開文,孫京寧.對目前中國IC卡行業現狀以及發展的幾個看法[J]..計算機系統應用,2003,4:72-74.
本文為全文原貌 未安裝PDF瀏覽器用戶請先下載安裝 原版全文
㈤ 資料庫表結構設計，常見的資料庫管理系統
一、數據場景 1、表結構簡介 任何工具類的東西都是為了解決某個場景下的問題，比如Redis緩存系統熱點數據，ClickHouse解決海量數據的實時分析，MySQL關系型資料庫存儲結構化數據。數據的存儲則需要設計對應的表結構，清楚的表結構，有助於快速開發業務，和理解系統。表結構的設計通常從下面幾個方面考慮：業務場景、設計規范、表結構、欄位屬性、數據管理。
2、用戶場景
例如存儲用戶基礎信息數據，通常都會下面幾個相關表結構：用戶信息表、單點登錄表、狀態管理表、支付賬戶表等。
用戶信息表
存儲用戶三要素相關信息：姓名，手機號，身份證，登錄密碼，郵箱等。
CREATE TABLE `ms_user_center` ( `id` int(11) NOT NULL AUTO_INCREMENT COMMENT '用戶ID', `user_name` varchar(20) NOT NULL COMMENT '用戶名', `real_name` varchar(20) DEFAULT NULL COMMENT '真實姓名', `pass_word` varchar(32) NOT NULL COMMENT '密碼', `phone` varchar(20) NOT NULL COMMENT '手機號', `email` varchar(32) DEFAULT NULL COMMENT '郵箱', `head_url` varchar(100) DEFAULT NULL COMMENT '用戶頭像URL', `card_id` varchar(32) DEFAULT NULL COMMENT '身份證號', `user_sex` int(1) DEFAULT '1' COMMENT '用戶性別:0-女,1-男', `create_time` datetime DEFAULT NULL COMMENT '創建時間', `update_time` datetime DEFAULT NULL COMMENT '更新時間', `state` int(1) DEFAULT '1' COMMENT '是否可用,0-不可用,1-可用', PRIMARY KEY (`id`) ) ENGINE=InnoDB DEFAULT CHARSET=utf8 COMMENT='用戶表'; 單點登錄表
用意是在多個業務系統中，用戶登錄一次就可以訪問所有相互信任的業務子系統，是聚合業務平台常用的解決方案。
CREATE TABLE `ms_user_sso` ( `user_id` int(11) NOT NULL COMMENT '用戶ID', `sso_id` varchar(32) NOT NULL COMMENT '單點信息編號ID', `sso_code` varchar(32) NOT NULL COMMENT '單點登錄碼,唯一核心標識', `log_ip` varchar(32) DEFAULT NULL COMMENT '登錄IP地址', `create_time` datetime DEFAULT NULL COMMENT '創建時間', `update_time` datetime DEFAULT NULL COMMENT '更新時間', `state` int(1) DEFAULT '1' COMMENT '是否可用,0-不可用,1-可用', PRIMARY KEY (`user_id`) ) ENGINE=InnoDB DEFAULT CHARSET=utf8 COMMENT='用戶單點登錄表'; 狀態管理表
系統用戶在使用時候可能出現多個狀態，例如賬戶凍結、密碼鎖定等，把狀態聚合到一起，可以更加方便的管理和驗證。
CREATE TABLE `ms_user_status` ( `user_id` int(11) NOT NULL COMMENT '用戶ID', `account_status` int(1) DEFAULT '1' COMMENT '賬戶狀態：0-凍結,1-未凍結', `real_name_status` int(1) DEFAULT '0' COMMENT '實名認證狀態：0-未實名,1-已實名', `pay_pass_status` int(1) DEFAULT '0' COMMENT '支付密碼是否設置：0-未設置,1-設置', `wallet_pass_status` int(1) DEFAULT '0' COMMENT '錢包密碼是否設置：0-未設置,1-設置', `wallet_status` int(1) DEFAULT '1' COMMENT '錢包是否凍結:0-凍結,1-未凍結', `email_status` int(1) DEFAULT '0' COMMENT '郵箱狀態:0-未激活,1-激活', `message_status` int(1) DEFAULT '1' COMMENT '簡訊提醒開啟：0-未開啟,1-開啟', `letter_status` int(1) DEFAULT '1' COMMENT '站內信提醒開啟：0-未開啟,1-開啟', `emailmsg_status` int(1) DEFAULT '0' COMMENT '郵件提醒開啟：0-未開啟,1-開啟', `create_time` datetime DEFAULT NULL COMMENT '創建時間', `update_time` datetime DEFAULT NULL COMMENT '更新時間', `state` int(1) DEFAULT '1' COMMENT '是否可用,0-不可用,1-可用', PRIMARY KEY (`user_id`) ) ENGINE=InnoDB DEFAULT CHARSET=utf8 COMMENT='用戶狀態表'; 支付賬戶表
用戶交易的核心表，存儲用戶相關的賬戶資金信息。
CREATE TABLE `ms_user_wallet` ( `wallet_id` int(11) NOT NULL AUTO_INCREMENT COMMENT '錢包ID', `user_id` int(11) NOT NULL COMMENT '用戶ID', `wallet_pwd` varchar(32) DEFAULT NULL COMMENT '錢包密碼', `total_account` decimal(20,2) DEFAULT '0.00' COMMENT '賬戶總額', `usable_money` decimal(20,2) DEFAULT '0.00' COMMENT '可用余額', `freeze_money` decimal(20,2) DEFAULT '0.00' COMMENT '凍結金額', `freeze_time` datetime DEFAULT NULL COMMENT '凍結時間', `thaw_time` datetime DEFAULT NULL COMMENT '解凍時間', `create_time` datetime DEFAULT NULL COMMENT '創建時間', `update_time` datetime DEFAULT NULL COMMENT '更新時間', `state` int(1) DEFAULT '1' COMMENT '是否可用,0-不可用,1-可用', PRIMARY KEY (`wallet_id`) ) ENGINE=InnoDB DEFAULT CHARSET=utf8 COMMENT='用戶錢包'; 二、設計規范 1、涉及模塊
通過上面幾個表設計的案例，可以看到表設計關聯到資料庫的各個方面知識：數據類型，索引，編碼，存儲引擎等。表設計是一個很大的命題，不過也遵循一個基本規范：三範式。
2、三範式 基礎概念
一範式
表的列的具有原子性,不可再分解，即列的信息，不能分解,關系型資料庫MySQL、Oracle等自動的滿足。
二範式
每個事實的數據記錄只會出現一次, 不會冗餘, 通常設計一個主鍵來實現。
三範式
要求一個表中不包含已經存在於其它表的非主鍵信息，例如部門和員工的信息，員工表包含部門表的主鍵ID，則可以關聯獲取相關信息，沒必要在員工表保存相關信息。
優缺點對比
範式化設計
範式化結構設計通常更新快，因為冗餘數據較少，表結構輕巧，也更好的寫入內存中。但是查詢起來涉及到關聯，代價非常高，非常損耗查詢性能。
反範式化設計
所有的數據都在一張表中，避免關聯查詢，索引的有效性更高，但是數據的冗餘性極高。
建議結論
上述的兩種設計方式在實際開發中都是不存在的，在實際開發中都是混合使用。比如匯總統計，緩存數據，都會基於反範式化的設計。
三、欄位屬性
合適的欄位類型對於高性能來說非常重要，基本原則如下：簡單的類型佔用資源更少；在可以正確存儲數據的情況下，選最小的數據類型。
1、數據類型選擇 整數類型
TINYINT、SMALLINT、MEDIUMINT、INT、BIGINT，根據數據類型範圍合理選擇即可。
實數類型
FLOAT、DOUBLE、DECIMAL，建議資金貨幣相關類型使用高精度DECIMAL存儲，或者把數據成倍擴大為整數，採用BIGINT存儲，不過處理相對麻煩。
字元類型
CHAR、VARCHAR，長度不確定建議採用VARCHAR存儲，不過VARCHAR類型需要額外開銷記錄字元串長度。CHAR適合存儲短字元，或者定長字元串，例如MD5的加密結構。
時間類型
DATETIME、TIMESTAMP，DATETIME保存大范圍的值，精度秒。TIMESTAMP以時間戳的格式，范圍相對較小，效率也相對較高，所以通常情況建議使用。
MySQL的欄位類型有很多種，可以根據數據特性選擇合適的，這里只描述常見的幾種類型。
2、基礎用法操作 數據類型
修改欄位類型
ALTER TABLE ms_user_sso MODIFY state CHAR(1) DEFAULT '0' ; ALTER TABLE ms_user_sso MODIFY state INT(1) DEFAULT '1' COMMENT '狀態：0不可用,1可用';
修改名稱位置
ALTER TABLE ms_user_sso CHANGE log_ip login_ip VARCHAR(32) AFTER update_time ; 索引使用
索引類型：主鍵索引，普通索引，唯一索引，組合索引，全文索引。這里演示普通索引的操作。MySQL的核心模塊，後續詳說。
添加索引
ALTER TABLE ms_user_wallet ADD INDEX user_id_index(user_id) ; CREATE INDEX state_index ON ms_user_wallet(state) ;
查看索引
SHOW INDEX FROM ms_user_wallet;
刪除索引
DROP INDEX state_index ON ms_user_wallet ;
修改索引
不具有真正意義上的修改，可以把原有的索引刪除之後，再次添加索引。
外鍵關聯
用處：外鍵關聯的作用保證多個數據表的數據一致性和完整性，建表時先有主表，後有從表；刪除數據表，需要先刪從表，再刪主表。復雜場景不建議使用，實際開發中用的也不多。
添加外鍵
ALTER TABLE ms_user_wallet ADD CONSTRAINT user_id_out_key FOREIGN KEY(user_id) REFERENCES ms_user_center(id) ;
刪除外鍵
ALTER TABLE ms_user_wallet DROP FOREIGN KEY user_id_out_key ; 四、表結構管理 1、查看結構 DESC ms_user_status ; SHOW CREATE TABLE ms_user_status ; 2、欄位結構 添加欄位 ALTER TABLE ms_user_status ADD `delete_time` datetime DEFAULT NULL COMMENT '刪除時間' ; 刪除欄位 ALTER TABLE ms_user_status DROP COLUMN delete_time ; 3、修改表名 ALTER TABLE ms_user_center RENAME ms_user_info ; 4、存儲引擎 存儲引擎 SELECT VERSION() ; SHOW ENGINES ;
MySQL 5.6 支持的存儲引擎有InnoDB、MyISAM、Memory、Archive、CSV、BLACKHOLE等。一般默認使用InnoDB，支持事務管理。該模塊MySQL核心，後續詳解。
修改引擎
數據量大的場景下，存儲引擎修改是一個難度極大的操作，容易會導致表的特性變動，引起各種後續反應，後續會詳說。
ALTER TABLE ms_user_sso ENGINE = MyISAM ; 5、修改編碼
表字元集默認使用utf8，通用，無亂碼風險，漢字3位元組，英文1位元組，utf8mb4是utf8的超集，有存儲4位元組例如表情符號時使用。
查看編碼 SHOW VARIABLES LIKE 'character%'; 修改編碼 ALTER TABLE ms_user_sso DEFAULT CHARACTER SET utf8mb4; 五、數據管理 1、增刪改查
添加數據
INSERT INTO ms_user_sso ( user_id,sso_id,sso_code,create_time,update_time,login_ip,state ) VALUES ( '1','SSO7637267','SSO78631273612', '2019-12-24 11:56:57','2019-12-24 11:57:01','127.0.0.1','1' );
更新數據
UPDATE ms_user_sso SET user_id = '1',sso_id = 'SSO20191224',sso_code = 'SSO20191224', create_time = '2019-11-24 11:56:57',update_time = '2019-11-24 11:57:01', login_ip = '127.0.0.1',state = '1' WHERE user_id = '1';
查詢數據
一般情況下都是禁止使用 select* 操作。
SELECT user_id,sso_id,sso_code,create_time,update_time,login_ip,state FROM ms_user_sso WHERE user_id = '1';
刪除數據
DELETE FROM ms_user_sso WHERE user_id = '2' ;
不帶where條件，就是刪除全部數據。原則上不允許該操作，優化篇會詳解。TRUNCATE TABLE也是清空表數據，但是佔用的資源相對較少。
2、數據安全 不可逆加密
這類加密演算法，多用來做數據驗證操作，比如常見的密碼驗證。
SELECT MD5('cicada')='' ; SELECT SHA('cicada')=''; SELECT PASSWORD('smile')='*' ; 可逆加密
安全性要求高的系統，需要做三級等保，對數據的安全性極高，數據在存儲時必須加密入庫，取出時候需要解密，這些就需要可逆加密。
SELECT DECODE(ENCODE('123456','key_salt'),'key_salt') ; SELECT AES_DECRYPT(AES_ENCRYPT('cicada','salt123'),'salt123');
上述數據安全的管理，也可以基於應用系統的服務(代碼)層進行處理，相對專業的流程是從數據生成源頭處理，規避數據傳遞過程泄露，造成不必要的風險。
㈥ 如何進行文章分類和標簽的資料庫設計
幾乎在所有web項目中，都涉及文章分類和標簽的設計，應該說這是一個比較常見、典型的案例
站長並不保證我的思路就是最好的，只是分享出來大家一起交流一下，互相促進與提高
我們假設的開發項目是一個博客系統，最核心的部分就是與文章相關的，那麼我們今天討論如何設計博客系統的文章分類和標簽
1、首先，分類和標簽都是要和具體的文章相關聯的，當然也可能一些文章既沒有分類也沒有標簽，這一點是大家在寫查詢的時候容易疏忽的地方
因為我們的第一感覺就是，在查詢文章列表的時候關聯分類表，查出所有的文章和分類，對應關系一般是文章表的分類id對應分類表的id，使用where子句進行限定
這里就存在一個問題了，由於使用了where子句，那麼只能查詢有分類的文章，而沒有分類的文章就查詢不到了
這時候怎麼辦？應該使用連接查詢，leftjoin，這要沒有分類的文章，在文章分類id那一欄會顯示null
通常我們只使用leftjoin，而很少使用rightjoin
2、一般，一篇文章最好只對應一個分類，當然如果你想要對應多個分類也可以
但站長並不提倡，文章在多個分類中重復會給人很不專業的感覺，即使有些文章可能確實設計到多方面的內容，那麼你應就其中的側重點來分類
而標簽就不一樣了，一篇文章可能有多個標簽
這就意味著我們無法靠一個sql語句既查出所有文章的分類和標簽，又做到查詢結果中的文章id不重復
通常我們需要把查詢出來的結果直接循環出來，那麼這個結果一般是二維數組，第二維的都存儲了唯一一篇文章的相關信息
但是，標簽和文章是多對一的關系，多個標簽對應一篇文章，如果你只用一條sql語句的話，那麼我們查詢出來的結果，當然也是多行，這不符合我們目標數據的要求
應此，需要在查詢完文章和分類之後，在前面結果的基礎上再查詢一次文章標簽，把兩次的結果結合起來，存在數組中，這是對應文章列表頁面的查詢方法
對於具體文章頁面，可以分兩次查詢
好了，還沒有給出具體的資料庫設計，就先說了如何查詢結果，相信大家也看煩了，下面就舉例說明：一、文章表：post，欄位如下：id【唯一標識】，aid【作者id】，title【標題】,content【內容】，cid【分類id】二、分類表，category，欄位如下：id【唯一標識，與post表的cid關聯】,name【分類名】三、標簽表，tag，欄位如下：id【唯一標識】，name【標簽名】四、標簽與文章對應關系表，tag_，欄位如下：id【唯一標識】，postid【文章id，與post表的id關聯】，tagid【標簽id，tag表的id關聯】有朋友可能會問：為什麼要單獨用一個表來存儲文章與標簽圓伍睜的對應關系，為什麼不可以直接在tag表中增加一個文章id欄位呢，比如：tag表：id，postid，name這樣做的話，並不是不可以，但是，由於一篇文章對應多個標簽，所以name欄位的值橘陪會出現很多重復，比如一篇文章，假設文章id為1，有2個標簽，php和mysql，那麼在tag表會這樣存儲：id:1,postid:1,name:phpid2,postid:1,name:mysql另一篇文章，假設id為2，有2個標簽，也是php和mysql，那麼在tag表中它會這樣存儲：id:3,postid:2,name:phpid4,postid:2,name:mysql大家很快就發現了問題，這樣的設計name欄位也就是標簽的名稱在同一張表中可能會大量橘歲重復
但是這樣設計的好處是，如果你要查詢一個標簽下有多少篇文章，只要單獨查這個表就可以了，比如要查詢含有php標簽的文章有多少篇，只需要selectcount(name)??fromtagwherename=』php』,就可以查出來
不好的地方是，如果要查詢所有標簽的集合，使用這種設計需要使用groupbyname語句來去除重復的行
如果用之前的那種，只需要select*fromtag就可以了
一時之間，好像不太好取捨
這兩種設計都會有數據冢余，第一種tag_表中，存在tagid欄位的重復；而這兩種設計又都有各自的好處
那麼我們到底該怎麼選擇呢？站長也說不好，所以無法為大家下結論
但是站長在研究wordpress數據結構的時候，發現wp是採用的單獨建表存儲文章與標簽對應關系的方式
㈦ 資料庫具體應用的實例有哪些
資料庫的應用領域
1、多媒體資料庫： 這類資料庫主要存儲與多媒體相關的數據，如聲音、圖像和視頻等數據。多媒體數據最大的特點是數據連續，而且數據量比較大，存儲需要的空間較大。
2、移動資料庫： 該類資料庫是在移動計算機系統上發展起來的，如筆記本電腦、掌上計算機等。該資料庫最大的特點是通過無線數字通信網路傳輸的。移動資料庫可以隨時隨地地獲取和訪問數據，為一些商務應用和一些緊急情況帶來了很大的便利。
3、空間資料庫： 這類資料庫目前發展比較迅速。它主要包括地理信息資料庫（又稱為地理信息系統，即GIS）和計算機輔助設計（CAD）資料庫。其中地理信息資料庫一般存儲與地圖相關的信息數據；計算機輔助設計資料庫一般存儲設計信息的空間資料庫，如機械、集成電路以及電子設備設計圖等。
4、信息檢索系統： 信息檢索就是根據用戶輸入的信息，從資料庫中查找相關的文檔或信息，並把查找的信息反饋給用戶。信息檢索領域和資料庫是同步發展的，它是一種典型的聯機文檔管理系統或者聯機圖書目錄。
5、分布式信息檢索： 這類資料庫是隨著Internet的發展而產生的資料庫。它一般用於網際網路及遠距離計算機網路系統中。特別是隨著電子商務的發展，這類資料庫發展更加迅猛。
許多網路用戶（如個人、公司或企業等）在自己的計算機中存儲信息，同時希望通過網路使用發送電子郵件、文件傳輸、遠程登錄方式和別人共享這些信息。分布式信息檢索滿足了這一要求。
6、專家決策系統： 專家決策系統也是資料庫應用的一部分。由於越來越多的數據可以聯機獲取，特別是企業通過這些數據可以對企業的發展作出更好的決策，以使企業更好地運行。由於人工智慧的發展，使得專家決策系統的應用更加廣泛。
(7)資料庫表設計案例擴展閱讀
對資料庫系統的基本要求是：
①能夠保證數據的獨立性。數據和程序相互獨立有利於加快軟體開發速度，節省開發費用。
②冗餘數據少，數據共享程度高。
③系統的用戶介面簡單，用戶容易掌握，使用方便。
④能夠確保系統運行可靠，出現故障時能迅速排除；能夠保護數據不受非受權者訪問或破壞；能夠防止錯誤數據的產生，一旦產生也能及時發現。
⑤有重新組織數據的能力，能改變數據的存儲結構或數據存儲位置，以適應用戶操作特性的變化，改善由於頻繁插入、刪除操作造成的數據組織零亂和時空性能變壞的狀況。
⑥具有可修改性和可擴充性。
⑦能夠充分描述數據間的內在聯系。
㈧ 有沒有利用python開發資料庫的案例
在Windows平台上安裝mysql模塊用於Python開發
用python連接mysql的時候，需要用的安裝版本，源碼版本容易有錯誤提示。下邊是打包了32與64版本。
MySQL-python-1.2.3.win32-py2.7.exe
MySQL-python-1.2.3.win-amd64-py2.7.exe
實例 1、取得 MYSQL 的版本
# -*- coding: UTF-8 -*-
#安裝 MYSQL DB for python
import MySQLdb as mdb
con = None
try:
#連接 mysql 的方法： connect('ip','user','password','dbname')
con = mdb.connect('localhost', 'root','root', 'test');
#所有的查詢，都在連接 con 的一個模塊 cursor 上面運行的
cur = con.cursor()
#執行一個查詢
cur.execute("SELECT VERSION()")
#取得上個查詢的結果，是單個結果
data = cur.fetchone()
print "Database version : %s " % data
finally:
if con:
#無論如何，連接記得關閉
con.close()
實例 2、創建一個表並且插入數據
import MySQLdb as mdb
import sys
#將 con 設定為全局連接
con = mdb.connect('localhost', 'root', 'root', 'test');
with con:
#獲取連接的 cursor，只有獲取了 cursor，我們才能進行各種操作
cur = con.cursor()
#創建一個數據表 writers(id,name)
cur.execute("CREATE TABLE IF NOT EXISTS
Writers(Id INT PRIMARY KEY AUTO_INCREMENT, Name VARCHAR(25))")
#以下插入了 5 條數據
cur.execute("INSERT INTO Writers(Name) VALUES('Jack London')")
cur.execute("INSERT INTO Writers(Name) VALUES('Honore de Balzac')")
cur.execute("INSERT INTO Writers(Name) VALUES('Lion Feuchtwanger')")
cur.execute("INSERT INTO Writers(Name) VALUES('Emile Zola')")
cur.execute("INSERT INTO Writers(Name) VALUES('Truman Capote')")
實例 3、 python 使用 slect 獲取 mysql 的數據並遍歷
import MySQLdb as mdb
import sys
#連接 mysql，獲取連接的對象
con = mdb.connect('localhost', 'root', 'root', 'test');
with con:
#仍然是，第一步要獲取連接的 cursor 對象，用於執行查詢
cur = con.cursor()
#類似於其他語言的 query 函數， execute 是 python 中的執行查詢函數
cur.execute("SELECT * FROM Writers")
#使用 fetchall 函數，將結果集（多維元組）存入 rows 裡面
rows = cur.fetchall()
#依次遍歷結果集，發現每個元素，就是表中的一條記錄，用一個元組來顯示
for row in rows:
print row
運行結果：
(1L, 『Jack London')
(2L, 『Honore de Balzac')
(3L, 『Lion Feuchtwanger')
(4L, 『Emile Zola')
(5L, 『Truman Capote')
上面的代碼，用來將所有的結果取出，不過列印的時候是每行一個元祖列印，現在我們使用方法，取出其中的單個數據：
import MySQLdb as mdb
import sys
#獲取 mysql 的鏈接對象
con = mdb.connect('localhost', 'root', 'root', 'test');
with con:
#獲取執行查詢的對象
cur = con.cursor()
#執行那個查詢，這里用的是 select 語句
cur.execute("SELECT * FROM Writers")
#使用 cur.rowcount 獲取結果集的條數
numrows = int(cur.rowcount)
#循環 numrows 次，每次取出一行數據
for i in range(numrows):
#每次取出一行，放到 row 中，這是一個元組(id,name)
row = cur.fetchone()
#直接輸出兩個元素
print row[0], row[1]
運行結果：
1 Jack London
2 Honore de Balzac
3 Lion Feuchtwanger
4 Emile Zola
5 Truman Capote
實例 4、使用字典 cursor 取得結果集（可以使用表欄位名字訪問值）
import MySQLdb as mdb
import sys
#獲得 mysql 查詢的鏈接對象
con = mdb.connect('localhost', 'root', 'root', 'test')
with con:
#獲取連接上的字典 cursor，注意獲取的方法，
#每一個 cursor 其實都是 cursor 的子類
cur = con.cursor(mdb.cursors.DictCursor)
#執行語句不變
cur.execute("SELECT * FROM Writers")
#獲取數據方法不變
rows = cur.fetchall()
#遍歷數據也不變（比上一個更直接一點）
for row in rows:
#這里，可以使用鍵值對的方法，由鍵名字來獲取數據
print "%s %s" % (row["Id"], row["Name"])
實例 5、獲取單個表的欄位名和信息的方法
import MySQLdb as mdb
import sys
#獲取資料庫的鏈接對象
con = mdb.connect('localhost', 'root', 'root', 'test')
with con:
#獲取普通的查詢 cursor
cur = con.cursor()
cur.execute("SELECT * FROM Writers")
rows = cur.fetchall()
#獲取連接對象的描述信息
desc = cur.description
print 'cur.description:',desc
#列印表頭，就是欄位名字
print "%s %3s" % (desc[0][0], desc[1][0])
for row in rows:
#列印結果
print "%2s %3s" % row
運行結果：
cur.description: ((『Id', 3, 1, 11, 11, 0, 0), (『Name', 253, 17, 25, 25, 0, 1))
Id Name
1 Jack London
2 Honore de Balzac
3 Lion Feuchtwanger
4 Emile Zola
5 Truman Capote
實例 6、使用 Prepared statements 執行查詢（更安全方便）
import MySQLdb as mdb
import sys
con = mdb.connect('localhost', 'root', 'root', 'test')
with con:
cur = con.cursor()
#我們看到，這里可以通過寫一個可以組裝的 sql 語句來進行
cur.execute("UPDATE Writers SET Name = %s WHERE Id = %s",
("Guy de Maupasant", "4"))
#使用 cur.rowcount 獲取影響了多少行
print "Number of rows updated: %d" % cur.rowcount
結果：
Number of rows updated: 1
實例 7、把圖片用二進制存入 MYSQL
有人喜歡把圖片存入 MYSQL（這種做法貌似很少吧），我看大部分的程序，圖片都是存放在伺服器上的文件，資料庫中存的只是圖片的地址而已，不過 MYSQL 是支持把圖片存入資料庫的，也相應的有一個專門的欄位 BLOB (Binary Large Object)，即較大的二進制對象欄位，請看如下程序，注意測試圖片自己隨便找一個，地址要正確：
首先，在資料庫中創建一個表，用於存放圖片：
復制代碼代碼如下:
CREATE TABLE Images(Id INT PRIMARY KEY AUTO_INCREMENT, Data MEDIUMBLOB);
然後運行如下 PYTHON 代碼進行：
import MySQLdb as mdb
import sys
try:
#用讀文件模式打開圖片
fin = open("../web.jpg")
#將文本讀入 img 對象中
img = fin.read()
#關閉文件
fin.close()
except IOError, e:
#如果出錯，列印錯誤信息
print "Error %d: %s" % (e.args[0],e.args[1])
sys.exit(1)
try:
#鏈接 mysql，獲取對象
conn = mdb.connect(host='localhost',user='root',passwd='root',
db='test')
#獲取執行 cursor
cursor = conn.cursor()
#直接將數據作為字元串，插入資料庫
cursor.execute("INSERT INTO Images SET Data='%s'" %
mdb.escape_string(img))
#提交數據
conn.commit()
#提交之後，再關閉 cursor 和鏈接
cursor.close()
conn.close()
except mdb.Error, e:
#若出現異常，列印信息
print "Error %d: %s" % (e.args[0],e.args[1])
sys.exit(1)
實例 8、從資料庫中把圖片讀出來
import MySQLdb as mdb
import sys
try:
#連接 mysql，獲取連接的對象
conn = mdb.connect('localhost', 'root', 'root', 'test');
cursor = conn.cursor()
#執行查詢該圖片欄位的 SQL
cursor.execute("SELECT Data FROM Images LIMIT 1")
#使用二進制寫文件的方法，打開一個圖片文件，若不存在則自動創建
fout = open('image.png','wb')
#直接將數據如文件
fout.write(cursor.fetchone()[0])
#關閉寫入的文件
fout.close()
#釋放查詢數據的資源
cursor.close()
conn.close()
except IOError, e:
#捕獲 IO 的異常 ，主要是文件寫入會發生錯誤
print "Error %d: %s" % (e.args[0],e.args[1])
sys.exit(1)
實例 9、使用 Transaction 即事務（手動提交，自動回滾）
import MySQLdb as mdb
import sys
try:
#連接 mysql，獲取連接的對象
conn = mdb.connect('localhost', 'root', 'root', 'test');
cursor = conn.cursor()
#如果某個資料庫支持事務，會自動開啟
#這里用的是 MYSQL，所以會自動開啟事務（若是 MYISM 引擎則不會）
cursor.execute("UPDATE Writers SET Name = %s WHERE Id = %s",
("Leo Tolstoy", "1"))
cursor.execute("UPDATE Writers SET Name = %s WHERE Id = %s",
("Boris Pasternak", "2"))
cursor.execute("UPDATE Writer SET Name = %s WHERE Id = %s",
("Leonid Leonov", "3"))
#事務的特性 1、原子性的手動提交
conn.commit()
cursor.close()
conn.close()
except mdb.Error, e:
#如果出現了錯誤，那麼可以回滾，就是上面的三條語句要麼執行，要麼都不執行
conn.rollback()
print "Error %d: %s" % (e.args[0],e.args[1])
結果：
1、因為不存在 writer 表（ SQL 第三條語句），所以出現錯誤：Error 1146: Table 『test.writer' doesn't exist
2、出現錯誤，出發異常處理， 3 條語句的前兩條會自動變成了沒有執行，結果不變
3、如果本代碼放到一個 MyISAM 引擎表，前兩句會執行，第三句不會；如果是 INNDB 引擎，則都不會執行。
㈨ 誰知道資料庫優化設計方案有哪些
本文首先討論了基於第三範式的資料庫表的基本設計，著重論述了建立主鍵和索引的策略和方案，然後從資料庫表的擴展設計和庫表對象的放置等角度概述了資料庫管理系統的優化方案。
關鍵詞： 優化（Optimizing） 第三範式（3NF） 冗餘數據（Rendant Data） 索引（Index） 數據分割（Data Partitioning） 對象放置（Object Placement）
1 引言
資料庫優化的目標無非是避免磁碟I/O瓶頸、減少CPU利用率和減少資源競爭。為了便於讀者閱讀和理解，筆者參閱了Sybase、Informix和Oracle等大型資料庫系統參考資料，基於多年的工程實踐經驗，從基本表設計、擴展設計和資料庫表對象放置等角度進行討論，著重討論了如何避免磁碟I/O瓶頸和減少資源競爭，相信讀者會一目瞭然。
2 基於第三範式的基本表設計
在基於表驅動的信息管理系統（MIS）中，基本表的設計規范是第三範式（3NF）。第三範式的基本特徵是非主鍵屬性只依賴於主鍵屬性。基於第三範式的資料庫表設計具有很多優點：一是消除了冗餘數據，節省了磁碟存儲空間；二是有良好的數據完整性限制，即基於主外鍵的參照完整限制和基於主鍵的實體完整性限制，這使得數據容易維護，也容易移植和更新；三是數據的可逆性好，在做連接（Join）查詢或者合並表時不遺漏、也不重復；四是因消除了冗餘數據（冗餘列），在查詢（Select）時每個數據頁存的數據行就多，這樣就有效地減少了邏輯I/O，每個Cash存的頁面就多，也減少物理I/O；五是對大多數事務(Transaction)而言，運行性能好；六是物理設計(Physical Design)的機動性較大，能滿足日益增長的用戶需求。
在基本表設計中，表的主鍵、外鍵、索引設計佔有非常重要的地位，但系統設計人員往往只注重於滿足用戶要求，而沒有從系統優化的高度來認識和重視它們。實際上，它們與系統的運行性能密切相關。現在從系統資料庫優化角度討論這些基本概念及其重要意義：
（1）主鍵(Primary Key)：主鍵被用於復雜的SQL語句時，頻繁地在數據訪問中被用到。一個表只有一個主鍵。主鍵應該有固定值（不能為Null或預設值，要有相對穩定性），不含代碼信息，易訪問。把常用（眾所周知）的列作為主鍵才有意義。短主鍵最佳（小於25bytes），主鍵的長短影響索引的大小，索引的大小影響索引頁的大小，從而影響磁碟I/O。主鍵分為自然主鍵和人為主鍵。自然主鍵由實體的屬性構成，自然主鍵可以是復合性的，在形成復合主鍵時，主鍵列不能太多，復合主鍵使得Join*作復雜化、也增加了外鍵表的大小。人為主鍵是，在沒有合適的自然屬性鍵、或自然屬性復雜或靈敏度高時，人為形成的。人為主鍵一般是整型值（滿足最小化要求），沒有實際意義，也略微增加了表的大小；但減少了把它作為外鍵的表的大小。
（2）外鍵（Foreign Key）：外鍵的作用是建立關系型資料庫中表之間的關系（參照完整性），主鍵只能從獨立的實體遷移到非獨立的實體，成為後者的一個屬性，被稱為外鍵。
（3）索引(Index)：利用索引優化系統性能是顯而易見的，對所有常用於查詢中的Where子句的列和所有用於排序的列創建索引，可以避免整表掃描或訪問，在不改變表的物理結構的情況下，直接訪問特定的數據列，這樣減少數據存取時間；利用索引可以優化或排除耗時的分類*作；把數據分散到不同的頁面上，就分散了插入的數據；主鍵自動建立了唯一索引，因此唯一索引也能確保數據的唯一性（即實體完整性）；索引碼越小，定位就越直接；新建的索引效能最好，因此定期更新索引非常必要。索引也有代價：有空間開銷，建立它也要花費時間，在進行Insert、Delete和Update*作時，也有維護代價。索引有兩種：聚族索引和非聚族索引。一個表只能有一個聚族索引，可有多個非聚族索引。使用聚族索引查詢數據要比使用非聚族索引快。在建索引前，應利用資料庫系統函數估算索引的大小。
① 聚族索引（Clustered Index）：聚族索引的數據頁按物理有序儲存，佔用空間小。選擇策略是，被用於Where子句的列：包括范圍查詢、模糊查詢或高度重復的列（連續磁碟掃描）；被用於連接Join*作的列；被用於Order by和Group by子句的列。聚族索引不利於插入*作，另外沒有必要用主鍵建聚族索引。
② 非聚族索引（Nonclustered Index）：與聚族索引相比，佔用空間大，而且效率低。選擇策略是，被用於Where子句的列：包括范圍查詢、模糊查詢（在沒有聚族索引時）、主鍵或外鍵列、點（指針類）或小范圍（返回的結果域小於整表數據的20%）查詢；被用於連接Join*作的列、主鍵列（范圍查詢）；被用於Order by和Group by子句的列；需要被覆蓋的列。對只讀表建多個非聚族索引有利。索引也有其弊端，一是創建索引要耗費時間，二是索引要佔有大量磁碟空間，三是增加了維護代價（在修改帶索引的數據列時索引會減緩修改速度）。那麼，在哪種情況下不建索引呢？對於小表（數據小於5頁）、小到中表（不直接訪問單行數據或結果集不用排序）、單值域（返回值密集）、索引列值太長（大於20bitys）、容易變化的列、高度重復的列、Null值列，對沒有被用於Where子語句和Join查詢的列都不能建索引。另外，對主要用於數據錄入的，盡可能少建索引。當然，也要防止建立無效索引，當Where語句中多於5個條件時，維護索引的開銷大於索引的效益，這時，建立臨時表存儲有關數據更有效。
批量導入數據時的注意事項：在實際應用中，大批量的計算（如電信話單計費）用C語言程序做，這種基於主外鍵關系數據計算而得的批量數據（文本文件），可利用系統的自身功能函數（如Sybase的BCP命令）快速批量導入，在導入資料庫表時，可先刪除相應庫表的索引，這有利於加快導入速度，減少導入時間。在導入後再重建索引以便優化查詢。
（4）鎖：鎖是並行處理的重要機制，能保持數據並發的一致性，即按事務進行處理；系統利用鎖，保證數據完整性。因此，我們避免不了死鎖，但在設計時可以充分考慮如何避免長事務，減少排它鎖時間，減少在事務中與用戶的交互，杜絕讓用戶控制事務的長短；要避免批量數據同時執行，尤其是耗時並用到相同的數據表。鎖的徵用：一個表同時只能有一個排它鎖，一個用戶用時，其它用戶在等待。若用戶數增加，則Server的性能下降，出現「假死」現象。如何避免死鎖呢？從頁級鎖到行級鎖，減少了鎖徵用；給小表增加無效記錄，從頁級鎖到行級鎖沒有影響，若在同一頁內競爭有影響，可選擇合適的聚族索引把數據分配到不同的頁面；創建冗餘表；保持事務簡短；同一批處理應該沒有網路交互。
（5）查詢優化規則：在訪問資料庫表的數據(Access Data)時，要盡可能避免排序（Sort）、連接(Join)和相關子查詢*作。經驗告訴我們，在優化查詢時，必須做到：
① 盡可能少的行；
② 避免排序或為盡可能少的行排序，若要做大量數據排序，最好將相關數據放在臨時表中*作；用簡單的鍵（列）排序，如整型或短字元串排序；
③ 避免表內的相關子查詢；
④ 避免在Where子句中使用復雜的表達式或非起始的子字元串、用長字元串連接；
⑤ 在Where子句中多使用「與」（And）連接，少使用「或」(Or)連接；
⑥ 利用臨時資料庫。在查詢多表、有多個連接、查詢復雜、數據要過濾時，可以建臨時表（索引）以減少I/O。但缺點是增加了空間開銷。
除非每個列都有索引支持，否則在有連接的查詢時分別找出兩個動態索引，放在工作表中重新排序。
3 基本表擴展設計
基於第三範式設計的庫表雖然有其優越性（見本文第一部分），然而在實際應用中有時不利於系統運行性能的優化：如需要部分數據時而要掃描整表，許多過程同時競爭同一數據，反復用相同行計算相同的結果，過程從多表獲取數據時引發大量的連接*作，當數據來源於多表時的連接*作；這都消耗了磁碟I/O和CPU時間。
尤其在遇到下列情形時，我們要對基本表進行擴展設計：許多過程要頻繁訪問一個表、子集數據訪問、重復計算和冗餘數據，有時用戶要求一些過程優先或低的響應時間。
如何避免這些不利因素呢？根據訪問的頻繁程度對相關表進行分割處理、存儲冗餘數據、存儲衍生列、合並相關表處理，這些都是克服這些不利因素和優化系統運行的有效途徑。
3.1 分割表或儲存冗餘數據
分割表分為水平分割表和垂直分割表兩種。分割表增加了維護數據完整性的代價。
水平分割表：一種是當多個過程頻繁訪問數據表的不同行時，水平分割表，並消除新表中的冗餘數據列；若個別過程要訪問整個數據，則要用連接*作，這也無妨分割表；典型案例是電信話單按月分割存放。另一種是當主要過程要重復訪問部分行時，最好將被重復訪問的這些行單獨形成子集表（冗餘儲存），這在不考慮磁碟空間開銷時顯得十分重要；但在分割表以後，增加了維護難度，要用觸發器立即更新、或存儲過程或應用代碼批量更新，這也會增加額外的磁碟I/O開銷。
垂直分割表（不破壞第三範式），一種是當多個過程頻繁訪問表的不同列時，可將表垂直分成幾個表，減少磁碟I/O（每行的數據列少，每頁存的數據行就多，相應佔用的頁就少），更新時不必考慮鎖，沒有冗餘數據。缺點是要在插入或刪除數據時要考慮數據的完整性，用存儲過程維護。另一種是當主要過程反復訪問部分列時，最好將這部分被頻繁訪問的列數據單獨存為一個子集表（冗餘儲存），這在不考慮磁碟空間開銷時顯得十分重要；但這增加了重疊列的維護難度，要用觸發器立即更新、或存儲過程或應用代碼批量更新，這也會增加額外的磁碟I/O開銷。垂直分割表可以達到最大化利用Cache的目的。
總之，為主要過程分割表的方法適用於：各個過程需要表的不聯結的子集，各個過程需要表的子集，訪問頻率高的主要過程不需要整表。在主要的、頻繁訪問的主表需要表的子集而其它主要頻繁訪問的過程需要整表時則產生冗餘子集表。
注意，在分割表以後，要考慮重新建立索引。
3.2 存儲衍生數據
對一些要做大量重復性計算的過程而言，若重復計算過程得到的結果相同（源列數據穩定，因此計算結果也不變），或計算牽扯多行數據需額外的磁碟I/O開銷，或計算復雜需要大量的CPU時間，就考慮存儲計算結果（冗餘儲存）。現予以分類說明：
若在一行內重復計算，就在表內增加列存儲結果。但若參與計算的列被更新時，必須要用觸發器更新這個新列。
若對表按類進行重復計算，就增加新表（一般而言，存放類和結果兩列就可以了）存儲相關結果。但若參與計算的列被更新時，就必須要用觸發器立即更新、或存儲過程或應用代碼批量更新這個新表。
若對多行進行重復性計算（如排名次），就在表內增加列存儲結果。但若參與計算的列被更新時，必須要用觸發器或存儲過程更新這個新列。
總之，存儲冗餘數據有利於加快訪問速度；但違反了第三範式，這會增加維護數據完整性的代價，必須用觸發器立即更新、或存儲過程或應用代碼批量更新，以維護數據的完整性。
3.3 消除昂貴結合
對於頻繁同時訪問多表的一些主要過程，考慮在主表內存儲冗餘數據，即存儲冗餘列或衍生列（它不依賴於主鍵），但破壞了第三範式，也增加了維護難度。在源表的相關列發生變化時，必須要用觸發器或存儲過程更新這個冗餘列。當主要過程總同時訪問兩個表時可以合並表，這樣可以減少磁碟I/O*作，但破壞了第三範式，也增加了維護難度。對父子表和1：1關系表合並方法不同：合並父子表後，產生冗餘表；合並1：1關系表後，在表內產生冗餘數據。
4 資料庫對象的放置策略
資料庫對象的放置策略是均勻地把數據分布在系統的磁碟中，平衡I/O訪問，避免I/O瓶頸。
⑴ 訪問分散到不同的磁碟，即使用戶數據盡可能跨越多個設備，多個I/O運轉，避免I/O競爭，克服訪問瓶頸；分別放置隨機訪問和連續訪問數據。
⑵ 分離系統資料庫I/O和應用資料庫I/O。把系統審計表和臨時庫表放在不忙的磁碟上。
⑶ 把事務日誌放在單獨的磁碟上，減少磁碟I/O開銷，這還有利於在障礙後恢復，提高了系統的安全性。
⑷ 把頻繁訪問的「活性」表放在不同的磁碟上；把頻繁用的表、頻繁做Join*作的表分別放在單獨的磁碟上，甚至把把頻繁訪問的表的欄位放在不同的磁碟上，把訪問分散到不同的磁碟上，避免I/O爭奪；
⑸ 利用段分離頻繁訪問的表及其索引（非聚族的）、分離文本和圖像數據。段的目的是平衡I/O，避免瓶頸，增加吞吐量，實現並行掃描，提高並發度，最大化磁碟的吞吐量。利用邏輯段功能，分別放置「活性」表及其非聚族索引以平衡I/O。當然最好利用系統的默認段。另外，利用段可以使備份和恢復數據更加靈活，使系統授權更加靈活。
㈩ 資料庫作業，高手解答。。。
第一個表桐世伏： create table goods(goodsId char(8) primary key, goodName varchar2(30), unitprice number(10,2) check(unitprice>0), category varchar2(8), provider varchar2(30)); 第二個表： create table customer(customerId char(2) primary key, name varchar2(50) not null, address varchar2(50), email varchar2(50) unique, sex char(2) default '男局攜' check(sex in('男'返卜，'女'))， cardId char(18)); 第三個表： create table purchase(customerId char(8) references customer(customerId), goodsId char(8) references goods(goodsId), nums number(5) check(nums between 1 and 30));