[IT計算機]醫(yī)院需求分析文檔

1、醫(yī)院管理系統(tǒng)醫(yī)院管理系統(tǒng) 數據庫設計說明書數據庫設計說明書 (內部資料 請勿外傳) 編編 寫：寫： 日日 期：期： 檢檢 查：查： 日日 期：期： 審審 核：核： 日日 期：期： 批批 準：準： 日日 期：期： itit 有機公司有機公司 版權所有版權所有 不得復制不得復制 文檔編文檔編 號號 kf-0418-2012 版版 本本 a1 密密 級級 商商 密密 a 項目名項目名 稱稱 醫(yī)院管理系統(tǒng)醫(yī)院管理系統(tǒng) itit 有機公司軟件有機公司軟件 開發(fā)事業(yè)部開發(fā)事業(yè)部 項目來項目來 源源 xxxxxxxx 目錄目錄 醫(yī)院管理系統(tǒng)醫(yī)院管理系統(tǒng).1 數據庫設計說明書數據庫設計說明書.1 1引言引言.

2、2 1.1編寫目的.2 1.2術語表.2 1.3參考資料.3 2數據庫環(huán)境說明數據庫環(huán)境說明.3 3數據庫的命名規(guī)則數據庫的命名規(guī)則.3 4邏輯設計邏輯設計.3 5物理設計物理設計.4 5.1表匯總.4 5.2表x：xxx 表.4 5.3視圖的設計.6 5.4存儲過程、函數及觸發(fā)器的設計.6 6安全性設計安全性設計.6 6.1防止用戶直接操作數據庫的方法.6 6.2用戶帳號密碼的加密方法.7 6.3角色與權限.7 7優(yōu)化優(yōu)化.7 8數據庫管理與維護說明數據庫管理與維護說明.7 1引言引言 1.1 編寫目編寫目的的 在完成了對醫(yī)院各個部門的調查后,同時與多名病人進行了全面 深入地探討和分析的基礎

3、上,提出了這份系統(tǒng)需求分析報告. 此需求分析報告對醫(yī)院管理利通做了全面細致的用戶需求分析， 明確所要開發(fā)的系統(tǒng)應具備的功能、性能與界面，使系統(tǒng)分析人員 及軟件開發(fā)人員能清楚地了解用戶的需求，并在此基礎上進一步提 出概要設計說明書和完成后續(xù)設計與開發(fā)工作。此外，這份需求分 析報告中介紹了我們系統(tǒng)的框架結構，明確了該系統(tǒng)的方向及用途， 是客戶了解我們系統(tǒng)的一份詳細資料，本分析報告的預期讀者為客 戶、業(yè)務或需求分析人員、測試人員、用戶文檔編寫者、項目管理 人員。 此分析報告是整個系統(tǒng)開發(fā)的依據，它對以后階段的工作起指 導作用。本文也是項目完成后系統(tǒng)驗收的依據。 1.2 術語表術語表 序號術語或縮略語

4、說明性定義 1papatient 病人 2dodoctor 醫(yī)生 3pbpatient-bed 病床 4prpatient-room 病房 5zrzhuyuan-register 住院登記 6trtrue-record 治療記錄 1.3 參考資料參考資料 資料名稱資料名稱作者作者文件編號、版本文件編號、版本資料存放地點資料存放地點 數據庫原理及應用何玉潔機械工程出版社圖書館 sql server 使用教程范立南清華大學出版社圖書館 數據庫應用技術張蒲生機械工業(yè)出版社圖書館 2.數據庫環(huán)境說明數據庫環(huán)境說明 2.1 網絡邏輯結構網絡邏輯結構 本次設計基于的網絡邏輯結構是客戶/服務器（c/s）體系

5、結構。 它由三個主要部分構成：數據庫服務器、客戶應用程序和網絡?；?于 c/s 的住院管理系統(tǒng)的結構示意圖如圖所示 2.2 軟件支撐環(huán)境及開發(fā)工具軟件支撐環(huán)境及開發(fā)工具 在 windows xp 操作系統(tǒng)下完成 包括應用程序的開發(fā)、數據庫的設計以及設計報告的編寫 應用的開發(fā)工具有： vc 程序設計語言 sql server 2000 microsoft office word 2003 3.數據庫的命名規(guī)則數據庫的命名規(guī)則 3.1.1 此數據庫完全按照 my sql 數據庫設計規(guī)范命名。 表名命名依據英文單詞全稱。 列名命名依據整個列的屬性取相應的英文縮寫或拼音縮寫 4.系統(tǒng)需求簡介系統(tǒng)需求簡

6、介 4.1.1 總體需求簡單介紹總體需求簡單介紹 1 建立對醫(yī)院全面管理的信息系統(tǒng) 2 對所有醫(yī)生和病人進行管理 3 對所有部門的詳細信息進行管理 4 對所有醫(yī)生的詳細信息進行管理 1系統(tǒng)的功能實現情況系統(tǒng)的功能實現情況: 用戶可在本系統(tǒng)下實現各種用戶要求的功能 2系統(tǒng)的安全性系統(tǒng)的安全性: 對于系統(tǒng)的重要數據都有密碼保護，具有一定的安全性 對用戶提供證書支持（此功能在后續(xù)版本中實現） 3 3系統(tǒng)的容錯性系統(tǒng)的容錯性: 用戶輸錯數據都有提示信息，具有較好的容錯性能。 4系統(tǒng)的封閉性系統(tǒng)的封閉性: 用戶的封閉性較好，用戶基本上在提示信息下輸數據 4.1.2 數據字典數據字典 數據項數據項 數據結

