数据库课程设计实验报告 联系客服

发布时间 : 星期日 文章数据库课程设计实验报告更新完毕开始阅读158105ff0242a8956bece4b6

物,为此数据库要记录订单的内容:客户名、支付方式、订购时间、订购的内容等。此外,处理订单的员工还应查询和处理用户的订单。处理完后需要把处理这个订单的员工信息存入数据库中。

@ 客户信息的查询:订单处理人员和发货人员在处理订单时。需要查询创建这个订单的客户的各类信息,以便在出现问题时及时与客户联系。

@ 库存不足时的替代功能:当订单处理人员处理订单时,如果出现溢出配件库存量的情况,应及时与客户联系,并采取以下措施之一:(1)按照现有的库存量发货,或者不发货;(2)按照客户的需求用其他货物来替代。

@ 商品的库存信息:为了在订单处理员处理客户订单时能够及时了解到公司当前的仓库中是否有足量的货物供应,应创建配件的库存信息表。此外公司有新货到来时或者有货源补充时应及时修改库存信息。

@ 商品的查看:用户在订购配件时,应该能够查询到库存信息表里那些配件可以订购(既库存量大于零的配件)。

二、深入分析

如果只按照以上的需求进行设计,时无法编写出可以投入使用的

应用程序的。因为在客户的需求称述里还有一些隐含的信息需要分析。具体如下:

5

1.用户权限分配和身份的识别

由于客户、工作人员使用的都是同一个应用程序系统(用户通过网络来登录到公司的订购系统),而客户、工作人员执行的功能是不同的,故需要提供一种机制区分用户和工作人员。系统需要识别当前登录到系统的用户,以便实现以下操作:

@ 如果是客户,则只能看到可以订购的配件列表、新建订单和查询订单的界面,而不能处理订单、查看和管理商品库存信息等; @ 如果是订单处理人员,则可以看到客户的信息、订单处理的界面,也可以看到配件的库存,但是不能新建订单,也不能随意修改商品的库存;

@ 如果是库存管理人员,则可以管理商品的库存信息,但是不能看用户的订单,也不能够创建订单;

@ 如果总管理员(例如公司经理),则可以查看和管理数据库中的各类数据。

对于同一种类的用户,系统也应该要记录登录到系统的用户名,以便实现以下操作:

@ 对于某一个客户,他应该可以查询到自己已经订购的订单,以

及能够及时查看这些订单的处理结果和状态,但是不能随意查看其他用户的订单;

@ 对于某个订单处理人员,在他处理完某一客户的订单后,系统

应根据用户登录时提供的信息自动在该订单的详情表内填写处理该订单的员工号,而不应该由用户填写员工号或者员工自己填写。

6

2.订单中应记录的内容

用户的需求中说明了需要记录的用户订购的配件、支付方式、处

理该订单的员工,但是经过分析之后发现订单信息表中还应该记录其他信息:

@ 订购某种配件的单价。这里记录的单价和“库存信息表”中记录的单价含义是不同的,库存信息表中的配件单价反映的是该种配件当前价格,而订单中记录的单价是购买时的单价。 @ 实际发货数量。由于在处理订单时的配件量不一定能满足客户的需求,故不一定可以提供用户其所订购的数量。当处理人员与客户联系后决定使用其他配件替换库存中不足的配件时,需要提供一种方法区分用户订购的配件和进行替代配件。 @ 订单状态。用户应该能及时查询自己的订单是否被处理,或者处理过之后已经发货。这是需要向客户提供状态信息。 由于已经记录了处理该订单的员工号以及负责发货的员工号,故不需要额外使用字段来存储这个状态。

3.商品库存的自动更新

当处理完一个客户的订单后,应该自动根据实际的发货数量立即更新配件的库存信息。具体为:订单处理信息提交后,自动更新库存信息表中对应配件的库存量。否则会出现配件被订购完后库存量没有更新,还显示此配件有库存的现象。

4.用户查看的配件列表和库存信息表的关系

7

用户看到的配件列表应该是建立在库存信息表上的一个视图。 在本项目中,库存信息表是一个基本表,存储了配件库存的实际数据;配件列表是从该基本表导出的视图,具体限制如下: @ 只显示当前有库存的配件:即Where子句的要求是该商品的库存量大于0;

@ 只能查看配件的编号、名称、单价和描述,不能看到配件的库存量。公司一般不希望用户能够随时得知商品的库存量,而只是提供给用户一个“有货”或者“无货”的标志。

三、需求分析

①基础信息管理:

1、厂商信息的管理:查询、增、删、改 2、配件信息的管理:查询、增、删、改 3、客户信息的管理:查询、增、删、改 ②进货管理:

4、配件采购信息的管理:查询、增、删、改 5、配件入库信息的管理:查询、增、删、改 ③销售管理:

6、车辆销售:客户可以根据自己的需求,选择不同型号的配件型 7、收益统计:厂商按照所出售的配件数量及价格进行统计 ④仓库管理:

8、库存配件:仓库管理员对已有配件进行详细管理

8