當前位置:首頁 » 數據倉庫 » 大學生資料庫系統課程設計
擴展閱讀
webinf下怎麼引入js 2023-08-31 21:54:13
堡壘機怎麼打開web 2023-08-31 21:54:11

大學生資料庫系統課程設計

發布時間: 2023-08-04 23:43:58

1. 200分2天內求大學本科資料庫課程設計!急!急!

一、課程設計的內容
本課程設計要採用本課程中學習的資料庫設計方法,運用其基本思路與主要圖表工具完成「企業報刊訂閱管理系統」資料庫應用系統。完成信息需求分析與資料庫的概念設計、邏輯設計、物理設計以及處理功能設計,用sql Sever的資料庫管理系統、JSP開發工具實現該系統,並運行、評價、改進之;在此基礎上嚴格按課程設計教學大綱所附報告提綱撰寫課程設計報告。通過本課程設計進一步弄懂資料庫系統及其相關的基本概念,理解資料庫系統的系統結構、主要特點,掌握資料庫設計的原理、方法及其基本過程,初步具備資料庫應用設計的能力,初步形成運用資料庫應用系統解決管理決策中的實際問題的基本素質。
二、課程設計的要求與數據
要求學生結合所學管理知識,在借鑒課堂教學案例、了解家人或親友所從事的業務及其流程的基礎上,參考有關資料,選擇自己了解的一項業務,運用課堂所學資料庫系統與資料庫設計知識,完成信息需求分析、資料庫概念設計、邏輯設計、物理設計,實現完成該業務的資料庫應用系統,並運行、評價改進之,最後要寫出課程設計報告。
三、課程設計應完成的工作
要求學生按照《資料庫應用課程設計》教學大綱完成一個資料庫應用系統,並撰寫相應的課程設計報告,主要內容包括:
概述:系統的基本任務,主要業務,開發目標
1. 需求分析
2. (資料庫)概念(模型)設計
3. (資料庫)邏輯(模型)設計
4. 資料庫物理設計與資料庫保護設計
5. 處理功能設計
6. 資料庫應用系統的實現
7. 資料庫應用系統運行
四、課程設計進程安排
序號 設計各階段內容 地點 起止日期

五、應收集的資料及主要參考文獻
[1] 王 珊、陳 虹編著,資料庫系統原理教程,清華大學出版社,2003.
[1] 金銀秋主編,資料庫原理與設計,科學出版社,2000.
[2] 李建中 王珊,資料庫系統原理,電子工業出版社,1998.
[3] 李大友,資料庫原理及應用(第二版),清華大學出版社,2000

發出任務書日期: 年 月 日 指導教師簽名:

計劃完成日期: 年 月 日 基層教學單位責任人簽章:

主管院長簽章:
目錄
概述 …………………………………………………………………4
1. 需求分析…………………………………………………………4
1.1用戶需求……………………………………………………………………4
1.2業務流程分析………………………………………………………………4
1.3信息需求分析………………………………………………………………5
1.4功能需求分析………………………………………………………………6
2. (資料庫)概念(模型)設計…………………………………7
3. (資料庫)邏輯(模型)設計…………………………………9
3.1 一般邏輯模型設計…………………………………………………………9
3.2 具體邏輯模型設計…………………………………………………………9
4. 資料庫物理設計與資料庫保護設計…………………………10
4.1設計索引……………………………………………………………………10
4.2 設計表間關系………………………………………………………………10
4.3完整性設計…………………………………………………………………10
5. 處理功能設計…………………………………………………11
6. 資料庫應用系統的實現………………………………………11
7. 資料庫應用系統運行…………………………………………11
7.1 寫出系統操作使用的簡要說明……………………………………………11
7.2 系統實施過程………………………………………………………………11
7.3系統使用結果………………………………………………………………22
7.4系統評價……………………………………………………………………31

企業報刊訂閱管理系統
概述
隨著社會不斷的發展,人們的生活水平越來越高,對知識的和對時事的渴求也越來越高,人們希望能夠方便快捷地訂閱各種報刊雜志。但是各種各樣的報刊名目和詳細信息以及訂閱,為相關企業的管理造成很大的麻煩。因此網上訂閱成為不可或缺的一部分。
本系統就是面向一個企業的報刊訂閱管理系統。此系統是一種比較智能化的管理系統,它面向所有企業部門的職工用戶,但具有比較高的安全性能。它能夠實現報刊訂閱的基本功能,包括新報刊信息的錄入、訂閱、查詢等操作以及後台資料庫的備份和恢復。用戶合法注冊後必須輸入有效密碼才能成功進入此系統,可以進行訂閱報刊,查詢信息,統計信息等操作。對於非法操作,系統有識別和防護措施。

1. 需求分析
1.1 用戶需求:
本系統就是面向一個企業的報刊訂閱管理系統。此系統是一種比較智能化的管理系統,它面向所有企業部門的職工用戶,但具有比較高的安全性能。它能夠實現報刊訂閱的基本功能,包括新報刊信息的錄入、訂閱、查詢等操作以及後台資料庫的備份和恢復。用戶合法注冊後必須輸入有效密碼才能成功進入此系統,可以進行訂閱報刊,查詢信息,統計信息等操作。對於非法操作,系統有識別和防護措施。
訂閱信息處理的特點是訂閱信息處理量比較大,所管理的信息信息種類繁多,而且訂閱單、編輯單的發生量特別大,關聯信息多,查詢和統計的方式各不相同。因此在管理上實現起來有一定因難。
本系統在設計過程中,為了克服這些困難,需要使程序代碼標准化,軟體統一化,確保軟體的可維護性和實用性;刪除不必要的管理冗餘,實現管理規范化、科學化;界面友好、簡單化,做到實用、方便,盡量滿足報刊訂閱中員工的需要。

1.2 業務流程分析:
本系統主要面向的用戶有系統管理員、讀者。下面分角色對該系統的不同操作范圍做說明。
本系統主要有以下功能模塊:
(1)登陸功能:登陸系統為身份驗證登錄。分為管理員登錄和一般用戶登錄。分別通過不同的用戶名和密碼進入報刊訂閱管理界面,新的用戶需要注冊。
(2)錄入新信息功能:對於管理員,包括新用戶信息和新報刊信息的錄入功能,信息一旦提交就存入到後台資料庫中;普通用戶自行注冊進行可以修改個人信息。
(3)訂閱功能:用戶可以訂閱報刊,系統自動計算所需金額,並顯示在界面上;管理員不可訂閱報刊,必須以用戶身份訂閱報刊。
(4)查詢功能:用戶可以查詢並顯示自己所訂閱的信息;管理員可以按人員、報刊、部門分類查詢。查詢出的信息顯示在界面上,並且可以預覽和列印出結果。
(5)統計功能:管理員可以按用戶、部門、報刊統計報刊的銷售情況,並對一些重要的訂閱信息進行統計;普通用戶可以統計出自己的訂閱情況,並且可以預覽和列印出結果。
(6)系統維護功能:數據的安全管理,主要是依靠管理員對資料庫里的信息進行備份和恢復,資料庫備份後,如果出了什麼意外可以恢復資料庫到當時備份的狀態,這提高了系統和數據的安全性,有利於系統的維護。
下圖為該系統的業務流程圖

1.3 信息需求分析
1.3.1 資料收集:業務流程中用到的相關單據主要是報刊信息還有訂單信息
報刊信息表:
報刊代號 46-250 報刊名稱 IT時代周刊
出版報社 科技出版社
出版周期 半月刊
每月定價 10.00 元/月
分類編號 1001
報刊介紹 《IT時代周刊》是一本深刻解讀信息時代商業變革的雜志。除深度報道信息產業的重大新聞外,還報道金融、汽車、股市、零售等傳統行業利用IT提升商業與管理的新聞。《IT時代周刊》以調查見深度;以商業故事見功力。是CEO/CIO/CFO以及政府官員、商業領袖首選刊物。
訂單信息表:
訂單編號 報刊代號 用戶編號 訂閱日期 訂閱月數 份數 操作
3003 46-205 3206 2008-7-1 訂一月 1 取消訂閱
3004 26-306 3108 2008-7-8 訂半年 2 取消訂閱
3005 72-310 3100 2008-7-9 訂一年 1 取消訂閱
3006 45-214 2541 2008-7-10 訂一季 1 取消訂閱

