1、數據庫原理及應用Application and principles of database數據庫原理及應用實驗報告數據庫設計及實現（電話計費管理系統）17實驗報告實驗類型_綜合設計_ 實驗室_軟件實驗室一_電話計費管理系統1.實驗項目名稱：數據庫設計及實現（電話計費管理系統）2.實驗項目的目的和任務：熟悉數據庫設計的各個階段，會使用visio工具實現階段性設計的表達，并使用語言實現數據庫的連接，完成數據的顯示、修改、插入和刪除。學生根據所學的數據庫原理與程序設計知識，能夠針對一個小型的數據庫管理系統進行需求分析、系統設計、數據庫設計、編碼，測試等，完成要求的功能，從而達到掌握開發一個小型數據

2、庫的目的。3.實驗內容： （1） 根據數據庫設計各個階段得出的內容，在SQLSERVER中建立數據庫 （2） 選擇語言設計一個系統，實現連接數據庫，并且可以顯示數據庫內容4. 需求分析（1）計費系統作為業務運營支撐系統的基礎， 其準確性和有效性至關重要， 計費系統的錯誤將直接影響結算、 賬務及客戶管理系統的處理結果。 由于我國移動手機用戶的基數很大， 計費系統任何微小的偏差所造成的損失都是巨大的。 該系統信息來源主要有管理員添加，方便網站管理員的查詢和管理。該系統的任務是方便，靈活的管理用戶的各項信息。（2) 總體描述對電話計費業務進行調查，設計的系統要求：能夠記錄通話信息，如來電號碼、去電號

3、碼、通話時長、通話費用，查詢費用帳單等信息具體對各種數據文件裝入和修改數據的功能。能在用戶交費同時打印發票。能用關系數據庫理論建立幾個數據庫文件來存儲用戶信息，收費員信息和收費信息等資料。能夠為用戶提供查詢各種記錄的功能（3) 功能需求：查詢模塊月花費查詢 ：客戶可對每月的話費進行查詢 （每項記錄包括通話費、 新業務費、費用合計、實繳費用合計等信息） 。帳戶余額查詢： 客戶可查詢話費單上的余額。用戶資料查詢： 客戶可以查閱個人資料。業務查詢： 客戶可以實時了解個部門的各項活動。計費模塊繳費信息 ：管理員可根據用戶所繳的話費進行計費， 并反饋給用戶，用戶在交費的同時可打印發票。基本信息更新模塊月

4、話費管理： 管理員可對每月的話費記錄進行逐條添加、更新和刪除。客戶受理結果： 管理員可對每月的話費記錄進行逐條添加、更新和刪除。（4） 數據流程圖（5） 數據字典數據項客戶受理表客戶資料表收款表通話信息表收費員表消費表數據結構 （1）數據結構名：客戶受理 組成結構:客戶姓名、受理號碼、受理內容 （2）數據結構名：客戶資料 組成結構:客戶姓名、聯系電話、聯系地址、套餐名稱、手機號碼、手機密碼 （3）數據結構名：收款 組成結構:手機號碼、客戶姓名、應收費用、余額 （4）數據結構名：通話信息 組成結構:來電號碼、去電號碼、通話時長、通話時間、單位費用、總費用 （5）數據結構名：收款員 組成結構:姓名

5、、密碼 （6）數據結構名：消費 組成結構:手機號碼、客戶姓名、通話費、新業務費、費用合計、套餐名稱數據流 （1）數據流名稱：登錄申請 輸入：客戶 輸出：用戶信息 （2）數據流名稱：登錄申請 輸入：收銀員 輸出：收銀員信息 （3）數據流名稱：查詢資料 輸入：客戶 輸出：資料信息 （4）數據流名稱：套餐查詢 輸入：客戶 輸出：套餐信息 （5）數據流名稱：客戶受理情況 輸入：收銀員 輸出：受理信息數據存儲 （1）數據存儲名：客戶信息 輸入數據流：客戶基本信息 輸出數據流：客戶信息 （2）數據存儲名：收營員信息 輸入數據流：收銀員基本信息 輸出數據流：收銀員信息 （3）數據存儲名：客戶費用信息 輸入數

