客户订购登记系统Word下载.docx
《客户订购登记系统Word下载.docx》由会员分享，可在线阅读，更多相关《客户订购登记系统Word下载.docx（18页珍藏版）》请在冰豆网上搜索。
已经在线注册的浏览者，在浏览产品页面时，可以将自己喜欢的产品直接放入购物车中，系统便会自动生成定购单，提交给管理员，企业便会依据顾客注册信息将产品或服务送达顾客手中，从而实现在线订购。
顾客还可以随时登陆查看自己的订单情况，了解企业对自己的产品订单的处理情况。
而采购管理员也可以通过查看每个顾客的定单情况，了解各种产品的销售情况和需要进行采购的商品信息，从而了解市场发展态势并制定相应的措施。
这样更有利于公司的长期发展。
关键词:
JAVA，SQLserver2008，数据库
1、需求分析
1.1问题描述：
随着信息技术的发展和网络在广大消费者中的普及，网上购物愈来愈成为一种潮流和时尚。
一个公司希望为其客户的订购行为建立一个数据库。
1.2业务流程描述：
（1）数据流图：
图1：
顶层数据流图
图2：
第0层数据流图
（2）数据字典：
表格1：
数据字典——消费者
名字
消费者
描述
应用该系统的公司客户
定义
消费者=消费者ID+消费者姓名+地址+联系电话
表格2：
数据字典——订购请求
订购请求
消费者发出的订购请求
订购请求=订购商品的名称、编号+订购商品的数量
表格3：
数据字典——合法的订购请求
合法的订购请求
经过系统检验后合格的请求
合法的订购请求=合法的商品名称、编号+合法的数量
表格4：
数据字典——订单
订单
系统登记用户的请求后，打印出来的关于用户订购请求的详细描述
订单=订单号+消费者ID+订货项数+订货日期+交货日期
表格5：
数据字典——发票
发票
每一张订单，都对应着一张发票，发票上记着消费者所订购商品的价格等信息。
消费者必须支付该发票（支付方式为支票、信用卡或现金）
发票=发票号+订单号+应收金额
表格6：
数据字典——应收账款
应收账款
一个消费者可能一次有多个订单（即对应有多张发票），应收金额将所有发票上的应收金额累加起来，最后由消费者支付
应收金额=某个消费者一次订购的所有应收金额之和
2、概念结构设计
（1）经过分析可知，该系统的实体有：
消费者、订单、订单细节、商品、发票、应收帐。
各个实体的具体E-R图如下：
图3：
消费者实体的E-R图
图4：
订单实体的E-R图
图5：
订单细节的E-R图
图6：
商品实体的E-R图
图7：
发票实体的E-R图
（2）实体-联系方法是抽象和描述现实世界的有力工具。
用E-R图表示的该类模型独立于具体的DBMS所支持的数据模型，它是各种数据模型的共同基础。
经过分析，得到客户订购登记系统的E-R图：
图8：
系统的E-R图
定义每个实体的属性（其中加下划线的属性为实体的码）：
表格7：
E-R图中的实体的属性
消费者ID，消费者姓名，地址，电话
应收帐
消费者ID，发票号，支付日期
订单号，消费者ID，订货项数，订货日期，交货日期
订单细节
订单号，细则号，订货数，商品号，金额
发票号，订单号，应收金额
商品
商品号，商品名，单价
3、逻辑结构设计
3.1E-R图向关系模型的转换
逻辑结构设计的任务就是把概念结构设计阶段设计好的基本E-R图转换为与选用的DBMS产品所支持的数据模型相符合的逻辑结构。
我们将概念结构设计中的E-R图转换成关系模式，转换得到的关系模式：
（1）消费者（消费者ID，消费者姓名，地址，电话）
——此为“消费者”实体型的关系模式。
（2）支付账款（消费者ID，发票号，支付方式）
——此为联系“支付”所对应的关系模式。
（3）应收帐（消费者ID，发票号，支付日期）
——此为“应收帐”实体型对应的关系模式。
（4）订购（订单号，消费者ID）
——此为联系“订购”所对应的关系模式。
（5）订单（订单号，消费者ID，订货项数，订货日期，交货日期）
——此为“订单”实体型所对应的关系模式。
（6）参照（发票号，消费者ID）
——此为联系“参照”所对应的关系模式。
（7）发票（发票号，订单号，应收金额）
——此为“发票”实体型所对应的关系模式。
（8）订单细节（订单号，细则号，订货数，商品号，金额）
——此为“订单细节”实体型所对应的关系模式。
（9）包含（订单号，细则号，商品号）
——此为联系“包含”所对应的关系模式。
（10）商品（商品号，商品名，单价）
——此为“商品”实体型所对应的关系模式。
3.2数据模型的优化
规范化理论为数据库设计人员判断关系模式的优劣提供了理论标准，可以用来预测关系模式可能出现的问题，是数据库设计工作有严格的理论基础。
经过检验，可知以上10个关系模式都满足3NF。
而且因为这里设计的关系模式都比较简单，模式之间的关系也不太复杂，所以也不需要再进行分解等操作。
4、物理结构设计
4.1关系存取方法选择
存取方法是使事务能够快速存取数据库中数据的技术。
常用的存取方法有索引方法、Hash方法、聚簇方法等。
（1）如果一个属性经常在查询条件中出现，或者经常作为最大值和最小值等聚集函数的参数，或者经常在连接操作的连接条件中出现，则考虑在这个属性上建立索引。
但是，若一个关系的更新频率很高，这个关系上定义的索引数就不能太多。
因为更新一个关系时，这样的代价相当高。
（2）如果一个关系的属性主要出现在等值连接条件中或主要出现在相等比较选择条件中，而且一个关系的大小可预知且变化不大，则此关系可以选择Hash存取方法。
（3）当通过聚簇码进行访问或连接是该关系的主要应用，与聚簇码无关的其他访问很少或者是次要的时，可以使用聚簇。
尤其当SQL语句中包含有与聚簇码有关的ORDERBY,GROUPBY,UNION,DISTINCT等子句或短语时，使用聚簇特别有利，可以省去对结果集的排序操作。
由以上各种存取方法的特点可知，商品关系的更新会比较频繁，所以不适合建立索引，但是可以使用聚簇方法，将商品按类型排列，显示给顾客。
同样，对于订单的设计，也可以选择使用聚簇方法，当采购管理员查询订购登记系统中的订单时，就可以将订单信息按照订单号递增的显示，当然，订单的编号是与时间相关的，这样也方便订购管理员对订单进行添加和删除等操作。
5、数据库实施
5.1数据库的实现：
◆createtable消费者
（
消费者IDchar（10）primarykey,
密码char（20）notnull,
消费者姓名char（10）notnull,
地址char（20）notnull,
电话smallintnotnull
）
◆createtable支付账款
消费者IDchar（10）foreignkeyreferences消费者（消费者ID）,
发票号smallintforeignkeyreferences发票（发票号）,
支付方式char（10）notnull,
primarykey（消费者ID,发票号）,
constraintc1check（支付方式in（'
支票'
'
信用卡'
现金'
））
）
◆createtable发票
发票号smallintprimarykey,
订单号smallintforeignkeyreferences订单（订单号）,
应收金额smallint
◆createtable订单
订单号smallintprimarykey,
订货项数smallint,
订货日期datetime,
交货日期datetime
◆createtable应收帐
消费者IDchar（10）foreignkeyreferences消费者（消费者ID）,
支付日期datetime,
primarykey（消费者ID,发票号）
◆createtable订购
订单号smallintforeignkeyreferences订单（订单号）primarykey,
消费者IDchar（10）foreignkeyreferences消费者（消费者ID）
◆createtable参照
发票号smallintforeignkeyreferences发票（发票号）primarykey,
◆createtable订单细节
细则号smallint,
订货数smallint,
商品号smallintforeignkeyreferences商品（商品号）,
金额float（4）,
primarykey（订单号,细则号）
◆createtable商品
商品号smallintprimarykey,
商品名char（20）,
单价float（4）
◆createtable包含
5.2生成的关系表：
由对数据库的设计得到了10个表：
图9：
“消费者”表
这里不允许密码、消费者姓名、地址和电话为空，也就是要求用户在进行注册时必须填写这些项，这样使得后来的寄送订单等环节可行。
图10：
“支付账款”表
这里我们假设支付账款只能选择支票、信用卡或现金中的某种方式，在创建表的时候，进行约束：
））从而得到一个约束：
图11：
“支付账款”表的元组级限制
图12：
“应收帐”表
“应收帐”表中有一个属性“支付日期”，它应该是日期型或时间型，但是由于我使用的SQLServer2000不支持date数据类型，所以这里选用datetime数据类型。
图13：
“订购”表
图14：
“订单”表
图15：
“参照”表
图16：
“发票”表
图17：
“订单细节”表
图18：
“包含”表
图19：
“商品”表
5.3权限管理
数据库的安全性不容忽视，所以这里对用户权限进行了相应的设置。
为该系统设置的角色有：
超级管理员、一般用户、订购管理员、商品管理员、财务管理员、采购管理员等。
每个角色都有相应不同的权限。
下面只列举其中两个角色的权限：
图20：
一般用户的权限
图21：
订购管理员的权限
6、数据库运行与维护
6.1应用系统开发——用户注册模块的实现
本次课程设计只实现了其中的用户注册模块。
在顾客需要进行订购行为之前，需要注册用户的基本信息，包括登录用户名、登录密码、姓名、地址、电话等信息。
这样，在订购系统登记顾客的订购请求后，所产生的订单将会被寄给正确的顾客。
当然，在实现该模块之前，数据库中应该已经存在“消费者”这个表，这个模块只是向该表中插入一些合法的记录。
填写完“注册”中的每一项后，点击“确定”按钮，系统提示“注册成功”，这样系统已经将该用户的信息存入了数据库。
当然，由于“登录用户名”是“消费者”关系的主码，由该主码约束可知，当输入了一个与数据库中某条记录相同的用户名时，注册将不能成功。
这时系统会提示填入一个新的用户名。
为了检验该系统是否正确与数据库交互，我们打开SQLServer2000查询分析器，输入“select*from消费者”语句，执行后的结果为：
由此可见，用户通过“注册”注册的信息与我们直接在数据库中插入该条记录的结果是一样的。
每次有顾客正确注册之后，系统就会向“消费者”数据库中插入新的信息。
当然，应该有数据库管理员来维护这些信息。
6.2数据库的维护
数据库试运行合格后，数据库开发工作就基本完成。
但是，由于应用环境在不断变化，数据库运行过程中物理存储也会不断变化，所以就需要对数据库进行长期的维护工作。
DBA要针对不同的应用要求制定不同的转储计划，以保证一旦发生故障能尽快将数据库恢复到某种一致的状态，并尽可能减少对数据库的破坏。
而且，在数据库的运行过程中，对安全性的要求也会发生变化，比如有的数据原来是机密的，现在可以公开查询，而新加入的数据又可能是机密的。
这都需要DBA根据实际情况修改原有的安全性控制。
同样，数据库的完整性约束条件也会变化，也需要DBA不断修正，以满足用户要求。
数据库因为记录的不断增、删、改的操作，其物理存储情况会变坏，从而降低了数据的存取效率，数据库的性能也下降了。
这要求DBA对数据库进行重组织，或部分重组织。
在重组织过程中，按原设计要求重新安排存储位置、回收垃圾、减少指针链等，提高系统性能。
7、总结
通过设计客户订购登记系统，从需求分析开始，逐步的进行概念设计、逻辑设计、物理设计以及实现等，掌握了数据库系统设计的整个流程。
在设计过程中，首先将系统中的实体找出来，然后再建立系统的E-R图，这是概念结构设计的内容。
在逻辑设计中，将E-R图转换成关系模式，这里涉及到对联系的处理。
我们可以按照习惯将联系作为一个单独的关系模式，也可以将联系与n端对应的关系模式合并。
该设计中，就采用了这两种不同的方式。
物理设计主要是完成数据库在实际物理设备上的存储结构和存取方法的选取。
我选用了聚簇方法应用到订单和商品关系，这样，进行商品查询或订单查询时，就比较方便、也省去了对结果的再排序等麻烦。
而对系统中其他关系的存取方法的选取还有待研究。
由于对物理设计掌握的不够好，这里设计的也并不全面。
最后的实现中，用VC++和SQL实现了用户注册这个模块。
通过与数据库连接，可以在程序中对数据库中的表直接操作。
从而实现了将用户的注册信息插入数据库。
当然，由于是第一次进行数据库的设计，这次课程设计中也存在一些不足，比如说在设计用户注册时，由于数据库中的各属性都设置成了char型，“登录用户名”就没有被限制只能是字母、数字、下划线，且“电话”的值也可以是任意不超过20个字符的字符串，但是实际来说，这一项只能是数字或连接符。
这些都是需要改进的地方。
总的来说，通过对系统的设计，我对数据库设计的处理过程、对数据的分析、对SQL语言的运用等都有了进一步的掌握和提高。
参考文献：
《SQLServer实用教程（第三版）》....................................主编：
郑阿奇电子工业出版社
《C语言程序设计》...............................................................主编：
谭浩强
《软件工程导论》..................................................................主编：
张海藩清华大学出版社
《软件需求》..........................................................................主编：
刘晓辉电子工业出版社
WelcomeTo
Download!
!
欢迎您的下载，资料仅供参考！
升级会员 