酒店管理信息系统(共23页).doc

《酒店管理信息系统(共23页).doc》由会员分享，可在线阅读，更多相关《酒店管理信息系统(共23页).doc（23页珍藏版）》请在淘文阁 - 分享文档赚钱的网站上搜索。

1、精选优质文档-倾情为你奉上应用软件工程方法对酒店进行管理 作者：李凤 李聚宝 贾富涛 赵倩 一、背景说明 目前大多数酒店提供的服务多种多样，规模大小也各不相同，但稍具规模的酒店必含下面二类服务：饮食、住宿。由于我们对酒店行业没有具体的接触和实质性的了解。此次数据库设计只能在一些收集到的基本材料与个人直观认识的基础上，简单模仿中等规模的酒店设计管理系统，并将其抽象成一个二部门组成、实现二大服务的系统。二、部门的划分1 饮食部门 它是酒店基本部门之一。它提供服务的特点是实时性强、持续时间短，强调效率。例如，顾客人数、顾客所用的菜及其它饮料等种类繁多，数量不等；后勤各种活动如采购等频繁发生。通过分析

2、可发现，用人工完成此类操作比计算机更具实效与时效，且此类信息也没有长时间保留的必要，因此这些信息没有必要采用数据库管理。对于饮食部门，需要较长时间保留的信息主要是财务信息，一方面便于期末汇总，另一方面便于向上级报告。在规模较大的酒店餐饮服务部分，餐厅可分成几个等级或几个小部门，然后各自形成小系统，本系统为了简单起见，把饮食部门作为一个子系统，不再细分。2 住宿管理部门它也是酒店基本部门之一。住宿管理部门的主要职责有：A.给个房间布置各种设备、分类、编号、制定收费标准、分配服务人员。B.登记旅客信息，确认其身份，登记其入住、退房时间。C.统计各类房间的客满程度。D.对本部门的财务流动进行登记处理

3、。以上信息处理可以通过计算机完成，其他不便于计算机操作的在此没有列出。3 经理部门 经理部门的功能虽然不是面向顾客、不是酒店的服务项之一，但它的存在却是必不可少的。它的主要职责有：A.管理员工。给员工编号，登记其基本信息；根据员工的平时表现及工龄确定工资；此外，还要给员工分配工作部门及职务等等。B.划分部门。给个部门编号、命名、确定其职责范围、任命部门经理、分配员工。C.对本部门的财务进行核算（支付工资等）。D.期末对酒店的收益情况进行核算。三、 课程题目 1、 课程题目：酒店管理系统。2、 编写目地：完成软件工程概论课程设计内容，供老师进行课程考核。 第一章 系统分析一、 系统简介1、 酒店

4、管理系统开发的环境 C+是我们大学学习中学习的一门课程，我们利用课余生活用C+编辑了酒店管理系统，因时间的管理设计的不是很充分，因此这个酒店管理系统做的不是很完美。希望老师看后能多给我指点下。（需截图）二、 基本功能 酒店管理系统有如下功能：1、 利用数据库，可以根据需要建立和保存多个客户的数据信息。2、 可以查询酒店剩余的房间信息，客户已入住信息、更改房间信息。3、 可以对客户入住进行房间选择，客户信息登记，时间登记。4、 随时可以进行按客户的要求进行更改和结算，记录本天的收入情况。5、 系统有针对于员工和管理人员的操作范围。（需截图）三、 系统流程二、 系统存在的缺点 1、 此系统没有专门

5、的代码来记录、扫描客户的照片信息。2、 此系统只凭人工输入，没有电脑的自动化系统。3、 系统没有办法进行身份证号码、客户照片进行核对，任何满足身份证的号码都可以登记入住。4、 系统没有一处有效验码验证。5、 任何人都可以进行对客户信息的修改。6、 系统部署的软件、硬件环境没有考虑。第二节 系统项目的计划、一、 项目范围都和目标 系统最终将以C+的形式进行发布，在系统进行发布前会对系统中以前含有不足的地方进行全面的修改，改善系统运行的环境，达到以前其他酒店管理系统没有的功能。最终实现的系统功能有：1、 新系统将带有全自动的扫描功能，能将客户的身份证信息通过扫描的形式记录在电脑中。2、 所有有效数

