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