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

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

《客户订购登记系统课程设计.docx》由会员分享，可在线阅读，更多相关《客户订购登记系统课程设计.docx（25页珍藏版）》请在冰豆网上搜索。

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

资料范本

本资料为word版本，可以直接编辑和打印，感谢您的下载

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

地点：

__________________

时间：

__________________

说明：

本资料适用于约定双方经过谈判，协商而共同承认，共同遵守的责任与义务，仅供参考，文档可直接下载或修改，不需要的部分可直接删除，使用时请详细阅读内容

《网络数据库技术》

课程设计

题目客户订购登记系统

班级网络0904

学号310909050154

姓名袁建龙

指导老师彭维平

2012年12月22日

一．概述

1.1课程设计的目的

通过课程设计，使学生具备将数据库系统与现实世界密切、协调一致结合起来的能力，掌握数据库设计中的需求分析、概念设计、逻辑设计、物理设计的方法，并能够用具体的数据库和编程语言来解决实际的问题。

此外还要求学生具备实验结果分析、总结及撰写技术报告的能力。

1.2课程设计的内容

客户订购登记系统

现有一个公司希望为其客户订购行为建立一个数据库。

如果一个客户可以有一份或多份订单，每份订单可以订购一种或多种商品。

每份订单有一个发票，可以通过多种方式来支付，例如支票，信用卡或者现金。

处理这个客户订购登记的职工的名字要被记录下来。

部门工作人员负责整理订单并根据库存情况处理订单。

如果订单上的产品在库存中有，就可以直接发货，发货方式也有多种；如果订单上的产品在库存中没有，就不需要登记或者订购其它产品。

1.3课程设计的要求

1、根据题目查找资料及调研，写出数据库系统的需求分析报告；

2、根据需求分析，设计系统的功能结构，画出系统的功能结构图，设计的功能要全面、正确，能解决现实世界各类用户的实际需要；

3、根据需求分析，确定所设计的系统涉及到的实体、各实体的属性以及各实体之间的联系，用E-R图完成系统的概念模型设计，设计的概念模型要能全面、真实的反应现实世界，能满足系统功能的需要；

4、根据E-R图转换为DBMS支持的关系模型；

5、根据逻辑模型、系统环境和用户需求，设计数据库的物理结构。

6、采用B/S模式，使用Java、ASP、JSP、PHP或ASP.NET程序设计语言之一进行相应前台主要模块和菜单的设计，选择Mysql、Oracle或者SQLServer数据库作为后台服务器。

7、设计一组数据库表的测试实例，对各项功能进行简单的测试并写出测试结果。

二．需求分析

2.1系统需求

客户订购登记数据流图

客户实体的描述属性有：

客户编号，客户名，邮编，电话号，传真号，银行帐号。

产品实体的描述属性有：

产品编号，产品名，型号，规格，单价，重量。

订单实体的描述属性有：

订单编号，客户编号，订货日期，交货日期，发货方式编号，职工编号，执行状态。

订单细节实体的描述属性有：

订单编号，产品编号，订货数量。

发票实体的描述属性有：

发票编号，开票日期，付款日期，订单编号，客户编号，付款方式编号。

发货实体的描述属性有：

发货编号，订单编号，产品编号，数量，发货日期，发货方式编号，完成状态，职工编号。

职工实体的描述属性有：

职工编号，姓名，性别，出生年月，地址，办公电话，住宅电话，EMAIL，职务，职称。

付款方式实体的描述属性有：

付款方式编号，付款方式。

发货方式实体的描述属性有：

发货方式编号，发货方式。

2.2数据字典

（一）客户表

（二）产品表

（三）订单表

（四）订单细节表

（五）发票表

（六）发货表

（七）职工信息表

（八）付款方式表

（九）发货方式表三．系统总体设计

3.1.系统总体设计思路

3.2概念模型设计

3.2.1局部E-R图

客户实体和订单实体通过提交订单发生联系。

每个客户可以提交多份订单，而每份订单只对应一个客户。

因此，客户实体和订单实体之间是一对多联系，如图所示。

产品实体和订单细节实体通过订购产品发生联系。

每个订单细节可以订购一种产品，而每种产品可以被不同的订单订购。

因此，产品实体和订单细节实体之间是一对多联系，如图所示。

订单细节实体是订单实体的组成部分，故必存在联系。

一份订单可以订购多种产品，也就是可以有多个订单细节，而每个订单细节只对应一份订单。

因此，订单实体和订单细节实体之间是一对多联系，如图所示。

职工实体通过处理订单和订单实体发生联系。

每个职工可以处理多份订单，而每份订单只能由一个职工处理。

因此，职工实体和订单实体之间是一对多联系，如图所示。

付款方式是发票的组成部分，故必存在联系。

每张发票对应一种付款方式，而每种付款方式可以用于不同的发票中。

因此，付款方式实体和发票实体之间是一对多联系，如图所示。

发货实体与订单细节实体通过发货打包发生联系。

每个订单细节对应多次发货，而每次发货只对应一个订单细节。

因此，发货实体和订单细节实体之间是一对多联系，如图所示。

发货方式是发货的组成部分，故必存在联系。

每个发货对应一种发货方式，而每种发货方式可以用于不同的发货中。

因此，发货方式实体和发货实体之间是一对多联系，如图所示

订单实体和发票实体通过开具发票发生联系。

每份订单开具一张发票，而每张发票也只对应一份订单。

因此，订单实体和发票实体之间是一对一联系，如图所示。

3.2.2全局E-R图

3.3逻辑结构设计

客户（客户编号，客户名，邮编，电话号，传真号，银行帐号）

