商品销售管理系统毕业论文-销售管理系统论文-商品销售管理系论文.doc

毕 业 论 文
第一章 远程销售管理系统开发背景

1.1奇正集团简介
奇正集团创建于1993年，是以研制、开发、生产、销售新剂型藏药为宗旨的高新技术企业，现已发展成为集科、工、贸为一体的大型民族药业集团。
 奇正集团下属10家企业，其中甘南佛阁藏药有限公司、西藏林芝奇正藏药厂、甘肃奇正藏药有限公司三家药厂均通过了国家药品监督管理局的GMP认证，为传统藏药的现代化生产建立了稳固的质量保证体系。
奇正集团建立了遍布全国的三级营销网络，拥有30个销售分支机构，经过对国际市场的研究和持续开发，目前，奇正集团已经将多种产品销往多个国家和地区。奇正集团销售收入继2002年突破2亿元后，持续增长。
由此看出，奇正集团是一个大型的医药销售机构，公司的组织机构如图1-1。
总部
总经理
财务部
人事部
市场部
销售部
图1-1 组织机构图

作为一个药品销售公司，奇正公司将全国分为十个大区，每个大区设有办事处（总共三十个左右）。
全公司总人数在五百人左右，总部有四十人左右，大区设有大区经理、大区行政及大区财务，办事处设有地区经理。
总部设有财务部，主要负责总部凭证的制作；各大区设有财务人员一名，负责该大区财务工作。
该公司的终端客户为目标医院和目标药店，其中药店又分为连锁药店、驻店促销药店；销售渠道就是经销商和分销商。
经销商为分销商、目标药店、目标医院供货；分销商为目标医院、目标药店供货。这样就形成了公司的销售体系。销售的结构如图1-2。

奇正藏药

目标药店
经销商
目标医院
分销商
销售渠道
经销商
分销商
图1-2 销售结构图

经销商由公司直接供货，分销商从经销商进货。公司所有回款仅来源于经销商。销售数据指经销商销售数量（经销商流向单）、分销商的进货数量（经销商流向单）、分销商的销售数量（分销商流向单）、目标医院和目标药店的进货数量（经销商和分销商流向单）。

1.2建立新系统的必要性
一个公司在成立之初，首先要解决的问题是生存，之后才是发展。企业要生存，就必须节省开支，将更多的资金投入到新产品的研发当中去，打造出自己的品牌，只有这样，公司才能长久的发展。
在公司刚成立时，由于公司的产品较少，名气不大，自然业务就不会太多，销售额也不会很高。在这个时期，公司每月的销售统计、结算等工作派几个人来做就足够了，而不必花大量的钱去开发一个计算机系统，企业可以把这一笔钱投入到新产品的研发当中，丰富和完善自己的产品，这对一个处于起步阶段的企业来说是一个非常明智的选择。
可是，企业在度过了成立之初期那一段囊中羞涩的日子之后，随着公司业务的不断扩展、公司营业额的不断增长，这就对公司每月的销售统计、结算等工作的要求有了进一步的提高。
其实在企业的整个生命周期里，“节省开支，将更多的资金投入到新产品的研发和改善现有产品中”是一条不变的定律。所以，在企业的营业额达到一个高度的时候，如果在用人工来统计整个公司的销售额等信息的话，就要增加工作的人员数量，这样就大大增加了企业为此投入的资金，而且若是在销售额较大的月份，工期都很难保证，这将成为制约公司进一步发展的障碍，也是公司发展的一个瓶颈。这个瓶颈是每个企业发展时都会遇到的。
突破这个瓶颈对于企业的发展是一个迫在眉睫的事情。要解决这个问题，首先要找出引起这个瓶颈的原因——“低下的工作效率”正是这个瓶颈存在的根源。
找到了问题存在的原因，就要寻找解决问题的方法。在实际工作中，提高工作的效率的方法很多，一个最有效也最直接的方法就是增加工作的人员。
这种方法在企业成长初期是可以说是一种行之有效的方法，可是，在企业已经渡过了生存期而进入发展期之后，这就不一定是最好的方法了。
企业增加工作人员，就等于增加企业的成本。而且这个成本是有很长的延续性的。那么，这对企业的长期发展是非常不利的，所以这是解决以上提出的问题的下下之策。
最好的解决办法应该是寻找到一种方法，来取代人的工作，使得这一过程简单化、程序化，这样不仅精简了人员，而且减少了工作量。在当今社会，很自然地就会想到用计算机来实现。
虽然开发这么一个系统一次性投入的成本比较高，可是这对公司长期的发展是非常有利的。
如果采取增加工作人数的方法，那么只要现有的人员不能按时完成工作，就要再增加人数，这样的话，随着公司不断的发展壮大，公司的人员也会随之“壮大”，直接的后果就是公司的成本不断的增加。
而如果使用计算机这种方法将大大的减少这方面的支出。因为除了第一次的投入以外，以后的花费是比较少的，比较多的就是对硬件的维护等，这一笔花销甚至不到增加一个员工所要支付的工资。
所以，当企业处于以上所说的发展瓶颈的时候，就应该考虑使用一套计算机系统来辅助工作。只有这样，企业才能提高工作效率，使企业有调步稳地发展壮大。
而现在，奇正集团正处在这么一个发展的关口，为了突破这个瓶颈，他决定开发一套系统来取代现在在财务结算方面的人工操作，提高企业每个月末的结算速度，使企业真正向现代化看齐。
本论文是在参加奇正集团的一个ERP系统开发的基础上完成的，主要介绍了远程销售管理系统的分析、设计及实现过程。

