資料庫課程設計銀行

❶ 資料庫課程設計是怎麼一個流程啊，完全不知道怎麼下手，誰能幫我找一下一個關於銀行儲蓄管理的系統嗎

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

❸ 資料庫課程的內容有那些

本課程主要介紹數據結構原理，內容有：1. 緒論；2. 三種主要數據模型；3. 關系資料庫標准語言、關系系統及其查詢優化；4. 關系數據理論；5. 資料庫設計；6. 資料庫維護；7. 資料庫管理系統；8. 分布式資料庫系統；9. 計算機網路的安全等。
資料庫課程設計是在學生系統的學習了資料庫原理課程後，按照關系型資料庫的基本原理，綜合運用所學的知識，以小組為單位，設計開發一個小型的資料庫管理系統。通過對一個實際問題的分析、設計與實現，將原理與應用相結合，使學生學會如何把書本上學到的知識用於解決實際問題，培養學生的動手能力；另一方面，使學生能深入理解和靈活掌握教學內容。

總體設計要求：
四到五人為一個小組，小組成員既要有相互合作的精神，又要分工明確。每個學生都必須充分了解整個設計的全過程。
從開始的系統需求分析到最後的軟體測試，都要有詳細的計劃，設計文檔應按照軟體工程的要求書寫。
系統中的數據表設計應合理、高效，盡量減少數據冗餘。
軟體界面要友好、安全性高。
軟體要易於維護、方便升級。
編程語言可由小組根據自己的情況選擇，但一般情況下應該是小組的每個成員都對該語言較熟悉。避免把學習語言的時間放在設計期間。
參考使用的語言有：VF、VB、Delphi 、PB、VC、SQL_Server等。

學生學籍管理系統

一、設計目的
學生根據所學的資料庫原理與程序設計的知識，能夠針對一個小型的資料庫管理系統，進行系統的需求分析，系統設計，資料庫設計，編碼，測試等，完成題目要求的功能，從而達到掌握開發一個小型資料庫的目的。

二、設計內容
1．主要的數據表
學生基本情況數據表，學生成績數據表，課程表，代碼表等。
2．主要功能模塊
1）實現學生基本情況的錄入、修改、刪除等基本操作。
2）對學生基本信息提供靈活的查詢方式。
3）完成一個班級的學期選課功能。
4）實現學生成績的錄入、修改、刪除等基本操作。
5）能方便的對學生的個學期成績進行查詢。
6）具有成績統計、排名等功能。
7）具有留級、休學等特殊情況的處理功能。
8）能輸出常用的各種報表。
9）具有數據備份和數據恢復功能。

三、設計要求
學生成績表的設計，要考慮到不同年級的教學計劃的變化情況。
對於新生班級，應該首先進行基本情況錄入、選課、然後才能進行成績錄入。

圖書管理系統

一、設計目的
學生根據所學的資料庫原理與程序設計的知識，能夠針對一個小型的資料庫管理系統，進行系統的需求分析，系統設計，資料庫設計，編碼，測試等，完成題目要求的功能，從而達到掌握開發一個小型資料庫的目的。

二、設計內容
1．要的數據表
圖書基本信息表，借書卡信息表，借閱信息表，圖書分類信息表，代碼表等。
2．功能模塊
1）圖書基本情況的錄入、修改、刪除等基本操作。
2）辦理借書卡模塊。
3）實現借書功能。
4）實現還書功能。
5）能方便的對圖書進行查詢。
6）對超期的情況能自動給出提示信息。
7）具有數據備份和數據恢復功能。

三、設計要求
圖書編號可參考國家統一的圖書編碼方法，再完成基本功能模塊的情況下，盡量使系統能具有通用性。

銀行儲蓄系統

一、設計目的
學生根據所學的資料庫原理與程序設計的知識，能夠針對一個小型的資料庫管理系統，進行系統的需求分析，系統設計，資料庫設計，編碼，測試等，完成題目要求的功能，從而達到掌握開發一個小型資料庫的目的。

