《网上书店数据库设计实例.ppt》由会员分享，可在线阅读，更多相关《网上书店数据库设计实例.ppt（75页珍藏版）》请在三一办公上搜索。
1、第6章 关系数据库设计实例,数据库系统原理与设计(第 2 版),目 录,确定联系集及E-R图,需求描述和系统边界,需求分析,确定实体集及属性,检查是否满足需求,逻辑数据库设计,模式求精,主要业务的概念建模分析,基于B2C的网上书店系统需求描述,该系统支持4类用户：游客、会员、职员(书店工作人员)和系统管理员。游客可以随意浏览图书及网站信息，但只有在注册为网站会员后才能在线购书。游客注册成功后即为普通会员，当其购书金额达到一定数量时可升级为不同等级的VIP会员，以享受相应的优惠折扣。会员登录系统后，可通过不同方式(如书名、作者、出版社等)搜索图书信息、网上订书、在线支付、订单查询与修改，发布留言
2、等。,基于B2C的网上书店系统需求描述,书店工作人员以职员身份注册登录后，可维护与发布图书信息、审核订单、安排图书配送、办理收款、处理退货，并进行图书采购、库存管理、会员管理、留言回复等。系统管理员的主要职责是维护已注册会员、职员信息。请为该网上书店设计数据库E-R图和关系模式。要求保存所需全部信息，并高效地支持上述各种应用。由于网上书店功能比较复杂，本设计不考虑网上支付和退货等功能。确定系统边界,目 录,确定联系集及E-R图,需求描述和系统边界,需求分析,确定实体集及属性,检查是否满足需求,逻辑数据库设计,模式求精,主要业务的概念建模分析,业务需求及处理流程,业务需求分析是根据现实世界对象需
3、求，描述应用的具体业务处理流程，并分析哪些业务是计算机可以完成的，而哪些业务是不能由计算机完成的。网上书店主要业务包括：图书信息发布与查询、订购图书、处理订单，并通知配送公司进行图书配送等。本节只给出网上书店的核心业务“订单生成”及“订单受理”处理流程。常见的网上书店一般包括哪些业务功能？,图6.1 网上书店的 主要业务流程,功能需求及数据需求分析,注册管理会员注册。会员注册时要求填写会员基本信息，包括姓名、登录密码、性别、出生日期、电话、地址、邮政编码、电子邮箱、单位等信息。系统检查所有信息填写正确后提示会员注册成功，并返回会员编号。职员注册。职员注册时要填写基本信息，包括姓名、登录密码、性
4、别、出生日期、部门、薪水、住址、电话、电子邮箱等信息。系统检查所有信息填写正确后提示注册成功，并返回职员编号。,功能需求及数据需求分析,图书管理图书信息维护。图书：ISBN、书名、作者、版次、类别、出版社、出版年份、库存数量、定价、图书折扣、内容简介、目录等信息。图书采购。当库存数量不足或出版社出版新书，书店职员负责图书采购。采购单：采购单号、出版社、采购日期、采购人、采购明细(ISBN、书名、采购数量、单价)等。图书入库。当订购的图书到货后办理图书入库，并增加新图书信息、更新图书库存数量。入库单：入库单号、出版社、入库日期、入库人、收货人、入库明细(ISBN、书名、入库数量)等。图书发布。书
5、店职员负责及时在网上发布新书信息、图书推荐信息、促销信息等，并及时更新、删除旧信息。,功能需求及数据需求分析,在线订书会员登录后，选购图书放入购物车中，并填写购买数量。购物车中的图书可增加、删除和修改，并自动统计图书总价格。选书完成后，会员填写配送信息、发票单位及选择支付方式。配送信息默认为会员注册时填写的基本信息，也可重新填写。确认所填信息后，提交生成订单。每张订单记录：订单号、订购日期、应收总金额、会员折扣、实收总金额、付款方式、订单状态、订单明细(ISBN、书名、订购数量、定价、应收金额、图书折扣、实收金额、配送状态)和发票信息(如发票单位等)。如果选择在线支付方式，则还需进行网上结算。
6、若余额不足，则取消订单（本设计不作考虑）。,功能需求及数据需求分析,配送管理假设一张订单所订购的图书可拆分成不同的配送单发货，但一个配送单不能包含不同订单的图书。会员在生成订单之后需要进一步进行配送设置，包括填写配送信息(收货人、送货地址、邮政编码、联系电话等)，定义配送明细(ISBN、书名、配送数量等)。同时还需要选择：如果一个配送单中的所有图书不是同时有货，是否需要自动拆送。每张配送单要求记录：配送单号、配送日期、是否拆送、发票编号、配送状态、配送信息和配送明细。配送状态用于记录该配送单的当前配送状态：未发货、已发货、已送到等。,功能需求及数据需求分析,订单管理订单查询。订单提交后，会员可
7、查询订单状态：未审核、退回、已审核、已部分配送、已全部配送、已处理结束。订单更新。订单未审核前，允许会员修改、取消订单。订单受理。订单生成后，职员对订单进行审核。如发现订单及配送单信息填写不正确，则退回客户重新填写。如果通过审核，则检查所订购图书是否有库存。如一个配送单中所购图书均库存，则生成该配送单的发票，更新库存数量，安排配送。如一个配送单中的部分图书库存不足(通知尽快进货)，且会员选择是否拆送为“Y”，则系统自动对该配送单进行拆分配送(先配送有库存的图书)，生成拆分的配送单及发票，更新库存数量，安排配送。,功能需求及数据需求分析,出版社管理网上书店直接从出版社采购图书。要求保存和维护出版
8、社信息：出版社编号、出版社名称、出版社地址、邮政编码、联系人、电话、传真、电子邮箱等。配送公司管理网上书店通过配送公司将图书送到会员手中。要求保存和维护配送公司信息：公司编号、公司名称、公司地址、邮政编码、联系人、电话、传真、电子邮箱等,功能需求及数据需求分析,留言管理发布留言。会员可在网站发表留言或评论。留言需记录：留言人、留言内容、发布时间等。回复留言。书店职员可回复留言，并记录：回复人、回复时间、回复内容等。用户管理会员升级。系统可对会员进行分级，即当会员订书总金额到达一定数额后成为不同级别的用户，以享受相应的优惠折扣。会员信息维护。系统管理员及会员可修改、删除和更新会员信息。职员信息维
9、护。系统管理员及职员可修改、删除和更新职员信息。,业务规则分析,业务规则分析主要是分析数据之间的约束以及数据库约束。网上书店业务规则如下：游客均可搜索图书信息，但只有注册会员才能提交订单；只有注册职员才能维护图书信息及受理订单。会员编号唯一标识会员，会员编号由系统按时间顺序生成。职员编号唯一标识职员，职员编号由系统按时间顺序生成。会员等级分类：购书总额达到 10000元，三级VIP会员，享受售价 9.5 折优惠；购书总额达到 20000元，二级VIP会员，享受售价 9 折优惠；购书总额达到 30000元，一级VIP客户，享受售价 8.5 折优惠。,业务规则分析,ISBN唯一标识一种图书。系统记
10、录每种图书的当前库存数量，当某图书的库存数量低于某一阈值时，则通知该图书补货。选购的图书必须放入购物车后才能生成订单。订单受理前允许会员删除所选图书，修改购书数量、配送信息和发票单位，甚至取消订单。但是订单审核通过后，则不允许再做任何修改。订单编号唯一标识订单。订单编号由系统按时间顺序生成。同一订单可订购多种图书，且订购数量可以不同。因此，一张订单的订单明细包括：ISBN、图书名称、订购数量、定价、应收金额、图书折扣、实收金额、配送状态。每种图书的实收金额=订购数量*定价*图书折扣*会员折扣。,业务规则分析,每个订单可分多个配送单进行配送，配送单的配送明细信息由会员设置。配送单编号唯一标识配送
11、单。每个订单的配送单编号由订单编号加上系统按时间顺序生成的配送单流水号组成。假设一张订单的每一个配送单对应开一张发票，但一张订单的所有发票的发票单位都相同。发票用发票编号唯一标识。配送单中的图书采取先到先发货原则进行配送。若一个配送单中的图书未同时有货，且会员选择可以拆送，则系统会自动拆分成不同配送单发货；但是，一个配送单中的某种图书只有库存足够时才能安排配送。一个配送单只能由一个配送公司进行配送(不同配送单可以由不同配送公司配送)；一个配送公司可以承接多次配送业务。,业务规则分析,配送单的配送状态记录了该配送单的当前配送情况：未发货、已发货、已送到等。订单中的订单状态记录了该订单的当前处理情
12、况：未审核、退回、已审核、已部分配送、已全部配送、已处理结束等。订单明细的配送状态记录了该图书的当前配送情况：未配送、已部分配送、已全部配送等。当订单中的某种图书全部送到后，则更新该图书的配送状态为“已全部送到”。当订单内全部图书的配送状态为“已全部送到”时，则更新该订单的订单状态为“已处理结束”。一种图书由一个出版社出版，而一个出版社可出版多种图书。一个会员可发表多条留言，一个职员可回复多条留言，但假设一条会员发布的留言至多只回复一次。,目 录,确定联系集及E-R图,需求描述和系统边界,需求分析,确定实体集及属性,检查是否满足需求,逻辑数据库设计,模式求精,主要业务的概念建模分析,订单生成与
13、订单审核,订单生成涉及会员、图书等基本实体集，并会伴随着生成订单和订单明细。根据4.6.2节的分析可知，伴随着“订购”业务而形成的订单需要单独建模为依赖实体集，它的属性有订单号、订购日期、应收总金额、实收总金额、付款方式、订单状态、会员折扣、发票单位等。订单实体集与图书实体集之间存在多对多的图书订购(即订单明细)联系集，联系属性有订购数量、定价、应收金额、图书折扣、实收金额、配送状态等。订单实体集与会员、职员实体集之间分别存在着多对一的订购、审核联系集。,图6-2 订单生成与订单审核业务的建模,订单：应收总金额、实收总金额为派生属性，通过图书订购汇总得到；会员折扣也是派生属性，它的值取自会员实
14、体集中该会员对应属性；发票单位属性的值默认取自会员的单位属性，可修改。图书订购：应收金额、实收金额为派生属性，可通过订购数量、定价、会员折扣、图书折扣等属性计算得到；定价、图书折扣也是派生属性，它们的值分别取自图书实体集中该图书对应属性。,说明：为了不使E-R图过于复杂，并未将实体集、联系集的所有属性在图中画出来。,配送设置与图书配送,伴随着配送设置会生成配送单和配送明细。配送单是依附于订单的，因此可将配送单建模为订单的弱实体集，属性有配送单号、收货人、送货地址、邮政编码、联系电话、发票编号、是否拆送等，配送单号为部分码。一方面，订单实体集与配送单弱实体集之间存在一对多的包含标识联系集。另一方
15、面，配送单弱实体集与图书实体集之间存在多对多的图书配送(即配送明细)联系集，联系属性有配送数量。在会员设置的配送单基础上，由职员根据库存情况进行调整和确认，并分派给配送公司进行配送。因此，在配送单弱实体集与职员实体集之间存在多对一的分派联系集；在配送单弱实体集与配送公司实体集之间存在多对一的配送联系集，联系属性有配送日期、配送状态。,图6-3 配送设置与图书配送业务的建模,订单,ISBN,书名,订购,会员,职员,审核,图书,图书订购,订购数量,配送状态,订购日期,订单状态,已配送数量,订单号,图书配送联系集反映的是配送明细信息，即一个配送单中需要配送哪些图书？每一种图书的配送数量是多少？为了“
16、核对”一个订单所订购的所有图书是否已经配送完毕，需在图书配送联系集与图书订购联系集之间进行“配送核对”，它是多对一的汇总核对。可在图书订购(即订单明细)联系集中增加一个派生属性已配送数量，它可在图书配送(即配送明细)联系集中按订单号、图书编号汇总得到。,图6-3 配送设置与图书配送业务的建模,订单,ISBN,书名,订购,会员,职员,审核,图书,图书订购,订购数量,配送状态,订购日期,订单状态,已配送数量,订单号,图书配送联系集反映的是配送明细信息，即一个配送单中需要配送哪些图书？每一种图书的配送数量是多少？为了“核对”一个订单所订购的所有图书是否已经配送完毕，需在图书配送联系集与图书订购联系集
17、之间进行“配送核对”，它是多对一的汇总核对。可在图书订购(即订单明细)联系集中增加一个派生属性已配送数量，它可在图书配送(即配送明细)联系集中按订单号、图书编号汇总得到。,如果一个订单明细的已配送数量与订购数量的值相同，则可将该订单明细的配送状态置为“已全部配送”。如果同一个订单的所有订单明细的配送状态都为“已全部配送”，则可将该订单的订单状态置为“已全部配送”。如果一个订单的所有配送单的配送状态都为“已送到”，则可将该订单的订单状态置为“已处理结束”。,图6-4 配送设置与图书配送业务的另一种建模方案,订单,ISBN,书名,订购,会员,职员,审核,图书,图书订购,订购数量,配送状态,订购日期
18、,订单状态,已配送数量,订单号,另一种建模方案：将配送单建模为强实体集，而图书配送建模为实体集配送单与联系实体集图书订购(即联系实体集)之间的多对多联系集。,图书采购与图书入库,图书采购涉及职员(采购员)、出版社、图书等基本实体集，并会伴随着生成采购单和采购明细。根据4.6.2节的分析可知，伴随着“采购”业务而形成的采购单需要单独建模为依赖实体集，它的属性有采购单号、采购日期、采购总金额等，其中采购总金额为派生属性，可通过图书采购(即采购明细)联系集汇总得到。采购单实体集与图书实体集之间存在多对多的图书采购联系集，联系属性有采购数量、采购单价、采购金额等，其中采购金额为派生属性。采购单实体集与
19、职员实体集之间存在多对一的采购联系集；采购单实体集与出版社实体集之间存在多对一的供应联系集,图6-5 图书采购业务的建模,图书采购联系集反映的就是采购明细，即一个采购单中采购了哪些图书？每一种图书的采购数量、单价分别是多少？显然在一个采购单的采购明细中，每一种图书只能出现一次。假设同一种图书允许在一个采购单的采购明细中出现多次，即图书采购是多值联系，则可以将图书采购联系集建模为采购明细弱实体集(序号为部分码)，它依赖于采购单实体集而存在。这样在一个采购单中可以方便地表示同一种图书以不同价格采购的情况。,图6-5 图书采购业务的建模,图书采购联系集反映的就是采购明细，即一个采购单中采购了哪些图书
20、？每一种图书的采购数量、单价分别是多少？显然在一个采购单的采购明细中，每一种图书只能出现一次。假设同一种图书允许在一个采购单的采购明细中出现多次，即图书采购是多值联系，则可以将图书采购联系集建模为采购明细弱实体集(序号为部分码)，它依赖于采购单实体集而存在。这样在一个采购单中可以方便地表示同一种图书以不同价格采购的情况。,图书采购与图书入库,图书采购到货后需要办理图书入库手续。入库单是依附于采购单的，因此将入库单建模为采购单的弱实体集，属性有入库单号、入库日期，入库单号为部分码。一方面，采购单实体集与入库单弱实体集之间存在一对多的拥有标识联系集。另一方面，图书入库会涉及到职员(采购员和仓库保管
21、员)、图书等基本实体集，入库单弱实体集与图书实体集之间存在多对多的图书入库联系集，联系属性有入库数量。入库单弱实体集与职员(采购员)实体集之间存在多对一的入库联系集；入库单弱实体集与职员(仓库保管员)实体集之间存在多对一的验收联系集。,图6-7 图书采购与图书入库业务的建模,采购单,采购,职员,出版社,供应,采购日期,参照,图书,ISBN,书名,是否入库,采购单号,一个采购单采购的图书可能分多次到货入库，因此，在图书入库联系集与采购明细弱实体集之间需要进行“入库核对”。(1)一笔采购明细可能分多次入库；(2)虽然一笔图书入库只能来自于一个采购单的采购明细，但由于在一个采购单中同一种图书可能在采
22、购明细中出现多次，导致在图书入库中同一种图书的多个采购明细可能需合并入库因此，图书入库联系集与采购明细弱实体集之间的“入库核对”是多对多的,图6-7 图书采购与图书入库业务的建模,采购单,采购,职员,出版社,供应,采购日期,参照,图书,ISBN,书名,是否入库,采购单号,“入库核对”的方法：首先对采购明细弱实体集按采购单号、图书编号汇总采购数量；然后对图书入库联系集按采购单号、图书编号汇总入库数量，如果一个入库单中所有图书的汇总采购数量都等于汇总入库数量，则表示该采购单已入库完毕。可在采购单实体集中增加一个是否入库属性。如果同一个采购单中每一种图书都已入库，则可将采购单实体集中对应实体的是否入
23、库置为“Y”。,目 录,确定联系集及E-R图,需求描述和系统边界,需求分析,确定实体集及属性,检查是否满足需求,逻辑数据库设计,模式求精,主要业务的概念建模分析,发现实体集的步骤,实体集是具有相同类型及相同性质(或属性)的实体集合。通常，一个实体对应一个事物，是名词。发现实体集的步骤可归纳为：找出需求分析中出现的具有一组属性的“名词”；分析这些“名词”信息是否需要存储。对于不需要存储的“名词”不必建模为实体集；分析这些“名词”是否依赖于其它对象存在。如果是，可考虑建模为依赖实体集、弱实体集或联系集。,发现实体集,网上书店系统中的“名词”主要有：会员、职员、图书、出版社、配送公司、订单、配送单、
24、采购单、入库单、订单明细、采购明细、入库明细、购物车、留言和发票等。显然，会员、职员、图书、出版社、配送公司等都是对应为有形的人、物或单位，且都具有一组属性且部分属性能唯一标识每个实体，而且它们需要存储到数据库中供查询用，因此可直接建模为实体集。购物车用于临时存放购书信息，包括选购图书的ISBN、图书名称、订购数量、订购价格。订单成功提交后，购物车中的信息将全部存放到订单中去。故购物车不必建模为一个实体集。,发现实体集,根据6.3节的分析可知，伴随着业务发生而形成的订单、采购单等分别建模为依赖订购、采购业务的依赖实体集；并将配送单建模为依赖于订单的弱实体集，采购明细、入库单都建模为依赖于采购单
25、的弱实体集；而将订单明细、入库明细分别建模为图书订购、图书入库联系集。发票是提供给会员的购书凭证。每张发票有唯一的发票编号。由于每个配送单对应生成一张发票，而且发票并没有太多的属性需要存储，因此这里不将发票建模为实体集，而是将发票编号建模为配送单弱实体集的属性，发票单位建模为订单实体集的属性(假设一个订单生成的一张或多张发票的发票单位相同)。,确定各实体集的属性和主码,确定属性的总原则：只需要将那些与应用相关的特征建模为实体集的属性。对于网上书店，图书的重量、印刷单位等信息不必建模为图书实体集的属性。属性确定后，还要进一步分析属性是简单属性还是复合属性，是单值属性还是多值属性。选择由哪些属性来
26、构成实体集的主码，即能唯一标识各个实体的属性或属性集。当一实体集存在多个候选码时，可按4.3.2中的原则选择主码。确定属性时一个容易犯的错误：一实体集将其它实体集的主码作为其属性，而不是使用联系。换句话说，当一实体集需将另一实体集的主码作为其属性时，需通过建模为联系集来解决。,职员(Employee)实体集。其属性有：职员编号(employeeNo)、登录密码(empPassword)、姓名(empName)、性别(sex)、出生日期(birthday)、部门(department)、职务(title)、薪水(salary)、住址(address)、电话(telephone)、电子邮箱(ema
27、il)等。图6-8为职员实体集的数据字典。,确定各实体集的属性和主码,图6-8 职员(Employee)实体集的数据字典,会员(Member)实体集。其属性有：会员编号(memberNo)、登录密码(memPassword)、姓名(memName)、性别(sex)、出生日期(birthday)、电话(telephone)、电子邮箱(email)、地址(address)、邮政编码(zipCode)、单位(unit)、购书总额(totalAmount)、会员等级(memLevel)、等级购书额定(levelSum)、会员折扣(memDiscount).订单(OrderSheet)实体集。其属性有：
28、订单号(orderNo)、订购日期(orderDate)、应收总金额(amountReceivable)、实收总金额(paidAmount)、会员折扣(memDiscount)、付款方式(payWay)、是否付款(paidFlag)、订单状态(orderState)、发票单位(invoiceUnit).配送单(ShipSheet)弱实体集。其属性有：配送单号(shipNo)、配送日期(shipDate)、收货人(receiver)、送货地址(shipAddress)、邮政编码(zipCode)、联系电话(shipTel)、是否拆送(separatedFlag)、发票编号(invoiceNo)、
29、配送状态(shipState)等。,确定各实体集的属性和主码,采购单(PurchaseSheet)实体集。其属性有：采购单号(purchaseNo)、采购日期(purDate)、采购总金额(purAmount)、是否入库(storedFlag)。采购明细(PurchaseBook)弱实体集。其属性有：序号(serialNo)、采购数量(purQuantity)、采购单价(purPrice)等。入库单(StoreSheet)弱实体集。其属性有：入库单号(storeNo)、入库日期(storeDate)等。图书(Book)实体集。其属性有：书号(ISBN)、书名(bookTitle)、作者(aut
30、hor)、出版日期(publishDate)、版次(version)、类别(category)、库存数量(stockNumber)、定价(price)、图书折扣(bookDiscount)、内容简介(introduction)、目录(catalog)等。,确定各实体集的属性和主码,出版社(Press)实体集。其属性有：出版社编号(pressNo)、出版社名称(pressTitle)、出版社地址(address)、邮政编码(zipCode)、联系人(contactPerson)、联系电话(telephone)、传真(fax)、电子邮箱(email)等。配送公司(Company)实体集。其属性有：
31、公司编号(companyNo)、公司名称(companyTitle)、公司地址(address)、邮政编码(zipCode)、联系人(contactPerson)、联系电话(telephone)、传真(fax)、电子邮箱(email)等。留言(Message)实体集。其属性有：留言编号(messageNo)、留言日期(messageDate)、留言内容(messageContent)、回复日期(replyDate)、回复内容(replyContent)等。,确定各实体集的属性和主码,目 录,确定联系集及E-R图,需求描述和系统边界,需求分析,确定实体集及属性,检查是否满足需求,逻辑数据库设计,
32、模式求精,主要业务的概念建模分析,确定联系集及E-R图,当发现两个或多个实体之间的某种行为需要记录时，可建模为一个联系集。确定联系集的一个重要任务是：分析所建模联系集的映射基数，即参与联系的实体集中的一个实体通过该联系集能同时与另一个实体集中多少个实体相联系(参见4.3.1节)。同实体集一样，联系集也可以有自己的描述属性。要注意的是，联系集已包含了所有参与该联系的实体集的主码属性，故在E-R图中参与联系的实体集的主码属性不要作为联系集的描述属性画出。,确定联系集及属性,图书订购(OrderBook)联系集：它是订单实体集和图书实体集之间的多对多联系集，其描述属性有：订购数量(quantity)
33、、定价(price)、图书折扣(bookDiscount)、已配送数量(shippedQuantity)、配送状态(shipState)。图6-12为图书订购联系集的数据字典。,图6-12 图书订购(OrderBook)联系集的数据字典,确定联系集及属性,订购(Order)联系集：订单实体集和会员实体集之间的多对一联系集，没有联系属性。审核(Check)联系集：订单实体集和职员实体集之间的多对一联系集，没有联系属性。包含(Include)标识联系集：订单实体集和配送单弱实体集之间的一对多联系集，没有联系描述。图书配送(ShipBook)联系集：配送单弱实体集和图书实体集之间的多对多联系集，联系
34、属性有：配送数量(shipQuantity)。分派(Assign)联系集：配送单弱实体集和职员实体集之间的多对一联系集，没有联系属性。配送(Ship)联系集：配送单弱实体集和配送公司实体集之间的多对一联系集，联系属性配送日期(shipDate)、配送状态(shipState)已建模为配送单弱实体集的属性。,确定联系集及属性,组成(Compose)标识联系集：采购单实体集和采购明细弱实体集之间的一对多联系集，没有联系属性。参照(Reference)联系集：采购明细弱实体集和图书实体集之间的多对一联系集，没有联系属性。拥有(Hold)标识联系集：采购单实体集和入库单弱实体集之间的一对多联系集，没有
35、联系属性。采购(Purchase)联系集：采购单实体集和职员实体集之间的多对一联系集，没有联系属性。供应(Supply)联系集：采购单实体集和出版社实体集之间的多对一联系集，没有联系属性。图书入库(StoreBook)联系集：入库单弱实体集和图书实体集之间的多对多联系集，联系属性有：入库数量(quantity)。,确定联系集及属性,入库(Store)联系集：入库单弱实体集和职员实体集之间的多对一联系集，没有联系属性。验收(Accept)联系集：入库单弱实体集和职员实体集之间的多对一联系集，没有联系属性。发布(Release)联系集：会员实体集与留言实体集之间的一对多联系集，联系属性留言日期(r
36、eleaseDate)、留言内容(messageContent)已建模为留言实体集的属性。回复(Reply)联系集：职员实体集与留言实体集之间的一对多联系集，联系属性回复日期(replyDate)、回复内容(replyContent)已建模为留言实体集的属性。属于(Belong)联系集：图书实体集和出版社实体集之间的多对一联系集，没有联系属性。,图6-13 网上书店总E-R图,目 录,确定联系集及E-R图,需求描述和系统边界,需求分析,确定实体集及属性,检查是否满足需求,逻辑数据库设计,模式求精,主要业务的概念建模分析,网上书店总E-R图存在的问题,仔细分析，发现该E-R图存在如下问题：数据冗
37、余。会员等级、等级购书额定、会员折扣等信息在每个会员中都冗余存储。将它独立出来，单独建立会员等级(MemClass)实体集，属性有会员等级(memLevel)、等级购书额定(levelSum)、会员折扣(memDiscount)等。会员与会员等级实体集之间存在多对一的引用(Citation)联系集。如图6-14所示。,网上书店总E-R图存在的问题,业务规则脱离现实需求。例如，如果图书有多个作者，如何处理？读者去思考解决。再如，对于留言的发布与回复，现规定的业务规则为：一会员可发布多条留言，且一留言只能由一会员发布；一留言由某职员至多回复一次，但一职员可以回复多条留言。显然，该业务规则不能较好地
38、满足现实需求。可考虑将留言发布与回复业务的业务规则修改为：一会员可发布多条留言，且一留言只能由一会员发布；对于一条留言(即一个主题)，一职员可以回复多次，也可以多个职员进行回复；其他会员也可对某会员的一条留言进行多次回复，包括会员本人也可对自己已经发布的一条留言进行回复。,网上书店总E-R图存在的问题,分析该业务规则可知：会员(Member)与留言(Message)之间的一对多发布(Release)联系集的语义并没有变化；对于回复业务，不仅留言实体集分别与职员、会员实体集之间存在多对多的回复联系，而且这种回复联系是多值联系，因为一个职员或会员可以对同一条留言进行多次回复。由于回复业务是依赖于留
39、言实体集，且一个留言允许有多个回复，因此，可考虑如下的回复业务建模方案：建立一个留言实体集的留言回复(MessageReply)弱实体集，属性回复编号(replyNo)为部分码，标识联系集是指向(Direct)；在职员实体集与留言回复弱实体集之间存在一对多的回复1(Reply1)联系集，在会员实体集与留言回复弱实体集之间存在一对多的回复2(Reply2)联系集，联系属性均为回复日期(replyDate)、回复内容(replyContent)。,图6-16 改进的网上书店总E-R图,目 录,确定联系集及E-R图,需求描述和系统边界,需求分析,确定实体集及属性,检查是否满足需求,逻辑数据库设计,模
40、式求精,主要业务的概念建模分析,图6-16 改进的网上书店总E-R图,逻辑数据库设计,设计出E-R图后，可根据4.8节所给出的原则将E-R图转换为数据库模式。通常是每个实体集(包括强和弱实体集)都对应于一个关系表。而联系集则应根据映射基数决定具体转换方式。图6-16所示的 E-R图可转为如下数据库模式，其中主码属性加下划线、外码属性加斜体以示区分。,逻辑数据库设计,职员Employee表：由职员(Employee)实体集转化而来。,图6-17 职员Employee表,逻辑数据库设计,会员Member表：由会员(Member)实体集转化而来。,图6-18 会员Member表,逻辑数据库设计,会员
41、等级MemClass表：由会员等级(MemClass)实体集转化而来。,图6-19 会员等级MemClass表,逻辑数据库设计,图书Book表：由图书(Book)实体集和一对多的属于(Belong)联系集共同转化而来。,图6-20 图书Book表,逻辑数据库设计,出版社Press表：由出版社(Press)实体集转化而来。,图6-21 出版社Press表,逻辑数据库设计,配送公司Company表：由配送公司(Company)实体集转化而来,图6-22 配送公司Company表,逻辑数据库设计,留言Message表：由留言(Message)实体集和发布(Release)联系集共同转化而来。,图6-
42、23 留言Message表,逻辑数据库设计,留言回复MessageReply表：由留言回复(MessageReply)弱实体集和一对多的标识联系集指向(Direct)以及一对多的联系集回复1(Reply1)、回复2(Reply2)共同转化而来。,图6-24 留言回复MessageReply表,逻辑数据库设计,订单OrderSheet表：由订单(OrderSheet)实体集以及一对多的订购(Order)、审核(Check)联系集转化而来。,图6-25 订单OrderSheet表,逻辑数据库设计,订单明细OrderBook表：由图书订购(OrderBook)多对多联系集转化而来。,图6-26 订单
43、明细OrderBook表,逻辑数据库设计,配送单ShipSheet表：由配送单(ShipSheet)弱实体集和一对多的包含(Include)标识联系集以及一对多的联系集分派(Assign)、配送(Ship)转化而来。,图6-27 配送单ShipSheet表,逻辑数据库设计,配送明细ShipBook表：由图书配送(ShipBook)多对多联系集转化而来。,图6-28 配送明细ShipBook表,逻辑数据库设计,采购单PurchaseSheet表：由采购单(PurchaseSheet)实体集以及一对多的采购(Purchase)、供应(Supply)联系集转化而来。,图6-29 采购单Purchas
44、eSheet表,逻辑数据库设计,采购明细PurchaseBook表：由采购明细(PurchaseBook)弱实体集和一对多的标识联系集组成(Compose)以及一对多的联系集参照(Reference)转化而来。,图6-30 采购明细PurchaseBook表,逻辑数据库设计,入库单StoreSheet表：由入库单(StoreSheet)弱实体集和一对多的标识联系集拥有(Hold)以及一对多的联系集入库(Store)、验收(Accept)转化而来。,图6-31 入库单StoreSheet表,逻辑数据库设计,入库明细StoreBook表：由图书入库(StoreBook)多对多联系集转化而来。,图6
45、-32 入库明细StoreBook表,目 录,确定联系集及E-R图,需求描述和系统边界,需求分析,确定实体集及属性,检查是否满足需求,逻辑数据库设计,模式求精,主要业务的概念建模分析,模式求精,如果直接根据图6-9所示的会员(Member)实体集的数据字典转化得到一个关系模式，则该关系模式中存在一个对非主属性的函数依赖关系：memLevel levelSum,memDiscount，由此导致的问题是数据冗余，即每一个相同等级会员都需要存放levelSum和memDiscount。该关系模式不满足BCNF范式。据BCNF分解算法，该关系模式可分解为以下2个关系模式：Member(memberNo
46、,memPassword,memName,sex,birthday,telephone,email,address,zipCode,totalAmount,memLevel)MemClass(memLevel,levelSum,memDiscount)这就是图6-18和图6-19所示的关系模式。可以验证，它们都满足BCNF要求，且是无损分解(因为公共属性memLevel是关系MemClass的主码)。,进一步思考,本章给出了一个基本的网上书店的需求分析、概念数据库设计(E-R模型)和逻辑数据库设计(关系数据库模式)的全过程。但是本实例未考虑网上结算与退货等功能，请读者在上述设计基础上，进一步考虑下列功能：增加客户退货功能，客户可在三包期内退货；增加网上结算功能，包括客户存款和结帐付款等；实现图书销售排行榜以及查询畅销图书、滞销图书信息等功能。实现库存管理、成本核算、帐务管理等功能。实现客户关系管理，如实现客户跟踪服务、图书推荐、发现客户的潜在需求等个性化服务功能。,本章结束！,请同学们对本章内容进行复习、总结！,