第二章 远程销售管理系统系统分析

本章主要是介绍远程销售管理系统系统分析过程。首先对企业现行的业务流程进行分析，找出存在的问题。接着对这一问题提出相应地解决方案，也就是设计新系统的业务流程，最后用数据流程图以及数据字典提出新系统的逻辑模型。

2.1现行业务流程及存在的问题
在（新、旧）业务流程图中各个符号所起的作用，如图2-1。

处 理
内部实体
表 单
业务流向
外部实体
图2-1 业务流程图符号说明

奇正集团作为一个年净利润在几百万的国有大型企业，它们有着自己的一套销售管理方法，如图2-2。

总部销售行政
大区行 政
客户当月销售记录
原始流向单
制
作
核
对
销售渠道
每月商业流 向 单
图2-2 现行业务流程图

现行的业务流程如下：
销售渠道（经销商、分销商）将每个月的销售记录（即每月商业流向单）派人送给大区行政。
大区行政得到流向单后，要对流向单进行核对，若发现问题，就要及时更正，在核对无误后，将各个销售商送来的商业流向单汇总，制作成原始流向单。
原始流向单交送给总部销售行政，由他们来根据原始流向单制作各个客户当月的销售记录，以供之后查询。并且手工的制作各个药品的销售数据明细，以及汇总明细。
以上过程均由是用手工完成的，可想而知如果是在业务繁忙的月份，这一过程将会需要很长的时间，这对企业来说是非常不利的——从企业的角度来说，企业无法按时结算出当月的销售数据，那么就不知道下个月份应该如何调配各个地区的产品数量。
比如在北京大区，在刚刚结束的3月份里，某种药品的销售情况非常的好，甚至有供不应求的情况出现，那么，总公司在得到这一数据之后，经过分析，就会对下个月的北京市场投放更多的产品。
而相对来说，另外一种产品出现了供大于求的情况，那么，就应该减少这种产品在北京的投放量，企业所作出的决策完全以统计的数据为依据。所以说，能否及时地统计出这些数据，对公司制定下一个月的销售计划起着至关重要的作用。
在现行的统计方法中，存在着相当大的弊端。由于整个过程都是由人手工完成，这就很难体现效率了——排除各种意外因素不谈，单单是在数量上，就可以充分地体现了。
一个大区少则几十个经销商和分销商，多则上百个，全国总共分为十个大区，总部要针对每一个客户进行当月的销售记录进行统计，还要制作各种明细报表及汇总报表，可想而知这个工作量是相当大的。
若是纯人工的工作，公司要雇用相当多的人力，相应的公司的成本就会提高很多。显然这是公司最不愿意看到的。
从各个大区的角度来讲，他们要投入相当的人力对销售渠道送来的商业流向单进行核对并修改错误的地方，这些人力物力的成本也是相当高的。如果说雇佣这些人来是专门为了核对单据的话，那么在核对完之后，人员的闲置率就相当高了。
但是如果不雇用人员的话，就要从现有的人员中抽调一部份来完成这个工作，这样市场人员有少了，而各个大区的主要工作就是扩展市场，所以这就明显违背了他们的工作主题。
从上面的分析可以看出，现行的这个流程很大程度上制约了公司的进一步发展。对于一个药品销售公司，他们最主要的工作应该是改善产品的质量，提高产品的市场竞争力，不断地开阔新的市场，提高产品的市场占有率，而不是为了统计销售数量。当然，这些数据对于公司也是非常重要的，但是不应该以提高公司的成本为前提，那么，如何才能既不提高公司的成本，又能高效地完成这些重要数据的统计工作呢？当然使用计算机来取代人的工作是最好的方法了。

