当前位置:  首页  >  PHP教程  >  PHP 基础  >  环境

数据库设计StepbyStep(4)高级ER模型构件

引言:数据库设计StepbyStep(3)中我们讨论了基本实体关系模型构件及其语义。这些概念非常重要,是今天这一讲的基础,在开始本文内容之前建议大家可以再回顾一下上一篇的内容。今天我们将讨论高级实体关系模型构件,与上一篇一起涵盖了ER模型构图的大部分

引言:数据库设计 Step by Step (3)中我们讨论了基本实体关系模型构件及其语义。这些概念非常重要,是今天这一讲的基础,在开始本文内容之前建议大家可以再回顾一下上一篇的内容。今天我们将讨论高级实体关系模型构件,与上一篇一起涵盖了ER模型构图的大部分

引言:数据库设计 Step by Step (3)中我们讨论了基本实体关系模型构件及其语义。这些概念非常重要,是今天这一讲的基础,在开始本文内容之前建议大家可以再回顾一下上一篇的内容。今天我们将讨论高级实体关系模型构件,与上一篇一起涵盖了ER模型构图的大部分内容。三元关系是今天这一讲的难点,大家可以重点关注。

泛化(Generalization):超类型与子类型

原始的ER模型已经能描述基本的数据和关系,但泛化(Generalization)概念的引入能方便多个概念数据模型的集成。

泛化关系是指抽取多个实体的共同属性作为超类实体。泛化层次关系中的低层次实体——子类型,对超类实体中的属性进行继承与添加,美国服务器,子类型特殊化了超类型。

ER模型中的泛化与面向对象编程中的继承概念相似,但其标记法(构图方式)有些差异。

下图表示员工与经理、工程师、技术员、秘书之间的泛化关系。Employee为超类实体,并包含共同属性,Manager、Engineer、Technician、Secretary都是Employee的子类实体,它们能包含自身特有的属性。

image

图1 Employee与Manager、Engineer、Technician、Secretary之间的泛化关系

泛化可以表达子类型的两种重要约束,重叠性约束(disjointness)与完备性约束(completeness)。

重叠性约束表示各个子类型之间是否是排他的。若为排他的则用字母“d”标识,否则用“o”标识(o -> overlap)。图1中各子类实体概念上是排他的。

对员工、客户实体进行泛化,抽象出超类实体个人,得到如下关系图。由于部分Employee也可能是Customer,故子类实体Employee与Customer之间概念是重叠的。

image

图2 Inpidual与Employee、Customer之间的泛化关系

完备性约束表示所有子类型在当前系统中是否能完全覆盖超类型。若能完全覆盖则在超类型与圆圈之间用双线标识(可以把双线理解为等号)。在图2中子类实体Employee与Customer能完全覆盖超类Inpidual实体。

聚合(Aggregation)

聚合是与泛化抽象不同的另一种超类型与子类型间的抽象。

泛化表示“is-a”语义,聚合表示“part-of”语义。聚合中子类型与超类型间没有继承关系。

聚合关系的标记法是在圆圈中标识字母“A”来表示。

下图表示软件产品由程序与用户手册组成。

image

图3 Software-product与Program、User’s Guide之间的聚合关系

三元关系(Ternary Relationships)

当通过二元关系无法准确描述三个实体间的联系时,我们需要使用三元关系。

三元关系中“连通数”的确定方法:

a) 以三元关系中的一个实体作为中心,假设另两个实体都只有一个实例

b) 若中心实体只有一个实例能与另两个实体的一个实例进行关联,则中心实体的连通数为“一”

c) 若中心实体有多于一个实例能与另两个实体实例进行关联,则中心实体的连通数为“多”

注:什么时候需要使用三元关系的实例请参看:数据库设计 Step by Step (3)中的“关系的度(Degree of a Relationship)”小节。关系的“连通数”概念请参看:数据库设计 Step by Step (3)中的“关系的连通数(Connectivity of a Relationship)”小节。

我们来看几个三元关系的实例,注意各个图中关系的度,并理解其中的语义。

