计算机毕业设计 jsp网银管理系统sqlserver 毕设

https://www.bilibili.com/video/BV1z2421w7xy/

演示视频：

3.2 JSP 简介

基于WEB的应用系统，在Internet/Intranet技术推广以来，得到了迅速发展。无论是银行、政府的内部计算机应用系统，还是在互联网上的应用服务系统，基于WEB的计算机应用系统都发挥着越来越多的作用。逐渐成为计算机应用系统的主流。

JSP是微软公司的.NET框架技术的一部分，旨在建立WEB应用程序和XML WEB服务。JSP使用编译的、事件驱动编程模型从而提高运行速度和分离应用程序逻辑和用户界面。使用JSP可以很容易的开发基于三层架构的B/S应用程序[6]。

JSP又叫ASP+，但并不是ASP的简单升级，而是Microsoft推出的新一代Active Server Pages脚本语言。ASP NET是Microsoft发展的新型体系结构.NET框架中的核心要素。JSP完全基于模块和组件，具有更好的可扩展性和可定制性，JSP建立在CLR ( Common Language Runtime，通用语言运行库)基础之上，它主要用于在服务器上开发功能强大的Web应用。

JSP具有如下的优点：

(1) 速度奇快，所有的JSP代码(包括服务器脚本)都经过了编译后运行，所以执行效率极高。

(2) 可用XCOPY轻松完成部署及应用升级。JSP支持应用程序的实时更新。管理员不必关掉网络服务器或者甚至不用停止应用程序的运行就可以更新应用程序。

(3) 代码与内容分离。JSP程序通过Code-Behind、用户控件、自定义控件及组件这四种方法将程序结构与执行代码分离，使程序的逻辑结构一目了然，便于团队开发。

