1.需求描述和系统边界
在市场经济中，销售是企业动作的重要环节，为了更好地推动销售，不少企业建立分公司或代理制，通过公司或代理把产品推向最终用户。这些分公司或代理商大多分布在全国各地，甚至是在国外，远距离频繁的业务信息交流构成了这些企业业务活动的主要特点。 这些信息传递和管理的方式不仅效率低，可靠性、安全性和保密性都无法满足需求，而且数据统计时间严重滞后，往往是当领导了解到企业的“产、销、存”环节出现问题时，就已经远离了问题出现的时间和地点。即便是没有分公司的企业，使用传统的手工方式管理也存在同样的问题。通过订单生成与管理系统，及时通过网络把决策信息传递给相关决策人，从而可以及时发现问题、解决问题，从而更好地把握机会，提高自己在市场竞争中的地位，增强企业的生命力。设计订单生成和管理系统正是为了适应这种形势，它已经刻不容缓了。
消音材料本系统为订单管理系统，能够实现订单录入、确认、拣货、发货、出库、入库、库存查询、订单查询等功能。本系统分为主数据、订单管理、库存管理和查询统计四个部分。 主数据部
分主要用于维护库存、产品、客户和供应商的基本信息，包括仓库、货位表、库存表、客户信息表、产品表、产品价格表、订单状态、供应商信息表、供应商报价表等模板。用户在开始使用系统之前，需要将主数据录入或者导入系统。
2.需求分析
2.1业务需求及处理流程
业务需求分析是根据现实世界对象要求，描述应用的具体业务处理流程，并分析哪些业务是计算机可以完成的，而哪些业务是不能由计算机完成的。
公司日常业务数据量巨大，其中订单信息是联系客户信息与商品信息的关键，这些信息需要大量的编排与整理，但是它们的分析收集过程全部依赖工作人员的手工操作，工作人员的绝大多数精力投入到浩繁的数据整理中，这样的情况不仅仅大大加剧了工作难度，而且无形中加大了信息处理的错误概率。本系统的建立能够将客户于商品的关系明显的联系起来，并且生成订单信息，使用它大大的简化了数据的录入，计算，修改的工作量，而且极大程度的提高了信息处理效率，因此，该系统的需求十分迫切，功能十分实用。
在订单生成与管理系统的数据库中，一个客户可以有一份或多份订单，即它们是一对多的关系，每份订单也可以订购一种或多种商品。每份订单有一张发票，发票可以通过多种方式来支付购买款，如支票、信用卡或者现金。处理这个订购登记的职工的名字要被记录下来。
部门工作人员负责整理订单并根据库存情况处理订单。如果库存中有订单上的产品，就可以直接发货，发货方式也有很多种；如果库存中没有订单上的产品，就不需要登记或者订购其他产品。
经过仔细分析系统需求之后，企业订单系统要完成的主要功能如下：
1) 进入系统之前需要身份验证，待用户名、密码，输入正确之后方可进入。
2) 企业可以对已存在的产品信息进行修改和删除，增加新的产品信息。
3) 对已存在的订单信息进行添加，修改和删除。
4) 企业可以更新对订单产生的方式。
5) 企业可以更新已有客户的信息并对客户信息进行分析。
系统的具体的业务流程图见下图1
图1 业务流程图
2.2功能需求及数据需求分析
功能需求分析是描述系统应提供的功能和服务。根据上述需求描述和业务流程，通过与订单管理人员的沟通与交流，订单生成系统的主要功能和数据需求包括：
注册管理
·会员注册。会员注册时要求填写基本信息，包括姓名、登录密码、性别。出生年月、地址、、、电话等信息。系统检查所有信息填写正确后提示会员注册成功，并返还会员编号。
·职员注册。工作人员以职员身份注册并填写信息，包括姓名、登录密码、性别、出生年月、住址、电话、等信息。系统检查所有信息正确后提示注册成功并返回职员编号。
商品管理
·
增加商品信息。当有新商品上架时，职员负责添加和发布商品信息。包括商品名称、商品编号、售价、商品简介等。
·商品信息查询。系统需要提供多种方便快捷方式对商品进行检索。如既可以输入关键词进行简单查询，也可以根据商品编号、售价、简介等单一或组合查询。
·商品信息更新及删除。商品信息发布后，职员可以随时更新和删除商品信息。
选择商品
会员登录后，将需订购的商品放入购物车并填写购买数量。购物车内的商品可以随意增加、删除和修改数量，并能即时统计购物车内的商品总价格。
选择完成后，会员还需填写送货地址、支付方式等。确认填写的信息无误后，则提交生成订单。每张订单要求记录订单号（按时间顺序生成）、客户编号、生成订单日期、收货人、送货人、订单明细（包括商品名称、数量、价格）。
订单管理
·
订单查询。订单提交后，会员可随时查询订单的最新状态以及全部历史订单。
·订单取消及更新。订单未审核前，允许会员取消订单及更新订单信息。
·订单受理。订单生成后，职员对订单进行审核。如发现订单填写不正确则退回订单客户重新填写。如正确无误，则生成订单并安排配送。
2.3 业务规则分析
业务规则分析主要是分析数据之间的约束以及数据库约束。基本上述功能需求，通过进一步了解，订单生成系统业务规则如下：
（1）所有用户均可搜索图书信息，但只有注册会员才能在网上提交订单；只有注册职员才能维护图书信息及受理订单。
（2）每位会员由会员编号唯一标识，会员编号由系统按时间顺序生成。
沟槽式管接头
（3）每位职员由职员编号唯一标识，职员编号由系统按时间顺序生成。
u型玻璃幕墙
（4）商品编号是系统识别商品的唯一标识。系统需记录每种商品的当前库存量，当库存量低于某一阈值时则通知补货。
（5）选购的商品必须放入购物车后才能生成订单。
（6）每一个订单用订单编号唯一标识。订单编号由系统按时间顺序生成，后提交的订单具有更大的订单号。
（7）订单需记录当前状态，包括未审核，退回，已审核和已处理结束等状态。
（8）同一订单可订购多种图书，且订购数量可以不同。因此，一个订单可包括多个商品明细。订单中每种商品需记录其状态，包括未送货、已送货、已送到等。
（9）订单受理前允许会员删除所选商品，修改订购数量，配送信息等，甚至取消订单。但订单审核通过后，则不允许做任何修改。
完成需求分析后，接下来的任务就是根据上述分析结果设计数据库的概念模型，即E-R模型，包括确定实体集、联系集及属性。
３确定实体集及属性
实体集是具有相同类型及相同性质（或属性）的实体集合。通常，一个实体对应一个事物，是名词。发现实体集的步骤可归纳为：
发泄工具
（1） 出需求分析中出现的具有一组属性的“名词”。
（2） 分析这些“名词”信息是否需要存储。对于不需要存储的“名词”不必建模为实体集。
（3） 分析这些“名词”是否依赖于其他对象存在。如果是，可考虑为联系或弱实体集。
由上节分析可知，订单生成系统中出现的名词主要有：会员，职员，商品，订单等。
显然，会员、职员、商品等都具有一组属性且部分属性能唯一标识每个实体，而且它们需要存储到数据库中供查询用，因此可直接建模为实体集。
购物车用于临时存放购物信息，包括选购商品的商品名称、编号、订购数量、价格。订单提交成功后，购物车中的信息将全部存放到订单中去。当客户放弃订购不生成订单时，购物车中的信息不需要保留。由于购物车中的信息无需查询，故不必建模为实体集。
订单是用于记录一次订购的全部信息。按上述规则由订单编号唯一标识不同订单，故订单可建模为一个实体集。但另一方面，订单又反映了会员与商品之间的一种“订购”联系，反映“谁什么时候订购了什么商品，订购了多少”等信息，它对会员和图书具有一定的“依赖”关系。因此，直观上将订单建模为会员与商品之间的联系集更为合适。
图2 职员实体集E-R图
图3 会员实体集E-R图
图4 商品实体集E-R图
4.确定联系集及E-R图
定了实体集后，接下来就是确定联系集，即发生实体集之间的数学关系，这是决定E-R图
设计好坏的关键。通常，联系对应的概念为一种动作，即描述实体间的一种行为。因此，当发现两个或多个实体之间的某种行为需要记录时，课建模为一个联系集。
确定联系集的一个重要任务是分析所建模联系集的映射基数，即参与联系的实体集中一个实体通过该联系集能同时与另一个实体集中多少个实体相联系。
同实体集一样，联系集也可以有自己的描述属性。要注意的是，联系集已包含了所有参与该联系的实体集的主码属性，故在E-R 图中参与联系的实体集的主码属性不要作为联系集的描述属性画出。
基于上节设计得到的实体集，课确定联系集，并得到以下E-R图：
图5 订单生成系统E-R图
如上图5，其中外部实体包括员工，商品，订单，客户四个部分，相应的两个实体之间由联系相连接，每个实体都有自身的属性。上图可知，员工与录入的商品信息之间是一对多的关系，员工与商品是通过录入信息联系起来的。每个都有自己的编号，，姓名等属性，这些属性能够区分不同的员工。相应的，不同商品之间也有不同名称，单位，型号，售价等属性。商品与对单一一对应，并且可以通过对订单的查询，寻到商品信息。客户与订单也是一对一关系，客户的属性在本系统中是最多的，这样也保证了订单不会在对应库户时发生错误，提高了系统工作效率
。
5 检查是否满足需求
在图5所示的E-R图中，按照E-R减速电动机图的转换规则，多对多的联系的主码为两个参与联系集的主码的集合。仔细分析，发现该E-R图存在如下问题：
（1） 会员不能在不同订单里订购同一种商品；
（2） 当一次订购多种商品时，订单中存在大量信息冗余；
（3） 未反应配送单与订单的依赖关系；
（4） 未反应配送单与发票一对一联系。
于是，订单实体集OrderSheet属性可确定未:订单号（OrderNo）、订单日期（orderDate）、订单总金额（orderMoney）、收货人（receiver）、送货地址（shipAddress）、（zipCode）、（shipTel）、付款方式（payWay）、是否付款（payFlag）、订单状态（orderState）和发票单位（invoiceUnit）等其E-R图如下图所示。
图6 订单实体集的E-R图
6 逻辑数据库设计
设计出E-R图后，可将E-R图转换为数据库模式。通常是每个实体集（包括强和弱实体集）都对应于一个关系表。而联系及则应根据映射基数决定具体转换方式。其中主码属性加出题和下划线，外码属性加出斜体以示区分。
表1：商品表
属性名称 | 数据类型 | 属性描述 |
GoodsＩＤ | char(9) | 商品编号 |
Goods Name | varchar(12) | 商品名称 |
units | Varchar(9) | 商品单位 |
model | Varchar(10) | 商品信号 |
selling price | Char(16) | 商品售价 |
汽车膨胀水箱 | | |
豫公网安备41160202000603
站长QQ:729038198
关于我们
投诉建议