网上书店数据库设计实例.ppt

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