示例一精品店数据库系统设计.docx
- 文档编号:2926731
- 上传时间:2022-11-16
- 格式:DOCX
- 页数:9
- 大小:147.92KB
示例一精品店数据库系统设计.docx
《示例一精品店数据库系统设计.docx》由会员分享,可在线阅读,更多相关《示例一精品店数据库系统设计.docx(9页珍藏版)》请在冰豆网上搜索。
示例一精品店数据库系统设计
精品店的数据库系统设计报告
1需求分析
1.1需求分析概述
数据库是面向用户开发的,所以数据库是否符合用户的需求,是否能够适合用户的操作习惯成了数据库是否成功的标志之一。
本数据库是一个面向销售精品的商店的数据库。
用户需求的收集:
本小组采用观察与体验相结合的方式进行收集,具体为小组成员通过自己的生活阅历和常识实现构建出商店的基本需求,再通过观察的方法,到后市场的商店进行亲身体验,实地观察,最终实现用户需求的收集。
随着时代的发展,商品销售管理系统已经成为商店的必备系统,商店销售系统是典型的信息管理系统(MIS),其开发主要包括后台数据库的建立和维护以及前端应用程序的开发两个方面。
对于前者要求建立数据一致性和完整性且数据安全性好的数据库,而对于后者则要求应用程序功能完备、易使用等特点。
商店的运营和管理涉及商品的采购、存储和销售,以及人员,仓库管理等环节。
会涉及大量的商品信息,人员信息,以及存储信息。
而且商店每天的客流量很大,商品种类繁杂,对单笔交易的处理速度要求很高,因此要保证商店正常且高效的运营,必须有一个方便操作且可靠的信息管理系统。
本系统能够快速而准确地记录商品的仓储,销售数据以及工作人员的相关信息,从而保证商店高效率的运营。
1.2功能需求
本系统用户组分为三类普通员工,店面经理,和数据库管理员。
(1)普通员工
商品录入:
进货时,把商品的条形码存入系统数据库,这样就可以在销售时通过扫描商品的条形码,实现销售商品的记录,并且自动更新、存取。
该方法可以使各种电脑操作水平的人员均能进行录入操作。
收银业务:
根据输入条形码来自动计算购入商品的价值总额,然后根据顾客所付相应款项实现自动计算找零,同时打印交易清单(包括交易清单号、本实体店名称、商品名称、数量、交易时间)。
进货管理:
根据销售情况及存货情况,再根据市场行情来制定进货计划,避免商品的积压及缺货。
销售管理:
商品的销售,能够从中查询商品的销售记录,便于月末或年终盘点,实现销售最大化。
(2)店面经理
库存管理:
综合查询库存明细记录,存货状态自动报警提示,比如少货、缺货时。
人员管理:
员工、供应商、店面经理等基本信息的管理。
统计分析:
此系统通过对商店数据的实时更新,统计,便于商店经营者决策。
(3)数据库管理员
备份管理:
此系统要有自动备份的功能,时间为一天一备份。
安全管理:
数据库管理员有权修改用户组的权限,确保数据库的安全。
1.3性能需求
(1)由于该数据库系统数据录入频繁,对此数据存储速度要求很高,故响应时间应尽量快。
(2)易于数据的录入,方便员工的查询。
1.4安全性分析
(1)店面经理在此系统中拥有数据的修改、插入、查询、删除等权限。
(2)商店员工仅仅只有数据录入与查询的权限。
(3)此系统有备份的功能,是数据长期保存,防止丢失。
2精品店的概念模型设计
将需求分析得到的用户需求抽象为信息结构即概念模型的过程就是概念结构设计,其中包含了实体、属性及实体之间的关系,通常用矩形框表示实体、菱形框表示关系、用椭圆形表示实体或者是关系的属性,并用直线把实体联系起来,这种数据模型是与DBMS无关的、面向现实世界的、容易理解的数据模型。
2.1此系统的实体
商品:
其属性有条形码、商品名称、单价
销售人员:
其属性有销售人员ID、姓名、电话、经理ID
仓库:
其属性有仓库编号、仓库容量
供应商:
其属性有供应商编号、姓名、电话
店面经理:
其属性有经理ID、姓名、电话
仓库管理员:
其属性有管理员ID、管理员姓名、电话、经理ID
采购人员:
其属性有采购人员ID、采购人员姓名、电话、经理ID
会员:
其属性有会员ID、商品条形码、会员姓名、电话、累计金额、积分
采购单:
其属性有采购单编号、采购员ID、商品条形码、供应商编号、
商品数量
入库单:
其属性有入库单编号、货架号、商品条形码、商品数量、入库日期
出库单:
其属性有出库单编号、货架号、商品条形码、商品数量、出库日期
销售单:
其属性有销售单标号、销售员ID、销售日期、销售日期、商品条形码
2.2实体之间的联系
一个销售人员可以销售多件商品,一种商品可由多个销售人员销售。
每个供应商可以提供多种商品,一种商品可由多个供应商提供。
一个仓库可以储存多种商品,一种商品只能保存在一个仓库中。
一个员工被一个经理管理,一个经理管理多个员工。
一个管理员管理一个仓库,一个仓库由一个管理员管理。
一个采购人员采购多个供应单,一个采购单可以由多个采购人员采购。
一张销售单能记录多种商品,一种商品可以被多张销售单记录。
一个会员能购买多种商品,一种商品可以被多个会员购买。
一张出库单可以记录多种商品,一种商品可以被多张出库单记录。
一张入库单可以记录多种商品,一种商品可以被多张入库单记录。
一种商品可以被多个供应商供应,一个供应商可以供应多种商品。
一个采购单可以采购多种商品,一个商品可以被多个采购单采购。
2.3系统E-R图设计
3精品店的逻辑模型设计
概念结构是独立于任何一种数据库模型的信息结构。
系统逻辑设计即为将概念结构设计阶段设计好的基本E-R图转化为DBMS所支持的逻辑模型。
3.1实体关系模式
(1)销售人员表(销售人员ID、销售人员姓名、电话、经理ID)
(2)商品表(条形码、商品名称、单价)
(3)仓库表(仓库编号、仓库容量)
(4)供应商表(供应商编号、供应商姓名、电话、所供商品条形码)
(5)店面经理表(经理ID、姓名、电话)
(6)采购人员表(采购人员ID、采购人员姓名、电话、经理ID)
(7)仓库管理员(管理员ID、管理员姓名、电话、经理ID)
(8)出库单(出库单号、出库数量、货架号、仓库编号、商品条形码、出库日期)
(9)入库单(入库单号、入库数量、货架号、仓库编号、商品条形码、入库日期)
(10)采购单(采购单编号、采购人员ID、采购日期、商品条形码、商品数量)
(11)会员(会员编号、会员姓名、会员电话、积分点、购买商品条形码、累计金额)
(12)销售单(销售单编号、销售日期、销售商品条形码、商品数量、销售人员ID)
3.2联系关系模式
(1)交易表(条形码、会员编号)
(2)销售表(条形码、销售人员ID、销售单号)
(3)供应表(条形码、供应商编号)
(4)采购表(供应商编号、采购人员编号、采购单号)
注:
此四个表与上述的一些表有所重复,在后面将会删除这些多余的表。
3.3数据依赖
1、实体关系模式的数据依赖
(1)销售人员表={销售人员ID、销售人员姓名、电话、经理ID}
F={销售人员ID——>销售人员姓名,销售人员ID——>电话,销售人员ID——>经理ID}
(2)商品表={条形码、商品名称、单价}
F={条形码——>商品名称,条形码——>单价}
(3)仓库表={销仓库编号、仓库容量}
F={仓库编号——>仓库容量}
(4)供应商表={供应商编号、供应商姓名、电话}
F={供应商编号——>供应商姓名,供应商编号——>电话,供应商编号——>所供商品条形码}
(5)店面经理表={经理ID、姓名、电话}
F={经理ID——>姓名,经理ID——>电话}
(6)采购人员表={采购员ID、采购员姓名、采购员电话、经理ID}
F={采购员ID——>采购员姓名,采购员ID——>采购员电话,采购员ID——>经理ID}
(7)仓库管理员表={管理员ID、管理员姓名、电话、经理ID}
F={管理员ID——>管理员姓名,管理员ID——>管理员电话,经理ID——>管理员ID}
(8)出库单={出库单号、出库数量、货架号、仓库编号、商品条形码、出库日期}
F={出库单号——>出库数量,出库单号——>货架号,出库单号——>仓库编号,出库单号——>商品条形码,出库单号——>出库日期}
(9)入库单={入库单号、入库数量、货架号、仓库编号、商品条形码、入库日期}
F={入库单号——>入库数量,入库单号——>货架号,入库单号——>仓库编号,入库单号——>商品条形码,入库单号——>入库日期}
(10)采购单={采购单编号、采购员ID、,采购日期、商品条形码、商品数量、供应商编号}
F={采购单编号——>采购员ID,采购单编号——>采购日期,采购单编号——>商品条形码,采购单编号——>商品数量,供应商编号——>采购单号}
(11)会员={会员编号、会员姓名、会员电话、积分点、购买商品条形码、累计金额}
F={会员编号——>会员姓名,会员编号——>会员电话,会员编号——>积分点,会员编号——>购买商品条形码,会员编号——>累计金额}
(12)销售单={销售单编号、销售日期、销售商品条形码、商品数量、销售人员ID}
F={销售单编号——>销售日期,销售单编号——>销售商品条形码,销售单编号——>商品数量,销售单编号——>销售人员ID}
2、联系关系模式的数据依赖
(1)交易表和供应表中不存在非主属性部分和传递依赖主属性,也不存在主属性之间的部分依赖和传递依赖。
(2)销售表中不存在非主属性对主属性的部分和传递依赖,而主属性之间却存在部分以来,销售单号可以决定商品条形码和销售人员ID,但是,此表与销售单重复,故最终将会删去。
(3)采购表中不存在非主属性对主属性的部分和传递依赖,但是主属性之间存在依赖,采购单号可以决定供货商编号和采购人员编号。
3.4完整性分析
实体完整性:
每个实体都拥有一个主码,且每个主码不能为空值。
参照完整性:
3.5规范化
①由于每个关系模式的所有属性都是不可分的数据项,所以上述关系符合1NF。
②由于在概念模型映射成为逻辑模型时,存在很大的数据冗余,销售表和销售单存在重复的地方,可以将销售表删除,而保留销售单即可;同理,采购表和采购单也是这种情况,可以将采购表删除。
交易表中的相关数据可以在会员表中体现,所以也可以删除交易表;供应表上的相关信息在采购单上都有所体现,所以,可以将供应表删除,用采购单即可。
③经过上述的分析,每个非主属性完全函数依赖于主属性,所以上述关系符合2NF。
④经过上述的分析,舍弃一些多余的表之后,每个关系模式的非主属性都不存在传递依赖,所以上述关系符合3NF。
⑤经过上述的分析,舍弃一些多余的表之后,每个关系模式的主属性间都不存在传递依赖,所以关系符合BCNF。
3.6最终的逻辑模式结果
(1)销售人员表(销售人员ID、销售人员姓名、电话、经理ID)
(2)商品表(条形码、商品名称、单价)
(3)仓库表(仓库编号、仓库容量)
(4)供应商表(供应商编号、供应商姓名、电话、所供商品条形码)
(5)店面经理表(经理ID、姓名、电话)
(6)采购人员表(采购人员ID、采购人员姓名、电话、经理ID)
(7)仓库管理员(管理员ID、管理员姓名、电话、经理ID)
(8)出库单(出库单号、仓库编号、商品条形码、出库数量、货架号、出库日期)
(9)入库单(入库单号、仓库编号、商品条形码、入库数量、货架号、入库日期)
(10)采购单(采购单编号、采购人员ID、供应商编号、采购日期、商品条形码、商品数量)
(11)会员(会员编号、购买商品条形码、会员姓名、会员电话、积分点、累计金额)
(12)销售单(销售单编号、销售日期、销售商品条形码、商品数量、销售人员ID)
4物理结构设计
4.1关系模式存取方法的选择
1、聚簇索引
DBMS系统会自动为各个表的主码建立聚簇索引。
2、其他类型的索引
(1)在会员表中为姓名做升序索引。
(2)在销售人员表中为销售人员ID建立降序索引,对销售人员电话建立唯一索引。
(3)在商品表中为商品的单价建立降序索引。
(4)在仓库管理员表中为仓库管理员ID做降序索引。
(5)为供应商表中的供应商电话建立唯一索引。
(6
- 配套讲稿:
如PPT文件的首页显示word图标,表示该PPT已包含配套word讲稿。双击word图标可打开word文档。
- 特殊限制:
部分文档作品中含有的国旗、国徽等图片,仅作为作品整体效果示例展示,禁止商用。设计者仅对作品中独创性部分享有著作权。
- 关 键 词:
- 示例 精品店 数据库 系统 设计
![提示](https://static.bdocx.com/images/bang_tan.gif)