6、据存放到信息中心，通过大型数据库管理系统进行管理；3、 系统管理的权限有明确要求，针对不同管理人员，所拥有的权限也是不同的，以便于工作安全、有效的进行。4、 提供安全、便捷的查询功能，供客户和管理人员进行查询。5、 系统将接收高级数据设备，将各个同一老板旗下的酒店进行信息联合，并设置权限，让每个酒店的最高管理人员都可以查询到每一个连锁店以前和现在的客户登记信息。二、 项目的可行性分析 系统已经初步形成，能满足大多数小型酒店和宾馆的需求，同时也得到了大多数同学的认可，具有一定的可行性。1、 经济可行性本系统投资大概在2万元左右，随着世界人口的增长，旅游的人越来越多，群众和企业家对酒店管理的要求越

7、来越高，群众要求酒店办理的速度要快要方便，隐私要能够有保障，企业家要求酒店的收入要高，服务要令客户满意，并且酒店管理人员的开支不是很大，此系统的优势就在于：投资小、自动化存储信息方便快，方便意懂，能为不少企业老板省掉大半心思，并且给社会群众留下满意的服务态度。2、 技术可行性 本系统采用全自动收集数据方法，自动储存客户入住手续、结算手续、酒店收入的相关信息，虽然在技术上不是很成熟，但是有一定的可行性。3、 社会可行性 本系统一般运用于在大型的酒店当中，但是也可以用于小型酒店当中。 能够自动储存客户入住和酒店收入相关信息，最高人员可以通过互联网对酒店进行管理，办理手续壁一般的酒店快，给老板和群众

8、带来了极大的方便，并且在技术上具有一定的可行性。 综上所诉，本系统还是可行的。 三、 项目进度计划 本项目按照作业要求，安排进度如下： 序号项目天数主要工作1系统分析1完成对旧系统的分析，初步制定新系统的目标，并分析可能性确定项目计划2需求分析1确定系统的要求、功能、性能、运用、扩展3概要设计2给出系统原型、最佳方案、结构设计、数据库设计、测试结果4详细设计3文档审核5系统设计2提供测试方案第二章 需求分析第一节 基本需求说明一、 系统概述 本系统是一个酒店管理支撑系统。作为管理在酒店务服务平台，系统基于C+ 运行方式的提供酒店管理服务。二、 功能要求1、 客户可以根据自动扫描系统进行登记，无

9、需手动输入。2、 系统可以安全快捷的结算出当日酒店的收入，以及相关收入和支出的相关情况。3、 工作人员可以及时的查询房间信息和入住人的情况。4、 老板能随时随地在有网的地方查看自己酒店的营业情况。5、 客户也可以随时查询自己入住的情况。三、 性能要求安全性：提供用户身份验收证、客户隐私保护，酒店数据安全策略。友好性：好的图形用户界面。系统容量：系统可以同时对 800 个客户入住。稳定性：系统 7 天24 小时工作，并提供数据安全备份。第二节 用例分析一、 系统基本用例本系统的系统边界是：酒店服务平台。系统的参与者有：客户，一般管理人员，高级管理人员，最高级管理人员系统，系统管理员。 客户可以通

10、过系统实现以下功能： 登记 查看房间 找人 查看自己入住情况 管理人员可以通过系统实现以下功能： 记录客户的入住信息 查看亿住房间和未住房间信息 查看当日收入情况 进行员工的入职登记四、各子系统的功能虽然酒店按功能可以划分成四个部门，但是饮食部门的大部分工作手工操作比计算机操作更具有效率，如上所述，便于电脑操作只有财务处理。在划分子系统时，考虑到各子系统都有各自的财务处理，且有相似性，所以就把它们归为统一的一个“财务子系统”。同时“饮食子系统”取消，因为它的所有需要涵盖的功能都已包含在“财务子系统”中。因此系统共划分为四部分：总经理子系统、财务子系统、住宿子系统和娱乐子系统。1 总经理子系统A