7、構數據結構 數據結構含義說明組成 病人定義了每個病人的有關信息 病案號，姓名，性別，地址， 電話號碼，病房編號，醫(yī)生 編號 醫(yī)生定義了每個醫(yī)生的有關信息 醫(yī)生編號，姓名，性別，職 稱，電話號碼，部門，月工 資 病房定義了每個病房的有關信息 病房編號，地點，收費標準， 所屬部門 病床定義了每個病床的有關信息病房編號，病床號 數據項含義說明類型長度取值范圍取值含義 與其他數據項的邏輯 關系 病案號 唯一標識每 個病人 字符型15 000000000000000 至 999999999999999 前兩位標明 該病人所掛 診的部門， 后十三位按 順序編號 與住院登記，治療記錄用此數 據項相聯系 醫(yī)生

8、編號 唯一標識每 個醫(yī)生 字符型10 0000000001 至 9999999999 前兩位表示 所屬部門， 后八位按順 序編號 與治療記錄用此數據項相聯系 病房編號 唯一標識每 個病房 字符型40001 至 9999 前兩位表示 所屬部門， 后兩位按順 序編號 與病床，住院登記用此數據相 聯系 床位號 唯一標識每 個病床 字符型3001 至 999 前兩位表示 所屬病房， 后兩位按順 序編號 引用病房主碼做病床表的外碼， 與住院登記用此數據相聯系 日期，病案 號 唯一標識每 個住院登記 date,字 符型 10,15 日期的取值范圍， 病案號引用病人 表的主碼 表示每個住 院登記的記 錄 聯

9、系病人和住院登記 病案號，醫(yī) 生編號 唯一標識每 個治療記錄 字符型15，10 病案號引用病人 表的主碼，醫(yī)生 編碼引用醫(yī)生表 的主碼 表示每個治 療記錄的情 況 聯系病人和醫(yī)生 住院登記定義了每個住院登記的有關信息 日期，病案號，入院日期， 出院日期，病房編號，床位 號，住院費用 數據流數據流 數據流：病人診斷情況 說明：病人病情的最終結果 數據流來源：病人 數據流去向：醫(yī)生 組成：病人，住院登記，治療記錄 平均流量：每天幾百人 高峰期流量：每天幾千人 數據存儲數據存儲 數據存儲：病人入院登記 說明：記錄病人的基本情況 流入數據流：住院登記 流出數據流：住院登記 組成：病人，醫(yī)生，住院登記，

10、治療記錄 數據量：每天幾百張 存取頻度：每人一次 存取方式：隨機存取 處理邏輯處理邏輯 處理名稱：生成病人就醫(yī)情況總表 說明：說明處理過程 輸入數據流：病人，治療記錄 輸出數據流：住院登記 處理邏輯：記錄病人診治記錄，形成治療記錄，匯總成病人住院 登記，再生成總表 平均執(zhí)行頻率：每天幾百次 （說明：以上平均頻率需長期觀察得到） 數據流圖圖元數據流圖圖元 4.1.3 系統(tǒng)功能設想系統(tǒng)功能設想 這里的功能劃分，是根據第一階段需求調查基礎上進行的初步劃 分。隨著需求調查的深入，功能模塊隨著對需求了解的明確得到調 整。 醫(yī)院管理系統(tǒng)的四個主要部分,可以將系統(tǒng)應用程序劃分為對應 的 4 個子模塊:包括醫(yī)

11、生管理系統(tǒng),病人管理系統(tǒng),病房管理系統(tǒng),科室 管理系統(tǒng). 根據各業(yè)務子系統(tǒng)所包括業(yè)務內容,還可以將各個子系統(tǒng) 繼續(xù)細化劃分為更小的功能模塊。劃分的準則主要遵循模塊的內聚 性要求和模塊間的低聚合性。如圖所示表示一個醫(yī)院管理系統(tǒng)功能 模塊結構圖。 醫(yī)生病人診治 醫(yī)生 編 號 醫(yī)生 屬 性 病案 號 病人 屬 性 應用系統(tǒng) 醫(yī)生管理病人管理病房管理系統(tǒng)管理 治療病人 信息 醫(yī)生的詳細信 息 病人的詳細 信息 各科室醫(yī)生及 病人信息 所有部門科室 信息 住院信息 4.1.4 業(yè)務流程分析業(yè)務流程分析 簡單醫(yī)院流程圖簡單醫(yī)院流程圖 收 費 單 請 住 院 單 請 住院申請病人信息 圖圖 4-1 入院數據

12、流圖入院數據流圖 病人 查看 信 息 病人病案 病人 分配 床 位 病房信息 產生收費 單及住院 單 治療方案出示病歷病人 醫(yī)生 診 斷 病人病歷 病人檢查情況 給出治 療方案 方 案 病人 圖圖 4-2 治療數據流圖治療數據流圖 申請出院繳費單病人 病人病案 收費準則 病歷 歸 檔 費用 統(tǒng) 計 病人 圖圖 4-3 出院數據流圖出院數據流圖 5.概念設計概念設計 5.1.1 實體實體 病房（病房編號，地點，收費標準，所屬科室） 病床（病房編號，床位號） 病人（病案號，姓名，性別，地址，電話號碼，病房編號，醫(yī) 生編號） 醫(yī)生（醫(yī)生編號，姓名，性別，職稱，電話號碼，部門，工資） 住院登記（日期，

