《數(shù)據(jù)庫系統(tǒng)原理》課程設計說明書醫(yī)院住院數(shù)據(jù)庫設計

《《數(shù)據(jù)庫系統(tǒng)原理》課程設計說明書醫(yī)院住院數(shù)據(jù)庫設計》由會員分享，可在線閱讀，更多相關《《數(shù)據(jù)庫系統(tǒng)原理》課程設計說明書醫(yī)院住院數(shù)據(jù)庫設計（21頁珍藏版）》請在裝配圖網上搜索。

1、武漢理工大學《數(shù)據(jù)庫系統(tǒng)原理》課程設計說明書 課程設計任務書 學生姓名： 專業(yè)班級： 指導教師： 工作單位： 計算機學院 題目：醫(yī)院住院數(shù)據(jù)庫設計 初始條件： 醫(yī)院業(yè)務規(guī)則： l 病房（編號、地點、收費標準，所屬科室） l 病床（病房編號、床位號） l 病人（病案號、姓名、性別、地址、電話號碼、病房編號） l 醫(yī)生（編號、姓名、性別、職稱、電話號碼、部門） l 住院（日期、病案號、入院時間、出院時間、病房編號、床位號） l 治療（時間、病案號、醫(yī)生編號、診斷、治療方案） 一位病人可能有多位

2、治療醫(yī)生，而每一位醫(yī)生又可能給多名病人治病。每一個病房可能住多位病人，而每一位病人只能住在一間病房中。一位病人可能有多個住院登記，而一份住院登記只能有一個病人。病房中有多個床位、一個床位只能在一個病房中。一個床位可以出現(xiàn)在不同的住院登記上，而一份住院登記只能給病人分配一張病床。 要求完成的主要任務： 1. 根據(jù)上述的初始條件，進行調查分析并設計適當?shù)膶傩浴ＴO計一個醫(yī)院住院數(shù)據(jù)庫，DBMS可選Ms SQL Server、Access、VFP等。 2. 完成課程設計說明書，其格式遵守學校今年的新規(guī)定。主要內容包括：需求分析，概念設計，邏輯設計，物理實現(xiàn)等。 3. 基于該數(shù)據(jù)庫，最好實現(xiàn)一個

3、或多個應用程序（自己確定功能），程序設計語言（工具）任選。這一項是選作，不作硬性要求。 時間安排： 本學期第18周： 1. 消化資料、系統(tǒng)調查 1天 2. 系統(tǒng)分析 1天 3. 總體設計，實施計劃 2天 4. 撰寫報告 1天 指導教師簽名： 年 月 日 系主任（或責任教師）簽名： 年 月 日 醫(yī)院住院數(shù)據(jù)庫設計 1 系統(tǒng)概述 1.1 概述 近年來，隨著我國人民生活水平的迅速提高，科學技術的進一步發(fā)展，醫(yī)院對HMIS（醫(yī)院管理信息系統(tǒng)）的需求就越來越迫切，一套好的HMIS在全面提高醫(yī)院的醫(yī)療、教學、科研水平，提高醫(yī)院整體

4、工作效率，為病人提供方便快捷全面的服務等方面都能發(fā)揮出重要作用。然而由于種種原因，在國內HMIS的使用尚不普及，許多小型醫(yī)院還是完全依靠手工操作在管理病人和醫(yī)院員工的一切信息，這不僅勞動強度大且工作效率低，醫(yī)師護士和管理人員的大量時間都消耗在事務性工作上，對其所掌握的信息也無法很好地統(tǒng)計應用起來，這樣既無法提高醫(yī)院自身的醫(yī)療水平，同時又無法很好地為病人服務。 從“醫(yī)院”概念上來看，住院部是醫(yī)院的基本組成單位；從醫(yī)院管理角度看，住院診療是醫(yī)院業(yè)務工作的核心部分。因此，建立一個高效可靠的住院業(yè)務管理系統(tǒng)，不僅可以在一定程度上減輕醫(yī)務人員的勞動強度，提高工作效率和工作質量，而且可以更及時、準確和有

