當前位置:論文網 > 論文寶庫 > 信息科技類 > 計算機信息管理 > 正文

酒店管理系統中的數據庫設計

來源:UC論文網2019-05-16 09:41

摘要:

  摘要:在構建信息管理系統的過程中,“重實現,輕設計”是很多開發人員常見的通病,特別是后臺數據庫的規范化設計更是容易被忽略。因而往往導致最終實現的系統數據處理能力有限,效率低下,數據管理維護和后期更新困難重重。該文嚴格遵循規范化的數據庫設計思路,針對當前典型的商業酒店管理系統的事務邏輯,闡述了在信息系統開發過程中數據庫設計的主要步驟和方法。  關鍵詞:信息系統;酒店管理;數據庫;設計  中圖分類...

  摘要:在構建信息管理系統的過程中,“重實現,輕設計”是很多開發人員常見的通病,特別是后臺數據庫的規范化設計更是容易被忽略。因而往往導致最終實現的系統數據處理能力有限,效率低下,數據管理維護和后期更新困難重重。該文嚴格遵循規范化的數據庫設計思路,針對當前典型的商業酒店管理系統的事務邏輯,闡述了在信息系統開發過程中數據庫設計的主要步驟和方法。


  關鍵詞:信息系統;酒店管理;數據庫;設計


  中圖分類號:TP391文獻標識碼:A文章編號:1009-3044(2012)17-4043-03


  作者:譚倩芳


  在信息管理系統的設計和開發過程中,數據庫設計是其中最為重要的環節之一。設計規范、良好的數據庫不僅能帶來系統數據處理效率的極大提升,更重要的是在系統正式運行后能大大簡化后期的數據更新維護工作,提高系統的可擴展性。目前大多數酒店提供的服務多種多樣,規模大小也各不相同,較為典型的酒店服務業務一般都包括飲食、住宿和娛樂等方面,下面該文從這些典型的酒店業務邏輯出發,分析和探討數據庫的設計方案。


  1數據庫需求分析


  數據庫設計的第一步是做好需求分析。在此階段需要準確了解和分析用戶的具體需求,包括數據需求和處理需求,這是整個數據庫設計過程的基礎,也是最困難、最耗費時間的一步。


  1.1數據流圖分析


  典型的酒店管理一般包括飲食部門、住宿管理部門、娛樂管理部門和經理部門,下面簡要分析各部門的業務邏輯。


  飲食部門是酒店基本部門之一,所提供服務的特點是實時性強、持續時間短、強調效率。此處需要重點處理的信息是與飲食有關的財務數據,一方面便于定期的賬目匯總,另一方面也便于及時向酒店管理層匯報。


  住宿管理部門也是酒店基本部門之一。其主要職責包括:(1)布置房間設施、分類、編號、制定收費標準、分配服務人員;(2)登記旅客信息,記錄其入住、退房時間;(3)統計各類房間的客滿程度;(4)處理本部門的財務信息。


  娛樂部門需要處理的業務主要包括:(1)制定收費標準,分配負責人;(2)收入支出財務處理等。經理部門的功能是必不可少的。主要職責有:(1)員工管理;(2)部門劃分;(3)各部門的財務核算;(4)酒店營業收益的定期核算。從上面各個部門的業務分析可以看出,不同部門都有財務處理的需求,因此歸總設計一個統一的“財務子系統”。而飲食部門因為所需要的業務功能都已包含在“財務子系統”中,故而去掉該功能模塊。最終設計酒店信息管理系統分為四個子模塊:經理子系統、財務子系統、住宿子系統和娛樂子系統。根據前面對業務邏輯的詳細分析,畫出各子系統的數據流圖,例如圖1所示為財務子系統的數據流圖。


  1.2數據字典設計


  數據字典是數據庫中各類數據描述的集合,需要設計人員對所開發系統的實際情況進行詳細的數據收集和數據分析才能得到。數據字典內容一般包括數據項、數據結構、數據流、數據存儲和數據處理過程。下面列舉幾例:


  數據項如:員工號(編號:1,數據項名稱:員工號,說明部分:整數類型,有唯一性)


  數據結構如:員工信息(編號:1,數據結構名:員工信息,屬性:包括員工號、姓名、性別、年齡、工齡、級別、部門、職務、備注)


  數據流如:員工基本信息(編號:1,數據流名:員工基本信息,輸入:招新員工,輸出:員工信息)


  數據存儲如:員工信息(數據存儲名:員工信息,輸入數據流:員工基本信息,輸出數據流:工資結算)


  處理過程如:招新員工(處理過程名:招新員工,輸入數據流:終端,輸出數據流:員工基本信息)


  ……


  2數據庫概念結構設計


  數據庫概念結構設計常用方法有自底向上和自頂向下兩種。該文采用自底向上的設計方法,即首先定義各局部應用的概念結構,然后將它們集成,得到全局概念結構。


  2.1局部概念結構設計


  下面以財務管理子系統為例,分析子系統的功能,設計局部概念結構,并且對該局部概念結構進行合理優化調整。


  圖2財務管理子系統E-R圖


  財務管理子系統的功能為:首先對各部門上交的收支情況進行匯總,得出各部門的收益情況;然后在此基礎上進行整體匯總,得到整個酒店的收益信息;最后將酒店的收益情況下發給各個部門,公開賬目。根據該分析,得到描述財務管理子系統概念結構的E-R模型如圖2所示。


  E-R模型調整的準則:(1)現實世界中的事物能作為屬性對待的盡量作為屬性對待;(2)屬性中不具有需要描述的信息,即屬性是不可分的數據項,不再包含其他信息。根據原則分析,員工應對應一個領導關系,但為了簡便起見,就用員工的“等級”屬性來表達員工之間的領導關系。


  2.2數據視圖集成


  完成各子系統的分E-R圖設計及優化之后,接下來需要將所有的分E-R圖綜合集成為一個總的E-R圖。由于本系統中各分E-R圖的規模較小,所以合成過程采用了一次集成方式。


  整個過程分兩步進行:第一步:合并。將各分E-R圖合并生成初步E-R圖,解決各分E-R圖間可能存在的屬性沖突、命名沖突或結構沖突。第二步:修改和重構。消除不必要的冗余,生成基本E-R圖。


  由于本系統涵蓋的內容比較少,基本不存在冗余的現象,所以初步E-R圖就是基本E-R圖,不必再進行調整。


  3數據庫邏輯結構設計


  3.1生成關系模式


  根據E-R圖向關系模式的映射法則,可以將2.2中得到的系統總體E-R圖轉換為一組關系模式。轉換過程簡單描述如下:


  一個實體直接轉換為一個關系模式,如:


  員工(員工號,姓名,性別,年齡,工齡,級別,部門號,職務,備注);


  工資(員工號,等級,實際工資,基本工資,出勤工資);


  ……


  實體與實體之間的一對一聯系或一對多聯系可以直接合并到實體所對應的關系模式中,而實體之間的多對多聯系則必須轉換為一個單獨的關系模式。根據這兩條原則,對系統總體E-R圖中的所有聯系進行轉換。


  工資和員工之間的1:1聯系與員工實體所對應的關系模式合并;


  員工和部門之間的n:1聯系與員工實體所對應的關系模式合并;


  ……


  客房和訂單之間n:m的預約聯系轉化為:預約(訂單號,客房號,始定時間,結束時間);顧客和房間之間n:m的住宿聯系轉化為:住宿(顧客號,房間號碼,住宿時間)


  3.2關系模式優化


  將E-R模型轉換為關系模式后,還應該根據關系規范化理論對所有關系模式進行優化,以得到更為科學合理的關系模式。一般而言,在函數依賴的范疇之內,關系模式達到3NF或BCNF層次即可。下面對3.1中的關系模式進行分析:


  (1)在顧客關系模式“顧客(顧客編號、級別、姓名、年齡、性別、證件號碼、證件名稱、所選項目、使用時間、備注)”中,因為“使用時間”對于顧客的必要性不強,且該屬性在別的關系中可以查詢得到,所以將“使用時間”屬性刪除。分析可得,“顧客”關系模式屬于BCNF。


  (2)在總賬關系模式“總賬(總賬編號、部門號、財務狀況編號、收入、支出、凈利、日期、經手人號、備注)”中,“凈利”屬性可以根據收入和支出計算得到,并且不需要經常性的查詢,所以將該屬性刪除。該關系模式也屬于BCNF。


  (3)在財務狀況關系模式“財務狀況(財務狀況編號、時期、總收入、總支出、凈利潤)”中,雖然“凈利潤”也可以通過計算得到,但由于在這一項上查詢比較頻繁,如果每次查詢都計算,必然使得系統性能降低,故保留下來。


  (4)在員工關系模式“員工(員工號、姓名、性別、年齡、工齡、級別、部門號、職務、備注)”中,用戶查詢時,一般只需查詢自己所屬單位的員工信息,故可將其按部門水平分解為三個模式,以提高查詢效率。


  負責人員(員工號、姓名、性別、年齡、工齡、級別、部門號、職務、備注);


  服務人員(員工號、姓名、性別、年齡、工齡、級別、部門號、職務、備注);


  經手人員(員工號、姓名、性別、年齡、工齡、級別、部門號、職務、備注);


  3.3用戶子模式設計


  得到優化后的總體邏輯結構后,還應該根據局部應用需求,結合具體的DBMS特點,設計用戶的子模式。設計過程如下:


  (1)因為經理對于員工的次要信息不會經常關注,因此將員工信息中最主要的內容映射過來,在經理子系統上設立員工關系子模式。


  員工(員工號、姓名、級別、部門號、職務、部門經理、實際工資);


  (2)因為酒店員工經常使用的只有客房的主要信息,所以在住宿子系統上設立客房關系子模式。


  客房(客房號、位置、設備、收費標準、管理人員號、狀態);


  (3)因為酒店管理人員對于顧客的情況管理經常使用的只有部分信息,所以在經營管理子系統上設立顧客關系子模式。


  顧客(顧客編號、住宿號、姓名、級別、應收款、使用時間、備注)


  4物理結構設計


  4.1存儲結構設計


  通過對典型酒店中的信息處理需求進行分析,可以得到如下需求特點:飲食、住宿、娛樂三大部門的數據不僅經常需要查詢,而且更新速度快;各個部門信息要求共享的較多,如員工信息、來客信息等,但財務信息一般不共享;經理部門有一定的特殊職能,如匯總財務信息、級聯刪除辭退員工等。針對這些特點,設計如下:


  首先要確定數據庫的存放位置。為了提高系統性能,根據應用情況將數據按照易變部分和穩定部分、經常存取部分和存取頻率較低的部分分別在兩個磁盤上存放。經常存取部分包括員工、工資、客房、款項、折扣規則、項目、顧客等;而信息存取頻率較低的部分包括部門、賬單、訂單、總賬、財務狀況等。同時考慮到本系統是多用戶的,為了提高效率,數據庫的備份的數據和日志文件將保存在磁帶中。


  然后要確定系統配置。酒店管理系統需要的微機數量和規模都不必太大,但在系統設計時應考慮到酒店的發展需求,在選擇硬件設備、服務器操作系統、數據庫時都考慮到能夠逐步擴展。本酒店管理系統選用了WindowsXP操作系統,后臺數據庫選用目前應用最多的ORACLE10g。由于涉及到酒店的財務管理,數據的完整性和安全性顯得尤其重要,為了保障系統安全穩定運行,需要每天進行數據備份。數據備份需要嚴格按照制定的備份與故障恢復策略進行,并落實備份登記和檢查措施。


  4.2存取路徑設計


  首先確定數據的存取方式。對飲食、住宿、娛樂三個子系統的各個關系最經常的操作是查找,假設現有n個住宿房間的信息,如果采取順序查找,平均查找n/2次;建立B+樹索引,則平均查找次數為B+樹的層數log2n+1,所以選擇B+樹作為索引,具體設計如下:


  (1)對經常在查詢中出現的關系碼建立索引。包括員工、工資、部門、客房、款項、折扣規則和財務狀況等關系。


  (2)對經常需要進行連接操作的關系碼建立索引。包括員工號、客房號和部門號等。


  (3)對于更新頻率很高的關系模式,不宜在其上定義索引。包括顧客、訂單和賬單等。


  4.3設計評價及說明


  上述設計對時間效率,空間效率,維護代價和用戶的實際需求做出了較好的權衡。實際方案還需要根據酒店管理的真實環境,以時間效率和用戶需求為根本,進一步優化和完善。


  5結束語


  該文依據關系數據庫設計的原則和步驟,結合典型的酒店管理的實際情況,設計了酒店信息管理系統所需的數據庫。設計方案科學合理,考慮了實際的業務邏輯需求,對同類信息系統開發中數據庫設計工作具有較高的參考價值。

核心期刊推薦

河北时时彩一定牛推荐号