数据库课程设计网络商城管理系统Word文档格式.docx

数据库课程设计网络商城管理系统Word文档格式.docx

《数据库课程设计网络商城管理系统Word文档格式.docx》由会员分享，可在线阅读，更多相关《数据库课程设计网络商城管理系统Word文档格式.docx（37页珍藏版）》请在冰豆网上搜索。

MyEclipse8.6企业版，Tomcat7。

0,SQLServer2005企业版，JDK1.6。

●所建议开发项目的建模工具：

PowerDesinger15。

1.2可行性研究的前提

1.2.1条件假定和限制

建议软件寿命:

未知。

经费来源：

无.

硬件条件：

IntelPentium4、2G内存同等性能及以上的硬件条件.

运行环境：

Window2003/XP。

数据库：

MicrosoftSQLserver2005.

投入运行最迟时间：

2012年1月2日。

3技术可行性分析

1.3。

1技术的支持能力

本系统采用MVC设计模式，使用当前最流行的Struts2+Spring3+Hibernate框架进行开发，在前台用JSP页面进行开发和管理用户界面，利用轻巧的JavaScript库-jQuery处理页面的JavaScript脚本，使开发更加的高效、提示信息更加的完善、界面更加友好,并且有较强的亲和力.后台采用微软的SQLServer2005数据库。

本系统采用的技术和开发环境在实际中应用非常广泛，充分说明本系统在技术方面的可行性。

此前，我们已使用相同技术开发过类似软件系统,具有一定开发经验。

此外，从开发人员的水平考虑，本系统的2名开发人员，具有较强软件开发能力，且之前开发参加过类似软件系统的开发,经验丰富。

3.2技术的优势

1.B/S结构最大的优点就是可以在任何地方进行操作而不用安装任何专门的软件。

只要有一台能上网的电脑就能使用，客户端零维护。

系统的扩展非常容易，只要能上网,再由系统管理员分配一个用户名和密码，就可以使用了.

2.J2EE体系结构提供中间层集成框架用来满足无需太多费用而又需要高可用性、高可靠性以及可扩展性的应用的需求。

3.开发效率、代码重用率高。

4。

跨平台，编写一次，随处运行。

3技术的难点

考虑系统的高并发问题。

2。

系统安全性问题.

4经济可行性分析

1投资

1.基础投资 

计算机10台总记8万，服务器4台总记20万，数据通讯设备5万元，安全与保密设备1万元，操作系统,应用软件和数据库管理软件0.4万元。

所以总基建投资需要 

34。

4万元。

2.经常性支出

对服务器定期更新和维护，1000元一个月，宽带网络1万元一年, 

2个管理员每月2000元/个,公司人员如果需要进行自己维护,员工维护培训费用.

2效益

1。

经常性收益

（1）提高商城管理效率的时间收益。

（2）因网上购物替代传统购物模式,而减少通讯等的经费损失5万/年。

总结：

收益/投资比：

按5年算，140万/64。

4万，收益远远大于投资.

1.5社会可行性分析

1.5.1法律因素

1.所有软件都选用正版。

所有技术资料都由提出方保管.

3.合同制定确定违约责任。

1.5。

2用户可行性

使用本系统人员要求有一定计算机基础的人员，系统管理员要求有计算机的专业知识，所有人员都要经过一定的指导。

管理人员也需经一般培训.经过培训人员将会熟练使用本系统.

系统管理员将进行专业培训,他们将熟练管理本系统。

1.6结论意见

由于投资效益比远大于支出,技术、经济、操作都有可行性,可以马上进行开发.

第二章需求分析

2.1概述

2.1。

1编写目的

本文档由彭果、李井军小组共同编写。

本需求分析目的在于明确说明本系统需求，界定系统实现功能的范围，指导系统设计以及编码。

并且下阶段的设计、开发提供依据,为项目组成员对需求的详尽理解，以及在开发开发过程中的协同工作提供强有力的保证。

本文档的读者为项目组的全体开发人员。

2项目范围

本商城系统包括:

商品管理、会员管理、购物管理、订单管理等模块.

3运行环境

系统所需运行环境如下：

表2-1软件环境

名称

版本

语种

操作系统

Windows

7

