前言:想要寫出一篇引人入勝的文章?我們特意為您整理了酒店管理數據庫設計的原則及步驟范文,希望能給你帶來靈感和參考,敬請閱讀。
本文作者:譚倩芳 單位:湖南食品藥品職業(yè)學院
在信息管理系統(tǒng)的設計和開發(fā)過程中,數據庫設計是其中最為重要的環(huán)節(jié)之一。設計規(guī)范、良好的數據庫不僅能帶來系統(tǒng)數據處理效率的極大提升,更重要的是在系統(tǒng)正式運行后能大大簡化后期的數據更新維護工作,提高系統(tǒng)的可擴展性。目前大多數酒店提供的服務多種多樣,規(guī)模大小也各不相同,較為典型的酒店服務業(yè)務一般都包括飲食、住宿和娛樂等方面,下面該文從這些典型的酒店業(yè)務邏輯出發(fā),分析和探討數據庫的設計方案。
1數據庫需求分析
數據庫設計的第一步是做好需求分析。在此階段需要準確了解和分析用戶的具體需求,包括數據需求和處理需求,這是整個數據庫設計過程的基礎,也是最困難、最耗費時間的一步。
1.1數據流圖分析
典型的酒店管理一般包括飲食部門、住宿管理部門、娛樂管理部門和經理部門,下面簡要分析各部門的業(yè)務邏輯。飲食部門是酒店基本部門之一,所提供服務的特點是實時性強、持續(xù)時間短、強調效率。此處需要重點處理的信息是與飲食有關的財務數據,一方面便于定期的賬目匯總,另一方面也便于及時向酒店管理層匯報。住宿管理部門也是酒店基本部門之一。其主要職責包括:(1)布置房間設施、分類、編號、制定收費標準、分配服務人員;(2)登記旅客信息,記錄其入住、退房時間;(3)統(tǒng)計各類房間的客滿程度;(4)處理本部門的財務信息。娛樂部門需要處理的業(yè)務主要包括:(1)制定收費標準,分配負責人;(2)收入支出財務處理等。經理部門的功能是必不可少的。主要職責有:(1)員工管理;(2)部門劃分;(3)各部門的財務核算;(4)酒店營業(yè)收益的定期核算。從上面各個部門的業(yè)務分析可以看出,不同部門都有財務處理的需求,因此歸總設計一個統(tǒng)一的“財務子系統(tǒng)”。而飲食部門因為所需要的業(yè)務功能都已包含在“財務子系統(tǒng)”中,故而去掉該功能模塊。最終設計酒店信息管理系統(tǒng)分為四個子模塊:經理子系統(tǒng)、財務子系統(tǒng)、住宿子系統(tǒng)和娛樂子系統(tǒng)。根據前面對業(yè)務邏輯的詳細分析,畫出各子系統(tǒng)的數據流圖,例如圖1所示為財務子系統(tǒng)的數據流圖。
1.2數據字典設計
數據字典是數據庫中各類數據描述的集合,需要設計人員對所開發(fā)系統(tǒng)的實際情況進行詳細的數據收集和數據分析才能得到。數據字典內容一般包括數據項、數據結構、數據流、數據存儲和數據處理過程。下面列舉幾例:數據項如:員工號(編號:1,數據項名稱:員工號,說明部分:整數類型,有唯一性)數據結構如:員工信息(編號:1,數據結構名:員工信息,屬性:包括員工號、姓名、性別、年齡、工齡、級別、部門、職務、備注)數據流如:員工基本信息(編號:1,數據流名:員工基本信息,輸入:招新員工,輸出:員工信息)數據存儲如:員工信息(數據存儲名:員工信息,輸入數據流:員工基本信息,輸出數據流:工資結算)處理過程如:招新員工(處理過程名:招新員工,輸入數據流:終端,輸出數據流:員工基本信息)……
2數據庫概念結構設計
數據庫概念結構設計常用方法有自底向上和自頂向下兩種。該文采用自底向上的設計方法,即首先定義各局部應用的概念結構,然后將它們集成,得到全局概念結構。
2.1局部概念結構設計
下面以財務管理子系統(tǒng)為例,分析子系統(tǒng)的功能,設計局部概念結構,并且對該局部概念結構進行合理優(yōu)化調整。財務管理子系統(tǒng)的功能為:首先對各部門上交的收支情況進行匯總,得出各部門的收益情況;然后在此基礎上進行整體匯總,得到整個酒店的收益信息;最后將酒店的收益情況下發(fā)給各個部門,公開賬目。根據該分析,得到描述財務管理子系統(tǒng)概念結構的E-R模型如圖2所示。E-R模型調整的準則:(1)現實世界中的事物能作為屬性對待的盡量作為屬性對待;(2)屬性中不具有需要描述的信息,即屬性是不可分的數據項,不再包含其他信息。根據原則分析,員工應對應一個領導關系,但為了簡便起見,就用員工的“等級”屬性來表達員工之間的領導關系。
2.2數據視圖集成
完成各子系統(tǒng)的分E-R圖設計及優(yōu)化之后,接下來需要將所有的分E-R圖綜合集成為一個總的E-R圖。由于本系統(tǒng)中各分E-R圖的規(guī)模較小,所以合成過程采用了一次集成方式。整個過程分兩步進行:第一步:合并。將各分E-R圖合并生成初步E-R圖,解決各分E-R圖間可能存在的屬性沖突、命名沖突或結構沖突。第二步:修改和重構。消除不必要的冗余,生成基本E-R圖。由于本系統(tǒng)涵蓋的內容比較少,基本不存在冗余的現象,所以初步E-R圖就是基本E-R圖,不必再進行調整。
3數據庫邏輯結構設計
3.1生成關系模式
根據E-R圖向關系模式的映射法則,可以將2.2中得到的系統(tǒng)總體E-R圖轉換為一組關系模式。轉換過程簡單描述如下:一個實體直接轉換為一個關系模式,如:員工(員工號,姓名,性別,年齡,工齡,級別,部門號,職務,備注);工資(員工號,等級,實際工資,基本工資,出勤工資);……實體與實體之間的一對一聯系或一對多聯系可以直接合并到實體所對應的關系模式中,而實體之間的多對多聯系則必須轉換為一個單獨的關系模式。根據這兩條原則,對系統(tǒng)總體E-R圖中的所有聯系進行轉換。工資和員工之間的1:1聯系與員工實體所對應的關系模式合并;員工和部門之間的n:1聯系與員工實體所對應的關系模式合并;……客房和訂單之間n:m的預約聯系轉化為:預約(訂單號,客房號,始定時間,結束時間);顧客和房間之間n:m的住宿聯系轉化為:住宿(顧客號,房間號碼,住宿時間)
3.2關系模式優(yōu)化
將E-R模型轉換為關系模式后,還應該根據關系規(guī)范化理論對所有關系模式進行優(yōu)化,以得到更為科學合理的關系模式。一般而言,在函數依賴的范疇之內,關系模式達到3NF或BCNF層次即可。下面對3.1中的關系模式進行分析:(1)在顧客關系模式“顧客(顧客編號、級別、姓名、年齡、性別、證件號碼、證件名稱、所選項目、使用時間、備注)”中,因為“使用時間”對于顧客的必要性不強,且該屬性在別的關系中可以查詢得到,所以將“使用時間”屬性刪除。分析可得,“顧客”關系模式屬于BCNF。(2)在總賬關系模式“總賬(總賬編號、部門號、財務狀況編號、收入、支出、凈利、日期、經手人號、備注)”中,“凈利”屬性可以根據收入和支出計算得到,并且不需要經常性的查詢,所以將該屬性刪除。該關系模式也屬于BCNF。(3)在財務狀況關系模式“財務狀況(財務狀況編號、時期、總收入、總支出、凈利潤)”中,雖然“凈利潤”也可以通過計算得到,但由于在這一項上查詢比較頻繁,如果每次查詢都計算,必然使得系統(tǒng)性能降低,故保留下來。(4)在員工關系模式“員工(員工號、姓名、性別、年齡、工齡、級別、部門號、職務、備注)”中,用戶查詢時,一般只需查詢自己所屬單位的員工信息,故可將其按部門水平分解為三個模式,以提高查詢效率。負責人員(員工號、姓名、性別、年齡、工齡、級別、部門號、職務、備注);服務人員(員工號、姓名、性別、年齡、工齡、級別、部門號、職務、備注);經手人員(員工號、姓名、性別、年齡、工齡、級別、部門號、職務、備注);
3.3用戶子模式設計
得到優(yōu)化后的總體邏輯結構后,還應該根據局部應用需求,結合具體的DBMS特點,設計用戶的子模式。設計過程如下:(1)因為經理對于員工的次要信息不會經常關注,因此將員工信息中最主要的內容映射過來,在經理子系統(tǒng)上設立員工關系子模式。員工(員工號、姓名、級別、部門號、職務、部門經理、實際工資);(2)因為酒店員工經常使用的只有客房的主要信息,所以在住宿子系統(tǒng)上設立客房關系子模式。客房(客房號、位置、設備、收費標準、管理人員號、狀態(tài));(3)因為酒店管理人員對于顧客的情況管理經常使用的只有部分信息,所以在經營管理子系統(tǒng)上設立顧客關系子模式。顧客(顧客編號、住宿號、姓名、級別、應收款、使用時間、備注)
4物理結構設計
4.1存儲結構設計
通過對典型酒店中的信息處理需求進行分析,可以得到如下需求特點:飲食、住宿、娛樂三大部門的數據不僅經常需要查詢,而且更新速度快;各個部門信息要求共享的較多,如員工信息、來客信息等,但財務信息一般不共享;經理部門有一定的特殊職能,如匯總財務信息、級聯刪除辭退員工等。針對這些特點,設計如下:首先要確定數據庫的存放位置。為了提高系統(tǒng)性能,根據應用情況將數據按照易變部分和穩(wěn)定部分、經常存取部分和存取頻率較低的部分分別在兩個磁盤上存放。經常存取部分包括員工、工資、客房、款項、折扣規(guī)則、項目、顧客等;而信息存取頻率較低的部分包括部門、賬單、訂單、總賬、財務狀況等。同時考慮到本系統(tǒng)是多用戶的,為了提高效率,數據庫的備份的數據和日志文件將保存在磁帶中。然后要確定系統(tǒng)配置。酒店管理系統(tǒng)需要的微機數量和規(guī)模都不必太大,但在系統(tǒng)設計時應考慮到酒店的發(fā)展需求,在選擇硬件設備、服務器操作系統(tǒng)、數據庫時都考慮到能夠逐步擴展。本酒店管理系統(tǒng)選用了WindowsXP操作系統(tǒng),后臺數據庫選用目前應用最多的ORACLE10g。由于涉及到酒店的財務管理,數據的完整性和安全性顯得尤其重要,為了保障系統(tǒng)安全穩(wěn)定運行,需要每天進行數據備份。數據備份需要嚴格按照制定的備份與故障恢復策略進行,并落實備份登記和檢查措施。
4.2存取路徑設計
首先確定數據的存取方式。對飲食、住宿、娛樂三個子系統(tǒng)的各個關系最經常的操作是查找,假設現有n個住宿房間的信息,如果采取順序查找,平均查找n/2次;建立B+樹索引,則平均查找次數為B+樹的層數log2n+1,所以選擇B+樹作為索引,具體設計如下:(1)對經常在查詢中出現的關系碼建立索引。包括員工、工資、部門、客房、款項、折扣規(guī)則和財務狀況等關系。(2)對經常需要進行連接操作的關系碼建立索引。包括員工號、客房號和部門號等。(3)對于更新頻率很高的關系模式,不宜在其上定義索引。包括顧客、訂單和賬單等。
4.3設計評價及說明
上述設計對時間效率,空間效率,維護代價和用戶的實際需求做出了較好的權衡。實際方案還需要根據酒店管理的真實環(huán)境,以時間效率和用戶需求為根本,進一步優(yōu)化和完善。
5結束語
該文依據關系數據庫設計的原則和步驟,結合典型的酒店管理的實際情況,設計了酒店信息管理系統(tǒng)所需的數據庫。設計方案科學合理,考慮了實際的業(yè)務邏輯需求,對同類信息系統(tǒng)開發(fā)中數據庫設計工作具有較高的參考價值。