进销存管理系统数据库设计.docx

资源描述

进销存管理系统数据库设计.docx

《进销存管理系统数据库设计.docx》由会员分享，可在线阅读，更多相关《进销存管理系统数据库设计.docx（29页珍藏版）》请在冰豆网上搜索。

进销存管理系统数据库设计.docx

进销存管理系统数据库设计

1．需求分析报告

1.1系统目的

随着社会的进步和计算机的不断普及，各行各业的管理、控制都越来越离不开计算机的辅助。

"*进销存管理系统〞的开发就是为了辅助大多数企业的根本管理，实现信息管理的系统化、标准化和自动化简化人们日常工作中的大量机械重复的操作，使一些过程繁琐且数据量大的工作得已高效的进展，进销存管理系统还可以通过对数据的有效控制，实现对工作流层的控制、协调，从而提高企业的竞争力。

1.2进销存系统的数据需求

〔1〕商品按类别和名称进展管理。

〔2〕必须记录商品的根本信息，比方规格和生产企业等。

〔3〕需要记录商品的供给信息。

〔4〕供给商的联系方式非常重要。

〔5〕在采购信息中需要记录采购的数量和单价等。

〔6〕在采购信息中要包含登记商品销售数量，单价等信息。

〔7〕商品销售信息要有报损原因。

〔8〕所以单据必须记录相应的经手人和相应的时间。

〔9〕采购，销售，报损信息都可以进展添加，删除，修改，查找，统计，等操作。

〔10〕当进展进货，销售和报销操作后，能相应更改库存。

〔11〕需要对进货，销售，库存，报损等操作生成相应的报表。

1.3组织结合构造图

根据系统及公司实际情况绘出组织构造图如下.

图表1组织结合构造图

总经理:

负责实施公司总体战略。

副经理:

协助总经理完成具体完成各项事物.

采购部:

负责缺货时向外采购商品及完成相应货物进货统计.完成进货信息的登记,修改,和删除等.

销售部:

向外出售商品及完成相应出售商品的统计.完成进货信息的登记,修改,和删除等.

维护部:

完成商品信息的登记,修改,和删除等.及各项商品信息的维护工作.

1.4功能模块图

根据上述系统功能的需求分析，按照构造化程序设计的要求，得到如下所示的系统功能模块图，如图

图表2功能模块图

1.5业务流程图

图表3业务流程图

1.6数据流程图

数据流程图顶层图

分析：

该图简单的包含两个外部实体分别为顾客和供给商，主要业务分为两个，销售和采购。

顾客查询商品资料信息，订购后收到付款通知进展付款交易。

销售部接收到定货单，然后进展库存查询是否有货。

有货则向顾客发货,无货则向供给商下定货单.从下列图可看出没有反映帐务，而且销售和采购没有分开表示，但是高度概括地反映了进销存业务，因此要进一步扩展出更详细的数据流程图。

图4数据流程图DFD

1.6.2数据流程图第一层

分析:

顾客先通过查看商品信息来获取自己想要的商品然后向公司下定单.销售部受到上级的定货单查看库存情况.有货就向仓库下提货单发货.仓库收到提货单反应出货单给销售部，销售部下发货单给顾客。

如果缺货则向供货商下班定货单采购。

到货之后采购部发出到货通知反应销售部。

同时采购部发入库单货物入库。

在货物入库与仓库货物出库过程中报损部进展检查。

有物品损失的生成报损单。

图表5数据吧流程图第一层

数据流程图第二层

分析：

客户发出订货单。

根据订货单的订货数量发聩给仓库查询货物库存信息。

判定是否缺货。

如果缺货则显示出缺货数量并生成缺货订购单。

在到货之后进展到货处理发将可发货单存档然后进展发货管理。

发货单锅里过程中生成提货单，出货单，报损单和发货单台帐到货处理过程中生成报损记录生成报损单。

最后向顾客发出发货单。

图表6数据流程图第三层

（1）第二层销售模块

分析：

客户发出订货单。

根据订货单的订货数量发聩给仓库查询货物库存信息。

判定是否缺货。

在到货之后进展到货处理发将可发货单存档然后进展发货管理。

发货单锅里过程中生成提货单，出货单，

〔2〕第二层采购模块

分析：

如果缺货生成请购台帐且显示出缺货数量并生成缺货订购单。