5、效地分析統(tǒng)計各種臨床數(shù)據(jù)及管理數(shù)據(jù)，供上級主管部門作出科學的管理決策，促進醫(yī)院管理水平的進一步提高。而在整個住院業(yè)務管理系統(tǒng)，住院數(shù)據(jù)庫的設計是必不可少的。 1.2 可行性分析 首先，硬件和軟件要求不高，目前市場上的一般計算機軟硬件資源均能滿足系統(tǒng)開發(fā)需要。其中軟件主要有VB，數(shù)據(jù)庫采用Microsoft SQL Server2000。對于該數(shù)據(jù)庫的設計主要以Microsoft SQL Server2000為主要開發(fā)工具，通過ADO方式與VB程序前臺相連接，建立了一個基于C/S（客戶/服務器）的數(shù)據(jù)庫應用管理系統(tǒng)。維護工作方便，由于SQL2000的易用性，使得后臺的操作十分便捷，操

6、作人員可以在短時間內完全掌握系統(tǒng)的維護工作。 由于醫(yī)院住院病人數(shù)量眾多，因而通過電腦化操作可以減少紙張的使用，同時由于數(shù)據(jù)直接通過局域網傳輸，可以減少信息傳遞時間，提高效率，同時也方便醫(yī)生，病人搜查相關住院信息，提高醫(yī)院工作透明度和工作效率。 2 系統(tǒng)目標和建設原則 2.1 系統(tǒng)目標 1. 方便醫(yī)院管理病人的住院費用。 2. 方便醫(yī)院管理病人住院期間的病情變化。 3. 便于醫(yī)生根據(jù)具體病情及時對病人采取必要的治療。 2.2 基本原則 1. 采用生命周期法和原型法相結合的方法開發(fā)系統(tǒng) 由于本系統(tǒng)開發(fā)設計過程中受到各方條件的影響，在開發(fā)初期采用生命周期法進行

7、設計開發(fā)，嚴格按照系統(tǒng)規(guī)劃，系統(tǒng)分析，系統(tǒng)設計，系統(tǒng)實施和系統(tǒng)維護這五個階段，系統(tǒng)能正常運行后，再進一步調查和分析，其中如有不足之處，再進行合理解決。 2. 注重系統(tǒng)的易用性 本系統(tǒng)設計過程中力求人性化，結合強大的搜索功能幫助醫(yī)生、護士、病人隨時查找到各自所需的信息，同時在數(shù)據(jù)錄入過程中，盡可能減少人工輸入部分，降低人工輸入錯誤的可能性。 3. 注重系統(tǒng)的可移植性 由于醫(yī)院整體系統(tǒng)龐大復雜，可以根據(jù)需要實際取系統(tǒng)中的部分功能。同時由于數(shù)據(jù)庫采用微軟的SQL Server 2000，可以很方便地備數(shù)據(jù)，轉移數(shù)據(jù)。 3 支撐環(huán)境計劃 3.1 網絡邏輯結構 本次設計基于的網絡

8、邏輯結構是客戶/服務器（C/S）體系結構。C/S是基于資源不對等，并且為了實現(xiàn)共享而提出來的，它由三個主要部分構成：數(shù)據(jù)庫服務器、客戶應用程序和網絡。C/S體系結構的優(yōu)點在于系統(tǒng)的客戶應用程序和服務器構件分別運行在不同的計算機上，這對硬件和軟件的變化顯示出極強的適應性和靈活性，而且易于對系統(tǒng)進行擴充和縮小。 基于C/S的住院管理系統(tǒng)的結構示意圖如圖3-1所示。 …….. …….. 住院數(shù)據(jù)庫服務器 網絡 集線器 病人用戶 病人用戶 醫(yī)生用戶 管理員 3.1 基于C/S的住院管理系統(tǒng)結構 醫(yī)生用戶

9、 打印設 備 其他公用設備 3.2 軟件支撐環(huán)境及開發(fā)工具 這次課程設計基本是都是在WINDOWS XP操作系統(tǒng)下完成的。包括應用程序的開發(fā)、數(shù)據(jù)庫的設計以及設計報告的編寫。在這一過程中，應用的開發(fā)工具有： 1. VB程序設計語言 2. SQL Server 2000 3. Microsoft Office Word 2003 4 系統(tǒng)總體結構 4.1 數(shù)據(jù)流圖的設計 數(shù)據(jù)流圖可以表示現(xiàn)行系統(tǒng)的信息流動和加工處理等詳細情況，是現(xiàn)行系統(tǒng)的一種邏輯抽象，獨立于系統(tǒng)的實現(xiàn)。對于本次設計，我將根據(jù)系統(tǒng)的業(yè)務流程分別來設計數(shù)據(jù)流圖。 對于入院處理的數(shù)