二、設計內容
1．主要的數據表
定期存款單，活期存款帳，存款類別代碼表等。
2．功能模塊
1）實現儲戶開戶登記。
2）辦理定期存款帳。
3）辦理定期取款手續。
4）辦理活期存款帳
5）辦理活期取款手續。
6）實現利息計算。
7）輸出明細表。
8）具有數據備份和數據恢復功能。

三、設計要求
要進行實際調研，系統功能在實現時參照實際的儲蓄系統的功能。同時要考慮銀行系統數據的安全與保密工作。數據要有加密功能。

設備管理系統

一、設計目的
學生根據所學的資料庫原理與程序設計的知識，能夠針對一個小型的資料庫管理系統，進行系統的需求分析，系統設計，資料庫設計，編碼，測試等，完成題目要求的功能，從而達到掌握開發一個小型資料庫的目的。

二、設計內容
1．主要數據表
設備明細帳表，設備使用單位代碼表，國家標准設備分類表等。
2．功能模塊
1）實現設備的錄入、刪除、修改等基本操作。
2）實現國家標准設備代碼的維護。
3）能夠對設備進行方便的檢索。
4）實現設備折舊計算。
5）能夠輸出設備分類明細表。
6）具有數據備份和數據恢復功能。

三、設計要求
具體設備編碼參考國家統一編碼方法，功能實現也要考慮通用性。

醫院葯品進銷存系統

❹ 一個資料庫設計問題

顧客(姓名,地址,電話,身份證號,客戶號,顧客狀態,申請時間,開戶行),主鍵為客戶號

帳戶信息(客戶號,銀行帳號,身份證號,余額,交易次數,帳戶狀態,開戶時間)，主鍵為銀行帳號,外鍵為客戶號

交易記錄(流水號,銀行帳號,交易金額,交易時間)，主鍵為流水號,外鍵為銀行帳號

顧客記錄可能存在相同姓名相同身份證號相同開戶行申請的情況，但客戶號是唯一的，一個顧客理論上對應多個帳戶信息(有可能多次開戶,銀行帳號是唯一的)，一個帳戶信息對應多個交易記錄（可以通過銀行帳號查詢相應明細）

本人不才，對這個不是太懂，希望有高人指點

ps:2樓不用畫er圖，余額不能放在顧客表裡面,只需要用專用的工具例如PD或ERWIN將物理模式和邏輯模式輸入，然後逆向工程導出建表sql即可

❺ 資料庫課程設計

自己做

❻ 誰能幫我做一份SQL課程設計，關於銀行儲蓄管理系統設計與開發的（

這么完整的一套誰會幫你做，No Money，No Service

❼ 資料庫高手請進——關於銀行儲蓄系統問題

....要是設計好了,就可以自己開銀行

❽ 求幫忙做一個銀行資料庫 Oracle