2.2新系统业务流程
以上对现行销售管理的流程进行了简单的介绍，分析出了现行系统中存在的问题，接下来在设计新系统模型时，就要充分考虑到这些问题。
新系统应能够及时地得到销售数据，及时地统计出公司所需的数据，及时地查询出指定的数据信息。“及时”是信息系统的主题。
以下就是针对现行业务流程中的问题提出的新系统的业务流程。如图2-3。
销售渠道
每月商业流 向 单
总部销售行政
原始流向单
核
对
上
传
待确认
流向单
大区行 政
正式流向单
总部销售行政
客户当月销售记录
制
作
图2-3 新系统业务流程图

从图中可以看出，在新的业务流程中，改变的地方比较多：销售渠道将每月的商业流向单直接通过互联网邮件的形式发送给总部销售行政，由总部的人员来进行核对。
这个核对是一个初步的核对，在确认数据上没有大的出入之后，形成了原始的流向单。总部人员将原始流向单上传至服务器。
在服务器上的流向单被称作待确认的流向单。所谓待确认就是说，总部人员只是粗略地对商业流向单进行核对，而其中的数据还需要各个大区的大区行政确认后，才能得到最后的正式的流向单。
所以，总部在上传了原始流向单后，大区行政要在规定的时间内，去确认自己所在大区的原始流向单中的数据是否准确，在大区行政确认过之后的流向单就是正式的流向单。
总部销售行政根据正式的流向单制作客户当月的销售记录。以及生成各种销售明细、汇总明细。
在这个流程中，都是用计算机网络来实现的。每个月，经销商和分销商通过电子邮件的方式，将他们的销售记录（即每月商业流向单）发给总部销售行政。
总部将这个销售记录下载下来，对所有这些流向单进行初步的审核，在确认没有什么太大的出入之后，将这些流向单上传到服务器上。
当所有的流行单都上传完之后，总部会在他们的网站上公布之一消息，要求各个大区行政在指定日期之前对自己所辖大区的流向单进行核对。
这样各个大区行政在看到这一消息后，就可以到网上来查看自己大区的流向单，若发现有不正确的数据，他们可以对其进行修改。
在指定的日期过后，总部就会用这些正式的流向单来制作客户（就是各个具体的药店、医院）当月的销售记录，供以后查询，以及生成各种明细报表。
整个过程全部通过计算机来实现，通过计算机来取代人工之后，不仅工期有了保证，也大大降低了公司的运营成本。
在这个流程中，公司不再需要太多的人来进行这方面的工作，而只需少数几个人负责即可，大大减轻了大区的工作量。整个过程中，与大区有关的，只有大区行政要对待确定的流向单进行审核，而无须更多的人，大区的员工可以专心于扩展市场的工作。
大区行政的工作完全是在网上完成的，所以非常的方便快捷。这对于公司来说，正好解决了之前提出的瓶颈问题。

