数据库系统教学课件：第3讲--概念设计2

1、课程名称课程名称: : 数据库系统数据库系统 -1在现实生活中会经常遇到父类型和子类型，如食品订单 （堂食、外卖）、杂货袋（纸袋、塑料袋）、付款类型 （支票、现金、信用卡）。通常可以将某事物的“选项”与父类型和子类型相关联。 23实体的某些实例通常会有其它实例所没有的属性和（或）关系。假设某项业务需要跟踪顾客的付款方式。顾客可以用现金、支票或信用卡付款。 所有付款方式都有一些共同的属性：付款日期、付款金额等。但只有信用卡具有“卡号”属性。 对于信用卡付款与支票付款，我们可能需要知道是哪位顾客支付的，而对于现金付款，这是不必要的我们是应创建一个“付款”实体，还是应创建“现金”、“支票”和“信用卡

2、”这三个不同的实体？如果以后我们引入第四种付款方式，又会发生什么情况？ 4有时将一个实体细分为若干个子类型 很有意义。这适用于一组实例有特殊 属性的情况，如属性或关系仅存在于 该组中时。在这种情况下，实体称为 “父类型”，每个组称为“子类型”。子类型： 继承父类型的所有属性 继承父类型的所有关系 通常有自己的属性或关系 在父类型中进行绘制 从不独立存在 可以有自己的子类型 也称为“子实体”，如无脊椎动物是没有脊椎的动物（如蚯蚓）。脊椎动物有脊椎，并可细分为鸟类、哺乳类、爬行类等。 5考试是随堂测验、期中考试、期末考试的父类型。子类型有几个共同的属性。将在父类型层列出这些共同属性。这同样适用于关

3、系。子类型继承了父类型实体的所有属性与关系。 当完成实体关系模型时，子类型绝对不会只有一个。换句话说，如果一个实体有一个子类型，则还必须存在第二个子类型。这很有意义。单个子类型与父类型完全相同。这个问题引出了两个子类型规则： 全面性：父类型的每个实例也是某个子类型的一个实例。所有子类型都会毫无遗漏地列出。 相互排斥性：父类型的每个实例只能是一个可能子类型的实例。 6在概念建模阶段，最好包括一个“其它”子类型以确保您的子类型是全面的，包含您正在处理的父类型的每个实例。 7任何实体均可通过创建一个按组细分实例的规则来子类型化。 但是，能够子类型化不是问题 问题是具有子类型化的原因。当业务需要显示各

4、实例间的异同时，需要进行子类型化。 在为父类型与子类型建模时，可以使用三个问题检查是否正确地标识了子类型： 1.该子类型是否是一种父类型？ 2.是否考虑到了所有可能的情况？（全面性） 3.每个实例是否适用于一个且仅 一个子类型？（相互排斥性） 8可以嵌套子类型。为了便于阅读（可读性），通常只显示两层子类型，但是不限制为只能访问两层以内的子类型。 9数据建模的主要目的之一是为了确保发现进行业务活动所需的所有信息。确定和记录业务规则是检查数据模型准确性与完整性的关键。并非所有业务规则都能用实体关系图来表示，认识到这一点很重要。一些业务规则必须通过编程才能实现。10结构性业务规则表明要存储的信息类型

5、以及信息元素是如何相互关联的。 过程性业务规则处理业务的先决条件、步骤、流程或工作流要求。许多过程性业务规则都与时间相关：事件 A 必须发生在事件 B 之前。 结构性业务规则几乎总是能用实体关系图来表示。一些过程性业务规则不能用图进行表示，但仍必须制定相关文档才能在以后对其进行编程。 11结构性业务规则表明要存储的信息类型以及信息元素是如何相互关联的。餐厅的所有订单都必须由一名员工进行处理（尤其指订单受理人）。该餐厅没有自助订餐系统。 学校的所有教师都必须拥有一个有效的教学资格证书。 12我们学校有许多回答下列问题的业务规则： 不分配教师来管理某个班级，这样是否合理/有效？ 两名学生的学生标识

