关系数据库设计实例课件.ppt

《关系数据库设计实例课件.ppt》由会员分享，可在线阅读，更多相关《关系数据库设计实例课件.ppt（59页珍藏版）》请在三一办公上搜索。

1、目 录,确定联系集及E-R图,需求描述和系统边界,定义需求分析,确定实体集及属性,检查是否满足需求,逻辑数据库设计,模式求精,基于B2C的网上书店系统需求描述,该系统支持4类用户：游客、会员、职员和系统管理员。游客可以随意浏览图书及网站信息，但只有在注册为网站会员后才能在线购书。游客注册成功后即为普通会员，当其购书金额达到一定数量时可升级为不同等级的VIP会员，以享受相应的优惠折扣。会员登录系统后，可通过不同方式(如书名、作者、出版社等)搜索图书信息、网上订书、在线支付、订单查询与修改，发布留言等。,基于B2C的网上书店系统需求描述,书店工作人员以职员身份注册登录后，可维护与发布图书信息、处理

2、订单、安排图书配送和处理退货等。系统管理员的主要职责是维护注册会员和职员信息。请为该网上书店设计数据库E-R图和关系模式。要求保存所需全部信息，并高效地支持上述各种应用。由于网上书店功能比较复杂，本设计不考虑网上支付和退货等功能 确定系统边界。,目 录,确定联系集及E-R图,需求描述和系统边界,定义需求分析,确定实体集及属性,检查是否满足需求,逻辑数据库设计,模式求精,业务需求及处理流程,业务需求分析是根据现实世界对象需求，描述应用的具体业务处理流程，并分析哪些业务是计算机可以完成的，而哪些业务是不能由计算机完成的。网上书店主要业务包括：图书信息发布与查询、订购图书、处理订单并通知配送公司送书

3、等。本节只给出网上书店的核心业务“订单生成”及“订单受理”处理流程。常见的网上书店一般包括哪些业务功能？,图6.1 网上书店的主要业务流程,功能需求及数据需求分析,注册管理会员注册。会员注册时要求填写基本信息，包括姓名、性别、出生年月、地址、邮政编码、电话、电子邮箱、登录密码等信息。系统检查所有信息填写正确后提示会员注册成功，并返回会员编号。职员注册。书店工作人员以职员身份注册并填写基本信息，包括姓名、性别、出生年月、部门、薪水、住址、电话、电子邮箱、登录密码等信息。系统检查所有信息填写正确后提示注册成功，并返回职员编号。图书管理增加图书信息。当有新书发布时，书店职员负责添加和发布图书信息，包

4、括ISBN、书名、作者、版次、类别、出版社、出版年份、定价、售价、内容简介、目录等。图书信息查询。网站需提供多种方便快捷方式进行图书检索，如既可输入指定关键词进行简单查询，也可根据ISBN、书名、作者、出版社、出版年份等单一或组合条件进行查询图书信息更新及删除。图书信息发布后，职员可随时更新和删除图书信息。,功能需求及数据需求分析,在线订书会员登录网站后，将需订购的图书放入购物车中并填写购买数量。购物车内的图书可以随意增加、删除和修改数量，并能即时统计购物车内的图书总价格。选书完成后，会员还需填写配送信息、发票单位及选择支付方式(在线支付或上门付款)。配送信息默认为会员注册时填写的基本信息，也

5、可填写新的配送信息，包括收货人、送货地址、邮政编码及联系电话等。确认所填写的信息无误后，则提交生成订单。每张订单要求记录订单号(按时间顺序生成)、客户号、订书日期、订书总金额、收货人、送货地址、邮政编码、联系电话、付款方式、订单状态、订单明细(包括书号、书名、数量、价格)和发票单位等。如果选择了在线支付方式，则还需进行网上结算。若余额不足，则取消订单(本设计不作考虑)。,功能需求及数据需求分析,订单管理订单查询。订单提交后，会员可随时查询订单的最新状态以及全部历史订单。订单取消及更新。订单未审核前，允许会员取消订单及更新订单信息。订单受理。订单生成后，职员对订单进行审核。如发现订单信息填写不正

6、确，则退回客户重新填写。如正确无误，则安排配送。配送管理一张订单所订购的图书可拆分成不同的配送单发货。每张配送单包括配送单编号、收货人、送货地址、邮政编码、联系电话、送书明细(包括书名及数量)，并填写一张发票。发票内容包括发票单位、业务摘要、总金额等信息。,功能需求及数据需求分析,出版社管理网上书店直接从出版社采购图书。为方便查询出版社信息，要求保存和维护出版社信息，包括出版社编号、出版社名称、出版社地址、邮政编码、联系人、电话、传真、电子邮箱等属性。配送公司管理网上书店通过配送公司将图书送到会员手中。为方便查询配送公司信息，要求保存和维护配送公司信息，包括公司编号、公司名称、公司地址、邮政编