image

图4 技术员在项目中使用手册的关系

图4中蕴含的语义为:

a) 一名技术员对于每一个项目使用一本手册

b) 每一本手册对于每一个项目属于一名技术员

c) 一名技术员可能在做多个项目,对于不同的项目维护不同的手册

用数学中的函数依赖表示图4的关系:

a) emp-id, project-name -> notebook-no

b) emp-id, notebook-no -> project-name

c) project-name, notebook-no -> emp-id

image

图5 员工被分配不同地点的项目之间的关系

图5中蕴含的语义为:

a) 每一个员工在一个地点只能被分配一个项目,但可以在不同地点做不同的项目

b) 在一个特定的地点,一个员工只能做一个项目

c) 在一个特定的地点,一个项目可以由多个员工来做

用数学中的函数依赖表示图5的关系:

a) emp-id, loc-name -> project-name

b) emp-id, project-name -> loc-name

image

图6 经理管理项目与工程师的关系

图6中蕴含的语义为:

a) 一名经理手下的一名工程师可能参与多个项目

b) 一名经理管理的一个项目可能会有多名工程师

c) 做某一个项目的一名工程师只会有一名经理

用数学中的函数依赖表示图6的关系:

a) project-name, emp-id -> mgr-id

image

图7 员工在项目中使用技能的关系

图7中蕴含的语义为:

a) 一名员工在一个项目中可以使用多种技能

b) 一名员工的一种技能可以在多个项目中使用

c) 一种技能在一个项目中可以被多名员工使用

图7各实体之间没有函数依赖

上述4种形式的三元关系,连通数为“一”的实体数量与该三元关系反映的函数依赖语义的数目一致。

三元关系也能有属性。属性值由三个实体的键的组合唯一确定。

n元关系(General n-ary Relationships)

三元关系可以扩展到n元关系,描述n个实体之间的关系。

一般而言,n元关系中每一个连通数为“一”的实体的键都会出现在一个函数依赖表达式的右侧。

对于n元关系,使用语言来表达其中的约束相对较为困难。建议使用数学形式即函数依赖(FD)来表现。

n元关系的函数依赖条目数量与关系图中“一”端实体的数量相同(0~n条)。

n元关系的函数依赖表达式包含n个元素,n-1个元素出现在表达式左侧,1个元素出现在右侧。

image

图8 n元关系图例

排他性约束(Exclusion Constraint)

一般(默认)情况下,多种关系之间是兼容的“或”关系,即允许任意或所有实体参与这些关系。

在某些情况下,多种关系之间是非兼容性“或”关系,即参与关系的实体只能选择其中一种关系,不能同时选择多种关系。

下图表示的语义为:一项工作任务要么被归为外部项目中,要么被归为内部项目中,不可能同时属于外部项目和内部项目。

image

图9 排他性约束关系图例

我们对上一篇数据库设计 Step by Step (3)与本篇的重点内容做一个总的回顾

1. 我们讨论了ER模型及构图的基本概念

2. 一个实体可以是一个人,地方,免备案空间,东西或事件

3. 属性是实体的描述信息

4. 属性可以是唯一标识或非唯一的描述

5. 关系描述了实体之间“一对一”,“一对多”,“多对多”的联系

6. 关系的度反映了参与关系的实体数量,如二元关系,三元关系,n元关系

7. 角色(名)定义了一个实体在一个关系中所具有的功能

8. 关系的存在概念表示一个实体在关系中是强制存在还是可选的

9. 泛化允许把实体抽象成超类与子类

10. 三元关系可使用函数依赖来定义

,香港服务器
吐了个 "CAO" !
扫码关注 PHP1 官方微信号
PHP1.CN | 中国最专业的PHP中文社区 | PHP资讯 | PHP教程 | 数据库技术 | 服务器技术 | 前端开发技术 | PHP框架 | 开发工具 | PHP问答
Copyright © 1998 - 2020 PHP1.CN. All Rights Reserved PHP1.CN 第一PHP社区 版权所有