21点-21点规则【真.乐色】
全国咨询服务热线

400-0484791

当前位置:主页 > 团膳百科 > 常见问题 >

21点酒店管理系统数据库设计

发布日期:2020-10-09 23:34

  酒店管理系统数据库设计_互联网_IT/计算机_专业资料。东方学院 实 验(实训)报 告 项 目 名 称 酒店管理系统数据库分析与设计 所属课程名称 数据库原理及应用 项 目 类 型 设计、综合型 实验(实训)日期 2010.11.5—2010.12.15

  东方学院 实 验(实训)报 告 项 目 名 称 酒店管理系统数据库分析与设计 所属课程名称 数据库原理及应用 项 目 类 型 设计、综合型 实验(实训)日期 2010.11.5—2010.12.15 班级 学号 姓名 指导教师 信息 2 班 0820400209 ,0820400324 沈琪 赵芬芬 严素蓉 酒店管理系统数据库设计与分析 一. 需求分析 1.信息要求 目前大多数酒店提供的服务多种多样,规模大小也各不相同,但稍具规模的酒店必含下 面三类服务:饮食、住宿和娱乐。由于我们对酒店行业没有具体的接触和实质性的了解。此 次数据库设计只能在一些收集到的基本材料与个人直观认识的基础上,简单模仿中等规模的 酒店设计管理系统,并将其抽象成一个由三部门组成、实现三大服务的系统。因此对于这三 大部门的信息要求也是不同的。 (1)饮食部门 它是酒店基本部门之一。它提供服务的特点是实时性强、持续时间短,强调效率。例如, 顾客人数、顾客所用的菜及其它饮料等种类繁多,数量不等;后勤各种活动如采购等频繁发 生。通过分析可发现,用人工完成此类操作比计 算机更具实效与时效,且此类信息也没有 长时间保留的必要,因此这些信息没有必要采用数据库管理。对于饮食部门,需要较长时间 保留的信息主要是财务信息,一方面便于期末汇总,另一方面便于向上级报告。 在规模较大的酒店餐饮服务部分,餐厅可分成几个等级或几个小部门,然后各自形成小 系统,本系统为了简单起见,把饮食部门作为一个子系统,不再细分 (2)住宿管理部门 它也是酒店基本部门之一。住宿管理部门的主要职责有:A.给个房间布置各种设备、分 类、编号、制定收费标准、分配服务人员。B.登记旅客信息,确认其身份,登记其入住、退 房时间。C.统计各类房间的客满程度。D.对本部门的财务流动进行登记处理。以上信息处理 可以通过计算机完成,其他不便于计算机操作的在此没有列出。 (3)娱乐管理部门 娱乐是酒店非主流服务,它的存在除了赢利,更多的是为了吸引顾客食宿。娱乐部门的 特点与饮食部门很相似,不便于使用计算机进行操作。可以用计算机完成并且有必要用计算 机完成的有:A.制定收费标准,分配负责人.B.收入支出财务处理:编号、财务来源去处的 摘要、数量、单价、数额、结余、经手人等。这些信息都需要长时间保留并上报。 (4)经理部门 经理部门的功能虽然不是面向顾客、不是酒店的服务项之一,但它的存在却是必不可 少的。它的主要职责有:A.管理员工。给员工编号,登记其基本信息;根据员工的平时表现 及工龄确定工资;此外,还要给员工分配工作部门及职务等等。B.划分部门。给个部门编号、 命名、确定其职责范围、任命部门经理、分配员工。C.对本部门的财务进行核算(支付工资 等)。D.期末对酒店的收益情况进行核算。 2.处理要求 虽然酒店按功能可以划分成四个部门,但是饮食部门的大部分工作手工操作比计算机操 作更具有效率,电脑操作只有财务处理。在划分子系统时,考虑到各子系统都有各自的财务 处理,且有相似性,所以就把它们归为统一的一个“财务子系统”。同时“饮食子系统”取 消,因为它的所有需要涵盖的功能都已包含在“财务子系统”中。因此系统共划分为四部分: 总经理子系统、财务子系统、住宿子系统和娱乐子系统。 (1) 总经理子系统 a)对新来的员工进行编号、登记、分配工作。 {员工号、姓名、性别、年龄、工龄、级别、部门号、职务、其他备注} b) 对于被辞退的员工从系统中级联删除其信息,如从员工表中删除其基本信息,从它所服 务的工作部门中删除该员工的工作名额,结算支付其工资、奖金;同时补充新的员工,代替 它的工作。 c) 对新增部门作各种初始工作。如编号、命名、任命经理等。 {部门号、名称、部门经理、员工数量} d) 取消某个部门时,核算该部门的财务情况,并作备份;同时对该部门的员工重新分配工 作。 e) 其他情况的处理。 (2) 财务子系统 a)每天的收入、支出登记 {编号、发票号、摘要、数量、单位、数额、经手人、日期} b)期末各子系统的财务汇总 {编号、上月余额、总收入、总支出、余额、经手人、日期} c)期末酒店汇总个部门的财务报表,结算本酒店收益 (3) 住宿子系统 a)来客登记 若多人住同一房间,只作一个记录。 客人信息{房间号、房间类别、客人数量、联系人名、身份、证件名称(类型)、证件号码、 入住时间、退出时间} b)房间管理 旅客入住(旅客退出)除了登记(删除)客人信息之外,还应对相关的记录进行修改,如房 间的状态等。 房间类别{类别号、名称、设备、收费标准、总数量、剩余量、管理人员} 房间{房间号,房间类型、状态} ( 该部门的财务处理与饮食子系统同,归到财务子系统) (4) 娱乐子系统 a) 添加新的娱乐项目 娱乐项目{娱乐项目号、名称、收费标准、负责人} b) 取消某娱乐项目 3.安全性和完整性要求 安全性要求: 系统应设置访问用户标识以鉴别是否为合法用户,并要求合法用户设置其密码,保证用 户身份不被盗用; 系统应对不同的访问级别,限制访问用户可查询和处理数据的类别和内容; 系统应对不同用户设置不同的权限,区分不同的用户,如区分住客,房间管理员。 完整性要求: 各种信息记录的完整性,信息记录内容不为空; 各种数据间相互的来联系的正确性; 相同的数据在不同的记录中的一致性。 4.数据流图 (1) 总经理子系统 (2) 财务子系统 (3) 住宿子系统 (4) 娱乐子系统 数据字典 1. 数据项 数据项有待按各子系统分类列表。 编 数据项名 说 明 部 分 编 号称 号 1 员工号 整数类型;有唯一性 2 3 性别 枚举类型:男、女 4 5 工龄 整数类型 0…100 6 7 名称 文本类型 8 9 级别号 整数类型 10 11 工资 整数类型 12 13 负责人 参照“员工号“ 14 15 员工数量 整数类型 16 17 设备 19 总数量 21 房间号 文本 说明设备情况 18 某一等级的房间的数量 20 数字串类型 有唯一性 22 23 客人数量 25 证件类型 27 入住时间 29 编号 31 摘要 33 单价 35 日期 某一房间所住的人数 24 文本类型 26 格式:**/** 28 在各系统有不同意义, 30 唯一 收入支出来源去向的摘 32 要 不同的系统有不同的单 34 位 格式:**/** 数据项名 称 姓名 年龄 部门号 职务 级别名 部门经理 经手人 房间类型 收费标准 剩余量 状态 身份 证件号码 退出时间 发票号 说 明部分 文本类型 长度为 10 字符 整数类型 18…100 数字串类型;有唯一性 枚举类型;根据公司的制定 而定 文本 参照“员工号“ 参照“员工号“ 枚举类型如单人、双人标准 间等 不同的实体有不同的单位 某一等级房的尚可用数 该房是否已被入住 枚举类 型 登记旅客的目前住址 整数类型 格式:**/** 按固定格式输入 数量 整数类型 备注 文本类型 2. 数据结构 编号 数据结构名 1 员工信息 2 部门 3 酒店财务总汇 4 部门营业情况 5 房间类别 6 房间 7 客人信息 8 娱乐项目 属性 员工号、姓名、性别、年龄、工龄、级别、部门、职务、备注 部门号、名称、部门经理、员工数量 编号、部门号、名称、收入、支出、净利、日期、经手人、备注 编号、发票号、摘要、单价、数量、数额、日期、经手人、备注 类别号、名称、设备、收费标准、总数量、剩余量、管理人员 房间号、房间类别、状态 房间号、客人数量、联系人名、身份、证件类型、证件号码、入 住时间、退出时间、备注 编号、名称、收费标准、负责人 3. 数据流 编号 数 据 流 名 输入 1 员工基本信息 招新员工 输出 员工信息 2 工资结算 员工信息 3 当前员工工作 员工信息 4 员工新工作 调配工作 5 “辞工”信息 辞老员工 6 部门基本信息 部门信息 7 更新后的部门信息 调配工作 8 新部门基本信息 新增部门 9 老部门信息 取消老部门 10 顾客基本信息 来客登记 11 顾客需求 住房登记 12 满足顾客要求 调配住房 13 顾客住房信息 顾客信息 14 目前住房信息 住房信息 15 更新后的住房信息 调配住房 16 住房单价 住房信息 17 住房数量 调配住房 18 新娱乐项目信息 添加新项目 19 老娱乐项目信息 取消老项目 20 数额 娱乐管理部门收入 21 项目单价 娱乐项目信息 22 支出情况 子部门支出 23 收入情况 子部门收入 24 部门营业情况 子部门财务信息 总经理处财务支出 调配工作 员工信息 调配工作 调配工作 部门信息 调配工作 调配工作 顾客信息 调配住房 顾客信息 调配住房 调配住房 住房信息 住宿管理部门收入 住宿管理部门收入 娱乐项目信息 娱乐项目信息 娱乐管理部门信息 娱乐管理部门收入 子部门财务信息 子部门财务信息 酒店财务总汇信息 4. 数据存储 数据存储名 员工信息 部门信息 经理处财务信息 顾客信息 住房信息 娱乐项目信息 子部门财务信息 酒店财务总汇信息 输入数据流 员工基本信息 员工新工作 更新后的部门信息 经理处财务支出 经理处财务收入 顾客基本信息 满足顾客要求 更新后的住房信息 新娱乐项目信息 老娱乐项目信息 收入情况 支出情况 部门营业情况 输出数据流 工资结算 当前员工工作 当前部门信息 部门营业情况 目前的住房信息 住房单价 娱乐项目单价 部门营业情况 5. 处理过程 说明部分 处理过程名 招新员工 辞老员工 调配工作 增新部门 取消部门 来客登记 顾客离开 调配住房 住宿管理部门收入 添加新项目 取消老项目 娱乐管理部门 部门收入 部门支出 输入数据流 终端 终端 当前员工工作 员工基本信息 当前部门基本信息 终端 终端 终端 顾客需求 注销住房 目前住房信息 住房数量 住房单价 终端 终端 娱乐项目单价 终端 终端 输出数据流 员工基本信息 员工基本信息 员工新工作 更新后的部门信息 部门基本信息 部门基本信息 部门营业结算 顾客基本信息 顾客需求 终端 注销住房 更新后的住房信息 住房数量 满足顾客要求 新项目信息 老项目信息 收入情况 支出情况 说明部分 二. 概念结构设计 本公司开发酒店管理系统,经过可行性分析、详细调查以及多次讨论,确定了该系统由娱 乐管理部门、经理管理部门、宿舍管理部门和财务管理部门四个子系统组成。 本过程结构设计过程采用自底向上的设计方法,即首先定义各局部应用的概念结构,然 后将它们集成起来,得到全局概念结构. 下面给出各个子系统的分析及分 E-R 图的设计及对其进行的各项调整。 经理管理部门子系统 子系统的功能: A.管理员工:给员工编号,登记其基本信息。根据员工的平时表现确定其出勤工资及根据等 级确定其固定工资,从而确定其实际工资,此外还要给员工分配工作部门等。 B.划分部门:给各部门编号、命名、确定其职责范围、任命部门经理、分配员工。 C.对本部门的财务进行核算(支付工资等)。 根据要求分析给出的数据流图,参照数据字典中的详细描述,给出经理管理部门 的分 E-R 图: 员工 1 对应 1 工资 n 组成 1 部门 1 核算 n 账单 对 E-R 图调整的准则: 现实世界中的事物能作为属性对待的尽量作为属性对待; 属性和实体的划分:属性中不具有需要描述的信息,即属性是不可分的数据项,不再包 含其他信息。 实体属性定义: 员工(员工号、姓名、性别、年龄、工龄、级别、部门、职务、备注) 工资(员工号、等级、实际工资、基本工资、出勤工资) 部门(部门号、名称、部门经理、员工数量) 账单(编号、发票号、摘要、收入数、支出数、日期、经手人、备注) 具体调整如下: 1.本来员工还应对应一个领导关系,但这里为了简便,就用员工的”等级”属性来表示员工 之间的领导关系; 2.工资本应作为员工的一个属性,但这里需强调员工对应的出勤工资(由出勤情况决定), 因此将它单独作为一个实体; 3.部门对应的账单本应属于财务子系统的内容,这里为了简化财务子系统,先在各个子系 统中进行财务总结,因此,将账单也作为一个实体。 娱乐管理部门子系统 子系统的功能: A.为各个项目制定收费标准,分配负责人; B.收入支出财务处理:编号、财务来源去处的摘要、数量、单价、数额、结余、经手人 等信息; C.对在部门内进行娱乐的顾客进行收费,并根据折扣规则给与顾客相应的折扣; D.对部门内部进行帐务处理; 根据要求分析给出的数据流图,参照数据字典中的详细描述,给出经理管理部门的分 E-R 图: 项目 1 1 n 负责 核算 n 员工 1 账单 折扣规则 n 选 择m 顾客 1 对 应付 1 款项 1 应 实体属性定义: 项目(编号、名称、所在位置、收费标准、负责人) 员工(员工号、姓名、性别、年龄、工龄、级别、部门、职务、备注) 顾客(顾客号、级别、姓名、年龄、性别、证件号码、证件名称、所选项目、使用时间、备 注) 款项(顾客号、级别、使用时间、应收款、实际收款、折扣) 折扣规则(级别、折扣情况) 账单(编号、发票号、摘要、收入数、支出数、日期、经手人、备注) 对 E-R 图调整的准则: 现实世界中的事物能作为属性对待的尽量作为属性对待; 属性和实体的划分:属性中不具有需要描述的信息,即属性是不可分的数据项,不再包含其 他信息。 具体调整如下: 1.本来员工还应对应一个领导关系,但这里为了简便,就用员工的“等级”属性来表示员工 之间的领导关系; 2.款项本可以作为顾客的一个属性来设置,但这里为了强调对顾客的折扣情况,需要对款 项进行进一步的描述,因此这里作为一个实体; 3.对顾客所采取的折扣规则,本应该根据顾客的实际消费量来划定,这里为了方便起见, 给每位顾客添加了一个“级别”属性,用以对应采取的折扣规则; 4.部门对应的账单本应属于财务子系统的内容,这里为了简化财务子系统,先在各个子系 统中进行财务总结,因此,将账单也作为一个实体; 住宿管理部门子系统 子系统的功能: A.给个房间布置设备、分类、编号、制定收费标准、分配服务人员。 B.登记旅客信息,确认其身份,登记其入住、退出时间; C.接受顾客的预定服务,对于已预定的客房进行登记的处理; D.统计各类房间的客满程度; E.对本部门的财务流动进行登记处理。 根据需求分析给出的数据流图,参照数据字典中的详细描述,给出经理管理部门的分 E-R 图: 顾客 m 住宿 11 预 应 订 付 n 客房 m 1 m 核 预 算 约 负责 n 员工 1 账单 1 1 订单 1 款项 1 对应 1 折扣规则 实体属性定义: 顾客(顾客号、级别、姓名、年龄、性别、证件类型、证件号码、入住时间、退出时间、备 注) 客房(客房号、类别、位置、设备、收费标准、管理人员、状态) 员工(员工号、姓名、性别、年龄、工龄、级别、部门、备注) 款项(顾客号、级别、使用时间、应收款、实际收款、折扣) 折扣规则(级别、折扣情况) 订单(订单号、时间、房间号、经手人、备注) 账单(编号、发票号、摘要、收入数、支出数、日期、经手人、备注) 对 E-R 图调整的准则: 现实世界中的事物能作为属性对待的尽量作为属性对待; 属性和实体的划分:属性中不具有需要描述的信息,即属性是不可分的数据项,不再包含其 他信息。 具体调整如下: 1.本来员工还应对应一个领导关系,但这里为了简便,就用员工的“等级”属性来表示员工 之间的领导关系; 2.款项本可以作为顾客的一个属性来设置,但这里为了强调对顾客的折扣情况,需要对款 项进行进一步的描述,因此这里作为一个实体; 3.对顾客所采取的折扣规则,本应该根据顾客的实际消费量来划定,21点这里为了方便起见, 给每位顾客添加了一个“级别”属性,用以对应应采取的折扣规则; 4.部门对应的账单本应属于财务子系统的内容,这里为了简化财务子系统,先在各个子系 统中进行财务总结,因此,将账单也作为一个实体。 财务管理子系统 子系统的功能: 对各个部门上交上来的收支情况进行汇总,得出各个部门的损益情况; 对整个酒店各个部门的损益情况进行汇总登记,得出本期酒店的损益; 将整个酒店的收益情况下发给各个部门,帐务公开,集思广益。 分 E-R 图如下: 部门 1 1n 核 算 组成 下 发 n 员工 1 财务状况 1 m 账单 m m 汇总 结算 1 总帐 实体属性定义: 部门(部门号、名称、部门经理、员工数量) 员工(员工号、姓名、性别、年龄、工龄、级别、部门、职务、备注) 账单(编号、发票号、摘要、收入数、支出数、日期、经手人、备注) 总帐(编号、部门号、收入、支出、净利、日期、经手人、备注) 财务状况(时期、总收入、总支出、净利润) 对 E-R 图调整的准则: 现实世界中的事物能作为属性对待的尽量作为属性对待; 属性和实体的划分:属性中不具有需要描述的信息,即属性是不可分的数据项,不再包含其 他信息。 具体调整如下: 员工应对应一个领导关系,但为了简便起见,就用员工的“等级”属性来表示员工之间的领导 关系。 视图集成 以上便是四个子系统的分 E-R 图设计及其调整的整个过程,接着要做的就是将所有的分 E-R 图进行综合,合成一个系统的总 E-R 图. 由于本系统比较简单,分 E-R 图规模也比较小,所以 E-R 图合成过程采用一次将四个子系统分 E-R 图集成总 E-R 图的方式. 分两步进行: 第一步:合并。 解决各分 E-R 图之间的冲突,将各分 E-R 图合并起来生成初步 E-R 图。 各分 E-R 图之间的冲突主要有三类: 属性冲突: (1)属性域冲突,即属性值的类型、取值范围或取值集合不同。由于本系统较简单,所以 并不存在这种冲突; (2)属性取值单位冲突。由于本系统较简单,不存在这类冲突; 命名冲突: 同名异义:由于本系统较简单,所以不存在这类冲突; 异名同义:由于本系统较小,所以不存在这类冲突; 结构冲突: 同一对象在不同应用中具有不同的抽象:本系统在需求分析阶段原本存在这种冲突,考虑到 后期的简化合并,我们在设计各个分 E-R 图就早先解决了这个问题,即将在任何一个分 E-R 图中作为实体出现的属性全部作为实体; 同一实体在不同分 E-R 图中所包含的属性个数和属性排列次序不完全相同:由于本系统较简 单,所以并不存在这种冲突; 第二步:修改和重构。 消除不必要的冗余,生成基本 E-R 图。 由于本系统涵盖的内容比较少,基本不存在冗余的现象,所以初步 E-R 图就是基本 E-R 图, 不必再进行调整。下面给出 E-R 图。 总 E-R 图: 员工(员工号、姓名、性别、年龄、工龄、级别、部门号、职务、备注); 工资(员工号、等级、实际工资、基本工资、出勤工资); 部门(部门号、名称、部门经理、员工数量、财务状况编号); 项目(项目编号、部门号码、名称、所在位置、收费标准、负责人号); 顾客(顾客编号、级别、姓名、年龄、性别、证件号码、证件名称、所选项目、使用时间、 备注); 客房(客房号、类别、部门号、位置、设备、收费标准、管理人员号、状态); 款项(款项编号、顾客号、项目号、折扣级别、使用时间、应收款、实际收款); 折扣规则(折扣级别、折扣情况); 订单(订单号、顾客号、经手人号、备注); 账单(账单编号、总帐编号、发票号、收入数、支出数、日期、经手人号、备注); 总帐(总帐编号、部门号、财务状况编号、收入、支出、净利、日期、经手人号、备注); 财务状况(财务状况编号、时期、总收入、总支出、净利润); 三. 逻辑结构设计 一.与总 E-R 图对应的关系模式 1、实体所对应的关系模式: 员工(员工号、姓名、性别、年龄、工龄、级别、部门号、职务、备注); 工资(员工号、等级、实际工资、基本工资、出勤工资); 部门(部门号、名称、部门经理、员工数量、财务状况编号); 项目(项目编号、部门号码、名称、所在位置、收费标准、负责人号); 顾客(顾客编号、级别、姓名、年龄、性别、证件号码、证件名称、所选项目、使用时间、 备注); 客房(客房号、类别、部门号、位置、设备、收费标准、管理人员号、状态); 款项(款项编号、顾客号、项目号、折扣级别、使用时间、应收款、实际收款); 折扣规则(折扣级别、折扣情况); 订单(订单号、顾客号、经手人号、备注); 账单(账单编号、总帐编号、发票号、摘要、收入数、支出数、日期、经手人号、备注); 总帐(总帐编号、部门号、财务状况编号、收入、支出、净利、日期、经手人号、备注); 财务状况(财务状况编号、时期、总收入、总支出、净利润); 说明:1.下加横线.以上关系的详细内容说明请参照概念结构设计中的具体内容 3.上面的各个关系对概念结构设计中的相关内容了作了修改,主要加了各个实体中间 工资 1 对 应 1 员工 n 负 责 财务状况 1 汇 总 1 部门 1 1 结算 m n 1 总账 帐单 n 核算 下 属 下 属 1 n 项目 n m 选择 m 客房 m 住宿 n n 顾客 1 1 预 预 约 订 m 订单 1 折扣规则 1 对 应 1 款项 应付 1 的联系,尤其是一对多的联系,纳为属性。 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 部门(部门号、名称、部门经理、员工数量、财务状况编号);BCNF 项目(项目编号、部门号码、名称、所在位置、收费标准、负责人号);BCNF 顾客(顾客编号、级别、姓名、年龄、性别、证件号码、证件名称、所选项目、备注);BCNF 优化说明:删除了使用时间,一是因为“使用时间”对于顾客的属性必要性不强,二是因为 使用时间在别的关系中也可以查询到。 客房(客房号、类别、部门号、位置、设备、收费标准、管理人员号、状态);BCNF 款项(款项编号、顾客号、项目号、折扣级别、使用时间、应收款、实际收款);BCNF 折扣规则(折扣级别、折扣情况);BCNF 订单(订单号、顾客号、经手人号、备注);BCNF 账单(账单编号、总帐编号、发票号、摘要、收入数、支出数、日期、经手人号、备注); BCNF 总帐(总帐编号、部门号、财务状况编号、收入、支出、日期、经手人号、备注);BCNF 优化说明:删除了净利, 这一项可以根据收入、支出可以计算,而且并不经常对它进行查询。 财务状况(财务状况编号、时期、总收入、总支出、净利润);1NF 优化说明:净利润没有删除, 因为在这一项上查询比较频繁, 如果每次查询都计算, 必然使 系统计算增加,性能降低。保留下来虽然造成了一定的冗余, 但提高了查询的效率,利大于 弊。 预约(订单号、客房号、始定时间、结束时间);3NF 住宿(顾客号、房间号码、住宿时间);3NF 选择(顾客号、项目号、发生时间、经受人号、备注);3NF 2、 对关系模式进行必要的分解: 因公司内人员进行查询时,一般只用到自己所属单位的信息,故可把“人员”关系按 部门进行水平分解,以提高查询效率。 水平分解:员工(员工号、姓名、性别、年龄、工龄、级别、部门号、职务、备注) 改为:负责人员(员工号才、姓名、性别、年龄、工龄、级别、部门号、职务、备注); 服务人员(员工号、姓名、性别、年龄、工龄、级别、部门号、职务、备注); 经手人员(员工号、姓名、性别、年龄、工龄、级别、部门号、职务、备注); 三、用户子模式设计 1.经理子系统用户子模式 员工(员工号、姓名、级别、部门号、职务、部门经理、实际工资); 因为经理对于员工其他情况不会经常关注,经常使用的只有以上各项,所以在经理子系 统上设立员工关系。 2.住宿子系统用户子模式 客房(客房号、位置、设备、收费标准、管理人员号、状态); 因为管理员工对于客房的其他情况不会经常使用,经常使用的只有以上各项,所以在住宿子 系统上设立客房关系 3.经营管理子系统用户子模式 顾客(顾客编号、住宿号、姓名、级别、应收款、使用时间、备注) 因为对于顾客的情况管理经常使用是以上各项,所以在经营管理子系统上设立顾客关系。 四. 物理结构设计 一. 存储结构设计 经过分析可知,本酒店管理系统中信息处理的特点如下: (1)饮食、住宿、娱乐三大部门的数据不仅经常需要查询,而且更新速度快,例如住宿部门 的来客查询与登记,房间的动态分配等。 (2)各个部门信息要求共享的信息较多。例如员工信息,来客信息等。但财务信息一般不 共享。 (3)经理部门有一定的特殊职能:汇总财务信息;对于被辞退的员工从系统中级联删除其 信息、如从员工表中删除其基本信息、从它所服务的工作部门中删除该员工的工作名额,结 算支付其工资、奖金;同时补充新的员工,代替它的工作。 针对这些特点,设计如下: 1. 确定数据库的存放位置 为了提高系统性能,现根据应用情况将数据按照易变部分和稳定部分、经常存取部分 和存取频率较低的部分分别在两个磁盘上存放。同时,考虑到本系统是多用户的,为了提 高效率,数据库的备份的数据和日志文件将保存在磁带中。 经常存取部分: 员工(员工号、姓名、性别、年龄、工龄、级别、部门号、职务、备注); 工资(员工号、等级、实际工资、基本工资、出勤工资); 客房(客房号、类别、部门号、位置、设备、收费标准、管理人员号、状态); 款项(款项编号、顾客号、项目号、折扣级别、使用时间、应收款、实际收款); 折扣规则(折扣级别、折扣情况); 项目(项目编号、部门号码、名称、所在位置、收费标准、负责人号); 顾客(顾客编号、级别、姓名、年龄、性别、证件号码、证件名称、所选项 目、备注); 存取频率较低的部分: 部门(部门号、名称、部门经理、员工数量、财务状况编号); 账单(账单编号、总帐编号、发票号、摘要、收入数、支出数、日期、经手人号、备注); 订单(订单号、顾客号、经手人号、备注); 总帐(总帐编号、部门号、财务状况编号、收入、支出、日期、经手人号、备注); 财务状况(财务状况编号、时期、总收入、总支出、净利润); 2. 确定系统配置 酒店管理系统需要的微机数量和规模都不必太大,但在系统设计时应考虑到酒店的发展 需求,在选择硬件设备、服务器操作系统、数据库时都考虑到能够逐步的增加和扩展。 本酒店管理系统选用了 Windows9x 系统作为微机的操作系统,它能够有较好的使用界面 并能够充分发挥出微机硬件的作用,比较适合酒店这样的机构;另外,选用了目前应用最多 的 ORACLE 数据库。 由于涉及到酒店的财务管理,数据的完整性和安全性显得尤其重要。系统中的数据一旦 丢失,将需要很长时间进行恢复,有时甚至使信息系统不得不从系统初始化阶段重新开始运 行。每天进行数据备份是保障系统安全的重要手段。数据备份需要严格按照事先制定的备份 与故障恢复策略进行,并落实备份登记和检查措施。 具体的系统配置应当根据系统实际运行情况做进一步的调整。 二. 存取路径设计 1. 存取方式的分析: 对饮食、住宿、娱乐三个子系统的各个关系最经常的操作是查找,假设现有 n 个住宿 房间的信息,如果采取顺序查找,平均查找 n/2 次;建立 B+树索引,则平均查找次数为 B+ 树的层数 log2n+1。 所以选择 B+树作为索引,具体设计如下: 对以下经常在查询中出现的关系的码建立索引说明:下加横线部分表示关系的码 员工(员工号、姓名、性别、年龄、工龄、级别、部门号、职务、备注); 工资(员工号、等级、实际工资、基本工资、出勤工资); 部门(部门号、名称、部门经理、员工数量、财务状况编号); 客房(客房号、类别、部门号、位置、设备、收费标准、管理人员号、状态); 款项(款项编号、顾客号、项目号、折扣级别、使用时间、应收款、实际收款); 折扣规则(折扣级别、折扣情况); 财务状况(财务状况编号、时期、总收入、总支出、净利润); 以下经常进行连接操作的关系的码建立索引: 员工号、客房号、部门号等 由于下面几个关系模式的更新频率很高,所以没有定义索引: 顾客(顾客编号、级别、姓名、年龄、性别、证件号码、证件名称、所选项目、备注); 订单(订单号、顾客号、经手人号、备注); 账单(账单编号、总帐编号、发票号、摘要、收入数、支出数、日期、经手人号、备注); 五. 数据库实施 create database hotel /*建立 hotel 数据库*/ use hotel create table 员工 ( 员工号 int unique, 姓名 char(10), 性别 char(2) check(性别 in(男,女)), 年龄 int check(年龄=18 and 年龄=100), 工龄 int check(工龄=0 and 工龄=100), 级别 char(10), 部门号 int, 职务 char(10), 备注 char(40), primary key(员工号) ) create table 工资 ( 员工号 int unique, 等级 int, 实际工资 int, 基本工资 int, 出勤工资 int, primary key (员工号), foreign key(员工号) references 员工(员工号) ) create table 部门 ( 部门号 int unique, 名称 char(10), 部门经理 int, 员工数量 int, 财务状况编号 int , primary key(部门号), foreign key(部门经理) references 员工(员工号), foreign key(财务状况编号) references 财务状况(财务状况编号) ) create table 项目 ( 项目编号 int unique, 部门号码 int, 名称 char(20), 所在位置 char(20), 收费标准 int, 负责人号 int, primary key(项目编号), foreign key(部门号码) references 部门(部门号), foreign key(负责人号) references 员工(员工号) ) create table 顾客 ( 顾客编号 int unique, 级别 int, 姓名 char(20), 年龄 int check(年龄=18 and 年龄=100), 性别 char(2) check(性别 in(男,女)), 证件号码 int unique, 证件名称 char(10), 所选项目 int, 备注 char(40), primary key(顾客编号), foreign key(所选项目) references 项目(项目编号) ) create table 客房 ( 客房号 int unique, 类别 char(10) check(类别 in(单人间,双人间,标准间)), 部门号 int, 位置 char(20), 设备 char(40), 收费标准 int, 管理人员号 int, 状态 char(10) check(状态 in(以被入住,没被入住)), primary key(客房号), foreign key(部门号) references 部门(部门号), foreign key(管理人员号) references 员工(员工号) ) create table 款项 ( 款项编号 int unique, 顾客号 int, 项目号 int, 折扣级别 int, 使用时间 timestamp, 应收款 int, 实际收款 int, primary key(款项编号), foreign key(顾客号) references 顾客(顾客编号), foreign key(项目号) references 项目(项目编号), foreign key(折扣级别) references 折扣规则(折扣级别) ) create table 折扣规则 ( 折扣级别 int unique, 折扣情况 char(20), primary key(折扣级别) ) create table 订单 ( 订单号 int unique, 顾客号 int, 经手人号 int, 备注 char(40), primary key(订单号), foreign key(顾客号) references 顾客(顾客编号), foreign key(经手人号) references 员工(员工号) ) create table 账单 ( 账单编号 int unique, 总账编号 int, 发票号 int, 收入数 int, 支出数 int, 日期 int, 经手人号 int, 备注 char(40), primary key(账单编号), foreign key(经手人号) references 员工(员工号) ) create table 总账 ( 总账编号 int unique, 部门号 int, 财务状况编号 int, 收入 int, 支出 int, 日期 datetime, 经手人号 int, 备注 char(40), primary key(总账编号), foreign key(部门号) references 部门(部门号), foreign key(经手人号) references 员工(员工号) ) create table 财务状况 ( 财务状况编号 int unique, 总收入 int, 总支出 int, 净利润 int, 时期 int, primary key(财务状况编号) ) /*建立基本表*/ create table 预约 ( 订单号 int unique, 客房号 int unique, 始订时间 int, 结束时间 int, primary key(订单号,客房号), foreign key(订单号) references 订单(订单号), foreign key(客房号) references 客房(客房号) ) create table 住宿 ( 顾客号 int unique, 房间号码 int unique, 住宿时间 int, primary key(顾客号,房间号码), foreign key(顾客号) references 顾客(顾客编号), foreign key(房间号码) references 客房(客房号) ) create table 选择 ( 顾客号 int unique, 项目号 int unique, 发生时间 int, 经手人号 int, 备注 char(40) primary key(顾客号,项目号), foreign key(顾客号) references 顾客(顾客编号), foreign key(项目号) references 项目(项目编号), foreign key(经手人号) references 员工(员工号) ) create view 员工_经理 as select 员工.员工号,姓名,级别,部门.部门号,职务,部门经理,实际工资 from 员工,部门,工资 /*建立经理查询员工情况的视图*/ create view 客房_住宿 as select 客房号,位置,设备,收费标准,管理人员号,状态 from 客房 /*建立住宿客房查询视图*/ create view 顾客_管理 as select 顾客编号,客房号,姓名,级别,应收款,款项.使用时间,备注 from 顾客,客房,款项 /*建立经营管理顾客查询视图*/ create unique index 员工索引 on 员工(员工号); create unique index 工资索引 on 工资(员工号); create unique index 部门索引 on 部门(部门号); create unique index 客房索引 on 客房(客房号); create unique index 款项索引 on 款项(款项编号); create unique index 折扣索引 on 折扣规则(折扣级别); create unique index 财务索引 on 财务状况(财务状况编号); /*建立索引*/ 功能实现图: 酒店管理系统主界面 六. 数据库运行和维护 1. 维护数据库的安全性与完整性 按照设计阶段提供的安全规范和故障恢复规范,DBA 要经常检查系统的安全是否受到侵 犯,根据用户的实际需要授予用户不同的操作权限。 数据库在运行过程中,由于应用环境发生变化,对安全性的要求可能发生变化,DBA 要 根据实际情况及时调整相应的授权和密码,以保证数据库的安全性。 同样数据库的完整性约束条件也可能会随应用环境的改变而改变,这时 DBA 也要对其进 行调整,以满足用户的要求。 另外,为了确保系统在发生故障时,能够及时地进行恢复,DBA 要针对不同的应用要求 定制不同的转储计划,定期对数据库和日志文件进行备份,以使数据库在发生故障后恢复到 某种一致性状态,保证数据库的完整性 2. 监测并改善数据库性能 目前许多 DBMS 产品都提供了监测系统性能参数的工具,DBA 可以利用系统提供的这些 工具,经常对数据库的存储空间状况及响应时间进行分析评价;结合用户的反应情况确定改 进措施;及时改正运行中发现的错误;按用户的要求对数据库的现有功能进行适当的扩充。 但要注意在增加新功能时应保证原有功能和性能不受损害。 3. 重新构造和组织数据库 数据库建立后,除了数据本身是动态变化以外,随着应用环境的变化,数据库本身也必 须变化以适应应用要求。 数据库运行一段时间后,由于记录的不断增加、删除和修改,会改变数据库的物理存储 结构,使数据库的物理特性受到破坏,从而降低数据库存储空间的利用率和数据的存取效率, 使数据库的性能下降。因此,需要对数据库进行重新组织,即重新安排数据的存储位置,回 收垃圾,减少指针链,改进数据库的响应时间和空间利用率,提高系统性能。这与操作系统 对“磁盘碎片”的处理的概念相类似。 数据库的重组只是使数据库的物理存储结构发生变化,而数据库的逻辑结构不变,所以 根据数据库的三级模式,可以知道数据库重组对系统功能没有影响,只是为了提高系统的性 能。 数据库应用环境的变化可能导致数据库的逻辑结构发生变化,比如要增加新 的实体,增加某些实体的属性,这样实体之间的联系发生了变化,这样使原有的数据库设计 不能满足新的要求,必须对原来的数据库重新构造,适当调整数据库的模式和内模式,比如 要增加新的数据项,增加或删除索引,修改完整性约束条件等。 DBMS 一般都提供了重新组织和构造数据库的应用程序,以帮助 DBA 完成数据库的重组 和重构工作。 只要数据库系统在运行,就需要不断地进行修改、调整和维护。一旦应用变化太大,数 据库重新组织也无济于事,这就表明数据库应用系统的生命周期结束,应该建立新系统,重 新设计数据库。从头开始数据库设计工作,标志着一个新的数据库应用系统生命周期的开始。

Copyright©2015-201921点版权所有