10、據(jù)流圖如圖4-1所示： 收費單請 住院單請 住院申請 病人信息 圖4-1 入院數(shù)據(jù)流圖 病人 查看信 息 病人病案 病人 分配床 位 病房信息 產生收費單及住院單 對于治療處理的數(shù)據(jù)流圖如圖4-2所示： 治療方案 出示病歷 病人 醫(yī)生診 斷 病人病歷 病人檢查情況 給出治方 案 病人 圖4-2 治療數(shù)據(jù)流圖 對于出院處理的數(shù)據(jù)流圖如圖4-3所示： 申請出院 繳費單 病人 病人病案 收費準

11、則 病歷歸 檔 費用統(tǒng) 計 病人 圖4-3 出院數(shù)據(jù)流圖 4.2 功能結構設計 設計一個系統(tǒng)是要事先了解系統(tǒng)的基本功能，將其分成幾個模塊分別設計，能夠提高設計效率。對于住院業(yè)務管理系統(tǒng)來說，其基本業(yè)務功能應該包括： 1） 入院管理功能 2） 治療管理功能 3） 出院管理功能 4） 收費管理功能（收費常常伴隨著入院、治療以及出院管理而發(fā)生） 4.2.1 入院管理功能流程 對于曾在本醫(yī)院住院的病人，系統(tǒng)會根據(jù)其提供的病案號自動在病案首頁表中調出病人基本資料；而對于第一次在本院住院病人則系統(tǒng)會自動為其產生病案號，工作人員會要求其填寫基本資料，填寫無誤后，將基本資料存

12、入數(shù)據(jù)庫。其業(yè)務流程如圖4-4所示。 4.2.2 治療管理功能流程 病人在住院期間，接受醫(yī)生的治療是不可避免的。因此熟悉治療的流程，對于住院數(shù)據(jù)庫的設計也是必要的。其業(yè)務流程如圖4-5所示。 4.2.3 出院管理功能流程 病人要住院，當然也要出院。出院時，系統(tǒng)調出病人的基本資料，對于病人住院期間的各項費用進行統(tǒng)計，開收費單要求病人繳費。其業(yè)務流程如圖4-6所示。 曾住院？ 是 否 辦理入院手續(xù) 病人 查看病案 新建病案 分配病房及床位 住院 圖4-4 入院流程 收取一定費用

13、是 否 病人 出示病歷 醫(yī)生檢查 正常？ 給出治療方案 治療 不做處理 圖4-5 治療流程 病人 病歷歸檔 進入病人病案 出院結算 出院 圖4-6 出院流程 4.3 數(shù)據(jù)庫結構設計 4.3.1 數(shù)據(jù)字典 數(shù)據(jù)字典是系統(tǒng)中各類數(shù)據(jù)描述的集合，是進行詳細的數(shù)據(jù)收集和數(shù)據(jù)分析所獲得的主要成果，并且數(shù)據(jù)字典的內容將在數(shù)據(jù)庫的設計過程中不斷的修改、充實和完善。 根據(jù)對住院管理系統(tǒng)業(yè)務流程的了解，可以定義以下數(shù)據(jù)結構：病人、病房、病床、醫(yī)生、治療記錄和住院登記。其中在病人、治療記錄和住院登記中都涉及病案號，對于一個病人

14、唯一對應一個病案號，而病案就是治療記錄和住院登記的集合。 病人的數(shù)據(jù)項描述： 數(shù)據(jù)項名 數(shù)據(jù)項含義 類型 長度 備注 病案號 病人的編號 VARCHAR 15 對應唯一一個病人 姓名 病人姓名 VARCHAR 20 性別 病人性別 CHAR 2 只能取‘男’或‘女’ 地址 病人住址 VARCHAR 100 電話 病人電話 VARCHAR 12 病房編號 CHAR 4 住院時由系統(tǒng)分配 病房的數(shù)據(jù)項描述： 數(shù)據(jù)項名 數(shù)據(jù)項含義 類型 長度 備注 編號 病房編號 CHAR 4