1.3.2 事項分析:根據以上資料中標題、表頭等中各欄目名,可以得出相關事項,作為數據項;分析這些數據項,找出組合項、導出項、非結構化數據項,確定基本項。檢查是否有要補充的基本數據項,是否有要改進的地方,補充改進之,得出所有基本項。
1.4 功能需求分析:
本系統的主要結構功能圖如下:

2. (資料庫)概念(模型)設計
基本項構思ERD的四條基本原則:
①原則1 (確定實體):能獨立存在的事物,例如人、物、事、地、團體、機構、活動、事項等等,在其有多個由基本項描述的特性需要關注時,就應把它作為實體。
②原則2 (確定聯系):兩個或多個實體間的關聯與結合,如主管,從屬,組成,佔有,作用,配合,協同等等,當需要予以關注時,應作為聯系。實體間的聯系可分為一對一、一對多、多對多等三類,在確定聯系時還要確定其類型。
③原則3 (確定屬性):實體的屬性是實體的本質特徵。實體應有標識屬性(能把不同個體區分開來的屬性組),並指定其中一個作為主標識。聯系的屬性是聯系的結果或狀態。
④原則4(一事一地):信息分析中得到的基本項要在且僅在實體聯系圖中的一個地方作為屬性出現。

經過上述系統功能分析和需求總結,設計如下面所示的數據項和數據結構。
 管理員表(Adminuser):用於存放管理員的數據記錄,包括數據項:管理員名、密碼。
 部門表(Department):用來存放部門的相關記錄,包括數據項:部門號,部門名。
 用戶表(Users):用於存放注冊用戶的記錄,包括數據項:用戶賬號、密碼、真實姓名、身份證號、聯系電話,聯系地址,部門號(和部門表有關)等。
 報刊類別表(NewspaperClass):用於存放初始的報刊類別記錄,包括數據項:分類編號、分類名稱。
 報刊信息表(Newspaper):用於存放報刊記錄,包括數據項:報刊代號、報刊名稱、出版報社、出版周期、季度報價、內容介紹、分類編號(和報刊類別表有關)等。
 訂單表(Order):用於存放用戶下達的訂閱報刊的基本信息,包括數據項:訂單編號、用戶編號(用戶表的主碼)、報刊代號(報刊信息表的主碼)、訂閱份數、訂閱月數等。

根據上面的設計規劃出來的實體有部門實體、管理員實體、用戶實體、報刊類別實體、報刊信息實體和訂單實體。
部門實體的E-R圖如下圖所示: 管理員實體的E-R圖如下圖所示:

用戶實體的E-R圖如下圖所示: 報刊信息實體的E-R圖如下圖所示:

訂單實體的E-R圖如下圖所示: 報刊類別實體的E-R圖如下圖所示:

所有實體之間的的關系E-R圖如下圖所示:

3. (資料庫)邏輯(模型)設計
3.1 一般邏輯模型設計:
關系模型的邏輯結構是一組關系模式的集合。將E-R圖轉換為關系模型就是要將實體型、實體的屬性和實體型之間的聯系轉換為關系模式。
由ERD導出一般關系模型的四條原則;
①一個1:1聯系可以轉換為一個獨立的關系模式,也可以與任意一端對應的關系模式合並。如果軟換為一個獨立的關系模式,則與該聯系相連的各實體的碼以及聯系本身的屬性均轉換為關系的屬性,每個實體的碼均是該關系的候選碼。如果與某一端實體對應的關系模式何明,則需要在該關系模式的屬性中加入另一個關系模式的碼和聯系本身的屬性。
②一個1:n聯系可以轉換為一個獨立的關系模式,也可以與n端對應的關系模式合並。如果轉換為一個獨立的關系模式,則與該聯系相連的各實體的碼以及聯系本身的屬性均轉換為關系的屬性,而關系的碼為n端實體的碼。
③一個m:n聯系轉換為一個關系模式。與該聯系相連的各實體的碼以及聯系本身的屬性均轉換為關系的屬性,各實體的碼組成關系的碼或關系碼的一部分。
④3個或3個以上實體間的一個多元聯系可以轉換為一個關系模式。與該多元聯系項鏈呢的各實體的碼以及聯系本身的屬性均轉換為關系的屬性,各實體的碼組成關系的碼或關系碼的一部分。

根據以上原則將E-R圖轉換成的關系模式如下:
部門(部門號,部門名稱)
用戶(用戶賬號,密碼,用戶真實姓名,聯系電話,聯系地址,部門號)
管理員(管理員名,密碼)
報刊類別(分類編號,分類名稱)
報刊(報刊代號,報刊名稱,出版報社,出版周期,每月訂價,內容介紹,分類編號)
訂單(用戶編號,報刊代號,訂閱份數,訂閱月數,訂閱總額)

3.2 具體邏輯模型設計:
在SQL Server2000資料庫中,首先創建newspaper資料庫,然後根據資料庫的邏輯結構分析創建表4-1━4-6的6張數據表。在前台訪問資料庫階段設置了用戶和密碼,用戶為sa,密碼為空。
表4-2 department部門表結構
欄位名稱 欄位類型 允許空 說明
depNumber(主碼) Char(10) 否 部門號
depName Char(50) 是 部門名稱
表4-3 users用戶表結構
欄位名稱 欄位類型 允許空 說明
userNo(主碼) Char(10) 否 用戶帳號
userName Char(20) 是 真實姓名
passWord Char(10) 否 用戶密碼
address Char(150) 是 用戶聯系地址
phone Char(20) 是 用戶聯系電話
depNumber Char(10) 否 用戶所屬部門號
表4-3 newspaperClass報刊分類表結構
欄位名稱 欄位類型 允許空 說明
classid(主碼) Int(4) 否 報刊分類編號
className Char(30) 是 報刊分類名稱
表4-4 newspaper報刊表結構
欄位名稱 欄位類型 允許空 說明
newsNo(主碼) Char(10) 否 報刊代號
newsName Char(40) 否 報刊名稱
classid Int(4) 否 報刊分類編號
publish Char(150) 是 出版報社
pubPeriod Char(30) 是 出版周期
content Char(4000) 是 內容介紹
price Float(8) 否 每月報價
表-6 book訂單表結構
欄位名稱 欄位類型 允許空 說明
userNo(主碼) Char(10) 否 用戶帳號
newsNo(主碼) Char(10) 否 報刊代號
orderAmount Int(4) 否 訂閱份數
orderMonth Int(4) 否 訂閱月數
totalPrice Float(8) 是 訂閱總額
表4-1 adminuser管理員表結構
欄位名稱 欄位類型 允許空 說明
adminUser(主碼) Char(20) 否 管理員用戶名
adminPass Char(10) 否 管理員密碼
4. 資料庫物理設計與資料庫保護設計
4.1設計索引:我們可以在最經常查詢的列上建立索引以提高查詢效率。
而在這個系統中,我們經常要按用戶賬號,按報刊代號,按部門查詢,所以,我們可以為這三個表建立索引,建立所以的SQL語句如下,這幾個都是字元型
Create unique index userNum on users(userNo)
Create unique index departNum on department(depNumber)
Create unique index newsNum on newspaper(newsNO)

4.2 設計表間關系:

4.3完整性設計列出主要欄位完整性的欄位名、完整性約束條件;列出記錄完整性約束及其約束條件;列出參照完整性表。
主要欄位的完整性欄位名和參照完整性表可以參照上圖各個表之間的關系來看。
比如建立報刊表newspaper時,要求報刊代號在100~99999之間,報刊名稱和每月定價不能取空值,報刊類別是報刊類別表的主鍵,則
Create table user
(userNo char(10) constraint C1 check(newsNo between 100 and 99999),
newsName char(40) constraint C2 not null,
classid int(4) constraint C3 not null,
publish char(150),pubPeriod char(30),content char(4000),
price float(8) not null,
constraint C4 foreign key(classid) references newspaperclass(classid) )
4.4在有多個用戶操作時,考慮用戶授權與安全性控制。
因為這個報刊訂閱系統由多個用戶使用,分為管理員和用戶,他們擁有不同的許可權和安全性控制。所以在許可權設置方面,採用管理員和用戶分別使用用戶名和密碼進入他們能使用許可權范圍里的界面。管理員登陸系統後,可以添加、修改用戶和報刊的信息,可以對訂單進行查詢和統計,並且可以把查詢統計的結果進行預覽和列印出來,還要對資料庫系統進行維護,適時備份資料庫,一旦資料庫遇到問題,可以恢復到最近備份的狀態,減少不必要的損失。
用戶登錄,用戶使用該系統前需要進行注冊,他應該是該企業某個部門下面的員工,所以他需要輸入他的部門號等信息,注冊成功後,登錄到系統,可以修改自己的信息還有訂閱報刊,但由於許可權的限制,他只能查看和統計自己的訂單信息。
5. 處理功能設計
5.1 主控模塊設計:
使用本系統,首先它會自動彈出「歡迎使用本系統」的歡迎界面,然後跳轉到用戶身份驗證界面,選擇管理員的身份進入,有錄入(錄入報刊信息、錄入用戶信息),查詢,統計(統計用戶、統計、報刊訂單),系統維護(備份資料庫、恢復資料庫),注銷,退出等菜單可使用,沒注冊的用戶可進入注冊界面進行注冊,然後返回登錄界面登錄,進入後有歡迎界面,有訂閱、查詢、統計、修改、注銷、退出等菜單可使用。
6. 資料庫應用系統的實現
6.1 資料庫及其表結構的建立:按照上面的邏輯分析見表
6.2數據輸入:在建好的各個表中輸入數據,要符合數據的約束條件
7. 資料庫應用系統運行
7.1 寫出系統操作使用的簡要說明
本系統的運行需要安裝PowerBuilder9.0和SQL Server2000軟體。操作該系統,首先把備份的資料庫還原出來,導入SQL Server中,然後打開該系統,連接上還原出來的資料庫,再運行,就可以了。
7.2 系統實施過程
(1)打開PowerBuilder,新建一個工作區,命名為newspaper
(2)新建一個Application,取名newspaper,然後點擊工具欄上的DB Profile,新建一個MSS Microsoft SQL Server,填入Profile Name,伺服器名,用戶名,密碼,資料庫,如下圖,然後輸入連接資料庫的主要代碼:
open(w_welcome)
// Profile newspaper
SQLCA.DBMS = "MSS Microsoft SQL Server"
SQLCA.Database = "newspaper"
SQLCA.ServerName = "CHINA-41CD782EF"
SQLCA.LogId = "sa"
SQLCA.LogPass=""
SQLCA.AutoCommit = False
SQLCA.DBParm = ""
connect;
if sqlca.sqlcode<>0 then
messagebox("錯誤","資料庫連接錯誤,程序將關閉!",stopsign!)
return
end if
close(w_welcome)
open(w_login)

(3)製作登錄頁面w_login,在「確定」按鈕輸入如下:

「注冊」按鈕代碼:open(w_register) //打開用戶注冊頁面
「退出」按鈕代碼:close(w_login) //退出本系統
(4)製作注冊窗口w_register,在「注冊」按鈕的代碼如下:

「取消」按鈕代碼:close(w_register)
open(w_login)
(5)製作管理員主菜單w_adminview,建管理員主界面w_adminview,將該菜單放到窗口中
(6)製作用戶主菜單w_userview,建用戶主界面w_userview,將菜單放到窗口中
(7)製作管理員主菜單里的錄入報刊信息窗口w_inmagazine,錄入用戶信息窗口w_inuser,
製作數據窗口dw_magagrid,dw_magafree,dw_userfree,dw_usergrid,在數據窗口調整好外觀,添加控制項,並設定相應的動作,分別放到這兩個窗口中
這兩個窗口功能相識,在窗口中輸入:
dw_1.settransobject(sqlca)
dw_1.retrieve()
dw_2.settransobject(sqlca)
dw_2.retrieve()

(8)製作管理員主菜單中的查詢訂閱信息窗口w_searchorder,製作數據窗口dw_booksearch,將其放入窗體中,在窗口中輸入代碼:
dw_1.settransobject(sqlca)
dw_1.retrieve()
sle_1.setfocus()
在「查詢」按鈕中輸入代碼:

「預覽」按鈕的代碼:

「關閉」按鈕代碼:close(w_searchorder)
數據窗口欄位如下:

(9)製作管理員主菜單中的統計用戶訂單窗口w_statuser,統計部門訂單窗口w_statdept,統計報刊訂單窗口w_statnews:製作統計數據窗口dw_statnews,dw_statuser,dw_statdept將dw_statnews,dw_statuser,dw_statdept分別放入w_statnews, w_statuser,w_statdept中;以下僅列出按出按部門統計的代碼和界面 (按用戶、報刊統計類似,略);
按部門統計代碼:
窗口代碼:
按部門統計數據窗口:
dw_1.settransobject(sqlca)
dw_1.retrieve()
預覽鍵代碼:(與上頁預覽代碼相同)
退出:close(parent)

(10)管理員主菜單中的更改登錄在w_adminview中的代碼

(11)管理員主菜單中的退出系統在w_adminview中的代碼

(12)管理員主菜單中的資料庫備份窗口w_backup,「開始備份」按鈕的代碼如下

在「>>」按鈕帶輸入代碼:

(13)管理員主菜單中的資料庫恢復窗口w_restore,「開始恢復」按鈕的代碼如下
在「>>」按鈕帶輸入代碼:

在「開始恢復」按鈕輸入代碼:

(14)用戶主菜單的訂閱報刊窗口w_userorder
該系統中定義了一個全局變數gs_userid,其它窗口界面都可以使用該變數,並顯示用戶名,用戶登錄後,它會顯示「~~~~,歡迎使用本系統!」的歡迎界面。
窗口代碼:
dw_1.settransobject(sqlca)
dw_1.retrieve()
sle_1.setfocus()
sle_2.text=gs_userid
「清空」按鈕代碼:
sle_1.text=""
sle_3.text=""
sle_5.text=""
「退出」按鈕代碼:
close(w_userorder)
「訂閱」按鈕代碼:

(14)用戶主菜單的查詢訂單窗口w_usersearch,將訂單查找dw_booksearch放到窗口裡,在窗口中過過濾器篩選中用戶自己的訂單信息,一打開就可以看到自己的訂單信息,可列印和預覽結果

窗口代碼:

「預覽」和「退出」按鈕同上
(15)用戶主菜單的查詢訂單窗口w_userstatis,將用戶統計dw_statuser放到窗口裡,在窗口中過過濾器篩選中用戶自己的訂單信息,一打開就可以看到自己的訂單信息,可列印和預覽結果,窗口代碼如下:

用戶統計dw_statuser數據窗口如下:

「預覽」「退出」按鈕略
(16)用戶主菜單中的修改用戶信息窗口w_usermodify,打開會先顯示出你的信息,而用戶名這一欄是輸入不了的,也就是不能修改用戶名,窗口代碼如下:

「保存」按鈕代碼如下:

(17)用戶主菜單中的更改登錄和退出系統的代碼和管理員的一樣,這里就省略了。
7.3系統使用結果

打開本系統,首先彈出歡迎界面,通常一閃而過,然後到了登錄界面,點擊「注冊」

按確定後,彈出「恭喜,您已注冊成功!」的對話框。如果這時刷新服務管理器,打開SQL Server企業管理器,打開該資料庫的用戶表,就可看到剛才注冊的用戶已經在表中了

然後返回到登陸頁面,輸入剛才注冊到的用戶名和密碼maishning,123456

登錄後,彈出一個窗口,有供用戶使用的菜單,界面顯示「~~~~,歡迎使用本系統」

選擇「訂閱」菜單,在這個訂閱界面,用戶可以瀏覽到所有的報刊信息,要訂閱報刊時,用戶不需輸入用戶名與密碼,只需輸入您要訂閱的報刊代號(該報刊代號必須是報刊表中存在的),訂閱份數(必須是小於8的整數才有效),然後選擇需要訂閱的月數(一月、一季、半年或一年)然後點擊「訂閱」按鈕

訂閱成功後,系統彈出「恭喜!你已成功訂閱該報刊,總金額是~~~~」確定後會顯示出您所訂閱的總額是多少元,按「清空」按鈕後可以訂閱其它報刊(同樣的報刊不可重復訂閱)

再訂閱其它報刊,然後按「退出」按鈕,來到用戶主菜單然後選擇「查詢」菜單,這個數據窗口經過過濾,一打開就直接顯示該用戶過訂閱的訂單,可以進行預覽和列印。

由於許可權的限制,「統計」菜單中的也是只能統計自己訂單信息的數據