2.3新系统模型的数据流程
前面，对现行的系统进行了分析，找出了存在的问题，之后又针对这些问题设计出了新的业务流程。新的流程解决了现行流程中的存在的弊端，对于一个企业，这是进一步发展必须要解决的问题，现在我们将对这一个方案提出新系统模型的方案。
2.3.1数据流程图符号说明
在以下的数据流程图中，各图形符号的含义如图2-4。

外部实体

数据存储

处 理

数据流

图2-4 数据流程图符号说明

2.3.2顶层数据流程图
顶层数据流程图如图2-5所示。
各种销售记录及单据
流向单处理
P1
销售渠道
F2正式
流向单
F1商业
流向单
图2-5 顶层数据流程图

D1

顶层数据流程图是对流向单处理过程一个总的描述，它体现了流向单的一个总的走向：流向单由外部实体“销售渠道”给出，然后经过处理得到正式流向单，接着对正式的流向单的处理得到客户当月的销售记录及各种相关单据。

2.3.3一层数据流程图
一层数据流程图是对顶层流程图中比较概括的地方的一个细化，以下就是对对顶层数据流程图中的P1处理过程的细化。可将其分为三个小的模块，如图2-6-1至2-6-3所示。
销售渠 道
F1.2待确认流向单
P1.1
处理
F1.1商业流向单
正式流向单
P1.2
核对
图2-6-1 一层数据流程图
F2正式流向单
待确认流向单

D2

D3

在得到销售渠道送来的流向单之后，由总部行政进行初步的核对处理。经过处理的商业流向单叫做待确认流向单，待确认流向单经过大区行政的核对无误后，就是正式的流向单，要对正式的流向单进行存储，以备后用。

P1.3
制 作
客户当月销售记录
正式流向单
F2正式流向单
图2-6-2 一层数据流程图

D3 D4

这一过程是从正式的流向单中提取所需的数据。制作出每个客户的当月销售记录，以供客户查询。总部对于这些数据都有统一的规范。只要从正式流向单中抽取出这些数据即可。

D6
P1.4
生成
汇总明细
销售数据明细
正式流向单
F2正式流向单

图2-6-3 一层数据流程图

D5
D3

根据所选定的条件，从正式流向单中提取所需数据，生成各种销售数据明细表或汇总明细表。

2.4关于新系统模型数据的详细说明
为详细说明数据流程中各个文件的内容及存储方式等，编制了以下相应的数据字典。 数据字典的内容主要包括了对数据流程图中的数据项、数据流、处理逻辑、数据存储和外部实体等方面进行具体的定义。数据流程图与以数据字典两者相结合，从而对新系统逻辑进行完整地描述。

2.4.1数据项的定义
新系统主要包含的数据项有：I01-01 药品名称；I01-02 药品编号；I01-03大区名称；I01-04 大区编号；I01-05客户名称；I01-06 客户编号；I01-07 药品销售数量；I01-08 药品单价；I01-09 药品规格；I01-10 销售日期；I01-11 备注等。
接下来，对所有的数据项进行了详细的定义。

例如：数据项I01-01药品名称的具体描述如下：
数据项编号：I01-01
数据项名称：药品名称
别 名：药品名称
简 述: 公司所售各类药品的名称，可以区分药品的种类，功用等类型及宽度：字符型 50位

再如：数据项I01-02 药品编号的具体描述如下：
数据项编号：I01-02
数据项名称：药品编号
别 名：药品编号
简 述: 某种药品的代码
类型及宽度：字符型 10位

又如：数据项I01-05 客户名称的具体描述如下：
数据项编号：I01-05
数据项名称：客户名称
别 名：客户名称
简 述: 具体某个目标药店或目标医院的名称，有以区分客户
类型及宽度：字符型 50位

2.4.2数据流的定义
新系统中包含的数据流有：F1 每月商业流向单；F1.2 待确认流向单；F2 正式流向单等。
以下对各个数据流进行了详细的定义。

例如：数据流F1每月商业流向单的详细描述如下：
数据流编号：F1
数据流名称：每月商业流向单
简 述：由销售渠道提供的原始的销售数据
数据流来源：销售渠道
数据流去向：总部销售行政
数据流组成：目标药店或医院名称 + 药品名称 + 销售数量 + 药品单价 + 药品规格 + 销售日期

