客户订购登记系统课程设计

1/31《网络数据库技术》课程设计题目客户订购登记系统班级网络0904学号310909050154姓名袁建龙指导老师彭维平2012年12月22日2/31目录一、概述..........................................31.1课程设计的目的................................31.2课程设计的内容................................31.3课程设计的要求................................4二、需求分析......................................52.1系统需求.....................................52.2数据字典.....................................7三、系统总体设计...................................93.1系统总体设计思路..............................93.2概念模型设计.................................103.2.1局部E-R图.............................103.2.2全局E-R图.............................143.3逻辑结构设计.................................143.4数据库建立实施...............................193.4.1建立数据库.............................193.4.2建立关系表.............................19四、系统实现.....................................25五、系统评价.....................................27六、课程设计心得、总结............................28参考文献：......................................293/31一．概述1.1课程设计的目的通过课程设计，使学生具备将数据库系统与现实世界密切、协调一致结合起来的能力，掌握数据库设计中的需求分析、概念设计、逻辑设计、物理设计的方法，并能够用具体的数据库和编程语言来解决实际的问题。此外还要求学生具备实验结果分析、总结及撰写技术报告的能力。1.2课程设计的内容客户订购登记系统现有一个公司希望为其客户订购行为建立一个数据库。如果一个客户可以有一份或多份订单，每份订单可以订购一种或多种商品。每份订单有一个发票，可以通过多种方式来支付，例如支票，信用卡或者现金。处理这个客户订购登记的职工的名字要被记录下来。部门工作人员负责整理订单并根据库存情况处理订单。如果订单上的产品在库存中有，就可以直接发货，发货方式也有多种；如果订单上的产品在库存中没有，就不需要登记或者订购其它产品。4/311.3课程设计的要求1、根据题目查找资料及调研，写出数据库系统的需求分析报告；2、根据需求分析，设计系统的功能结构，画出系统的功能结构图，设计的功能要全面、正确，能解决现实世界各类用户的实际需要；3、根据需求分析，确定所设计的系统涉及到的实体、各实体的属性以及各实体之间的联系，用E-R图完成系统的概念模型设计，设计的概念模型要能全面、真实的反应现实世界，能满足系统功能的需要；4、根据E-R图转换为DBMS支持的关系模型；5、根据逻辑模型、系统环境和用户需求，设计数据库的物理结构。6、采用B/S模式，使用Java、ASP、JSP、PHP或ASP.NET程序设计语言之一进行相应前台主要模块和菜单的设计，选择Mysql、Oracle或者SQLServer数据库作为后台服务器。7、设计一组数据库表的测试实例，对各项功能进行简单的测试并写出测试结果。5/31二．需求分析2.1系统需求客户订购登记数据流图客户实体的描述属性有：客户编号，客户名，邮编，电话号，传真号，银行帐号。产品实体的描述属性有：产品编号，产品名，型号，规格，单价，重量。订单实体的描述属性有：订单录入订单产品发票订单开发票发货处理发货台帐客户信息员工6/31订单编号，客户编号，订货日期，交货日期，发货方式编号，职工编号，执行状态。订单细节实体的描述属性有：订单编号，产品编号，订货数量。发票实体的描述属性有：发票编号，开票日期，付款日期，订单编号，客户编号，付款方式编号。发货实体的描述属性有：发货编号，订单编号，产品编号，数量，发货日期，发货方式编号，完成状态，职工编号。职工实体的描述属性有：职工编号，姓名，性别，出生年月，地址，办公电话，住宅电话，EMAIL，职务，职称。付款方式实体的描述属性有：付款方式编号，付款方式。发货方式实体的描述属性有：发货方式编号，发货方式。7/312.2数据字典(一)客户表(二)产品表(三)订单表8/31(四)订单细节表(五)发票表(六)发货表(七)职工信息表9/31(八)付款方式表(九)发货方式表三．系统总体设计3.1.系统总体设计思路10/313.2概念模型设计3.2.1局部E-R图客户实体和订单实体通过提交订单发生联系。每个客户可以提交多份订单，而每份订单只对应一个客户。因此，客户实体和订单实体之间是一对多联系，如图所示。产品实体和订单细节实体通过订购产品发生联系。每个订单细节可以订购一种产品，而每种产品可以被不同的订单订购。因此，产品实体和订单细节实体之间是一对多联系，如图所示。客户订单提交（1:1）（1:N）客户订单客户编号[PK]订单编号[PK]1..11..*提交订单编号客户编号产品订单细节订购（1:1）（1:N）产品订单细节产品编号[PK]订单编号[PK]产品编号[PK]1..11..*订购订单编号产品编号产品编号11/31订单细节实体是订单实体的组成部分，故必存在联系。一份订单可以订购多种产品，也就是可以有多个订单细节，而每个订单细节只对应一份订单。因此，订单实体和订单细节实体之间是一对多联系，如图所示。职工实体通过处理订单和订单实体发生联系。每个职工可以处理多份订单，而每份订单只能由一个职工处理。因此，职工实体和订单实体之间是一对多联系，如图所示。订单订单细节有（1:1）（1:N）订单订单细节订单编号[PK]订单编号[PK]产品编号[PK]1..11..*有订单编号订单编号产品编号职工订单处理（1:1）（1:N）职工订单职工编号[PK]订单编号[PK]1..11..*处理订单编号职工编号12/31付款方式是发票的组成部分，故必存在联系。每张发票对应一种付款方式，而每种付款方式可以用于不同的发票中。因此，付款方式实体和发票实体之间是一对多联系，如图所示。发货实体与订单细节实体通过发货打包发生联系。每个订单细节对应多次发货，而每次发货只对应一个订单细节。因此，发货实体和订单细节实体之间是一对多联系，如图所示。付款方式发票付款（1:1）（1:N）付款方式发票付款方式编号[PK]发票编号[PK]1..11..*付款发票编号付款方式编号订单细节发货打包（1:1）（1:N）订单细节发货订单编号[PK]产品编号[PK]发货编号[PK]1..11..*打包发货编号订单编号产品编号13/31发货方式是发货的组成部分，故必存在联系。每个发货对应一种发货方式，而每种发货方式可以用于不同的发货中。因此，发货方式实体和发货实体之间是一对多联系，如图所示订单实体和发票实体通过开具发票发生联系。每份订单开具一张发票，而每张发票也只对应一份订单。因此，订单实体和发票实体之间是一对一联系，如图所示。发货方式发货发货（1:1）（1:N）发货方式发货发货方式编号[PK]发货编号[PK]1..11..*发货发货编号发货方式编号订单发票开出（1:1）（1:1）订单发票订单编号[PK]发票编号[PK]1..11..1开出发票编号订单编号14/313.2.2全局E-R图3.3逻辑结构设计客户（客户编号，客户名，邮编，电话号，传真号，银行帐号）主键：客户编号。候补键：电话号，传真号，银行帐号。函数依赖集F：客户编号{客户名，邮编，电话号，传真号，银行帐号}，电话号{客户编号，邮编，传真号，银行帐号}，传真号{客户编号，客户名，邮编，电话号，银行帐号}，银行帐号{客户编号，客户名，邮编，电话号，传真号}产品订单细节订购（1:1）（1:N）订单编号产品编号订单有（1:1）（1:N）订单编号产品编号发货打包（1:1）（1:N）发货编号发货方式发货（1:1）（1:N）发货方式编号客户提交客户编号（1:1）（1:N）职工处理（0:N）（1:1）发票开出（1:1）（1:1）付款方式付款（1:1）（1:N）15/31虽然，客户编号电话号，电话号传真号，但由于电话号客户编号也成立，所以，客户编号传真号不是传递函数依赖。客户关系中不存在非主属性与候选键之间的部分与传递函数依赖，所以客户关系满足第3范式。产品（产品编号，产品名，型号，规格，单价，重量）主键：产品编号。函数依赖集F：产品编号{产品名，型号，规格，单价，重量}。产品关系不存在非主属性与候选键之间的部分与传递函数依赖，所以产品关系满足第3范式。订单（订单编号，客户编号，订货日期，交货日期，发货方式编号，职工编号，执行状态）主键：订单编号。外键：客户编号，引用了客户关系中的客户编号；发货方式编号，引用了发货方式关系中的发货方式编号；职工编号，引用了职工关系中的职工编号。函数依赖集F：订单编号{客户编号，订货日期，交货日期，发货方式编号，职工编号，执行状态}。16/31订单关系中不存在非主属性与候选键之间的部分与传递函数依赖，所以订单关系满足第3范式。订单细节（订单编号，产品编号，订货数量）主键：订单编号＋产品编号。函数依赖集F：{订单编号，产品编号}订货数量。订单细节关系中不存在非主属性与候选键之间的部分与传递函数依赖，所以订单细节关系满足第3范式。发票（发票编号，开票日期，付款日期，订单编号，客户编号，付款方式编号）主键：发票编号。候选键：订单编号。外键：订单编号，引用了订单关系中的订单编号；客户编号，引用了客户关系中的客户编号；付款方式编号，引用了付款方式关系中的付款方式编号。函数依赖集F：发票编号{开票日期，付款日期，订单编号，客户编号，付款方式编号}，17/31订单编号{发票编号，开票日期，付款日期，客户编号，付款方式编号}。发票关系中不存在非主属性与候选键之间的部分与传递函数依赖，所以发票关系满足第3范式。发货（发货编号，数量，发货日期，订单编号，产品编号，发货方式编号，完成状态，职工编号）主键：发货编号。外键：订单编号，引用了订单关系中的订单编号；产品编号，引用了产品关系中的产品编号；发货方式编号，引用了发货方式关系中的发货方式编号。函数依赖集F：发货编号{数量，发货日期，订单编号，产品编号，发货方式编号，完成状态，职工编号}。发货关系中不存在非主属性与候选键之间的部分与传递函数依赖，所以发货关系满足第3范式。职工（职工编号，姓名，性别，出生年月，地址，办公电话，住宅电话，EMAIL，职务，职称）主键：职工编号。候选键：EMAIL。18/31函数依赖集F：职工编号{姓名，性别，出生年月，地址，办公电话，住宅电话，EMAIL，职务，职称}，EMAIL{职工编号，姓名，性别，出生年月，地址，办公电话，住宅电话，职务，职称}。职工关系中不存在非主属性与候选键之间的部分与传递函数依赖，所以职工关系满足第3范式。付款方式（付款方式编号，付款方式）主键：付款方式编号。函数依赖集F：付款方式编号付款方式。付款方式关系满足第3范式。发货方式（发货方式编号，发货方式）主键：发货方式编号。函数依赖集F：发货方式编号发货方式。发货方式关系满足第3范式。所有关系都满足较高的范式要求，故客户订购登记管理的数据库设计是合理