7、码、联系人、电话、传真、电子邮箱等属性。,功能需求及数据需求分析,留言管理发布留言。会员可在网站发表留言或评论。留言需记录留言人、留言内容、发布时间等信息。回复留言。书店职员可回复留言，并记录回复人、回复时间及回复内容等。用户管理会员升级。系统可对会员进行分级，即当会员订书总金额到达一定数额后成为不同级别的用户，以享受相应的优惠折扣。会员信息维护。系统管理员及会员可修改、删除和更新会员信息。职员信息维护。系统管理员及职员可修改、删除和更新职员信息。,业务规则分析,业务规则分析主要是分析数据之间的约束以及数据库约束。网上书店业务规则如下：所有用户均可搜索图书信息，但只有注册会员才能提交订单；只有

8、注册职员才能维护图书信息及受理订单。每位会员由会员编号唯一标识，会员编号由系统按时间顺序生成。每位职员由职员编号唯一标识，职员编号由系统按时间顺序生成。当普通会员购书总额达到10000元，即升级为三级VIP会员，享受售价9.5折优惠；购书总额达到20000元，升级为二级VIP会员，享受售价9折优惠；购书总额达到30000元，升级为一级VIP客户，享受售价8.5折优惠。ISBN是图书的唯一标识。系统需记录每种图书的当前库存数量，当库存量低于某一阈值时，则通知补货。,业务规则分析,选购的图书必须放入购物车后才能生成订单。每个订单用订单编号唯一标识。订单编号由系统按时间顺序生成，后提交的订单具有更大

9、的订单号。订单需记录当前状态，包括未审核、退回、已审核、已处理结束等状态。同一订单可订购多种图书，且订购数量可以不同。因此，一张订单可包括多个书目明细，包括ISBN、图书名称、订购数量、订购价格。订单中的每种图书需记录其状态，包括未送货、已送货、已送到等状态。订单受理前允许会员删除所选图书，修改购书数量、配送信息和发票单位，甚至取消订单。但是订单审核通过后，则不允许再做任何修改。,业务规则分析,订单中的图书采取先到先发货原则。若一订单中的图书未同时有货，可拆分成不同配送单发货；但是，一订单中的某种图书只有库存有足够存书时才能安排配送。配送单由配送单编号标识。每个订单的配送单编号是由订单编号加上

10、系统按时间顺序生成的流水号组成。每张配送单对应一张发票。发票用发票的实际编号唯一标识。当订单中的某种图书送到后，则更新该书的状态为“已送到”。当订单内全部图书状态为“已送到”时，则更新该订单状态为“已处理结束”。一种图书只由一个出版社出版，而一个出版社可出版多种图书。一个会员可发表多条留言，一个职员可回复多条留言。,目 录,确定联系集及E-R图,需求描述和系统边界,定义需求分析,确定实体集及属性,检查是否满足需求,逻辑数据库设计,模式求精,发现实体集的步骤,实体集是具有相同类型及相同性质(或属性)的实体集合。通常，一个实体对应一个事物，是名词。发现实体集的步骤可归纳为：找出需求分析中出现的具有

11、一组属性的“名词”；分析这些“名词”信息是否需要存储。对于不需要存储的“名词”不必建模为实体集；分析这些“名词”是否依赖于其它对象存在。如果是，可考虑建模为联系或弱实体集。,网上书店系统实体集发现,网上书店系统中出现的“名词”主要有：会员、职员、图书、出版社、配送公司、留言、购物车、订单、配送单和发票等。会员、职员、图书、出版社、配送公司、留言等都具有一组属性且部分属性能唯一标识每个实体，而且它们需要存储到数据库中供查询用，因此可直接建模为实体集。购物车用于临时存放购书信息，包括选购图书的书号、名称、订购数量和订购价格。订单成功提交后，购物车中的信息将全部存放到订单中去。当客户放弃购书不生成订