15、病房編號唯一 地點 病房位置 VARCHAR 40 收費標準 INT 4 單位為（元/天） 所屬科室 VARCHAR 20 病床的數(shù)據(jù)項描述： 數(shù)據(jù)項名 數(shù)據(jù)項含義 類型 長度 備注 病房編號 CHAR 4 床位號 INT 2 一個病房一般有1-3個床位 醫(yī)生的數(shù)據(jù)項描述： 數(shù)據(jù)項名 數(shù)據(jù)項含義 類型 長度 備注 編號 醫(yī)生編號 VARCHAR 10 對應唯一一個醫(yī)生 姓名 醫(yī)生姓名 VARCHAR 20 性別 醫(yī)生性別 CHAR 2 只能取‘男’或‘女’ 職稱

16、 醫(yī)生職稱 VARCHAR 20 有可能有多個職稱 電話 醫(yī)生電話 VARCHAR 12 部門 所屬部門 VARCHAR 20 住院登記的數(shù)據(jù)項描述： 數(shù)據(jù)項名 數(shù)據(jù)項含義 類型 長度 備注 日期 登記日期 DATE 10 病案號 VARCHAR 15 入院時間 DATE 10 出院時間 DATE 10 必須在入院時間之后 病房編號 CHAR 4 病床編號 INT 2 治療記錄的數(shù)據(jù)項描述： 數(shù)據(jù)項名 數(shù)據(jù)項含義 類型 長度 備注 時間 治療日期

17、 DATE 10 入院和出院時間之間 病案號 VARCHAR 15 醫(yī)生編號 VARCHAR 10 診斷 VARCHAR 50 醫(yī)生診斷結果 治療方案 VARCHAR 200 醫(yī)生給出的治療方案 4.3.2 E-R圖設計 E-R圖提供了表示實體型、屬性和聯(lián)系的方法。 1） 實體型：用矩形表示，矩形框內寫明實體名； 2） 屬性：用橢圓形表示，并用無向邊將其與相應的實體連接起來； 3） 聯(lián)系：用菱形表示，菱形框內寫明聯(lián)系名，并用無向邊分別與有關實體型連接起來，同時在無向邊旁標上聯(lián)系的類型。

18、 注意：如果一個聯(lián)系也具有屬性，則這些屬性也要用無向邊與該聯(lián)系連接起來。 下面將根據(jù)要設計的住院數(shù)據(jù)庫對其中涉及到的實體、實體屬性和實體間的聯(lián)系進行分析和設計。 （1） 實體及其屬性分析 根據(jù)本次課程設計所給出的初始條件，目前有以下實體：病人實體、病房實體、病床實體、醫(yī)生實體和住院登記實體。對于這些實體，它們的實體及屬性圖如圖4-7所示： 病房 地點 收費標準 所屬科室 編號 病人 病案號 姓名 性別 地址 電話號碼 病房編號 部門 電話號碼 職稱 性別 姓名 編號 醫(yī)生 病房編號 床位號 病床 日期 入院時間 床位

19、號 出院時間 病案號 病房編號 住院登記 圖4-7 住院數(shù)據(jù)庫實體及其屬性圖 （2） 分E-R圖設計 在本次設計中，根據(jù)任務書所提供的業(yè)務規(guī)則，實體和實體之間可以有以下幾種聯(lián)系： 1） 醫(yī)生與病人之間的聯(lián)系，它們之間的聯(lián)系圖如圖4-8所示； 2） 病人與病房以及病房與病床之間的聯(lián)系，它們之間的聯(lián)系圖如圖4-9所示； 3） 病人與住院登記以及住院登記與病床之間的聯(lián)系，它們之間的聯(lián)系圖如圖4-10所示。 n人 m人

20、 醫(yī)生 病人 治療 診斷 治療方案 圖4-8 病人與醫(yī)生聯(lián)系圖 治療時間 n人 1人 擁有 病房 病床 病房 n人 1人 住在 病人 圖4-9 病人與病房及病房與病床聯(lián)系圖 1 n 住院登記 病床 分配 圖4-10 病人與住院登記及住院登記與病床聯(lián)系圖 n 1 病人 住院登記 登記 （3） 基本E-R圖設計 對于分E-R圖，它們之間往往存在一些不一致的地方，即沖突。合并時不能簡單的將上述的各個分E-R圖畫在一起，必須要消除各個分E-R圖中的不一致，以形成一個能為全系統(tǒng)所有用