向供货商发订购单供货商收到订购单处理后发出发货单。

之后采购部进展到货处生成到货通知给仓库。

〔3〕第二层报损模块

分析：

仓库进货出货过程中检查过程中生成报损记录上报报损部另一方面顾客上报维修单生成报损记录再汇总到报损部。

由报损部生成报损报表。

1.7数据字典

1.7.1.数据项定义

编号

名称

别名

数据类型

是否可空

长度

简述

商品名称

商品名

Char

NULLull

*种商品的名字

商品编号

商品编码

Char

NULL

*种商品的代码

商品数量

商品个数

INULLT

NULL

*种商品的容量

商品单价

商品价钱

float

NULL

*种商品进货单价

商品日期

DateTime

NULL

*商品的日期

供给商名称

Char

NULL

*供给商的名字

供给商地址

Char

NULL

*供给商的地址

顾客姓名

顾客名称

Char

NULL

*顾客的姓名

顾客地址

Char

NULL

*顾客的地址

B10

部门名称

Char

NULL

公司*部门的名称

B11

经理名称

经理姓名

Char

NULL

公司部门经理名字

B12

库存量

商品库存

INULLT

NULL

商品的库存数量

B13

员工名称

Char

NULL

公司员工的名称

B14

顾客号码

号码

INULLT

NULL

*顾客的号码

B15

订货单编码

订货单编号

Char

NULL

*订货单的编号

B16

发货单编码

发货单编号

Char

NULL

*发货单的编号

B17

到货通知编码

Char

NULL

*商品到货通知编号

B18

报损表编号

商品报损表编号

Char

NULL

*商品报损表编号

B19

销售历史表编号

商品销售表编号

Char

NULL

*商品销售表编号

1.7.2、数据流定义

编号

名称

简介

数据流组成

数据流来源

数据流去向

数据流量

订货单

顾客开出的订货单

B1+B2+B3+B15

顾客

编辑订货单模块

10份/时

发货单

已确定的发货货单

B1+B2+B3+B4+B16

开发货单修改库存模块

顾客

100份/时

到货通知

顾客收到商品到货通知

B1+B2+B3+B4+B6+ID17

采购员

对照暂存定货单模块

10份/天

订货单

公司向供给商采购订货单

B1+B2+B3+B4+B6

公司采购部门

供给商

100份/天

到货通知

采购部门收到商品到货通知

B1+B2+B3+B4+B6+B10

产生到货通知模块

公司采购部门

10份/天

报损表

顾客及部门商品报损表

B1+B2+B3+B4+B6+B18

顾客、销售采购部门

售后效劳维修部门

100份/天

1.7.3、数据存储定义

编号

名称

简述

数据存储组成

关键字

相关属性列表：

实体

属性

销售部

部门号

销售员

工号、、性别。

商品

商品名称，编号，生产规格，数量，单价，商品类别，生产企业

客户

、性别、联系方式、客户编号、。

仓库管理员

工号、、性别。

订货单

商品名称、订单号、数量、单价、日期、销售员

联系

属性

销售

下达订单

商品编号，销售员，销售员编号，出货日期，开单日期

提货信息

商品编号、商品名称、规格、数量、销售员、订货日期、开单日期、订单号

关系描述分析：

〔1〕一名客户可以生成多分订购单，一份订购单对应一个客户。

所以是以对多关系。

〔2〕一名销售员可以销售多种商品，每种商品可以由多名导购员销售，因此销售员与商品之间是多对多的联系，该联系取名为销售。

〔3〕一名客户可以向多个销售员订购商品，一个销售员可以承受多位客户的订购，因此销售员与客户的关系是一对多的关系，该联系取名为订购。

〔4〕一份订购单可以对应多种商品。

一种商品可以产生多份订购单。

该联系取名为订购。

〔5〕一个仓库管理员可以处理多份订单。

一份订单对应一个仓库管理员。

该联系取名为提货信息。

2.1.2采购业务的局部E-R图

相关属性列表：

实体

属性

仓库管理员

工号、、性别

商品

商品名称，编号，生产规格，数量，单价，商品类别，生产企业

采购员

工号、、性别。

订货单

采购员、商品编号、进货日期、商品名称、下单日期

供货商

、性别、地址、联系方式、供货商编号

联系

属性

出货信息

商品编号，销售员，销售员编号，出货日期，开单日期

货物缺乏通知