12、单时，购物车信息不需保留。由于购物车中的信息无需查询，故不必建模为一个实体集。,网上书店系统实体集发现,订单是网上书店的一个重要“名词”，用于记录一次订书的全部信息。按上述规则，由订单编号唯一标识不同订单，故订单可建模为一个实体集。但另一方面，订单又反映了会员与图书之间的一种“订书”联系，反映“谁什么时候订购了什么图书，订购了多少”等信息，它对会员和图书具有一定的“依赖”关系。因此，直观上将订单建模为会员与图书之间的联系集更为合适。同理，也可将配送单建模为配送公司与图书之间的联系集。发票是提供给会员的购书凭证。每张发票有唯一的发票号，并具有一组属性，故可建模为实体。,确定各实体集的属性和主码,

13、确定属性的总原则是，只需要将那些与应用相关的特征建模为实体集的属性。对于网上书店，图书的重量、印刷单位等信息不必建模为图书实体集的属性。确定了属性后，还要进一步分析属性是简单属性还是复合属性，是单值属性还是多值属性。选择由哪些属性来构成实体集的主码，即能唯一标识各个实体的属性或属性集。当一实体集存在多个候选码时，可按4.3.2中的原则选择主码。确定属性时一个容易犯的错误是：一实体集将其它实体集的主码作为其属性，而不是使用联系。换句话说，当一实体集需将另一实体集的主码作为其属性时，需通过建模为联系来解决。,网上书店系统实体集及属性,职员(Employee)实体集：,网上书店系统实体集及属性,职员

14、(Employee)实体集：,网上书店系统实体集及属性,会员(Member)实体集：,网上书店系统实体集及属性,图书(Book)实体集：,网上书店系统实体集及属性,图书(Book)实体集：,网上书店系统实体集及属性,出版社(Press)实体集：,网上书店系统实体集及属性,配送公司(Company)实体集：,网上书店系统实体集及属性,留言(Message)实体集：,网上书店系统实体集及属性,发票(Invoice)实体集：,目 录,确定联系集及E-R图,需求描述和系统边界,定义需求分析,确定实体集及属性,检查是否满足需求,逻辑数据库设计,模式求精,确定联系集及E-R图,当发现两个或多个实体之间的某

15、种行为需要记录时，可建模为一个联系集。确定联系集的一个重要任务是分析所建模联系集的映射基数，即参与联系的实体集中的一个实体通过该联系集能同时与另一个实体集中多少个实体相联系(参见4.5节)。同实体集一样，联系集也可以有自己的描述属性。要注意的是，联系集已包含了所有参与该联系的实体集的主码属性，故在E-R图中参与联系的实体集的主码属性不要作为联系集的描述属性画出。,确定联系集,网上书店系统联系集会员和图书之间的“订书(Order)”联系集，一个多对多联系。配送公司与图书之间的“配送(Ship)”联系集，多对多联系。出版社与图书之间的“供应(Supply)”联系集，一对多联系。会员与留言之间的“发

16、布(Release)”联系集，一对多联系。职员与留言之间的“回复(Reply)”联系集，一对多联系。发票与图书之间的“包含(Include)”联系集，多对多联系。包括上述设计的全部实体集、联系集及其描述属性的E-R图如图6-9所示。注意，图中省略了实体集属性。,目 录,确定联系集及E-R图,需求描述和系统边界,定义需求分析,确定实体集及属性,检查是否满足需求,逻辑数据库设计,模式求精,网上书店总E-R图存在的问题,仔细分析，发现该E-R图存在如下问题：会员不能在不同订单里订购同一种图书；配送公司不能在不同配送单中配送同一种书；当一次订购多种图书时，联系集Order中存在大量信息冗余；未反映配送

17、单对订单的依赖关系；未反映配送单与发票之间的一对一联系。可考虑将订单建模为实体集OrderSheet，将配送单建模为依赖于订单的弱实体集ShipSheet。事实上，在上节我们就可以将它们建模为实体集。,新增实体集,订单实体集OrderSheet：,新增实体集,订单实体集OrderSheet：,新增实体集,配送单号是依赖于订单编号生成的流水号，不能唯一标识任一配送单，因此ShipSheet应建模为弱实体集。配送单ShipSheet弱实体集：,联系集调整,基于新增的实体集，联系集也重新调整如下：图书与订单之间建立多对多联系集Order；会员与订单之间建立一对多联系集Sale；职员与订单之间建立一对

18、多联系集Deal；订单与配送单之间建立标识联系集Have；配送公司与配送单之间建立一对多联系集Take；发票与配送单之间建立一对一联系集Own；配送单与图书之间建立多对多联系集Ship。修改后的完整网上书店E-R图如图6-12所示。,Press,Supply,Book,Sale,OrderSheet,Member,Order,Employee,Deal,Release,Message,Reply,releaseDate,replyContent,quantity,bookState,Ship,Have,ShipSheet,Invoice,orderDate,Own,replyDate,Comp