再如: 数据流F1.2待确认流向单的描述如下：
数据流编号：F1.2
数据流名称：待确认流向单
简 述：经初步审核的流向单数据，待大区行政审核确认
数据流来源：总部销售行政
数据流去向：大区行政
数据流组成：目标药店或医院名称 + 药品名称 + 销售数量 + 药品单价 + 药品规格 + 销售日期 + 大区名称

又如：数据流F2正式流向单的描述如下：
数据流编号：F2
数据流名称：正式流向单
简 述：经大区行政确认的流向单
数据流来源：大区行政
数据流去向：总部销售行政
数据流组成：目标药店或医院名称 + 药品名称 + 销售数量 + 药品单价 + 药品规格 + 销售日期 + 大区名称 +大区行政签名

2.4.3处理逻辑的定义
新系统中包含的处理逻辑主要有：P1.1 商业流向单的初步审核；P1.2 待确认流向单的核对；P1.3 客户销售记录的制作；P1.4各种明细的生成等。
以下对各个处理逻辑进行了详细的定义。
例如：处理逻辑P01-02待确认流向单的核对的具体描述如下：
处理逻辑编号：P1.2
处理逻辑名称：待确认流向单的核对
简 述：大区行政对流向单进行最后核对
输入的数据流：经总部初步审核过的原始流向单
处 理：大区行政通过互联网浏览自己所在大区的待确认流向单，发现问题可以及时更正，并存储
输出的数据流：审核完的流向单，正式流向单

再如：处理逻辑P1.4各种明细的生成的具体描述如下：
处理逻辑编号：P1.4
处理逻辑名称：各种明细的生成
简 述：进行采购药品的处理
输入的数据流：正式的流向单存储的数据
处 理：工作人员根据需要，选定检索条件，检索出特定的结果，然后导入到EXCEL中进行打印，生成报表
输出的数据流：各种明细单据

2.4.4数据存储的定义
新系统中包含的数据存储主要有：D2 待确认流向单；D3 正式流向单等。
以下对各个数据存储进行了详细的定义。

例如：数据存储D2待确认流向单存储的具体描述如下：
数据存储编号：D2
数据存储名称：待确认流向单的存储
简 述：总部将初步审核的流向单上传至服务器
数据存储组成：F1.2
关 键 字：无
关键联的处理：P1.2

例如：数据存储D3正式流向单存储的具体描述如下：
数据存储编号：D3
数据存储名称：正式流向单的存储
简 述：经过大区行政确认后的正式流向单
数据存储组成：F2
关 键 字：无
关键联的处理：P1.2、P1.3、P1.4

2.4.5外部实体的定义
新系统中包含的外部实体主要有：S1 销售渠道（客户）
外部实体S1销售渠道的具体描述如下：
外部实体编号：S1
外部实体名称：销售渠道
简 述：商业流向单的来源
输入的数据流：无
输出的数据流: F1.1

第三章 远程销售管理系统系统设计

本章是在系统分析提出的新系统逻辑模型的基础上，对新系统的物理模型进行详细的设计。系统设计的主要任务包括：
l 总体设计，包括信息系统结构图，功能模块设计等。
l 代码设计和设计规范的制定。
l 软硬件配置方案的设计。
l 数据库的设计。
l 计算机处理过程设计，包括输出设计，输入设计，处理流程图设计及编写程序设计说明书等。

3.1远程销售系统总体设计
3.1.1 远程销售系统功能模块的划分
远程销售管理系统是公司管理的一个重要的组成部分，是提高公司资金结算效率的重要手段。
通过这个系统，公司可以及时的结算出当月的销售额，并根据需要得到相关大区或各个客户的销售的详细数据，从而能够准确的对过去的一个月中产品销售的情况作出一个准确的判断，并对下一个月的产品走势有一个初步的估计，这样就知道各个客户在下一个月所需产品是增是减，这样公司就可以对产品的调度有了一个相对准确的数量。
这个系统将大大节省工作人员的时间，提高工作效率，这样大区员工不必再为流向单的审核费时间了，可以将更多的时间投入到开阔市场上去。这无论是对公司还是对个人都是有利的。
经过前期的分析调查，远程销售管理系统具有如下功能，功能结构如图3-1。
l 流向单上传：总部行政得到原始流向单后，对其进行初步的审核，然后将这些待确认的流向单上传至服务器；
l 审核待确认流向单：总部将待确认流向单上传完毕后，由各个大区行政对所辖大区的流向单进行进一步的审核，在确认无误后即可得到正式的流向单；

