数据库概念结构设计和逻辑结构设计举例

数据库概念结构设计和逻辑结构设计举例

某超市公司要设计一个数据库系统来管理公司的业务信息，该超市公司的业务管理大致可分为三部分：

1、超市公司的仓库管理业务；

2、连锁商店的商品销售业务；

3、连锁商店的集团购买业务。

业务管理规则如下：

（1）该超市公司有若干仓库，若干连锁商店，供应若干商品；

（2）超市公司的业务员负责与供应商联系商品进货业务；

（3）购进的商品按类存放在仓库中，每个仓库有若干保管员；

（4）每个连锁商店有一个经理和若干收银员，每个收银员只在一个连锁商店工作。

（5）每个商品编号只有一个商品名称，但不同商品编号可以有相同的商品名称，每种商品可有多种销售价格；

（6）连锁商店实行会员制，通过会员卡收集顾客信息。顾客办理会员卡后，可享受一定的优惠；

（7）连锁商店要处理客户和销售员送来的集团购买大宗商品的订单，并根据库存情况交出货物同时开出发票，收到付款后应进行收款处理；

（8）连锁商店对大宗订货给予优惠，每种商品规定了不同订货数量和折扣。

一、设计局部ER模式

1、仓库管理子系统分ER图

根据管理规则（2），（3），与仓库管理子系统有关的实体包括：业务员、商品、供应商、仓库、职工。

因为每个业务员都可以与若干家供应商联系多项商品或进货业务，所以在业务员、商品、供应商之间存在一个三元的多对多的联系。仓库与商品之间存在多对多，仓库与职工之间存在一对多的联系。

2、根据规则（1）（4）（5）（6），与商品销售业务有关的实体有商店、商品、收银员、顾客。

因为每个收银员都要与多个顾客购买的多种商品发生业务联系，所以在收银员、商品与顾客之间存在一个多对多的联系。商品与商存在多对多的联系，商店与收银员之间存在一对多的联系。

3、连锁商店的集团购买业务是单独处理的，此业务处理主要是围绕“订单”和“应收帐款”的处理。且这两项处理用的数字，是许多数据流共享的数据。因此可以确定“订单”、“应收帐款”为实体。

因为每张订单有订单号、若干头信息和订单细节组成。订单细节又由商品号、数量等来描述。因此订单细节就不能作为订单的属性处理，而应该上升为实体。一张订单可以订若干商品，所以订单与订单细节两个实体之间是一对多的联系。由此，原订单和商品的联系实际上是订单细节和商品的联系。每条订单细节对应一个商品描述，订单处理从中获得当前商品单价、重量等信息。

由于连锁商店对集团的大宗订货给予优惠，每种商品都规定了不同的订货数量的折扣，应增加一个“折扣规则”实体来存放这些有关信息。

二、设计全局ER图

任务：把分ER图集成在一起。（1）合理地消除各分ER图的冲突；（2）消除不必要的冗余。

如：连锁商店的所有商品，都是通过公司的仓库调配进货的，所以商品和仓库之间的多对多联系，以及商品和商店之间的多对多联系，可以合并成三个实体间的多对多联系。

把ER图转换成关系模式

1、职工（工号，姓名，性别，仓库号）

2、仓库（仓库号，地址，电话，负责人）

3、商店（商店号，商店名，地址，电话，经理）

4、商品（商品号，商品名，规格，单价，产地）

5、顾客1（顾客号，姓名，地址，电话）

6、收银员（工号，姓名，性别，商店号）

7、业务员（工号，姓名，性别，电话）

8、供应商（供应商号，名称，地址，帐号，电话）

9、进货1（商品号，供应商号，业务员，进货量））

10、进货2（商品号，商店号，仓库号，数量））

11、销售（商品号，收银员，顾客号，销售额）

12、顾客2（顾客号，姓名，地址，电话，信贷状况，帐目余额）

13、应收帐款（顾客号，订单号，发票号，应收金额，支付日期，支付金额）

14、订单（订单号，顾客号，订货项数，订货日期，交货日期）

15、订单细节（）

16、商品描述（）

17、折扣规则（）