内容发布更新时间 : 2025/5/1 14:07:23星期一 下面是文章的全部内容请认真阅读。
数据库原理及应用实验指导书
逻 辑 结 构 设 计
一.与总E-R图对应的关系模式
1、实体所对应的关系模式：
员工(员工号、姓名、性别、年龄、工龄、级别、部门号、职务、备注)； 工资(员工号、等级、实际工资、基本工资、出勤工资)； 部门(部门号、名称、部门经理、员工数量、财务状况编号)；
项目(项目编号、部门号码、名称、所在位置、收费标准、负责人号)；
顾客(顾客编号、级别、姓名、年龄、性别、证件号码、证件名称、所选项目、使用时间、备注)； 客房（客房号、类别、部门号、位置、设备、收费标准、管理人员号、状态）； 款项(款项编号、顾客号、项目号、折扣级别、使用时间、应收款、实际收款)； 折扣规则(折扣级别、折扣情况)；
订单(订单号、顾客号、经手人号、备注)；
账单（账单编号、总帐编号、发票号、摘要、收入数、支出数、日期、经手人号、备注）； 总帐(总帐编号、部门号、财务状况编号、收入、支出、净利、日期、经手人号、备注)； 财务状况（财务状况编号、时期、总收入、总支出、净利润）； 说明：1.下加横线部分表示关系的码
2.以上关系的详细内容说明请参照概念结构设计中的具体内容
3.上面的各个关系对概念结构设计中的相关内容了作了修改，主要加了各个实体中间的联系，尤其是一对多的联系，纳为属性。
2、联系所对应的关系模式：
1）、把客房和订单之间的n : m的预约联系转化为相应的关系模式如下： 预约（订单号、客房号、始定时间、结束时间）；
2）、把顾客和房间之间的n : m的住宿联系转化为相应的关系模式如下： 住宿（顾客号、房间号码、住宿时间）；
3）、把顾客和项目之间的n : m的选择联系转化为相应的关系模式如下： 选择（顾客号、项目号、发生时间、经受人号、备注）； 4）、其他联系处理说明如下：
工资和员工之间的1：1联系与员工关系合并； 顾客和订单之间的1：1联系与订单关系合并； 折扣规则和款项之间的1：1联系与款项关系合并； 员工和部门之间的n：1联系与员工关系合并； 部门和财务状况之间的n：1联系与部门关系合并； 客房和部门之间的n：1联系与客房关系合并； 项目和部门之间的n：1联系与项目关系合并； 总帐和财务状况之间的n：1联系与总帐关系合并； 帐单和总帐之间的n：1联系与帐单关系合并； 帐单和项目之间的n：1联系与项目关系合并；
二.优化后的数据模型
1、 按照数据依赖对关系模式进行逐一分析，并进行极小化处理：
员工(员工号、姓名、性别、年龄、工龄、级别、部门号、职务、备注)；BCNF 工资(员工号、等级、实际工资、基本工资、出勤工资)；BCNF
37
数据库原理及应用实验指导书
部门(部门号、名称、部门经理、员工数量、财务状况编号)；BCNF
项目(项目编号、部门号码、名称、所在位置、收费标准、负责人号)；BCNF
顾客(顾客编号、级别、姓名、年龄、性别、证件号码、证件名称、所选项目、备注)；BCNF
优化说明：删除了使用时间，一是因为“使用时间”对于顾客的属性必要性不强，二是因为使用时间在别
的关系中也可以查询到。
客房（客房号、类别、部门号、位置、设备、收费标准、管理人员号、状态）；BCNF 款项(款项编号、顾客号、项目号、折扣级别、使用时间、应收款、实际收款)；BCNF 折扣规则(折扣级别、折扣情况)；BCNF
订单(订单号、顾客号、经手人号、备注)；BCNF
账单（账单编号、总帐编号、发票号、摘要、收入数、支出数、日期、经手人号、备注）；BCNF 总帐(总帐编号、部门号、财务状况编号、收入、支出、日期、经手人号、备注)；BCNF
优化说明：删除了净利, 这一项可以根据收入、支出可以计算，而且并不经常对它进行查询。 财务状况（财务状况编号、时期、总收入、总支出、净利润）；1NF
优化说明：净利润没有删除, 因为在这一项上查询比较频繁, 如果每次查询都计算, 必然使系统计算增加，
性能降低。保留下来虽然造成了一定的冗余, 但提高了查询的效率，利大于弊。
预约（订单号、客房号、始定时间、结束时间）；3NF 住宿（顾客号、房间号码、住宿时间）；3NF
选择（顾客号、项目号、发生时间、经受人号、备注）；3NF
2、 对关系模式进行必要的分解：
因公司内人员进行查询时，一般只用到自己所属单位的信息，故可把“人员”关系按部门进行水平分解，以提
高查询效率。
水平分解：员工(员工号、姓名、性别、年龄、工龄、级别、部门号、职务、备注) 改为：负责人员(员工号、姓名、性别、年龄、工龄、级别、部门号、职务、备注)； 服务人员(员工号、姓名、性别、年龄、工龄、级别、部门号、职务、备注)； 经手人员(员工号、姓名、性别、年龄、工龄、级别、部门号、职务、备注)；
三、用户子模式设计
1．经理子系统用户子模式
员工(员工号、姓名、级别、部门号、职务、部门经理、实际工资)；
因为经理对于员工其他情况不会经常关注，经常使用的只有以上各项，所以在经理子系统上设立员工关系。
2．住宿子系统用户子模式
客房（客房号、位置、设备、收费标准、管理人员号、状态）；
因为管理员工对于客房的其他情况不会经常使用，经常使用的只有以上各项，所以在住宿子系统上设立客房关系
3．经营管理子系统用户子模式
顾客（顾客编号、住宿号、姓名、级别、应收款、使用时间、备注）
因为对于顾客的情况管理经常使用是以上各项，所以在经营管理子系统上设立顾客关系。
38
数据库原理及应用实验指导书
物 理 结 构 设 计
一. 存储结构设计
经过分析可知,本酒店管理系统中信息处理的特点如下：
（１）饮食、住宿、娱乐三大部门的数据不仅经常需要查询,而且更新速度快,例如住宿部门的来客查询与登记，房间的动态分配等。
（２）各个部门信息要求共享的信息较多。例如员工信息,来客信息等。但财务信息一般不共享。 （３）经理部门有一定的特殊职能：汇总财务信息；对于被辞退的员工从系统中级联删除其信息、如从员工表中删除其基本信息、从它所服务的工作部门中删除该员工的工作名额，结算支付其工资、奖金；同时补充新的员工，代替它的工作。
针对这些特点，设计如下:
1. 确定数据库的存放位置
为了提高系统性能，现根据应用情况将数据按照易变部分和稳定部分、经常存取部分和存取频率较低的部分分别在两个磁盘上存放。同时，考虑到本系统是多用户的，为了提高效率，数据库的备份的数据和日志文件将保存在磁带中。 ? 经常存取部分：
员工(员工号、姓名、性别、年龄、工龄、级别、部门号、职务、备注)； 工资(员工号、等级、实际工资、基本工资、出勤工资)；
客房（客房号、类别、部门号、位置、设备、收费标准、管理人员号、状态）； 款项(款项编号、顾客号、项目号、折扣级别、使用时间、应收款、实际收款)； 折扣规则(折扣级别、折扣情况)；
项目(项目编号、部门号码、名称、所在位置、收费标准、负责人号)；
顾客(顾客编号、级别、姓名、年龄、性别、证件号码、证件名称、所选项目、备注)；
? 存取频率较低的部分：
部门(部门号、名称、部门经理、员工数量、财务状况编号)；
账单（账单编号、总帐编号、发票号、摘要、收入数、支出数、日期、经手人号、备注）； 订单(订单号、顾客号、经手人号、备注)；
总帐(总帐编号、部门号、财务状况编号、收入、支出、日期、经手人号、备注)； 财务状况（财务状况编号、时期、总收入、总支出、净利润）；
2. 确定系统配置
酒店管理系统需要的微机数量和规模都不必太大，但在系统设计时应考虑到酒店的发展需求，在选择硬件设备、服务器操作系统、数据库时都考虑到能够逐步的增加和扩展。
本酒店管理系统选用了Windows9x系统作为微机的操作系统，它能够有较好的使用界面并能够充分发挥出微机硬件的作用，比较适合酒店这样的机构；另外，选用了目前应用最多的ORACLE 数据库。
由于涉及到酒店的财务管理，数据的完整性和安全性显得尤其重要。系统中的数据一旦丢失，将需要很长时间进行恢复，有时甚至使信息系统不得不从系统初始化阶段重新开始运行。每天进行数据备份是保障系统安全的重要手段。数据备份需要严格按照事先制定的备份与故障恢复策略进行，并落实备份登记和检查措施。
具体的系统配置应当根据系统实际运行情况做进一步的调整。
39
数据库原理及应用实验指导书
二. 存取路径设计
1. 存取方式的分析:
对饮食、住宿、娱乐三个子系统的各个关系最经常的操作是查找，假设现有n个住宿房间的信
息，如果采取顺序查找，平均查找n/2次；建立B+树索引，则平均查找次数为B+树的层数log2n+1。
所以选择B+树作为索引,具体设计如下：
? 对以下经常在查询中出现的关系的码建立索引<说明：下加横线部分表示关系的码>
员工(员工号、姓名、性别、年龄、工龄、级别、部门号、职务、备注)； 工资(员工号、等级、实际工资、基本工资、出勤工资)； 部门(部门号、名称、部门经理、员工数量、财务状况编号)；
客房（客房号、类别、部门号、位置、设备、收费标准、管理人员号、状态）； 款项(款项编号、顾客号、项目号、折扣级别、使用时间、应收款、实际收款)； 折扣规则(折扣级别、折扣情况)；
财务状况（财务状况编号、时期、总收入、总支出、净利润）；
? 以下经常进行连接操作的关系的码建立索引:
员工号、客房号、部门号等
? 由于下面几个关系模式的更新频率很高,所以没有定义索引:
顾客(顾客编号、级别、姓名、年龄、性别、证件号码、证件名称、所选项目、备注)； 订单(订单号、顾客号、经手人号、备注)；
账单（账单编号、总帐编号、发票号、摘要、收入数、支出数、日期、经手人号、备注）；
三. 设计评价及说明
上述设计对时间效率，空间效率，维护代价和用户的实际需求做出了较好的权衡，根据酒店管理的实际出发，以时间效率和用户的实际需求为根本，得出的最后方案。
40