远程销售管理信息系统
生成当月销售记录
核对待确认流向单
生成各种销售明细
生成各种汇总明细
流向单上传
图3-1 远程销售系统功能图

l 生成当月销售记录：在得到正式流向单后，总部将根据这些流向单制作出各个客户的当月销售记录，以备查询；
l 生成各种销售明细：根据所选的条件，查询处所需的结果，例如某个产品的销售明细等；
l 生成各种汇总明细：对指定的某个产品或客户等，根据所选的项目进行汇总查询，并返回结果。

3.1.2部分子功能的结构图
（1）核对待确认流向单功能结构图
待确认流向单由各个大区行政来核对，那么，对于各个大区行政就只能看到所辖大区的流向单，并可对这些流向单进行修改并保存。所以在大区行政登陆的时候，首先要判断是哪个大区的行政，并据此调出此大区的待确认流向单。

核对待确认流向单
检查所属大区
删除流向单内容
添加流向单内容
修改流向单内容
调出此大区的待确认流向单
保存修改的流向单
图3-2 核对待确认流向单功能结构图

（2）生成汇总明细功能结构图
汇总明细的生成首先是要选定范围，是哪个大区或者是哪个客户、哪个产品等，然后还要选择所要汇总的项目，最后生成汇总明细。图3-2 核对待确认流向单功能结构图

生成汇总明细
选定范围
选定项目
生成明细
图3-3 生成汇总明细功能结构图

3.2远程销售系统代码设计
代码是代表事物的名称、属性、状态等的符号，为了便于计算机处理，一般用数字、字符或是他们的组合来表示。
1、 大区代码的设计
公司将全国分为若干个大区，每个大区都有相应的编号，现将这一编号设计
为两位整数，例如北京大区可以是01，天津大区可以是02，如此类推。
2、 客户代码的设计
各个客户都存在于某个具体的大区中，所以，客户代码就应能够体现出这个
客户所处的大区，因此将客户代码设计如图3-4。
客户编号
大区编号
图3-4 客户代码设计图
XX XXX

其中客户编号是一个逐一递增的整数，这样就能够唯一的表示一个客户了。
3、 流向单代码设计
流向单代码应该能够识别出该流向单的来源，以及日期等，因此，流向单代
码的设计如图3-5。
流向单日期
客户编号
大区编号
图3-5 流向单代码设计图
XX XXX XXXX

这样的流向单代码设计就能够比较清楚的看出这一流向单的来源以及日期了。
以上列举了部分代码的设计过程，从中可以知道，一个好的代码应该能够比较清楚的体现出它的内在含义来。
3.3软硬件配置方案设计
本系统是一个B/S系统，所有的工作都可以通过浏览器的点击来完成，这个系统的实施将大大缩短公司现在的工作周期，由于公司的业务量比较大，因此服务器的处理机能将是十分关键的因素，这将由公司解决。
软件方面，采用了WIN2003SERVER 网络操作系统，这是微软新近推出的一个网络操作系统，它比WIN2000系统更加安全和稳定，是开发B/S系统的理想选择。
数据库方面，选用了SQL SERVER2000，这是个相对熟悉的数据库，开发起来也比较方便，并于选用的开发工具VB.NET同属于微软的产品，相互结合的比较好。它完全能够胜任这个项目的数据存储工作。并且，选择的.NET开发工具，与以往的微软的网络开发工具相比，具有运行速度快、保密性好、易于开发、易于维护、具有更高的可靠性等优点。所以选择这么一个开发工具是比较理想的。
公司的网络环境是已经搭建好的2M的光纤，完全满足此次开发系统的需求。