6、據流：客戶各項費用信息 輸出數據流：客戶費用信息 （4）數據存儲名：客戶繳費信息 輸入數據流：客戶繳費信息 輸出數據流：客戶繳費信息處理過程 （1）處理過程名：登錄查看 輸入數據流：終端 輸出數據流：客戶信息 （2）處理過程名：登錄查看 輸入數據流：終端 輸出數據流：收銀員信息 （3）處理過程名：客戶受理 輸入數據流：客戶要求 輸出數據流：客戶受理情況 （4）處理過程名：客戶繳費 輸入數據流：客戶信息 輸出數據流：客戶 （5）處理過程名：顯示余額信息 輸入數據流：客戶信息 輸出數據流：客戶余額信息 （6）處理過程名：顯示套餐信息 輸入數據流：客戶信息 輸出數據流：客戶套餐信息5. 概念結構設計

7、 （1) 概述根據需求將分析階段形成的分析說明書，把用戶的信息需求抽象為信息結構即概念模型的過程就是概念設計。設計概念結構通常有自頂向下、自底向上、逐步擴張、混合策略 4 類方法。其中最常用的策略是自底向上方法。下面就用 E-R圖來描述顯示世界的概念模型。（2) 系統 E-R 圖 6.邏輯結構設計（1) 概述邏輯設計的任務就是把概念結構設計階段的設計好的基本 E-R 圖轉換為選用的 DBMS 產品所支持的數據模型項符合的邏輯結構設計。 設計邏輯結構時一般要分為兩步進行如下圖所示：（2) E-R圖向關系模型的轉換 實體及其屬性 客戶： 客戶姓名，聯系電話，聯系地址，套餐名稱 應收款額： 賬戶編號

8、，手機號碼，應收費用，余額 話費信息庫： 手機號碼， 客戶姓名， 通話費，新業務費， 費用合計，套餐名稱 收費員： 收費員編號，姓名，年齡 客戶受理： 手機號碼，客戶姓名，受理內容，受理時間 通話信息： 手機號碼，來電號碼，去電號碼，單位費用，通話時長，總費用 聯系的屬性 使用： 手機密碼 計費： 密碼根據轉換規則將實體轉換為關系模式本實例中沒有 1：1 關系對于 1：n 聯系，將它們與 n 端的關系模式合并。該關系模式中應加入 1 端的碼和聯系本身的屬性。客戶： 客戶姓名， 所在城市， 套餐名稱，手機號碼，手機密碼收費員： 收費員編號，姓名，年齡，手機號碼，密碼對于 m ：n 的聯系，必須單

9、獨轉換為一個關系模式，屬性由各實體的碼和聯系本身的屬性組成， 關系的碼為組成聯系各實體的碼的組合。支付： 客戶姓名，聯系電話，收費員編號處理： 手機號碼，收費員編號電話計費系統的 E-R 圖，轉換為以下 6 個關系模式 ：客戶： 手機號碼，所在城市，套餐名稱，客戶姓名，手機密碼收費員： 收費員編號，姓名，年齡，手機號碼，密碼話費信息：手機號碼，客戶姓名，通話費，費用合計，套餐名稱客戶受理：手機號碼，收費員編號，客戶姓名，受理內容，受理時間通話信息： 手機號碼，來電號碼，去電號碼，單位費用，通話時長，總費用 （3) 關系模式的規范化關系模式屬于第三范式，每個非主屬性都不傳遞函數依賴于主關系鍵。在

10、關系模式中， 對于客戶模式， 手機號碼為主屬性， 其余的為非主屬性， 非主屬性不傳遞依賴于手機號碼， 屬于第三范式。 對于收費員， 收費員編號為主屬性， 姓名，年齡，手機號碼，編號，密碼為非主屬性， 它們不傳遞依賴于主關系鍵收費編號，屬于第三范式。 對于客戶受理， 手機號碼和收費員編號為主屬性， 客戶姓名， 受理內容，受理時間為非主屬性， 手機號碼、收費員編號， 他們不依賴于手機號碼、收費員編號，屬于第三范式。對于應收款額、話費信息、通話信息，他們的非主屬性同樣不傳遞依賴于主屬性手機號碼，都屬于第三范式。7. 數據庫實施（1) 概述數據庫實施階段包括兩項重要的工作，一是數據集的載入，另一項就是應用程序的編碼和調式。8.總結過這次課程設計，從設計需求分析，到各模塊功能的設計及數據庫設計，我