订购

商品编号，商品数量

提供

名称，地址，联系方式

下达订单

商品编号，销售员，销售员编号，出货日期，开单日期

购置

商品编号，客户，生产企业，商品数量，商品单价，商品名称，商品别名，商品规格

关系描述分析：

〔1〕一个仓库管理员向采购员发出商品数量缺乏的通知，一个采购员向以名采购员发送需要采购商品的通知，所以仓库管理员与采购员的关系为一对一的关系。

〔2〕一名采购员可以订购多种商品，每种商品也可以由多名采购员订购，因此采购员与商品之间是多对多的联系，该联系取名为订购。

〔3〕一个供给商可以供给多种商品，每种商品也可以由多个供给商供给，因此供给商与商品之间是多对多的联系，该联系取名为供给。

（4）一名采购员可下达多份订购单。

。

一份订购单只能由一个采购员下达。

所以是一对多关系。

该联系取名为下达订单。

（5）一份订单可以采购多种商品。

一种商品可以有多份订单。

所以为多对多关系。

该联系取名为购置。

2.1.3报损局部E-R图

相关属性列表：

实体

属性

仓库管理员

工号、、性别

退货单

商品名称，商品编号，开单日期、退货原因、开单员

报损员

工号、、性别。

报损单

报损员、商品编号、报损原因、商品名称、商品编号

供货商

、性别、地址、供货商编号、联系方式

联系

属性

上报损坏

商品编号，开单员，开单员编号，开单日期，损坏原因

汇总

退货单数量

制定报损单

报损员、商品编号、商品名称、开单日期、报损原因、报损数量

关系描述分析：

〔1〕一名开单员可以向一个存储部交报损单，一个存储部可以承受多位开单员的报损单，因此存储部与开单员之间是一对多的联系，该联系取名为发现损坏。

〔2〕一个顾客可以上报多份退货单，一份退货单只能对应一个客户。

所以为一对多关系。

该联系取名为上报损坏。

〔3〕一个仓库管理员可以向一个报损员上报损坏情况。

一个报损员可以承受对应多个仓库管理员的上报情况。

所以该关系为一对多。

该联系取名为上报损坏。

〔4〕一份退货单只能对应交给一个报损员。

一个报损员可以承受多份退货单。

所以该关系为一对多关系，该联系取名为汇总。

〔5〕一个报损员对应制定多份报损单。

一份报损单由一个报损员制定。

所以该联系为一对多。

该联系取名为制定报损单。

2.2全局E-R图

相关属性列表：

实体

属性

商品

商品名称，编号，生产规格，数量，单价，商品类别，生产企业

部门

部门名称，部门号

供货商

、性别、地址、供货商编号、联系方式

职工

，工号，部门号，性别

客户

，性别，客户编号，，联系方式

联系

属性

管理

名称，编号，规格，数量，单价，供给商，生产企业，开单时间，处理结果，处理时间

附属

，编号，部门号

库存缺乏

编号，数量，供给商

供给

名称，地址，联系方式

处理信息

商品编号，职工编号，开单时间，处理结果，处理时间

订购

商品编号，商品数量

购置

商品编号，客户，生产企业，商品数量，商品单价，商品名称，商品别名，商品规格

关系描述分析：

〔1〕一名客户可以生成多分订购单，一份订购单对应一个客户。

所以是以对多关系。

〔2〕一名销售员可以销售多种商品，每种商品可以由多名导购员销售，因此销售员与商品之间是多对多的联系，该联系取名为销售。

〔3〕一名客户可以向多个销售员订购商品，一个销售员可以承受多位客户的订购，因此销售员与客户的关系是一对多的关系，该联系取名为订购。

〔4〕一份订购单可以对应多种商品。

一种商品可以产生多份订购单。

该联系取名为订购。

〔5〕一个仓库管理员可以处理多份订单。

一份订单对应一个仓库管理员。

该联系取名为提货信息。

〔6〕一个仓库管理员向采购员发出商品数量缺乏的通知，一个采购员向以名采购员发送需要采购商品的通知，所以仓库管理员与采购员的关系为一对一的关系。

〔7〕一名采购员可以订购多种商品，每种商品也可以由多名采购员订购，因此采购员与商品之间是多对多的联系，该联系取名为订购。

〔8〕一个供给商可以供给多种商品，每种商品也可以由多个供给商供给，因此供给商与商品之间是多对多的联系，该联系取名为供给。

