您的位置:知识库 » 数据库

数据库设计

作者: DBFocus  来源: 博客园  发布时间: 2011-05-21 12:09  阅读: 7120 次  推荐: 0   原文链接   [收藏]  
摘要:数据库设计 Step by Step (3)中我们讨论了基本实体关系模型构件及其语义。这些概念非常重要,是今天这一讲的基础,在开始本文内容之前建议大家可以再回顾一下上一篇的内容。今天我们将讨论高级实体关系模型构件,与上一篇一起涵盖了ER模型构图的大部分内容。三元关系是今天这一讲的难点,大家可以重点关注。

  上一篇:数据库设计 Step by Step (3)

image  泛化(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  Individual与Employee、Customer之间的泛化关系

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

  聚合(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  排他性约束关系图例

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

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

  2. 一个实体可以是一个人,地方,东西或事件

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

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

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

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

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

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

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

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

0
0

数据库热门文章

    数据库最新文章

      最新新闻

        热门新闻