旅行社综合管理系统数据库设计.doc

计算机科学和技术学部

数据库课程设计汇报

题 目： 旅行社管理系统
指导老师： 李军
学 号： 06
17
姓 名： 易优龙
陈科
班 级： 计算机科学和技术0901
时 间： -12-25
分 数：
摘要
伴随生活水平提升，越来越多人外出旅游，这势必给旅游管理强度带来了不小挑战，应对这一情况，开发了此旅行社管理系统。
对于旅游管理这一服务性行业，服务质量是吸引用户、提升经济效益关键原因。越来越多旅行社采取管理信息系统来管理日常工作，合理配置资源，提升管理水平，从而在市场竞争取得优势。
这次课程设计关键介绍旅行社管理设计和开发过程，本系统采取C#作为开发工具,SQL sever 作为后台数据管理。经过此次开发，使得开发人员更深入了解C#开发工具和数据库技术，积累更多实践经验。
本系统含有对相关数据查询，修改，删除等功效，较之于之前相关类系统含有更简便，更实用有点，不过因为技术不成熟，又含有不完整，结构不清楚等缺点。
关键字: 数据库；旅行社管理；管理

目 录

第一章 系统计划 1
1.1引言 1
1.1.1编写目标 1
1.1.2项目背景 1
1.1.3可行性分析前提 1
1.1.4决定可行性关键原因 1
1.2对现有情况分析 2
1.2.1工作负荷 2
1.2.2费用支出 2
1.2.3人员 2
1.2.4不足 2
1.3技术可行性分析 2
1.3.1对系统简明描述 2
1.3.2所掌握技术 2
1.3.3团体技术评价 3
1.4经济可行性分析 3
1.4.1成本 3
1.4.2效益 3
1.5社会可行性分析 3
1.5.1法律方面可行性 4
1.5.2用户使用可行性 4
1.6结论意见 4
第二章 需求分析 5
2.1用户需求 5
2.2系统数据流图 5
2.2.1顶层数据流图 6
2.2.2一层数据流图 6
2.2.3二层数据流图 7
2.3数据字典 8
第三章 概念设计 12
3.1概念设计阶段 12
3.1.1 局部E-R模型图 12
3.1.2 概念模型 14
第四章 逻辑设计 15
4.1 E-R模型图向关系模型转换 15
4.2模式规范化 15
第五章 运行和维护 18
5.1系统功效模块 18
5.2数据库实施 18
5.2.1表创建 18
5.3 数据库中表数据载入示例图 20
5.4 系统功效展示和数据库查询 21
课程设计总结 26
参考文件 27

第一章 系统计划
1.1引言
1.1.1编写目标
本文档将描述对旅行社管理系统项目标可行性研究。
1.1.2项目背景
本项目作为《数据库技术和应用》课程设计项目提出，期望对该项目标分析和设计，切实领会数据库设计和应用。伴随旅游产业发展，大量用户数据和相关产业数据需要处理，为了降低相关从业人员工作量，提升工作效率，推出一款旅行社管理软件是肯定。
1.1.3可行性分析前提
要求：
（1）功效：能够管理用户信息，对景点信息进行罗列处理，综合管理用户游览地点信息，用户入住旅馆信息化管理，和对客房管理。
（2）性能：数据库录入；信息检索；用户信息查询。
（3）运行环境
操作系统：windows
硬件要求：内存512M以上
（4）完成日期：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对系统简明描述
伴随当下大量游客信息需要处理，我们小组将开发这款管理系统。它是基于SQL Server 和C#技术以数据库后台关键应用、以服务、查询为目标信息管理平台。
1.3.2所掌握技术
数据库技术，C#程序设计，用数据库技术做后台数据管理，用C#设计前台窗体。从硬件和开发环境来看，除了对数据库服务器要求稍微高了点些，其它现有条件全部能够得到满足。能够确保系统功效实现，和稳定性，提升利用效率，以对管理达成最优化管理。而且要求对系统有一定安全性要求，不得随意删除，修改和增加相关数据，采取相关技术尽可能地提升系统运行速度。
1.3.3团体技术评价
因为sql server 数据库技术和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顶层数据流图
依据系统关键信息处理功效，整个系统能够看作登陆管理，旅游管理两个部分从而得出了旅行社管理系统顶层图以下所表示：
D4 用户订房信息表