〔9〕一名采购员可下达多份订购单。

。

一份订购单只能由一个采购员下达。

所以是一对多关系。

该联系取名为下达订单。

〔10〕一份订单可以采购多种商品。

一种商品可以有多份订单。

所以为多对多关系。

该联系取名为购置。

〔11〕一名开单员可以向一个存储部交报损单，一个存储部可以承受多位开单员的报损单，因此存储部与开单员之间是一对多的联系，该联系取名为发现损坏。

〔12〕一个顾客可以上报多份退货单，一份退货单只能对应一个客户。

所以为一对多关系。

该联系取名为上报损坏。

〔13〕一个仓库管理员可以向一个报损员上报损坏情况。

一个报损员可以承受对应多个仓库管理员的上报情况。

所以该关系为一对多。

该联系取名为上报损坏。

〔14〕一份退货单只能对应交给一个报损员。

一个报损员可以承受多份退货单。

所以该关系为一对多关系，该联系取名为汇总。

〔15〕一个报损员对应制定多份报损单。

一份报损单由一个报损员制定。

所以该联系为一对多。

该联系取名为制定报损单。

3将各分E-R图合并成全局E-R图所作的处理

3.1进展相关实体类型的合并，以减少实体类型的个数

将采购和销售业务中的商品进展合并。

3.2消除冗余

〔1〕将采购和销售业务中的采购员、销售员统一用职工表示。

〔2〕将采购部和销售部，存储部统一用部门表示。

〔3〕将出货信息，提货信息，报损信息统一用处理信息来表示。

4.逻辑构造设计

4.1逻辑设计概述

由于目前使用的数据库根本上都是关系数据库，因此首先需要将E-R图转换为关系模型，然后根据具体DBMS的特点和限制转换为特定的DBMS支持下的数据模型，然后进展优化。

4.2转换规则

〔1〕一个实体型转换为一个关系模型，实体的属性就是关系的属性，实体的码就是关系的码。

〔2〕一个1：

1联系可以转换为一个独立的关系模型，也可以与任何一端对应的关系式合并。

〔3〕一个1：

n联系可以转换为一个独立的关系模型，也可以与n端对应的关系式合并。

4.3根据全局E-R图设计出系统的数据模型：

1.商品〔商品名称，编号，生产规格，数量，单价，商品类别，生产企业〕

2.部门〔部门名称，部门号〕

3.供货商〔、性别、地址、联系方式、供货商编号〕

4.职工〔，工号，部门号，性别〕

5.客户〔，性别，，客户编号，联系方式〕

6.管理〔名称，编号，规格，数量，单价，供给商，生产企业，开单时间，处理结果，处理时间〕

7.附属〔，编号，部门号〕

8.库存缺乏〔编号，数量，供给商〕

9.供给〔名称，地址，联系方式〕

10.处理信息〔商品编号，职工编号，开单时间，处理结果，处理时间〕

11.订购〔商品编号，商品数量,商品名称，

12.购置〔商品编号，客户，生产企业，商品数量，商品单价，商品名称，商品别名，商品规格〕

4.4初步优化：

部门与职工之间

将采购信息，报损信息，出货信息关系模式合并为：

处理信息〔商品数量，处理单编号，商品编号，开单日期，工号，类别〕

4.4.2商品与供货商之间形成一个供给过程

供给商与商品的实体关系

1〕供给商与商品作为关系模式。

供给商〔，地址，性别，联系方式〕

商品〔商品名称，商品单价，商品规格，商品数量，商品编号，生产企业〕

供给〔采购单编号，商品名称，商品单价，商品规格，商品数量，商品编号〕

2〕与供给商端合并

供给商〔，地址，性别，联系方式，采购单编号〕

商品〔商品名称，商品单价，商品规格，商品数量，商品编号，生产企业〕

关系模式合并为：

供给信息：

〔采购单编号，商品名称，商品编号，，地址，性别，联系方式〕

4.4.3商品与客户之间形成一个购置过程

客户与商品的实体关系

1〕客户与商品作为关系模式。

客户〔，地址，性别，联系方式〕

商品〔商品名称，商品单价，商品规格，商品数量，商品编号，生产企业〕

购置〔订单编号，商品编号，商品数量〕

2〕与客户端合并

