ASP网上购物系统
3 需求分析
3 需求分析
网上书店需求,这两方面分别是图书购买者、书店管理人员。图书购买者的需求是查询图书馆所存的图书、个人购买情况及个人信息的修改;书店工作人员对图书借阅者的借阅及还书要求进行操作,同时形成借书或还书报表给借阅者查看确认;图书馆管理人员的功能最为复杂,包括对工作人员、购买者、图书进行管理和维护,及系统状态的查看。powered by 25175.net
图书购买者可直接查看图书情况,如果图书购买者根据本人用户名和密码登录系统,还可以进行本人购书情况的查询和维护部分个人信息。一般情况下,图书购买者只应该查询和维护本人的借书情况和个人信息,若查询和维护其他购买者的购书情况和个人信息,就要知道其他购物者的用户名和密码。这些是很难得到的,特别是密码,所以不但满足了图书购买者的要求,还保护了图书购买者的个人隐私。
书店管理人员功能的信息量大,数据安全性和保密性要求最高。本功能实现对图书信息、购买者信息管理和统计查看及维护。书店管理员可以浏览、查询、添加、删除、修改、统计图书的基本信息;浏览、查询、统计、添加、删除和修改图书购买的基本信息,浏览、查询、统计书店信息,但不能添加、删除和修改购买信息,但是,删除某条图书购买者基本信息记录时,应实现对该图书定单记录的级联删除。
4 系统设计
4.1 概要设计
在软件需求分析阶段,搞清楚了软件“做什么”的问题,形成了目标系统的逻辑模型。现在我们所要做的就是要把软件“做什么”的逻辑模型变换为“怎么做”的物理模型,即着手实现软件的需求。首先,我们需要描述的是系统的总的体系结构。
4.1.1 系统结构设计
系统的概要设计中最重要的就是系统的模块化。模块化是指解决一个复杂问题时自项向下逐层把软件系统划分成若干个模块的过程。每个模块完成一个特定的功能,所有的模块按某种方法组织起来,成为一个整体,完成整个系统所要求的功能。
将系统划分为多个模块是为了降低软件系统的复杂性,提高可读性、可维护性,但模块的划分不能是任意的,应尽量保持其独立性。也就是说,每个模块只完成系统要求的独立的子功能,并且与其他模块的联系最少且接口简单,即尽量做到高内聚低耦合,提高模块的独立性,为设计高质量的软件结构奠定基础。
在系统的概要设计中我采用结构化设计(Structure Design,简称SD)。我首先将整个系统化分为几个小问题,小模块。在系统中,我把系统分为2大块,用户的前台使用和管理员的后台管理。
4.1.2 概念设计
在设计阶段中,我从用户的角度看待数据及处理要求和约束,产生一个反映用户观点的概念模式。然后再把概念模式转换成逻辑模式。将概念设计从设计过程中独立开来,使各阶段的任务相对单一化,设计复杂程度大大降低,不受特定DBMS的限制。利用ER方法进行数据库的概念设计,可分成三步进行:首先设计局部ER模式,然后把各局部ER模式综合成一个全局模式,最后对全局ER模式进行优化,得到最终的模式,即概念模式。
设计局部ER模式
实体和属性的定义:
图书(图书编号,图书名称,作者,出版社,出版日期,价格)
购买者(姓名,身份证,联系电话,密码)
图书类别(图书类别编号,类别描述)
ER模型的“联系”用于刻画实体之间的关联。一种完整的方式是对局部结构中任意两个实体类型,依据需求分析的结果,考察局部结构中任意两个实体类型之间是否存在联系。若有联系,进一步确定是1:N,M:N,还是1:1等。还要考察一个实体类型内部是否存在联系,两个实体类型之间是否存在联系,多个实体类型之间是否存在联系,等等。解释如下:
一个购买者(用户)只能具有一种身份,而一种身份可被多个购买者所具有;
一本图书只能属于一种图书类别(类别),而一种图书类别可以包含多本图书;一个用户可以购买多本不同的书,而一本书也可以被多个不同的用户所购买。
设计全局ER模式
所有局部ER模式都设计好了后,接下来就是把它们综合成单一的全局概念结构。全局概念结构不仅要支持所有局部ER模式,而且必须合理地表示一个完整、一致的数据库概念结构。
确定公共实体类型
为了给多个局部ER模式的合并提供开始合并的基础,首先要确定各局部结构中的公共实体类型。在这一步中我们仅根据实体类型名和键来认定公共实体类型。一般把同名实体类型作为公共实体类型的一类候选,把具有相同键的实体类型作为公共实体类型的另一类候选。
局部ER模式的合并
合并的原则是:首先进行两两合并;先和合并那些现实世界中有联系的局部结构;合并从公共实体类型开始,最后再加入独立的局部结构。
消除冲突
冲突分为三类:属性冲突、结构冲突、命名冲突。
设计全局ER模式的目的不在于把若干局部ER模式形式上合并为一个ER模式,而在于消除冲突,使之成为能够被所有用户共同理解和接受的同一的概念模型。
全局ER模式的优化
在得到全局ER模式后,为了提高数据库系统的效率,还应进一步依据处理需求对ER模式进行优化。一个好的全局ER模式,除能准确、全面地反映用户功能需求外,还应满足下列条件:实体类型的个数要尽可能的少;实体类型所含属性个数尽可能少;实体类型间联系无冗余。
4.2 详细设计
4.2.1 关系数据库的逻辑设计
由于概念设计的结果是ER图,DBMS一般采用关系型(本人所使用的MS SQL Server就是关系型的DBMS),因此数据库的逻辑设计过程就是把ER图转化为关系模式的过程。由于关系模型所具有的优点,逻辑设计可以充分运用关系数据库规范化理论,使设计过程形式化地进行。设计结果是一组关系模式的定义。
(1) 导出初始关系模式
product(图书编号#,图书名称,图书类别#,作者,出版社,出版日期,备注,价格,数量)category(图书类别#,类别名)user(姓名,身份证,联系电话,密码)
(2) 产生子模式
子模式是用户所用到的那部分数据的描述。除了指出用户用到的数据外,还应指出数据与概念模式中相应数据的联系,即指出概念模式与子模式之间的对应性。
在信息世界中,信息从客观事物出发流经数据库,通过决策机构最后又回到客观世界,信息的这一循环经历了三个领域:信息世界,数据世界,现实世界。现实世界的事物反映到人的头脑中,人的大脑对它有个认识过程,经过分析(选择、命名、分类等)进入信息世界。这些信息再进一步加工、编码,然后进数据世界,而软件系统的开发工作需要考虑这两个方面的问题,也就是要考虑系统开发所需要的数据,以及如何对这些数据进行操作。这两个问题贯穿了整个软件系统的开发过程,这也就是数据库的设计问题,软件设计的一个核心。
4.2.2 数据库设计
我在系统中定义的表格都严格地按照范式的思想和要求去完成,数据库中的所有表格都达到了三范式的要求。针对本系统的特点,在对所搜集的数据进行规范化之后,定义了如下六张表格,分别是管理员信息表,用户信息表,商品分类信息表,商品信息表,订单信息表和送货方式信息表。通过对这六张表格的操作可以较好地完成系统设计的各项功能,六张表格之间有着不同程度的联系。
管理员信息表(admin):admin(管理员名),password(管理员密码)。
管理员信息表用来记录管理人员的登陆名和密码,通过管理员的身份进入系统后可以对商品进行管理。是区别于一般用户登陆的超级用户,具有最高的权限,包括对商品的添加,删除,修改等,同时还要处理各种订单。
用户信息表(user):username(用户名),password(用户密码),useremail(用户电子邮件),identify(身份证号),question(密码保护提问),answer(回答),address(地址),postzode(邮编)。
用户信息表记录着用户的各种信息,包括用户名、密码、email、身份证号、地址、邮编、提问、回答等用户的基本信息。它为系统提供会员的基本信息,因为购物是和会员的信息联系在一起的。作为会员系统应该知道些资料,以便进行查找。
商品分类信息表(category):categoryid(分类号),category(分类名),categoryorder(分类的顺序)。
商品分类信息表记录着类名,分类号和分类的顺序。商品如果没有分类的话就会很乱,不便于管理,也可以说是没法管理。
商品信息表(product):name(名称),author(作者),mark(出版社),productdate(出版日期),detial(简介),price1(原价),price2(优惠价),solded(卖过的册数),viewnum(被浏览次数),category(分类名),pic(图片),adddate(上架日期),pagenum(页数),format(开本),printed(印刷次数),productnum(商品号)。
商品信息表记录着书名、作者、出版社、出版日期、简介、原价、优惠价、卖过的册数、被浏览次数,分类名,图片、上架日期、页数,开本、印刷次数、书号。有了这些信息和上面的分类表,就会和容易的查找各类的图书以及了解他们的相关信息,用户就可以通过这些信息购买自己想要的商品。
订单信息表(orders):username(用户名),actiondate(下订单的日期),postcode(邮编),address(地址),paymethod(支付方式),realname(真名)。
订单信息表记录着用户名,下订单的日期、邮编、支付方式和真名,通过这些信息系统就会知道收货人的一些基本信息,在这里可以发现,会员可以帮别人买东西,或者送东西给朋友。有了上面的信息,当按上面的支付方式成功后商品就会往订单上的地址发货。
送货方式信息表(delivery):subject(送货方式),fee(外加费用),deliveryorder(排列顺序)。
送货方式信息表记录着送货方式,外加费用,排列顺序。因为在当今信息化的社会中必然会有多种的支付方式,单一的支付方式是不能满足今天社会的要求的,只有多元化的发展才能满足各种不同状况下的需求。
| 【内容导航】 | |
| 第1页:摘要 | 第2页: 背 景 |
| 第3页:2 理论基础 | 第4页:3 需求分析 |
| 第5页:5 系统实现 | 第6页:6 系统应用 |
上一篇:分布式学生成绩查询系统
下一篇:基于Client/Server 的课件系统的设计与实现
|
|
没有图片
(诚实大人
,11月07日 11:13
)
好奇怪呀。。。全网络翻遍没图呀。。。
(as
,10月15日
)
没图片
(条件鱼
,09月03日
)
怎么没图片呢
(洁
,06月18日
)
高手,问下你们...那图片怎么没有类?
(longyu1314520
,06月11日
)