13、病案號，入院時間，出院時間，病房編號， 床位號，住院費用） 治療記錄（治療時間，病案號，醫(yī)生編號，診斷，治療方案） 5.1.2 系統(tǒng)局部系統(tǒng)局部 er 圖圖 n 人 1 人 醫(yī)生病人 治療 診斷 治療方案 圖圖 4-8 病人與醫(yī)生聯系圖病人與醫(yī)生聯系圖 治療時間 n 人 1 人 擁有 病房病床 病房 n 人 1 人 住在 病人 圖圖 4-9 病人與病房及病房與病床聯系圖病人與病房及病房與病床聯系圖 n1 病人住院登記 登記 5.1.3 系統(tǒng)全局系統(tǒng)全局 er 圖圖 出院時間 病房病房 地點 收費標準 所屬部門 病房編號 n 1 1 n 1 病房編號 床位號 治療時間 部門 電話號碼 職稱 性別

14、 姓名 醫(yī)生編號 圖圖 4-11 醫(yī)院住院數據庫基本醫(yī)院住院數據庫基本 e-r 圖圖 n n 1 n 1 病床病床 病人病人 醫(yī)生醫(yī)生 病案號 姓名 性別 地址 電話號碼 病房編號 病案號 病房編號 床位號 診斷 日期 入院時間 治療方案 治 療 住在 住院登記住院登記 擁有 登記 分配 醫(yī)生編號 住院費用 工資 6.邏輯設計邏輯設計 6.1.1 e-r 圖到關系模式轉換圖到關系模式轉換 按照上述的原則，根據設計好的 e-r 圖，可以將其轉換為以下 一組關系模式，其中關系模式的碼用下橫線標出。 將 e-r 圖中 1:1 的聯系與任意一端所對應的關系模式合并。 將 e-r 圖中 1：n 的聯系與

15、 n 端所對應的關系模式合并，如：將 “病床”這一聯系并到“病房”關系模式； 將 e-r 圖中 m:n 的聯系轉換為一個獨立的關系模式。 病房（病房（病房編號病房編號，地點，收費標準，所屬科室），地點，收費標準，所屬科室） 此為病房實體型所對應的關系模式。其中病房編號唯一確定一 個病房，所以為該關系模式的碼。 病床（病床（病房編號，床位號病房編號，床位號） 此為病床實體型所對應的關系模式。由于病房編號是病房關系 模式的碼，所以在該關系模式中病房編號為外碼。 病人（病人（病案號病案號，姓名，性別，地址，電話號碼，病房編號，姓名，性別，地址，電話號碼，病房編號， 醫(yī)生編號）醫(yī)生編號） 此為病人實體

16、型所對應的關系模式。其中病案號為此關系模式 的碼，而病房編號，醫(yī)生編號 為該關系模式的外碼。 醫(yī)生（醫(yī)生（醫(yī)生編號醫(yī)生編號，姓名，性別，職稱，電話號碼，部門，工，姓名，性別，職稱，電話號碼，部門，工 資）資） 此為醫(yī)生實體型所對應的關系模式。其中醫(yī)生編號唯一確定一 個醫(yī)生，所以為該關系模式的碼。 住院登記（住院登記（日期，病案號日期，病案號，入院時間，出院時間，病房編號，入院時間，出院時間，病房編號， 床位號）床位號） 此為住院登記實體型所對應的關系模式。其中，日期和病案號 共同確定一個住院登記，病房編號為該關系模式的外碼。 治療記錄（治療記錄（治療時間，病案號，醫(yī)生編號治療時間，病案號，醫(yī)生

17、編號，診斷，治療方案），診斷，治療方案） 此為聯系“治療”所對應的關系模式。其中，病案號和醫(yī)生編號 都是該關系模式的外碼。 6.1.2 各個數據表的表結構設計各個數據表的表結構設計 patientpatient 的數據項描述的數據項描述： 數據項名數據項含義類型長度備注 病案號病人的編號 (pno) int15對應唯一一個病人 姓名病人姓名 (pname) char20 性別病人性別 (psex) char2只能取男或 女 地址病人住址 (paddr) varchar100 電話病人電話 (ptel) smallint10 病房編號病人病房 （pro） char4住院時由系統(tǒng)分配 醫(yī)生編號主治

18、醫(yī)生 （ppno） int15 一位病人只能對應一 位主治醫(yī)生 patient-roompatient-room 的數據項描述的數據項描述： 數據項名數據項含義類型長度備注 編號病房編號 (rno) int15病房編號唯一 地點病房位置 (radd) char20非空 收費標準住院收費 （rcha） int15單位為（元/天） 所屬部門病房所屬部門 （rbu） vaechar20一間病房只能屬于一 個部門 patient-bedpatient-bed 的數據項描述的數據項描述： 數據項名數據項含義類型長度備注 病房編號病房編號 （rno） int15唯一確定，引用病房 的外碼 床位號病房床位