(4) 广泛的移动设备支持。JSP的移动控件使开发人员可以面向广泛的移动设备，包括支持Web的移动电话、寻呼机和个人数字助理((PDA)。

(5) 轻松构建和使用Web服务。由于JSP和.NET远程处理建立在.NET Framework之上，因此它们可以使创建XML  Web services变得更为容易[7]。

3.3 SQL Server 2000

SQL Server 2000是建立在 SQL Server 7.0 在可伸缩性、可用性、可管理性和数据仓库成功的基础上，并且引入了针对电子商务的重要新功能[8]。

4  系统的功能设计

3.1 功能概述

本系统要实现用户对自助银行的所有操作：账户管理、出入账管理、系统维护管理等功能。

(一) 自助银行账户管理模块：本模块又包括账户资料添加模块、账户资料管理模块等子模块。

(二) 出入账管理模块：本模块又包括出入账资料添加、出入账资料管理模块等子模块。

(三) 系统维护管理：本模块又包括公司用户设置模块、重新登录模块、数据管理模块等子模块。

根据上功能模块图，可设计出相对应的系统数据流程图。如下：

图3-1系统数据流程图

3.2 后台数据库设计

3.2.1 存储过程介绍

1. 考虑使用存储过程的理由

相对于使用一般的SqlCommand 对象的 T-SQL语句，使用存储过程可以使SqlCommand 对象的 T-SQL语句并入数据访问代码更好的位置。由于应用程序随着时间的推移增添了一些功能，因此其内部可能包含一些复杂的 T-SQL 过程代码。存储过程为封装此代码提供了一个替换位置。

大多数人可能对存储过程已有所了解，但对于那些不了解存储过程的人员而言，存储过程是指一组作为单个代码单元一起存储于数据库中的 T-SQL 语句。您可以使用输入参数传入运行时信息，并取回作为结果集或输出参数的数据。存储过程在首次运行时将被编译。这将产生一个执行计划 - 实际上是 Microsoft® SQL Server™ 为在存储过程中获取由 T-SQL 指定的结果而必须采取的步骤的记录。然后，执行计划在内存中得到缓存，以备以后使用。这样会改善存储过程的性能，因为 SQL Server 无需为确定如何处理代码而重新分析它，而只需引用缓存的计划即可。这个缓存的计划一直可用，直到SQL Server 重新启动，或直到它由于使用率较低而溢出内存[9]。

2. 性能

缓存的执行计划曾使存储过程较之查询更有性能优势。但对于 SQL Server 的几个最新版本，执行计划已针对所有 T-SQL 批处理进行了缓存，而不管它们是否在存储过程中。因此，基于此功能的性能已不再是存储过程的卖点。任何使用静态语法，且提交频率足以阻止执行计划溢出内存的 T-SQL 批处理将会获得同样的性能好处。“静态”部分是关键；任何更改，即使像添加注释这样无关紧要的更改，也将导致无法与缓存的计划相匹配，从而将无法重复使用计划。

但是，当存储过程可以用于降低网络流量时，它们仍然能够提供性能好处。您只需在网络中发送 EXECUTE stored_proc_name 语句，而非整个 T-SQL 例程，这可以在复杂操作中广泛使用。设计良好的存储过程可以将交易记录端与服务器之间的许多往返过程简化为单个调用。

此外，使用存储过程使您能够增强对执行计划的重复使用，由此可以通过使用远程过程调用 (RPC) 处理服务器上的存储过程而提高性能。使用 StoredProcedure 的SqlCommand.CommandType 时，存储过程通过 RPC 执行。RPC 封装参数和调用服务器端过程的方式使引擎能够轻松地找到匹配的执行计划，并只需插入更新的参数值。

考虑使用存储过程提高性能时，最后要考虑是否要充分利用 T-SQL 的优点。请考虑要如何处理数据。

(1) 是否要使用基于集合的操作，或执行 T-SQL 中完全支持的其他操作？那么存储过程就是一个选择，而内联查询也可以使用。

(2) 是否尝试执行基于行的操作，或复杂的字符串处理？那么可能要重新考虑在T-SQL 中进行这种处理，这不包括使用存储过程，至少要到 Yukon 发布并且公共语言运行库 (CLR) 集成可用后，才能使用存储过程。

3. 可维护性和抽象

要考虑的另一个潜在优势是可维护性。理想情况下，数据库架构从不更改，业务规则不被修改，但在现实环境中，情况则完全不同。既然情况如此，那么如果可以修改存储过程以包括新 X、Y 和 Z 表（为支持新的销售活动而添加了这些表）中的数据，而不是在应用程序代码中的某个位置更改此信息，则维护对您来说可能比较容易。在存储过程中更改此信息使得更新对应用程序而言具有透明性。您仍然返回相同的销售信息，即使存储过程的内部实现已经更改。更新存储过程通常比更改、测试以及重新部署程序集需要较少的时间和精力。

另外，通过抽象化实现并将此代码保存在存储过程中，任何需要访问数据的应用程序均可以获取一致的数据。您无需在多个位置维护相同的代码，用户便可获取一致的信息。

在存储过程中存储 T-SQL 的另一个可维护性优点是更好的版本控制。您可以对创建和修改存储过程的脚本进行版本控制，就像可以对任何其他源代码模块进行版本控制一样。通过使用 Microsoft Visual SourceSafe® 或某个其他源代码控制工具，您可以轻松地恢复到或引用旧版本的存储过程。

在使用存储过程提高可维护性时应值得注意的一点是，它们无法阻止您对架构和规则进行所有可能的更改。如果更改范围大到需要对输入存储过程的参数进行更改，或者要更改由其返回的数据，则您仍需要更新程序集中的代码以添加参数、更新GetValue()调用，等等。

要注意的另一个问题是，由于存储过程将应用程序绑定到SQL Server，因此使用存储过程封装业务逻辑将限制应用程序的可移植性。如果应用程序的可移植性在您的环境中非常重要，则将业务逻辑封装在不特定于RDBMS的中间层中可能是一个更佳的选择。

4. 安全性

考虑使用存储过程的最终原因是它们可用于增强安全性。

就管理用户对信息的访问而言，通过向用户授予对存储过程（而不是基础表）的访问权限，它们可以提供对特定数据的访问。存储过程可以看成是SQL Server视图，除非存储过程接受用户的输入以动态更改显示的数据。

存储过程还可以解决代码安全问题。它们可以防止某些类型的SQL插入攻击。主要是一些使用运算符（如AND或OR）将命令附加到有效输入参数值的攻击。在应用程序受到攻击时，存储过程还可以隐藏业务规则的实现。这对于将此类信息视为知识产权的公司非常重要。

另外，使用存储过程使您可以使用JAVA中提供的SqlParameter类指定存储过程参数的数据类型。这为验证用户提供的值类型（作为深层次防御性策略的一部分）提供了一个简单方法。在缩小可接受用户输入的范围方面，参数在内联查询中与在存储过程中一样有用。

使用存储过程仅仅能够增强数据库安全性，而不能完全使数据库免受攻击。如果数据库的安全性或编码做法不完善仍然会受到攻击。对SQL Server角色创建和分配如果不加注意将导致人们访问到不应看到的数据。同时，如果认为使用存储过程便可防止所有SQL插入代码攻击（例如，将数据操作语言 (DML) 附加到输入参数），后果将是一样的。

另外，无论T-SQL位于代码还是位于存储过程中，使用参数进行数据类型验证都不是万无一失的。所有用户提供的数据（尤其是文本数据）在传递到数据库之前都应受到附加的验证。

5. 使用存储过程的优缺点

使用存储过程封装应用逻辑的优点如下：

(1) DBA+Developer分工明确，之间代码模块化。减少数据库操作员和程序员的错误。

(2) 数据库安全性；可以设置连接字符串中账号只可访问存储过程，不可操作表。这样数据完整性也有保证。

(3) 存储过程是编译过的，执行快。

(4) 事务的级别，存储过程级别的事务，JAVA级别的事务比较。一致性。

(5) 减少网络通信量。一个需要数行 Transact-SQL 代码的操作由一条执行过程代码的单独语句就可实现，而不需要在网络中发送数行代码。

使用存储过程封装应用逻辑的缺点如下：

(1) 编程语言SQL功能较差（不包括 SQL 2005）

(2) 与编程环境集成不够（不包括 SQL 2005）

(3) 移植性差（不同数据库）

(4) 数据库服务器压力大

3.2.2 数据库的表的设计

根据项目要求进行数据库中表格的建立。根据对用户的需求分析，在项目中，需要记录银行的基本信息、交易记录的基本信息、银行的操作信息。

数据库的设计范式是数据库设计所需要满足的规范，满足这些规范的数据库是简洁的、结构明晰的，同时，不会发生插入（insert）、删除（delete）和更新（update）操作异常。反之则是乱七八糟，不仅给数据库的编程人员制造麻烦，而且面目可憎，可能存储了大量不需要的冗余信息。

范式的介绍：

第一范式（1NF）：数据库表中的字段都是单一属性的，不可再分。这个单一属性由基本类型构成，包括整型、实数、字符型、逻辑型、日期型等。

第二范式（2NF）：数据库表中不存在非关键字段对任一候选关键字段的部分函数依赖（部分函数依赖指的是存在组合关键字中的某些字段决定非关键字段的情况），也即所有非关键字段都完全依赖于任意一组候选关键字。

第三范式（3NF）：在第二范式的基础上，数据表中如果不存在非关键字段对任一候选关键字段的传递函数依赖则符合第三范式。所谓传递函数依赖，指的是如果存在“A → B → C”的决定关系，则C传递函数依赖于A。因此，满足第三范式的数据库表应该不存在如下依赖关系：

　　关键字段 → 非关键字段x → 非关键字段y

鲍依斯-科得范式（BCNF）：在第三范式的基础上，数据库表中如果不存在任何字段对任一候选关键字段的传递函数依赖则符合第三范式。可以消除第三范式删除异常、插入异常和更新异常[13]。

系统中还需要有用户的登录信息表用于记录用户的登录信息。登录信息表中应该有登录的用户名和密码，其中登录名为主键。

3.2.3 设计局部ER模式

1实体和属性的定义：

1）管理员用户类别（用户名，密码，权限，注册时间等）

图3-2管理员用户实体与属性的定义

2）账户信息类别（姓名，身份证，性别，联系电话，地址，注册时间等）

图3-3账户信息实体与属性的定义

3）交易记录信息类别（姓名，性别，身份证，电话，地址）     

图3-4 交易记录信息实体与属性的定义

2 实体关系定义：

ER模型的“联系”用于刻画实体之间的关联。一种完整的方式是对局部结构中任意两个实体类型，依据需求分析的结果，考察局部结构中任意两个实体类型之间是否存在联系。若有联系，进一步确定是1:1、1:N、M:N的关系。还要考察一个实体类型内部是否存在联系，两个实体类型之间是否存在联系，多个实体类型之间是否存在联系，等等针对本系统分析如下：

实体间的关系：
① 一个管理员可以管理多个自助银行账户，而一个自助银行账户只能被一个管理员管理。

图3-5 自助银行账户与管理员信息管理1:N(一对多的关系)

② 一个管理员可以管理多个出入账信息，而一个出入账信息只可以被一个管理员管理

图3-6管理员与出入账信息1:N（一对多的关系）

3.2.4设计全局ER模式

所有局部ER模式都设计好了后，接下来就是把它们综合成单一的全局概念结构。全局概念结构不仅要支持所有局部ER模式，而且必须合理地表示一个完整、一致的数据库概念结构。
1) 确定公共实体类型
   为了给多个局部ER模式的合并提供开始合并的基础，首先要确定各局部结构中的公共实体类型。在这一步中我们仅根据实体类型名和键来认定公共实体类型。一般把同名实体类型作为公共实体类型的一类候选，把具有相同键的实体类型作为公共实体类型的另一类候选。
2) 局部ER模式的合并
   合并的原则是：首先进行两两合并；先合并那些现实世界中有联系的局部结构；合并从公共实体类型开始，最后再加入独立的局部结构。
3) 消除冲突
   冲突分为三类：属性冲突、结构冲突、命名冲突。
   设计全局ER模式的目的不在于把若干局部ER模式形式上合并为一个ER模式，而在于消除冲突，使之成为能够被所有用户共同理解和接受的同一的概念模型。
4) 全局ER模式的优化
   在得到全局ER模式后，为了提高数据库系统的效率，还应进一步依据处理需求对ER模式进行优化。一个好的全局ER模式，除能准确、全面地反映用户功能需求外，还应满足下列条件：实体类型的个数要尽可能的少；实体类型所含属性个数尽可能少；实体类型间联系无冗余。