F12
D5 用户旅游信息表

F13
F14
D6 景点信息表

F15
F16
F10

管理员
P1

登录管理
P2

旅游管理
F4
F1
F11
D1 管理员信息表

F2
F5
F3
F6
D2 客房信息表

D3 用户信息表

F8
F7
F9

图2.2.1 旅行社管理系统顶层数据流图

注：
F1： 管理员登陆信息 F2:管理员身份信息 F3:登陆错误信息 F4:管理员身份信息 F5:管理员基础信息 F6:不一样权限管理员信息 F7：F8：用户信息F9：F10：客房信息 F11: F12:用户订房信息 F13: F14:用户旅游信息 F15: F16:景点信息

2.2.2一层数据流图
管理员登陆管理。管理员在登陆时，系统会进行判定。管理员一共有两种类型，分别是一般管理员和系统管理员。在登陆时候管理员身份由系统自行判定。在判定时需要查询管理员信息表。管理员信息表，存放管理员信息等。验证以后凭身份进入一般管理员系统或系统管理员系统。旅游管理系统一层分解图——登陆管理，图2.2所表示：

管理员
P1

登录身份判定
F1
P2.1

系统管理员部分
P2.2

一般管理员部分
F2
F4.1
F4.2
F3
D1 管理员信息表

图2.2.2旅行社管理系统一层数据流图—登录管理

注：F1： 管理员登陆信息 F2:管理员身份信息 F4.1 系统管理员登录信息 F4.2一般管理员登录信息

2.2.3二层数据流图
管理员登录后，依据所对应帐号密码进入系统管理员部分，系统管理员能够增、删、改客房信息，旅游景点信息；查询全部信息；并有权限增加、删除、修改系统管理员或一般管理员帐号密码，旅游管理系统二层数据流图：F6

F4.1.5
F4.1.6
F15
P2.1

系统管理员部分
P2.1.1
管理员信息处理
P2.1.2
客房信息处理
P2.1.3
景点信息处理
P2.1.4
用户订房信息查询
P2.1.5
用户信息查询
P2.1.6
用户旅游信息查询
F4.1.1
F4.1.2
F4.1.3
F4.1.4
D1 管理员信息表

D2 客房信息表

D3 用户信息表

D4 用户订房信息表

D5 用户旅游信息表

D6 景点信息表

F5
F9
F10
F16
F12
F7
F14

图2.2.3旅行社管理系统二层数据流图—系统管理员部分

依据一般管理员权限，能够得到大约数据操作，一般管理员数据流图以下所表示：

F4.2.4
F4.2.6
F4.2.3
F4.2.5
F8
F9
F16
F11
P2.2

一般管理员部分
P2.2.2
客房信息处理
P2.2.3
景点信息处理
P2.2.4
用户订房信息查询
P2.2.5
用户信息查询
P2.2.6
用户旅游信息查询
F4.2.1
F7
F4.2.2
F12
D2 客房信息表

D3 用户信息表

D4 用户订房信息表

D5 用户旅游信息表

D6 景点信息表

F14
F13

图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
取值范围及含义：“00000000”-“99999999”，表示管理员名称。
3.数据项名称：管理员密码
简述：全部管理员名称
类型：字符串
长度：10
取值范围及含义：“”-“”，表示管理员名称。
4.数据项名称：用户编号
简述：全部用户编号
类型：字符串
长度：6
取值范围及含义：“000000”-“999999”，表示用户编号。
5.数据项名称：用户姓名
简述：全部用户姓名
类型：字符串
长度：10
取值范围及含义：取实际字符表示用户姓名。
6.数据项名称：用户身份证号码
简述：全部用户身份证号码
类型：字符串
长度：18
取值范围及含义：“000000”-“999999”，表示用户身份证号码。
7.数据项名称：用户性别
简述：全部用户行不
类型：字符串
长度：2
取值范围及含义：“男”或“女”，表示用户性别。
8.数据项名称：用户联络方法
简述：全部用户联络方法
类型：字符串
长度：12
取值范围及含义：“”-“”，表示用户联络方法。
9.数据项名称：用户名
简述：全部用户名称
类型：字符串
长度：20
取值范围及含义：“00000000”-“99999999”，表示管理员名称。
10.数据项名称：客房编号
简述：全部客房名称
类型：字符串
长度：6
取值范围及含义：“000000”-“999999”，表示客房编号。
11.数据项名称：客房名称
简述：全部客房名称
类型：字符串
长度：10
取值范围及含义：“”-“”，表示客房名称。
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.2 E-R模型图
3.2.1 局部E-R模型图
依据上述全局概念模型图，得出下列局部E-R图
用户
景点
N
1
游览
用户号
姓名
身份证号码
性别
联络
景点名称
城市名称
乘车路线
景点费用
天气
用户号
景点名称
旅行否
1.用户游览景点局部E-R模型图：

