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

计算机科学和技术学部数据库课程设计汇报题 目： 旅行社管理系统 指导老师： 李军 学 号： 06 17 姓 名： 易优龙 陈科 班 级： 计算机科学和技术0901 时 间： -12-25 分 数： 摘要伴随生活水平提升，越来越多人外出旅游，这势必给旅游管理强度带来了不小挑战，应对这一情况，开发了此旅行社管理系统。对于旅游管理这一服务性行业，服务质量是吸引用户、提升经济效益关键原因。越来越多旅行社采取管理信息系统来管理日常工作，合理配置资源，提升管理水平，从而在市场竞争取得优势。这次课程设计关键介绍旅行社管理设计和开发过程，本系统采取C#作为开发工具,SQL sever 作为后台数据管理。经过此次开发，使得开发人员更深入了解C#开发工具和数据库技术，积累更多实践经验。本系统含有对相关数据查询，修改，删除等功效，较之于之前相关类系统含有更简便，更实用有点，不过因为技术不成熟，又含有不完整，结构不清楚等缺点。关键字: 数据库；旅行社管理；管理目 录第一章 系统计划11.1引言11.1.1编写目标11.1.2项目背景11.1.3可行性分析前提11.1.4决定可行性关键原因11.2对现有情况分析21.2.1工作负荷21.2.2费用支出21.2.3人员21.2.4不足21.3技术可行性分析21.3.1对系统简明描述21.3.2所掌握技术21.3.3团体技术评价31.4经济可行性分析31.4.1成本31.4.2效益31.5社会可行性分析31.5.1法律方面可行性41.5.2用户使用可行性41.6结论意见4第二章 需求分析52.1用户需求52.2系统数据流图52.2.1顶层数据流图62.2.2一层数据流图62.2.3二层数据流图72.3数据字典8第三章 概念设计123.1概念设计阶段123.1.1 局部E-R模型图123.1.2 概念模型14第四章 逻辑设计154.1 E-R模型图向关系模型转换154.2模式规范化15第五章 运行和维护185.1系统功效模块185.2数据库实施185.2.1表创建185.3 数据库中表数据载入示例图205.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 用户订房信息表F12D5 用户旅游信息表F13F14D6 景点信息表F15F16F10管理员P1登录管理P2旅游管理F4F1F11D1 管理员信息表F2F5F3F6D2 客房信息表D3 用户信息表F8F7F9图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登录身份判定F1P2.1系统管理员部分P2.2一般管理员部分F2F4.1F4.2F3D1 管理员信息表图2.2.2旅行社管理系统一层数据流图登录管理注：F1： 管理员登陆信息 F2:管理员身份信息 F4.1 系统管理员登录信息 F4.2一般管理员登录信息2.2.3二层数据流图管理员登录后，依据所对应帐号密码进入系统管理员部分，系统管理员能够增、删、改客房信息，旅游景点信息；查询全部信息；并有权限增加、删除、修改系统管理员或一般管理员帐号密码，旅游管理系统二层数据流图：F6F4.1.5F4.1.6F15P2.1系统管理员部分P2.1.1管理员信息处理P2.1.2客房信息处理P2.1.3景点信息处理P2.1.4用户订房信息查询P2.1.5用户信息查询P2.1.6用户旅游信息查询F4.1.1F4.1.2F4.1.3F4.1.4D1 管理员信息表D2 客房信息表D3 用户信息表D4 用户订房信息表D5 用户旅游信息表D6 景点信息表F5F9F10F16F12F7F14图2.2.3旅行社管理系统二层数据流图系统管理员部分依据一般管理员权限，能够得到大约数据操作，一般管理员数据流图以下所表示：F4.2.4F4.2.6F4.2.3F4.2.5F8F9F16F11P2.2一般管理员部分P2.2.2客房信息处理P2.2.3景点信息处理P2.2.4用户订房信息查询P2.2.5用户信息查询P2.2.6用户旅游信息查询F4.2.1F7F4.2.2F12D2 客房信息表D3 用户信息表D4 用户订房信息表D5 用户旅游信息表D6 景点信息表F14F13图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 输出“用户名或密码错误”；Endif2.加工名：系统管理员编号：P2.1激发条件：接收到登录信息为系统管理员信息后优先级：高输入：有效系统管理员身份信息输出：系统管理员基础信息。 加工逻辑：依据系统管理身份及登录信息比对 if 存在系统管理员身份信息；Then比对登录信息和身份信息；Else 输出“输入密码和用户名错误”；Endif3.加工名：一般管理员编号：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图用户景点N1游览用户号姓名身份证号码性别联络景点名称城市名称乘车路线景点费用天气用户号景点名称旅行否1.用户游览景点局部E-R模型图：图3.2.1 用户游览局部E-R模型图：2.用户入住客房局部E-R模型图：用户入住客房11用户号姓名身份证号码性别联络客房号客房名称客房地址价格是否预定用户编号客房号订房日期退房日期订房人退房人图3.2.2 用户入住客房E-R模型图3.管理员处理客房信息局部E-R模型图：管理员处理1NM职员号职员号号用户名密码等级客房号客房名称客房地价格预定客房图3.2.3 管理员处理客房信息E-R模型图4.管理员处理用户信息局部E-R模型图：处理2NM管理员职员号职员号用户名密码等级用户用户号身份证号性别联络姓名图3.2.4 管理员处理用户信息E-R模型图 5.管理员处理景点信息局部E-R模型图：管理员处理3景点NM职员号用户名密码等级景点费用路线城市名景点名职员号天气情况图3.2.5 管理员处理景点信息E-R模型图3.2.2 概念模型依据系统需求分析汇报，能够得出旅行社业务及其服务概念模型，以下图是用E-R模型图表示该系统全局概念模型。1用户客房景点入住游览管理员处理3处理1处理2N11NMNMMN 图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,Cno4.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 管理员表字段名字段类型长度主/外键字段约束对应汉字名MNameNchar10PNOT NULL职员号MacNchar20用户名MPswNchar10密码MClNchar12等级MNoNchar10职员编号2.表名：景点表数据起源：景点信息数据录入。表5.1.2 景点表字段名字段类型长度主/外键字段约束对应汉字名SNameNchar10PNOT NULL景点名称CTnameNchar8城市名称CrtNchar80乘车路线SFeFloat景点费用SwthNchar8当地天气3.表名：客房表数据起源：客房信息数据录入。表5.1.3 客房表字段名字段类型长度主/外键字段约束对应汉字名RnoNchar6PNOT NULL客房编号Rname,Nchar10客房名称Radd,Nchar20客房地址RFeFloat价格RorNchar2是否预定4.表名：用户表数据起源：用户信息数据录入。表5.1.4 用户表字段名字段类型长度主/外键字段约束对应汉字名Cno,Nchar6PNOT NULL用户编号CnameNchar10姓名CCrt,Nchar18身份证号码CsexNchar2性别CcntNchar12联络方法5.表名：用户订房表数据起源：用户订房所产生数据统计。表5.1.5 用户订房表字段名字段类型长度主/外键字段约束对应汉字名Rno Nchar6PNOT NULL客房编号CnoNchar6FNOT NULL用户编号RordDatatime订房日期RqtdDatatime退房日期RormNchar10订房经手人RqtmNchar10退房经手人6.表名：用户旅游表数据起源：用户游览景点产生统计。表5.1.6 用户旅游表字段名字段类型长度主/外键字段约束对应汉字名Cno Nchar6PNOT NULL用户编号SnameNchar10F景点名称TyonNchar2是否游览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(用户编号)