6、号相同，或某名学生没有学生标识号，这样是否合理/有效？ 如果某个班级没有招收到学生，仍安排一个教师来教授这个班级，这样是否合理？ 如果有人没有注册加入任何班级，仍允许其到校，这样是否合理？ 13过程性业务规则是相关的工作流或流程。下面是一些在 “按需 DJ”中必须遵循的流程的示例： 与客户的初次接触必须由项目经理来安排，以确认该活动。项目经理指定负责该活动的活动主管和 DJ。 一个活动的差旅请求必须得到负责该活动的项目经理的签字才能获得批准。 14在开发概念数据模型的过程中，不是所有的业务规则都可以进行建模。 必须通过对与数据交互的过程进行编程来实现某些规则，例如，下面列出的两个规则： 1.对

7、于每周加班时间超过 10 小时的所有雇员，必须按每小时工资的 1.5 倍来支付这些时间的工资。 2.对于帐户余额过期 90 天的客户，不允许其再支付其它订单。 15掩盖属性的关系 l在 DJ 业务中，每个合作伙伴可以分配给一个或多个活动。l每个活动可以由一个或多个合作伙伴来处理。l活动策划者、DJ 或项目经理处理一个活动时，需要记录工作状态。 l那么状态属性应属于哪个实体？ 16解析多对多关系时需要使用第三个实体。此实体称为“交集”实体。添加了交集实体 工作分配，其中包括状态属性。最初的多对多关系已变成了两个一对多关系。那么交集实体的 UID 应是什么？17交集实体的唯一标识符 (UID) 通

8、常来自于最初的关系，并以短线表示。在此情况下，将从初始实体到交集实体的关系称作“限定”关系。18每个电视节目都可以被一人或多人观看。 每个人都可以观看一个或多个电视节目。19每家公司都可以提供一种或多种清洁服务。 每种清洁服务都可以由一家或多家公司提供。20在数据建模中，设计者可以借助弧表明实体的排斥 OR 关系。客户需求定义得越明确，最终的实现就会越准确。 例如：广告牌是一种广告空间，其内容可以是某部电影、某个产品或公告。但在一个时点它只能包含其中一种广告内容。 对于 DJ 业务活动，活动和地点之间具有互斥关系。 21弧是一种用来在实体关系图中表示互斥关系的方法。 例如， 每个活动要么在私人

9、住宅举行，要么在公共场所举行，不能在两处同时举行。弧 一个弧始终属于一个实体。 弧可以包含两个以上的关系。 弧不一定需要包含一个实体的所有关系。 一个实体可以有多个弧。 弧应始终由可选性相同的关系组成。 弧中的所有关系必须均为必需的或均为可选的。 弧中的关系可以有不同的基数，不过这种情况很少见。 22弧有时也可绘制为父类型或子类型。23有时，可以将父类型和子类型绘制为弧。在此图中，DJ 模型中的父类型合作伙伴可以表示为一段弧。 24通常，不同角色按层次结构来组织。例如，在工作中可以分为经理、组长、前台工作人员、后勤，在学校里有校长、副校长、教师、工作人员等。分层数据很常见，了解分层数据有助于您

10、建立以下模型： 企业组织结构图 建筑结构 谱系树以及现实生活中遇到的许多其它层次结构。25可以用以下数据模型来表示一个组织结构图。每个实体的UID 分别是什么？ 26可以用以下数据模型来表示一个组织结构图。每个实体的UID 分别是什么？ 27这两种模型都可以表示所有雇员。左边的模型采用层次结构。右边的模型采用递归关系。一个关系不可以同时是层次关系和递归关系。哪个更好？ 28在这个 DJ 模型中，项目经理全面负责某一活动，并管理从事该活动的其他雇员（活动策划者、DJ）。我们选择使用递归关系表示该层次结构。29在某个汽车制造企业中，假设有一个称为组件的实体，其实例包括所有的基本零件、子组装件、组装

11、件和产品。此模型可以用简单的递归关系表示。以一个多对多递归关系对物料清单数据建模： 每个组件都可以是一个或多个组件的一部分。每个组件都可以由一个或多个组件组成。30你5 岁时有多高？你 10 岁时有多高？你现在身高是多少？如果你父母在你小时候时记下了这些情况，他们就是在跟踪历史数据。大多数企业都需要跟踪某些历史数据。这样有助于发现某些趋势和模式，据此可以进行业务创新和流程改进。 例如，电影的租赁历史记录对录像店很有用。录像店经理可根据这一情况了解哪些电影比较流行，哪些电影应该转移到后面的货架上。 31某组织需要保留有关雇员薪金的数据。所有雇员都拿周薪。起初，建立了以下雇员实体模型。 现在有了一