3.4数据库的设计
3.4.1设计原则
数据库设计是把现实世界的实体模型与需求转换成数据模型的过程，它是建立数据库应用系统的核心问题。
数据库及其应用的性能都建立在良好的数据库设计的基础之上，数据库的数据是一切操作的基础，如果数据库设计不好，将影响到以后的工作效率，这对于此次开发的系统是致命的。
数据库设计的关键是如何使设计的数据库能合理地存储用户的数据，方便用户进行数据处理，提高处理的效率。
以上阐述的这么多都是围绕着工作效率来考虑的，而在真正事实过程中数据库设计最主要的就是要符合三范式的规范化。所谓三范式就是这表的设计时，表中的字段没有传递依赖于主键的字段，而三范式是在第二范式的基础上建立的，因此它也消除了字段的部分依赖问题，这样就减少了数据冗余的存在，提高了数据库的查询效率。
除了以上提到的原则以外，设计数据库时还必须符合系统实际数据结构，这样的数据库才能更好的与实际的数据情况相结合，存取有用的数据。
3.4.2远程销售系统E-R图
E-R图用来表示各个实体之间的联系，它是数据库表设计的基础。本系统的实体有客户、流向单、大区和大区行政，各个实体之间的关系及其属性由图3-6给出。
图3-6 远程销售系统E-R图
客户
流向单
制作
地址
编号
名称
销售日期
姓名
1
1
大区行政
大 区
属于
审核
编号
编号
M
1
N
1
管 辖
1
1
销售数量
图例：
实体
属性
关系
名称

编号

以上就是本系统的实体联系图，它清楚地说明了实体之间的关系，客户属于所处大区，各个大区又一名大区行政，客户制作每月的商业流向单，大区行政队流向单进行审核。
由E-R图描述的关系模型的结构，可以设计出各个数据表。

3.4.3数据库表的设计
由以上的E-R图，并根据数据库规范化理论中第三范式（3NF）的思想，设计出本系统的表结构如表3.1所示。
表3.1 本系统的基本表一览

表 名
备 注
字 段 数
Customer
客户表
7
Area
大区表
3
Area_Master
大区行政表
6
Product
产品表
7
Sales_Info
销售记录表

Flow_order
流向单表

表3.1是本系统的基本表结构，总共有五个表，接下来将对每一个表进行详细的描述（注：所有表中主键均为非空，其他若无具体说明则允许为空）。
表3.2，客户表中建立了六个字段，用C_ID作为主键，由于公司的客户非常多，因此主键类型设置为BIGINT，并且设置它是由系统自动增加的，这样可以表示出唯一的一个客户，以此作为主键是可以的。其它的字段将用来记录客户的基本信息，其中，A_ID这个字段是大区的编号，它与大区表中的同一字段相关联，用来确定客户所在的大区，Rmak字段用来记录一些额外的信息。这些字段都完全依赖于主键，这个表的设计符合三范式。

表3.2 客户表

字 段 名
类 型
长 度
说 明
备 注
C_ID
BIGINT
20
自动增加
主键
A_ID
INT
10
大区编号
外键
C_Name
CHAR
50
客户名称

Sort
Char
20
客户类型

Address
CHAR
50
地 址

Phone
INT
10
联系方式

Rmak
CHAR
100
备 注

表3.3，大区表中只有两个字段，A_ID和A_NAME。这个表是用来记录大区的基本信息。公司将全国分为若干个大区，每个大区分别管理本区的业务，以及为客户分配产品。此表的设置是根据三范式的要求，几个大区的信息提取出来，用A_ID这个字段作为其他表的外键与此表相关联。

表3.3 大区表

字 段 名
类 型
长 度
说 明
备 注
A_ID
INT
10
编号
主键
A_Name
CHAR
30
名称

PHONE
INT
10
联系方式

表3.4，大区行政表用来记录各个大区的大区行政的信息，字段M_ID设为主键，A_ID为外键，与大区表中的相关字段相关联，确定此大区行政所管辖的大区。

表3.4 大区行政表

字 段 名
类 型
长 度
说 明
备 注
M_ID
INT
10
编号
主键
A_ID
INT
10
大区编号
外键
M_Name
CHAR
20
姓名

