(2) 方便系统分析人员对系统范围和规模有大概认识; (3) 方便构建测试用例,方便分析人员明确系统功能; (4) 方便接口设计人员尽早介入设计开发过程。
图2.1 宠物管理系统用例图
通过对宠物市场进行查询和了解,现行的一些网上宠物店规模庞大,业务繁
琐,则相应
的管理系统也十分复杂。但是考虑到人们在购买宠物和宠物物品这一方面的消费习惯,大多数消费者还是选择去实体店进行挑选和购买,那么这时候负责的宠物店管理系统略显大材小用,则面向小型实体宠物店管理的简单快捷的宠物店管理系统应该走向市场,本宠物店管理系统则主要面向小型实体宠物店。本系统只涉及宠物店管理者,通过与宠物店管理者进行交互完成一系列功能。
通过图2.1宠物管理系统用例图描述本系统与管理员之间的交互:
2.2系统的数据流程设计
当信息在软件中移动时,它将被一系列“变换”所修改。数据流图(DFD)是过程模型的体现,它描述数据如何在系统变化,也就是说经过每次不同功能点的处理,数据被加工后传递到下一个流向,数据从哪里获取,又最终会存取在那里,这就是数据流图体现的技术。数据流图主要包括过程,数据流,数据存储,外部实体。
画数据流图的基本目的是利用它作为交流信息的工具。我们把对现有系统的认识或对目标系统的设想用数据流图描绘出来,如图2.2宠物管理系统数据流。
顾客购物信息1.2生成用户订单D1 订单信息1.1提供订单信息信息2.1公司管理员登录码账户、密码顾客购D2职工信息顾客购物、密3.1息物信账户息信物品宠物更新宠物物品信息D3宠物物品信息宠物物品信息3.2显示宠物物品信息宠物物品信息公司管理员宠物信息4.1更新宠物信息D4宠物信息宠物信息4.2显示宠物信息信宠物息顾客品商价评5.1显示商品评价商品评价D5反馈信息5.2更新商品评价图2.2 宠物店管理系统数据流图
由该数据流图我们可以发现5种数据流:订信信息、职工信息、宠物物品信息、宠物信息、反馈信息。下面就5种数据流进行说明:
(1)订单信息面向公司管理员,用户在选择好商品后,可以去收银台进行支付,然后由收银员进行收费和登记订单信息。那么对于宠物店的订单信息,由公司管理员进行更新和处理。
(2)职工信息是面向公司管理员和职员,每个职员的信息都存有信息档案,公司管理员和职员都可以登录查看自己的信息,但是查看的级别略有不同,而且在登录的时候还需要进行登录时信息的验证。
(3)宠物物品信息面向公司管理员和顾客,在宠物店进货或者卖出货后,公司管理员及时更新宠物物品信息,然后这些信息将面向顾客,顾客可以及时了解宠物物品信息,是有货还是缺货,还可以关注自己喜欢的宠物物品。
(4)宠物信息同样面向公司管理员和顾客,宠物店购进宠物或者卖出宠物后,公司管理员会对这些信息进行及时更新,以达到实时更新给顾客,为顾客提供便捷。
(5)当用户购买宠物或者宠物物品等商品后会对商品、宠物店职员服务态度等进行评价,这时评价信息会录入商品评价信息库中,然后公司管理员可以从信息库中获取用户的反馈信息,及时做调整 3.概念设计
根据需求分析中的图2.2宠物店管理系统数据流图以及分析报告可以得到职员、工资和职位之间的E-R图,如图3.1所示:
图3.1 职员-工资-职位的E-R图
根据需求分析中的图2.2数据流图以及分析报告可以得到种类、宠物和顾客之间的E-R图,如图3.2所示:
宠物种类名进价用品名数量用品种类号用品种类进价库存数量宠物种类宠物种类号1属于属于零售价宠物号种类n宠物用品图片零售价宠物名宠物性别nn宠物用品号加入加入11商品种类商品商品号价钱n购买时间订单数量邮箱1姓名顾客号固定电话顾客地址1手机号反馈性别n反馈时间反馈信息反馈内容种类图3.2 种类-宠物-顾客的E-R图
4.逻辑设计
4.1实体—关系属性
在概念设计的基础上,根据设计得到系统总的E-R图,按照概念模式与关系表转化的一般规则,结合实际的需要进行逻辑设计,E—R图中的实体、实体的属性和实体之间的联系转化为关系模式,相应的实体-关系属性如下:
? 宠物(宠物号,宠物名,性别,图片,零售价,宠物种类号) ? 宠物种类(宠物种类号,宠物种类名,库存数量,进货单价) ? 宠物用品(宠物用品号,用品种类号,售价) ? 商品(商品号,零售价,商品种类)
? 订单(顾客号,商品号,数量,价钱,购买时间)
? 顾客(顾客号,姓名,性别,地址,固定电话,手机号,邮箱) ? 反馈信息(编号,反馈种类,顾客号,反馈内容,反馈时间)
? 职员(职员号,姓名,性别,固定电话,手机号,职位号,工资单号) ? 工资项(工资项号,基本工资,奖金,福利,职位津贴,职位号,其他) ? 工资表(工资单号,职员号,工资项号,发放时间,工资总和) ? 职位号(职位号,职位名称)
4.2关系模式
宠物:
宠物种类: 宠物用品: 商品: 订单: 顾客:
反馈信息: 职员: 工资项: 工资表: 职位号: 5.规范化分析
5.1任务和目标
以规范化理论为指导对关系模式进行合理的优化,得到为MS SQL Server 2005以上版本 所支持的数据表。
5.2具体关系表的设计与优化
1)第四部分中的关系模式都满足第一范式和第二范式,即所有关系的属性都是原子属性并且不存在非主属性对码的部分函数依赖。但并非所有的关系都满足第三范式。工资项和工资表不满足第三范式通过修改可以满足第三范式 修改前:
工资项(工资项号,基本工资,奖金,福利,职位津贴,职位号,其他) 修改后:
工资项(工资项号,职位号,其他)
职位工资(职位号,基本工资,奖金,职位津贴) 修改前:
工资表(工资单号,职员号,工资项号,发放时间,工资明细) 修改后:
工资表(工资单号,职员号,工资项号)
职员工资表(职员号,工资项号,发放时间,工资明细) 此时关系也满足了BC范式。
2)规范化工作总结:从第一范式到第二范式的规范化实际上是消除非主属性对码的部分函数依赖;从第二范式到第三范式的规范化实际上是消除非主属性对码的传递函数依赖; 3)从第三范式到BC范式的规范化消除了主属性对码的部分和传递函数依赖。经过了规范化后关系变成:
宠物(宠物号,宠物名,性别,图片,零售价,宠物种类号) 宠物种类(宠物种类号,宠物种类名,库存数量,进货单价) 宠物用品(宠物用品号,用品种类号,售价) 商品(商品号,零售价,商品种类)
订单(顾客号,商品号,数量,价钱,购买时间)
顾客(顾客号,姓名,性别,地址,固定电话,手机号,邮箱) 反馈信息(编号,反馈种类,顾客号,反馈内容,反馈时间)
职员(职员号,姓名,性别,固定电话,手机号,职位号,工资单号) 工资项(工资项号,职位号,其他)
职位工资(职位号,基本工资,奖金,职位津贴) 工资表(工资单号,职员号,工资项号)
职员工资表(职员号,工资项号,发放时间,工资明细) 职位号(职位号,职位名称)
4)鉴于系统的效率考虑,最终决定仍然采用第四部分的关系模式,从这一点可以看出。并不是规范化程度越高越好,要根据实际情况,考虑多方面因素决定最后的关系模式。 6.物理设计
用DDL 语言实现所选课题的相关设计,过程如下所示:
create table
相关推荐: