各子系统的分E-R图设计好以后,下一步就是将所有的分E-R图综合成一个总的E-R图。由于各个局部所面向的问题不同,这就导致各个分E-R图之间必定会存在许多不一致的问题,称之为冲突。因此合并分E-R图并不能简单地将各个分E-R图画到一起,而是必须合理消除各分E-R图中的不一致,以形成一个能为全系统中所有用户共同理解和接受的统一的概念模型,是合并E-R图的主要工作和关键。各E-R图之间的冲突主要有三种:属性冲突、命名冲突、结构冲突。
在超市收费管理系统设计过程中,有属性冲突和结构冲突。属性域冲突,即属性值的类型、取值范围或取值集合不同。如员工编号在不同的关系中都要定义成相同的属性值的类型为字符型并且字长相等,才能避免属性冲突。
按照合成总体E-R图的规则,画出完整的E-R图,如图2.14所示。
若图片无法显示请联系QQ752018766
图2.14 超市销售管理的总体E-R图
概念结构设计是独立于任何一种数据模型的信息结构。逻辑结构设计是把概念结构设计阶段设计好的基本E-R图转换为与选用DBMS产品所支持的数据模型相符合的逻辑结构。所以逻辑结构设计一般分以下三个方面:
(1) 将概念结构转换为一般的关系、网状、层次模型。
(2) 将转换来的关系、网状、层次模型向特定DBMS支持下的数据模型转换。
(3) 对数据模型进行优化。
针对超市收费管理系统 ,逻辑结构设计采用概念结构转换关系模型,将E-R图依照规则转换为关系模型,为了进一步提高数据库应用系统的性能,再将转换后的关系模型进行优化,确定是否要对某些模式进行合并或分解,为物理设计提供最优的处理。
E-R图向关系模型的转换要解决的问题是如何将实体和实体间的联系转换为关系模型,如何确定这些关系模式的属性和码。
关系模型的逻辑结构是一组关系模式的集合。E-R图则是由实体、实体的发生和实体之间的联系三个要素组成的。所以将E-R图转换为关系模型实际上就是要将实体、实体的属性和实体之间的联系转换为关系模式,这种转换一般遵循如下原则:
(1)一个实体型转换为一个关系模式。实体的属性就是关系的属性,实体的码就是关系的码。
对于实体间的联系则有以下不同的情况:
(2)一个1:1联系可以转换为一个独立的关系模式,也可以与任意一端对应的关系模式合并。如果转换为一个独立的关系模式,则与该联系相连的各实体的码以及联系本身的属性均转换为关系的属性,每个实体的码均是该关系的候选码。如果与某一端实体对应的关系模式合并,则需要在该关系模式的属
性中加入另一个关系模式的码和联系本身的属性。
(3)一个1:n联系可以转换为一个独立的关系模式,也可以与n端对应的关系模式合并。如果转换为一个独立的关系模式,则与该联系相连的各实体的码以及联系本身的属性均转换为关系的属性,而关系的码为n端实体的码。
(4)一个n:m联系转换为一个关系模式。与该联系相连的各实体的码以及联系本身的属性均转换为关系的属性而关系的码为各实体码的组合。
(5)三个或三个以上实体间的一个多无联系可以转换为一个关系模式。与该多元联系相连的各实体的码以及联系本身的属性均转换为关系的属性而关系的码为各实体码的组合。
通过上述转换原则,可以将E-R图转换为关系模型,转换结果如下:
顾客(顾客编号,顾客姓名,会员卡号,顾客地址,顾客电话)
此为顾客实体对应的关系模型。根据转换原则(1):一个实体型转换为一个关系模式。实体的属性就是关系的属性,实体的码就是关系的码。
商品(商品编号,商品名称,规格,单价)
此为商品实体对应的关系模型。根据转换原则(1):一个实体型转换为一个关系模式。实体的属性就是关系的属性,实体的码就是关系的码。
供应商(供应商编号,供应商姓名,供应商地址,供应商电话)
此为供应商实体对应的关系模型。根据转换原则(1):一个实体型转换为一个关系模式。实体的属性就是关系的属性,实体的码就是关系的码。
员工(员工编号,员工姓名,员工电话,员工地址,职称)
此为员工实体对应的关系模型。根据转换原则(1):一个实体型转换为一个关系模式。实体的属性就是关系的属性,实体的码就是关系的码。
仓库(仓库编号,仓库地址,仓库电话,仓库面积,仓库负责人)
此为仓库实体对应的关系模型。根据转换原则(1):一个实体型转换为一个关系模式。实体的属性就是关系的属性,实体的码就是关系的码。
购买(顾客编号,商品编号,顾客姓名,会员卡号,顾客地址,顾客电话,商品名称,规格,单价,购买日期,购买数量,换货日期,换货数量,退货日期,退货数量,折扣)
此为联系“购买”所对应的关系模式。根据转换原则(4):一个n:m联系转换为一个关系模式。与该联系相连的各实体的码以及联系本身的属性均转换为关系的属性而
关系的码为各实体码的组合。
供应(商品编号,供应商编号,商品名称,规格,单价,供应商姓名,供应商地址,供应商电话,供应日期,供应数量,汇款方式,汇款人)
此为联系“供应”所对应的关系模式。根据转换原则(4):一个n:m联系转换为一个关系模式。与该联系相连的各实体的码以及联系本身的属性均转换为关系的属性而关系的码为各实体码的组合。
销售(商品编号,员工编号,商品名称,规格,单价,员工姓名,员工电话,员工地址,职称,销售总额,销售数量)
此为联系“销售”所对应的关系模式。根据转换原则(4):一个n:m联系转换为一个关系模式。与该联系相连的各实体的码以及联系本身的属性均转换为关系的属性而
关系的码为各实体码的组合。
存放(商品编号,仓库编号,商品名称,规格,单价,仓库地址,仓库电话,仓库面积,仓库负责人,库存量)
此为联系“存放”所对应的关系模式。根据转换原则(4):一个n:m联系转换为一个关系模式。与该联系相连的各实体的码以及联系本身的属性均转换为关系的属性而关系的码为各实体码的组合。
根据数据库需求分析,系统一共需要11张表。这11张表的结构定义如下表所示。
(1) 供应商表
用来存放供应商的信息,包括:供应商编号,供应商姓名,供应商电话,如表2.2所示。
表2.2供应商表
列名 |
数据类型 |
主键 |
必填字段 |
备注 |
供应商编号 |
字符 |
是 |
是 |
|
供应商姓名 |
字符 |
否 |
是 |
|
供应商电话 |
字符 |
否 |
否 |
|
(2) 购买表
用来存放购买商品的基本信息:顾客编号,商品编号,购买日期,购买数量,折扣,退货数量,退货日期,换货数量,换货日期,如表2.3所示。
表2.3 购买表
列名 |
数据类型 |
主键 |
必填字段 |
备注 |
顾客编号 |
字符 |
是 |
是 |
外键 |
商品编号 |
字符 |
是 |
是 |
外键 |
购买日期 |
日期 |
否 |
否 |
|
购买数量 |
数字 |
否 |
否 |
|
折扣 |
浮点 |
否 |
否 |
|
退货数量 |
数字 |
否 |
否 |
|
退货日期 |
日期 |
否 |
否 |
|
换货数量 |
数字 |
否 |
否 |
|
换货日期 |
日期 |
否 |
否 |
|
(3) 供应表
用来存放商品供应商供应商品的信息:商品编号,供应商编号,供应日期,供应数量,汇款方式,汇款人,如表2.4所示。
表2.4 供应表
列名 |
数据类型 |
主键 |
必填字段 |
备注 |
商品编号 |
字符 |
是 |
是 |
外键 |
供应商编号 |
字符 |
是 |
是 |
外键 |
供应日期 |
日期 |
否 |
否 |
|
供应数量 |
数字 |
否 |
是 |
|
汇款方式 |
字符 |
否 |
否 |
|
汇款人 |
字符 |
否 |
否 |
|
(4) 仓库表
用来存放商品存放于仓库的基本信息包括:仓库编号,仓库地址,仓库电话,仓库面积,如表2.5所示。
表2.5 仓库表
列名 |
数据类型 |
主键 |
必填字段 |
备注 |
仓库编号 |
字符 |
是 |
是 |
|
仓库地质 |
字符 |
否 |
否 |
|
仓库电话 |
字符 |
否 |
否 |
|
仓库面积 |
数字 |
否 |
否 |
|
负责人 |
字符 |
否 |
否 |
|
(5) 商品表
用来存放商品信息包括:商品编号,商品名称,单价,单位,数量,如表2.6所示。
表2.6 商品表
列名 |
数据类型 |
主键 |
必填字段 |
备注 |
商品编号 |
字符 |
是 |
是 |
|
商品名称 |
字符 |
否 |
是 |
|
单价 |
数字 |
否 |
是 |
|
单位 |
字符 |
否 |
是 |
|
数量 |
数字 |
否 |
是 |
|
(6) 存放表
用来存放仓库存放商品的信息,包括:仓库编号,商品编号,库存量,如表2.7所示。
表2.7存放表
列名 |
数据类型 |
主键 |
必填字段 |
备注 |
商品编号 |
字符 |
是 |
是 |
外键 |
仓库编号 |
字符 |
是 |
是 |
外键 |
库存量 |
字符 |
否 |
否 |
|
(7) 销售表
用来存放员工销售商品的信息,包括:员工编号,商品编号,销售总额,销售数量,如表2.8所示。
表2.8销售表
列名 |
数据类型 |
主键 |
必填字段 |
备注 |
员工编号 |
字符 |
是 |
是 |
外键 |
商品编号 |
字符 |
是 |
是 |
外键 |
销售总额 |
数字 |
否 |
否 |
|
销售数量 |
数字 |
否 |
否 |
|
(8) 存取货表
用来存放员工存取货的信息,包括:员工编号,仓库编号,存货数量,存货日期,取货数量,取货日期,如表2.9所示。
上一页 [1] [2] [3] [4] [5] [6] [7] [8] [9] [10] ... 下一页 >>