酒店管理系统中的数据库设计

1、酒店治理系统中的数据库设计XX： 1009-3044(20XX)17-4043-03Dtbse Design in the Hotel Mngement SystemTN Qin-fng(HunnFoodndDrug Voctionl College， Chngsh410016,Chin)bstrct： Intheprocess ofbuildinginformtionmngement system, py more ttention on reliztion, Contempt on design is common problem with technology developers, e

2、specilly the stndrdiztion of bck-end dtbse design is esily overlooked. This will led to the eventul reliztion of the system dt processing cpcity is limited, inefficient, dt mngement, mintennce nd post-updte difficul? ties. The rticle strictly follow normlized dtbse design ides, with the typicl busin

3、ess hotel mngement system for business logic toex? plin the minsteps in the informtion systems development process, dtbse design nd methods.Key words: informtion system; hotel mngement; dtbse; progrming在信息治理系统的设计和开发过程中，数据库设计是其中最为重要的环节之一。设计规范、良好的数据库不仅能带来系统数据处理效率的极大提升，更重要的是在系统正式运行后能大大简化后期的数据更新维护工作，提高系

4、统的可扩展性。目前大多数酒店提供的服务多种多样，规模大小也各不相同，较为典型的酒店服务业务一般都包括饮食、住宿和娱乐等方面，下面该文从这些典型的酒店业务逻辑出发，分析和探讨数据库的设计方案。数据库需求分析数据库设计的第一步是做好需求分析。在此阶段需要准确了解和分析用户的具体需求，包括数据需求和处理需求，这是整个数据库设计过程的基础，也是最困难、最耗费时间的一步。数据流图分析典型的酒店治理一般包括饮食部门、住宿治理部门、娱乐治理部门和经理部门，下面简要分析各部门的业务逻辑。饮食部门是酒店基本部门之一，所提供服务的特点是实时性强、持续时间短、强调效率。此处需要重点处理的信息是与饮食有关的财务数据，

5、一方面便于定期的账目汇总，另一方面也便于及时向酒店治理层汇报。 TOC o 1-5 h z 住宿治理部门也是酒店基本部门之一。其主要职责包括：（ 1 ）布置房间设施、分类、 编号、 制定收费标准、分配服务人员；（ 2）登记旅客信息，记录其入住、退房时间；（ 3）统计各类房间的客满程度； （ 4）处理本部门的财务信息。娱乐部门需要处理的业务主要包括：（ 1 ） 制定收费标准，分配负责人；（ 2） 收入支出财务处理等。经理部门的功能是必不可少的。主要职责有：（ 1 ）员工治理；（ 2）部门划分；（ 3）各部门的财务核算；（ 4） 酒店营业收益的定期核算。从上面各个部门的业务分析可以看出，不同部门都

6、有财务处理的需求，因此归总设计一个统一的“财务子系统”。而饮食部门因为所需要的业务功能都已包含在“财务子系统”中，故而去掉该功能模块。最终设计酒店信息治理系统分为四个子模块：经理子系统、财务子系统、 住宿子系统和娱乐子系统。根据前面对业务逻辑的详细分析，画出各子系统的数据流图，例如图 1 所示为财务子系统的数据流图。数据字典设计数据字典是数据库中各类数据描述的集合，需要设计人员对所开发系统的实际情况进行详细的数据收集和数据分析才能得到。数据字典内容一般包括数据项、数据结构、数据流、数据存储和数据处理过程。下面列举几例：数据项如：员工号（编号：1 ，数据项名称：员工号，说明部分：整数类型，有唯一

7、性）数据结构如：员工信息 （编号：1 ， 数据结构名：员工信息，属性：包括员工号、姓名、性别、年龄、工龄、级别、部门、职务、备注）数据流如：员工基本信息（编号：1 ，数据流名：员工基本信息，输入：招新员工，输出：员工信息）数据存储如：员工信息（数据存储名：员工信息，输入数据流：员工基本信息，输出数据流：工资结算）处理过程如：招新员工（处理过程名：招新员工，输入数据流：终端，输出数据流：员工基本信息）数据库概念结构设计数据库概念结构设计常用方法有自底向上和自顶向下两种。该文采纳自底向上的设计方法，即首先定义各局部应用的概念结构，然后将它们集成，得到全局概念结构。局部概念结构设计下面以财务治理子系

8、统为例，分析子系统的功能，设计局部概念结构，并且对该局部概念结构进行合理优化调整。图 2 财务治理子系统E-R 图财务治理子系统的功能为：首先对各部门上交的收支情况进行汇总， 得出各部门的收益情况；然后在此基础上进行整体汇总，得到整个酒店的收益信息；最后将酒店的收益情况下发给各个部门，公开账目。根据该分析，得到描述财务治理子系统概念结构的 E-R 模型如图2 所示。E-R 模型调整的准则：（ 1 ） 现实世界中的事物能作为属性对待的尽量作为属性对待；（ 2） 属性中不具有需要描述的信息，即属性是不可分的数据项，不再包含其他信息。根据原则分析，员工应对应一个领导关系，但为了简便起见，就用员工的“

9、等级”属性来表达员工之间的领导关系。数据视图集成完成各子系统的分E-R 图设计及优化之后，接下来需要将所有的分 E-R 图综合集成为一个总的E-R 图。由于本系统中各分E-R 图的规模较小，所以合成过程采纳了一次集成方式。整个过程分两步进行：第一步： 合并。 将各分 E-R 图合并生成初步 E-R 图，解决各分E-R 图间可能存在的属性冲突、命名冲突或结构冲突。第二步：修改和重构。消除不必要的冗余，生成基本E-R 图。由于本系统涵盖的内容比较少，基本不存在冗余的现象，所以初步E-R 图就是基本E-R 图，不必再进行调整。数据库逻辑结构设计生成关系模式根据 E-R 图向关系模式的映射法则，可以将