21、戶所共同理解和接受的統(tǒng)一的概念模型。 在上述分E-R圖上可以做出修改,最終形成的基本E-R圖如圖4-11所示： 出院時間 病房 地點 收費標準 所屬科室 病房編號 n 1 1 n 1 病房編號 床位號 治療時間 部門 電話號碼 職稱 性別 姓名 醫(yī)生編號 圖4-11 醫(yī)院住院數(shù)據(jù)庫基本E-R圖 n n m n 1 病床 病人 醫(yī)生 病案號 姓名 性別 地址 電話號碼 病房編號 病案號 病房編號 床位號 診斷 日期 入

22、院時間 治療方案 治療 住在 住院登記 擁有 登記 分配 4.3.3 關系模型設計 關系模型的邏輯結構是一組關系模式的集合。將E-R圖轉換為關系模型實際上就是將實體型、實體型的屬性和實體之間的聯(lián)系轉換為一組關系模式，這種轉換需要遵守以下原則： 1. 一個實體型轉換為一個關系模式。實體的屬性就是關系的屬性，實體的碼就是關系的碼。 2. 對于實體之間的聯(lián)系有以下幾種情況： （1） 一個1：1的聯(lián)系可以轉換為一個獨立的關系模式，也可以與任意一端對應的關系模式合并。 （2） 一個1：n的聯(lián)系可以轉換成為一個獨立的關系模式，也可以與n端對應的關系模式合并。 （3） 一個m

23、: n的聯(lián)系轉換為一個關系模式。 （4） 3個或者3個以上的實體之間的一個多元聯(lián)系可以轉換為一個關系模式。 （5） 具有相同碼的關系模式可以合并。 按照上述的原則，根據(jù)設計好的E-R圖，可以將其轉換為以下一組關系模式，其中關系模式的碼用下橫線標出。 病房（病房編號，地點，收費標準，所屬科室） 此為病房實體型所對應的關系模式。其中病房編號唯一確定一個病房，所以為該關系模式的碼。 病床（病房編號，床位號） 此為病床實體型所對應的關系模式。由于病房編號是病房關系模式的碼，所以在該關系模式中病房編號為外碼。 病人（病案號，姓名，性別，地址，電

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

25、 5 總體實施計劃 5.1 基本表的設計 完成數(shù)據(jù)庫的邏輯和物理設計后，需要運用SQL語言對數(shù)據(jù)庫中所涉及的表進行定義，同時要考慮與表有關的完整性約束條件。 1. 建立病人表： CREATE TABLE 病人 （病案號 VARCHAR（15） PRIMARY KEY， 姓名 VARCHAR（20） NOT NULL， 性別 CHAR（2） CHECK（性別 IN（‘男’，‘女’））， 地址 VARCHAR（100） NOT

26、 NULL， 電話 VARCHAR（12）， 病房編號 CHAR（4）NOT NULL， FOREIGN KEY 病房編號 REFERENCES 病房（病房編號））； 2.建立醫(yī)生表： CREATE TABLE 醫(yī)生 （醫(yī)生編號 VARCHAR（10） PRIMARY KEY， 姓名 VARCHAR（20） NOT NULL， 性別 CHAR（2） CHE

27、CK（性別 IN（‘男’，‘女’））， 職稱 VARCHAR（20） NOT NULL， 電話 VARCHAR（12）， 部門 VARCHAR（20） NOT NULL ）； 3.建立病房表： CREATE TABLE 病房 （病房編號 CHAR（4） PRIMARY KEY， 地點 VARCHAR（40） NOT NULL，

28、 收費標準 INT NOT NULL， 所屬科室 VARCHAR（20） NOT NULL ）； 4.建立病床表： CREATE TABLE 病床 （病房編號 CHAR（4） NOT NULL， 床位號 INT NOT NULL， PRIMARY KEY（病房編號，床位號）， FOREIGN KEY 病房編號 REFERENCES 病房（病房編號）