19、（rbe） int15唯一確定，一個病房 一般有 1-3 個床位 doctordoctor 的數據項描述：的數據項描述： 數據項名數據項含義類型長度備注 編號醫(yī)生編號 (dno) int15對應唯一一個醫(yī)生 姓名醫(yī)生姓名 (dname) char20非空 性別醫(yī)生性別 (dsex) char2只能取男或 女 職稱醫(yī)生職稱 (dzhi) varchar20有可能有多個職稱 電話醫(yī)生電話 (dtel) smallint10 部門所屬部門 (dbu) varchar20 工資醫(yī)生工資 （dsa） int20 zhuyuan-registerzhuyuan-register 的數據項描述：的數據項描述

20、： 數據項名數據項名數據項含義數據項含義類型類型長度長度備注備注 日期登記日期 (rad) char10唯一標識 病案號病案號 （pno） int15唯一標識，引用病人 外碼 入院時間入院時間 （iti） char10 出院時間出院時間 （gti） char10必須在入院時間之后 病房編號病房號 （rno） int15引用病房表的外碼 病床編號病床號 （rbe0 int15引用病床表的外碼 true-recordtrue-record 的數據項描述的數據項描述： 數據項名數據項名數據項含義數據項含義類型類型長度長度備注備注 時間治療日期 (time) char8入院和出院時間之間, 唯一標識

21、病案號病案號 （pno） int15唯一標識，引用病人 外碼 醫(yī)生編號主治醫(yī)生 （dno） int15唯一標志，引用醫(yī)生 外碼 診斷病情診斷 （tre） varchar50醫(yī)生診斷結果 治療方案治療方案 （mea） varchar200醫(yī)生給出的治療方案 7、物理設計、物理設計 7.1 表匯總 表名表名功能說明功能說明 表 patient病人表，屬性列有病案號、姓名、性別、地址、電話、病房編號、醫(yī)生 編號。主碼是病案號，外碼是醫(yī)生編號。病人可以查看關于自己的屬性 列及住院信息。 表 doctor 醫(yī)生表，屬性有醫(yī)生編號、姓名、性別、職稱、電話號碼、部門。醫(yī)生 編號是主碼。醫(yī)生可以查看自己的屬性

22、列及病人病情狀況。 表 patient-room 病房表，屬性列有病房編號、地點、收費標準、所屬科室。病房編號是 主碼。病房表的創(chuàng)建便于醫(yī)生查看治療病人的住院地點、便于病人明確 自己的收費標準。 表 patient-bed 病床表，主碼為病房編號和床位號。外碼為病房編號。此表方便病房管 理員進一步掌握各病人的詳細床位信息。 表 true-register治療記錄表，治療時間、病案號、醫(yī)生編號共同為主碼。此表由病房管 理員對于每一位住院的病人進行分配登記。醫(yī)生查詢此表可以了解所醫(yī) 治病人的診斷信息并提出治療方案。 表 zhuyuan-register 住院登記表，主碼為日期和病案號，屬性列有入院

23、時間、出院時間、病 房編號、床位號。外碼為病案號、病房編號、床位號。 7.27.2 表表 7.2.17.2.1 表名 patientpatient 數據庫用戶 病人 主鍵病案號 其他排序字段病人姓名，性別，地址，電話號碼，病房編號，醫(yī)生編號 索引字段病案號 序號字段名稱數據類型（精度 范圍） 允許 為空 y/n 唯一 y/n 區(qū)別度默認值約束條件/說明 1pnoint(15)ny 高主碼 2pnamechar(20)nn 中 3psexchar(2)yn 低男必須是“男”或 者“女” 4paddvarchar(100)yn 中 5ptelsmallint(10)yn 中 6prochar(4)

24、nn 低 7ppnoint(15)yn 低一位病人只能對 應一位主治醫(yī)生 的醫(yī)生編號（引 用醫(yī)生表中的醫(yī) 生編號外碼） mysql 腳本 create table( pno int(15) primary key not null， pname char(20） ， psex char(2) default 男 check(男,女), padd varchar(100), pro char(4), ppno int(15) foreign key) 7.2.27.2.2 表名 doctordoctor 數據庫用戶醫(yī)生 主鍵醫(yī)生編號 其他排序字段醫(yī)生姓名，性別，職稱，電話，部門，工資 索引字段醫(yī)

25、生編號 序號字段名 稱 數據類型 （精度范圍） 允 許 為 空 y/n 唯一 y/n 區(qū)別 度 默認 值 約束條件/說明 1dnoint(15)ny 高主碼 2dnamechar(20)nn 中 3dsexchar(2)yn 中男必須是“男”或 者“女” 4dzhivarchar(20 ) nn 低 5dtelsmallint(10)yn 中 6dbuvarchar(20 ) nn 低 7dsaint(20)yn 低 mysql 腳本 create table（ dno int(15) primary key, dname char(20), dsex char(2) default 男 ch

26、eck(男,女), dzhi varchar(20), dtel smallint(10), dbu varchar(20), dsa int(20), ) 7.2.37.2.3 表名 proom 數據庫用戶病房管理員、病人 主鍵病房編號 其他排序字段地點，收費標準，所屬部門 索引字段病房編號 序號字段名稱數據類型 （精度范 圍） 允許 為空 y/n 唯一 y/n 區(qū)別 度 默認 值 約束條件/說明 1rnoint(15)ny 高主碼 2raddchar(20)nn 中非空 3 rchaint(15) yn 低 4 rbum varchar( 20) nn 低 mysql 腳本 create