在「退訂」報刊菜單中,可以查看自己的訂單,單擊「退訂」然後「保存」即可完成退訂
在「修改」信息菜單中,用戶名也是不可輸入的文本框,即不可修改用戶名,其它信息可以修改,保存後它會自動添加到資料庫中

選擇菜單上的「注銷」,可以用不同的身份進入系統,確定後回到登錄界面

以管理員的身份登錄,用戶名111,密碼111,按登錄按鍵,可看到管理員菜單

選擇菜單欄中的錄入->錄入報刊信息,管理員可以大致瀏覽所有報刊信息,在上面的數據窗口可以查看上一頁和下一頁的具體內容,並且可以對其進行添加,刪除、修改、保存等操作。

錄入用戶信息頁面,基本相似

選擇菜單欄中的「查詢」->「訂單信息」,管理員擁有的許可權可以看到所有的訂單信息

管理員也可以根據需要分別按部門、按用戶、按報刊查詢,比如,要查詢msishning用戶,在文本框中輸入關鍵字,選擇單選按鈕中的「按部門號」,點擊「查詢」,結果如下
可對全部訂單或查詢出來的訂單進行預覽和列印,方便使用

菜單欄中的「統計」菜單有三個子菜單,管理員可以分別統計用戶訂單信息、部門訂單信息和報刊訂單信息, 直接選擇就可看到統計結果,比如選擇「統計用戶訂單信息」

可將統計出來的結果進行預覽和列印,方便使用,其它兩個統計功能相似,略

主菜單中的系統維護->資料庫備份,選擇備份的位置,然後「開始備份」

主菜單中的系統維護->資料庫恢復,選擇之前備份的文件,輸入路徑和資料庫名,然後「開始恢復」

7.4系統評價:

2. 資料庫課程設計心得體會範文

通過資料庫課程設計的完成,我們從中獲得了不少的感慨,通過對所學知識的體會,能夠明顯感覺到自己比以往進步了不少。以下是由我為大家整理的「資料庫課程設計心得體會範文」,僅供參考,歡迎大家閱讀。

資料庫課程設計心得體會範文(一)

在我看來,資料庫課程設計主要的目標是利用課程中學到的資料庫知識和技術較好的開發設計出資料庫應用系統,去解決各行各業信息化處理的要求。通過這次的課程設計,可以鞏固我們對資料庫基本原理和基礎理論的理解,掌握資料庫應用系統設計開發的基本方法,進一步提高我們綜合運用所學知識的能力。

當搏棚我們這組決定做大學生就業咨詢系統時,我們並沒有著手寫程序。而是大家一起商量這個系統概述、系統目標、系統需求、業務流程分析、數據流程分析和數據詞典。當這些都准備好了之後,我們進行模塊的分工。每個人都有自己的模塊設計,而且寫出來的代碼要求可以實現相應模塊的功能,得到理想的效果。當每個人都把自己的分工做好了,最後會由一個人把這些全部組合搭建在一起。我們使用的是html和php相互嵌套使用,當一個系統做好了之後,我會好好地把程序都看一遍,理會其中的奧秘。

我所負責的是資料庫的備份和還原還有一些界面的實現。還記得自己剛接觸html的時候,覺得很感興趣,所以有一段時間幾乎到了痴迷的程度。然而php是我剛接觸不久的一種編程語言。不過覺得它的功能真的很強大,可以開發出很多大型的系統。但是在做備份和還原的時候,要考慮的東西還是很多的。當我遇到錯誤的時候,感到很受打擊。值得欣慰的是,在同學的幫助和大量參考書的查閱下,我把自己的模塊做好了。這就是我收獲最大的地方。而且,我明白了遇到困難永不放棄的重要性,我知道了團隊合作的重要性,我領悟了只有堅持不懈才會取得勝利。

知識的獲得是無止境的,只要你想基渣則學,只要你行動,沒有什麼會難倒我們的。回首這一個多星期的課程設計,我很欣慰。因為我有了動力,有了勇氣。謝謝老師對我們的不懈幫助,謝謝學校給了我們這一次實踐的機會,也謝謝組員們的關懷。這些美好的回憶美好的東西將永遠伴隨著我。

資料庫課程設計心得體會範文(二)

本次課程設計,使我對《數據結構》這門課程有了更深入理解。《數據結構》是一門實踐性較強課程,為了學好這門課程,必須在掌握理論知識同時,加強上機實踐。

我課程設計題目是線索二叉樹運算。剛開始做這個程序時候,感到完全無從下手,甚至讓我覺得完成這次程序設計根本就是不可能,於是開始查閱各種資料以及參考文獻,之後便開始著手寫程序,寫完運行時有很多問題。特別是實現線索二叉樹刪除運算時很多情況沒有考慮周全,經常運行出現錯誤,但通過同學間幫助最終基本解決問題。

在本課程設計中,我明白了理論與實際應用相結合重要性,並提高了自己組織數據及編寫大型程序能力。培養了基本、良好程序設計技能以及合作能力。這次課程設計同樣提高了我綜合運用所學知識能力。並對VC有了更深入了解。《數據結構》是一門實踐性很強課程,上機實習是對學生全面綜合素質進行訓練一種最基本方法,是與課梁衡堂聽講、自學和練習相輔相成、必不可少一個教學環節。

上機實習一方面能使書本上知識變「活」,起到深化理解和靈活掌握教學內容目;另一方面,上機實習是對學生軟體設計綜合能力訓練,包括問題分析,總體結構設計,程序設計基本技能和技巧訓練。此外,還有更重要一點是:機器是比任何教師更嚴厲檢查者。因此,在「數據結構」學習過程中,必須嚴格按照老師要求,主動地、積極地、認真地做好每一個實驗,以不斷提高自己編程能力與專業素質。

通過這段時間課程設計,我認識到數據結構是一門比較難課程。需要多花時間上機練習。這次程序訓練培養了我實際分析問題、編程和動手能力,使我掌握了程序設計基本技能,提高了我適應實際,實踐編程能力。總來說,這次課程設計讓我獲益匪淺,對數據結構也有了進一步理解和認識。

資料庫課程設計心得體會範文(三)

一周的課程設計結束了,在這次的課程設計中不僅檢驗了我所學習的知識,也培養了我如何去把握一件事情,如何去做一件事情,又如何完成一件事情的方法和技巧。在設計過程中,和同學們相互探討,相互學習,相互監督。我學會了運籌帷幄,學會了寬容,學會了理解,也學會了做人與處世,這次課程設計對我來說受益良多。

課程設計是我們專業課程知識綜合應用的實踐訓練,著是我們邁向社會,從事職業工作前一個必不少的過程。「千里之行始於足下」,通過這次課程設計,我深深體會到這句千古名言的真正含義。我今天認真的進行課程設計,學會腳踏實地邁開這一步,就是為明天能穩健地在社會大潮中奔跑打下堅實的基礎。我這次設計的科目是數據結。

數據結構,是一門研究非數值計算的程序設計問題中計算機的操作對象(數據元素)以及它們之間的關系和運算等的學科,而且確保經過這些運算後所得到的新結構仍然是原來的結構類型。「數據結構」在計算機科學中是一門綜合性的專業基礎課。數據結構是介於數學、計算機硬體和計算機軟體三者之間的一門核心課程。數據結構這一門課的內容不僅是一般程序設計(特別是非數值性程序設計)的基礎,而且是設計和實現編譯程序、操作系統、資料庫系統及其他系統程序的重要基礎。通過這次模具設計,我在多方面都有所提高。

在界面設置中使用函數調用while。其中文本顯示顏色和背景顏色都可以任意按照自己的喜好,任意改變,但改變的時候必須採用標准英文大寫,同時在製作顯示菜單的窗口,大小根據菜單條數設計。最後採用printf輸出程序設計界面。

這次的程序軟體基本上運行成功,可以簡單的建立鏈式循環鏈表,並進行輸出,及循環語句的運用和選擇語句的控制。由於時間和知識上的限制,使得程序規模相對較小,即功能還不很全面,應用也不很普遍。原來c語言可是涉及很多知識,而不是枯燥無聊的簡單的代碼部分而已,利用C語言方面的知識,我們可以設計出更完善的軟體。

通過這次的課程設計,更是讓我深刻認識到自己在學習中的不足,同時也找到了克服這些不足的方法,這也是一筆很大的資源。在以後的時間中,我們應該利用更多的時間去上機實驗,加強自學的能力,多編寫程序,相信不久後我們的編程能力都會有很大的提高能設計出更多的更有創新的作品。