29、 ）； 5. 建立住院登記表： CREATE TABLE 住院登記 （日期 DATE NOT NULL， 病案號 VARCHAR（15） NOT NULL， 入院時間 DATE NOT NULL， 出院時間 DATE NOT NULL， 病房編號 CHAR（4） NOT NULL， 床

30、位號 INT NOT NULL， PRIMARY KEY（日期，病案號）， FOREIGN KEY 病案號 REFERENCES 病人（病案號）， FOREIGN KEY 病房編號 REFERENCES 病房（病房編號） ）； 6. 建立治療記錄表： CREATE TABLE 治療記錄 （治療時間 DATE NOT NULL， 病案號 V

31、ARCHAR（15） NOT NULL， 醫(yī)生編號 VARCHAR（10） NOT NULL， 診斷 VARCHAR（50） NOT NULL， 治療方案 VARCHAR（200） NOT NULL， PRIMARY KEY（治療時間，病案號，醫(yī)生編號）， FOREIGN KEY 病案號 REFERENCES 病人（病案號）， FOREIGN KEY 醫(yī)生

32、編號 REFERENCES 醫(yī)生（醫(yī)生編號） ）； 5.2 關系圖設計 根據(jù)5.1中所建立的表及其它們之間的關系可以用圖5-1來表示： 圖5-1 住院關系圖 5.3 角色的創(chuàng)建 由于不用的系統(tǒng)用戶會擁有不同的權限，這樣才能保證數(shù)據(jù)庫的安全性。在這次住院數(shù)據(jù)庫的設計中，主要用戶包括管理員、醫(yī)生和病人。管理員應該具有超級用戶的權限，而醫(yī)生和病人只能對數(shù)據(jù)進行簡單的查詢，不能修改數(shù)據(jù)庫中的數(shù)據(jù)。因此在數(shù)據(jù)庫中分別建立3個角色：role

33、_adin,role_doctor和role_br。管理員角色的權限設置如圖5-2所示，醫(yī)生角色的權限如圖5-3所示，病人角色的權限如圖5-4所示。 圖5-2 role_adin的權限 圖5-3 role_doctor的權限 圖5-4 role_br的權限 5.4 數(shù)

34、據(jù)的載入和應用程序調試 在本次住院數(shù)據(jù)庫的設計中，數(shù)據(jù)載入并不是一次性全部入庫的。對于第一次來醫(yī)院住院的病人，要為其新建病案，將該病人的信息寫進數(shù)據(jù)庫中，而對于已經在醫(yī)院住過院的病人，只需要調出其病案，當有病人信息需要更改時，須更新數(shù)據(jù)庫。 對于醫(yī)生的信息的載入，可以先將所有現(xiàn)有醫(yī)生的資料入庫。如果有新醫(yī)生的到來或者有醫(yī)生離開，則需要添加或者刪除部分數(shù)據(jù)。下表是一個簡單的數(shù)據(jù)入庫表： 醫(yī)生表： 編號 姓名 性別 職稱 電話號碼 部門 8001 李思 男 住院醫(yī)師 58362214 住院部 8002 錢玉 女 主治醫(yī)師 56203221 住院部 8

35、003 令狐沖 男 主任醫(yī)師 86542256 住院部 8004 歐陽風 男 副主任醫(yī)師 58885545 住院部 8005 何雨 女 住院醫(yī)師 86584523 住院部 對于病房和病床資料的錄入，基本與醫(yī)生信息載入相似，下面兩張表表現(xiàn)了部分病房與病床的資料： 病房表： 病房編號 地點 收費標準（元/每天） 所屬科室 1021 住院大樓1樓 100 內科 1052 住院大樓1樓 150 外科 2033 住院大樓2樓 150 內科 3015 住院大樓3樓 100 外科 4048 住院大樓4樓 10

36、0 內科 病床表： 病房編號 床位號 1021 01 3015 02 4022 01 4038 02 4040 02 對于住院登記和治療記錄的數(shù)據(jù)的載入，它們分別伴隨病人住院和醫(yī)生為病人治療而產生的。因此在數(shù)據(jù)庫剛剛設計完成后，只有將原有系統(tǒng)或者手工處理的數(shù)據(jù)進行轉換使之符合新系統(tǒng)的數(shù)據(jù)模式，從而完成數(shù)據(jù)輸入工作。 由于本次課程設計主要是醫(yī)院住院數(shù)據(jù)庫的設計，對應用程序的設計不做要求，所以對于應用程序的調試和運行不做描述。 6 研制報告 6.1 研制過程 這份課程設計報告是我花費大量時間查閱關于軟件設計方面的書籍，以及在互聯(lián)網上查找資料，耗費大量