10、 2.2 中得到的系统总体 E-R 图转换为一组关系模式。转换过程简单描述如下：一个实体直接转换为一个关系模式，如：员工（员工号,姓名,性别,年龄,工龄,级别,部门号,职务,备注）；工资（员工号,等级,实际工资,基本工资,出勤工资）；实体与实体之间的一对一联系或一对多联系可以直接合并到实体所对应的关系模式中，而实体之间的多对多联系则必须转换为一个单独的关系模式。根据这两条原则，对系统总体E-R图中的所有联系进行转换。工资和员工之间的1 ： 1 联系与员工实体所对应的关系模式合并；员工和部门之间的n ： 1 联系与员工实体所对应的关系模式合并；客房和订单之间n : m 的预约联系转化为：预约（订

11、单号客房号 ,始定时间,结束时间）； 顾客和房间之间n : m 的住宿联系转化为：住宿（顾客号,房间号码,住宿时间）关系模式优化将 E-R 模型转换为关系模式后，还应该根据关系规范化理论对所有关系模式进行优化，以得到更为科学合理的关系模式。一般而言，在函数依赖的范畴之内，关系模式达到3NF 或 BCNF层次即可。下面对3.1 中的关系模式进行分析：（ 1 ） 在顾客关系模式 “顾客（顾客编号、级别、 姓名、 年龄、性别、证件号码、证件名称、所选项目、使用时间、备注）”中，因为“使用时间”对于顾客的必要性不强， 且该属性在别的关系中可以查询得到，所以将 “使用时间”属性删除。分析可得， “顾客”

12、关系模式属于 BCNF 。（ 2 ）在总账关系模式“总账（总账编号、部门号、财务状况编号、 收入、 支出、 净利、 日期、 经手人号、备注）” 中， “净利”属性可以根据收入和支出计算得到，并且不需要经常性的查询，所以将该属性删除。该关系模式也属于BCNF 。（ 3 ）在财务状况关系模式“财务状况（财务状况编号、时期、总收入、总支出、净利润） ”中，虽然“净利润”也可以通过计算得到，但由于在这一项上查询比较频繁，如果每次查询都计算，必定使得系统性能降低，故保留下来。（ 4 ）在员工关系模式“员工（员工号、姓名、性别、年龄、工龄、级别、部门号、职务、备注）”中，用户查询时，一般只需查询自己所属单

13、位的员工信息，故可将其按部门水平分解为三个模式，以提高查询效率。负责人员（员工号、姓名、性别、年龄、工龄、级别、部门 TOC o 1-5 h z 号、职务、备注）；服务人员（员工号、姓名、性别、年龄、工龄、级别、部门号、职务、备注）；经手人员（员工号、姓名、性别、年龄、工龄、级别、部门号、职务、备注）；用户子模式设计得到优化后的总体逻辑结构后，还应该根据局部应用需求，结合具体的DBMS 特点，设计用户的子模式。设计过程如下：（ 1 ）因为经理对于员工的次要信息不会经常关注，因此将员工信息中最主要的内容映射过来，在经理子系统上设立员工关系子模式。员工（员工号、姓名、级别、部门号、职务、部门经理、

14、实际工资）；（ 2 ）因为酒店员工经常使用的只有客房的主要信息，所以在住宿子系统上设立客房关系子模式。客房 （客房号、位置、 设备、 收费标准、治理人员号、状态） ；（ 3 ）因为酒店治理人员对于顾客的情况治理经常使用的只有部分信息，所以在经营治理子系统上设立顾客关系子模式。顾客 （顾客编号、住宿号、 姓名、 级别、 应收款、 使用时间、备注）物理结构设计存储结构设计通过对典型酒店中的信息处理需求进行分析，可以得到如下需求特点：饮食、 住宿、 娱乐三大部门的数据不仅经常需要查询，而且更新速度快；各个部门信息要求共享的较多，如员工信息、来客信息等，但财务信息一般不共享；经理部门有一定的特别职能，

15、如汇总财务信息、级联删除辞退员工等。针对这些特点，设计如下：首先要确定数据库的存放位置。为了提高系统性能，根据应用情况将数据按照易变部分和稳定部分、经常存取部分和存取频率较低的部分分别在两个磁盘上存放。经常存取部分包括员工、工资、客房、款项、折扣规则、项目、顾客等；而信息存取频率较低的部分包括部门、账单、订单、总账、财务状况等。同时考虑到本系统是多用户的，为了提高效率，数据库的备份的数据和日志文件将保存在磁带中。然后要确定系统配置。酒店治理系统需要的微机数量和规模都不必太大，但在系统设计时应考虑到酒店的进展需求，在选择硬件设备、服务器操作系统、数据库时都考虑到能够逐步扩展。本酒店治理系统选用了

16、Windows XP 操作系统，后台数据库选用目前应用最多的ORCLE 10g 。由于涉及到酒店的财务治理，数据的完整性和安全性显得尤其重要，为了保障系统安全稳定运行， 需要每天进行数据备份。数据备份需要严格按照制定的备份与故障恢复策略进行，并落实备份登记和检查措施。存取路径设计首先确定数据的存取方式。对饮食、住宿、娱乐三个子系统的各个关系最经常的操作是查找，假设现有n 个住宿房间的信息，如果采取顺序查找，平均查找n/2 次；建立B+ 树索引，则平均查找次数为B+ 树的层数log2n+1 ，所以选择B+ 树作为索引，具体设计如下：（ 1 ）对经常在查询中出现的关系码建立索引。包括员工、工资、部门、客房、款项、折扣规则和财务状况等关系。（ 2 ）对经常需要进行连接操作