3. 資料庫sql 的課程設計怎麼做,要借哪些書看,求大神指教

  • IT行業,資料庫確實是一門相當重要的課程。但是在大學裡面,對待資料庫原理及應用這么課程以及其課程設計的重視程度就相差很大了,各個學校要求也不一樣。如果是要學好,那確實要下工夫;如果只是完成課程設計,交差了事,其實相當簡單。

  • 既然是課程設計,也算是個小小的項目,既然是項目,也就離不開需求分析、資料庫設計、部署實現等環節。當然,這個小小的項目只需要前面的部分:需求和資料庫設計,資料庫設計是重點。

  • 需求分析就不用多說,和所有其他項目一樣,無非就是用戶需求,功能需求,系統需求等,找任何一本關於需求分析的書都是可以,除了那些個空話之外,更多的是要根據設計需要進行分析。

  • 資料庫設計就比較復雜一點,首先得把資料庫原理搞清楚,比如:符合什麼樣的範式,怎麼畫ER圖,如何理解用例圖。在設計資料庫之前,有一系列的分析要做:面向對象分析,用例分析,類和對象分析等等。分析到位是資料庫設計成功的重要保障。分析完成之後才是設計,比如:邏輯結構設計,關系模式設計,存取方法設計,存儲結構設計,數據完整性設計,參考完整性設計,Check約束,Default約束,觸發器設計,視圖設計,存儲過程設計,許可權設計等。這些都完成了,最後一步才是寫SQL代碼實現這些設計,創建資料庫及相關的數據表,關聯,視圖,觸發器,存儲過程等一些列的看得見的資料庫參數。

  • 上面說的比較理論,也比較籠統。我想我可以用一個簡單例子告訴你我要表達的意思。例子很簡單,其中很多地方都不是太好,不過或許可以給你一個直觀的思路。

資料庫應用課程設計報告書


網上超市管理系統

成 績:

學 號:

姓 名:

指導教師:


20 年 月 日


目錄

任務書......................................... (3)

1. 需求調查、分析................................. (4)

1.1.企業介紹.................................... (4)

1.2.需求調查及分析.............................. (5)

2. 面向對象分析和設計............................. (7)

2.1. 用例分析 (7)

2.2.類和對象設計 (12)

3. 邏輯結構設計.................................. (15)

3.1. 類和對象向關系模式轉換............................................ (15)

3.2. 關系模式優化 (16)

4. 資料庫物理結構設計............................ (16)

4.1. 存取方法設計 (16)

4.2. 存儲結構設計 (17)

5. 資料庫完整性設計.............................. (17)

5.1. 主鍵及唯一性索引 (17)

5.2. 參照完整性設計 (18)

5.3. Check約束 (18)

5.4. Default約束 (18)

5.5. 觸發器設計 (19)

6. 資料庫視圖設計................................ (19)

7. 資料庫存儲過程設計............................ (20)

8. 許可權設計...................................... (20)

9. 總結.......................................... (21)

4. 急求一份資料庫課程設計

合肥經濟技術職業學院
電子信息系

課程設計報告

課程:資料庫課程設計

題目:學生管理系統

班級:09計 用

成員:

指導老師:
日期:

目錄
第一章 前言 3
1.1 課題簡介 3
1.2 設計目的 3
1.3 需求分析 4
第二章 資料庫實例的分析及應用 4
2.1 題目和E-R圖 4
2.2 資料庫的實現 5
2.3 資料庫結構屬性 8
2.3.1主鍵(主鍵約束PRIMARYKEY;索引設置) 8
2.3.2資料庫的默認值和規則 13
2.3.3 視圖和存儲過程 15
2.3.4 觸發器 17
第三章 總結報告 19
參考文獻 19

第一章 前言
1.1 課題簡介
資料庫技術是計算機科學技術發展最快,應用最為廣泛的技術之一。其在計算機設計,人工智慧,電子商務,企業管理,科學計算等諸多領域均得到了廣泛的應用,已經成為計算機信息系統和應用的核心技術和重要基礎。
本文主要介紹學生成績管理系統的資料庫設計,從需求分析到資料庫的運行與維護都進行詳細的敘述。本系統是利用SQL開發出來的。通過SQL建立學生成績管理系統,大大方便和簡化了數據的查詢和處理,管理員可以通過SQL語言對表內數據進行添加,刪除,修改,查詢等操作,還可以建立多用戶,對其使用許可權進行分配和回收。隨著數據處理的不斷進步和計算機網路的迅速發展,使資料庫應用系統不僅在功能而且在結構上都有了深刻的變化,而且運用在生活的每一個方面。通過學習關系代數,關系演算,函數依賴,關系模式分解,關系模式的規范化讓我們建立了扎實的關系資料庫理論基礎。而在掌握基本理論的基礎上掌握關系資料庫的設計方法,掌握現代信息系統的開發方法也顯得尤為必要。目前在關系資料庫中用得最多的SQL資料庫,開發資料庫的語言工具多數用C++.。所以對於計算機專業的學生來說掌握資料庫應用的基本技術,熟悉編程語言與SQL資料庫的結合運用是我們計算機專業學生之必備本領。本次課程設計是以學生信息管理系統為模擬模型,運用C++編程語言結合SQL資料庫所開發系統。
1.2 設計目的
隨著學生數量的日益增多,學校對學生的管理要求也越來越高,為了使信息技術與學生信息更好的結合在一起以及使學生成績的管理更加系統化,數字化,因此我們設計了該學生信息管理系統。運用基於E-R模型的資料庫設計方法和關系規范化理論做指導完成從系統的分析到設計直至系統的最終實現,開發學生成績管理系統,完成學生成績管理系統的全部功能。首先做好需求分析,並完成數據流圖,其次做概念分析,利用實體聯系的方法將需求分析的用戶需求抽象為信息結構,得到E-R圖,然後就是邏輯結構設計,將E-R圖轉換為計算機系統所支持的邏輯模型。最後利用SQL完成具體的實例。
1.3 需求分析
1、問題的提出:為了高效率的完成學生的管理,決定開發學生管理系統。
2、需完成的功能:
(1)能錄入、修改、查詢、輸出學生的檔案信息,這些信息包括學生的成績、課程、個人信息等。
(2)觸發器,索引,約束,規則,默認值,,視圖,存儲過程的建立及使用。

第二章 資料庫實例的分析及應用
2.1 題目和E-R圖
隨著學生數量的日益增多,學校對學生的管理要求也越來越高,為了使信息技術與學生信息更好的結合在一起以及使學生成績的管理更加系統化,數字化,因此我們設計了該學生信息管理系統。以下是次學生信息管理系統的E-R圖,進一步詳細的說明資料庫的結構以及用途。實體和屬性的定義:
學生表(學生學號,姓名,班級編號)
班級表(班級編號,班級名稱,系部編號)
系部表(系部編號,系部名)
教師表(教師名,課程編號,系部編號)
課程表(課程編號,課程名,學分,教師,系部號)
下面是E-R圖,用來進一步說明資料庫的作用和用途:

2.2 資料庫的實現
運用SQL Server 2000數據設計表格的物理結構如下:

班級表:

學生表:

系部表:

課程表:

教師表:

各表關系圖:

設計表格的具體填入數據是:
班級表:

學生表:

教師表:

系部表:

課程表:

2.3 資料庫結構屬性
2.3.1主鍵(主鍵約束PRIMARYKEY;索引設置)
1.索引與書目錄相似,可以快速找到指定內容。索引通過記錄表中的關鍵值來指向表中的記錄,這樣資料庫就不用掃描而能定位到相關的記錄。以下是對各表進行索引的實現。
學生表的設置如圖:

班級表的設計如下:

教師表的設計如下:

課程表的設計如下:

系部表的設置如下:

2.約束定義了關於允許什麼數據進入資料庫的規則,是分配給表或表中某列的一個屬性。使用約束的目的在於防止列中出現非法的數據,可以自動維護資料庫的數據完整性。下面是用企業管理器對class表實現的主鍵約束:

2.3.2資料庫的默認值和規則
1.使用默認可以實現當用戶在向數據表中插入新紀錄時,如果沒有給出某列的輸入值,則由SQL Server自動為該列輸入默認值。下面是對class表進行實現默認的功能:

