【正文】 來作為數(shù)據(jù)庫服務(wù)器。 如果實體已經(jīng)是第一范式的，并且如果所有非逐漸屬性的值都依賴于主鍵，而不僅僅是部分的依賴，則這個實體是第二范式的。規(guī)范化一般包括三個步驟的技術(shù)，該技術(shù)把數(shù)據(jù)模型規(guī)范成第一范式，第二范式，第三范式。在為數(shù)據(jù)庫設(shè)計做準(zhǔn)備的過程中，用來改變一個數(shù)據(jù)模型的技術(shù)稱為數(shù)據(jù)分析。自產(chǎn)生之日起， SQL 語言大大推動了關(guān)系數(shù)據(jù)庫的應(yīng)用并指導(dǎo)著關(guān)系數(shù)據(jù)庫的發(fā)展方向 [6]。 SQL 語言的功能包括查詢、操縱、定義和控制，是一個綜合的、通用的關(guān)系數(shù)據(jù)庫語言，同時又是一種高度非過程化的語言，只要求用戶指出做什么而不需要指出怎么做。對關(guān)系數(shù)據(jù)庫的操作是高度非過程化的，用戶不需要指出特殊的存取路徑，路徑的選擇由 DBMS 的優(yōu)化機制來完成。這一系列的行和列被稱為表，一組表組成了數(shù)據(jù)庫。而后來出現(xiàn)的關(guān)系數(shù)據(jù)庫較好地解決了這些問題。 網(wǎng)狀數(shù)據(jù)庫和層次數(shù)據(jù)庫已經(jīng)很好地解決了數(shù)據(jù)的集中和共享問題，但是在數(shù)據(jù)獨立性和抽象級別上仍有很大欠缺。層次數(shù)據(jù)模型的提出，首先是為了模擬這種按層次組織起來的事物。在數(shù)據(jù)庫發(fā)展史上，網(wǎng)狀數(shù)據(jù)庫占有重要地位 層次型數(shù)據(jù)庫管理系統(tǒng)是緊隨 網(wǎng)狀 DBMS 而出現(xiàn)的。每個記錄有一個惟一地標(biāo)識它的內(nèi)部標(biāo)識符，稱為碼(DatabaseKey,DBK)，它在一個記錄存入數(shù)據(jù)庫時由 DBMS 自動賦予。記錄包含若干數(shù)據(jù)項。 24 信 息 系 統(tǒng)信 息 系 統(tǒng)信 息 系 統(tǒng)信 息 系 統(tǒng)數(shù) 據(jù) 庫 圖 31 數(shù)據(jù)庫與信息系統(tǒng)關(guān)系描述圖 最早出現(xiàn)的是網(wǎng)狀 DBMS。能夠統(tǒng)一管理和共享數(shù)據(jù)的數(shù)據(jù)庫管理系統(tǒng) (DBMS)應(yīng)運而生。當(dāng)時計算機開始廣泛地應(yīng)用于數(shù)據(jù)管理，對數(shù)據(jù)的共享提出了越來越高的要求。而且本系統(tǒng)中與數(shù)據(jù)庫的操作完全是靠 WEB 頁面來實現(xiàn)，合理的數(shù)據(jù)庫設(shè)計和建立更顯得重要。當(dāng)一個系統(tǒng)涉及數(shù)據(jù)庫相關(guān)的操作時，其運行效率，冗余程度，可靠性，穩(wěn)定性，可操作性，都顯得尤為重要。 23 第 3 章 數(shù)據(jù)庫設(shè)計 本在線手機銷售系統(tǒng)是完成基于 WEB 頁面來進(jìn)行手機選購的業(yè)務(wù)流程， 在整個選購過程中不論是是對商品的瀏覽，下訂單，還是維護(hù)相關(guān)的信息，無處不與數(shù)據(jù)庫產(chǎn)生相應(yīng)的交互。 樣式表，或者稱為層疊樣式表，英文名Cascading Style Sheet，即 CSS，是 HTML 的一部分，作為對 HTML元素展示效果的一種擴展，其功能極為強大，有了樣式表，可以放棄 HTML 元素的屬性不用就能實現(xiàn)精美的網(wǎng)頁排版布局。否則，會給人以凌亂不 堪的感覺。在每個子項目頁面的下一級還有相應(yīng)的增刪改查等信息維護(hù)頁面，由于篇幅所限，圖中并未全部畫出。管理員成功登錄系統(tǒng)后，進(jìn)入管理頁面，在本頁面中可以進(jìn)入不同的管理子項目頁面。其中商品瀏覽界面可以查看具體手機的詳細(xì)信息。匿名用戶亦可瀏覽本系統(tǒng)主界 面，但不能進(jìn)行信息維護(hù)，購物車提交等功能操作。 圖 27 用戶級頁面轉(zhuǎn)換圖 21 圖 28 管理員級部分頁面轉(zhuǎn)換圖 首先對于本系統(tǒng)中所涉及的主要操作頁面進(jìn)行描述，基本的頁面轉(zhuǎn)換圖如圖 2 28所示。只有一個友好的交互界面才能使消費者對網(wǎng)站的整體形象有好的認(rèn)同。 系統(tǒng)開發(fā)環(huán)境及技術(shù)方案 綜合前面幾節(jié)的分析，本系的最終開發(fā)技術(shù)方案及環(huán)境如下 1 采用 JSP 實現(xiàn)系統(tǒng)開發(fā) 2 系統(tǒng)采用三層體系結(jié)構(gòu) 3 操作系統(tǒng)平臺： Windows XP 4 數(shù)據(jù)庫系統(tǒng)： MS SQL Server 2021 5 JSP 服務(wù)器引擎： Tomcat 6 IDE 采用 eclipse 開發(fā)平臺 7 界面設(shè)計工具 Dreamweaver MX 2021 20 界面設(shè)計 本系統(tǒng)作為一個基于 B/S 模式 的在線手機銷售系統(tǒng)，界面是系統(tǒng)與外界交互的一個窗口，界面的好壞直接影響到了實際中系統(tǒng)的應(yīng)用。 關(guān)系型數(shù)據(jù)庫 關(guān)系型數(shù)據(jù)庫在處理海量數(shù)據(jù)和單位時間響應(yīng)事務(wù)處理請求等方面 ,有著明顯的優(yōu)勢 .關(guān)系型數(shù)據(jù)庫是以服務(wù)器的方式提供數(shù)據(jù)服務(wù)的 ,對于數(shù)據(jù)的管理有著良好的控制 ,在維護(hù)數(shù)據(jù)的完整性、安全性方面有全面的考慮 .對于本系統(tǒng)而言 ,數(shù)據(jù)庫信息的中心，是整個運作流程的核心部分。 表示層：就是數(shù)據(jù)的表示 ,可以表示成 WEB 方式 ,也可以表示成WINFORM 方式， WEB 方式可以表現(xiàn)成 aspx，也可以表示成 asp,jsp等。 表 示 層業(yè) 務(wù) 邏 輯 層 數(shù) 據(jù) 層提 交 信 息信 息 反 饋提 交 信 息數(shù) 據(jù) 庫 操 作D a t e A c c e s sB u s i n e s s O b j e c t sS e r v l e t A P I 圖 26 系統(tǒng)三層結(jié)構(gòu)邏輯框圖 邏輯層：這個主要是完成應(yīng)用的邏輯處理，你可以把它理解為 服務(wù) ，它為數(shù)據(jù)層和表現(xiàn)層提供服務(wù)。比如實時應(yīng)用你用關(guān)系數(shù)據(jù)庫來處理效果就不會很好，大批量的數(shù)據(jù)用文件系統(tǒng)來管理效率就不高。數(shù)據(jù)層的的概念不等同于數(shù)據(jù)庫 ,比如你的應(yīng)用可以把數(shù)據(jù)放入關(guān)系數(shù)據(jù)庫 ,也可以放入 XML， 也可以放入傳統(tǒng)的文件系統(tǒng) ,也可以放入內(nèi)存。三層結(jié)構(gòu)圖如圖 26 所示。 18 三層結(jié)構(gòu)簡介 整個系統(tǒng)構(gòu)建采用 B/S 模式下的 Presentation(表示層 )、BusinessLogic(業(yè)務(wù)邏輯層 )、 Data(數(shù)據(jù)層 )三層結(jié)構(gòu)模式。 JSP 的編譯操作僅在第一次對頁面請求時發(fā)生 ,速度遠(yuǎn)遠(yuǎn)大于 ASP,而且 JSP 是基于 Java 技術(shù)的，作為 J2EE 體系中的一項主要技術(shù)，在跨操作系統(tǒng) ,安全機制和性能方面均相對于 ASP 都體現(xiàn)出很大優(yōu)勢 [4]。另外安全性也是需要注意的問題。但 ASP 有它的一定局限性。 為何選用 JSP 電子商務(wù)網(wǎng)站目前國內(nèi)大多是用 ASP 或 JSP 來編寫。在整個系統(tǒng)中表示層不與數(shù)據(jù)庫直 接發(fā)生交互，而是通過封裝了各種邏輯功能的 JavaBean來完成整個系統(tǒng)內(nèi)信息的交互。 系統(tǒng)其它用例文檔在此不再詳述。 ○ 3 管理員對訂單進(jìn)行處理。 17 主要事 件流程： 角色動作 系統(tǒng)響應(yīng) ○ 1 管理員查看訂單。也可查看未處理訂單。 表 28 訂單查看用例詳細(xì)描述 用例名稱： 訂單查看 用例 ID： 118 角色： Administrator 基本描述： 此用例的前提條件為管理員成功登錄系統(tǒng)?？梢酝瓿蔁o效訂單的刪除，未處理訂單的查看等操作。 ○ 4 系統(tǒng)對填寫表單進(jìn)行驗證，驗證合法，進(jìn)行添加，否則給出錯誤提示。 ○ 2 系統(tǒng)等待提交。與本用例相關(guān)的角色為Administrator。 表 27 手機添加用例詳細(xì)描述 用例名稱： 手機添加 用例 ID： 107 角色： Administrator 基本描述： 此用例的前提條件為管理員成功登錄系統(tǒng)。 手機信息維護(hù)用例完成管理員對整個系統(tǒng)中信息量最大的手機信息進(jìn)行維護(hù)的功能，其中包括手機信息的添加，刪除，更新和查看。 16 ○ 3 會員輸入自己的要求并查詢。 主要事 件流程： 角色動作 系統(tǒng)響應(yīng) ○ 1 會員欲查詢符合自己需求的手機。用戶可以根據(jù)自己的要求在系統(tǒng)中查找符合其要求的手機。手機查詢用例文檔見表 26。 對于一個商務(wù)網(wǎng)站搜索功能是非常關(guān)鍵的，如何讓用 戶最快，最有效的找到自己所需要的商品是系統(tǒng)首要完成的任務(wù)。 主要事 件流程： 角色動作 系統(tǒng)響應(yīng) ○ 1 會員提交購物車。然后提交購物車，本次購買的信息將以一條訂單記錄的形式反饋給系統(tǒng)。提交購物車用例文檔見表25。 ○ 4 系統(tǒng)獲取修改信息，進(jìn)行購買數(shù)量校驗，如果購買數(shù)量大于庫存，給出錯誤提示，否則修改完成。 ○ 2 系統(tǒng)等待會員進(jìn)行更改操作。與本用例相關(guān)的角色為 Leaguer。 修改購物車用例文檔見表 24。 主要事 件流程： 角色動作 系統(tǒng)響應(yīng) ○ 1 會員選擇要購買的手機，進(jìn)行購物車添加動作。 表 23 添加購物車用例詳細(xì)描述 用例名稱： 添加購物車 用例 ID： 103 續(xù)表 23 添加購物車用例詳細(xì)描述 角色： Leaguer 基本描述： 此用例完成用戶購買手機的最基本操作：添加購物車，即用戶將要買的商品暫時保存在系統(tǒng)購物車中，從而最終提交，來完成一個或多個商品的購買。 ○ 2 系統(tǒng)根據(jù)用戶的 id，在服務(wù)器端對數(shù)據(jù)庫中的信息進(jìn)行更新。與本用例相關(guān)的角色為 Leaguer。 表 22 會員信息更新用例詳細(xì)描述 用例名稱： 會員信息更新 用例 ID： 102 角色： Leaguer 14 基本描述： 此用例的前提條件為會員登錄成功，然后對其個人信息進(jìn)行修改。 會員信息更新是會員的 信息發(fā)生變更的時候，會員成功登錄，并對失效信息進(jìn)行更改。 ○ 3 會員或管理員輸入登錄信息。 主要事 件流程： 角色動作 系統(tǒng)響應(yīng) ○ 1 會員或管理員要進(jìn)入系統(tǒng)。 表 21 登錄用例詳細(xì)描述 用例名稱： 登錄 用例 ID： 100 角色： Leaguer,Administrator 基本描述： 此用例描述會員和管理員如何登錄進(jìn)入本在線手機銷售系統(tǒng)。 部分用例文檔 系統(tǒng)登錄是管理員和會員要維護(hù)系統(tǒng)或使用系統(tǒng)的第一步，也是先決條件，只有通過系統(tǒng)的登錄驗證，系統(tǒng)才允許管理員和會員的合法操作的進(jìn)行。其中手機信息處理功能模塊將是與管理員相關(guān)功能模塊中的一個重點 。其中手機信息處理功能模塊，公司信息處理功模塊，會員信息處理功能模塊都是管理員通過 WEB 頁面對系統(tǒng)的手機信息，手機品牌信息，會員信息進(jìn)行相應(yīng)的增刪改查操作，即通過 WEB 頁面來操作數(shù)據(jù)庫中存儲的信息能。 管理員是本系統(tǒng)信息維護(hù)的核心。 首先會員通過登錄進(jìn)入系統(tǒng)，瀏覽系統(tǒng)提供的各款手機信息，對符合自己要求的手機進(jìn)行添加到購物車的操作。這也是系統(tǒng)開發(fā)過程中的一個重點。此模塊將是與消費者相關(guān)功能模塊中的一個重要部分?？梢愿鶕?jù)手機的品牌查找，列出該品牌在信息庫中存儲的所有手機，也可以根據(jù)手機的型號，不同的價格范圍進(jìn)行查找。手機查詢是對會員購買手機的流程中的一個關(guān)鍵步驟。 會員的信息維護(hù)功能模塊是對自己的注冊信息進(jìn)行維護(hù)。 11 系統(tǒng)用例描述 系統(tǒng)用例圖 本手機銷售系統(tǒng)的用例描述如圖 25所示。如上頁圖 24所示。 整體圖中反應(yīng)了消費者和管理員兩個外部實體與系統(tǒng)進(jìn)行交互的整體關(guān)系，描述了 系統(tǒng)的運作環(huán)境。 數(shù)據(jù)流程分析 系統(tǒng)數(shù)據(jù)流程圖整體圖 根據(jù)前面系統(tǒng)概述中描述的系統(tǒng)基本特點及其完成的功能，可得系統(tǒng)與外部實體之間的操作關(guān)系。在系統(tǒng)開發(fā)及運行過程中僅需要支付少量開發(fā)成本，及服務(wù)器架設(shè)成本和系統(tǒng)運行時的維護(hù)成本，相對傳統(tǒng)商務(wù)模式中店面，店員等各種開銷來說將節(jié)約大量的資金。 經(jīng)濟可行性 在前一章中對 B2C 模式的電子商務(wù)系統(tǒng)有較詳細(xì)的敘述。相應(yīng)的開發(fā)環(huán)境通過互聯(lián)網(wǎng)也都可以獲取。業(yè)務(wù)邏輯的處理，及相應(yīng)的數(shù)據(jù)存儲的技術(shù)都已經(jīng)很完備。首先 B/S 的開發(fā)模式在各個行業(yè)都有較好的應(yīng)用。 技術(shù)可行性 電子商務(wù)系統(tǒng) 發(fā)展至今業(yè)務(wù)邏輯的分析和開發(fā)技術(shù)都已經(jīng)比較成熟。經(jīng)濟可行性是對一個項目或方案的成本效益的度量 [3]。技術(shù)可行性是對一種特定技術(shù)方案的現(xiàn)實性以及技術(shù)資源和專家的可用性的度量。系統(tǒng)可行性大致包括如下四類準(zhǔn)則。管理員可以對手機信息，會員信息，品牌信息，訂單信息進(jìn)行相應(yīng)的維護(hù)，其基本 操作如圖 22所示。消費者整個網(wǎng)上購物基本流程如圖 21所示。在瀏覽過程中，可以對自己選中的商品進(jìn)行添加購物車的操作，更改購買的數(shù)量，并最終提交自己的訂單。 從消費者的角度來看，消費者首先選擇自己要訪問的站點，并在其上完成用戶信息的注冊任務(wù)。消費者通過登錄來完成購買手機的相關(guān)操作。管理員可以在 WEB 頁面中完成對系統(tǒng)各種信息的添加、刪除、修改并處理用戶提交的訂單。并可以通過注冊或登錄的方式進(jìn)入系統(tǒng)，采用添加購物車的方式完成手機的購買，并最終以下訂單的形式將購買信息反饋給網(wǎng)站提供商。 本手機銷售系統(tǒng)指在滿足消費者購買手機的需求，和管 理員通過 WEB 頁面來完成系統(tǒng)的維護(hù)和整個商務(wù)網(wǎng)站的運作。在這種矛盾的前提下，在線手機銷售恰恰就是一個很好的解決方案。試想一下，一個滿負(fù)荷工作的人，想選購一部新手機時是否能抽出時間，穿梭于各大手機賣場，在琳瑯滿目的機器中去尋找符合自己要求的手機呢。根據(jù)價值規(guī)律的原則，有需求就會有供給，正是因 6 為市場的需求，各大電子產(chǎn)品廠商紛紛投身于手機 行業(yè)，各種手機品牌更是如雨后春筍般的涌現(xiàn)。同時 B2C 在實際的控制力，購買人群的數(shù)量，以及物流等方面也都存在著很多問題，但隨著電子商務(wù)的不斷發(fā)展，和信息技術(shù)的不斷進(jìn)步，此種電子商務(wù)模式也正更加的完善更加的成熟。這 些技 術(shù) 和服 務(wù) ，都 從某種角度說明了 B2C 的技 術(shù) 決不是 為 技 術(shù) 而技 術(shù) ，而是以 顧 客 為 中心采用技 術(shù) 。所以，客 戶 能 記 住某一個方向的最好的一兩個網(wǎng)站，客 戶很 難記 住第三個網(wǎng)站，如果沒有新意，很 難獲 得 PAGEVIEW。也就是當(dāng)一個大型的 購