27、table proom （rno int(15) primary key, radd char(20) not null, rcha int(15), rbum varchar(20), ) 7.2.47.2.4 表名 pbedpbed 數據庫用戶病房管理員 主鍵病房編號和床位號 序號字段名 稱 數據類型 （精度范 圍） 允許 為空 y/n 唯一 y/n 區(qū)別 度 默認 值 約束條件/說明 1 rnoint(15) ny 高主碼，引用 proom 的外碼 2 rbeint(15) ny 高主碼 mysql 腳本 create table pbed (rno int(15) references

28、 proom(床位號) rbe int(15) primary key) 7.2.57.2.5 表名 zhuyuan-register 數據庫用戶病房管理員、病人 主鍵日期和病案號 序號字段名 稱 數據類型 （精度范 圍） 允許 為空 y/n 唯一 y/n 區(qū)別 度 默認 值 約束條件/說明 1rda char(10) ny 高主碼 2pno int(15) ny 高主空 ，引用病 人表的外碼 3iti char(10) nn 低 4gti char(10) nn 低 5rno int(15) yn 低 引用病房表的 外碼 6rbe int(15) yn 引用病床表的 外碼 mysql 腳本

29、create table zhuyuan-register (rda char(10) primary key, pno int(15) references patient(pno) not null, iti char(10), gti char(10), rno int(15) references proom(rno), rbe int(15) references pbed(rbe), ) 7.2.67.2.6 表名 true-record 數據庫用戶病房管理員、醫(yī)生 主鍵治療時間，病案號和醫(yī)生編號 序號字段名 稱 數據類型（精 度范圍） 允許 為空 唯 一 區(qū)別 度 默認 值 約束

30、條件/說明 y/ny/ n 1 timechar(8) ny 高主碼 2 pnoint(15) yy 高主碼，引用病 人表的外碼 3 dnoint(15) yy 高主碼，引用醫(yī) 生表的外碼 4 trevarchar(50) yn 低 5 dnovarchar(200) yn 低 mysql 腳本 create table true-record (time char(8) primary key, pno int(15) references patient(pno), dno int(15) references doctor(dno), tre varchar(50), mea varch

31、ar(200) ) 7.1.37.1.3 視圖的設計視圖的設計 病人能看到的視圖病人能看到的視圖 每個視圖采用一張表格進行描述，其格式如下： 數據庫編號：kf-001-2012 視圖編號：p-001-2012 視圖英文名稱：patient 視圖中文名稱：病歷 視圖說明：病人可以看到入院出院日期，就醫(yī)花費，且只能看到自 己的部分 create view v_patient as select patient.pno,pname,rdate,ruyuandate,chuyuandate,rno,bedno,pafee from patient join zhuyuan-record on pati

32、ent.pno=zhuyuan-record.pno 醫(yī)生能看到的視圖醫(yī)生能看到的視圖 數據庫編號：kf-001-2012 視圖編號：d-002-2012 視圖英文名稱：doctor 視圖中文名稱：醫(yī)生 視圖說明：醫(yī)生可以看到工資，負責的病人的治療概況，且只能看 到自己的部分 create view v_doctor as select doctor.dno,dname,dkeshi,dpay,pno,pail,zhiliaofangan from doctor join treat-gister on doctor.dno=treat-gister.dno 系統(tǒng)管理員可以看到的視圖系統(tǒng)管理員

33、可以看到的視圖 數據庫編號：kf-001-2012 視圖編號：all-003-2012 視圖英文名稱：all-data 視圖中文名稱：全部數據 視圖說明：管理員可以看到醫(yī)生病人的對應關系，病人繳納費用， 住院時間，所有醫(yī)生工資， create view v_all_data as select patient.pno,pname,doctor.dno,dname,pafee,dpay,dkeshi,zhuyuandate,chu yuandate,paill,date from patient join zhuyuan-record on patient.pno=zhuyuan-record.

34、pno join treat-gister on patient.pno=treat-gister.pno join doctor on treat- gister.dno=doctor.dno 7.1.47.1.4 觸發(fā)器的設計及函數設計觸發(fā)器的設計及函數設計 1.錄用（新鍵入）的醫(yī)生的年齡必須在五十歲以下 crate trigger p_age on 醫(yī)生 for insert,update as if exists(select * from inserted where page50) begin print醫(yī)生年齡應小于五十 rollback end 2.醫(yī)生的最低工資應該大于 13

35、00 元 crate trigger doc_salary1 on 醫(yī)生 for insert,update as if exists (select * from inserted where 最低工資23) begin print病房號應小于 23 rollback end end 8 8 安全設計安全設計 8.1.18.1.1 安全防護安全防護 對數據庫存儲敏感信息： 針對本系統(tǒng)我們對用戶密碼進行加密，以保證各級用戶對系統(tǒng) 訪問的安全性。生成的口令不可逆轉（用 md5 加密是一種 32 位字 符的加密方法） 。輸入的口令不應顯示在顯示終端上。 數據信息的保存： 利用 rdbms 的服務器