19、any,Take,图6-12 更新后的网上书店总E-R图,supplyDate,supplyNo,Press,Supply,Book,Sale,OrderSheet,Member,Order,Employee,Deal,Release,Message,Reply,releaseDate,replyContent,quantity,bookState,Ship,Have,ShipSheet,Invoice,orderDate,Own,replyDate,Company,Take,图6-12 更新后的网上书店总E-R图,supplyDate,supplyNo,目 录,确定联系集及E-R图,需求描述

20、和系统边界,定义需求分析,确定实体集及属性,检查是否满足需求,逻辑数据库设计,模式求精,逻辑数据库设计,设计出E-R图后，可根据4.6节所给出的原则将E-R图转换为数据库模式。通常是每个实体集(包括强和弱实体集)都对应于一个关系表。而联系集则应根据映射基数决定具体转换方式。图6-12所示的 E-R图可转为如下数据库模式，其中主码属性加粗体和下划线、外码属性加粗斜体以示区分。,逻辑数据库设计,职员表Employee：由Employee强实体集转化而来。,图6-13 职员表Employee,逻辑数据库设计,会员表Member：由Member强实体集转化而来。,图6-14 会员表Member,逻辑数

21、据库设计,图书表Book：由Book强实体集和Supply联系集共同转化而来。,图6-15 图书表Book,逻辑数据库设计,出版社表Press：由Press强实体集转化而来。,图6-16 出版社表Press,逻辑数据库设计,表留言Message：由Message强实体集和Release、Reply两个联系集共同转化而来。,图6-17 留言表Message,逻辑数据库设计,订单表OrderSheet：由OrderSheet强实体集以及Deal、Order联系集转化而来，如图6-18所示。由于联系集Deal、Order都为一对多联系，故都可合并到OrderSheet表中来,图6-18 订单表Ord

22、erSheet,逻辑数据库设计,订单明细表Sale：由多对多联系集Sale转化而来。,图6-19 订单明细表Sale,逻辑数据库设计,配送公司表Company：由Company强实体集转化而来。,图6-20 配送公司表Company,逻辑数据库设计,配送单表ShipSheet：由ShipSheet弱实体集以及Own、Take联系集转化而来。由于Own为一对一联系，Take为一对多联系，故可合并到ShipSheet表中来,图6-21 配送单表ShipSheet,逻辑数据库设计,配送明细表Ship：由Ship联系集转化而来。由于Ship为多对多联系集，不能与任一实体集合并，故单独建立一个表。,图6

23、-22 配送明细表Ship,逻辑数据库设计,发票表Invoice：由强实体集Invoice转化而来。,图6-23 发票表Invoice,目 录,确定联系集及E-R图,需求描述和系统边界,定义需求分析,确定实体集及属性,检查是否满足需求,逻辑数据库设计,模式求精,模式求精,Member关系模式中存在一个对非主属性的函数依赖关系：memLeveldiscount，由此导致的问题是数据冗余，即每一个相同等级会员都需要存放discount信息。该模式不满足BCNF范式。因此，需要对Member进行分解。依据BCNF分解算法，Member可分解为以下两个模式：NewMember(memberNo,mem

24、Password,memName,sex,birthday,telephone,email,address,zipCode,totalAmount,memLevel)MemberLevel(memLevel,discount)可以验证，关系模式NewMember和MemberLevel都满足BCNF要求，且分解是无损分解(因为公共属性memLevel是MemberLevel的主码)。,模式导航图,Press,Supply,Book,Sale,OrderSheet,Member,Order,Employee,Deal,Release,Message,Reply,releaseDate,reply

25、Content,quantity,bookState,Ship,Have,ShipSheet,Invoice,orderDate,Own,replyDate,Company,Take,图6-12 更新后的网上书店总E-R图,supplyDate,supplyNo,E-R图,进一步思考,本章给出了一个基本的网上书店的需求分析、概念数据库设计(E-R模型)和逻辑数据库设计(关系数据库模式)的全过程。但是本实例未考虑网上结算与退货等功能，请读者在上述设计基础上，进一步考虑下列功能：增加客户退货功能，客户可在三包期内退货；增加网上结算功能，包括客户存款和结帐付款等；实现图书销售排行榜和查询畅销图书、滞销图书信息等功能。实现图书采购和库存管理等功能。实现客户关系管理，如实现客户跟踪服务、图书推荐、发现客户的潜在需求等个性化服务功能。,本章结束！,请同学们对本章内容进行复习、总结！,