37、精力編寫成功的。并且在報告編寫的過程中，和其他同學互相學習、討論，對于遇到的問題，積極尋求解決辦法，如果遇到了自己和同學不能解決的問題，就向指導老師請教。最終在老師和同學的幫助下，以及在自己的努力下，我完成了本次設計。 6.2 對設計的評價 這次課程設計，主要是根據(jù)教材所講述的數(shù)據(jù)庫設計步驟，從需求分析到概念結構設計到邏輯結構設計再到物理實現(xiàn)，最后到數(shù)據(jù)庫實施，按照任務書的要求一步步完成的。因為本次設計主要是數(shù)據(jù)庫的設計，所以僅對應用程序進行了敘述，并沒有進行詳細設計，這一點應該算是這次課程設計的一個缺陷吧。 盡管沒有應用程序的詳細設計，但是從課程設計的要求來看，這個住院數(shù)據(jù)

38、庫的設計是滿足系統(tǒng)設計要求的。因此，從總體上看，這次醫(yī)院住院數(shù)據(jù)庫的設計是比較成功的。 6.3 心得與體會 通過本次課程設計，使我接受了一次用專業(yè)知識、專業(yè)技能分析和解決問題的全面系統(tǒng)的鍛煉。使我在綜合知識的選用方面，在數(shù)據(jù)庫設計的基本思想、方法方面，以及在常用編程設計思路技巧的掌握方面都能向前邁了一大步。為日后成為合格的應用型人才打下良好的基礎。這次在指導老師的幫助下，在同學的幫助下，基本上完成了設計任務，在軟件的設計方面的能力也有了一定的提高，為今后順利地走上工作崗位奠定了基礎。 而且經過本次課程設計，使我懂得了理論與實際相結合是很重要的，只有理論知識是遠遠不夠的，只有

39、把所學的理論知識與實踐相結合起來，從理論中得出結論，從而提高自己的實際動手能力和獨立思考的能力，才能真正為社會服務。在設計的過程中，難免會遇到各種各樣的問題，但我會努力克服，同時在設計的過程中發(fā)現(xiàn)了自己的不足之處，對以前所學過的知識理解得不夠深刻，掌握得不夠牢固，但通過對課本以及一些相關書籍的查閱，并且在指導老師和同學的幫助下，算是比較成功的完成了這次課程設計。 7 參考文獻 1. 王珊.數(shù)據(jù)庫系統(tǒng)簡明教程.北京：高等教育出版社，2004 2. 王珊，馮念真.計算機應用系統(tǒng)的設計與開發(fā).北京：高等教育出版社，1989 3. 薩師煊，王珊.數(shù)據(jù)庫系統(tǒng)概論.第三版.北京：高

40、等教育出版社，2000 4. 王珊，陳紅.數(shù)據(jù)庫系統(tǒng)教程.北京：清華大學出版社，1998 5. 周龍驤等.分布式數(shù)據(jù)庫管理系統(tǒng)實現(xiàn)技術.北京：科學出版社，1998 6. 徐潔磐，馬玉書，范明.數(shù)據(jù)庫系統(tǒng)導論.北京：科學出版社，1999 7. 李昭原.數(shù)據(jù)庫技術新進展.北京：清華大學出版社，1997 8. 何守才.數(shù)據(jù)庫綜合大詞典.上海：上海科學技術文獻出版社，1995ut2ApOdfXXc02GyBKsKCWw97MrqqWhoj5TL15Zt6jIPYytYCummtARp3v1N5luizi3xh3BhWYreKO8d9g7nmZQoWPJeTLDr