36、穩(wěn)定運行實現各種信息的儲存、控制及 調節(jié)備份、恢復等日常的維護管理工作。在軟件園后期的項目中建 立異地備份服務器后備份數據進行異地保存。 8.1.28.1.2 操作跟蹤操作跟蹤 針對系統(tǒng)運行出現的異常，跟蹤調查出現異常的情況，了解操 作意圖，有針對性的解決問題。 系統(tǒng)日志，便于查看系統(tǒng)的運行情況。 操作日志, 提供用戶在系統(tǒng)中增加、修改系統(tǒng)數據信息時記錄 日志。用于跟蹤用戶的操作，了解信息的變更，在需要時對事情進 行調查 8.1.38.1.3 訪問控制訪問控制 頁面不可直接訪問，防止黑客對頁面篡改。頁面訪問通過連接動 作驅動，訪問時作權限檢查。有效防止用戶通過地址欄輸入地址對 信息非法訪問。系

37、統(tǒng)在頁面執(zhí)行過一次后再次訪問通過緩沖工作區(qū) 執(zhí)行，對頁面屏蔽。 易用性 醫(yī)院管理系統(tǒng)要簡單、易用，具有清晰的導航功能，使操作者快 速找到自己想要執(zhí)行的操作頁面。 醫(yī)院管理系統(tǒng)要保證一個非計算機專業(yè)的用戶，通過自己閱讀用 戶手冊，可以使用此系統(tǒng)。 8.28.2 角色與權限角色與權限 角色或者執(zhí)行者（actor）是指與系統(tǒng)產生交互的外部用戶或者 外部系統(tǒng)，本系統(tǒng)主要包括病人，醫(yī)生，病房管理員和系統(tǒng)管理員 等角色（actor） 。 8.2.1 角色管理角色管理 可以對單個角色進行添加、修改、刪除和查詢等維護操作，可以 針對不同的角色選擇對應的權限進行設置。 用例描述：角色管理 執(zhí)行者：系統(tǒng)管理員 前

38、置條件：系統(tǒng)管理員已登錄系統(tǒng) 后置條件：角色信息維護后，相應信息記錄到數據庫中，以供帳號 授權使用 基本路徑： a) 進入角色管理界面，顯示目前的角色列表； b) 點擊不同的角色，可以顯示這個角色的信息以及相應權限，必要 時可以修改其權限； c) 可以增加、修改、刪除角色。 8.2.28.2.2 角色創(chuàng)建角色創(chuàng)建 角色角色可以訪問的表與列可以訪問的表與列操作權限操作權限 patient 表查詢 patient-room 表查詢 zhouyuan-record 表查詢 病人 cure-gister 表查詢 doctor 表查詢醫(yī)生 cure-gister 表查詢 proom 表查詢，插入， 刪除

39、 patient 表查詢，插入， 刪除 patient-bed 表查詢，修改 zhuyuan-record 表查詢，修改 病房管理員 cure-gister 表查詢，插入， 修改，刪除 patient-room 表查詢，插入， 修改，刪除 doctor 表查詢，插入， 修改，刪除系統(tǒng)管理員 patient 表查詢，插入， 修改，刪除 patient-bed 表查詢，插入， 修改，刪除 zhuyuan-record 表查詢，插入， 修改，刪除 cure-gister 表查詢，插入， 修改，刪除 8.38.3 應用級用戶設計應用級用戶設計 應用級的用戶賬號密碼不能與數據庫想通，防止用戶直接操作 數

40、據庫。用戶只能用賬號登錄到應用軟件，通過應用軟件訪問數據 庫，而沒用其他途徑操作數據庫。 8.3.18.3.1 登錄管理登錄管理 登錄管理是負責所有用戶的登錄，用戶要登錄到綜合信息管 理平臺必須經過登錄界面，輸入自己的用戶名和密碼，通過判斷 這個用戶的權限信息，不同的登錄人可能具有不同的權限，根據 不同的權限現實不同的功能。 8.3.2 用戶管理用戶管理 當進入用戶管理模塊時，在用戶管理中可以增加或刪除用 戶，編輯用戶名，用戶密碼，修改用戶權限，具有不同權限的用 戶進入系統(tǒng)主界面，界面左側欄中的圖標數有所不同，具體的面 標與用戶所具有的權限對應。 8.3.3 日志查詢日志查詢 實現對用戶的所有

41、操作過程的歷史日志查詢。查詢結果以列 表方式顯示，可以根據查詢條件進行過濾。 8.48.4 用戶密碼管理用戶密碼管理 用戶賬號的密碼必須進行加密處理，確保在任何地方的查詢都 不能出現密碼的明文。 用戶帳號采用 md5 進行數據加密后再錄入數據庫，以防止任何地 方密碼的安全性要求。 8.58.5 防止用戶直接操作數據庫的方法防止用戶直接操作數據庫的方法 建立應用程序角色，給角色相應的權限，然后應用程序以各自 的用戶登錄就可以了（scott 是一個系統(tǒng)已經新建好的普通用戶用戶 名 scott，密碼默認 tiger，默認狀態(tài)是被定,dba 用戶執(zhí)行 alter user scott account

