商品销售管理数据库系统设计概要Word格式.docx
《商品销售管理数据库系统设计概要Word格式.docx》由会员分享,可在线阅读,更多相关《商品销售管理数据库系统设计概要Word格式.docx(31页珍藏版)》请在冰豆网上搜索。
(1)概述:
包括项目背景、编写目的、软件定义、开发环境等内容。
(2)需求分析:
问题陈述、需完成的功能,画出ER模型图;
(3)数据库逻辑设计:
把ER模型图转换为关系表。
描述每一个基本表关系。
要求所有关系达到BCNF范式。
定义视图、定义索引、主关键字、定义权限。
(4)数据库物理设计:
定义数据物理文件及管理。
(5)开发与编码:
编写程序、调试并进行测试。
(6)结束语:
写出完成本课程设计的心得,领会数据库理论与软件开发实践的关系。
有哪些收获。
软件还需要哪些改进。
(7)参考文献。
严禁剽窃、抄袭等作弊行为!
全文抄袭,或未按时交卷,或与课程内容毫不相关按不及格处理。
评分标准
分值
得分
完成数据库系统设计工作任务
20分
论文文章结构安排合理,写作规范,引注正确。
10分
论文逻辑条理清晰,论证有力。
理论阐述全面,能够联系实际分析问题,解决问题。
需求分析:
问题陈述清楚、需完成的功能描写准确,ER模型图正确。
数据库逻辑设计:
定义视图、索引、主关键字、权限。
数据库物理设计:
开发与编码:
成绩
==========================================
(题目)商品销售管理数据库系统设计
(正文)
内容摘要
数据库是数据管理的最新技术,是计算机科学的重要分支也是计算机科学技术中应用最为广泛的技术之一。
随着现代化科技的发展,设备和管理的现代化,在实际工作中如何提高工作效率成为一个十分重要的课题。
今天,信息资源已经成为各个部门的重要财富和资源。
建立一个满足各级部门信息处理要求的行之有效的信息系统也成为一个企业或组织生存和发展的重要条件。
1概述
1.1项目背景
销售管理是为了实现各种组织目标,创造、建立和保持与目标市场之间的有益交换和联系而设计的方案的分析、计划、执行和控制。
通过计划、执行及控制企业的销售活动,以达到企业的销售目标。
现代企业都很重视销售管理,其根本目的是提高销售额,增加企业盈利。
通过数据库系统设计可以有效地帮助企业达到利益的最大化。
1.2编写目的
帮助企业对销售信息进行快速、准确的录入、查询、修改等。
面对各种不同的信息,利用合理的数据库结构来保存保存数据信息。
做到企业信息查询便捷,信息准确。
极大地提高商品信息管理的效率,也是企业的科学化,正规化管理及与世界接轨的重要条件。
1.3软件定义
1.MicrosoftWindows7旗舰版2.MicrosoftOfficeVisio2007
3.MicrosoftOfficeWord20074.SybasePowerDesigner15
1.4开发环境
操作系统:
MicrosoftWindows7
硬件组成:
处理器:
英特尔奔43.0GHZ芯片组:
威盛CN700/VN800/P4M800CE/Pro内存:
512DIMM1:
syncMAX533MHZ512MB主硬盘:
三星SP0842N(80G)显卡:
威盛S3GraphicsUnichromePro(64MB)
2需求分析
2.1问题陈述
本商品销售管理系统中首先要确定在处理销售过程中需要设计的部门。
1、当顾客产生需求下单,销售部门接收到订单,进行订单的处理;
2、销售部门接收订单并进行处理后,开出销售小票,并记录在账本中,以便以后查阅;
3、确定订单后,财务部门进行财务处理,记录账本,做好财务记录;
4、订单确认,发送发货通知,仓务部发货,并记录在案。
而本系统系统的组织主要有3个部门:
销售部门:
主要是对订单进行分析审核开出相应的票据,对企业的销售情况进行记录;
财务部门:
主要对资金流动方面进行操作和开发票确认资金流向,对企业的资金发展起指导作用;
仓库部门:
主要对货物仓库的账本进行调整和对货物的出进仓进行管理。
组织结构图如图1:
图1商品销售管理系统的组织结构图
2.2功能描述
客户产生需求,生成订单。
销售部门对订单进行审核,合格订单则继续工作流程,若是不合格订单则退会给客户。
确定合格订单后,并且需要记录在销售账本中,以便于查阅公司企业的商品销售情况。
开销售小票,传递到财务部门。
财务部门会进行款项的处理(收款),并对借贷收款情况记录在财务账本。
开出发票与小票,小票以作为仓库部门的发货依据,仓库部门发货给客户,并做好库存的记录,收取客户的到货签收单。
业务流程图如图2:
图2销售业务管理业务流程图
2.2数据流分析
根据商品销售管理系统的业务流程图,对其数据进行深入的分析,利用PowerDesigner工作绘制出数据流图(DFD),其中共有3种方案。
方案1如图3:
图3方案1的数据流图
方案2如图4:
图4方案2的数据流图
方案3如图5:
图5方案3的数据流图
方案1:
在方案一中,客户直接产生订单,然后订单进行了审核,在审核的过程中忽视了库存的部分,而导致在假设库存都足够的情况,因而可能会导致订单生成可是库存却不足的情况。
在数据流图过程中主要以小票的方式进行部门的传递,造成混乱,小票过多难以辨清,并且在企业内部容易造成部门之间的功能实现受阻。
方案2:
在方案二中,在审核过程中增加了缺货量项目,可以明确订单生成确定。
不至于造成库存不足的销售影响。
在数据传递中运用了其他的方式传递于下一个部门,可是在实现数据流通的过程中还是不够完善。
方案3:
在方案3中,并不是直接由客户产生订单,而是由客户产生需求,审核后才生成订单传递,销售部门处理后产生小票,在财务部门收款后产生出货单,发货后与客户签订到货签收单。
在方案三中,各个数据的流向清晰,不易混乱,在各个部门的的账本记录中分工明确。
方案三中生成的部分报告内容
Name
Code
ParentOrganization
客户
Composite
Implementer
OrganizationUnit
发货
审核
收款
采购入库
销售
Split/Merge_1
Destination
Source
MessageFormat
Transport
FlowType
?
Success
产品目录
价格
发货计划生成
缺货量
财务账本
账本2
货物量
销售账本
Resource
Process
3数据库概念设计和逻辑设计
3.1..关系模式
根据上面的3种方案,各自的优缺点,本人选择第三种方案来进行ER模型图分析,确定实体,联系以及各自的属性,并通过联系关联实体,画出ER图。
实体有9个,分别是顾客、订单、销售小票、出货单、到货签收单、支付凭证、销售账本、财务账本、库存账本。
顾客(身份证号,姓名,住址,联系电话,工作)
身份证号->
姓名
姓名->
住址,联系电话,工作
姓名,住址,联系电话,工作
所以身份证号是主键
订单(订单编号,货物信息,货物编号,货物量,单价,总价,付款方式,订货人,订货日期,发货日期,开单日期)
订单编号->
货物信息,订货人,付款方式,开单日期
货物信息->
订货日期,交货日期,货物编号,单价,总价
货物信息,货物编号,货物量,单价,总价,付款方式,订货人,订货日期,交货日期,开单日期)
销售小票(小票编号,订单号,货物信息,订货人,开票日期,开票人,备注)
小票编号->
订单号,开票日期,开票人,备注
货物信息,订货人,
发票代码->
小票编号,订单号,订货人,货物信息,开票日期,开票人,备注
所以小票编号为主键
出货单(出货单编号,订单号,货物信息,备注,发货人,收货人,开单日期,发货日期)
出货单编号->
订单号,备注,开单日期
订单号->
货物信息,发货人,收货人,发货日期
出货单编号,订单号,货物信息,备注,发货人,收货人,开单日期
所以出货单编号是主键
到货签收单(签收单号,订单号,货物信息,交付方式,收货人,收货日期,开单日期)
签收单号->
订单号,交付方式,开单日期
货物信息,收货人,收货日期
签收单号,订单号,货物信息,交付方式,收货人,收货日期,开单日期
所以签收单号是主键
支付凭证(支付凭证编号,付款人,收款单位,付款方式,日期)
支付凭证号->
付款人,收款单位,付款方式,日期
支付凭证编号->
所以支付凭证号是主键
销售账本(销售账目号,订单号,货物信息,货物编号,货物量,单价,订货人,付款额,记账人,备注,记账日期)
销售账目号->
订单号,记账人,备注,记账日期
货物信息,订货人