旅行社管理系统数据库设计.docx
《旅行社管理系统数据库设计.docx》由会员分享，可在线阅读，更多相关《旅行社管理系统数据库设计.docx（33页珍藏版）》请在冰豆网上搜索。
旅行社管理系统数据库设计
计算机科学与技术学部
数据库课程设计报告
题目：
旅行社管理系统
指导老师：
李军
学号：
0943********
09430624816217
姓名：
易优龙
陈科
班级：
计算机科学与技术0901
时间：
2011-12-25
分数：
摘要
随着生活水平的提高，越来越多的人外出旅游，这势必给旅游管理的强度带来了不小的挑战，应对这一情况，开发了此旅行社管理系统。
对于旅游管理这一服务性行业，服务质量是吸引客户、提高经济效益的关键因素。
越来越多的旅行社采用管理信息系统来管理日常工作，合理配置资源，提升管理水平，从而在市场竞争取得优势。
这次课程设计主要介绍旅行社管理的设计与开发过程，本系统采用C#作为开发工具,SQLsever作为后台数据管理。
通过此次开发，使得开发人员更进一步了解C#开发工具以及数据库技术，积累更多的实践经验。
本系统具有对相关数据的查询，修改，删除等功能，较之于之前的相关类系统具有更简便，更实用的有点，但是由于技术的不成熟，又具有不完整，结构不清晰等缺点。
关键字:
数据库；旅行社管理；管理
第一章系统规划
1.1引言
1.1.1编写目的
本文档将描述对旅行社管理系统项目的可行性研究。
1.1.2项目背景
本项目作为《数据库技术与应用》的课程设计项目提出，希望对该项目的分析与设计，切实领会数据库的设计与应用。
随着旅游产业的发展，大量的客户数据以及相关产业的数据需要处理，为了减少相关从业人员的工作量，提高工作效率，推出一款旅行社的管理软件是必然的。
1.1.3可行性分析的前提
要求：
（1）功能：
能够管理客户信息，对景点信息进行罗列处理，综合管理客户游览地点的信息，客户入住旅馆的信息化管理，以及对客房的管理。
（2）性能：
数据库的录入；信息检索；用户信息查询。
（3）运行环境
操作系统：
windows
硬件要求：
内存512M以上
（4）完成日期：
2011年12月
1.1.4决定可行性的主要因素
技术因素、硬件因素、软件因素、经济因素、团队合作等
1.2对现有情况的分析
1.2.1工作负荷
每天工作5个小时，团队合作
1.2.2费用支出
人力开支：
没人每小时20元；设备开支：
计算机2台，每天开支费用20元；其他材料开支：
每天20元。
1.2.3人员
团队共有2人。
1.2.4局限性
技术不够精通，影响进度。
1.3技术可行性分析
1.3.1对系统的简要描述
随着当下大量的游客信息需要处理，我们小组将开发这款管理系统。
它是基于SQLServer2005以及C#技术以数据库后台核心应用、以服务、查询为目的信息管理平台。
1.3.2所掌握的技术
数据库技术，C#程序设计，用数据库技术做后台数据的管理，用C#设计前台窗体。
从硬件和开发环境来看，除了对数据库服务器要求稍微高了点些，其他现有条件都可以得到满足。
可以保证系统的功能实现，以及稳定性，提高利用的效率，以对管理达到最优化的管理。
并且要求对系统有一定的安全性要求，不得随意删除，修改以及增加有关数据，采用相关技术尽可能地提高系统的运行速度。
1.3.3团队技术评价
由于sqlserver2005数据库技术和C#技术没有熟练掌握，导致个别技术手段无法实现，会导致进度缓慢，但是不影响整体开发。
本系统要求对人员达到最精简化要求，明确分工，以免造成人员的冗余导致的任务不清楚，混乱的局面，效率降低的不良后果。
1.4经济可行性分析
1.4.1成本
采购、开发所需费用，有以下可能情况：
A.服务器设备租用，
B.环境保护设备
C.安全与保密设备
D.数据库管理软件
E.设备维护费用
F.人员的工资、奖金
G.保密安全方面的开支
H.公用设施方面的开支
1.4.2效益
1）该系统减少了不必要的人力管理成本，提高了管理效率。
2）由于开发难度不大，对于人员的要求，以及技术要求不是很高，但是能够很有效的对数据进行管理，带来对旅行社的效益。
1.5社会可行性分析
1.5.1法律方面的可行性
政府，无论是中央政府还是地方政府，一般都用法律规定组织可以做什么，不可以做什么。
例如：
《合同法》，《消费者权益保护法》，《专利法》，《反不正当竞争法》等对所有商业组织的行为都做了限制，我们的技术团队设有自己的法律顾问，因此不会在法律方面出现不必要的麻烦。
1.5.2用户使用的可行性
该系统是一个旅行社的信息管理平台，用户可以根据平台中的文字提示以及以往的类似的软件操作进行无障碍的操作。
1.6结论意见
综上所述，该项目在技术，技术上可以加大对这款软件的功能，让此系统更具有价值，经济上又可以以较少的资本取得翻倍的利益，绝对是值得我们去开发这款软件，最后，此开发软件项目不会牵扯到任何触犯法律之类的事。
所以，我们占据了天时，地利，人和的优势。
第二章需求分析
需求分析也称为系统分析。
通过需求分析，得出系统分析对数据的要求和对功能的需求。
2.1用户需求
一个旅行社管理系统，包括了许多的方面，里面结构复杂，大体上我们可以从这几个方面来说。
本系统主要实现以下几项功能：
（1）客房管理：
1）对旅行社的所有住房按类别统一编号；登记客房的主要信息。
2）设备有损害或者是不便入住的客房注销客房登记。
（2）客户管理：
1）建立客户信息表，对客户统一编号。
2）对新加入的客户，将信息加入到信息客户表中。
3）当客户信息表发生变化时，修改客户信息表中相应的记录。
（3）旅游管理
1）对旅游景点的名称和城市名称进行统一编号。
2）将对应景点的乘车路线和景点费用以及天气状况录入相应的记录。
3）景点的乘车路线和费用发生变化时，修改记录中的相应信息。
（4）订房服务：
未入住的客房要按照客房列别进行分类，供客户查询预定。
录入入住客户的姓名
备注订房日期，以及退房日期
（5）退房服务：
根据客户要求进行退房服务，删除之前的客户订房记录。
2.2系统数据流图
2.2.1顶层数据流图
根据系统主要信息的处理功能，整个系统可以看作登陆管理，旅游管理两个部分从而得出了旅行社管理系统的顶层图如下所示：
2.2.2一层数据流图
管理员登陆管理。
管理员在登陆时，系统会进行判断。
管理员一共有两种类型，分别是普通管理员和系统管理员。
在登陆的时候管理员的身份由系统自行判断。
在判定时需要查询管理员信息表。
管理员信息表，存储管理员信息等。
验证之后凭身份进入普通管理员系统或者系统管理员系统。
旅游管理系统一层分解图——登陆管理，如图2.2所示：
注：
F1：
管理员登陆信息F2:
管理员身份信息F4.1系统管理员登录信息F4.2普通管理员登录信息
2.2.3二层数据流图
管理员登录后，根据所相应的帐号密码进入系统管理员部分，系统管理员可以增、删、改客房信息，旅游景点信息；查询所有的信息；并有权限增加、删除、修改系统管理员或普通管理员的帐号密码，旅游管理系统二层数据流图：
F6
图2.2.3旅行社管理系统二层数据流图—系统管理员部分
根据普通管理员的权限，可以得到大概的数据操作，普通管理员数据流图如下所示：
图2.2.4旅行社管理系统二层数据流图—普通管理员部分
2.3数据字典
2.3.1数据流条目
表2.3.1管理员登陆信息数据流条目
编号
F1
数据流名
管理员登陆信息
简述
管理员在登陆时输入的账号、密码
去向
P1：
登陆管理
组成
用户名+密码
表2.3.2管理员登录时身份验证信息数据流条目
编号
F2
数据流名
管理员身份信息
简述
登陆系统时判断比对管理员发送的登录信息
去向
P1：
登陆管理
组成
用户名+密码
表2.3.3登陆错误信息数据流条目
编号
F3
数据流名
登录错误信息
简述
登陆错误时发送的信息
去向
管理员
组成
错误提示
表2.3.4管理员登陆后信息数据流条目
编号
F4
数据流名
管理员身份信息
简述
登陆系统判断管理员身份后发送的信息
去向
P2：
旅游管理
组成
用户名+密码
表2.3.5系统查询管理员身份信息数据流条目
编号
F5
数据流名
管理员身份信息
简述
登陆系统后查询时所发送的信息
去向
P2：
旅游管理
组成
用户名+密码
表2.3.6系统处理管理员身份信息数据流条目
编号
F6
数据流名
管理员身份信息
简述
登录系统后增加、修改、删除的管理员身份信息
去向
管理员信息表
组成
用户名+密码
表2.3.7系统查询客户信息数据流条目
编号
F7
数据流名
客户信息
简述
系统查询的客户信息流
去向
P2：
旅游管理
组成
客户编号+姓名+身份证号码+性别+联系方式
表2.3.8系统处理客户信息数据流条目
编号
F8
数据流名
客户信息
简述
系统对客户信息增加、删除、修改后的信息流
去向
客户信息表
组成
客户编号+姓名+身份证号码+性别+联系方式
表2.3.9系统查询客房信息数据流条目
编号
F9
数据流名
客房信息
简述
系统查询的客房信息
去向
P2：
旅游管理
组成
客房编号+客房名称+客房地址+价格+是否预定
表2.3.10系统处理客房信息数据流条目
编号
F10
数据流名
客房信息
简述
系统对客房信息增加、删除、修改后的数据流
去向
客房信息表
组成
客房编号+客房名称+客房地址+价格+是否预定
表2.3.11系统处理客户订房信息数据流条目
编号
F11
数据流名
客户订房信息
简述
系统对客户订房信息增加、删除、修改后的数据流
去向
客户订房信息表
组成
姓名+客房名称+订房人编号+订房日期+退房人编号+退房日期
表2.3.12系统查询客户订房信息数据流条目
编号
F12
数据流名
客户订房信息
简述
系统对客户订房信息进行查询的数据流
去向
P2:
旅游管理
组成
姓名+客房名称+订房人编号+订房日期+退房人编号+退房日期
表2.3.13系统处理客户旅游信息数据流条目
编号
F13
数据流名
客户旅游信息
简述
系统对客户旅游信息增加、删除、修改后的数据流
去向
客户旅游信息表
组成
客户姓名+景点名称+是否游览
表2.3.14系统查询客户旅游信息数据流条目
编号
F14
数据流名
客户旅游信息
简述
系统对客户旅游信息进行查询的数据流
去向
P2：
旅游管理
组成
客户姓名+景点名称+是否游览
表2.3.15系统处理景点信息数据流条目
编号
F15
数据流名
景点信息
简述
系统对景点信息增加、删除、修改后的数据流
去向
景点信息表
组成
景点名称+城市名称+乘车路线+景点费用+当地天气
表2.3.16系统查询景点信息数据流条目
编号
F16
数据流名
景点信息
简述
系统对景点信息进行查询的数据流
去向
P2：
旅游管理
组成
景点名称+城市名称+乘车路线+景点费用+当地天气
2.3.2数据项
重要部分数据项条目如下：
1.数据项名称：
管理员ID
简述：
所有职工的编号
类型：
字符串
长度：
10
取值范围及含义：
“00000000”-“99999999”，表示管理员的编号。
2.数据项名称：
管理员名称
简述：
所有管理员的名称
类型：
字符串
长度：
20
取值范围及含义：
“00000000000000000000”-“99999999999999999999”，表示管理员的名称。
3.数据项名称：
管理员密码
简述：
所有管理员的名称
类型：
字符串
长度：
10
取值范围及含义：
“0000000000”-“9999999999”，表示管理员的名称。
4.数据项名称：
客户编号
简述：
所有客户的编号
类型：
字符串
长度：
6
取值范围及含义：
“000000”-“999999”，表示客户的编号。
5.数据项名称：
客户姓名
简述：
所有客户的姓名
类型：
字符串
长度：
10
取值范围及含义：
取实际的字符表示客户的姓名。
6.数据项名称：
客户身份证号码
简述：
所有客户的身份证号码
类型：
字符串
长度：
18
取值范围及含义：
“000000000000000000”-“999999999999999999”，表示客户的身份证号码。
7.数据项名称：
客户性别
简述：
所有客户的行不
类型：
字符串
长度：
2
取值范围及含义：
“男”或“女”，表示客户的性别。
8.数据项名称：
客户联系方式
简述：
所有客户联系方式
类型：
字符串
长度：
12
取值范围及含义：
“000000000000”-“999999999999”，表示客户的联系方式。
9.数据项名称：
用户名
简述：
所有用户的名称
类型：
字符串
长度：
20
取值范围及含义：
“00000000000000000000”-“99999999999999999999”，表示管理员的名称。
10.数据项名称：
客房编号
简述：
所有客房名称
类型：
字符串
长度：
6
取值范围及含义：
“000000”-“999999”，表示客房的编号。
11.数据项名称：
客房名称
简述：
所有客房的名称
类型：
字符串
长度：
10
取值范围及含义：
“0000000000”-“9999999999”，表示客房的名称。
12.数据项名称：
客房地址
简述：
所有客房的地址
类型：
字符串
长度：
20
取值范围及含义：
所有描述客房地址的长度在20位以内的字符。
13.数据项名称：
客房价格
简述：
所有客房户的价格
类型：
浮点型
长度：
取值范围及含义：
浮点型数据
14.数据项名称：
是否预定房间
简述：
预定房间描述
类型：
字符串
长度：
2
取值范围及含义：
“是”或“否”，表示是否预定房间。
15.数据项名称：
景点名称
简述：
所有景点的名称
类型：
字符串
长度：
10
取值范围及含义：
描述景点名称的长度在10以内的字符。
16.数据项名称：
城市名称
简述：
所有被记录的城市的名称
类型：
字符串
长度：
8
取值范围及含义：
描述城市名称的长度在8以内的字符
描述景点名称的长度在10以内的字符
17.数据项名称：
乘车费用
简述：
乘车费用的金额
类型：
float
长度：
取值范围及含义：
实际金额大小
18.数据项名称：
当地天气情况
简述：
当地天气情况
类型：
字符串
长度：
8
取值范围及含义：
描述当地天气的长度在8以内的字符
2.3.3加工条目
重要的部分加工条目如下：
1.加工名：
登陆
编号：
P1
激发条件：
接受到登陆请求时
优先级：
高
输入：
有效的用户名，密码
输出：
用户身份信息，登陆错误信息
加工逻辑：
根据用户的登陆申请指定用户号查询用户信息表。
if用户名存在，密码正确；
Then输出身份信息；
Else输出“用户名或密码错误”；
Endif
2.加工名：
系统管理员
编号：
P2.1
激发条件：
接受到登录信息为系统管理员信息后
优先级：
高
输入：
有效的系统管理员身份信息
输出：
系统管理员基本信息。
加工逻辑：
根据系统管理的身份及登录信息比对
if存在系统管理员身份信息；
Then比对登录信息和身份信息；
Else输出“输入的密码和用户名错误”；
Endif
3.加工名：
普通管理员
编号：
P2.2
激发条件：
接受到登录信息为普通管理员信息后
优先级：
高
输入：
有效的普通管理员身份信息
输出：
管理员基本信息。
加工逻辑：
根据管理的身份及登录信息比对
if存在普通管理员身份信息；
Then比对登录信息和身份信息；
Else输出“输入的密码和用户名错误”；
Endif
第三章概念设计
概念设计是将需求分析得到的用户需求抽象为信息结构的过程，是数据库设计的关键之一。
其结果是数据库的概念模式。
在需求分析和逻辑设计之间插入概念设计，使设计者仅从用户角度开袋数据及处理要求和约束，将注意力从复杂、繁琐的实现细节中解脱出来，集中在最重要的信息组织结构和处理模式设计上，还能从各阶段任务相对单一，大大降低设计复杂程度。
3.1概念设计阶段
3.1.1实体间的联系
1.一个客户只能入住一个房间。
2.多名客户可以同时游览一个景点，但是一名客户不能同时游览多个景点。
3.一个系统管理员可以处理多个客房信息，一个客房信息可以被多名系统管理员管理。
4.一个普通管理员可以处理多名客户信息，一个客户信息可以被多名普通管理员管理。
5.一个系统管理员可以处理多个景点信息，一个景点信息可以被多名系统管理员管理。
3.2E-R模型图
3.2.1局部E-R模型图
根据上述全局概念模型图，得出下列局部E-R图
图3.2.2客户入住客房E-R模型图
3.管理员处理客房信息的局部E-R模型图：
图3.2.3管理员处理客房信息E-R模型图
4.管理员处理客户信息的局部E-R模型图：
图3.2.4管理员处理客户信息E-R模型图
5.管理员处理景点信息的局部E-R模型图：
图3.2.5管理员处理景点信息E-R模型图
3.2.2概念模型
根据系统需求分析报告，可以得出旅行社业务及其服务的概念模型，如下图是用E-R模型图表示的该系统的全局概念模型。
图3.2.6旅行社全局概念模型
第四章逻辑设计
逻辑结构设计是将抽象的概念结构转换为所选用的DBMS支持的数据模型，并对其进行优化。
4.1E-R模型图向关系模型的转换
4.1.1关系模式：
R（MName,Mac,MPsw,MCl,MNo,SName,CTname,Crt,SFe,Swth,Rno,Rname,Radd,RFe,Ror,Cno,Cname,CCrt,Csex,Ccnt,Rord,Rqtd,Rorm,Rqtm,Tyon）
4.1.2函数依赖：
F1:
（MName,SName,Rno,Cno）->（Mac,MPsw,MCl,MNo,CTname,Crt,SFe,Swth,Rname,Radd,RFe,Ror,Cname,CCrt,Csex,Ccnt,Rord,Rqtd,Rorm,Rqtm,Tyon）
F2:
MName—>（Mac,MPsw,MCl,MNo）
F3:
SName—>（CTname,Crt,SFe,Swth）
F4:
Rno—>（Rname,Radd,RFe,Ror）
F5:
Cno—>（Cname,CCrt,Csex,Ccnt）
F6:
（Rno,Cno）—>（,Rord,Rqtd,Rorm,Rqtm）
F7:
Cno—>（Sname,Tyon）
易知候选键是：
MName,SName,Rno,Cno
4.1.31：
1联系转换的关系模式
1．客户入住客房联系概念模型向关系模型的转换
客房表：
GesRoom（Rno,Rname,Radd,RFe,Ror）；
客户表：
Custm（Cno,Cname,CCrt,Csex,Ccnt）；
客户订房表：
Gr_Csm（Rno,Cno,Rord,Rqtd,Rorm,Rqtm）。
4.1.4M：
N联系转换的关系模式
1.客户旅游景点联系概念模型向关系模型转换
客户表：
Custm（Cno,Cname,CCrt,Csex,Ccnt）；
景点表：
Sight_Spot（SName,CTname,Crt,SFe,Swth）；
客户旅游表：
Tour（Cno,Sname,Tyon）。
2.管理员处理客房联系概念模型向关系模型转换
管理员表：
Worker（MName,Mac,MPsw,MCl,MNo）；
客房表：
GesRoom（Rno,Rname,Radd,RFe,Ror）。
3.管理员处理客户联系概念模型向关系模型转换
管理员表：
Worker（MName,Mac,MPsw,MCl,MNo）；
客户表：
Custm（Cno,Cname,CCrt,Csex,Ccnt）。
4.管理员处理景点联系概念模型向关系模型转换
管理员表：
Worker（MName,Mac,MPsw,MCl,MNo）；
景点表：
Sight_Spot（SName,CTname,Crt,SFe,Swth）
4.2模式规范化
4.2.1确定范式级别
根据上述分析所归结出来的数据依赖的种类和在本系统实际的开发过程中，需要涉及多表的查询及表的添加，修改和删除，且存在多值依赖的实际情况下，其关系模式应达到BCNF。
4.2.2实施规范化处理
由于R中的属性都是不能再分的项，所以R满足第一范式。
由函数依赖F1，F2，F3，F4，F6，F7可知R中存在部分函数依赖。
于是考虑把关系分解成以下几个子关系：
管理员表：
Worker（MName,Mac,MPsw,MCl,MNo）
景点表：
Sight_Spot（SName,CTname,Crt,SFe,Swth）
客房表：
GesRoom（Rno,Rname,Radd,RFe,Ror）
客户表：
Custm（Cno,Cname,CCrt,Csex,Ccnt）
客户订房表：
Gr_Csm（Rno,Cno,Rord,Rqtd,Rorm,Rqtm）
客户旅游表：
Tour（Cno,Sname,Tyon）
由于以上各关系模式已经消除了部分函数依赖、传递函数依赖，所以符合3范式，并且消除各关系的主属性对于主键的部分函数以及传递函数依赖，所以符合BC范式。
第五章物理设计
5.1数据库的存储结构
根据需求分析，概要设计和逻辑设计的流程得到本系统数据库和数据表结构。
5.1.1数据库
数据库名称：
旅行社管理信息库
5.1.2数据库表结构
1.表名：
管理员表
数据来源：
管理员的基本信息数据导入本系统。
表5.1.1管理员表
字段名
字段类型
长度
主/外键
字段约束
对应中文名
MName
Nchar
10
P
NOTNULL
职工号
Mac
Nchar
20
用户名
MPsw
Nchar
10
密码
MCl
Nchar
12
级别
MNo
Nchar
10
职工编号
2.表名：
景点表
数据来源：
景点信息数据的录入。
表5.1.2景点表
字段名
字段类型
长度
主/外键
字段约束
对应中文名
SName
Nchar
10
P
NOTNULL
景点名称
CTname
Nchar
8
城市名称
Crt
Nchar
80
乘车路线
SFe
Float
景点费用
Swth
Nchar
8
当地天气
升级会员 