實現默認值:

2.規則也是實現數據完整性的方法之一,作用與CHECK約束類似,在向表的某列插入或更新數據時,用它來限制輸入值的取值范圍。下面我們運用對Course表進行規則的實現:

2.3.3 視圖和存儲過程
1.視圖的作用相當於一個虛擬表,是用戶查看資料庫表中數據的一種方式使用戶通過他能夠以需要的方式瀏覽表中的部分或全部數據,而數據的物理存放位置仍然在資料庫的表中。我們通過在企業管理器中創建視圖管理視圖應用視圖,更加形象具體的說明了視圖的作用。
添加表格到視圖:

添加數據並運行:

運行結果,具體視圖呈現:

2.存儲過程是一組編譯在單個執行計劃中的Transact-SQL語句,它將一些固定的操作集中起來交給SQL-Server資料庫伺服器完成,以實現某個任務。首先我們在查詢管理器中創建存儲過程:

並且執行存儲過程:

在企業管理器中也可以體現出存儲過程:

2.3.4 觸發器
觸發器的作用是強制執行業務規則。SQL Server主要提供了兩種機制來強制業務規則和數據完整性:約束和觸發器。觸發器在指定的表中數據發生變化時被調用以響應INSERT、UPDATE或DELETE事件。觸發器可以查詢其他表,並可以包含復雜的語句。SQL Server將觸發器和觸發它的語句作為可在觸發器內回滾的單個事物對待,如果檢測到嚴重錯誤,則整個事物即自動回滾。首先我們在查詢管理器中新建觸發器:

新建觸發器:

管理觸發器:

第三章 總結報告
這次的課程設計真的做起來困難重重,深刻體會到做一個軟體,裡面需要的很多知識我們沒有接觸過,去圖書館找書的時候發現,我們學的僅僅是皮毛,還有很多東西需要我們去發掘,就算是借一本書看完它,我們還是會發現還有很多知識沒有吃透,這需要我們不斷的實踐,不斷地自學習,不斷地發現問題去思考問題。
經過不斷地測試,不斷地改進,其中還是發現了不少問題,第一次做這些工作,沒有任何經驗,甚至無從下手,還是很謝謝老師和同學的幫忙,從中也學到了一些代碼的寫法,為什麼要這樣寫,通過和同學的討論,找到一些書本上沒有的方法,如何數據綁定等等,怎樣從資料庫中將數據提取出來放到一個文本框或者標簽內,這些東西是組成界面的東西,雖然小,但是可以體現整個軟體的水平,其實並不需要建多少資料庫的表,寫多少復雜的存儲過程,是不是用了資料庫函數,觸發器等等,但是至少要弄明白這些東西如果操作,清晰思路才能將功能分清晰。
經過一段時間的學習與實踐,學生信息管理系統基本上開發好了。該系統具備了:添加、修改、刪除、瀏覽、查詢、輸出日程信息,實現了根據用戶需求查看日程等功能。作為一個個人日程管理系統,本系統所提供的功能的確太少了一些,僅僅只實現了一些基本的功能,有很多地方還有待擴展和改良。
人如果沒有自信,沒有目標,沒有信心就不可能把事情做好,當其他人都在迷茫的時候,自己一定要堅信目標,大學畢業出去即是面臨找工作,從學習這個專業,到以後做這方面的工作都需要不斷地去學習去實踐,這次實踐可以給我們敲一個警鍾,我們面臨畢業,面臨擇業,需要這些實踐經驗,在困難面前要勇於嘗試,這是這次課程設計給我的最大感想。在此特別感謝老師的辛苦指導和教育!
參考文獻
黃維通編《SQL Server2000 簡明教程》
徐人鳳 曾建華編《SQL Server2000資料庫及應用》

5. 資料庫課程設計

一、通過ODBC DSN建立連接 運用ODBC數據源,首先必須在控制面板的ODBC中設置數據源,然後再編寫腳本和資料庫源建立連接。 1、創建 ODBC DSN 通過在 Windows 的"開始"菜單打開"控制面板",您可以創建基於 DSN 的文件。雙擊"ODBC"圖標,然後選擇"系統 DSN"屬性頁,單擊"添加",選擇資料庫驅動程序,然後單擊"下一步"。按照後面的指示配置適用於您的資料庫軟體的 DSN。常用的資料庫軟體有Microsoft Access和SQL Server等,這里以SQL Server 資料庫為例。 配置 SQL Server 資料庫系統 DSN:注意如果資料庫駐留在遠程伺服器上,請與伺服器管理員聯系,獲取附加的配置信息;下面的過程使用 SQL Server 的 ODBC 默認的設置,它可能不適用於您的硬體配置。在"創建新數據源"對話框中,從列表框中選擇"SQL Server",然後單擊"下一步"。鍵入 DSN 文件的名稱,然後單擊"下一步"。單擊"完成"創建數據源。鍵入運行 SQL 服務程序的伺服器的名稱、登錄 ID 和密碼。在"創建 SQL Server 的新數據源"對話框中,在"伺服器"列表框中鍵入包含 SQL Server 資料庫的伺服器的名稱,然後單擊"下一步"。選擇驗證登錄 ID 的方式。如果要選擇 SQL 伺服器驗證,請輸入一個登錄 ID 和密碼,然後單擊"下一步"。在"創建 SQL Server 的新數據源"對話框中,設置默認資料庫、存儲過程設置的驅動程序和 ANSI 標識,然後單擊"下一步"。(要獲取詳細信息,請單擊"幫助"。)在對話框(同樣名為"創建 SQL Server 的新數據源")中,選擇一種字元轉換方法,然後單擊"下一步"。(詳細信息,請單擊"幫助"。)在下一個對話框(同樣名為"創建 SQL Server 的新數據源")中,選擇登錄設置。 注意典型情況下,您只能使用日誌來調試資料庫訪問問題。 在"ODBC Microsoft SQL Server 安裝程序"對話框中,單擊"測試數據源"。如果 DSN 正確創建,"測試結果"對話框將指出測試成功完成。 首先,流程是一切的根本。所謂軟體工程,當初上課的時候根本無法體會其意義。現在經過一個個爛系統的熏陶之後,終於漸漸明白,流程不是用來說說而已的,一個項目真的不是那麼容易就可以掌控的,進度控制是項目順利進行的基礎。沒有大局觀,面對問題和變更就會不知所措了。 其次,架構是重要的,比你想像的還要重要!往往我們自以為明白這一點,但實際做起來卻總是不知不覺地偏離。上次做的宿舍管理系統,自以為做得很好,現在知道了,當時寫頁面那麼痛苦就是因為我們用的是「JSP + JavaBean」,連一個servlet都沒寫,把"C-V"部分全都推在頁面上了。。。這次用了Struts,雖然也沒用用到深層的東西,但至少明白了何為MVC,並切身感受到了Struts帶來的方便。 再次,我們原來只算是高級勞工罷了。說得很好聽,搞技術的,其實弄懂弄好技術之後,還不一樣是一堆一堆的體力勞動。所以有時候我在連續熬夜趕工調試代碼的時候會有種厭倦感,有時甚至真的做到想吐!因為做來做去都是那些東西,就像A片看多了也會乏味一樣吧。 最後,實踐比一切空談和理論更能學到東西。注意,這里不是說理論的基礎的東西就沒用。看『Java How To Program』那麼久,感覺真的很上癮。是的,沒錯,上癮!弄清了很多概念,解答了很多一直讓人困惑的問題。但是!!一個項目做下來,你就會覺得跟項目過程中學到的東西相比,平時那些不過都是理論都是皮毛,一旦不用很快就忘記,始終要在實踐中才會發現問題才會努力去解決才能成長。不過沒看完的『Java How To Program』還是會繼續看的,始終認為基礎便是這樣的東西,枯燥(JHTP至少比『Thinking In Java』好多了),看似簡單,卻是你走上高處的基礎。

6. 資料庫課程設計實例

資料庫課程設計

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

7. 資料庫課程設計(SQL Server 2000)

