【毕业学位论文】（Word原稿）JSP,JAVA公交查询系统毕业设计论文范文

公交查询系统 论文关键词： B/S 结构 计算机 网络 数据库 言 务器 论文摘要： 本文结合公交查询系统的实际需要，通过对 B/S 模式、 发 环境 及工具、 布服务、数据库以及 言的深入学习及实践，主要完成了公交查询系统的需求分析、数据库设计、应用程序设计的工作。 第一章 引 言 据库技术 数据库技术作为数据 管理 技术，是计算机软件领域的一个重要分支，产生于 60 年代末。现已形成相当规模的理论体系和实用技术。优秀的数据库设计是应用成功的基石。万万丈高楼平地起，数据库设计如同高楼的基石，是开发高品质应用的前提。 据库管理系统（ 数据库管理系统（ 指数据库系统中管理数据的软件系统。 数据库系统的核心组成部分。对数据 库的一切操作，包括定义、查询、更新及各种控制，都是通过行的。 在不同的计算机系统中，由于缺乏统一的标准，即使同种数据模型的 们在用户接口、系统功能方面也常常是不相同的。 用户对数据库进行操作，是由 操作从应用程序带到外部级、概念级、再导向内部级，进而操作存储器中的数据。 主要目标，是使数据作为一种可管理的资源处理。 交查询系统 统功能 1、基于浏览器（ B/S 模式）的公交线路分类查询； 2、数据的录入、修改、添 加、删除。 统运行环境 该系统采用 式进行设计： 在服务器上运行 布服务器、数据库程序，服务器操作系统为 000/003 户机操作为 000/003，其上运行浏览器程序，服务器和客户机可为同一设备。 统开发工具 该系统采用 境进行开发，数据库服务器为 布服务器为户端使用浏览器运行程序，整个 系统调试成功。 文所作工作 首先介绍了城市公交查询系统的应用背景、开发环境以及选用的开发工具与数据库的关系，阐明了计算机互联网络的概念。并对数据库的体系结构、 行了介绍；介绍关系型数据库的基本概念，着重说明了几个关键概念的定义；然后对 言作了一个介绍说明；从特点和功能入手，介绍 且介绍了 B/S 模式的概念、特点；用软件工程的方法分析城市公交查询系统，对整个系统进行了需求分析、功能模块划分，并通过对数据库进行概念设计；对城市公交查询系统的具体设计，描述了 查询、录入模块的实现过程。 第二章 数据库理论基础 系型数据库 据库的设计理论 关系数据库的设计理论主要包括三个方面的内容：数据依赖、范式，模式设计方法。其中数据依赖起着核心的作用。 1. 函数依赖（ 定义 设 R(U)是一个关系模式， U 是 R 的属性集合， X 和 Y 是 U 的子集。对于 R(U)的任何一个可能的关系 r，如果 r 中不存在两个元组，它们在 X 上的属性值相同，而在 Y 上的属性值不同，则称 “” ，记作 XY 。如果 XY ，并且对于 X 的任一真子集 X ，都有 Y 不函数依赖于 X ，则称 “” ，记作 X f Y 。若 XY ，但 Y 不完全函数依赖于 X，则称 “” ，记作 X P Y 。如果 XY ， YZ ，且 Y X， X 不函数依赖于 Y，则称 “Z 传递函数依赖于 X”。 2. 范式 在对表的形式进行了规范化定义后，数据结构还有五种规范化定义，定名为规范化模式，称为范式。在这五种范式中，一般只用前三种，对于常用系统就足够了。而且这五种范式是“向上兼容 ”的，即满足第五范式的数据结构自动 满足一、二、三、四范式，满足第四范式的数据结构自动满足第一、二、三范式， ，依此类推。 为防止数据库出现更新异常、插入异常、删除异常、数据冗余太大等现象，关系型数据库要尽量按关系规范化要求进行数据库设计。 3. 模式设计方法 一个好的模式设计方法应符合下列三条原则： 表达性：涉及到两个数据库模式的等价性问题，即数据等价和依赖等价，分别用无损联接和保持函数依赖来衡量。 分离性：是指属性间的 “独立关系 ”应该用不同的关系模式表达。独立联系是我们所考虑的 “基本信息单位 ”。实际上分离就是清除存 储异常和数据冗余现象。如果能达到这个目的，就分离。分离的基准就是一系列范式，分离与依赖等价有时是不可兼容的。 最小冗余性：要求在分解后的数据库能表达原来数据库的所有信息这个前提下实现。目的就是节省存储空间，提高对关系的操作效率，清除不必要的冗余。但要注意，在实际使用中，并不一定要达到最小宙余。因为有时带点冗余对于查询处理是有好处的。 关系模式的方法基本上可以分为分解与合成两大类。分解型算法要求输入一个初始模式集和依赖集，而结果满足数据等价要求。对于合成型算法只要求输入初始依赖集，结果满足依赖等要求。 但它们依据的基本思想是共同的，即独立的联系独立表示 言 介绍 “结构式查询语言 ”。 然名为查询语言，但实际上具有定义、查询、更新和控制等多种功能。由于它 使用方便、功能丰富、语言简单易学，很快得到应用和推广。 组成 要分成四个部分： 1）数据定义：这一部分也称为 “用于定义 式、基本表、视图和索引。 2）数据操纵：这一部分也称为 “它分为数据查询和数据更新两类。其中数据更新又分成插入、删除、和修改三种操作。 3）数据控制：这一部分包括对基本表和视图的授权，完整性规则的描述，事务控制等内容。 4）嵌入式 使用规定：这一部分内容涉及到 句嵌入在宿主语言程序中使用 的规则。 数据查询 n 句的语法 标表的列名或列表达式序列 本表和（或）视图序列 条件表达式 Y 列名序列 条件表达式 Y 列名 句法中 表示该成分可有，也可无。 整个语句的执行过程如下： a) 读取 句中基本表、视图的数据，执行笛卡尔积操作。 b) 读取满足 句中给出的条件表达式的元组。 c) 按 句中指定列的值分组，同时提取满足 句中组条件表达式的那些组。 d) 按 句中给出的列名或列表达式求值输出。 e) 句对输出的目标表进行排序，按附加说明 序排列，或按 序排列。 句中， 句称为 “行条件子句 ”， 句称为 “分组子句 ”，句称为 “组条件子句 ”， 句称为 “排序子句 ”。 数据更新 数据更新包括数据插入、删除和修改等三种操作 1）数据插入 a) 元组值的插入 本表名（列名表） 组值） 或者 本表名（列名表） （ 组值）， （元组值）， ) 前一种格式只能插入一个元组，后一种格式可以插入多个元组。 2）数据删除 删除操作是指从基本表删除元组，其语法如下： 本表名 件表达式 其语义是从基本表中删除满足条件表达式的元组。 3）数据修改 当需 要修改基本表中元组的某些列值时，可以用 句实现，其句法如下： 本表名 名值表达式 ，列名值表达式 件表达式 其语义是：修改基本表中满足条件表达式的那些元组中的列值，需修改的列值在 第三章 技术介绍 术介绍 在 式发布 之后，这种新的 用开发技术很快引起了人们的关注。 创建高度动态的 用提供了一个独特的开 发 环境 。按照 说法， 够适应 市场 上包括 内的 85% 的服务器产品。 行环境 司的 页上可以下载 范，这些规 范定义了供应商在创建 擎时所必须遵从的一些规则。 在运行 例页面之前，要注意安装 目录，特别是 “目录下的内容。执行示例页面时，可以在这里看到 面如何被转换成 文件，然后又被编译成件（即 件包中的示例页面分为两类，它们或者是 件，或者是包含一个表单的 件，这些表单均由 码处理。与 样， 的 此，在浏览器中使用 “查看源文件 ”菜单是无法看到 代 码的，只能看到结果 码。所有示例的源代码均通过一个单独的 “面提供。 面示例 下面分析一个简单的 面。可以在 录下创建另外一个目录存放此文件，文件名字可以任意，但扩展名必须为 下面的代码清单中可以看到，面除了比普通 面多一些 码外，两者具有基本相同的结构。 码是通过 符号加入到 码中间的，它的主要功能是生成并显示一个从 0 到 9 的字符串。在这个字符串的前面和后面都是一些通过 码输出的文本。 面 出之前。 出之后。 这个 面可以分成几个部分来分析 首先是 令。它描述的是页面的基本信息，如所使用的 语言 、是否维持会话状态、是否使用缓冲等。 令由 结束。在本例中，指令 “ ”只简单地定义了本例使用的是 言（当前，在 范中 唯一被支持的语言）。 接下来的是 明。 明可以看成是定义类这一层次的变量和方法的地方。 明由 结束。如本例中的 “ ”定义了一个字符串变量。在每一项声明的后面都必须有一个分号，就象在普通 中声明成员变量一样 。 位于 之间的代码块是描述 面处理 逻辑 的 码，如本例中的 环所示。 最后，位于 之间的代码称为 达式，如本例中的 “ ”所示。 达式提供了一种将 成的数值嵌入 面的简单方法。 会话状态维持是 用开发者必须面对的问题 。有多种方法可以用来解决这个问题，如使用 隐藏的表单输入域，或直接将状态信息附加到 。 供了一个在多个请求之间持续有效的会话对象，该对象允许用户存储和提取会话状态信息。 同样支持 的这个概念。 在 南 中可以看到许多有关隐含对象的说明（隐含的含义是，这些对象可以直接引用，不需要显式地声明，也不需要专门的代码创建其实例）。例如 象，它是 一个子 类。该对象包含了所有有关当前浏览器请求的信息，包括 单变量等等。 象也是这样一个隐含对象。这个对象在第一个 面被装载时自动创建，并被关联到 象上。与 的会话对象相似， 的 象对于那些希望通过多个页面完成一个事务的应用是非常有用的。 为说明 象的具体应用，接下来我们用三个页面模拟一个多页面的 用。第一个页面（ 仅包含一个要求输入用户名字的 单，代码如下： 请输入您的姓名： 第二个页面是一个 面（ ，它通过 象提取 单中的 ，将它存储为 量，然后将这个 保存到 象中。 象是一个名字 / 值对的集合，在这里，名字 / 值对中的名字为 “ ，值即为 量的值。由于 象在会话期间是一直有效的，因此这里保存的变量对后继的页面也有效。 另外一个任务是询问第二个问题。下面是它的代码： 您的姓名是： 您喜欢吃什么 ? 第三个页面也是一个 面（ ，主要任务是显示问答结果。它从 象提取 值并显示它，以此证明虽然该值在第一个页面输入，但通过 象得以保留。 另外一个任务是提取在第二个页面中的用户输入并显示它： 您的姓名是： 您喜欢吃： （客户机 /服务器， 式中，业务逻辑位于客户端，每完成一项事务，都要频繁地访问数据库，使得网络上数据流量非常大，对于慢速连接的用户，甚至无法使用。 为弥补上述 C/S 架构的缺陷，人们发展出了三层或多层架构：客户机 中间件（应用服务器） 数据库服务器 (在这种架构中，业务逻辑放置于中间件服务器上，大量的数据流也位于中间件和数据库之间，而客户机只是简单地发出请求，中间件接受请求后进行事务处理并将处理的结果返回给客户机，这一类型的客户机也称之为 “廋客户 ”。 B/S 架构实际上是三层架构的一种，所不同 的是客户端就是目前几乎每台电脑中都有的网络浏览器，而中间件则是 用服务器。注意到主要的业务逻辑均由位于 用服务器上的 序或 处理。 、面向 电子 商务时代的技 术 将来所有的应用系统几乎都在互联网或企业内部广域网上运行，发展电子商务成为企业不可避免的信息化道路。 B/S 架构的软件正是电子商务的基石，正是这类软件使得移动办公和分布式协同工作真正成为现实。无论在世界的那个角落，只需要一台可以联网的设备（ 计算机 、 至手机）都可以方便地与客户联系和与他人协同工作。 2、软件操作、维护和升级方式的革命 软件系统的改进和升级越来越频繁， B/S 架构的产品在维护和升级方面具备显著的优势。无论用户的规模有多大，有多少分支机构都不会增加任何维护升级的工作量，所有的操作只对服务器进行，通过远程连接服务器，异地的运维人员甚至于可以做到远程维护和升级，这对 人力 、时间、费用的节省是相 当惊人的。 所有的客户端只是浏览器，所有的操作都和上网浏览网页类似，使用者接受的培训也仅限于业务 逻辑 而无需将大量精力浪费学习软件操作上。 3、系统整合 无论是办公自动化（ 统， 人力资源 （ 统，客户关系 管理 （ 统，等，发展的趋势是不断融合。而采用统一的 B/S 结构开发的产品无论是现在还是将来都是最好的选择，它提供了真正意义上无缝地与其它系统进行整合的方案。 用 言 实现 1、跨越平台的限制 尽管目前 面系统一统天下，但是服务器系统采用的操作系统却具有多样性，包括 T/2000系统都可以实现企业级应用。即便是桌面系统，中国政府出于安全和国家战略的考虑，希望有自己的操作系统， 出现使这种想法变成了现实。 传统的 C/S 架构的软件需要针对不同的操作系统开发不同版本的软件，面对众多的操作系统和软件快速的升级换代，采 用这一架构开发软件，对于企业的 资 无疑是一种巨大的风险。而采用 言实现的 B/S 架构的软件产品真正做到了 “一次编写处处运行 ( ,对企业而言，可以规避将来更换操作系统所带来的风险。 2、健壮的系统 言实现的软件具有天然的健壮性。这是 言自身的特性保证的。利用 崩溃，这正是安全性要求很高的企业级应用所不可或缺的特性。 第四章 公交查询系统设计分析 根据数据库系统生存期的设计方法，从数据库应用系统和开发的全过程来考虑，将数据库应用系统设计分为以下几个阶段： 1）规划； 2）需求分析； 3）概念设计； 4）逻辑设计 5） 物理 设计 用需求分析 要设计一个良好的公交查询系统，就必须首先明确该应用 环境 对系统的要求。公交查询系统的应用背景为：方便市民搭乘公交车出行；手动（目前）、自动（将来）、及时更新查询数据。因此，该系统需满足以下几方面需求： 1、查询功能：系统需要提供几种不同方式的查询手段，以实现灵活方便地管理整个系统。 2、数据的更新修改： 更新：系统允许管理员级别的用户对数据进行更新、修改并且存盘操作； 编辑：系统允许管理员级别的用户对数 据进行编辑、删除的操作，保证现库的真实性与实时性。 3、打印输出（暂未实现）：系统可以将用户查询到的内容动态地生成报表，并打印输出。 统功能模块划分 公交查询系统功能划分模块如下： 查询系统模块 该模块实现公交查询功能。可实现按起点中转站终点查询查询和按线路查询两种查询方式。 录入系统模块 该模块实现数据的录入、修改、删除功能。 统数据库设计 概念设计 概念设计的目标是产生反映城市公交查询系统需求的数据库概念结构，即概 念模式。概念模式是独立于数据库逻辑结构，独立于支持数据库的 依赖于计算机系统的 1、 型 型是对现实世界的一种抽象。它的主要成分是实体、联系和属性。使 用这三种成分，我们可以建立许多应用 环境 的 型。 2、 型的操作 在利用 型进行数据库概念设计的过程中，常常需要对 进行种种 变换。这些变换又称为 型的操作，包 括实体类型、联系类型和属性的分裂、合并和增删等等。 3、利用 法的数据库概念设计 利用 法进行数据库的概念设计，可以分成三步进行：首先设计局部 式，然后把各局部 式综合成一个全局 式，最后对全局 式进行优化，得到最终的 概念模式。 设计局部的 式 通常，一个数据库系统都是为多个不同用户服务的。各个用户对数据的观点可能不一样，信息处理需求也可能不同。在设计数据库概念结构时，为了更好地模拟现实世界，一个有效的策略是 “分而治之 ”，即先分别考虑各 个用户的信息需求，形成局部概念结构，然后再综合成全局结构。在 法中，局部概念结构又称为局部 式，其图形表示称为 。 实体和属性的定义如下： 站点（站点编号，站点名称，站点类别） 线路（线路编号，始发时间，终发时间，备注） 线路站点对应（线路编号，站点名称） * 、联系定义 型的 “联系 ”用于刻画实体之间的关联。一种完整的方式是对局部结构中任意两个实体类型，依据需求分析的结果，考察局部结构中任意两个实体类型之间是否存在联系。若有联系，进一步确定是 1:N， M:N，还是 1:1 等。还要考察一个实体类型内部是否存在联系，两个实体类型之间是否存在联系，多个实体类型之间是否存在联系，等等。 5、设计全局 式 所有局部 式都设计好了后，接下来就是把它们综合成单一的全局概念结构。全局概念结构不仅要支持所有局部 式，而且必须合理地表示一个完整、一致的数据库概念结构。 1）确定 公共 实体类型 为了给多个局部 式的合并提供开始合并的基础，首先要确定各局部结构中的公共实体类型。在这一步中我们仅根据实体类型名和键枕认定公共实体类型。一般把同名实体类型作为公共实体类型的一类候选，把具有相同键的实体类型作为公共实体类型的另一类候选。 2）局部 式的合并 合并的原则是：首先进行两两合并；先和合并那些现实世界中有联系的局部结构；合并从公共实体类型开始，最后再加入独立的局部结构。 3）消除冲突 冲突分为三类：属性冲突、结构冲突、命名冲突。 设计全局 式的目的不在于把若干局部