简体中文

数据库平台

SQLServer

2005

运行平台

Tomcat

6。

2需求分析

2.2。

1功能划分

1.前台展示模块：

商品分类检索

用户登录与注册

购物车

订单生成

订单查询

2.后台管理模块：

管理员管理

商品类别管理

商品管理

会员管理

处理订单

2.2.2功能需求

后台管理员分为系统管理员、货物管理员两种.

1.系统管理员：

系统管理员可以对所有管理员进行管理，可以添加删除管理员资料，赋予权限等等.

货物管理员：

货物管理员能够对所有的商品信息、商品类别进行增删改。

3数据流图

2.3。

1系统顶层图

管理员输入帐号密码后进入管理系统，系统对管理员身份进行判断后会显示相应权限的模块，系统会根据要求进行数据读取.数据包括商品信息，商品类别信息，订单信息等等。

具体流程如下图所示：

图2.1系统顶层图

2一层分解图

根据管理员不同的权限可以控制相应权限的模块，响应的模块会产生相应的数据流在模块与数据库之间进行交互。

图2.2系统一层分解图

3。

3二层分解图

管理员信息管理

系统管理员可以查询与新增管理员,查询到管理员后可以进行信息的修改，新增和修改后的管理员信息会更新管理员信息库。

图2.3管理员信息管理分解图

用户信息管理

系统管理员可以先从用户信息库按照相应条件读取用户的信息，然后在模块中对用户信息进行修改,然后再更新用户信息库.具体流程如下图所示:

图2.4用户信息管理分解

管理员先可以从商品类别库或者商品信息库中按照相应条件读取到商品的类别信息和商品信息,然后再在相应模块中对类别或者商品进行增加、修改和删除，最后再提交并且更新商品类别信息库或者商品信息库。

图2.5商品管理分解图

订单管理

管理员先从订单信息库中按照相应条件读取到订单信息,然后在订单管理模块中对订单进行修改，修改后更新订单信息库。

图2。

6订单管理分解图

2.4数据字典

4.1数据流条目

主要的数据流条目如下：

表2.1管理员登录信息数据流

编号

F1

数据流名称

管理员登陆信息

简述

管理员在登陆时输入的账号、密码和验证码

去向

登陆管理

组成

用户名+密码+验证码

表2。

2管理员登录错误信息数据流

F2

登陆错误信息

用户名或密码错误后返回给用户的信息

管理员

错误信息

表2.3管理员信息数据流

F3

管理员信息

管理员信息库发出的管理员信息

4修改后的管理员信息数据流

F4

修改后的管理员信息

管理员修改后的管理员信息

管理员信息库

表2.5判断身份后的管理员信息数据流

F5

判断身份后的管理员信息

登陆管理对管理员身份判断后的信息

后台管理系统

管理员权限+管理员信息

表2.6商品信息数据流

F6

商品信息管理

对商品进行增加、修改、删除后的信息

商品信息库

商品信息

表2.7类别信息数据流

F7

类别信息管理

对商品类别进行增加、修改、删除后的信息

商品类别信息库

商品类别信息

8订单信息数据流

F8

订单信息管理

对订单进行修改后的信息

订单信息库

订单信息

2数据项条目

数据项名称：

用户ID

简述：

商城注册用户的编号

类型：

整形

长度：

6

取值范围及含义：

从000001开始自动增长

2.数据项名称:

用户名

商城注册用户用户名

可变长度字符串

50

从“A—Z”、“0—9”中由用户自行定义，用于用户登录商城时输入的用户名

3.数据项名称：

用户密码

商城注册用户的密码

长度：

取值范围及含义:

从“A-Z”、“0—9”中由用户自行定义，用于用户登录商城时输入的用户密码

4.数据项名称：

管理员ID

简述:

管理员的编号

类型:

4

从0001开始自动增长

5.数据项名称:

管理员用户名

管理员的登录帐号

无限制，自定义

6.数据项名称:

管理员密码

简述:

管理员登录的密码

每个字位度可以在”A"

-”Z”或"

0”—“9”中取，用于用户信息的保密。

7。

商品编号

每个商品的编号

无

取值范围及含义:

从1开始由系统自动增长

8.数据项名称：