網路即時通信系統是為用戶開發研製的,用戶是系統的最終使用者和評價者,所以在網路通信系統的開發設計的過程中,我們樹立了從用戶的尋求出發,面向用戶,一切為了用戶的觀念,在分析與設計系統的前期,為了保證系統的功能的完善多次尋求周圍同學和老師的意見,了解他們的要求,依照功能完善,界面美觀,操作簡單的原則進行設計 。
嚴格按階段進行
系統的開發設計是一項較大的工程,所以應該將整個系統的開發設計過程劃分為若干階段,相應的階段又要分為若干個不同的步驟,每個階段和步驟都要有明確的工作任務和目標。這種有序的組織安排,條例清楚、層次分明,便於計劃的制定和控制,並且為後續工作的進行奠定了堅實的基礎,提高了工作效率和質量。
採用系統的觀點處理
在系統分析階段,在對原系統進行全面調查和分析的基礎上,構造系統的最佳邏輯模型,使用戶對將來完整系統的輪廓有個初步的了解和認識,以便及時和用戶進行交流和探討,不斷提高系統的完善性。在此基礎上進行系統的物理實現和設計,切實完成邏輯模型的具體功能。邏輯設計和物理實現二者是相輔相成、密不可分的,這樣使系統的設計更加穩妥合理。
整個系統的設計主要採用快速原形法
快速原形法是信息系統設計的一個重要方法。它是根據用戶提出的需求,由用戶和開發者共同確定系統的基本要求和主要功能,並在一個較短的時間內建立一個實驗性的、簡單的信息系統模型,通過用戶不斷提出的意見和建議,對模型進行不斷的修改和完善,直到用戶比較滿意為止,以便形成一個相對穩定、較為理想的管理信息系統。該方法的主要優點。
1.脈絡清楚,所有問題都圍繞一個模型展開,使彼此之間聯系緊密。
2.有助於發現用戶需求,通過對原形和用戶接觸,能夠啟發開發人員去挖掘問題,從而不斷的修正、完善,最終得到一個理想的系統。
3.系統開發效率高,此方法的開發周期短、使用靈活、容易修改,這對於管理體制不夠穩定的系統更加適合。
4.系統的可擴展性好,由於此方法是在原型應用中不斷發展完善和修改的,所以有較強的擴展性。

在進行代碼設計時,遵循了以下原則。
唯一性:在本系統中,每一個代碼都和系統中的每一個對象唯一確定。
標准性:主要體現在對程序文件名命名和對數據文件命名的標准化上,遵循簡單扼要,方便適用的原則。一目瞭然,無重復現象。為了系統維護人員便於進行系統維護,使用了統一的標准。
合理性:系統中代碼設計與編碼對象的分類相適應,以使代碼對編碼對象的分類據有標志作用。
簡單性:在設計過程中採用Code-Behind代碼分離,使資料庫操作代碼和前端調用代碼分離,頁面修改容易。
適應性:在代碼設計過程中,代碼反映了編碼對象的特點,便於識別和記憶,使系統維護人員容易了解和掌握,便於進行維護工作。
系統總體功能結構
網路通信系統包含以下主要功能。
用戶注冊;用戶登錄;
查找好友;查看好友資料;
添加好友;
刪除好友;
發送消息;
發送文件.
資料庫表主要用來存放用戶的注冊信息和用戶的好友資料,可利用兩張資料庫表來 存放用戶信息和用戶好友的資料。包括用戶的號碼,昵稱,密碼,在線與否,ip地址,資料,頭像號,性別,E-mail和籍貫等信息。其中,用戶昵稱和密碼是必需的欄位;在線與否是由系統自動設置的;其餘的信息是可選的欄位。
課題整體以JAVA為平台,採用Eclipse開發工具,並使用SQL Server 2000管理資料庫數據開發而成的基於Socket的集中式網路通信系統,系統採用客戶機/伺服器(C/S)的模式設計,是一個三層C/S結構,資料庫伺服器、應用程序伺服器端 、應用程序客戶端。系統採用C/S結構,可以將任務合理分配到客戶機端和伺服器端 ,從而降低了系統的通信開銷。
客戶層。
客戶層是應用程序的用戶介面部分,它擔負著用戶與應用間的對話功能,用於檢查用戶的輸入數據,顯示應用的輸出數據,為了直觀的進行操作,客戶層需要使用圖形用戶介面,若聊天用戶變更,系統只需改寫顯示控制和數據檢查程序即可,而不會影響其他兩層。
服務層。(功能層)
服務層相當於應用的本體,它是將具體的業務處理邏輯編入程序中。在應用設計中,必須避免在表示層和功能層之間進行多次的數據交換,這就需要盡可能進行一次性的業務處理達到優化整體設計的目的。
數據層
數據層是DBMS,本系統使用了Microsoft 公司的SQL Ssever2000資料庫伺服器來管理數據。SQL Ssever2000能迅速的執行大量數據的更新和檢索,因此,從功能層傳送到數
據層的要求一般都使用SQL語言。

這是我畢業論文一部分 做的是聊天系統 給你參考 無所謂給不給分~! 也不可能全給你 帶代碼有20兆

8. 數據課程設計心得體會

課程設計既可以指為掌握某一課程內容所進行的設計,也要指對某一門課程教學策劃的研究活動,下面是為大家搜集整理的數據課程設計心得體會,歡迎閱讀。

數據課程設計心得體會(一)

在我看來,資料庫課程設計主要的目標是利用課程中學到的資料庫知識和技術較好的開發設計出資料庫應用系統,去解決各行各業信息化處理的要求。通過這次的課程設計,可以鞏固我們對資料庫基本原理和基礎理論的理解,掌握資料庫應用系統設計開發的基本方法,進一步提高我們綜合運用所學知識的能力。

當我們這組決定做大學生就業咨詢系統時,我們並沒有著手寫程序。而是大家一起商量這個系統概述、系統目標、系統需求、業務流程分析、數據流程分析和數據詞典。當這些都准備好了之後,我們進行模塊的分工。每個人都有自己的模塊設計,而且寫出來的代碼要求可以實現相應模塊的功能,得到理想的效果。當每個人都把自己的分工做好了,最後會由一個人把這些全部組合搭建在一起。我們使用的是Html和php相互嵌套使用,當一個系統做好了之後,我會好好地把程序都看一遍,理會其中的奧秘。

知識的獲得是無止境的,只要你想學,只要你行動,沒有什麼會難倒我們的。回首這一個多星期的課程設計,我很欣慰。因為我有了動力,有了勇氣。謝謝老師對我們的不懈幫助,謝謝學校給了我們這一次實踐的機會,也謝謝組員們的關懷。這些美好的回憶美好的東西將永遠伴隨著我。

數據課程設計心得體會(二)

資料庫課程設計大賽的塵囂漸漸遠去,懷著對這次大賽的些許不舍,懷著對當初課程設計開始時候的豪情萬丈的決心的留戀,懷著通過這次課程設計積累的信心與鬥志,我開始寫這篇文章,賀老薯為自己的足跡留下哪怕是微不足道但是對自己彌足珍貴的痕跡並期望與大家共勉。

首先,讓我的記憶追溯到大二暑假,在老含李大的指引下(老大勸我學ASP(ASP培訓 ).net),我接觸到microsoft 公司的.net產品。那個時候我已經學過vc和asp,因為windows程序設計實驗的課的關系,接觸過VB(VB培訓 ),但是沒有專門去學他,因為習慣了c++裡面的class,int,覺得vb的sub,var 看著就不是很順心。我是一個好奇心很強的人,突然看到了一個號稱“.net是用於創建下一代應用程序的理想而又現實的開發工具”,而且主推c#語言,由於對c語言的一貫好感,我幾乎是立刻對他產生了興趣。我就開始了對c#的學習,任何語言都不是孤立存在的,所以數據交互是很重要的,暑假的時候我把我們這學期的課本資料庫系統概論看了一遍。我記得以前用c語言編程的時候,數據是在內存中申請空間,譬如使用數組等等。很耗費內存空間。這個時候就是資料庫站出來的時候啦,於是我又裝上了sql server2000,以前學asp的時候用的是access,那個時候只是照著人家做,理論是什麼也不是很清楚。

開發的時候我想過用什麼架構,c/s模式?模式有很多,怎麼選擇?我就上網搜索現在最流行的架構是什麼。結果搜到了mvc架構,就是你啦。我決定用這個架構,不會,沒關系,咱學。just do it!前期工作準備好後,那麼我就得把我暑假學的.net加以實踐。這個時候我更加深入的了解了利用ado.net操縱資料庫的知識。並且對資料庫裡面的存儲過程有了比較深入的了解。經過大概2個多星期的奮斗,我完成了我的資料庫課程設計--基於.net數據集的圖書館管理系統。並最後非常榮幸的獲得了大賽的一等獎以及以及新技術應用獎。