图3.2.1 用户游览局部E-R模型图：

2.用户入住客房局部E-R模型图：

用户
入住
客房
1
1
用户号
姓名
身份证号码
性别
联络
客房号
客房名称
客房地址
价格
是否预定
用户编号
客房号
订房日期
退房日期
订房人
退房人

图3.2.2 用户入住客房E-R模型图

3.管理员处理客房信息局部E-R模型图：

管理员
处理1
N
M
职员号
职员号号
用户名
密码
等级
客房号
客房名称
客房地
价格
预定

客房

图3.2.3 管理员处理客房信息E-R模型图

4.管理员处理用户信息局部E-R模型图：

处理2
N
M
管理员
职员号
职员号
用户名
密码
等级
用户
用户号

身份证号

性别

联络

姓名

图3.2.4 管理员处理用户信息E-R模型图

5.管理员处理景点信息局部E-R模型图：

管理员
处理3
景点
N
M
职员号
用户名
密码
等级
景点费用

路线

城市名

景点名
职员号
天气情况

图3.2.5 管理员处理景点信息E-R模型图

3.2.2 概念模型
依据系统需求分析汇报，能够得出旅行社业务及其服务概念模型，以下图是用E-R模型图表示该系统全局概念模型。
1
用户
客房
景点
入住
游览
管理员
处理3

处理1
处理2
N
1
1
N
M
N
M
M
N

图3.2.6 旅行社全局概念模型

第四章 逻辑设计
逻辑结构设计是将抽象概念结构转换为所选择DBMS支持数据模型，并对其进行优化。
4.1 E-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,T yon)
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.3 1：1联络转换关系模式
1．用户入住客房联络概念模型向关系模型转换
客房表： GesRoom(Rno,Rname,Radd,RFe,Ror)；
用户表： Custm(Cno,Cname,CCrt,Csex,Ccnt)；
用户订房表：Gr_Csm(Rno,Cno,Rord,Rqtd,Rorm,Rqtm)。
4.1.4 M：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
NOT NULL
职员号
Mac
Nchar
20

用户名
MPsw
Nchar
10

密码
MCl
Nchar
12

等级
MNo
Nchar
10

职员编号

2.表名：景点表
数据起源：景点信息数据录入。
表5.1.2 景点表
字段名
字段类型
长度
主/外键
字段约束
对应汉字名
SName
Nchar
10
P
NOT NULL
景点名称
CTname
Nchar
8

城市名称
Crt
Nchar
80

乘车路线
SFe
Float

景点费用
Swth
Nchar
8

当地天气
3.表名：客房表
数据起源：客房信息数据录入。
表5.1.3 客房表
字段名
字段类型
长度
主/外键
字段约束
对应汉字名
Rno
Nchar
6
P
NOT NULL
客房编号
Rname,
Nchar
10

客房名称
Radd,
Nchar
20

客房地址
RFe
Float

价格
Ror
Nchar
2

是否预定

4.表名：用户表
数据起源：用户信息数据录入。
表5.1.4 用户表
字段名
字段类型
长度
主/外键
字段约束
对应汉字名
Cno,
Nchar
6
P
NOT NULL
用户编号
Cname
Nchar
10

姓名
CCrt,
Nchar
18

身份证号码
Csex
Nchar
2