42、unlock;可以解鎖登陸） 8.6 性能測試性能測試 8.6.1 性能需求性能需求 根據用戶對本系統(tǒng)的要求，確定系統(tǒng)在響應時間、可靠性、 安全性等方面有較高的性能要求。 8.6.2 界面需求界面需求 系統(tǒng)的界面要求如下： ）頁面內容：主題突出，站點定義、術語和行文格式統(tǒng) 一、規(guī)范、明確，欄目、菜單設置和布局合理，傳遞的信息 準確、及時。內容豐富，文字準確，語句通順；專用術語規(guī) 范，行文格式統(tǒng)一規(guī)范。 ）導航結構：頁面具有明確的導航指示，且便于理解，方 便用戶使用。 ）技術環(huán)境：頁面大小適當，能用各種常用瀏覽器以不同 分辨率瀏覽；無錯誤鏈接和空鏈接；采用 css 處理，控制字體大 小和版面布局

43、。 ）藝術風格：界面、版面形象清新悅目、布局合理,字號大 小適宜、字體選擇合理，前后一致，美觀大方；動與靜搭配恰當,動 靜效果好；色彩和諧自然,與主題內容相協(xié)調。 8.6.3 響應時間需求響應時間需求 無論是客戶端和管理端，當用戶登錄，進行任何操作的時候， 系統(tǒng)應該及時的進行反應，反應的時間在 5 秒以內。系統(tǒng)應能監(jiān) 測出各種非正常情況，如與設備的通信中斷，無法連接數據庫服 務器等，避免出現長時間等待甚至無響應。 8.6.4 可靠性需求可靠性需求 系統(tǒng)應保證 7x24 內不當機，保證 20 人可以同時在客戶端登 錄，系統(tǒng)正常運行，正確提示相關內容。 8.6.5 開放性需求開放性需求 系統(tǒng)應具有

44、十分的靈活性，以適應將來功能擴展的需求。 8.6.6 可擴展性需求可擴展性需求 系統(tǒng)設計要求能夠體現擴展性要求，以適應將來功能擴展的需求。 8.6.7 系統(tǒng)安全性需求系統(tǒng)安全性需求 系統(tǒng)有嚴格的權限管理功能，各功能模塊需有相應的權限方能進 入。系統(tǒng)需能夠防止各類誤操作可能造成的數據丟失，破壞，同時 防止用戶非法獲取網頁以及內容。 8.78.7 優(yōu)化優(yōu)化 數據庫優(yōu)化的目標無非是避免磁盤 i/o 瓶頸、減少 cpu 利用率 和減少資源競爭。 8.7.1 基于第三范式的基本表設計基于第三范式的基本表設計 在基于表驅動的信息管理系統(tǒng)（mis）中，基本表的設計規(guī)范 是第三范式。第三范式的基本特征是非主屬

45、性只依賴于主屬性?；?于第三范式的數據庫表設計具有很多優(yōu)點： 1.消除了冗余數據，節(jié)省了磁盤存儲空間； 2.有良好的數據完整性限制，即基于主外碼的參照完整限制和 基于主碼的實體完整性限制，這使得數據容易維護，也容易移 植和更新； 3.數據的可逆性好，在做連接（join）查詢或者合并表時不遺 漏、也不重復； 4.因消除了冗余數據（冗余列），在查詢（select）時每個數據 頁存的數據行就多，這樣就有效地減少了邏輯 i/o，每個 cash 存的頁面就多，也減少物理 i/o； 5.對大多數事務(transaction)而言，運行性能好； 6.物理設計(physical design)的機動性較大，能

46、滿足日益增長的 用戶需求。 在基本表設計中，表的主碼、外碼、索引設計占有非常重要的 地位，現在從系統(tǒng)數據庫優(yōu)化角度討論這些基本概念及其重要意義： （1）主碼(primary key)： 主碼被用于復雜的 sql 語句時，頻繁地在數據訪問中被用到。 一個表只有一個主碼。主碼應該有固定值（不能為 null 或缺省值， 要有相對穩(wěn)定性），不含代碼信息，易訪問。 把常用的列作為主碼才有意義。短主碼最佳（小于 25bytes）， 主碼的長短影響索引的大小，索引的大小影響索引頁的大小，從而 影響磁盤 i/o。 主碼分為自然主碼和人為主碼。自然主碼由實體的屬性構成， 自然主碼可以是復合性的，在形成復合主碼時

47、，主碼列不能太多， 復合主碼使得 join 操作復雜化、也增加了外碼表的大小。人為主碼 是在沒有合適的自然屬性碼、或自然屬性復雜或靈敏度高時，人為 形成的。人為主碼一般是整型值（滿足最小化要求），沒有實際意 義，也略微增加了表的大??；但減少了把它作為外碼的表的大小。 （2）外碼（foreign key）： 外碼的作用是建立關系型數據庫中表之間的關系（參照完整性） ，主碼只能從獨立的實體遷移到非獨立的實體，成為后者的一個屬 性，被稱為外碼。 （3）索引(index)： 利用索引優(yōu)化系統(tǒng)性能是顯而易見的，主要有以下幾個方面： 1.對所有常用于查詢中的 where 子句的列和所有用于排序的 列創(chuàng)建索