與其臨淵羨魚,不如退而結網。這次資料庫課程設計給我的最大的印象就是如果自己有了興趣,就動手去做,困難在你的勇氣和毅力下是抬不了頭的。從做這個資料庫開始無論遇到什麼困難,我都沒有一絲的放棄的念頭。出於對知識的渴望,出於對新技術的好奇,出於對一切未知的求知。我完成了這次資料庫課程設計,不過這只是我學習路上的驛站,未來十年.net的核心技術就是xml[至少微軟是這么宣傳的],我會繼續學習它禪者,包括jave公司的j2ee我也很想試試,語言本來就是相通的,just do it!語言並不重要畢竟它僅僅是工具,用好一個工具並不是一件值得為外人道的事情,主要是了解學習思想。古語說的好:學無止境啊。

實際上從學習的經歷來看,我們接觸的知識體系都是屬於比較老或比較傳統的,與現在發展迅速的IT行業相比很多情況已不再適用,尤其是當開源模式逐漸走近開發者後更是如此。雖然是一個資料庫課程設計,由於本人在選擇項目的時候是本著對自己有實際應用價值的角度考慮的,所以其中也涉及到一些資料庫以外的設計。總而言之,這次資料庫設計心得體會不能用語言完全表達。

數據課程設計心得體會(三)

本次課程設計,使我對《數據結構》這門課程有了更深入的理解。《數據結構》是一門實踐性較強的課程,為了學好這門課程,必須在掌握理論知識的同時,加強上機實踐。

我的課程設計題目是線索二叉樹的運算。剛開始做這個程序的時候,感到完全無從下手,甚至讓我覺得完成這次程序設計根本就是不可能的,於是開始查閱各種資料以及參考文獻,之後便開始著手寫程序,寫完運行時有很多問題。特別是實現線索二叉樹的刪除運算時很多情況沒有考慮周全,經常運行出現錯誤,但通過同學間的幫助最終基本解決問題。

在本課程設計中,我明白了理論與實際應用相結合的重要性,並提高了自己組織數據及編寫大型程序的能力。培養了基本的、良好的程序設計技能以及合作能力。這次課程設計同樣提高了我的綜合運用所學知識的能力。並對VC有了更深入的了解。《數據結構》是一門實踐性很強的課程,上機實習是對學生全面綜合素質進行訓練的一種最基本的方法,是與課堂聽講、自學和練習相輔相成的、必不可少的一個教學環節。上機實習一方面能使書本上的知識變“活”,起到深化理解和靈活掌握教學內容的目的;另一方面,上機實習是對學生軟體設計的綜合能力的訓練,包括問題分析,總體結構設計,程序設計基本技能和技巧的訓練。此外,還有更重要的一點是:機器是比任何教師更嚴厲的檢查者。因此,在“數據結構”的學習過程中,必須嚴格按照老師的要求,主動地、積極地、認真地做好每一個實驗,以不斷提高自己的編程能力與專業素質。

通過這段時間的課程設計,我認識到數據結構是一門比較難的課程。需要多花時間上機練習。這次的程序訓練培養了我實際分析問題、編程和動手能力,使我掌握了程序設計的基本技能,提高了我適應實際,實踐編程的能力。總的來說,這次課程設計讓我獲益匪淺,對數據結構也有了進一步的理解和認識。

數據課程設計心得體會(四)

兩個星期的時間非常快就過去了,這兩個星期不敢說自己有多大的進步,獲得了多少知識,但起碼是了解了項目開發的部分過程。雖說上過資料庫上過管理信息系統等相關的課程,但是沒有親身經歷過相關的設計工作細節。這次實習證實提供了一個很好的機會。

通過這次課程設計發現這其中需要的很多知識我們沒有接觸過,去圖書館查資料的時候發現我們前邊所學到的僅僅是皮毛,還有很多需要我們掌握的東西我們根本不知道。同時也發現有很多已經學過的東西我們沒有理解到位,不能靈活運用於實際,不能很好的用來解決問題,這就需要我們不斷的大量的實踐,通過不斷的自學,不斷地發現問題,思考問題,進而解決問題。在這個過程中我們將深刻理解所學知識,同時也可以學到不少很實用的東西。

從各種文檔的閱讀到開始的需求分析、概念結構設計、邏輯結構設計、物理結構設計。親身體驗了一回系統的設計開發過程。很多東西書上寫的很清楚,貌似看著也很簡單,思路非常清晰。但真正需要自己想辦法去設計一個系統的時候才發現其中的難度。經常做到後面突然就發現自己一開始的設計有問題,然後又回去翻工,在各種反復中不斷完善自己的想法。

我想有這樣的問題不止我一個,事後想想是一開始著手做的時候下手過於輕快,或者說是根本不了解自己要做的這個系統是給誰用的。因為沒有事先做過仔細的用戶調查,不知道整個業務的流程,也不知道用戶需要什麼功能就忙著開發,這是作為設計開發人員需要特別警惕避免的,不然會給後來的工作帶來很大的麻煩,甚至可能會需要全盤推倒重來。所以以後的課程設計要特別注意這一塊的設計。

按照要求,我們做的是機票預訂系統。說實話,我對這個是一無所知的,沒有訂過機票,也不知道航空公司是怎麼一個流程。盲目開始設計的下場我已經嘗過了,結果就是出來一個四不像的設計方案,沒有什麼實際用處。沒有前期的調查,僅從指導書上那幾條要求著手是不夠的。

在需求分析過程中,我們通過上網查資料,去圖書館查閱相關資料,結合我們的生活經驗,根據可行性研究的結果和客戶的要求,分析現有情況及問題,採用Client/Server結構,將機票預定系統劃分為兩個子系統:客戶端子系統,伺服器端子系統。在兩周的時間里,不斷地對程序及各模塊進行修改、編譯、調試、運行,其間遇到很多問題:由於忘記了一些java語言的規范使得在調試過程中一些錯誤沒有發現,通過這次課程設計,我對調試掌握得更加熟練了,意識到了程序語言的規范性以及我們在編程時要有嚴謹的態度,同時在寫程序時如有一定量的注釋,既增加了程序的可讀性,也可以使自己在讀程序時更容易。

我們學習並應用了SQL語言,對資料庫的創建、修改、刪除方法有了一定的了解,通過導入表和刪除表、更改表學會了對於表的一些操作,為了建立一個關系資料庫信息管理系統,必須得經過系統調研、需求分析、概念設計、邏輯設計、物理設計、系統調試、維護以及系統評價的一般過程,為畢業設計打下基礎。

很多事情不是想像中的那麼簡單的,它涉及到的各種實體、屬性、數據流程、數據處理等等。很多時候感覺後面的設計根本無法繼續,感覺像是被前面做的各種圖限制了。在做關系模型轉換的時候碰到有些實體即可以認為是實體又可以作為屬性,為了避免冗餘,盡量按照屬性處理了。

物理結構設計基本沒有碰到問題,這一塊和安全性、完整性不覺就會在物理結構設計中添加一些安全設置:主鍵約束、check約束、default定義等。最後才做索引的部分,對一些比較經常使用搜索的列,外鍵上建立索引,這樣可以明顯加快檢索的速度,最後別忘記重要的安全性設置,限制用戶訪問許可權,新建用戶並和資料庫用戶做相應的映射。

不管做什麼,我們都要相信自己,不能畏懼,不能怕遇到困難,什麼都需要去嘗試,有些你開始認為很難的事在你嘗試之後你可能會發現原來她並沒有你以前覺得的那樣,自己也是可以的。如果沒有自信,沒有目標,沒有信心就不可能把事情做好,當其他人都在迷茫的時候,自己一定要堅信目標,大學畢業出去即面臨找工作,從學習這個專業,到以後從事這方面的工作都需要不斷地去學習去實踐,這次實踐可以給我們敲一個警鍾,我們面臨畢業,面臨擇業,需要這些實踐經驗,在困難面前要勇於嘗試,這是這次課程設計給我的最大感想!

以上基本是這次實習的體會了,設計進行的非常艱難,編碼非常不容易,才發現做一個項目最重要的不在於如何實現,而是實現之前的需求分析和模塊設計。創新很難,有些流行的系統其實現並不難,難的在於對市場的分析和准確定位。設計,是一個任重道遠的過程。