11、. 对新来的员工进行编号、登记、分配工作。 员工号、姓名、性别、年龄、工龄、级别、部门号、职务、其他备注B. 对于被辞退的员工从系统中级联删除其信息，如从员工表中删除其基本信息，从它所服务的工作部门中删除该员工的工作名额，结算支付其工资、奖金；同时补充新的员工，代替它的工作。C. 对新增部门作各种初始工作。如编号、命名、任命经理等。部门号、名称、部门经理、员工数量D. 取消某个部门时，核算该部门的财务情况，并作备份；同时对该部门的员工重新分配工作。E. 其他情况的处理。2 财务子系统A. 每天的收入、支出登记编号、发票号、摘要、数量、单位、数额、经手人、日期B. 期末各子系统的财务汇总编号、上

12、月余额、总收入、总支出、余额、经手人、日期C. 期末酒店汇总个部门的财务报表，结算本酒店收益(编号、部门号、部门名称、收入、支出、净收入、经手人、日期)3 住宿子系统A. 来客登记 若多人住同一房间，只作一个记录。客人信息房间号、房间类别、客人数量、联系人名、身份、证件名称（类型）、证件号码、入住时间、退出时间B. 房间管理 旅客入住（旅客退出）除了登记（删除）客人信息之外，还应对相关的记录进行修改，如房间的状态等。房间类别类别号、名称、设备、收费标准、总数量、剩余量、管理人员房间房间号，房间类型、状态( 该部门的财务处理与饮食子系统同，归到财务子系统)五、数据字典1 数据项数据项有待按各子系

13、统分类列表。编号数据项名 称说 明 部 分编号数据项名 称说 明 部 分1员工号整数类型；有唯一性2姓名文本类型 长度为10字符3性别枚举类型：男、女4年龄整数类型 181005工龄整数类型 01006部门号数字串类型；有唯一性7名称文本类型 8职务枚举类型；根据公司的制定而定9级别号整数类型10级别名文本11工资整数类型12部门经理参照“员工号“13负责人参照“员工号“14经手人参照“员工号“15员工数量整数类型16房间类型枚举类型如单人、双人标准间等17设备文本 说明设备情况18收费标准不同的实体有不同的单位19总数量某一等级的房间的数量20剩余量某一等级房的尚可用数21房间号数字串类型

