客戶訂購登記系統(tǒng).doc

網絡數據庫課程設計網 絡 數 據 庫 課 程 設 計客戶訂購登記系統(tǒng) 班級：13升計科2班姓名：段詩慧 學號：1316353047 日期：2014.11.28 摘要客戶訂購登記系統(tǒng)的管理是公司管理的一個重要內容。隨著市場競爭的日趨激烈化，能夠擁有更多的客戶訂購信息，將是企業(yè)長久生存的重要因素。 隨著信息技術的發(fā)展和網絡在廣大消費者中的普及，網上購物愈來愈成為一種潮流和時尚。因此，建立一個網上的客戶訂購登記系統(tǒng)，必將成為企業(yè)在未來激烈的競爭中提升綜合競爭優(yōu)勢的有力武器。 一個公司希望為其客戶的訂購行為建立一個數據庫。瀏覽者如果想在線定購，需提交注冊單。詳細的注冊信息便于管理員對瀏覽者的身份進行確認，同時便于企業(yè)進行有針對性的推銷活動。而且，經過注冊的顧客可以在線修改個人資料，使企業(yè)能夠獲得第一手的客戶信息。已經在線注冊的瀏覽者，在瀏覽產品頁面時，可以將自己喜歡的產品直接放入購物車中，系統(tǒng)便會自動生成定購單，提交給管理員，企業(yè)便會依據顧客注冊信息將產品或服務送達顧客手中，從而實現在線訂購。顧客還可以隨時登陸查看自己的訂單情況，了解企業(yè)對自己的產品訂單的處理情況。而采購管理員也可以通過查看每個顧客的定單情況，了解各種產品的銷售情況和需要進行采購的商品信息，從而了解市場發(fā)展態(tài)勢并制定相應的措施。這樣更有利于公司的長期發(fā)展。關鍵詞:JAVA，SQL server 2008，數據庫目錄1、需求分析41.1 問題描述：41.2 業(yè)務流程描述：42、概念結構設計63、邏輯結構設計93.1 E-R圖向關系模型的轉換93.2數據模型的優(yōu)化104、物理結構設計104.1關系存取方法選擇105、數據庫實施 105.1 數據庫的實現：105.2 生成的關系表：135.3 權限管理166、數據庫運行與維護186.1 應用系統(tǒng)開發(fā)用戶注冊模塊的實現186.2 數據庫的維護187、總結19參考文獻：19客戶訂購登記系統(tǒng)1、需求分析1.1 問題描述：隨著信息技術的發(fā)展和網絡在廣大消費者中的普及，網上購物愈來愈成為一種潮流和時尚。因此，建立一個網上的客戶訂購登記系統(tǒng)，必將成為企業(yè)在未來激烈的競爭中提升綜合競爭優(yōu)勢的有力武器。一個公司希望為其客戶的訂購行為建立一個數據庫。瀏覽者如果想在線定購，需提交注冊單。詳細的注冊信息便于管理員對瀏覽者的身份進行確認，同時便于企業(yè)進行有針對性的推銷活動。而且，經過注冊的顧客可以在線修改個人資料，使企業(yè)能夠獲得第一手的客戶信息。已經在線注冊的瀏覽者，在瀏覽產品頁面時，可以將自己喜歡的產品直接放入購物車中，系統(tǒng)便會自動生成定購單，提交給管理員，企業(yè)便會依據顧客注冊信息將產品或服務送達顧客手中，從而實現在線訂購。顧客還可以隨時登陸查看自己的訂單情況，了解企業(yè)對自己的產品訂單的處理情況。而采購管理員也可以通過查看每個顧客的定單情況，了解各種產品的銷售情況和需要進行采購的商品信息，從而了解市場發(fā)展態(tài)勢并制定相應的措施。這樣更有利于公司的長期發(fā)展。1.2 業(yè)務流程描述：（1）數據流圖： 圖1：頂層數據流圖圖2：第0層數據流圖（2）數據字典：表格1：數據字典消費者名字消費者描述應用該系統(tǒng)的公司客戶定義消費者=消費者ID+消費者姓名+地址+聯(lián)系電話表格2：數據字典訂購請求名字訂購請求描述消費者發(fā)出的訂購請求定義訂購請求=訂購商品的名稱、編號+訂購商品的數量表格3：數據字典合法的訂購請求名字合法的訂購請求描述經過系統(tǒng)檢驗后合格的請求定義合法的訂購請求=合法的商品名稱、編號+合法的數量表格4：數據字典訂單名字訂單描述系統(tǒng)登記用戶的請求后，打印出來的關于用戶訂購請求的詳細描述定義訂單=訂單號+消費者ID+訂貨項數+訂貨日期+交貨日期表格5：數據字典發(fā)票名字發(fā)票描述每一張訂單，都對應著一張發(fā)票，發(fā)票上記著消費者所訂購商品的價格等信息。消費者必須支付該發(fā)票（支付方式為支票、信用卡或現金）定義發(fā)票=發(fā)票號+訂單號+應收金額表格6：數據字典應收賬款名字應收賬款描述一個消費者可能一次有多個訂單（即對應有多張發(fā)票），應收金額將所有發(fā)票上的應收金額累加起來，最后由消費者支付定義應收金額=某個消費者一次訂購的所有應收金額之和2、概念結構設計（1）經過分析可知，該系統(tǒng)的實體有：消費者、訂單、訂單細節(jié)、商品、發(fā)票、應收帳。各個實體的具體E-R圖如下：圖3：消費者實體的E-R圖圖4：訂單實體的E-R圖圖5：訂單細節(jié)的E-R圖圖6：商品實體的E-R圖圖7：發(fā)票實體的E-R圖（2）實體-聯(lián)系方法是抽象和描述現實世界的有力工具。用E-R圖表示的該類模型獨立于具體的DBMS所支持的數據模型，它是各種數據模型的共同基礎。經過分析，得到客戶訂購登記系統(tǒng)的E-R圖：圖8：系統(tǒng)的E-R圖定義每個實體的屬性（其中加下劃線的屬性為實體的碼）：表格7：E-R圖中的實體的屬性消費者消費者ID，消費者姓名，地址，電話應收帳消費者ID，發(fā)票號，支付日期訂單訂單號，消費者ID，訂貨項數，訂貨日期，交貨日期訂單細節(jié)訂單號，細則號，訂貨數，商品號，金額發(fā)票發(fā)票號，訂單號，應收金額商品商品號，商品名，單價 3、邏輯結構設計3.1 E-R圖向關系模型的轉換邏輯結構設計的任務就是把概念結構設計階段設計好的基本E-R圖轉換為與選用的DBMS產品所支持的數據模型相符合的邏輯結構。我們將概念結構設計中的E-R圖轉換成關系模式，轉換得到的關系模式：（1）消費者（消費者ID，消費者姓名，地址，電話）此為“消費者”實體型的關系模式。（2）支付賬款（消費者ID，發(fā)票號，支付方式）此為聯(lián)系“支付”所對應的關系模式。（3）應收帳（消費者ID，發(fā)票號，支付日期）此為“應收帳”實體型對應的關系模式。（4）訂購（訂單號，消費者ID）此為聯(lián)系“訂購”所對應的關系模式。（5）訂單（訂單號，消費者ID，訂貨項數，訂貨日期，交貨日期）此為“訂單”實體型所對應的關系模式。（6）參照（發(fā)票號，消費者ID）此為聯(lián)系“參照”所對應的關系模式。（7）發(fā)票（發(fā)票號，訂單號，應收金額）此為“發(fā)票”實體型所對應的關系模式。（8）訂單細節(jié)（訂單號，細則號，訂貨數，商品號，金額）此為“訂單細節(jié)”實體型所對應的關系模式。（9）包含（訂單號，細則號，商品號）此為聯(lián)系“包含”所對應的關系模式。（10）商品（商品號，商品名，單價）此為“商品”實體型所對應的關系模式。3.2數據模型的優(yōu)化規(guī)范化理論為數據庫設計人員判斷關系模式的優(yōu)劣提供了理論標準，可以用來預測關系模式可能出現的問題，是數據庫設計工作有嚴格的理論基礎。經過檢驗，可知以上10個關系模式都滿足3NF。而且因為這里設計的關系模式都比較簡單，模式之間的關系也不太復雜，所以也不需要再進行分解等操作。4、物理結構設計4.1關系存取方法選擇存取方法是使事務能夠快速存取數據庫中數據的技術。常用的存取方法有索引方法、Hash方法、聚簇方法等。（1）如果一個屬性經常在查詢條件中出現，或者經常作為最大值和最小值等聚集函數的參數，或者經常在連接操作的連接條件中出現，則考慮在這個屬性上建立索引。但是，若一個關系的更新頻率很高，這個關系上定義的索引數就不能太多。因為更新一個關系時，這樣的代價相當高。（2）如果一個關系的屬性主要出現在等值連接條件中或主要出現在相等比較選擇條件中，而且一個關系的大小可預知且變化不大，則此關系可以選擇Hash存取方法。（3）當通過聚簇碼進行訪問或連接是該關系的主要應用，與聚簇碼無關的其他訪問很少或者是次要的時，可以使用聚簇。尤其當SQL語句中包含有與聚簇碼有關的ORDER BY,GROUP BY,UNION,DISTINCT等子句或短語時，使用聚簇特別有利，可以省去對結果集的排序操作。由以上各種存取方法的特點可知，商品關系的更新會比較頻繁，所以不適合建立索引，但是可以使用聚簇方法，將商品按類型排列，顯示給顧客。同樣，對于訂單的設計，也可以選擇使用聚簇方法，當采購管理員查詢訂購登記系統(tǒng)中的訂單時，就可以將訂單信息按照訂單號遞增的顯示，當然，訂單的編號是與時間相關的，這樣也方便訂購管理員對訂單進行添加和刪除等操作。5、數據庫實施 5.1 數據庫的實現：u create table 消費者(消費者ID char(10) primary key,密碼 char(20) not null,消費者姓名 char(10)not null,地址 char(20) not null,電話 smallint not null)u create table 支付賬款(消費者ID char (10) foreign key references 消費者(消費者ID),發(fā)票號 smallint foreign key references 發(fā)票(發(fā)票號),支付方式 char(10) not null,primary key (消費者ID,發(fā)票號),constraint c1 check (支付方式 in(支票,信用卡,現金)u create table 發(fā)票(發(fā)票號 smallint primary key,訂單號 smallint foreign key references 訂單(訂單號),應收金額 smallint )u create table 訂單(訂單號 smallint primary key,消費者ID char (10) foreign key references 消費者(消費者ID),訂貨項數 smallint,訂貨日期 datetime,交貨日期 datetime)u create table 應收帳(消費者ID char(10) foreign key references 消費者(消費者ID),發(fā)票號 smallint foreign key references 發(fā)票(發(fā)票號),支付日期 datetime,primary key(消費者ID,發(fā)票號)u create table 訂購(訂單號 smallint foreign key references 訂單(訂單號) primary key,消費者ID char(10) foreign key references 消費者(消費者ID)u create table 參照(發(fā)票號 smallint foreign key references 發(fā)票(發(fā)票號) primary key,消費者ID char(10) foreign key references 消費者(消費者ID)u create table 訂單細節(jié)(訂單號 smallint foreign key references 訂單(訂單號),細則號 smallint,訂貨數 smallint,商品號 smallint foreign key references 商品(商品號),金額 float(4),primary key (訂單號,細則號)u create table 商品(商品號 smallint primary key,商品名 char(20),單價 float(4)u create table 包含(訂單號 smallint foreign key references 訂單(訂單號),細則號 smallint,商品號 smallint foreign key references 商品(商品號),primary key (訂單號,細則號)5.2 生成的關系表：由對數據庫的設計得到了10個表：圖 9：“消費者”表這里不允許密碼、消費者姓名、地址和電話為空，也就是要求用戶在進行注冊時必須填寫這些項，這樣使得后來的寄送訂單等環(huán)節(jié)可行。圖 10：“支付賬款”表這里我們假設支付賬款只能選擇支票、信用卡或現金中的某種方式，在創(chuàng)建表的時候，進行約束：constraint c1 check (支付方式 in(支票,信用卡,現金) 從而得到一個約束：圖 11：“支付賬款”表的元組級限制圖 12：“應收帳”表“應收帳”表中有一個屬性“支付日期”，它應該是日期型或時間型，但是由于我使用的SQL Server 2000 不支持date 數據類型，所以這里選用datetime數據類型。圖13 ：“訂購”表圖14：“訂單”表圖15 ：“參照”表圖16 ：“發(fā)票”表圖17 ：“訂單細節(jié)”表圖 18：“包含”表圖 19：“商品”表5.3 權限管理數據庫的安全性不容忽視，所以這里對用戶權限進行了相應的設置。為該系統(tǒng)設置的角色有：超級管理員、一般用戶、訂購管理員、商品管理員、財務管理員、采購管理員等。每個角色都有相應不同的權限。下面只列舉其中兩個角色的權限：圖20：一般用戶的權限圖21：訂購管理員的權限6、數據庫運行與維護 6.1 應用系統(tǒng)開發(fā)用戶注冊模塊的實現本次課程設計只實現了其中的用戶注冊模塊。在顧客需要進行訂購行為之前，需要注冊用戶的基本信息，包括登錄用戶名、登錄密碼、姓名、地址、電話等信息。這樣，在訂購系統(tǒng)登記顧客的訂購請求后，所產生的訂單將會被寄給正確的顧客。當然，在實現該模塊之前，數據庫中應該已經存在“消費者”這個表，這個模塊只是向該表中插入一些合法的記錄。填寫完“注冊”中的每一項后，點擊“確定”按鈕，系統(tǒng)提示“注冊成功”，這樣系統(tǒng)已經將該用戶的信息存入了數據庫。當然，由于“登錄用戶名”是“消費者”關系的主碼，由該主碼約束可知，當輸入了一個與數據庫中某條記錄相同的用戶名時，注冊將不能成功。這時系統(tǒng)會提示填入一個新的用戶名。為了檢驗該系統(tǒng)是否正確與數據庫交互，我們打開SQL Server 2000 查詢分析器，輸入 “ select * from 消費者 ”語句，執(zhí)行后的結果為：由此可見，用戶通過“注冊”注冊的信息與我們直接在數據庫中插入該條記錄的結果是一樣的。每次有顧客正確注冊之后，系統(tǒng)就會向“消費者”數據庫中插入新的信息。當然，應該有數據庫管理員來維護這些信息。6.2 數據庫的維護數據庫試運行合格后，數據庫開發(fā)工作就基本完成。但是，由于應用環(huán)境在不斷變化，數據庫運行過程中物理存儲也會不斷變化，所以就需要對數據庫進行長期的維護工作。DBA要針對不同的應用要求制定不同的轉儲計劃，以保證一旦發(fā)生故障能盡快將數據庫恢復到某種一致的狀態(tài)，并盡可能減少對數據庫的破壞。而且，在數據庫的運行過程中，對安全性的要求也會發(fā)生變化，比如有的數據原來是機密的，現在可以公開查詢，而新加入的數據又可能是機密的。這都需要DBA根據實際情況修改原有的安全性控制。同樣，數據庫的完整性約束條件也會變化，也需要DBA不斷修正，以滿足用戶要求。數據庫因為記錄的不斷增、刪、改的操作，其物理存儲情況會變壞，從而降低了數據的存取效率，數據庫的性能也下降了。這要求DBA對數據庫進行重組織，或部分重組織。在重組織過程中，按原設計要求重新安排存儲位置、回收垃圾、減少指針鏈等，提高系統(tǒng)性能。7、總結通過設計客戶訂購登記系統(tǒng)，從需求分析開始，逐步的進行概念設計、邏輯設