泉州朝歌量贩式KTV管理信息系统数据库分析设计.docx
- 文档编号:24724273
- 上传时间:2023-05-31
- 格式:DOCX
- 页数:37
- 大小:801.46KB
泉州朝歌量贩式KTV管理信息系统数据库分析设计.docx
《泉州朝歌量贩式KTV管理信息系统数据库分析设计.docx》由会员分享,可在线阅读,更多相关《泉州朝歌量贩式KTV管理信息系统数据库分析设计.docx(37页珍藏版)》请在冰豆网上搜索。
泉州朝歌量贩式KTV管理信息系统数据库分析设计
组长:
李尚鸿
组员:
苏少梅杜鹏程
唐家进张翯琦
泉州朝歌量贩式KTV管理信息系统数据库分析设计
目录
一、背景说明4
二、总体目标4
三、系统主要功能4
3.1该系统主要包括以下功能:
4
3.2系统结构图5
四、E-R图6
4.1基本信息:
6
4.2基本业务:
6
4.3房间管理:
8
4.4房间维护:
8
五、ER图的集成与优化8
六、数据流程图11
6.1顶层数据流程图:
11
6.2第1层数据流程图:
11
6.3第2层数据流程图11
6.3.1第2层数据流程图:
从包间信息管理角度出发11
6.3.2第2层数据流程图:
从结账退房处理角度出发12
七、逻辑结构设计13
7.1与总E-R图对应的关系模式13
7.1.1实体所对应的关系模式:
13
7.1.2联系所对应的关系模式:
13
7.2优化后的数据模型13
7.2.1关系模式的调整(基于处理效率的考虑)13
7.2.2关系模式的规范化(达到3NF)14
7.2.3用户子模式设计15
八、物理结构设计15
8.1DBMS选型及系统配置的选择15
8.2索引的设置16
8.3安全性及用户权限设计16
8.4其他物理细节16
8.4.1存储结构设计16
8.4.2存取路径设计17
九、数据库实施阶段18
9.1数据库实施阶段目标18
9.2数据库实施阶段任务18
9.3建立视图21
9.4基于视图的数据查询22
9.5数据库关系图24
十、KTV系统界面24
十一、设计评价及说明27
一、背景说明
随着社会的发展和人民生活水平的提离,人们对精神文化生活的需求也在不断地增加。
KTV的出现和发展在一定程度上满足了人们的这种需求,所以KTV行业迅速崛起并且占据了重要的市场。
KTV源于日本,之前叫“卡拉OK”,刚传入中国时,主要以一种高档娱乐形式存在于“夜总会、歌舞厅”等一些高级消费场所。
近10余年来的飞速发展现在已遍布全国各地,据权威数据显示我国注册登记的各种KTV、迪厅、数量达20万家以上。
目前的大部分KTV娱乐场所已不单是作为一个娱乐行业的形式存在,它同时兼容了娱乐业和服务业的特点。
从(KTV)消费来看,以一个中等城市为例,KTV等娱乐场所就有二三百家,大的一晚接待顾客三四百人,少的也有几十人,仅此一项,就有数万人在消费,这个数字目前还在呈快速上升趋势,而经营较好的店每晚平均客流量在500—700人次之间,消费群体主要是学生和公司的白领阶层,日常上座率为50%—70%,到周末时最为火爆,上座率可达到100%。
正如《时代》杂志预言的那样:
新技术和其他一些趋势可以让人把生命中的50%的时间用于玩乐,KTV等娱乐场所消费也越来越趋向大众化,唱K的人将会越来越多。
随着全国各地不断涌现的KTV、酒吧、迪厅等娱乐场所,与之相对应的配套设备的需求量也越来越大。
为满足现代人追求更高的物质精神享受的需要,KTV场所设备不再像以前那样陈旧落后,设备追求个性新潮,设备更新换代快,基本上两年就更换一整套设备,由此可见,娱乐场所设备前景非常看好。
同时,在这个信息经济飞速发展的时代,计算机管理软件已经成为各个行生眨主要的管理工具。
所以结合这两点,我们设计了一款KVT数据库管理系统。
二、总体目标
通过计算机管理软件的管理,可以大大提离管理的效率、安全性和准确性。
当然,在KTV行业的日常管理中,它的管理人员也同样希望通过信息化的管理来提高工作效率、降低运营成本、规范经营模式,大大提升自身的服务档次,提升了企业的管理水平,从而增强企业的竞争力,达到管理的系统化、规范化和自动化。
三、系统主要功能
3.1该系统主要包括以下功能:
Ø用户登录:
实现用户的登录验证,并且根据用户的权限来判断功能按钮的显示与否。
Ø基本信息:
其中包括用户信息和会员信息,并对相应的信息进行添加、删除、修改等操作。
Ø基本业务:
包括开房和结账。
同时当用户选定某个房间时,通过鼠标右击就可以弹出相应的菜单,操作更加方便快捷。
Ø房间管理:
查看订单明细表来了解当前的预定信息,通过查看开放单明细表来了解正在处于开发状态的房间信息。
Ø房间维护:
通过查询维护单明细表来了解但前房间的维修及清扫信息。
Ø查询统计:
对顾客的信息及消费情况和KTV的收支情况进行查询及管理。
Ø
退出系统:
关闭所有界面,退出系统。
3.2系统结构图
四、E-R图
4.1基本信息:
实体属性定义:
客户(会员编号,客户姓名,地址,消费积分,备注)
用户(用户ID,用户名,密码)
用户类型(名称,类型编号)
4.2基本业务:
实体属性定义:
客户(客户编号,会员编号,客户姓名,地址,电话,性别,消费积分)
房间(房间编号,类型,价格)
账单(账单编号,消费金额,结账日期,结账金额)
物品(物品编号,物品名,单价,赔偿价格)
4.3房间管理:
实体属性定义:
客户(客户编号,会员编号,客户姓名,地址,电话,性别,消费积分)
订单(订单编号,预订日期,预期时间,备注)
房间(房间编号,房间类型,房间状态,价格)
4.4房间维护:
实体属性定义:
员工(工号,类别,姓名,电话,地址,性别,工作状态)
房间(房间编号,房间类型,房间状态,价格)
五、ER图的集成与优化
以上便是四个子模块的分E-R图设计过程,接着要做的就是将所有的分E-R图进行综合,合成一个模块的总E-R图.
由于本系统比较简单,分E-R图规模也比较小,所以E-R图合成过程采用一次将四个子模块分E-R图集成总E-R图的方式.
分两步进行:
5.1第一步:
合并。
解决各分E-R图之间的冲突,将各分E-R图合并起来生成初步E-R图。
各分E-R图之间的冲突主要有三类:
1.属性冲突:
(1)属性域冲突,即属性值的类型、取值范围或取值集合不同。
由于本系统较简单,所以并不存在这种冲突;
(2)属性取值单位冲突。
由于本系统较简单,不存在这类冲突;
2.命名冲突:
(1)同名异义:
由于本系统较简单,所以不存在这类冲突;
(2)异名同义:
由于本系统较小,所以不存在这类冲突;
3.结构冲突:
(1)同一对象在不同应用中具有不同的抽象:
本系统在需求分析阶段原本存在这种冲突,考虑到后期的简化合并,我们在设计各个分E-R图就早先解决了这个问题,即将在任何一个分E-R图中作为实体出现的属性全部作为实体;
(2)同一实体在不同分E-R图中所包含的属性个数和属性排列次序不完全相同:
由于本系统较简单,所以并不存在这种冲突;
5.2第二步:
修改和重构。
消除不必要的冗余,生成基本E-R图。
由于本系统涵盖的内容比较少,基本不存在冗余的现象,所以初步E-R图就是基本E-R图,不必再进行调整。
下面给出总E-R图。
实体属性定义:
客户(客户编号会员编号,客户姓名,地址,消费积分,性别,备注)
账单(账单编号,消费金额,结账日期,结账时间)
房间(房间编号,房间类型,房间状态,价格)
员工(工号,类别,姓名,性别,电话,地址,工作状态)
订单(订单编号,预订日期,预期时间,备注)
物品(物品编号,物品名,单价,赔偿价格)
六、数据流程图
6.1顶层数据流程图:
6.2第1层数据流程图:
6.3第2层数据流程图
6.3.1第2层数据流程图:
从包间信息管理角度出发
6.3.2第2层数据流程图:
从结账退房处理角度出发
七、逻辑结构设计
7.1与总E-R图对应的关系模式
7.1.1实体所对应的关系模式:
客户(客户编号,会员编号,客户姓名,性别,地址,消费积分,备注)
用户(用户ID,用户名,密码)
用户类型(类型编号,名称)
账单(账单编号,消费金额,结账日期,结账时间)
订单(订单编号,预订日期,预期时间,备注)
员工(工号,员工类别,姓名,性别,工作状态,电话,地址)
房间(房间编号,房间类型,房间状态,价格)
物品(物品编号,物品名,单价,赔偿价格)
说明:
1.加下划线的部分表示关系的码
2.以上关系的详细内容说明请参照概念结构设计中的具体内容
3.上面的各个关系对概念结构设计中的相关内容了作了修改,主要加了各个实体中间的联系。
7.1.2联系所对应的关系模式:
1)、把顾客和订单之间的1:
m的预订联系转化为相应的关系模式如下:
预订(订单编号,客户编号);
2)、把订单和房间之间的1:
1的预订联系转化为相应的关系模式如下:
预约(订单编号,房间编号,房间类型,价格,开房日期,开房时间,);
3)、把顾客和房间之间的1:
m的开房联系转化为相应的关系模式如下:
开房(房间编号,客户编号,开房日期,开房时间,工号);
4)、把客户和账单之间的1:
m的付款联系转化为相应的关系模式如下:
付款(账单编号,客户编号,折扣,付款方式,消费时间,工号);
5)、把顾客和物品之间的1:
n的罚款联系转化为相应的关系模式如下:
罚款(物品编号,客户编号,罚款日期,赔偿价格,工号)
6)、把员工和房间之间的n:
m的维修联系转化为相应的关系模式如下:
维修(房间编号,工号,维修日期,维修缘由,维修结果);
7)、其他联系处理说明如下:
账单和员工之间的n:
1联系与付款关系合并;
7.2优化后的数据模型
7.2.1关系模式的调整(基于处理效率的考虑)
按照数据依赖对关系模式进行逐一分析,并进行极小化处理:
客户(客户编号,会员编号,客户姓名,地址,消费积分,备注)
用户(用户ID,用户名,密码)
用户类型(名称,类型编号)
账单(账单编号,消费金额,结账日期,结账时间)
订单(订单编号,预订日期,预期时间,备注)
员工(工号,员工类别,姓名,电话,地址)
房间(房间编号,房间类型,房间状态,价格)
物品(物品编号,物品名,单价,赔偿价格)
开房(账单编号,客户编号,房间编号,会员编号,房间类型,开房日期,开房时间,消费时间,折扣,消费金额,付款方式,结账日期,工号)
优化说明:
将开房和付款合并,减少冗余,提高查询效率
维修(房间编号,工号,维修日期,维修缘由,维修结果);
预订(订单编号,客户编号,会员编号,房间编号,房间类型,价格,开房日期,开房时间,预订日期,工号)
优化说明:
将预订和预约合并,减少冗余,提高查询效率
罚款(物品编号,客户编号)
7.2.2关系模式的规范化(达到3NF)
1)、客户(客户编号,客户姓名,性别,地址,消费积分,备注)
会员(客户编号,会员编号)
2)、用户(用户ID,用户名,密码)
3)、用户类型(类型编号,名称)
4)、账单(账单编号,消费金额,结账日期,结账时间)
5)、订单(订单编号,预订日期,预期时间,备注)
6)、员工(工号,员工类别,姓名,性别,工作状态,电话,地址)
7)、房间(房间编号,房间类型,房间状态,价格)
8)、物品(物品编号,物品名,单价,赔偿价格)
9)、开房(账单编号,客户编号,房间编号,开房日期,开房时间,消费时间,折扣,消费金额,付款方式,结账日期,工号)
客户(客户编号,会员编号)
房间(房间编号,房间类型)
10)、维修(维修编号,维修缘由,维修日期,维修结果)
11)、预订(订单编号,客户编号,房间编号,开房日期,开房时间,预订日期,工号)
客户(客户编号,会员编号)
房间(房间编号,房间类型,价格)
12)、罚款(物品编号,客户编号)
进一步调整优化:
1)、客户(客户编号,客户姓名,性别,地址,消费积分,备注)
2)、会员(客户编号,会员编号)
3)、房间(房间编号,房间类型,房间状态,价格)
4)、物品(物品编号,物品名,单价,赔偿价格)
5)、员工(工号,员工类别,姓名,性别,工作状态,电话,地址)
6)、订单(订单编号,预订日期,预期时间,备注)
7)、预订(订单编号,客户编号,房间编号,客户姓名,开房日期,开房时间,预订日期,工号)
8)、开房(账单编号,客户编号,房间编号,开房日期,开房时间,消费时间,折扣,消费金额,付款方式,结账日期,工号)
9)、账单(账单编号,消费金额,结账日期,结账时间)
10)、维修(房间编号,员工编号,维修日期,维修缘由,维修结果)
11)、罚款(物品编号,客户编号)
12)、用户(用户ID,用户名,密码)
13)、用户类型(类型编号,名称)
7.2.3用户子模式设计
将概念模型转换为全局逻辑模型后,还应该根据用户的习惯和具体需求情况设计符合局部用户需要的外模式,即视图设计。
用户子模式设计(View)列表
编号
用户子模式名(View)
作用(共性:
数据保密和安全保护机制)
V1
Cusbill
查询客户账单明细表并提供消费金额查询
V2
Cuspay
查看客户破坏物品的赔偿金
V3
Wrpair
查看房间维修情况
V4
Roomuse
查看房间使用情况和服务员服务情况
V5
Cusroom
查询客户及房间使用情况
Cusbill(客户编号,客户姓名,账单编号,消费时间,消费金额,结账时间)
Cuspay(客户编号,客户姓名,物品编号,赔偿价格,罚款日期,工号)
Wrpair(房间编号,房间类型,工号,员工姓名,维修原因,维修结果)
Roomuse(房间编号,工号,员工姓名,工作状态,开房时间,消费时间)
Cusroom(房间编号,房间编号,客户姓名,房间类型,房间价格)
八、物理结构设计
8.1DBMS选型及系统配置的选择
KTV管理系统需要的微机数量和规模都不必太大,但在系统设计时应考虑到KTV的发展需求,在选择硬件设备、服务器操作系统、数据库时都考虑到能够逐步的增加和扩展。
本KTV管理系统选用了WindowsXP系统作为微机的操作系统,它能够有较好的使用界面并能够充分发挥出微机硬件的作用,比较适合KTV这样的机构;另外,选用了SQLserver2005数据库。
由于涉及到KTV的财务管理,数据的完整性和安全性显得尤其重要。
系统中的数据一旦丢失,将需要很长时间进行恢复,有时甚至使信息系统不得不从系统初始化阶段重新开始运行。
每天进行数据备份是保障系统安全的重要手段。
数据备份需要严格按照事先制定的备份与故障恢复策略进行,并落实备份登记和检查措施。
具体的系统配置应当根据系统实际运行情况做进一步的调整。
8.2索引的设置
索引名
索引类型
对应的属性名
预定
主索引
订单编号,房间编号
开房
主索引
客户编号,房间编号
8.3安全性及用户权限设计
(1)安全性设计
分配一个可靠的密码给缺省的系统管理(SA)帐号。
并建立自己唯一命名的管理帐号,并将这一帐号放入sysadmin,确认新帐号也有一个可靠的密码。
将独立的密码分配给每一个用户。
使用Windows集成安全性,并让Windows遵循稳定密码规则。
(2)用户权限设计
操作权限
用户类型
可用关系
预订
开房
维修
罚款
负责人员
查看,更新
查看,更新
查看,更新
查看,更新
服务人员
查看
查看
查看
查看
系统管理员
查看,更新,结构修改,更改用户数据
8.4其他物理细节
8.4.1存储结构设计
经过分析可知,本KTV管理系统中信息处理的特点如下:
(1)房间、会员两大部分的数据不仅经常需要查询,而且更新速度快,例如新顾客的办理会员,并进行开房消费。
需要查询到房间的动态分配,更新会员信息及员工的分配。
(2)各个模块信息要求共享的信息较多。
例如会员客户信息,房间信息等。
但账单信息一般不共享。
(3)房间的信息较多,对其管理需要把信息进行分类,如,预订,开房管理,维修,能够及时更新房间信息,并进行快速查询。
从系统中级联修改更新信息。
如根据维修明细表来更新房间明细表中更新状态信息、并更新维修历史表的基本信息,还有就是根据预订明细表来更新房间明细表的状态。
针对这些特点,设计如下:
为了提高系统性能,现根据应用情况将数据按照易变部分和稳定部分、经常存取部分和存取频率较低的部分分别在两个磁盘上存放。
同时,考虑到本系统是多用户的,为了提高效率,数据库的备份的数据和日志文件将保存在磁带中。
●经常存取部分:
房间(房间编号,房间类型,房间状态,价格);
开房(账单编号,客户编号,房间编号,开房日期,开房时间,消费时间,折扣,消费金额,付款方式,结账日期,工号)
预订(订单编号,客户姓名,房间编号,开房日期,开房时间,预订日期,工号)
客户(客户编号,客户姓名,性别,地址,消费积分,备注)
会员(客户编号,会员编号)
员工(工号,员工类别,姓名,性别,工作状态,电话,地址)
订单(订单编号,预订日期,预期时间,备注)
账单(消费金额,结账日期,结账时间)
●存取频率较低的部分:
物品(物品编号,物品名,单价,赔偿价格)
罚款(物品编号,罚款日期,客户编号,工号)
维修(房间编号,维修日期,维修缘由,维修结果)
用户(用户ID,用户名,密码)
用户类型(名称,类型编号)
8.4.2存取路径设计
对会员,预订明细,维修明细,房间管理的信息最经常的操作是查找及更新,假设现有n个开房的信息,如果采取顺序查找,平均查找n/2次;建立B+树索引,则平均查找次数为B+树的层数log2n+1。
所以选择B+树作为索引,具体设计如下:
●对以下经常在查询中出现的关系的码建立索引<说明:
下加横线部分表示关系的码>
维修(房间编号,维修日期,维修缘由,维修结果)
订单(订单编号,预订日期,预期时间,备注);
房间(房间编号,房间类型,房间状态,价格);
员工(工号,员工类别,性别,姓名,工作状态,电话,地址);
会员(客户编号,会员编号);
用户(用户ID,用户名,密码);
用户类型(类型编号,名称,)。
罚款(物品编号,罚款日期,客户编号,工号)
●以下经常进行连接操作的关系的码建立索引:
房间编号、客户编号、会员编号、工号、
●由于下面几个关系模式的更新频率很高,所以没有定义索引:
物品(物品编号,物品名,单价,赔偿价格)
账单(账单编号、总帐编号、发票号、摘要、收入数、支出数、日期、经手人号、备注);
开房(账单编号,客户编号,房间编号,开房日期,开房时间,消费时间,折扣,消费金额,付款方式,结账日期,工号)
预订(订单编号,客户姓名,房间编号,开房日期,开房时间,预订日期,工号)
客户(客户编号,客户姓名,性别,地址,消费积分,备注)
九、数据库实施阶段
9.1数据库实施阶段目标
在上述设计的基础上,收集数据并具体建立一个数据库,运行一些典型的应用任务来验证数据库设计的正确性和合理性。
一般一个大型数据库的设计过程往往需要经过多次循环反复。
当设计的某步发现问题时,可能就需要返回到前面去进行修改。
因此,在做上述数据库设计时就应考虑到今后修改设计的可能性和方便性。
9.2数据库实施阶段任务
1、数据库的建立
CREATEDATABASE[KTVdb]ONPRIMARY
2、顾客信息表建立
CREATETABLE[dbo].[Customers](
[CustomersID][char](5)COLLATEChinese_PRC_CI_ASNOTNULL,
[MemberID][char](5)COLLATEChinese_PRC_CI_ASNULL,
[CustomersName][varchar](8)COLLATEChinese_PRC_CI_ASNOTNULL,
[Sex][char]
(2)COLLATEChinese_PRC_CI_ASNULL,
[Tel][varchar](20)COLLATEChinese_PRC_CI_ASNULL,
[Adress][varchar](50)COLLATEChinese_PRC_CI_ASNULL,
[ConsumptionScores][int]NULL,
[Note][varchar](50)COLLATEChinese_PRC_CI_ASNULL,
CONSTRAINT[PK_Customers]PRIMARYKEYCLUSTERED
(
[CustomersID]ASC
)WITH(PAD_INDEX=OFF,IGNORE_DUP_KEY=OFF)ON[PRIMARY]
)ON[PRIMARY]
3、房间信息表建立
REATETABLE[dbo].[Room](
[RoomID][char](3)COLLATEChinese_PRC_CI_ASNOTNULL,
[RoomType][varchar](8)COLLATEChinese_PRC_CI_ASNOTNULL,
[RoomPrice][float]NOTNULL,
[RoomState][varchar](8)COLLATEChinese_PRC_CI_ASNOTNULL,
CONSTRAINT[PK_Room_1]PRIMARYKEYCLUSTERED
(
[RoomID]ASC
)WITH(PAD_INDEX=OFF,IGNORE_DUP_KEY=OFF)ON[PRIMARY]
)ON[PRIMARY]
4、员工信息表建立
CREATETABLE[dbo].[Worker](
[WorkerID][char](5)COLLATEChinese_PRC_CI_ASNOTNULL,
[WorkerName][char](8)COLLATEChinese_PRC_CI_ASNOTNULL,
[Sex][char]
(2)COLLATEChinese_PRC_CI_ASNULL,
[WorkerType][char](8)COLLATEChinese_PRC_CI_ASNULL,
[WorkerState][varchar](20)COLLATEChinese_PRC_CI_ASNULL,
[Tel][float]NULL,
[Adress][varchar](50)COLLATEChinese_PRC_CI_ASNULL,
CONSTRAINT[PK_Worker]PRIMARYKEYCLUSTERED
(
[WorkerID]ASC
)WITH(PAD_INDEX=OFF,IGNORE_DUP_KEY=OFF)ON[PRIMARY]
)ON[PRIMARY
5、订单表格建立
CREATETABLE[dbo].[Order](
[OrderID][char](4)COLLATEChinese_PRC_CI_ASNOTNULL,
[OrderDate][datetime]NOTNULL,
[OrderTime][datetime]NOTNULL,
[Note][varchar](50)COLLATEC
- 配套讲稿:
如PPT文件的首页显示word图标,表示该PPT已包含配套word讲稿。双击word图标可打开word文档。
- 特殊限制:
部分文档作品中含有的国旗、国徽等图片,仅作为作品整体效果示例展示,禁止商用。设计者仅对作品中独创性部分享有著作权。
- 关 键 词:
- 泉州 朝歌量贩式 KTV 管理信息系统 数据库 分析 设计