14、有唯一性22状态该房是否已被入住 枚举类型23客人数量某一房间所住的人数24身份登记旅客的目前住址25证件类型文本类型26证件号码整数类型27入住时间格式：*/*28退出时间格式：*/*29编号在各系统有不同意义，唯一30发票号按固定格式输入31摘要收入支出来源去向的摘要32数量整数类型33单价不同的系统有不同的单位34备注文本类型35日期格式：*/*2 数据结构编号数据结构名属 性1员工信息员工号、姓名、性别、年龄、工龄、级别、部门、职务、备注2部门部门号、名称、部门经理、员工数量3酒店财务总汇编号、部门号、名称、收入、支出、净利、日期、经手人、备注4部门营业情况编号、发票号、摘要、单价、数

15、量、数额、日期、经手人、备注5房间类别类别号、名称、设备、收费标准、总数量、剩余量、管理人员6房间房间号、房间类别、状态7客人信息房间号、客人数量、联系人名、身份、证件类型、证件号码、入住时间、退出时间、备注3 数据流编号数 据 流 名输 入 输 出1员工基本信息招新员工员工信息2工资结算员工信息总经理处财务支出3当前员工工作员工信息调配工作4员工新工作调配工作员工信息5“辞工”信息辞老员工调配工作6部门基本信息部门信息调配工作7更新后的部门信息调配工作部门信息8新部门基本信息新增部门调配工作9老部门信息取消老部门调配工作10顾客基本信息来客登记顾客信息11顾客需求住房登记调配住房12满足顾客

16、要求调配住房顾客信息13顾客住房信息顾客信息调配住房14目前住房信息住房信息调配住房15更新后的住房信息调配住房住房信息16住房单价住房信息住宿管理部门收入17住房数量调配住房住宿管理部门收入18数额娱乐管理部门收入娱乐管理部门信息19项目单价娱乐项目信息娱乐管理部门收入20支出情况子部门支出子部门财务信息21收入情况子部门收入子部门财务信息22部门营业情况子部门财务信息酒店财务总汇信息4 数据存储数据存储名输入数据流输出数据流 说 明 部 分员工信息员工基本信息员工新工作工资结算当前员工工作部门信息更新后的部门信息当前部门信息经理处财务信息经理处财务支出经理处财务收入部门营业情况顾客信息顾客

17、基本信息满足顾客要求住房信息更新后的住房信息目前的住房信息住房单价娱乐项目信息新娱乐项目信息老娱乐项目信息娱乐项目单价子部门财务信息收入情况支出情况部门营业情况酒店财务总汇信息部门营业情况5 处理过程处理过程名输入数据流输出数据流说 明 部 分招新员工终端员工基本信息辞老员工终端员工基本信息调配工作当前员工工作员工基本信息当前部门基本信息员工新工作更新后的部门信息增新部门终端部门基本信息取消部门终端部门基本信息部门营业结算来客登记终端顾客基本信息顾客需求顾客离开终端注销住房调配住房顾客需求注销住房目前住房信息更新后的住房信息住房数量满足顾客要求住宿管理部门收入住房数量住房单价添加新项目终端新项

18、目信息取消老项目终端老项目信息部门收入终端收入情况部门支出终端支出情况 概念结构设计过程 本公司开发酒店管理系统,经过可行性分析、详细调查以及多次讨论,确定了该系统由经理管理部门、宿舍管理部门和财务管理部门三个子系统组成。本过程结构设计过程采用自底向上的设计方法,即首先定义各局部应用的概念结构,然后将它们集成起来,得到全局概念结构.下面给出各个子系统的分析及分E-R图的设计及对其进行的各项调整。 经理管理部门子系统本开发小组成员经过调查、信息流程分析、数据收集，并结合需求分析，明确了子系统的功能:A.管理员工:给员工编号，登记其基本信息。根据员工的平时表现确定其出勤工资及根据等级确定其固定工资

19、，从而确定其实际工资，此外还要给员工分配工作部门等。B.划分部门:给各部门编号、命名、确定其职责范围、任命部门经理、分配员工。C.对本部门的财务进行核算（支付工资等）。根据要求分析给出的数据流图,参照数据字典中的详细描述,给出经理管理部门的分E-R图: 对E-R图调整的准则:现实世界中的事物能作为属性对待的尽量作为属性对待； 属性和实体的划分：属性中不具有需要描述的信息，即属性是不可分的数据项，不再包含其他信息。实体属性定义:员工(员工号、姓名、性别、年龄、工龄、级别、部门、职务、备注)工资(员工号、等级、实际工资、基本工资、出勤工资)部门(部门号、名称、部门经理、员工数量)账单（编号、发票号

20、、摘要、收入数、支出数、日期、经手人、备注）具体调整如下:1. 本来员工还应对应一个领导关系,但这里为了简便,就用员工的”等级”属性来表示员工之间的领导关系；2. 工资本应作为员工的一个属性，但这里需强调员工对应的出勤工资（由出勤情况决定），因此将它单独作为一个实体；3. 部门对应的账单本应属于财务子系统的内容，这里为了简化财务子系统，先在各个子系统中进行财务总结，因此，将账单也作为一个实体。实体属性定义:项目(编号、名称、所在位置、收费标准、负责人)员工(员工号、姓名、性别、年龄、工龄、级别、部门、职务、备注)顾客(顾客号、级别、姓名、年龄、性别、证件号码、证件名称、所选项目、使用时间、备注

21、)款项(顾客号、级别、使用时间、应收款、实际收款、折扣)折扣规则(级别、折扣情况)账单（编号、发票号、摘要、收入数、支出数、日期、经手人、备注）对E-R图调整的准则:现实世界中的事物能作为属性对待的尽量作为属性对待；属性和实体的划分：属性中不具有需要描述的信息，即属性是不可分的数据项，不再包含其他信息。具体调整如下:1本来员工还应对应一个领导关系,但这里为了简便,就用员工的“等级”属性来表示员工之间的领导关系；2款项本可以作为顾客的一个属性来设置，但这里为了强调对顾客的折扣情况，需要对款项进行进一步的描述，因此这里作为一个实体；3对顾客所采取的折扣规则，本应该根据顾客的实际消费量来划定，这里为

22、了方便起见，给每位顾客添加了一个“级别”属性，用以对应采取的折扣规则；4部门对应的账单本应属于财务子系统的内容，这里为了简化财务子系统，先在各个子系统中进行财务总结，因此，将账单也作为一个实体；住宿管理部门子系统本开发小组成员经过调查、信息流程分析、数据收集,并结合需求分析，明确了子系统的功能:A.给个房间布置设备、分类、编号、制定收费标准、分配服务人员。B.登记旅客信息，确认其身份，登记其入住、退出时间；C.接受顾客的预定服务，对于已预定的客房进行登记的处理；D.统计各类房间的客满程度；E.对本部门的财务流动进行登记处理。根据需求分析给出的数据流图,参照数据字典中的详细描述,给出经理管理部门

23、的分E-R图:实体属性定义:顾客(顾客号、级别、姓名、年龄、性别、证件类型、证件号码、入住时间、退出时间、备注)客房（客房号、类别、位置、设备、收费标准、管理人员、状态）员工(员工号、姓名、性别、年龄、工龄、级别、部门、备注)款项(顾客号、级别、使用时间、应收款、实际收款、折扣)折扣规则(级别、折扣情况)订单(订单号、时间、房间号、经手人、备注)账单（编号、发票号、摘要、收入数、支出数、日期、经手人、备注）对E-R图调整的准则:现实世界中的事物能作为属性对待的尽量作为属性对待；属性和实体的划分：属性中不具有需要描述的信息，即属性是不可分的数据项，不再包含其他信息。具体调整如下:1本来员工还应对

24、应一个领导关系,但这里为了简便,就用员工的“等级”属性来表示员工之间的领导关系；2款项本可以作为顾客的一个属性来设置，但这里为了强调对顾客的折扣情况，需要对款项进行进一步的描述，因此这里作为一个实体；3对顾客所采取的折扣规则，本应该根据顾客的实际消费量来划定，这里为了方便起见，给每位顾客添加了一个“级别”属性，用以对应应采取的折扣规则；4部门对应的账单本应属于财务子系统的内容，这里为了简化财务子系统，先在各个子系统中进行财务总结，因此，将账单也作为一个实体。财务管理子系统本开发小组成员经过调查、信息流程分析、数据收集,并结合需求分析，明确了子系统的功能:A. 对各个部门上交上来的收支情况进行汇

25、总，得出各个部门的损益情况；B. 对整个酒店各个部门的损益情况进行汇总登记，得出本期酒店的损益；C. 将整个酒店的收益情况下发给各个部门，帐务公开，集思广益。分E-R图如下:实体属性定义:部门(部门号、名称、部门经理、员工数量)员工(员工号、姓名、性别、年龄、工龄、级别、部门、职务、备注)账单（编号、发票号、摘要、收入数、支出数、日期、经手人、备注）总帐(编号、部门号、收入、支出、净利、日期、经手人、备注)财务状况（时期、总收入、总支出、净利润）对E-R图调整的准则:现实世界中的事物能作为属性对待的尽量作为属性对待；属性和实体的划分：属性中不具有需要描述的信息，即属性是不可分的数据项，不再包含

26、其他信息。具体调整如下:员工应对应一个领导关系,但为了简便起见,就用员工的“等级”属性来表示员工之间的领导关系。视 图 集 成以上便是四个子系统的分E-R图设计及其调整的整个过程，接着要做的就是将所有的分E-R图进行综合,合成一个系统的总E-R图.由于本系统比较简单,分E-R图规模也比较小,所以E-R图合成过程采用一次将四个子系统分E-R图集成总E-R图的方式.分两步进行：第一步：合并。解决各分E-R图之间的冲突，将各分E-R图合并起来生成初步E-R图。各分E-R图之间的冲突主要有三类：1 属性冲突：（1）属性域冲突，即属性值的类型、取值范围或取值集合不同。由于本系统较简单，所以并不存在这种冲

27、突； （2）属性取值单位冲突。由于本系统较简单，不存在这类冲突；2 命名冲突：（1） 同名异义：由于本系统较简单，所以不存在这类冲突；（2） 异名同义：由于本系统较小，所以不存在这类冲突；3 结构冲突：（1） 同一对象在不同应用中具有不同的抽象：本系统在需求分析阶段原本存在这种冲突，考虑到后期的简化合并，我们在设计各个分E-R图就早先解决了这个问题，即将在任何一个分E-R图中作为实体出现的属性全部作为实体；（2） 同一实体在不同分E-R图中所包含的属性个数和属性排列次序不完全相同：由于本系统较简单，所以并不存在这种冲突；第二步：修改和重构。消除不必要的冗余，生成基本E-R图。由于本系统涵盖的内

28、容比较少，基本不存在冗余的现象，所以初步E-R图就是基本E-R图，不必再进行调整。下面给出E-R图。总E-R图:员工(员工号、姓名、性别、年龄、工龄、级别、部门号、职务、备注)；工资(员工号、等级、实际工资、基本工资、出勤工资)；部门(部门号、名称、部门经理、员工数量、财务状况编号)；项目(项目编号、部门号码、名称、所在位置、收费标准、负责人号)；顾客(顾客编号、级别、姓名、年龄、性别、证件号码、证件名称、所选项目、使用时间、备注)；客房（客房号、类别、部门号、位置、设备、收费标准、管理人员号、状态）；款项(款项编号、顾客号、项目号、折扣级别、使用时间、应收款、实际收款)；折扣规则(折扣级别、

29、折扣情况)；订单(订单号、顾客号、经手人号、备注)；账单（账单编号、总帐编号、发票号、收入数、支出数、日期、经手人号、备注）；总帐(总帐编号、部门号、财务状况编号、收入、支出、净利、日期、经手人号、备注)；财务状况（财务状况编号、时期、总收入、总支出、净利润）；逻 辑 结 构 设 计一.与总E-R图对应的关系模式1、实体所对应的关系模式：员工(员工号、姓名、性别、年龄、工龄、级别、部门号、职务、备注)；工资(员工号、等级、实际工资、基本工资、出勤工资)；部门(部门号、名称、部门经理、员工数量、财务状况编号)；项目(项目编号、部门号码、名称、所在位置、收费标准、负责人号)；顾客(顾客编号、级别、

30、姓名、年龄、性别、证件号码、证件名称、所选项目、使用时间、备注)；客房（客房号、类别、部门号、位置、设备、收费标准、管理人员号、状态）；款项(款项编号、顾客号、项目号、折扣级别、使用时间、应收款、实际收款)；折扣规则(折扣级别、折扣情况)；订单(订单号、顾客号、经手人号、备注)；账单（账单编号、总帐编号、发票号、摘要、收入数、支出数、日期、经手人号、备注）；总帐(总帐编号、部门号、财务状况编号、收入、支出、净利、日期、经手人号、备注)；财务状况（财务状况编号、时期、总收入、总支出、净利润）；说明：1.下加横线部分表示关系的码 2.以上关系的详细内容说明请参照概念结构设计中的具体内容 3.上面的

31、各个关系对概念结构设计中的相关内容了作了修改，主要加了各个实体中间的联系，尤其是一对多的联系，纳为属性。2、联系所对应的关系模式：1）、把客房和订单之间的n : m的预约联系转化为相应的关系模式如下： 预约（订单号、客房号、始定时间、结束时间）；2）、把顾客和房间之间的n : m的住宿联系转化为相应的关系模式如下： 住宿（顾客号、房间号码、住宿时间）；3）、把顾客和项目之间的n : m的选择联系转化为相应的关系模式如下： 选择（顾客号、项目号、发生时间、经受人号、备注）；4）、其他联系处理说明如下： 工资和员工之间的1：1联系与员工关系合并； 顾客和订单之间的1：1联系与订单关系合并； 折扣规

32、则和款项之间的1：1联系与款项关系合并； 员工和部门之间的n：1联系与员工关系合并； 部门和财务状况之间的n：1联系与部门关系合并； 客房和部门之间的n：1联系与客房关系合并； 项目和部门之间的n：1联系与项目关系合并； 总帐和财务状况之间的n：1联系与总帐关系合并； 帐单和总帐之间的n：1联系与帐单关系合并； 帐单和项目之间的n：1联系与项目关系合并；根据需求分析阶段的ER模型，建立实际的数据表，将有关的SQL语句呈现如下:1.管理员:create table admin ( ad_id int identity not null, ad_name varchar(30) null,-用户名

33、 ad_pwd varchar(30) null,-密码 ad_power int null,-权限 constraint PK_ADMIN primary key (ad_id)go结帐表：create table getmoney ( get_id int identity not null, get_usinfodanju varchar(30) unique null,-单据号 get_useruid varchar(30) not null,-用户身份证 get_roomno varchar(30) not null,-房间编号 get_usinfotime datetime nul

34、l,-入住时间 get_usinfoouttime datetime null,-退房时间 get_usinfoday int null,-实住天数 get_price decimal null,-消费金额 get_vip float null,-VIP打折 get_money decimal null,-实收金额 constraint PK_GETMONEY primary key (get_id)go房间表：create table room ( ro_id int identity not null, ro_no varchar(30) unique not null,-房间编号 ro_

35、cengshu int null,-房间层数 ro_type varchar(30) null,-房间类型 ro_price decimal null,-房间价格 ro_people int null,-房间可住人数 ro_state int null,-0可住 1不可住 -房间状态 constraint PK_ROOM primary key (ro_id)Go用户表：create table users ( us_id int identity not null, us_uid varchar(30) unique not null,-用户身份证 us_name varchar(30) n

36、ull,-用户名 us_sex char(2) null,-性别 us_age int null,-年龄 constraint PK_USER primary key (us_id)Go用户入住情况：create table userinfo ( usinfo_id int identity not null, usinfo_dangju varchar(30) null,-单据号 usinfo_no varchar(30) not null,-房间编号 usinfo_uid varchar(30) not null,-身份证 usinfo_time datetime null,-入住时间 u

37、sinfo_day int null,-预住天数 usinfo_money decimal null,-押金 usinfo_isout int null,-1在住 0没在住-是否可住 constraint PK_USERINFO primary key (usinfo_id)Go用户入住情况（子）连接用户表（父）-alter table userinfo- add constraint FK_GETMONEY_GETMONEY _ROOM1 foreign key (usinfo_uid)-子- references users (us_uid)-父用户的入住情况连接用户表-alter tab

38、le userinfo- add constraint FK_GETMONEY_GETMONEY _ROOM2 foreign key (usinfo_no)- references room (ro_no)结帐表连接用户的入住表-alter table getmoney- add constraint FK_GETMONEY_GETMONEY _ROOM3 foreign key (get_usinfodanju)- references userinfo (usinfo_dangju)二.优化后的数据模型1、 按照数据依赖对关系模式进行逐一分析，并进行极小化处理：员工(员工号、姓名、性别、年龄、工龄、级别、部门号、职务、备注)；BCNF工资(员工号、等级、实际工资、基本工资、出勤工资)；BCNF部门(部门号、名称、部门经理、员工数量、财务状况编号)；BCNF项目(项目编号、部门号码、名称、所在位置、收费标准、负责人号)；BCNF顾客(顾客编号、级别、姓名、年龄、性别、证件号码、证件名称、所选项目、备注)；BCNF优化说明：删除了使用时间，一是因为“使用时间”对于顾客的属性必要性不强，二是因为使用时间在别的关系中也可以查询到。客房（客房号、类别、部门号、位置、设备、收费标准、管理