41、w08gVS8DsDQQYGC3cE7moO2tLF0Jf1gK74IUXyBmtIVR97CkrfVqULT5fn2t6MpJR6rbzVPSortZvIj5NB5ndVvSr4iWr1TwLFKgLSPzuhRjQ3CmZU98eUOuijdLSZqPmvrw9zKupxf8WFUG9l2G9277g2rTipa1YpCZEuqxpKBhtVDCooQOzxUz3vJrZmOcijyM62zchmeooTYes8EBMm932tbz2Yo09RtsZEYS8Zrd2Yktj8l6jEAzVAjnfbtryLvsm6oFbfToXVRFFn7OwIYgJlamkUNXJYbz5Rrb7r4V

42、suR9zpfZFMfsjhcfCA37lNW2VVLRKN7R8psz1BN6oRic5hU5Z6HCxAYqyNPOG8duYbAwqSl20CSg06Dh2sM8HLtgPkIcSkrgOPDpuHBj1LmPk7lYdvC6NNMwL3fwhZFTFVYAARY7lHSSxJ10V3pH3Y19BxYR77Ib7CpZSu2tijqe3hKqkKAu9KSkCpHKXUIKvvyJZpg2YijRkqfbGgOvyqKuxNWI9oMnJtt6QilZxtyrF7d20FbmabcfiixrQKUsVNXBPPFUXyQ1fJSKFSUbkgs2DUVQC9sz4JkbgN4Qqv66

43、pyoARjurNFJ3TxyfclZiEePtwFJthphEipDFNqnR2HjQKV2DzWtMPDJQkBcXmovdsjqCTJagjMdLsKPgaD2s0H0vmZGAHt36gyUEZ7UmANk1ndREuBeqdgrx0venqGnsyIB2ilq3SIQrNL4m56t7Z8Y8da5K0KUpn5Nzg4JvjdtfFHyt82AoGQkXo4VBLmLEiy2P7HtHBho07rCfttxodYDPPdtQsO7wxD0J6fKKlGm4woDzplhtRr2XgqN13hqy59zU1GegDyQniHNTaVSieueFQcYfUCJwd3vk5I7YKmhu

44、nDmIZ ut2ApOdfXXc02GyBKsKCWw97MrqqWhoj5TL15Zt6jIPYytYCummtARp3v1N5luizi3xh3BhWYreKO8d9g7nmZQoWPJeTLDrw08gVS8DsDQQYGC3cE7moO2tLF0Jf1gK74IUXyBmtIVR97CkrfVqULT5fn2t6MpJR6rbzVPSortZvIj5NB5ndVvSr4iWr1TwLFKgLSPzuhRjQ3CmZU98eUOuijdLSZqPmvrw9zKupxf8WFUG9l2G9277g2rTipa1YpCZEuqxpKBhtVDCooQOzxUz3vJrZmOcijyM62z

45、chmeooTYes8EBMm932tbz2Yo09RtsZEYS8Zrd2Yktj8l6jEAzVAjnfbtryLvsm6oFbfToXVRFFn7OwIYgJlamkUNXJYbz5Rrb7r4VsuR9zpfZFMfsjhcfCA37lNW2VVLRKN7R8psz1BN6oRic5hU5Z6HCxAYqyNPOG8duYbAwqSl20CSg06Dh2sM8HLtgPkIcSkrgOPDpuHBj1LmPk7lYdvC6NNMwL3fwhZFTFVYAARY7lHSSxJ10V3pH3Y19BxYR77Ib7CpZSu2tijqe3hKqkKAu9KSkCpHKXUIKvvyJZpg

46、2YijRkqfbGgOvyqKuxNWI9oMnJtt6QilZxtyrF7d20FbmabcfiixrQKUsVNXBPPFUXyQ1fJSKFSUbkgs2DUVQC9sz4JkbgN4Qqv66pyoARjurNFJ3TxyfclZiEePtwFJthphEipDFNqnR2HjQKV2DzWtMPDJQkBcXmovdsjqCTJagjMdLsKPgaD2s0H0vmZGAHt36gyUEZ7UmANk1ndREuBeqdgrx0venqGnsyIB2ilq3SIQrNL4m56t7Z8Y8da5K0KUpn5Nzg4JvjdtfFHyt82AoGQkXo4VBLmLEiy2P7HtHBho07rCfttxodYDPPdtQsO7wxD0J6fKKlGm4woDzplhtRr2XgqN13hqy59zU1GegDyQniHNTaVSieueFQcYfUCJwd3vk5I7YKmhunDmIZ - 21 -