功能一：
create database bank;
功能二：
create table userinfo(
customerID number(10) not null,
customerName varchar2(10) not null,
PID char(18) not null,
telephone char(11) not null,
address varchar2(255) not null
);
create table cardinfo(
cardID varchar2(19) not null,
cardCustomerID number(10) not null,
curtype char(3) not null,
savingtype char(4) not null,
openDate date not null,
openmoney number(10,2) not null,
blance number(10,2) not null,
password char(6) not null,
isreportLoss char(2) not null
);
create table transinfo(
id number(15) not null,
transcustomerID number(10) not null,
transcardID varchar2(19) not null,
transdate date not null,
transmoney number(10,2) not null,
transtype char(4) not null,
remark varchar2(255) not null
);
功能三：
alter table userinfo add constraint pk_userinfo primary key (customerID);
alter table userinfo add constraint ck_PID check(length(PID)=18);
alter table cardinfo add constraint pk_cardinfo primary key (cardID);
alter table cardinfo add constraint fk_CustomerID_card foreign key cardCustomerID references userinfo(customerID);
alter table transinfo add constraint pk_transinfo primary key (id);
alter table transinfo add constraint fk_CustomerID_trans foreign key cardCustomerID references userinfo(customerID);
alter table transinfo add constraint fk_transcardID_trans foreign key cardCustomerID references cardinfo(cardID);
功能四：
insert into userinfo values(1,'張三','123456789012345671','13012345671','地址1');
insert into userinfo values(2,'李四','123456789012345672','13012345672','地址2');
insert into userinfo values(3,'王五','123456789012345673','13012345673','地址3');
insert into cardinfo values('1234567890123456789',1,'RMB','活期',sysdate,5.04,5.04,'123456','否');
insert into cardinfo values('1234567890123456788',2,'JPY','活期',sysdate,3.22,3.22,'123457','否');
insert into cardinfo values('1234567890123456787',3,'USA','定期',sysdate,6.78,6.78,'123458','否');
insert into transinfo values(1,1,'1234567890123456789',sysdate,0.23,'存入','存錢');
insert into transinfo values(2,2,'1234567890123456788',sysdate,1.27,'支取','取錢');
insert into transinfo values(3,3,'1234567890123456787',sysdate,2.34,'存入','存錢');
功能五：
select transcardID,transmoney from transinfo where to_char(transdate,'mm')=to_char(sysdate,'mm') and transmoney=max(transmoney);
功能六：
create procere p_c
is
cursor cr is
select b.cardID,a.customerName,a.telephone from userinfo a,cardinfo b where a.customerID=b.cardCustomerID and to_char(sysdate,'dd') in ('28','29','30','31') and b.blance<200;
cur_info cr;
begin
for cur_info in cr loop
dbms_output.put_line('卡號：' || cur_info.cardID || '&&' || '姓名：' || cur_info.customerName || '電話：' || cur_info.telephone);
end loop;
end p_c;

❾ 銀行如何建設企業級資料庫基礎邏輯數據模型

