[課堂案例分析]
案例51 基於web的高校教材查詢系統的分析與設計
**高校是一所綜合性高校，其涉及的專業課程多，教材用書種類多，數量大，傳統的管理方法存在著效率低，易出錯等諸多弊端，特別是學生、教師對教材使用情況了解相對較少，資訊的透明度較低，與當前高校管理中倡導的「以人為本」的管理思想存在著很大的差距。為此該校教材科開發了一套基於c/s的教材管理資訊系統。該系統主要包括以下六項處理功能：
系統維護、教材訂購計畫管理、教材庫存管理、教材銷售處理、學生預收款管理、資料統計、查詢與分析等功能。但是由於基於c/s的管理資訊系統自身存在的使用範圍小、地點固定等缺點，依然不能滿足管理上的需要。如學生想知道教材科是否有某本書、想了解自己教材款的使用情況，教師想要預訂下學期的教材等都必須親自去教材科，一方面浪費了學生和教師的時間和精力，另一方面也加大了教材科的工作量，為此教材科希望在原有的基於c/s的教材管理資訊系統的基礎上，利用高校校園網的強大儲存能力和方便的網路查詢能力，採用流行的browser/server結構體系，將最終使用者介面統一為瀏覽器，開發基於web的教材資訊查詢系統，更好地滿足各類人員對教材資訊管理的需求。
通過對該高校教材科的業務工作進行的調查，我們發現該教材科的業務物件主要有三類：學生、教師和教材科，其相應的日常業務也可以分為三類，分別是：
（1）有關學生的業務
教材科對於學生的業務主要是為學生提供入學以來在教材科的購書詳細資料的查詢，存款詳細資料的查詢，剩餘款項數額查詢及學生對所需教材的查詢等等。以往的方式是學生到教材科，提供自己的姓名、系別、年級，然後教材科在原始記錄中查詢。
（2）有關教師的業務
教師的業務主要是登記查詢教師領書的資訊，每學期開學，各系教師根據上學期預定的教材記錄到教材科領取教材，並登記；每學期教師可以預定下學期所用教材，方式是教師在學期末到教材科，提供所需教材名稱、教師個人資訊等，然後教材科記錄相應資訊並制定相應採購計畫。
（3）有關教材科的業務
教材科的業務主要是採購圖書，發放教材，對庫存圖書、學生購書資訊、教師（院系）領書的資訊進行管理、統計。這其中涉及到所有有關教材的各種資訊、資料，這部分也是教材科最主要、核心的業務。
通過對上述業務的歸納，可以畫出該系統的功能體系圖，如圖1所示。
3.1 業務分類
通過對上述業務的了解及分析，新系統的業務可以分為通用查詢業務、專用查詢業務和網上預定業務三部分。
（1）通用查詢業務
通用查詢業務包括教材基本資訊查詢業務、學生購書查詢業務、學生存款查詢業務、教師領書查詢業務、教材零售查詢業務等。任何人在學校或校外都可以使用自己的使用者名稱和密碼在任何一台能夠上網的電腦上查詢他想要查詢的內容（其中教材基本資訊查詢不需要使用者名稱和密碼）。
（2）教材科專用查詢業務
專用查詢業務是針對教材科的業務，這部分業務不對外開放，因為它沒有對外開放的必要，這部分業務主要是輔助教材科對庫存中教材的數量，更新速度等進行統計、**、分析。具體業務應包括：教材庫存統計業務、教材零售統計業務、學生購書統計業務和學生退書統計業務及教師（院系）領書情況的統計業務。
（3）教材預訂業務
網上教材預訂業務是辦公自動化優越性的體現。在新業務系統中，各系要預訂教材不用像以前跑到教材科進行登記了。只要在預定系統中輸入所要預定的教材的資訊，就可以完成對教材的預定，這樣大大提高了工作效率。
為完成網上預定的過程，相應的應該完成一系列的業務，包括：預定教材資訊錄入、預定教材資訊的修改、預定教材資訊查詢和預定教材資訊統計等內容。
3.2 業務流程圖
由於業務較多，在此僅對通用查詢業務和網上教材預定業務分別舉例加以說明。
（1）通用查詢業務
以學生查詢業務為例，該業務是學生向系統輸入使用者名稱和密碼進行身份認證，認證成功的學生就可以查詢其在教材中心的某一筆或全部購書、退書及訪問款記錄。其業務流程圖如圖2所示。
（2）教材預訂業務
教師進行教材預訂的業務流程是教師首先輸入自己的使用者名稱和密碼進行身份認證，然後在教材預訂系統中輸入自己下學期所上課程要使用的教材基本資訊，在規定的時間內，教師也可以對已輸入的教材資訊進行查詢和修改，超過了預定的時間，該資訊將被轉移到教材計畫表中。該業務的業務流程圖如圖3所示。
資料流程分析是在對上述業務流程圖進行分析的基礎上，從系統的科學性、管理的合理性和實際執行的可行性角度出發，將資訊處理的功能和彼此之間的聯絡自頂向下、逐層分解，在邏輯上精確地描述新系統應具有的功能、資料輸入、資料輸出、資料儲存及資料**和去向。
4.1 資料流程圖
由於該系統的資料流程圖較多，我們依然只對學生查詢業務和教材預訂業務的資料流程圖做詳細介紹。
（1）學生查詢子系統
由於學生要對自己的資訊進行查詢，涉及個人機密，所以學生應該首先進行身份確認，即登入系統，在身份得到確認後才可以查詢自己的購書記錄，退書記錄、自己的存款賬戶以及教材科現有教材的情況，其資料流程圖如圖4所示。
（2）教材預訂子系統
根據業務流程圖對教材預訂系統的描述，該系統的資料流程圖如圖5所示。
4.2 資料字典
資料流程圖只是從資料流向的角度描述了系統的組成和各部分之間的聯絡，但卻沒有具體說明各個組成部分和資料流的具體含義，而資料字典正好彌補了這一不足，資料字典是對資料流程的最底層圖中的資料項、資料流、資料儲存、處理邏輯和外部實體進行了詳細的說明。由於系統分析中資料字典的內容非常多，在此僅對各個部分分別舉例進行說明。
（1） 資料項的定義
資料項編號：a01-01
資料項名稱：學號
別名：無
簡述：學生資訊表中某個學生的學號
型別：字元型
長度：10個位元組
取值範圍：0000000000-9999999999
資料項編號：a02-01
資料項名稱：教材編號
別名：編號
簡述：教材資訊表中某種教材的編號
型別：字元型
長度：6個位元組
取值範圍：字母＋數字
（2）資料結構的定義
資料結構編號：d2
資料結構名稱：教材資訊表
簡述：教材科庫存教材的資訊情況表
資料結構組成：教材編碼＋教材名稱＋作者＋出版社＋版別序號＋印刷批次＋出版日期＋**＋理論庫存量＋實際庫存量＋庫存位置
資料結構編號：d1
資料結構名稱：學生資訊表
簡述：學生的相關資訊
資料結構組成：學號＋學生姓名＋使用者名稱＋密碼＋當前餘額
（3）資料流的定義
資料流編號：f02-01
資料流名稱：登入資訊
簡述：使用者登入系統時需要輸入的使用者資訊
資料流組成：使用者名稱+密碼
資料流**：學生、教師、教材管理人員
流通量：1000份/天
高峰流通量：700份/每天15：00-21：00
（4）處理邏輯的定義
處理邏輯編號：p1
處理邏輯名稱：驗證登入資訊
簡述：驗證使用者身份
輸入的資料流：登入資訊，**：外部實體「學生」、「教師」等
處理：查詢「學生資訊表」或「教師資訊表」，判斷其是否為合法使用者
輸出的資料流：合法使用者，去向是處理邏輯「輸入查詢條件」、「輸入教材預訂資訊」等
非法使用者，去向是外部實體「學生」、「教師」等
處理頻率：200次/天
（5）資料儲存的定義
資料儲存編號：d3
資料儲存名稱：學生領書表
簡述：存放學生在校期間所有的領書記錄
資料儲存組成：流水號＋學號＋教材編碼＋領書日期＋數量＋單價＋業務員
關鍵字：學號＋教材編碼＋領書日期
相關聯的處理：p4(「查詢」)等
（6）外部實體的定義
外部實體編號：s2
外部實體名稱：教師
簡述：本校所有任課教師
輸入的資料流：f1（「非法使用者資訊」）等
輸出的資料流：d02－01（「使用者登入資訊」）等
5.1 系統總體設計
5.1.1 系統硬體設計
在開發乙個網上瀏覽系統時，特別是基於具有大量資料的資料庫系統的**時，需要多伺服器的共同支援。雖然這些服務可以在乙個伺服器上整合，但這樣做可能會有安全問題。所以針對最典型的網路應用，至少需要兩台伺服器，他們分別是：
web 伺服器和資料庫伺服器。瀏覽器、web伺服器與資料庫伺服器之間的三層體系結構關係如圖6所示。
校園網web伺服器為sun ultra enterprise 450的unix伺服器，不相容微軟的iis/asp平台，所以瀏覽系統的web伺服器選用hp lh3伺服器，通過在校園網主dns伺服器設定網域名稱進行解析。資料庫伺服器同樣採用hp lh3伺服器並安裝微軟的sql server 7.0資料庫平台。
5.1.2 系統軟體設計
本系統全面採用微軟的產品解決方案。web伺服器作業系統採用微軟的windows nt server 4，web伺服器為微軟的inter*** information system 4，資料庫管理系統採用微軟的 sql server 7,開發工具採用微軟的visual interdev，採用微軟的active server pages（asp）技術開發**。
active server pages程式是在伺服器端工作，並且通過伺服器端的編譯動態的送出html檔案給客戶端，而不像一般script是在客戶端通過瀏覽器執行，因而產生各廠商瀏覽器並不完全支援某種指令碼語言而造成執行錯誤的現象；當客戶端瀏覽器向伺服器端要求乙個.asp檔案（active server pages檔案字尾名為.asp）時，server會將把這個asp檔案從頭到尾讀一遍，並加以編譯執行（利用核心程式asp.
dll的編譯），最後送出標準html格式檔案給客戶端，由於送給客戶端的是標準的html格式檔案，所以可以克服瀏覽器互不相容的問題。
圖6 三層體系結構示意圖
5.2 **設計
**設計是系統設計中非常重要的一部分。本系統中設計多個**的設計，如「學號」，為了和學校中的其他系統保持一致，所以使用學校目前「學號」**的設計，其設計規則如下：
順序號年級
專業院系編碼
「教材編碼」的設計考慮到教材一般都是各個院系有自己專用的教材，所以其**設計如下：
*** ***
順序號院系編碼
由於該高校的院系不超過30個，所以「院系編碼」的設計採用了3位的順序碼。其他**設計不再一一枚舉。
5.3 資料庫設計
資料庫設計是在選定的資料庫管理系統基礎上建立資料庫的過程。資料庫設計時需要綜合各個子系統的資料需求，分析各個資料之間的關係，按照dbms提供的功能和描述工具，設計出規模適當、正確反映資料關係、資料冗餘少、訪問效率高、能滿足各種查詢要求的資料模型。該設計過程包括概念結構設計、邏輯結構設計和物理結構設計。
高校教材資訊管理系統案例
課堂案例分析 案例51 基於web的高校教材查詢系統的分析與設計 高校是一所綜合性高校，其涉及的專業課程多，教材用書種類多，數量大，傳統的管理方法存在著效率低，易出錯等諸多弊端，特別是學生 教師對教材使用情況了解相對較少，資訊的透明度較低，與當前高校管理中倡導的 以人為本 的管理思想存在著很大的差距...
高校人事資訊管理系統,高校管理系統高效工作
總體概述 高校人事資訊管理系統為高校提供人員資訊管理，充分整合學校的資訊資源，利用網路協同辦公的優勢，使教職工資訊管理工作以更高效和公正透明的方式完成。博納思人事資訊管理系統包括人員基礎資訊庫 單位資訊庫 人員資訊管理 檔案資訊管理 系統管理五大模組。同時基於已有的人才招聘系統 崗位聘用系統，以及未...
應用資訊管理系統案例分析
國內外應用資訊管理系統成功案例及分析 網銷091 繆海鴻 erp案例 案例一 高露潔 棕欖公司 colgate palmolive 公司簡介 高露潔 棕欖是全球頂尖的消費品公司之一，總部在美國紐約，在全球200多個國家和地區設有分公司或辦事機構，雇員總數達40000人。公司在口腔護理 個人護理 家居...