【正文】 他信息。 {部門號、名稱、部門經理、員工數量 } D. 取消某個部門時，核算該部門的財務情況，并作備份；同時對該部門的員工重新分配工作。這些信息都需要長時間保留并上報。此次數據庫設計只能在一些收集到的基本材料與個人直觀認識的基礎上，簡單模仿中等規(guī)模的酒店設計管理系統(tǒng)，并將其抽象成一個由三部門組成、實現三大服務的系統(tǒng)。 2． 住宿管理部門 它也是酒店基本部門之一。 情況進行核算。 經理管理部門子系統(tǒng) 本開發(fā)小組成員經過調查、信息流程分析、數據收集，并結合需求分析，明確了 —— 、子系統(tǒng)的功能 : :給員工編號，登記其基本信息。 各分 ER 圖之間的沖突主要有三類： 1． 屬性沖突： （ 1）屬性域沖突，即屬性值的類型、取值范圍或取值集合不同。例如員工信息 ,來客信息等。 二 . 存取路徑設計 1. 存取方式的分析 : 對飲食、住宿、娛樂三個子系統(tǒng)的各個關系最經常的操作是查找，假設現有 n 個住宿房間的信息，如果采取順序查找，平均查找 n/2 次；建立 B+樹索引，則平均查找次數為 B+樹的層數 log2n+1。 水平分解：員工 (員工號 、姓名、性別、年齡、工齡、級別、部門號、職務、備注 ) 改為：負責人員 (員工號 、姓名、性別、年齡、工齡、級別、部門號、職務、備注 )； 服務人員 (員工號 、姓名、性別、年齡、工齡、級別、部門號、職務、備注 )； 經手人員 (員工號 、姓名、性別、年齡、工齡、級別、部門號、職務、備注 )； 三、用戶子模式設計 1．經理子系統(tǒng)用戶子模式 員工 (員工號 、姓名、級別、部門號、職務、部門經理、實際工資 )； 因為經理對于員工其他情況不會經常關注，經常使用的只有以上各項，所以在經理子系統(tǒng)上設立員工 第 16 頁 關系。 分 ER 圖如下 : 部門 1 n 員工 1 n 1 財務狀況 1 m m 賬單 m 1 總帳 實體屬性定義 : 部門 (部門號、名稱、部門經理、員工數量 ) 員工 (員工號、姓名、性別、年齡、工齡、級別、部門、職務、備注 ) 賬單（編號、發(fā)票號、摘要、收入數、支出數、日期、經手人、備注） 總帳 (編號、部門號、收入、支出、凈利、日期、經手人、備注 ) 財務狀況（時期、總收入、總支出、凈利潤） 、對 ER 圖調整的準則 : 現實世界中的事物能作為屬性對待的盡量作為屬性對待； 屬性和實體的劃分：屬性中不具 有需要描述的信息，即屬性是不可分的數據項，不再包含其他信息。 客人信息 {房間號、房間類別、客人數量、聯(lián)系人名、身份、證件名稱（類型）、證件號碼、入住時間、退出時間 } B. 房間管理 旅客入住（旅客退出）除了登記（刪除）客人信息之外，還應對相關的記錄進行修改，如房間的狀態(tài)等。給員工編號，登記其基本信息；根據員工的平時表現及工齡確定工資；此外，還要給員工分配工作部門及職務等等。例如，顧客人數、顧客所用的菜及其它飲料等種類繁多，數量不等；后勤各種活動如采購等頻繁發(fā)生。通過分析可發(fā)現，用人工完成此類操作比計算機更具實效與時效，且此類信息也沒有長時間保留的必要，因此這些信息沒有必要采用數據庫管理。 。 房間類別 {類別號、名稱、設備、收費標準、總數量、剩余量、管理人員 } 房間 {房間號，房間類型、狀 態(tài) } ( 該部門的財務處理與飲食子系統(tǒng)同，歸到財務子系統(tǒng) ) 第 4 頁 4． 娛樂子系統(tǒng) A. 添加新的娛樂項目 娛樂項目 {娛樂項目號、名稱、收費標準、負責人 } B. 取消某娛樂項目 （財務處理 （同飲食子系統(tǒng)） 歸到財務子系統(tǒng) ) 三、數據字典 1． 數據項 數據項有待按各子系統(tǒng)分類列表。 、具體調整如下 : 員工應對應一個領導關系 ,但為了簡便起見 ,就用員工的“等級 ” 屬性來表示員工之間的領導關系。 2．住宿子系統(tǒng)用戶子模式 客房（ 客房號 、位置、設備、收費標準、管理人員號、狀態(tài)）； 因為管理員工對于客房的其他情況不會經常使用，經常使用的只有以 上各項，所以在住宿子系統(tǒng)上設立客房關系 3．經營管理子系統(tǒng)用戶子模式 顧客（ 顧客編號 、住宿號、姓名、級別、應收款、使用時間、備注） 因為對于顧客的情況管理經常使用是以上各項，所以在經營管理子系統(tǒng)上設立顧客關系。 所以 選擇 B+樹作為索引 ,具體設計如下： ? 對以下經常在查詢中出現的關系的碼建立索引 說明：下加橫線部分表示關系的碼 員工 (員工號 、姓名、性別、年齡、工齡、級別、部門號、職務、備注 )； 工資 (員工號 、等級、實際工資、基本工資、出勤工資 )； 部門 (部門號 、名稱、部門經理、員 工數量、財務狀況編號 )； 客房（ 客房號 、類別、部門號、位置、設備、收費標準、管理人員號、狀態(tài)）； 款項 (款項編號 、顧客號、項目號、折扣級別、使用時間、應收款、實際收款 )； 折扣規(guī)則 (折扣級別 、折扣情況 )； 財務狀況（ 財務狀況編號 、時期、總收入、總支出、凈利潤）； ? 以下經常進行連接操作的關系的碼建立索引 : 員工號 、 客房號 、 部門號 等 ? 由于下面幾個關系模式的更新頻率很高 ,所以沒有定義索引 : 顧客 (顧客編號 、級別、姓名、年齡、性別、證件號碼、證件名稱、所選項目、備注 )； 訂單 (訂單號 、顧客號、經手人號、備注 )； 賬 單（ 賬單編號 、總帳編號、發(fā)票號、摘要、收入數、支出數、日期、經手人號、備注）； 三 . 設計評價及說明 上述設計對時間效率，空間效率，維護代價和用戶的實際需求做出了較好的權衡，根據酒店管理的實際出發(fā)，以時間效率和用戶的實際需求為根本，得出的最后方案。 （２）各個部門信息要求共享的信息較多。 解決各分 ER 圖之間的沖突，將各分 ER 圖合并起來生成初步 ER 圖。 本過程結構設計過程采用自底向上的設計方法 ,即首先定義各局部應用的概念結構 ,然后將它們集成起來 ,得到全局概念結構 . 下面給出各個子系統(tǒng)的分析及分 ER 圖的設計及對其進行的各項調整。 （支付工資等）。 在規(guī)模較大的酒店餐飲服務部分，餐廳可分成幾個等級或幾個小部門，然后各自形成小系統(tǒng)，本系統(tǒng)為了簡單起見，把飲食部門作為一個子系統(tǒng)，不再細 分。 一、 部門的劃分 1． 飲食部門 它是酒店基 本部門之一。 4． 經理部門 經理部門的功能雖然不是面向顧客、不是酒店的服務項之一，但它的存在卻是必不可少的。 E. 其他情況的處理。 、具體調整如下 : 1．本來員工還應對應一個領導關系 ,但這里為了簡便 ,就用員工的“等級 ” 屬性來表示員工之間的領導關系； 2．款項本可以作為顧客的一個屬性來設置，但這里為了強調對顧客的折扣情況，需要對款 項進行進一步的描述，因此這里作為一個實體； 3．對顧客所采取的折扣規(guī)則，本應該根據顧客的實際消費量來劃定，這里為了方便起見，給每位顧客添加了一個“級別”屬性，用以對應應采取的折扣規(guī)則； 4．部門對應的賬單本應屬于財務子系統(tǒng)的內容，這里為了簡化財務子系統(tǒng)，先在各個子系統(tǒng)中進行財務總住宿 負責應 付 預 訂 預約 對應 核算 第 11 頁 結，因此，將賬單也作為一個實體。保留下來雖然造成了一定的冗余 , 但提高了查詢的效率， 利大于弊。數據備份需要嚴格按照事先制定的備份與故障恢復策略進行，并落實備份登記和檢查措施。 （３）經理部門有一定的特殊職能：匯總財務信息；對于被辭退的員工從系統(tǒng)中級聯(lián)刪除其信息、如從員工表中刪除其基本信息、從它所服務的工作部門中刪除該員工的工作名額，結算支付其工資、獎金；同時補充新的員工，代替它的工作。由于本系統(tǒng)較簡單，不存在這類沖突； 2． 命名沖突： （ 1） 同名異義：由于本系統(tǒng)較簡單，所以不存在這類沖突； （ 2） 異名同義：由于本系統(tǒng)較小，所以不存在這類沖突； 3． 結構沖突： （ 1） 同一對象在不同應用中具有不同的抽象：本系統(tǒng)在需求分析階段原本存在這種沖突，考慮到后期的簡化合并，我們在設計各個分 ER 圖就早先解決了這個問題，即將 在任何一個分 ER 圖中作為實體出現的屬性全部作為實體； （ 2） 同一實體在不同分 ER圖中所包含的屬性個數和屬性排列次序不完全相同：由于本系統(tǒng)較簡單，所以并不存在這種沖突； 第二步：修改和重構。 :給各部門編號、命名、確定其職責范圍、任命部門經理、分配員工。在劃分子系統(tǒng)時，考慮到各子系統(tǒng)都有各自的財務處理，且有相似性，所以就把它們歸為統(tǒng)一的一個“財務子系統(tǒng)”。 ，確認其身份，登記其入住、退房時間。 ......................................................................................12 總 ER 圖 : .........................................................................................................12 五、邏 輯 結 構 設 計 ..................................................................................................14