性别
Ccnt
Nchar
12

联络方法

5.表名：用户订房表
数据起源：用户订房所产生数据统计。
表5.1.5 用户订房表
字段名
字段类型
长度
主/外键
字段约束
对应汉字名
Rno
Nchar
6
P
NOT NULL
客房编号
Cno
Nchar
6
F
NOT NULL
用户编号
Rord
Datatime

订房日期
Rqtd
Datatime

退房日期
Rorm
Nchar
10

订房经手人
Rqtm
Nchar
10

退房经手人

6.表名：用户旅游表
数据起源：用户游览景点产生统计。
表5.1.6 用户旅游表
字段名
字段类型
长度
主/外键
字段约束
对应汉字名
Cno
Nchar
6
P
NOT NULL
用户编号
Sname
Nchar
10
F

景点名称
Tyon
Nchar
2

是否游览

5.2数据存放位置设计
由系统应用情况特设计以下存放方法，管理员信息表，用户表，客房信息表，景点表，用户订房表，用户旅游表因为信息量大且使用频繁将其存放在高速存放器（硬盘）上。将表和表上索引存放在不一样磁盘上方便提升查询效率，同时这么能够提升物理I/O读写效率。数据库备份文件和日志文件等文件因为使用频率小而且数据量很大，存放在低速存放设备上。

5.3关系模式存取方法
关系模式采取索引存取方法，依据应用需求可知在旅行社管理系统中，职员号，用户名，密码，等级，职员编号，这些字段在查询当中会常常见到，其 中职员号，用户名，密码，等级，职员编号是每个管理员登录系统时全部必需使用，职员号也是管理员在进行信息处理时用到，所以对管理员职员号建立索引。

第六章 运行和维护

数据库物理结构和前台界面设计完成后，就可投入运行了，这标志着开发工作基础完成。不过因为应用环境不停改变，数据库运行过程中物理存放也会不停改变，对数据库设计进行评价、调整、修改等维护工作是一个长久任务，也是设计工作继续和提升

6.1系统功效模块
登录功效：为系统管理员和一般管理员提供登录功效，其它人无权登录。
查询功效：为系统管理员和一般管理员提供查询功效，其中系统管理员有查询全部信息权限，而一般管理员有查询除管理员身份信息之外信息权限。
维护功效：分别给系统管理员和一般管理员提供对应增加、删除不一样信息表功效权限。
退出功效，结束并关闭系统

6.2数据库实施
6.2.1表创建
管理员表：CREATE TABLE Worker(职员号NCHAR(10) NOT NULL, 用户名NCHAR(20), 密码NCHAR(10),等级 NCHAR(12),职员编号 NCHAR(10),CONSTRAINT C1 PRIMARY KEY(职员号))
景点表：CREATE TABLE Sight_Spot(景点名称 NCHAR(10) NOT NULL,城市名称 NCHAR(8), 乘车路线NCHAR(80),景点费用 FLOAT,Swth NCHAR(8),CONSTRAINT C2 PRIMARY KEY(景点名称))
客房表：CREATE TABLE GesRoom(客房编号 NCHAR(6) NOT NULL,客房名称 NCHAR(10),客房地址 NCHAR(20),价格 FLOAT,是否预定 NCHAR(2), CONSTRAINT C3 PRIMARY KEY(客房编号))
用户表：CREATE TABLE Custm(用户编号NCHAR(6) NOT NULL,用户姓名 NCHAR(10),身份证号码 NCHAR(18),性别 NCHAR(2),联络方法NCHAR(12), CONSTRAINT C4 PRIMARY KEY(用户编号))
用户订房表：CREATE TABLE Gr_Csm(客房编号 NCHAR(6) NOT NULL,用户编号 NCHAR(6) NOT NULL,订房日期DATETIME,退房日期 DATETIME,订房经手人 NCHAR(10),退房经手人 NCHAR(10), CONSTRAINT C5 PRIMARY KEY(客房编号,用户编号))
用户游览表：CREATE TABLE Tour(用户编号 NCHAR(6) NOT NULL,景点名称NCHAR(10),是否游览 NCHAR(2), CONSTRAINT C6 PRIMARY KEY(用户编号))