12、些附加要求，即，该组织需要保留雇员在职期间薪金变化幅度及变化时间的历史记录。 32要建立薪金随时间变化的模型，需要添加薪金历史记录实体。薪金历史记录实体的 UID 为相关的雇员标识和薪金开始日期。 33珠宝商店向电影明星租赁饰件（项链、手镯等）以用于特殊场合（例如颁奖典礼或电影首映式）。珠宝商店想要跟踪珠宝饰件的租赁历史记录。以下实体关系模型仅跟踪一件珠宝的当前租赁者。如何修改此关系以跟踪历史记录？ 34应该将珠宝饰件和电影明星之间的关系修改为多对多 (M:M)，然后使用交集实体租赁历史记录来解析。 租赁历史记录的 UID 是什么？35租赁历史记录的 UID 是租赁开始日期和珠宝饰件 UID

13、的组合（如限定关系所示）。36请阅读下面 DJ 业务活动的完整业务方案。然后检查完成的实体关系图。 一开始我们是一群组织聚会和定制我们自己的音乐的朋友。后来我们想，我们可以将其变成一项业务，这样我们既可 从事我们喜欢的工作，又可以赚一些钱。我们自称为“按 需 DJ”。这里工作的每个人都是合作伙伴。每个合作伙伴都有特定的责任。项目经理与客户进行第一次接触，讨论具体活动。是生日聚会、婚礼、周年纪念还是毕业典礼？聚会或活动什么时候举行？ 37一旦决定下来，活动策划者就会与客户进行联系，讨论具体的地点、餐饮的供应、装饰以及其他具体细节。DJ 与客户讨论他们喜欢的音乐风格。项目经理监督活动策划者和 DJ

14、。项目经理还负责批准与项目相关的支出。我们收藏了很多 CD。每张 CD 都包含若干首歌曲，相同的歌曲可能出现在数张 CD 上。我们希望按照类型（街头音乐、萨尔萨音乐、节奏蓝调、电子摇滚乐、波尔卡音乐、摇滚、爵士、新世纪音乐、古典音乐等）对歌曲进行分类。38我们可以根据活动向客户建议一些初选的歌曲。当然，客户也可以要求提供其它歌曲。 我们的客户越来越多。我们有很多回头客 一些对我们的业务很满意的客户要求我们为他们的其它活动提供服务.我们还有一些非常忙碌的客户，他们会在同一时间举办多场活动。 39我们还有一个主题列表，可以使用该列表对这些活动分类。例如：婚礼可能会有一个热烈的主题，聚会可能会有一个

15、狂欢的主题，周年纪念可能会有一个庆祝六十年的主题等。这些信息有助于我们选择地点，还会帮助 DJ（和其他乐师）选择适当的穿着。一些合作伙伴有自己的专长和专业技术，因此主题还可以帮助我们分配适合该工作的人员。40活动可能会在公共场所或私人住宅内举行。活动的经理需要与双方碰面，并与公共场所的出租人或私人住宅的所有者达成协议。 由于可能有多个合作伙伴同时为一个活动工作，而一个活动可能被分配给多个合作伙伴，因此我们需要跟踪谁为哪个活动工作。我们将保留一份记录，其中包含每个活动策划者和 DJ 在活动中完成的工作和完成时间。41分组讨论并画出上述DJ业务方案的ER图42Step 1:识别实体的属性Step 2：识别歌曲与类型实体的之间的关系类型1. 每首歌曲必须属于一种类型吗？2. 你可能会有一首不属于任何类型的歌曲吗？如果遇到这种情况，该怎么处理？3. 每种类型必须描述一首歌曲吗？4. 一种类型可以包含多少歌曲？5. 识别两个实体的属性Step3：识别客户，活动，和类型实体之间的关系Step4：过程业务规则 如：只有项目经理能修改活动决定之后客户提出的细节修改要求； 只有活动策划者能安排活动地点 所有的商业广告必须经理同意43Step5：解决多对多关系 歌曲和CD之间用曲目列表这个交集实体联系 合作伙伴与活动之间用工作分配状态这个交集实体联系Step 6