客户〔销售单编号，，地址，性别，联系方式〕

商品〔商品名称，商品单价，商品规格，商品数量，商品编号〕

关系模式合并为：

购置信息：

〔采购单编号，商品名称，商品编号，联系方式〕

4.4.4职工与商品之间有职工对商品产生销售管理，采购管理，报损管理等信息。

所以形成一个管理过程

销售员与商品的实体关系：

1〕销售员与商品作为关系模式。

销售员〔工号，，性别〕

商品〔商品名称，商品单价，商品规格，商品数量，商品编号，生产企业〕

销售〔出货单编号，商品编号，商品数量〕

2〕与销售员端合并

销售员〔出货单编号，工号，，性别〕

商品〔商品名称，商品单价，商品规格，商品数量，商品编号，生产企业〕

采购员与商品的实体关系：

1〕采购员与商品作为关系模式。

采购员〔工号，，性别〕

商品〔商品名称，商品单价，商品规格，商品数量，商品编号，生产企业〕

采购〔采购单编号，商品名称，商品单价，商品规格，商品数量，商品编号〕

2〕与采购员端合并

采购员〔采购单编号，工号，，性别〕

商品〔商品名称，商品单价，商品规格，商品数量，商品编号，生产企业〕

存储部与报损员的实体关系：

1〕存储部与报损员作为关系模式。

报损员〔工号，，性别〕

商品〔商品名称，商品单价，商品规格，商品数量，商品编号，生产企业〕

报损（报损单编号，商品编号，报损员，报损员工号，开单日期，损坏原因）

2〕与报损员端合并

报损员〔报损单编号，工号，，性别〕

商品〔商品名称，商品单价，商品规格，商品数量，商品编号，生产企业〕

管理信息：

〔商品编号，出货单编号，采购单编号，报损单编号，商品名称，〕

4.4.5将销售人员、采购员关系模式合并为：

员工（工号，，部门号，职称）

4.4.6将存储部、销售部和采购部关系模式合并为：

部门（部门编号，部门名称）

4.5最终优化：

职工：

（工号，，部门号，职称）

部门：

（部门编号，部门名称）

处理信息：

〔商品数量，处理单编号，商品编号，开单日期，工号，类别〕

供给信息：

〔采购单编号，商品名称，商品编号，联系方式〕

购置信息：

〔销售单编号，商品名称，联系方式，订购单编号〕

管理信息：

〔商品编号，出货单编号，采购单编号，报损单编号，开单日期，商品名称，联系方式〕

分析：

1、销售员、采购员、仓库管理员、都属于公司职工。

公司职工都以职工工号为主关键字，所以进展优化合并。

公司职员按照部门来分类。

部门编号为部门的主关键字。

2、采购、销售、报损因包含的主体不一样，都各自独立制表。

3、部门与职工之间细分有库存信息处理，到、发货信息处理、报损信息处理，附属，信息处理，信息都要经过信息处理。

总体这三种都属于处理信息，信息处理都已处理单编号为主键，所以进展优化合并。

4、职工对商品的采购、销售、报损。

属于职工对商品的管理。

销售、采购、报损因所包含的主键不一样所以要各自为表。

5、顾客提交订购单时以商品编号为外键。

购置时以商品编号为外键。

处理信息时以商品编号为外键。

5.数据库完整性与平安性设计

5.1数据库完整性

数据库的完整性维护数据库输入数据的正确性、有效性和相容性。

所谓正确性是指数据的合法性。

有效性是指数据是否属于所定义的有效范围。

相容性是指表示同一事实的两个数据应一样，不一致就是不相容。

数据库是否具备完整性关系到数据库系统能否真实地反映现实世界，因此维护数据库的完整性是非常重要的。

5.1.1约束

约束是MicrosoftSQLServer提供的自动保持数据库完整性的一种方法，定义了可输入表或表的单个列中的数据的限制条件。

1）六种约束：

空值约束、主键约束、惟一性约束、外键约束和参照约束、缺省值约束和检查约束。

（1）空值约束

（2）主键约束

（3）惟一性约束

（4）外键约束和参照约束

（5）缺省值约束

（6）检查约束

2）约束的作用：

保持数据的完整性

3）进销存系统的约束

◆ZG职工

列名

类型

可为空

缺省值

检查

键/索引

工号

Nvarchar（50）

否

主键

Nvarch

展开阅读全文