Phone
INT
10
联系方式

Address
CHAR
100
住址

Rmak
CHAR
100
备注

表3.5，产品表用来记录公司所售产品的基本信息，例如产品名称、单价、产品规格等。此表用P_ID作为主键，其他的字段有产品的名称、单价、规格、生产厂家等。其中字段“规格”用来描述产品的大小规格，因为对于同一种产品有不同的规格 大小，例如用20*10(cm)来表示奇正藏药贴的一种规格，而这种药贴还有其他的规格。字段“单价”是此种规格产品的售价，用于统计之用。字段“产品描述”用来记录关于产品的更详细的信息。

表3.5 产品表

字 段 名
类 型
宽 度
说 明
备 注
P_ID
CHAR
10
编号
主键
P_Name
CHAR
10
名称

Price
DECIMAL
9
单价

P_gg
CHAR
20
规格

Made_F
CHAR
20
生产厂家

Product_Discript
CHAR
100
产品描述

Rmak
CHAR
100
备注

表3.6，销售记录表中记录了产品销售的相关信息。表中用自动编号的字段S_ID作为主键，唯一的标识一条销售记录，C_ID（客户编号）P_ID（产品编号）以及File_ID（流向单编号）三各字段为外键。date_time用来记录客户进货的日期，sale_price记录的是客户售出药品的单价，与产品表中的单价不同的是，产品表中的单价对于客户来说是进货价。Sale_num记录了该月该种产品的销售数量，这个字段可以跟之前的sale_price字段相乘，得到某个客户该月该种产品的销售额，这些都是在制作各种明细表是用到的。字段last_date记录了对该条数据的最近一次操作时间；字段Checker，用来记录总部审核该流向单的人员名字，以便日后分清责任。表中还有一个字段Check_result用来记录词条销售记录是否正确，若是正确的则为Y，否则为N。

表3.6 销售记录表

字 段 名
类 型
宽 度
说 明
备 注
S_ID
INT
20
销售记录编号
主键
C_ID
INT
10
客户编号
外键
P_ID
INT
10
产品编号
外键
File_ID
INT
10
流向单编号
外键
date_time
DATE

进货日期

sale_price
DECIMAL
9
销售单价

Sale_num
INT
10
销售数量

last_date
DATE

最近处理日期

Checker
CHAR
10
审核人员

Check_result
Varchar
10
审核结果

表3.7，流向单表用来记录流向单的基本信息，在总部初步审核了各个客户传来的原始流向单后，将这些流向单上传至服务器上。这就需要将流向单中的各种信息存储在数据库中，其中流向单中有关销售数据的信息就存储在销售记录表（Sales_info）当中，而将流向单的一些基本的信息例如商业编号、流向单日期等存储在流向单表（Flow_order）中。
表中设流向单的编号为主键，客户编号（C_ID）以及产品编号（P_ID）为外键。其它的字段有商业编号（comm_id），这是公司的统一业务管理的一个规范化的编号；流向单日期（File_Date）是流向单记录的数据所属的年月；最近处理日期（last_date）记录的是对此流向单最近一次操作的时间；上传人（uploader）记录了上传这条记录的人员。Check_result字段表示这个流向单的数据是否已经全部审核完毕。
除了以上几个字段以外，其他的字段均与其它表中的相同字段的含义相同，在此就不一一解释了。

表4.7 流向单表

字 段 名
类 型
宽 度
说 明
备 注
File_ID
INT
20
流向单编号
主键
C_ID
INT
10
客户编号
外键
P_ID
INT
10
产品编号
外键
comm_id
INT
30
商业编号

File_Date
DATE

流向单日期

last_date
DATE

最近处理日期

uploader
CHAR
20
上传人

Check_result
VARCHAR
10
审核结果

3.4.4 表间关联图
以上是数据库中表的设计，其中各个表之间是根据主键和外键联系的，如图3-7所示。

大区行政表
M_ID 主 键
A _ID 外 键
:
:

1:1

大区表
A_ID 主 键
:
:

销售记录表
S_ID 主 键
C_ID 外 键
File_ID