商品名称

每个商品的名称

取值范围不限，表示该件商品的名称

3加工条目

1.加工名：

管理员登陆

激发条件：

收到到登陆请求时

优先级：

高

输入：

有效的用户名,密码

输出：

管理员身份信息,登陆错误信息

加工逻辑：

根据管理员的登陆申请查询管理员信息表。

if用户名存在，密码正确；

Then输出身份信息；

Else输出“用户名或密码错误”；

Endif

2.加工名：

商品类别查询

收到管理员身份信息后

输入:

要查询的商品类别信息

加工逻辑:

根据管理员的操作输出商品类别信息

if商品类别信息正确；

Then输出商品类别信息；

Else输出“没有此商品类别”；

Endif

3.加工名:

优先级:

要查询的商品信息

根据管理员的操作输出商品信息

if商品信息正确；

Then输出商品信息；

Else输出“没有此商品"

；

第三章概念设计

3.1实体之间的联系

一个用户可以查看或购买多件商品，一件商品可由多个用户购买。

2。

一个用户可以有多个订单，一个订单只属于一个用户。

3.一件商品有多张图片，一张图片只属于一个商品.

4.一件商品只属于一个类别，一个类别可以有多件商品。

5。

一个管理员可以修改多件商品，一件商品可以被多个管理员修改。

6。

一个管理员可以修改多个订单,一个订单可以被多个管理员修改。

7。

一个管理员可以修改多个商品类别，一个商品类别可以被多个管理员修改。

3.2E—R图

1局部E—R图

用户购买商品E-R图

图3.1用户购买商品E—R图

2.用户查看或生成订单E-R图

图3。

2用户查看或生成订单E-R图

3.商品图片E—R图

3商品图片E—R图

4。

商品类别E-R图

图3.4商品类别E-R图

订单管理E-R

5订单管理E—R图

6.商品管理E—R图

6商品管理E-R图

商品类别管理E-R图

7商品类别管理E-R图

2系统全局E—R图

8网络商城管理系统全局E-R图

第四章逻辑结构设计

1关系模型的设计依据

根据需求分析中的E-R图,可以很清晰的看出各个实体的属性和实体之间的联系,通过对实体的属性和之间的联系的分析，我们将其由概念模型向关系模型转化，并且根据范式化理论进行优化。

对于实体间的联系我们分不同的情况讨论：

若实体间的联系是1：

1，可以在两个实体转换成的两个关系中任意一个关系的属性中加入另一个关系的码.

若实体间联系为1：

n，则在n端实体转换成的关系中加入1端实体转换成的关系码。

若实体间联系为n:

m,则将联系转换为关系,关系的属性为诸个实体的码加上联系具有的属性,而关系的码则为诸实体的码的组合。

4.1实体间联系转化的关系模式

根据以上的关系模型设计依据信息,我们可以对实体进行关系模型的转化。

1.用户购买商品概念模型向关系模型的转化：

用户信息表（用户ID，用户名，用户密码，真实姓名,地址，电子邮件,电话号码）

商品信息表（商品ID,商品名称，商品描述,创建时间,采购价格，市场价格,销售价格，款式，是否推荐,浏览量,销售量，商品类别ID,商品图片ID）

订单项表（订单ID，商品ID,商品名称，商品价格，商品数量，订单信息ID）

2.管理员后台管理概念模型向关系模型的转化：

管理员信息表（管理员ID，用户名，密码）

订单信息表（订单信息ID，订单名称，送货地址，电话,采购价格，创建时间,支付方式,用户ID）

商品信息表（商品ID，商品名称,商品描述,创建时间，采购价格，市场价格,销售价格，款式,是否推荐，浏览量,销售量，商品类别ID，商品图片ID）

商品类别信息表（商品类别ID，类别名称，类别级别,父节点）

商品图片表（商品图片ID，路径）

3。

数据依赖

（1）用户信息

F1=（用户ID→用户名，用户ID→用户密码,用户ID→真实姓名,用户ID→地址，用户ID→电子邮件，用户ID→电话号码）

（2）商品信息