主键：

客户编号。

候补键：

电话号，传真号，银行帐号。

函数依赖集F：

客户编号→{客户名，邮编，电话号，传真号，银行帐号}，

电话号→{客户编号，邮编，传真号，银行帐号}，

传真号→{客户编号，客户名，邮编，电话号，银行帐号}，

银行帐号→{客户编号，客户名，邮编，电话号，传真号}

虽然，客户编号→电话号，电话号→传真号，但由于电话号→客户编号也成立，所以，客户编号→传真号不是传递函数依赖。

客户关系中不存在非主属性与候选键之间的部分与传递函数依赖，所以客户关系满足第3范式。

产品（产品编号，产品名，型号，规格，单价，重量）

主键：

产品编号。

函数依赖集F：

产品编号→{产品名，型号，规格，单价，重量}。

产品关系不存在非主属性与候选键之间的部分与传递函数依赖，所以产品关系满足第3范式。

订单（订单编号，客户编号，订货日期，交货日期，发货方式编号，职工编号，执行状态）

主键：

订单编号。

外键：

客户编号，引用了客户关系中的客户编号；

发货方式编号，引用了发货方式关系中的发货方式编号；

职工编号，引用了职工关系中的职工编号。

函数依赖集F：

订单编号→{客户编号，订货日期，交货日期，发货方式编号，职工编号，执行状态}。

订单关系中不存在非主属性与候选键之间的部分与传递函数依赖，所以订单关系满足第3范式。

订单细节（订单编号，产品编号，订货数量）

主键：

订单编号＋产品编号。

函数依赖集F：

{订单编号，产品编号}→订货数量。

订单细节关系中不存在非主属性与候选键之间的部分与传递函数依赖，所以订单细节关系满足第3范式。

发票（发票编号，开票日期，付款日期，订单编号，

客户编号，付款方式编号）

主键：

发票编号。

候选键：

订单编号。

外键：

订单编号，引用了订单关系中的订单编号；

客户编号，引用了客户关系中的客户编号；

付款方式编号，引用了付款方式关系中的付款方式编号。

函数依赖集F：

发票编号→{开票日期，付款日期，订单编号，客户编号，付款方式编号}，

订单编号→{发票编号，开票日期，付款日期，客户编号，付款方式编号}。

发票关系中不存在非主属性与候选键之间的部分与传递函数依赖，所以发票关系满足第3范式。

发货（发货编号，数量，发货日期，订单编号，

产品编号，发货方式编号，完成状态，职工编号）

主键：

发货编号。

外键：

订单编号，引用了订单关系中的订单编号；

产品编号，引用了产品关系中的产品编号；

发货方式编号，引用了发货方式关系中的发货方式编号。

函数依赖集F：

发货编号→{数量，发货日期，订单编号，产品编号，发货方式编号，完成状态，职工编号}。

发货关系中不存在非主属性与候选键之间的部分与传递函数依赖，所以发货关系满足第3范式。

职工（职工编号，姓名，性别，出生年月，地址，办公电话，住宅电话，EMAIL，职务，职称）

主键：

职工编号。

候选键：

EMAIL。

函数依赖集F：

职工编号→{姓名，性别，出生年月，地址，办公电话，住宅电话，EMAIL，职务，职称}，

EMAIL→{职工编号，姓名，性别，出生年月，地址，办公电话，住宅电话，职务，职称}。

职工关系中不存在非主属性与候选键之间的部分与传递函数依赖，所以职工关系满足第3范式。

付款方式（付款方式编号，付款方式）

主键：

付款方式编号。

函数依赖集F：

付款方式编号→付款方式。

付款方式关系满足第3范式。

发货方式（发货方式编号，发货方式）

主键：

发货方式编号。

函数依赖集F：

发货方式编号→发货方式。

发货方式关系满足第3范式。

所有关系都满足较高的范式要求，故客户订购登记管理的数据库设计是合理的。

3.4数据库建立实施

3.4.1建立数据库

CREATEDATABASE`customer_db`;

USE`customer_db`;

3.4.2建立关系表

建立账单表：

CREATETABLE`t_bill`（

`bill_id`int（11）NOTNULLAUTO_INCREMENTCOMMENT'发票编号',

`raiseddate`timestampNOTNULLDEFAULTCURRENT_TIMESTAMPONUPDATECURRENT_TIMESTAMPCOMMENT'开票日期',

`paydate`timestampNOTNULLDEFAULT'0000-00-0000:

00:

00'COMMENT'付款日期',

`o_id`int（11）NOTNULLCOMMENT'订单编号',

`c_id`int（11）NOTNULLCOMMENT'客户编号',

`pay_id`int（11）NOTNULLCOMMENT'付款方式编号',

PRIMARYKEY（`bill_id`）,

KEY`fk_bill_order`（`o_id`）,

KEY`fk_bill_customer`（`c_id`）,

KEY`fk_bill_pay`（`pay_id`）,

CONSTRAINT`fk_bill_customer`FOREIGNKEY（`c_id`）REFERENCES`t_customer`（`id`）,

CONSTRAINT`fk_bill_order`FOREIGNKEY（`o_id`）REFERENCES`t_order`（`id`）,

CONSTRAINT`fk_bill_pay`FOREIGNKEY（`pay_id`）REFERENCES`t_pay`（`id`）

）ENGINE=InnoDBDEFAULTCHARSET=utf8;

建立客户表：

CREATETABLE`t_customer`（

`id`int（11）NOTNULLAUTO_INCREMENTCOMMENT'客户编号',

`name`varchar（20）NOTNULLCOMMENT'姓名',

`z