前言:邏輯數據模型LDM是一種圖形化的展現方式，一般採用面向對象的設計方法，有效組織來源多樣的各種業務數據，使用統一的邏輯語言描述業務。藉助相對抽象、邏輯統一且結構穩健的結構，實現數據倉庫系統所要求的數據存儲目標，支持大量的分析應用，是實現業務智能的重要基礎，同時也是數據管理分析的工具和交流的有效手段。 需要強調的是，數據倉庫邏輯數據模型特指數據倉庫系統的核心基礎模型，在搭建企業級數據倉庫系統時，需要充分了解和分析種前台業務處理系統和應用，在此基礎上進行有效的重組和整合，為各種分析應用(如客戶關系管理、風險管理等)提供單一的、整合的數據基礎，保證全行不同業務部門從不同的視角都可以使用統一的數據實現各自的分析需求。——擔負這種數據重組和整合任務的數據模型稱為數據倉庫系統的「基礎邏輯數據模型」。 基礎邏輯數據模型建設好之後，銀行可根據不同的分析應用需要(如客戶關系管理、績效考核、風險管理等)，根據應用產品和功能設計不同的分析應用模型，包含具體的、特定的分析邏輯，往往這種模型中都含有較多加工處理的成分。——這種為實現特定用途而設計的數據模型稱為數據倉庫系統的「應用數據模型」。 因此，不誇張地說核心基礎數據模型建設的成敗性會影響到整個數據倉庫系統的建設乃至後續各種分析應用，應引起銀行科技建設和業務分析人員的高度重視。 本文嘗試從銀行建設基礎邏輯數據模型的角度出發，分析、探討建設過程中應該考慮的主要因素、建設的方法以及注意的問題。 一、整體規劃、明確目標、合理定位 銀行建設數據倉庫系統時應充分明確建設目標，核心的邏輯數據模型是對銀行業務的高度抽象、能夠提供對關鍵業務數據的組織和整理，建立一套完整、統一、規范的標准，以便進行各類分析。一個好的核心基礎數據數據模型應該滿足以下條件: 概念上:具有高度抽象的、中性的、可共享的的概念，可有效、全面、完整地適應與涵蓋銀行現有的業務范疇以及數據范圍;不針對某個特別的應用而設計; 結構上:應是穩定的、靈活的、可擴展的;能以滿足第三範式的方法構建模型，存放最詳盡的數據，保證足夠的靈活性，適應復雜的實際業務情況，在業務發生變化或者新增數據源時易於擴展;核心結構在很長時間內應保持穩定性，便於回答不斷產生、不斷變化且無法預先定義的業務問題; 表現形式:應是規范的，易懂的;包括各類命名規范，業務規則定義，度量方式等。使用統一的業務語言進行模型設計，易於業務人員的理解和使用;也有利於IT部門和業務部門人員的溝通; 數據倉庫系統的建設目的和方法不同於傳統業務系統，其開發建設方式也有所不同，它的建設絕不是一蹴而就的事情，不能期望一朝一夕就可以全部完成，比較成熟的建設步驟應該是分階段實施，逐步進行完善和增強因此作為項目起步的LDM建設對於規范和推動整個數據倉庫系統的建設都將起到一個很好的促進。整個建設過程最關鍵的階段就是項目的最初階段，應將工作重心放在搭建模型框架、建立模型設計思想和培養模型設計人員三個方面。 明確了建設目標，具體實施應該如何開展呢? 二、審慎選擇、量體裁衣、度身定做 銀行在明確建設目標之後，如何選擇具體的實施策略、制定設計的階段和步驟呢?常見的主要有以下兩種: 第一種:自主研發:銀行根據以往的業務經驗提煉本行業務的關鍵主題;再設計出本行的概念模型;然後通過具體的業務反復論證，同時考慮將來的分析需求進行基礎邏輯數據模型的詳細設計。 這種方法可以快速啟動，完全依託本行的業務元素和規則，使用行內技術人員和業務人員比較熟悉的語言進行模型的設計，具有很好的適用性。但是整個建設周期比較長，同時往往由於經驗不足等原因給項目帶來一些不可控的風險，由於參與人員經驗的不足，不能夠站在全行的高度，從管理分析的角度去理解所有的業務以及相應的數據，造成一些局限性。 第二種:依託業成熟產品進行客戶化:銀行研究不同的業界模型產品，從中選擇一個作為藍本，結合本行的業務數據和應用系統進行具體的定製化。 這種方法的建設周期短、風險小，同時也能夠很好地借鑒成熟的邏輯數據模型中蘊涵的經營管理理念。但是銀行需要研究和比較多個業界流行的邏輯數據模型，熟悉各自的設計思想和理念，並從中挑選一個適合本行的模型產品進行客戶化。 從國際、國內商業銀行建設數據倉庫系統的經驗和案例來看，為了保證項目的成功實施，避免和控制項目風險，他們幾乎都選擇了第二種方法:客戶化。那銀行在面對眾多邏輯數據模型產品進行選擇的過程中主要應該都關注一些什麼樣的內容呢? 產品層面: 覆蓋范圍:模型產品應能夠適合、涵蓋銀行的所有業務范圍，可以在單一模型中能支撐金零售銀行、公司業務、保險、信用卡、經紀、證券和電子商務等，滿足未來混業經營的需要; 對業務發展的適應性:模型產品應有高度的概括和歸納，既滿足範式化要求，又具有足夠的靈活性，在擴展業務、新增品種或改變規則時，模型通過簡單的調整和擴展即可適應; 對應用的支撐和擴充:模型產品不應偏向某個部門或某些專業的特定應用，要能夠支持績效管理、客戶關系管理、資產負債管理、資金財務管理、風險管理等應用，並與國際金融業完全接軌，從數據介面層面支撐業界監管需要; 模型的開放性:模型產品應有清晰、嚴謹的模型架構，滿足模塊化和結構化的設計要求，真正實現數據一次導入，多次使用; 轉化成物理數據模型的方便性:LDM設計完成，進行一些物理化的定義之後就可以直接利用建模工具平滑地完成物理模型設計。 服務層面: 客戶化方法與能力:邏輯數據模型必須有經過實際項目驗證過的客戶化方法論做指導，明確嚴格的工作步驟、流程、任務分配，並提供必要模板; 業績經驗與表現:應具有國際化大型(特別是國內)商業銀行相關項目和領域的成功實施案例;在行業內具有良好的信譽和業績; 全球支持能力:全球專職研發團隊——各國家地區的具體實施團隊;高級建模顧問——高級金融行業顧問; 不難看出，上述這些考核的方面都是和將來的實施密切相關的。的確，一個成熟的優秀的模型產品，如果沒有得到成功的實施，最終也不能為銀行創造效益。下一部分主要討論在實施過程中的關鍵因素。 三、關鍵成功因素 (1)參與人員的業務經驗 LDM的設計和實施不是一個純粹的技術問題，需要參與人員具有較高的銀行業務修養和素質，設計人員應能夠憑借豐富的業務經驗和知識，將散落在各種不同業務系統以及日常經營管理中的各種數據元素進行高度的抽象和概況，形成本行的幾個主題域(如當事人、協議、產品、事件等)，用以清晰地表達業務邏輯和關系。同時，他們也必須時刻以目標(建設數據倉庫系統)為導向，有選擇地從前台業務系統中抽取相關的數據信息進行映射。 (2)設計團隊的溝通機制 邏輯數據模型的設計過程本身就是一個不斷發現問題、解決問題的過程，不可能某一個人就能夠掌握龐雜銀行業務中的點點滴滴，因此需要整個項目團隊的密切配合。每個設計人員都必應具有良好的學習溝通能力，能夠對建模工作達成共識，根據所定義的結構，將具體的業務數據映射到模型中，同時進行一些修改和校正。 (3)銀行內部IT管理的水平 LDM設計過程中很大量的工作都是對現有業務系統的分析，包括對系統架構和功能的梳理、業務規則和關鍵業務元素的提煉、系統之間的邏輯關系等，並結合樣本數據初步了解數據質量。如果沒有一套有效的管理模式和有力的技術支持，如果沒有現有業務系統的完備資料;如果沒有快速問題反饋和解決機制，LDM的建設只能是空談，因此這給銀行內部IT管理水平提出了很高的要求。 (4)模型的管理和維護 在LDM整個建設周期內還應高度重視維護和管理工作，必需有嚴格的建模技術規范做指導和約束，包括命名、描述、版本控制等。隨著時間的推移和項目建設階段和目標的變化，為了使建成的基礎數據模型具有持續的生命力，應在建設的所有階段把涉及的建模規范內容文檔化並強制執行;在人員發生變動時規定新參與人員應嚴格遵守這些規范，不能另行編制，保證前後的一致性。 總結: 盡管LDM僅僅是一個邏輯的概念，數據倉庫系統需要在邏輯數據模型的指導下，進行真正的物理實施，將把分散在不同平台、以不同方式組織的各種業務數據以及部分外部信息經過清洗和轉化，在保證數據一致性、准確性和實效性的前提下，開發各種應用，奠定實現銀行商業智能的重要基礎。 但是可以看到，通過數據倉庫系統邏輯數據模型的設計，將有利於對銀行現有業務過程的全局認識和系統把握，同時還能夠從整體上對全行使用的操作型業務系統進行回顧，從而提供改造和完善的建議，最終探索出一條符合銀行自身業務實際發展要求的分析型應用系統的道路，為數據倉庫系統的建設奠定堅實的基礎。