F2=（商品ID→商品名称，商品ID→商品描述,商品ID→创建时间,商品ID→采购价格，商品ID→市场价格，商品ID→销售价格，商品ID→款式，商品ID→是否推荐,商品ID→浏览量，商品ID→销售量，商品ID→商品类别ID,商品ID→商品图片ID）

（3）订单项

F3=（订单ID→商品ID，商品ID→商品名称，商品ID→商品价格，商品ID→商品数量,订单ID→订单信息ID）

（4）管理员信息

F4=（管理员ID→用户名，管理员ID→密码）

（5）订单信息

F5=（订单信息ID→订单名称，订单信息ID→送货地址，订单信息ID→电话，订单信息ID→采购价格，订单信息ID→创建时间,订单信息ID→支付方式，订单信息ID→用户ID）

（6）商品类别信息

F6=（商品类别ID→类别名称,商品类别ID→类别级别，商品类别ID→父节点）

（7）商品图片

F7=（商品图片ID→路径）

4.2关系模型的优化

1确定范式级别

根据上述分析所归结出来的数据依赖的种类和在本系统实际的开发过程中,需要涉及多表的查询及表的修改和删除，且存在多值依赖的实际情况下，其关系模式应达到BCNF。

2.2实施规范化处理

根据以上信息,我们发现订单项表中存在传递依赖,因此我们要对此关系进行优化。

优化后的关系模型如下：

用户信息表（用户ID，用户名，用户密码,真实姓名，地址，电子邮件，电话号码）

商品信息表（商品ID，商品名称,商品描述，创建时间，采购价格，市场价格，销售价格，款式，是否推荐，浏览量，销售量,商品类别ID,商品图片ID）

订单项表（订单ID,商品ID,订单信息ID）

管理员信息表（管理员ID，用户名，密码）

订单信息表（订单信息ID,订单名称，送货地址,电话，采购价格，创建时间,支付方式，用户ID）

商品类别信息表（商品类别ID，类别名称，类别级别，父节点）

商品图片表（商品图片ID，路径）

第五章物理结构设计

5。

1创建数据库及数据表

本系统采用SQLServer2005数据库,创建的数据库名称为shop。

表的结构设计如下：

1.tb_customer（用户信息表）

表5。

1用户信息表

字段名

数据类型

是否为空

是否为主键

说明

Cid

INT

否

是

系统自动编号

Username

Varchar（50）

用户名

Password

用户密码

Realname

真实姓名

Address

Varchar（250）

地址

Email

电子邮件

Mobile

Varchar（11）

电话号码

2.tb_orderitem（订单项表）

表5.2订单项表

OrderItem_id

productID

商品编号

orderID

Varchar（30）

订单编号

tb_productInfo（商品信息表）

表5.3商品信息表

id

Name

Varchar（100）

商品名称

Description

TEXT

商品描述

createTime

DATETIME

创建时间

baseProce

FLOAT

采购价格

marketPrice

市场价格

sellPrice

销售价格

sexRequest

Varchar（5）

所属款式类别（男款、女款）

Commend

BIT

是否推荐

clickCount

浏览量

sellCount

销售量

categoryId

否

商品类别ID

uploadFile

否

上传文件ID

tb_productcategory（商品类别信息表）

4商品类别信息表

类别名称

Level

类别级别

Pid

父节点

tb_order（订单信息表）

表5.5订单信息表

Order_id

订单名称

送货地址

电话

totalPrice

CreateTime

DateTime

paymentWay

Varchar（15）

支付方式

cutomerId

用户ID

tb_uploadfile上传文件表

表5.6上传文件表

path

Varchar（255）

文件上传路径

7.tb_user管理员表

7管理员表

username

管理员名称

登陆密码

5.2数据的存放位置设计

由系统应用情况特设计如下存储方式，所有的表由于信息量大且使用频繁将其存储在高速存储器（硬盘）上。

将表存储在不同的磁盘上以便提高查询效率,同时这样可以提高物理I/O读写效率。

数据库备份文件和日志文件等文件因为使用频率小而且数据量非常大，存放在低速存储设备上.

第六章运行与维护

6.1项目运行界面

主界面

将SQLServer2005主服务打开，再将项目打包的war包放到tomcat下的workapp下，然后点击开始菜单→运行→输入cmd回车→输入startup回