娱乐休闲型酒店管理信息系统毕业设计论文.docx
- 文档编号:3482227
- 上传时间:2022-11-23
- 格式:DOCX
- 页数:42
- 大小:769.45KB
娱乐休闲型酒店管理信息系统毕业设计论文.docx
《娱乐休闲型酒店管理信息系统毕业设计论文.docx》由会员分享,可在线阅读,更多相关《娱乐休闲型酒店管理信息系统毕业设计论文.docx(42页珍藏版)》请在冰豆网上搜索。
娱乐休闲型酒店管理信息系统毕业设计论文
娱乐休闲型酒店管理信息系统毕业设计论文
第一章娱乐休闲型酒店管理信息系统的系统概述
1.1系统开发背景
近年来,随着改革开放步伐加快和中西方文化的交流,人民生活水平得到了极大的改善,全社会对第三产业特别是服务业的需求也越来越高。
国内旅游餐饮业,特别是宾馆、酒店行业的发展,逐渐打破了传统的普通旅游业那种以住宿休息为服务核心的单一运行管理方式。
如雨后春笋般拔地而起的高级宾馆、酒店,以其富丽堂皇的装饰、整洁舒适的环境、完善先进的设施、全面周到的服务和现代化的管理,塑造着全新的城市文化和文明形象。
在大中型城市里,除了四星级以上的酒店仍在基本遵循原由的比较保守和固定的运行模式之外,绝大多数新建和改扩建的中高档酒店,都装备了大型音像系统和桑拿浴等娱乐休闲设施或者直接以桑拿为住。
社会大众对酒店的认识和需求也随之发生了巨大变化,客人进店后,消极的休息已不是主要目的,投宿的概念已大大淡化。
因此,以人为本,突出娱乐休闲功能并兼有住宿餐饮购物等综合服务项目的酒店运行管理方式已成为时尚。
对于这些属于娱乐休闲类型的宾馆酒店,特别是能全面满足客人持卡消费的酒店,其接待本地客人的比例和数量都会大幅度上升,使旅游业原有的淡旺季特征不在明显,从而取得了更好的经济效益。
由于这类新型酒店的运行模式与传统酒店有很大的差异,它涉及的环节比较多,业务关系也比较复杂,因此到目前为止还没有一套较规范的公认的运行管理标准。
而照搬传统的酒店业务管理方式和运营机制显然已不能适应这些变化,难以满足实际需要了。
同样,那些基于传统酒店业管理模式而开发的计算机管理系统自然难以适应这种新的业务模式,所以造成一些酒店不得已而采用水工计费和人工结帐的方法,尤其是在新型酒店开业时增加新的服务项目时,这种现象往往很普遍。
显然,采用人工手段进行复杂的业务处理是一种相当原始的方法,在客户服务、人员管理、财务管理等方面都存在着许多薄弱环节,会给酒店的正常运行带来各种麻烦和漏洞。
比如,不能实施全面的持卡消费、不能与现代的电子商务营销模式接轨等等,客观上严重制约着酒店的发展。
酒店业务流程的多样性和客人的流动性也决定了手工方式不可能长久,必须按照新的模式进行全面细致的系统设计和软件开发,以适应着类酒店的计算机管理信息系统的迫切需求。
面对这种具有现代文明时尚的新型酒店的灵活多变的运营方式,更需要管理者和开发者用现代化和超前的眼光去看待它与认识它,要结合信息网络的特点,采用有效的手段进行方位的调查和分析。
开发的全过程始终要采取用户至上的观点,一切从用户利益考虑,在加强调查研究和系统分析的基础上,通过分步骤的不断的反馈的讨论方式确定出新系统的最佳方案。
各阶段可在局部上使用结构化、模块化的方法严格按照有效阶段进行开发,具体手段上尽量采用面向对象的开发形式,使形成的应用软件模块具有很强的独立性、适应性和扩展性。
1.2项目开发目的
项目开发目的具体任务就是设计一个娱乐休闲型管理信息统,利用现代计算机与数据库开发技术的提高,从而有效的对娱乐休闲型酒店的管理,提高工作质量与效率。
1.3可行性分析
传统酒店管理模式一般是以客房为主导,除了房费按客房结算,客人在酒店内的其他一切消费也基本上是按房间号划分。
而娱乐休闲型酒店则以每位客人为主导,客人的消费是按每人持有唯一性标志进行记录和统计的,它强调的是每位客人在酒店内的不同消费和接受的各种服务,也就是说消费与客人直接对应,这也是客人持卡消费的业务基础。
传统酒店以住宿为主要功能,房费结算也基本上是按天结算,其营业过程具有明显的时间段概念,故而大部分软件系统中都设置夜核功能,一般是在夜间(0点以后)将前一天的营业情况和数据进行核对、出汇总表,并完成数据库的整理和历史数据的转存,而娱乐休闲型酒店没有明显的时间段要求,客人随时可能来,也随时可能走,房费不以天为单位计算,没有客人在几点以前(以后)离开如何计费的说法,而是根据客人在店内停留的实际时间长短具体计算。
因此软件系统也就无法也没必要设置夜核功能,需要随时对数据库进行整理和转存历史数据,报表也是实时的,随时可以按照用户的要求统计产生。
在针对实际系统进行关系定义和逻辑设计过程中,我们发现采用移植的办法虽然在模块设置阶段进展很快,但后来就会被两类不同运行模式中的复杂关系所纠缠,而影响了开发进度,甚至会造成大面积返工。
相反,按照娱乐休闲型酒店的实际业务流程重新进行系统设计,到开发后期,就会发现这种淡化了住宿功能,而以洗浴、服务为主线的接待和消费方式还有一些规律性。
特别是实际系统在运行时对多用户实时共享的要求很高,着使得开发者在程序设计时更需要一个清晰的流程,需要完善的模块封装和灵活的数据接口,不因当搞无谓的引用和交叉而影响到系统的可靠性。
因此,我们采用了后一种思路。
系统的设计开发过程采用了快速原形法、结构化方法和演示讨论相结合的混合方式。
鉴于这类新型酒店的应用需求是不规范的和分批提出的,系统分析的深度和广度只能在开发过程中逐步增加和完善,所以在开发初期一般无法完整地定其总体设计方案。
为此,我们从用户对应用系统的粗略描述开始,现在计算机上搭建起一个简单的应用模型,并以词模型为基准,根据用户的意见和要求对系统进一步细化,通过不断的建模、演示、交流和讨论,使系统一步步地接近实际。
在开发后期,开发人员同用户已经有了充分的沟通,因此在一些后台模块的开发上也遵循了结构化的生命周期法。
在程序设计方式上主要是利用了一些高效率的面向对象的开发工具。
第二章娱乐休闲型酒店管理信息系统的系统分析
(一)酒店的组织结构
总经理
其他部门
------
财务部
康乐部
餐饮部
客房部
登
记
楼
层
洗
衣
餐
厅
酒
吧
洗
浴
区
娱乐
区
购
物
库
房
收银
台
点单
刷卡
酒店现形的组织结构
(二)基本术语
在娱乐休闲型酒店管理中,一般将业务流程的运行称为流转。
下面以“手牌”的流转为列,介绍酒店中一些基本术语:
手牌:
指客人在酒店内的身份标示。
每个客人在店内活动,均须随身携带一个号码唯一的手牌。
手牌在客人进行入店登记时取得,客人凭各自的手牌进行洗浴、娱乐、消费和接受各类服务。
主手牌:
这是针对一个以上的客人组成的团体而言的,主手牌的持有者作为该批客人的代表,是双方临时约定的总付帐人。
鞋牌:
客人进店后首先要到总台旁边的鞋房换拖鞋,同时领取与鞋架对应的具有唯一号码的鞋牌,然后凭鞋牌进行初始登记并领取各类手牌。
散座:
酒店为了方便仅为洗浴或消费的而来的客人,特别开辟了若干个比较大的空间,内设了一批可供临时休息的床位,称为散座。
超时:
在客房和散座的计费方面,这类酒店一般给客人规定一个固定的容许在店时间(如12小时),客人登记后开始计时。
点单:
房费散座费中以包括了基本的洗桑拿浴的费用。
客人若另外接受了按摩、美容、洗衣等附加服务,或者点了酒水,购买了物品等,则需另外签单,在结帐时一并付费。
班次:
24小时内业务部门按两个班次轮转,通常白班为8:
00~18:
00,这样可保证后台繁荣财务人员在19:
00前下班,夜班为18:
00~次日8:
00。
免单:
经酒店总经理或其他高级管理人员的批准,可免收某批客人的部分或全部费用。
(三)业务调查
酒店内主要包括接待、餐饮、康乐、收银、库存、财务等几大业务部分,试营业时所有业务均为手工处理。
经调查得到以下的业务基本情况:
接待业务:
客人进入、首次迎宾、到鞋房换鞋、领鞋牌。
到总台登记、选房/散座/收押金/刷卡、开设帐户、明确折扣和其他优惠措施/领手牌(明确主手牌)和房们IC卡、存鞋牌。
点单业务:
当客人在店内进行一项/多项消费或接受服务后,有关技师或服务生立即将相应的内容填写在三联单上,并根据其手牌号请客人签字,其中的一联要立即送到总台供结帐时汇总。
楼层业务:
各楼层的服务生应及时清扫房间,传送有关单据,应客人要求安排各种服务活动,向总台通报房间状况变化情况和客人遗失物品情况,提醒超时或超费用的客人补押金,客人退房时进行列行检查,填退房单,房间有故障时报修。
收银业务:
客人交还手牌/对应的帐单汇总/结帐/收/退款/刷卡/送客。
餐饮业务:
客人进入餐厅/迎宾开始/点菜/餐间服务/结帐/。
库存业务:
办理消费品和消耗品的入库登记,分类分批次分价格统计库存,控制商品质量和保质期,分营业部门出/退库,记录库存帐目,按规定时间制作库存报表。
2.2酒店实施管理信息系统的基本目标
娱乐休闲型酒店要想依托计算机网络开展现代化管理,必须首先依据酒店行业特定的运营方式和工作流程,对电脑软件系统要开展的工作提出一些基本要求。
这些要求会促使开发者和用户共同去全面深入地分析了解酒店的运作机制,区分经营项目类别和经营方式,掌握经营的难点和侧重点,从而才能在此基础上设计和开发出既符合酒店的实际情况,有能充分发挥计算机管理的积极作用,独具特色的管理信息系统,。
这个系统应该给酒店的经营带来直接或间接的经济效益,使酒店能在先进的计算机网络系统的支持下在管理方面逐步上档次上水平,进一步提高效率和体现酒店的整体形象。
这些基本要求如下:
1实现多操作点的信息共享,相互之间的信息传递要做到标准、快捷和顺畅
酒店管理信息系统中,各操作点在信息处理过程中离不开相互之间的信息传递。
列如客人在结帐时离不开入住时间、餐饮、消费、娱乐、房费、帐单的相互关系等多种信息的检索和综合。
表面上看,每个操作点的信息处理量都不是很大,都是些简单的录入,计算,修改和查询等,但对各类信息实施灵活而有序的实时管理,关键在于系统应用平台对信息共享的支持程度。
多操作点的快速并行工作,要求各操作点对相关信息的处理基本上能同时进行。
虽然多用户或网络管理软件在操作系统支持这种需求,但在应用系统的分析设计和程序开发过程中也要注意这个问题,避免引起冲突,这一点十分重要。
另外,必须在提供多点并行处理的同时,保证信息的可靠性和实是性。
列如,当客房部门因故修改房间状后,为客人办理入住用房手续的前台就应当及时得到或探知最新的房间信息,避免在同一时刻对同一房间采取不同的信息处理过程而产生业务上的误导。
总台结帐时,发现该帐户仍然有消费项目正在点单,则由系统提示收银员展缓进行结帐操作。
2采用图形化的操作界面,使人机对话方便,易懂、易用、
易培训.
系统的业务特点和酒店工作人员的素质都要求人机对话应当是十分方便的。
尤其在前台部分,当操作员在微机上进行业务处理时,其操作方式和相应的操作码要尽量简化统一,使操作员基本上靠移动鼠标来完成任务。
这一点与酒店要求前台工作人员尽量面向客人的规定是一致的,操作员过多的注视屏幕会使客人有冷落感。
因此,人机对话过程要尽量符合操作者的思维习惯,采用图形/图块显示方式,这样会减少理解和学习的难度。
常用的服务内容和项目一般采用速记码快速输入,可缩短操作时间,减轻工作强度。
此外,由于多数酒店的中下层员工流动性较大,造成其电脑管理部门经常忙于开展对新员工的电脑操作培训和技能测试。
如果应用软件系统的操作方式简单划一,人机对话形象方便,就可以减少再次培训的难度和工作量。
3系统24小时连续可靠运行,对重点业务实施全天动态监管
酒店中客人的往来是随机的,因此酒店必须24小时提供不间断的服务。
这对系统的要求包含两个方面:
第一,系统设计要面向连续性。
系统要满足客人随时点单、查询和结帐的要求,需考虑在汇总报表及每日交接班时支持对其他业务的并行处理,避免对酒店正常业务的影响。
在程序设计中要充分考虑24小时连续工作中对数据处理的实时性要求,采取措施自动进行数据的存储、整理一致性校验。
第二,系统的维护和管理要面向连续性。
软件开发时必须考虑系统在连续工作条件下的可维护性,出现局部故障后系统总体的强壮性,需要对重要信息进行动态监管,并建立有效的事后安全恢复机制。
当然,为了保证系统的连续正常运行,在系统试运行期间进行完全彻底的测试必不可少。
开发者要在系统建立初期就为酒店代培网络管理系统和业务管理系统的系统管理员,并支持其自行开展系统的维护管理工作,同时开发者也要安排专业维护人员对系统运行中的特殊要求随时响应。
4系统维护方便可靠,有较高的安全性,满足实用性、先进性和经济性的要求.
在系统设计是就应当选择先进的软硬件平台和面向对象的开发工具,充分利用系统软件自身提供的维护手段,以有针对性的维护策略和方法,尽量减少维护时对数据库的独占,保证系统的安全运行。
通过双方的磨合,初步建立起来的系统要与实际工作紧密配合,既要发挥出计算机作为先进管理工具的特征,将繁杂的手工制处理减到最少,堵塞住各种管理漏洞,又要充分调动各级管理人员从系统中获取实用信息,协同开发者不断对系统进行改进的积极性。
系统后台的查询、统计和报表部分要能及时,准确和灵活地反映出各种情况,特别是通过十分经济的方式得到过去根本无法或者很难通过手工获取的各个侧面的汇总信息。
酒店的高级管理人员能在此基础上进行科学的分析和判断,在微观上提高管理的精细程度,在宏观上进行重大的决策提供帮助。
2.3业务流程图《1-1》
散座客人
清扫房间
报表
客房客人
房态状况
点单消费
现结
迎宾
查询
库房
选房选散座
消费单
顾客
离
店
统一
结帐
分发
手牌
总台接待登记
退牌
房费单
鞋房换鞋
建立帐户
当前客人帐单
历史
单据
挂帐
酒店业务流程总图
前台消费
价格控制
进货
合同
领用
出库
库存帐
入库
成本控制
退货
盘店
损益
库房商品流转业务流程图《1-2》
2.4数据流程图
在分析各业务模块的状态和相互关系的基础上,可以分别画出各个系统的数据流程图,其中的数据程总图给出了系统中涉及客人部分的一般性业务流程。
统计报表
财务经理室
房号
客人历史DB
鞋牌柜
房态表
库房
基价表
房号
出库
离店
结帐
消费
入店
确认
总台
接待
客人
确定手牌
建立帐户
客人帐单DB
帐号、手牌号、房号
房费
计算
在店客
人DB
餐饮娱乐
费计算
直接
结帐
离店
系统数据流程总图《1-3》
消费项目
前台
点单员
客人消费签单
在结帐
增册记录
数量数量
消费帐单
消费类
手牌号
押金
超押金提示
相关消费
主客资料
点单业务的数据流成图《1-4》
打印帐单
离
开
历史
DB
在店
客人
DB
生成
点菜
要求送餐
流水号
合同
DB
挂单
客人手牌号
结帐
菜谱
加菜
洗台
客人
速记码
换/退菜
挂帐
用餐帐单
换台
台号
餐饮业务的数据流程图《1-5》
说明:
在餐厅结帐时,有现结、挂单和挂帐三种。
操作员将客人点、换、退菜的项目和数量输入微机,则系统自动调用餐厅,明细库中的基价,通过计算生成帐单,同时核减或增加有关营业部门中与菜谱相对应的各种配料,同时用移动加权平均计算方法调整由此而引起的部门中相关原物料的累计成本数额。
对于客人因故退回,但已无法再销售的菜肴,在做完退菜处理后,还要将其计入损耗,以保证有关部门中原物料存量数据的准确性和成本核算的准确性。
餐厅中也设置了收银台,客人可以直接在餐厅结帐,持有手牌者也可以先签单,将该笔帐单挂回自己的客房总帐中,待离店时在前台一并结算。
餐饮结帐时可打折,部分打折或免单。
在店客人信息
侧除
余额挂帐
输单员
入店时间
预览帐单
手
结帐正在牌
余额挂单
计算
房费
时间点单号
结帐
预结帐
客人
付款方式
计算
消费
折扣率
打印帐单
折扣/免单
批准人
在店客人帐单
侧除
客人历史信息
结帐业务的数据流程图《1-6》
说明
客人结帐时,收银台应处理的几个问题:
房费结算、娱乐消费结算、餐饮消费结算。
1房费消费结算
房间可以分为标准间、经济二人间、三人间、四人间、豪华三人间等多种类型,不同的房型按各自的标准收费,但根据客人在酒店停留时间的长短,又将同一类房间的价格分成四种(普通房价、长包房价、优惠房价、钟点房价)。
前三种房价均以客人入住12小时为一个基本收费单元酒店称为一个轮转,客人结帐时,收银员应先明确执行那一种房价,系统从房间类型表中调出各类房间对应的基价,然后再判断客人是否超时。
酒店一般容许客人多停留1小时,在该宽限期内不收超时费。
若在超出这1小时则加以收超时费,即在基价的基础上每超1小时加收%10的超时费。
根据客人利益最大化的原则,超时在10~12小时之间的免收该时段的超时费,散座则以14小时为一基价,每超2小时则再收一个基价。
仅进行娱乐的客人不收房费,其房间的基价为零。
2娱乐消费结算
娱乐消费包括桑拿、健身、游戏、球类、酒吧、美容等等
每项消费都从消费明细库汇总调出基价,乘以消费次数后求和,消费次数可以不是整数。
计时性消费在点单时就算出了金额。
3餐饮消费结算
菜肴类消费可按列盘或斤两/个数进行,系统分别从菜价数据库中调出基价,乘以相应的消费数目求和,生成餐厅消费帐单。
财务部
有效合同
批准
定价
供货商
库房
检货单
验收
标签
货物合格
不合格退货
历史合同
变动表
进货业务流程图《1-7》
库存帐
ABC
分析
价
格
入库单
验货单
定批次
财务部
退库单
清单
批准人
退款单
前台
入库业务流程图《1-8》
财务部
对帐表
退库单
批准人
客人
消费
部门台帐
出库单
部门
零耗单
消耗
消耗定额
库存帐
物品领用流程图《1-9》
第三章酒店休闲型管理信息系统的系统设计
3.1系统结构设计
1系统模块设计
系统的模块化形式在前面的内容中以有了较详细的描述,根据以客人为核心的运营模式,我们可以将这些模块定界为三个大层次,前台、后台和管理层。
不同层次的模块在设计上有不同的侧重,但提高并行处理和数据共享的程度,防止网络和功能冲突是模块划分时要特殊考虑的问题。
(1)前台
凡直接与客人接触,发生信息,物品或货币交流业务关系的,需要在计算机上进行记录,协调和处理的工作均属于前台范畴。
这个前台概念不仅包括酒店大堂前台的接待、收银、查询、餐厅的点菜,送餐和收银,各楼层的退房检查、精品购买、外卖和娱乐,还有为客人提供的多媒体接触屏查询和引导系统,电子商务网上营销系统等。
这些模块在运行时,既要符合酒店内部业务管理的要求,也要考虑客人的消费心理和思维习惯,通常应把客人也当作系统的设计对象之一。
要充分了解客人的想法和意愿,掌握他们的一般性需求和特别需求。
为系统制定的输入输出步骤和效果要能获得客人的积极配合,同时也要使操作员感到方便和快捷。
无论是信息流还是资金流,都要在与客人的反复交流过程中顺畅的运行,避免不必要的阻碍,在逻辑关系上要预先考虑各种可能发生的情况并设计出响应的对策,以便迅速准确地完成对客人的各种服务。
(2)后台
指那些对前台提供支持,一般不直接与客人发生关系的业务点。
如各楼层的点单、男女浴、美容美发、洗衣等消费服务单的输入、房态修改、库房、餐厅厨房、财务部门等。
虽然其中有一部分是通过单据与客人接触的,如客人消费签单,计时服务,为客人门提供物品的服务过程等,其特点是客人的需求以满足并在单据上记录后,由服务生将单据就近送到附近的一台微机出,再由输单员把有关内容输入到计算机系统中。
此时输单员面队的是单句而不是客人,所以我们认为其工作属于后台性质。
这些模块应简洁明确,以提高效率和方便使用为设计目的。
同时考虑培养使用者的工作习惯,强化他们对系统功能的理解和按流程办事的意识。
由于许多操作都是一次性的,在保证正确输入的前提下,系统内部对后台的各项操作都应区分权限,有详细的记录日志,以便事后进行核对,分清责任。
(3)管理层
通常前后台之间没有相互控制关系,虽然个别模块在运行时某些功能为了防止冲突,存在着互锁的可能,但我们都将协调双方的操作步骤,使其限制在最小的时间范围内,系统也会及时对此做出明确的文字提示,引导有关的操作员进行有效的避让。
可见前后台模块间的相互影响不大,只要按规定执行完有关业务流程并予记录即可。
系统的调控通过管理层间接进行,它依据财务部门对当期业务的核算汇总和分析,由酒店的有关人士下达指令,系统管理员通过软件中的管理和维护模块对系统参数、人员、项目属性和配方等进行定义和调整,达到精细管理、提高效益的目标。
该层次的模块以贯彻酒店高级管理人员的经营思想和管理意图为设计核心,力图是使模块功能和控制流程符合酒店管理的规律,既科学合理又可操作。
在报表设计上也冲淡计算机技术和学术特点,使之更加符合酒店/餐饮界管理人员的工作习惯。
2系统控制结构
对系统的控制主要体现在对流的把握上,即对参与处理流、
信息流、资金流和物流的模块进行分析和协调,从中找出相互之间的逻辑关系,以便采用不同的控制对策。
(1)对各种流的导向
客流:
客人入住或换房时,必须提供已清扫的OK房,若无OK房,系统可提示现有的脏房供参考,前台接待员可指定其中某些房间并要求楼层服务生立即清扫,修改房态。
主手牌持有着提前离开时必须先进行主手牌变更。
信息流:
当进入结帐模块,客人也表示同意付款时,就不能倒退或取消操作,必须把帐结掉并一此性打印结帐单。
此时信息流程是不可逆的,若确实出现差错,则只能到网管中心通过历史数据处理模块进行修改。
有住从关系的帐户必须遵循规定的结帐次序。
资金流:
点单和收银模块有互锁关系,不能在同一时刻对同一客人既点单又结帐。
系统的超押金提示可控制客人的过度消费。
同一帐户下的客人分别付款时,最终结算前支付的均按补押金来操作。
物流:
确认无法重新使用的消费,即便做了撤消点单处理,也要进行等量的报损。
(2)权限控制
系统运行初期可给各业务点适当多开放一些权限,目的是发生操作错误后能及时调整。
一旦系统运行基本正常,操作员比较熟练后,应当将其权限控制的最小的程度,防止应误操作而带来的责权上的矛盾。
列如初期在收银处设置了点单修改功能,使收银员能及时修正点单中的错误,但后来发现在结帐单中体现的消费数据与各业务点的原始签单有不一致的情况,所以再操作员对系统基本熟悉后就取消了收银员的这个权利。
(3)为了防止恶意操作,在关键点处要有意识地设置了多重的检查、校验和记录。
3.2网络规划
1网络总体结构
因为该系统总体的数据传输量不太大,而且主要工作站与服务器距离一般业不超过100米,故我们采用了当前最为成熟的低成本的10Base-T以太网作为网络的主干。
考虑到今后在电子商务方面的扩展和应用,我们采用5类双绞线以共享式HUB为中心,按照星型拓扑结构实施布线,使该网络系统可随时升级成100Base-T的快速以太网,满足Internet和VOD(视频点播)等新业务对网络带宽的要求。
娱乐休闲型酒店一般为多层建筑,通常的布局是把前台接待、收银、餐厅和洗浴区设在一层,散座、美容、精品购物、酒吧等设在二层,二层以上为各类客房,网管中心,管理办公室和财务室设在大楼的中间层。
网络服务器(一般配置要达到PII30064M/4.3G以上,负责提供文件服务和后台数据库服务)设在网管中心,它是整个酒店计算机管理系统的信息中心,必要是还应该设置备份服务器(配置可稍低些,平时兼作他用)。
服务器上安装56K的内置式MODEM和10M或100M自适应PCI网卡,该网卡直接与HUB短距离相连。
为了满足远程查询/维护,网上信息发布和营销以及公安机关对外籍人员实施连网管理的需要,MODEM应通过酒店的程控电话交换机
- 配套讲稿:
如PPT文件的首页显示word图标,表示该PPT已包含配套word讲稿。双击word图标可打开word文档。
- 特殊限制:
部分文档作品中含有的国旗、国徽等图片,仅作为作品整体效果示例展示,禁止商用。设计者仅对作品中独创性部分享有著作权。
- 关 键 词:
- 娱乐 休闲 酒店 管理信息系统 毕业设计 论文