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

目 录 确定联系集及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)、订单状态(orderS