《客户订购登记系统课程设计》由会员分享，可在线阅读，更多相关《客户订购登记系统课程设计（28页珍藏版）》请在金锄头文库上搜索。
1、网络数据库技术课 程 设 计题 目 客户订购登记系统班 级 网络学 号 姓 名 袁建龙指导老师 彭维平年月 日目 录一、概述 课程设计的目的 课程设计的内容 课程设计的要求二、需求分析 系统需求 数据字典三、系统总体设计系统总体设计思路 概念模型设计 局部图 全局图 逻辑结构设计 数据库建立实施 建立数据库 建立关系表四、系统实现五、系统评价六、课程设计心得、总结参考文献：一概述课程设计的目的通过课程设计，使学生具备将数据库系统与现实世界密切、协调一致结合起来的能力，掌握数据库设计中的需求分析、概念设计、逻辑设计、物理设计的方法，并能够用具体的数据库和编程语言来解决实际的问题。此外还要求学生具
2、备实验结果分析、总结及撰写技术报告的能力。课程设计的内容客户订购登记系统 现有一个公司希望为其客户订购行为建立一个数据库。 如果一个客户可以有一份或多份订单，每份订单可以订购一种或多种商品。每份订单有一个发票，可以通过多种方式来支付，例如支票，信用卡或者现金。处理这个客户订购登记的职工的名字要被记录下来。 部门工作人员负责整理订单并根据库存情况处理订单。如果订单上的产品在库存中有，就可以直接发货，发货方式也有多种；如果订单上的产品在库存中没有，就不需要登记或者订购其它产品。课程设计的要求、根据题目查找资料及调研，写出数据库系统的需求分析报告；、根据需求分析，设计系统的功能结构，画出系统的功能结
3、构图，设计的功能要全面、正确，能解决现实世界各类用户的实际需要；、根据需求分析，确定所设计的系统涉及到的实体、各实体的属性以及各实体之间的联系，用图完成系统的概念模型设计，设计的概念模型要能全面、真实的反应现实世界，能满足系统功能的需要；、根据图转换为支持的关系模型；、根据逻辑模型、系统环境和用户需求，设计数据库的物理结构。、采用模式，使用、或程序设计语言之一进行相应前台主要模块和菜单的设计，选择、或者数据库作为后台服务器。、设计一组数据库表的测试实例，对各项功能进行简单的测试并写出测试结果。二需求分析系统需求客户订购登记数据流图客户实体的描述属性有：客户编号，客户名，邮编，电话号，传真号，银
4、行帐号。产品实体的描述属性有：产品编号，产品名，型号，规格，单价，重量。订单实体的描述属性有：订单编号，客户编号，订货日期，交货日期，发货方式编号，职工编号，执行状态。订单细节实体的描述属性有：订单编号，产品编号，订货数量。发票实体的描述属性有：发票编号，开票日期，付款日期，订单编号，客户编号，付款方式编号。发货实体的描述属性有：发货编号，订单编号，产品编号，数量，发货日期，发货方式编号，完成状态，职工编号。职工实体的描述属性有：职工编号，姓名，性别，出生年月，地址，办公电话，住宅电话，职务，职称。付款方式实体的描述属性有：付款方式编号，付款方式。 发货方式实体的描述属性有：发货方式编号，发货
5、方式。数据字典(一)客户表(二)产品表(三)订单表(四)订单细节表(五)发票表(六)发货表(七)职工信息表(八)付款方式表(九)发货方式表三系统总体设计.系统总体设计思路概念模型设计局部图客户实体和订单实体通过提交订单发生联系。每个客户可以提交多份订单，而每份订单只对应一个客户。因此，客户实体和订单实体之间是一对多联系，如图所示。产品实体和订单细节实体通过订购产品发生联系。每个订单细节可以订购一种产品，而每种产品可以被不同的订单订购。因此，产品实体和订单细节实体之间是一对多联系，如图所示。订单细节实体是订单实体的组成部分，故必存在联系。一份订单可以订购多种产品，也就是可以有多个订单细节，而每个
6、订单细节只对应一份订单。因此，订单实体和订单细节实体之间是一对多联系，如图所示。职工实体通过处理订单和订单实体发生联系。每个职工可以处理多份订单，而每份订单只能由一个职工处理。因此，职工实体和订单实体之间是一对多联系，如图所示。 付款方式是发票的组成部分，故必存在联系。每张发票对应一种付款方式，而每种付款方式可以用于不同的发票中。因此，付款方式实体和发票实体之间是一对多联系，如图所示。发货实体与订单细节实体通过发货打包发生联系。每个订单细节对应多次发货，而每次发货只对应一个订单细节。因此，发货实体和订单细节实体之间是一对多联系，如图所示。发货方式是发货的组成部分，故必存在联系。每个发货对应一种
7、发货方式，而每种发货方式可以用于不同的发货中。因此，发货方式实体和发货实体之间是一对多联系，如图所示订单实体和发票实体通过开具发票发生联系。每份订单开具一张发票，而每张发票也只对应一份订单。因此，订单实体和发票实体之间是一对一联系，如图所示。全局图逻辑结构设计客户（客户编号，客户名，邮编，电话号，传真号，银行帐号）主键：客户编号。候补键：电话号，传真号，银行帐号。函数依赖集：客户编号客户名，邮编，电话号，传真号，银行帐号，电话号客户编号，邮编，传真号，银行帐号，传真号客户编号，客户名，邮编，电话号，银行帐号，银行帐号客户编号，客户名，邮编，电话号，传真号虽然，客户编号电话号，电话号传真号，但由
8、于电话号客户编号也成立，所以，客户编号传真号不是传递函数依赖。 客户关系中不存在非主属性与候选键之间的部分与传递函数依赖，所以客户关系满足第范式。 产品（产品编号，产品名，型号，规格，单价，重量）主键：产品编号。函数依赖集：产品编号产品名，型号，规格，单价，重量。 产品关系不存在非主属性与候选键之间的部分与传递函数依赖，所以产品关系满足第范式。 订单（订单编号，客户编号，订货日期，交货日期，发货方式编号，职工编号，执行状态）主键：订单编号。外键：客户编号，引用了客户关系中的客户编号；发货方式编号，引用了发货方式关系中的发货方式编号；职工编号，引用了职工关系中的职工编号。函数依赖集：订单编号客户
9、编号，订货日期，交货日期，发货方式编号，职工编号，执行状态。 订单关系中不存在非主属性与候选键之间的部分与传递函数依赖，所以订单关系满足第范式。 订单细节（订单编号，产品编号，订货数量）主键：订单编号产品编号。函数依赖集：订单编号，产品编号订货数量。 订单细节关系中不存在非主属性与候选键之间的部分与传递函数依赖，所以订单细节关系满足第范式。发票（发票编号，开票日期，付款日期，订单编号，客户编号，付款方式编号）主键：发票编号。候选键：订单编号。外键：订单编号，引用了订单关系中的订单编号；客户编号，引用了客户关系中的客户编号；付款方式编号，引用了付款方式关系中的付款方式编号。函数依赖集：发票编号开
10、票日期，付款日期，订单编号，客户编号，付款方式编号，订单编号发票编号，开票日期，付款日期，客户编号，付款方式编号。 发票关系中不存在非主属性与候选键之间的部分与传递函数依赖，所以发票关系满足第范式。发货（发货编号，数量，发货日期，订单编号，产品编号，发货方式编号，完成状态，职工编号）主键：发货编号。外键：订单编号，引用了订单关系中的订单编号；产品编号，引用了产品关系中的产品编号；发货方式编号，引用了发货方式关系中的发货方式编号。函数依赖集：发货编号数量，发货日期，订单编号，产品编号，发货方式编号，完成状态，职工编号。 发货关系中不存在非主属性与候选键之间的部分与传递函数依赖，所以发货关系满足第
11、范式。 职工（职工编号，姓名，性别，出生年月，地址，办公电话，住宅电话，职务，职称）主键：职工编号。候选键：。函数依赖集：职工编号姓名，性别，出生年月，地址，办公电话，住宅电话，职务，职称，职工编号，姓名，性别，出生年月，地址，办公电话，住宅电话，职务，职称。 职工关系中不存在非主属性与候选键之间的部分与传递函数依赖，所以职工关系满足第范式。 付款方式（付款方式编号，付款方式）主键：付款方式编号。函数依赖集：付款方式编号付款方式。 付款方式关系满足第范式。发货方式（发货方式编号，发货方式）主键：发货方式编号。函数依赖集：发货方式编号发货方式。 发货方式关系满足第范式。 所有关系都满足较高的范式
12、要求，故客户订购登记管理的数据库设计是合理的。数据库建立实施 建立数据库 ; ; 建立关系表建立账单表： ( () 发票编号, 开票日期, 付款日期, () 订单编号, () 客户编号, () 付款方式编号, (), (), (), (), () (), () (), () () ;建立客户表： ( () 客户编号, () 姓名, () 邮编, () 电话, () 传真, () 银行帐号, () ;建立职工表： ( () 职工编号, () 姓名, () 性别, 出生日期, () 地址, () 办公电话, () 住宅电话, () 邮箱, () 职位, () 职称, () ;建立订单表： ( () 订单编号, () 客户编号哦, 订货日期, 交货日期, () 发货方式编号, () 职工编号, () 执行状态, (), (), (), (), () (), () (), () () ;建立订单细节表： ( () 订单号, () 产品号, () 订货数量, (,) ;建立付款表： ( () 付款
