酒店管理實習論文免費

　　近年來,隨著經濟社會的發展以及旅遊市場的壯大,我國酒店業得到了長足發展。下文是小編為大家蒐集整理的關於的內容，歡迎大家閱讀參考!

　　篇1

　　淺析酒店管理系統中的資料庫設計

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

　　關鍵詞：資訊系統;酒店管理;資料庫;設計

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

　　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儲存結構設計

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

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

　　然後要確定系統配置。酒店管理系統需要的微機數量和規模都不必太大，但在系統設計時應考慮到酒店的發展需求，在選擇硬體裝置、伺服器作業系統、資料庫時都考慮到能夠逐步擴充套件。本酒店管理系統選用了Windows XP作業系統，後臺資料庫選用目前應用最多的ORACLE 10g。由於涉及到酒店的財務管理，資料的完整性和安全性顯得尤其重要，為了保障系統安全穩定執行，需要每天進行資料備份。資料備份需要嚴格按照制定的備份與故障恢復策略進行，並落實備份登記和檢查措施。

　　4.2存取路徑設計

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

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

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

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

　　4.3設計評價及說明

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

　　5結束語

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

　　參考文獻：

　　[1]王珊,薩師煊.資料庫系統概論[M].北京:高等教育出版社,2006:34-67.

　　[2]楊東青,馬秀莉等譯.資料庫系統概念[M].北京:機械工業出版社,2007:27-60.

　　[3]毛國君.高階資料庫原理與技術[M].北京:人民郵電出版社,2002:43-52.

　　[4] Jeffrey D.Ullman,Jenifer Widom.A First Course in Database Systems[M].北京:機械工業出版社2008:23-27.

　　[5]王建設,張金娜.酒店管理系統的設計與實現[J].計算機與現代化，20111:91-93.

　　[6]白雪峰,賀春林.酒店餐飲管理系統的設計與實現[J].電腦知識與技術,20106:1281-1282.

　　[7]於侃侃.資料庫原理與應用課程教學改革探討[J].無線互聯科技，20119:41-43.

　　[8]劉芬.資料倉庫在酒店CRM系統中的應用研究[J].科技資訊,200914:557-558.

　　[9]王寶友.淺議資料庫型式標準[J].標準與技術追蹤, 20053:34-36.

　　[10]江霞.客房管理系統開發中的資料庫伺服器端程式設計[J].科技資訊,200833:485-486.

　　<<<下頁帶來更多的