48、引，可以避免整表掃描或訪問，在不改變表的物 理結構的情況下，直接訪問特定的數據列，從而減少數據 存取時間； 2.利用索引可以優(yōu)化或排除耗時的分類操作，把數據分散到不 同的頁面上，就分散了插入的數據； 3.主碼自動建立了唯一索引，因此唯一索引也能確保數據的唯 一性（即實體完整性）； 4.索引碼越小，定位就越直接； 5.新建的索引效能最好，因此定期更新索引非常必要。 索引也有代價： 有空間開銷，建立它也要花費時間，在進行 insert、delete 和 update*作時，也有維護代價。 索引有兩種：聚族索引和非聚族索引。 一個表只能有一個聚族索引，可有多個非聚族索引。使用聚 族索引查詢數據要比使

49、用非聚族索引快。在建索引前，應利用數 據庫系統(tǒng)函數估算索引的大小。 聚族索引（clustered index）：聚族索引的數據頁按物理有序 儲存，占用空間小。 選擇策略是被用于 where 子句的列：包括范圍查詢、模糊查詢 或高度重復的列（連續(xù)磁盤掃描）；被用于連接 join 操作的列；被 用于 order by 和 group by 子句的列。聚族索引不利于插入操作， 另外沒有必要用主碼建聚族索引。 非聚族索引（nonclustered index）：與聚族索引相比，占用空 間大，而且效率低。選擇策略是，被用于 where 子句的列：包括范 圍查詢、模糊查詢（在沒有聚族索引時）、主碼或外碼列

50、、點（指 針類）或小范圍（返回的結果域小于整表數據的 20%）查詢；被用 于連接 join 操作的列、主碼列（范圍查詢）；被用于 order by 和 group by 子句的列；需要被覆蓋的列。對只讀表建多個非聚族索引 有利。 索引也有其弊端，一是創(chuàng)建索引要耗費時間，二是索引要占有 大量磁盤空間，三是增加了維護代價（在修改帶索引的數據列時索 引會減緩修改速度）。 （4）鎖：鎖是并行處理的重要機制，能保持數據并發(fā)的一致性， 即按事務進行處理；系統(tǒng)利用鎖，保證數據完整性。因此，我們避 免不了死鎖，但在設計時可以充分考慮如何避免長事務，減少排它 鎖時間，減少在事務中與用戶的交互，杜絕讓用戶控制事務

51、的長短； 要避免批量數據同時執(zhí)行，尤其是耗時并用到相同的數據表。鎖的 征用：一個表同時只能有一個排它鎖，一個用戶用時，其它用戶在 等待。若用戶數增加，則 server 的性能下降，出現“假死”現象。如 何避免死鎖呢？從頁級鎖到行級鎖，減少了鎖征用；給小表增加無 效記錄，從頁級鎖到行級鎖沒有影響，若在同一頁內競爭有影響， 可選擇合適的聚族索引把數據分配到不同的頁面；創(chuàng)建冗余表；保 持事務簡短；同一批處理應該沒有網絡交互。 （5）查詢優(yōu)化規(guī)則： 在訪問數據庫表的數據(access data)時，要盡可能避免排序 （sort）、連接(join)和相關子查詢*作。經驗告訴我們，在優(yōu)化查 詢時，必須做到

52、： 盡可能少的行； 避免排序或為盡可能少的行排序，若要做大量數據排序，最好 將相關數據放在臨時表中*作；用簡單的碼（列）排序，如整型或短 字符串排序； 避免表內的相關子查詢； 避免在 where 子句中使用復雜的表達式或非起始的子字符串、 用長字符串連接； 在 where 子句中多使用“與”（and）連接，少使用“或”(or)連 接； 利用臨時數據庫。在查詢多表、有多個連接、查詢復雜、數據 要過濾時，可以建臨時表（索引）以減少 i/o。但缺點是增加了空間 開銷。 除非每個列都有索引支持，否則在有連接的查詢時分別找出兩 個動態(tài)索引，放在工作表中重新排序。 8.7.3 基本表擴展設計基本表擴展設計

53、 基于第三范式設計的庫表雖然有其優(yōu)越性，然而在實際應用中 有時不利于系統(tǒng)運行性能的優(yōu)化：如需要部分數據時而要掃描整表， 許多過程同時競爭同一數據，反復用相同行計算相同的結果，過程 從多表獲取數據時引發(fā)大量的連接操作，當數據來源于多表時的連 接操作；這都消耗了磁盤 i/o 和 cpu 時間。 尤其在遇到下列情形時，要對基本表進行擴展設計：許多過程 要頻繁訪問一個表、子集數據訪問、重復計算和冗余數據，有時用 戶要求一些過程優(yōu)先或低的響應時間。 根據訪問的頻繁程度對相關表進行分割處理、存儲冗余數據、 存儲衍生列、合并相關表處理，這些都是克服這些不利因素和優(yōu)化 系統(tǒng)運行的有效途徑。 8.7.4 存儲衍生數據存儲衍生數據 對一些要做大量重復性計算的過程而言，若重復計算過程得到 的結果相同（源列數據穩(wěn)定，因此計算結果也不變），或計算牽扯 多行數據需額外的磁盤 i/o 開銷，或計算復雜需要大量的 cpu 時間， 就考慮存儲計算結果（冗余儲存）。現予以分類說明： 若在一行內重復計算，就在表內增加列存儲結果。但若參與計 算的列被更新時，必須要用觸發(fā)器更新這個新列。 若對表按類進行重復計算，就增加新表（一般而言，存放類和 結果兩列就可以了）存