《数据库原理》-旅游景区管理系统

《数据库原理》课程设计报告

设计题目：旅游景区管理系统

专业：信息管理与信息系统

计算机与数据科学学院

2019 年01月11日

目录

1 概述 (1)

1.1选题的背景与意义 (1)

1.2相关技术分析 (1)

1.2.1 系统功能需求 (1)

1.2.2 系统数据要求 (1)

2 系统功能设计 (2)

2.1系统总体结构设计图 (2)

2.2系统功能模块 (3)

2.2.1 用户模块 (3)

2.2.2 管理模块 (3)

3 数据库设计 (4)

3.1需求分析 (4)

3.2.1 系统需求分析 (4)

3.2.2 数据流图 (4)

3.2.3 数据字典 (5)

3.2概念结构设计 (7)

3.3逻辑结构设计 (9)

3.4物理结构设计 (10)

3.4.1 存储结构设计 (10)

3.4.2 存取方式 (10)

3.5数据库实施 (10)

3.6数据库运行与维护 (14)

3.6.1 数据库备份与还原的原则 (14)

3.6.2 数据库备份与还原过程中注意的问题 (14)

3.6.3 数据库的备份计划 (14)

3.6.4 数据库的还原计划 (14)

4 结束语 (15)

参考文献 (16)

1 概述

1.1 选题的背景与意义

由于时下大多数人生活优越，交通工具方便快捷，信息获取方便，导致旅游业迅速发展。为了方便旅游爱好者在网上获取信息，有效地掌握景区的相关信息，开发出一套适合于旅游者在网络上快速获取信息的管理系统，通过本系统，出行者可以查看河南的全部景点列表，了解某个景点的详细情况，自驾车、公交线路，获取景区内的旅游地图等。该系统为旅客提供全面的旅游景点查询服务。

1.2相关技术分析

1.2.1 系统功能需求

1.可以对用户的有关资料进行查询，输入，修改以及删除。

2.便于管理人员掌握用户的具体情况，提供强大的查询功能。

1.2.2 系统数据要求

1.数据录入和处理时的准确性

数据输入错误会导致系统输出的不正确或不可用，从而使此系统的工作没有意义。

2.数据的一致性与完整性

因为信息量非常大，处理用户信息的时候操作非常频繁，管理系统对数据的处理有着非常高的硬性要求，所以要有一定数量的操作人员来维护数据的一致性，在数据录入处来控制数据的去向。

3.数据的独立性

对用户信息进行日常管理，及时进行信息的更新，并且要对系统进行独立且准确的操作。

2 系统功能设计2.1 系统总体结构设计图

图2.1用户设计图

图2.2管理设计图

2.2 系统功能模块

2.2.1 用户模块

（1）用户对旅游线路的查询。

（2）用户对售票情况的查询。

（3）用户对留言的增加，查询。

（4）用户对景区的查询。

2.2.2 管理模块

（1）管理员对旅游线路的增加，修改，删除，查询。

（2）管理员对热点线路的增加，修改，删除，查询。

（3）管理员对留言的增加，修改，删除，查询。

（4）管理员对旅游信息的增加，更新，删除，查询。

3 数据库设计

3.1 需求分析

3.2.1 系统需求分析

通过系统功能分析，针对一般旅游景区信息管理的需求，分析总结出如下需求信息。用户可以对旅游线路及其详细信息进行查询

用户可以预定旅游线路

用户可以查看网站的公告信息

用户可以查看留言板以及留言

管理员可以修改旅游线路信息

管理员可以删除和增加旅游线路

管理员可以增加和修改公告信息

管理员可以查看留言板以及回复留言

3.2.2 数据流图

（1）旅客数据流图：

图3.1旅客数据流图

（2）管理数据流图：

图3.2管理数据流图

3.2.3 数据字典

（1）数据项

用户信息表：

表3.1 用户信息

留言板信息表：

（2）数据结构

表3.3 数据结构

（3）数据流

（4）数据存储

（5）处理过程

3.2 概念结构设计

1.局部E-R图

图3.3用户与可预订旅游线路之间的实体关系E-R图

图3.4管理员与旅游线路之间的实体关系E-R图

图3.5管理员与公告之间的实体关系E-R图

图3.6管理员与留言板之间的实体关系E-R图

2.全局E-R图

图3.7全局E-R图

3.3 逻辑结构设计

1.联系类型的转换

E-R图转换为相应的关系模式（依据转换原则）。综观项目的具体特点和整体处理要求，同时为便于系统内部的管理，在各实体原有信息的基础上，确定增加候选码，作为各关系的主键（关键字）、考虑联系确定外键。

（1）管理员（用户名，密码）

（2）公告栏（公告标题，公告时间，公告内容）

（3）旅客（用户名，密码）

（4）旅游线路（旅游线路名称，旅游线路文字描述，介绍图片）

（5）留言板（留言标题，留言时间，回复内容，回复管理，留言内容）

2.关系模式规范化

关系模式属于第三范式，每个非主属性都不传递函数依赖于主关系键。在关系模式中，用户名，公告标题，旅游线路名称，留言标题为主属性，其余的为非主属性，对于公共栏，公告标题、公告时间决定公告内容，非主属性公告内容不传递函数依赖于主关系键，因此公告栏属于第三范式,对于旅客和管理员，密码不传递依赖于用户名，也属于第三范式。对于旅游路线和留言板也同样是，非主属性不传递依赖于主关系键，都属于第三范式。