第2章 数据模型 2.1 实体联系模型 2.2 关系模型 2.3 面向对象的数据模型 习 题 2
2.1 实体―联系模型 不同的数据模型提供给我们模型化数据和信息的不同工具。 根据模型应用的不同目的， 可以将这些模型划分为两个层次: 一类模型是概念模型， 也称信息模型， 它是按用户的观点来对数据和信息建模， 主要用于数据库设计; 另一类模型是数据模型， 主要包括网状模型、 层次模型、 关系模型等， 它是按计算机系统的观点对数据建模， 主要用于DBMS的实现。
概念模型是对信息世界建模， 所以概念模型应该能够方便、 准确地表示出信息世界中的常用概念。 概念模型的表示方法很多， 其中最常用的是P．P．S．Chen于1976年提出的实体-联系方法(Entity―Relationship Approach)。 该方法用E―R图来描述现实世界的概念模型， E―R方法也称为E―R模型。
实体―联系(E―R)数据模型是基于对现实世界的这样一种认识: 世界由一组称作实体的基本对象及这些对象间的联系组成。 E―R模型是一种语义模型， 模型的语义方面主要体现在模型力图去表达数据的意义。
2.1.1 基本概念 E―R数据模型所采用的概念主要是三个: 实体集、 联系集和属性。 1． 实体（entity） 实体是对现实世界中客观存在并可互相区别的“事件”或“物体”的抽象。 实体可以是具体的人、 事、 物， 也可以是抽象的概念或联系， 例如， 学校中的每个人是一个实体， 一个系、 一门课， 学生的一次选课也是一个实体。 实体集是具有相同类型及相同性质(或属性)的实体集合。
例如， 全体学生就是一个实体集， 全部课程也是一个实体集。 实体集可以相交。 例如， 假设某些教师在本校在职学习， 那么他们既是教师身份， 也是学生身份， 说明学生实体集和教师实体集是相交的。
2． 属性(attribute) 实体一般具有若干特征， 称之为实体的属性。 实体通过一组属性来表示， 而属性是实体集中每个成员具有的描述性性质。 例如学生具有姓名、 学号等属性。 每个属性都有其取值的范围， 在E-R数据模型中称为值集(value set)或域。 例如， 实体学生的属性姓名的域可能是某个长度的所有字符串的集合， 属性成绩的域可能是所有正整数的集合。
在同一实体集中， 每个实体的属性及其域是相同的， 但可能取不同的值。 一个实体是由其属性的值确定的。 例如， 实体班级（班级号， 班级名）属性的一个取值（10002， 计算机881）就确定了计算机881班这个实体。 在E―R模型中， 根据属性取值的不同种类， 可将属性划分为如下的几种类型: (1) 简单属性: 指它们不能再划分为更小的部分。 例如, 课程名是简单属性。
(2) 复合属性: 指它们可以再划分为更小的部分(即划分为别的属性)。 例如， 出生日期可被设计成包括出生年、 月、 日的成分属性， 它是复合属性。 如果用户希望在某些时候访问整个属性， 而在另一些时候访问属性的一个成分， 那么在设计模式中使用复合属性是一个很好的选择。 通过复合属性可将相关属性聚集起来， 使模型更清晰。 (3) 单值属性: 指所定义的属性对一个特定实体都只有单独的—个值。 例如， 学号属性只对应一个学号号码。
(4) 多值属性: 指对某个特定实体而言， 一个属性可能对应于一组值。 例如， 假设实体学生还有社会关系这个属性， 那么一个学生可能有0个、 1个或多个亲属， 该实体集中不同的学生实体在属性社会关系上有不同数目的值， 这样的属性称多值属性。 在具体设计中， 可根据应用需求对某个多值属性的取值数目进行上、 下界的限制。 例如， 上述学生社会关系属性限制在6个以内。
(5) NULL属性: 当实体在某个属性上没有值或属性值未知时使用NULL值。 例如， 某个学生无亲属， 那么该学生的社会关系属性值是NULL， 表示“无意义”。 NULL用于值未知时， 未知的值可能是缺失的(即值存在， 只不过我们没有该信息)或不知道的(我们并不知道该值是否真的存在)。
(6) 派生属性: 这类属性的值可以从别的相关属性或实体派生出来。 例如， 学生的年龄可以通过其出生日期计算出来。 形式化地说， 实体集的属性是将实体集映射到域的函数。 从数学上看， 每个属性可以看成是一个函数。 设A是实体集E的一个简单属性， v是A的值集， 则A可定义为函数 A: E→P(v) P(v)是v的幂集。 A(e)表示E中实体E的属性A的值。
从定义可知， A(e)可以是单值， 也可以是多值， 还可以是NULL(相当于空集)。 如果A是组合属性， 设其各分量的值集为v1, v2, …, vn， 则A可定义为函数 A: E→P(v1)×P(v2) ×…×P(vn) 由于一个实体集可能有多个属性， 每个实体可以用(属性， 数据值)对构成的集合来表示， 对应实体集的每个属性有一个(属性， 数据值)对。 从这里可以看出抽象模式与作为建模对象的现实世界的事实间的一致性。
3． 联系(relationship) 联系是多个实体间的相互关联。 实体之间会有各种关系， 例如学生实体与课程实体之间可有选课关系， 学生与教师之间可能有讲课关系等。 这种实体与实体间的关系抽象为联系。 联系可用实体所组成的元组表示， 例如元组〈e1， e2， …， en〉表示实体e1, e2, …, en之间的一个联系。 如果n=2， 则称为二元联系， 如果n>2， 则称为多元联系。 同一类型的联系可能包含若干具体的联系， 例如学生选课这一类型的联系就包含许多具体的学生选课联系。
同一类型的联系所组成的集合称为联系集(relationship set)。 设R(E1， E2， …， En)表示定义在实体集E1, E2, …, En上的联系集， 则R｛〈e1,e2,…,en〉|e1∈E1, e2∈E2,…,en∈En|｝。 规范地说， 联系集是n(n≥2)个实体集上的数学关系， 这些实体集不必互异。 如果E1， E2， …， En为n个实体集， 那么联系集R是 R｛〈e1,e2,…,en〉|e1∈E1,e2∈E2,…,en∈En｝的一个子集， 而(e1， e2， …， en)是一个联系。
实体集之间的关联称为参与， 也就是说， 实体集e1， e2， …， en参与联系集。 E―R模式中的一个联系实例表示所模拟的现实世界的命名实体间存在联系。 参与联系集的实体集的数目也称为联系集的度， 二元联系集的度为2， 三元联系集的度为3。 如图2.1所示。
图2.1 实体间的联系
实体在联系中的作用称为实体的角色。 由于参与一个联系的实体集通常是互异的， 因而角色是隐含的并且常常不声明。 但是， 当联系的含义需要解释时角色还是很有用的， 这主要是当参与联系集的实体集并非互异的时候， 也就是说， 同一个实体集在一个联系集中参与的次数大于一次， 且每次参与具有不同的角色。 在这类联系集(有时称作自环的联系集)中， 有必要用显式角色名来定义一个实体参与联系实例的方式。
与传统的数据模型相比， E-R数据模型在实体的联系方面提供了较多的语义。 联系的语义约束包括基数比约束和参与约束。 实体间联系的约束称为映射的基数比约束。 映射的基数（或基数比例）是指通过一个联系集能同另一实体相联系的实体数目。 下面讨论二元联系集的情况。
对于实体集A和B之间的二元联系集来说， 映射的基数必然是以下情况之一: (1) 一对一: A中的一个实体至多同B中的一个实体相联系， B中的一个实体也至多同A中的一个实体相联系， 如图2.2（a）所示。 (2) 一对多: A中的一个实体可以同B中的任意数目的实体相联系， 而B中的一个实体至多同A中的一个实体相联系， 如图2.2（b）所示。
(3) 多对一: A中的一个实体至多同B中的一个实体相联系， 而B中的一个实体可以同A中任意数目的实体相联系， 如图2.2（c）所示。 (4) 多对多: A中的一个实体可以同B中任意数目的实体相联系， B中的一个实体也可以同A中任意数目的实体相联系， 如图2.2（d）所示。
图2.2 二元联系集中映射的基数情况
显然， 某个联系集正确的映射基数应是什么依赖于该联系集用来作为建模对象的现实世界情况。 在有些E-R数据模型中， 还可以进一步给出实体参与联系的最小和最大次数， 这称为实体的参与度。 例如， 在选课联系中， 如果按规定每位学生最少应选三门课， 最多只能选六门课， 则学生在选课联系中的参与度可表示为(3， 6)； 又如在各门课程中， 有些课程可以无人选， 但任何一门课程最多只允许100人选， 则该课程在选课联系中的参与度为(0， 100)。
参与度的一般形式可表示为(min， max)， 式中， 0≤min≤max， 且max≥1。 如果min=0， 则意味着实体集的实体不一定每个都参与联系。 实体的这种参与联系的方式称为部分参与(part participation)。 如果min>0， 则意味着实体集中的每个实体都必须参与联系， 否则就不能作为一个成员在实体集中存在。 实体的这种参与联系的方式称为全参与(total participation)。实体参与联系的方式是重要的语义约束， 称为参与约束(participation constraint)。
基数比约束和参与约束构成联系的语义约束， 有时合称为结构约束(structure constraint)。 实际上， 只用实体的参与度便可表示结构约束。 如前所述， 参与度的min项隐含了参与约束， 而其中的max项隐含了基数比约束。 设R(E1， E2)为定义在实体集E1、 E2的联系集, E1、 E2的参与度分别为(min1， max1)、 (min2， max2)， 如果max1、 max2都为1， 则显然是1∶1联系； 如果max1、 max2中有一个为1， 另一个大于1， 则显然为1∶N联系; 如果max1和max2都大于1， 则显然为M∶N联系。 用参与度表示结构约束容易推广到多元联系， 且对实体参与联系的程度有量的概念。
联系也可能具有描述性属性， 称为联系的属性。 例如， 学生实体和课程实体存在选课的联系， 学生在课程上的成绩可作为选课联系的描述性属性。 如图2.3所示。
图2.3 实体间联系的属性 (a) 二元联系的描述性属性; (b) 实例
4． 键(key) 关于给定实体集中的实体或给定联系集中的联系如何相互区别的声明是非常重要的。 从概念上来说， 各个实体或联系是互异的， 但从数据库的观点来看， 它们的区别必须用其属性来表明。 键的概念使得我们可以进行这样的区别。 (1) 实体集的键。 能够惟一标识实体的属性或属性组称为实体集的超键。 超键是一个或多个属性的集合， 这些属性的组合可以使我们在一个实体集中惟一地标识一个实体。 例如， 实体集课程的课程号属性可以将不同课程区分开来， 因此， 课程号是一个超键。
超键的概念并不足以帮助我们达到目的， 超键中可能包含一些无关紧要的属性。 如果K是一个超键， 那么K的任意超集也是超键。 我们通常只对这样的一些超键感兴趣: 它们的任意真子集都不能成为超键。 这样的最小超键通常称为候选键。 显然， 几个不同的属性集都可以做候选键的情况是存在的。 例如， 实体集课程的课程号和课程名属性组合也可以将不同课程区分开来， 但它们的组合并不能成为候选键。 候选键的选择必须慎重， 如我们所见， 人名是不足以作为候选键的， 因为可能有多个人重名。
我们用主键（primary key）来代表被数据库设计者选中的， 用来在同一实体集中区分不同实体的候选键。 键(主键、 候选键和超键)是实体集的性质， 而不是一个实体的性质。 实体集中的任意两个实体都不允许同时在键属性上具有相同的值。 键的指定代表了对被建模的现实世界中的约束。
(2) 联系集的键。 实体集的主键使得我们可以将实体集中的不同实体区别开来。 我们需要一种类似的机制来区别一个联系集中不同的联系。 假设R只是一个涉及实体集El， E2， …， En的联系集， 而primary―key(Ei)代表构成实体集Ei主键的属性集合。 这里假设所有主键的属性名是惟一的(如果不是这样， 可以采用适当的重命名机制)。 联系集主键的构成依赖于同联系集相联系的属性的结构。
如果没有属性同联系集R相联， 那么属性集合 primary―key(E1)∪primary―key(E2)∪… ∪primary―key(En) 描述了集合R中的一个联系。 如果属性a1， a2， …， am同联系集R相联系， 那么属性集合 ∪primary―key(En)∪{a1， a2， …， am}
描述了集合R中的一个联系。 在以上两种情况下， 属性集合 primary―key(E1)∪primary―key(E2)∪… ∪primary―key(En) 构成联系集的一个超键。
联系的主键结构依赖于联系集映射的基数。 假设联系集是多对多的， 而且有表示联系特征的属性type与之相联系， 那么联系集的主键由参与的两个实体集的主键共同组成。 如果联系集是多对一的或一对多的， 那么联系集的主键就是参与多方的实体集的主键。 在一对一的联系中， 可以使用两个主键中的任何一个来作联系集的主键。
(3) 弱实体集的主键。 有些实体集的属性都不足以形成主键， 这样的实体集称作弱实体集。 与此相对， 有主键实体集称作强实体集。 弱实体集只有作为一对多联系的一部分才有意义， 这时该联系集就应该不具有任何描述性属性， 因为任何所需属性都可以同弱实体集相联系。 强实体集和弱实体集的概念是与存在依赖相关的。 那么， 什么是存在依赖？存在依赖是一类重要的约束。 具体地说， 如果实体x的存在依赖于实体y的存在， 那么就说x存在依赖于y。
在操作上， 如果y被删除， 那么x也要被删除。 实体y称作支配实体， 实体x称作从属实体。如果实体集E中的每个实体都参与到联系集的至少一个联系中， 称实体集E全部参与联系集R。 如果实体集中只有部分实体参与到联系集R的联系中， 称实体集部分参与联系集R。 全部参与同存在依赖紧密相关。 强实体集的成员必然是支配实体， 而弱实体集的成员是从属实体。 弱实体集与其拥有者之间的联系称为标识性联系。 例如， 学生实体有社会关系这方面的特性，若将社会关系抽象为社会关系实体， 那么该实体的存在依赖于学生实体， 所以社会关系实体为弱实体， 学生实体为对应的强实体。
虽然弱实体集没有主键， 但是仍需要用某种方法来区分该实体集中依赖于某个特定强实体的所有实体。 弱实体集的分辨符是使得我们能进行这种区分的属性集合。 弱实体集的主键由该弱实体集所存在依赖的强实体集的主键和该弱实体集的分辨符共同组成。 在某些情况下， 数据库设计者会选择用拥有者实体集的多值、 复合属性来表示弱实体集。如果弱实体集只参与标识性联系， 而且其属性不多， 那么在建模时将其表述为一个属性更恰当。 相反地， 如果弱实体集参与到标识性联系以外的联系中， 或者其属性较多， 则建模时将其表述为弱实体集更恰当。
2.1.2 E―R图 E―R数据模型提供了实体、 属性和联系三个主要的抽象概念。 这三个概念简单明了， 直观易懂， 用以模拟现实世界比较自然。 用E―R数据模型对一个系统的模拟， 称为E—R数据模式。 E―R数据模式可以很方便地转换成相应的关系、 层次和网状数据模式。 E―R数据模式可用非常直观的E―R图(E―R diagram)表示， E―R图中包括如下几个主要符号:
矩形: 表示实体集。 椭圆: 表示属性。 菱形: 表示联系集。 线段: 将属性连接到实体集或将实体集连接到联系集。 双椭圆: 表示多值属性。 虚椭圆: 表示派生属性。 双线: 表示一个实体全部参与到联系集中。 双边框的矩形: 表示弱实体集。 双边框的菱形: 表示弱实体集对应的标识性联系. E―R图中使用的各种构件如图2.4所示。
图2.4 E―R图中使用的各种符号
联系集可以是多对多的、 一对多的、 多对一的或一对一的。 为了将这些类型相互区别开来，在联系集和所联系的实体集间或者用箭头(→)， 或者用线段(—)标识， 并标注基数比。 例如， 学生实体和课程实体存在选课联系， 如图2.5所示。
图2.5 实体间的多对多联系 (a) 多对多联系； (b) 实例
在E―R图中， 通过在连接菱形和矩形的线上加标注来标识角色。 非二元的联系集在E-R图中也可以简单地表示。 学生实体和课程实体存在选课联系， 和系实体存在就读联系， 学生在选课联系中扮演选课角色， 而在就读联系中扮演就读角色。 如图2.6所示。
图2.6 角色
在E―R图中弱实体集以双边框的矩形表示， 而对应的标识性联系以双边框的菱形表示。 例如， 学生实体和社会关系实体之间的联系如图2.7所示。
图2.7 弱实体与实体间的联系 (a) 弱实体与实体间的联系; (b) 实例
图2.8 强实体集的主键和弱实体集的分辨符
通过E―R图， 计算机专业人员与非计算机专业人员可以进行交流和合作， 以真实、 合理地模拟一个单位， 作为进一步设计数据库的基础。 E-R图目前广泛地用于数据库的概念设计。 要注意的是， 用E - R图表示数据模式时， 人们所关心的仅仅是有哪些数据， 它们之间的关系如何， 而不必关心这些数据在计算机内如何表示和采用的是什么DBMS。
2.1.3 扩充E―R数据模型 为了满足新的应用需求和表达更多的语义， E―R数据模型进行了扩充。 扩充E-R数据模型引入了下列抽象概念。 1． 特殊化(specialization)和普遍化(generalization) 如前所述， 一个实体集是具有某些共性的实体的集合。 这些实体一方面具有共性， 另一方面还具有各自的特殊性。 一个实体集可以按照某一特征区分为几个子实体集。 例如学生这个实体集可以分为研究生、 本科生、 大专生等子集。 如果需要的话， 还可以把研究生这个实体集再分为博士生、 硕士生等子集。
这是一个从普遍到特殊的过程， 这个过程叫做特殊化。 与特殊化相反的过程叫普遍化， 即把几个具有某些共性的实体集概括成一个更普遍的实体集。 例如， 把研究生、 本科生、 大专生三个实体集概括为学生实体集， 还可以把学生、 教师、 职工这些实体集概括为“人”这个实体集。 从一般到特殊， 从特殊到一般， 本来就是人们认识世界常用的方法， 因而在E-R数据模型中引入特殊化和普遍化这两个概念， 对模拟现实世界是有用的。
设有实体集E， 如果F是E的某些真子集的集合， 即F={Si|SiE， i＝1，2, …， n}， 则称F是E的一个特殊化， E是S1, S2， …, Sn的超实体集， S1,S2, …, Sn称为E的子实体集。 如果Si=E， 则称F是E的全(total)特殊化; 否则， F是E的部分(partial)特殊化。 如果Si ∩Sj＝， i≠j， 则F是不相交(disjoint)的特殊化; 否则， F是重叠(overlapping)的特殊化。
全／部分特殊化和不相交／重叠特殊化是特殊化的两种重要的语义约束。 普遍化是特殊化的逆过程， 上述的讨论虽是对特殊化而言的， 对普遍化也基本适用， 但有一点不同， 设S1, S2, …, Sn被普遍化为超实体集G， 则G一定等于S1∪S2∪…∪Sn， 即在普遍化时， 不会出现上述的部分特殊化的情况。
子实体集中的实体也是超实体集的实体， 但在部分特殊化时， 超实体集的实体不一定都是子实体集的实体。 子实体集继承(inherit)超实体集的所有属性和联系。 除此以外， 子实体集还可以有自己的特殊属性和联系。 例如， 研究生除了继承学生的所有属性和联系外， 还要增加“导师”、 “学位类别”等属性。 因此， 在数据模型中， 引入子实体集， 可以很方便地描述实体集中部分实体的特殊属性和联系。
特殊化和普遍化可用扩充的E―R图表示(如图2 特殊化和普遍化可用扩充的E―R图表示(如图2.9所示)。 在扩充的E―R图中用有∪符号的线表示特殊化， 圆圈中的d表示不相交特殊化， 圆圈中的o表示重叠特殊化。 超实体集与圆圈的连线若是双线， 则表示全特殊化; 若是单线， 则表示部分特殊化。 例如在职进修生既是教职工， 又是学生， 所以有两个超实体集， 他继承两者的属性。
图2.9 特殊化和普遍化
对于所有实际应用来说， 普遍化只不过是特殊化的逆过程。 在E―R图中， 对普遍化和特殊化的表示不作区别。 为了使设计模式充分体现数据库应用和数据库用户的要求， 可通过特殊化或普遍化产生新的实体层次。 这两种方式的区别主要在于它们的出发点和总体目标。
特殊化从单一的实体集出发， 通过创建不同的低层实体集来强调同一实体集中不同实体间的差异。 低层实体集可以有不适用于高层实体集中所有实体的属性， 也可以参与到不适用于高层实体集中所有实体的联系中。 设计者采用特殊化的原因正是为了表达这些互不相同的特征。
普遍化处理基于这样的认识: 一些实体集具有共同的特征(即可以用相同的属性对它们进行描述， 且它们都参与到相同的联系中)。 普遍化是在这些实体集的共性的基础上将它们综合成一个高层实体集。 普遍化用于强调低层实体集间隐藏于它们区别背后的相似性， 同时由于去除了共同属性的重复出现， 使得普遍化的表示更简捷。
2． 属性继承 特殊化和普遍化所产生的高层实体集和低层实体集的一个重要特性是属性继承。 高层实体集的属性被低层实体集继承。 低层实体集(或子类)同时还继承参与其高层实体集所参与的那些联系集。 属性继承作用于低层实体集的所有联系中。 对E―R图的某个给定部分来说， 不管是通过特殊化还是通过概括得到的， 其结果都是一样的: 同高层实体集相联系的所有属性和联系也适用于它的所有低层实体集; 低层实体集特有的性质仅仅适用于某个特定的低层实体集。
3． 约束设计 为了更准确地对系统建模， 数据库设计者可能选择对特定的普遍化加上某些约束。 主要有以下三种约束: (1) 用来确定哪些实体能成为给定低层实体集的成员的约束。 成员资格可以是条件定义的（在条件定义的低层实体集中， 成员资格的确定基于实体是否满足一个显式的条件或谓词。 这种类型的普遍化称作是属性定义的）或用户定义的（用户定义的低层实体集不是通过成员资格条件来限制的， 而是由数据库用户将实体指派给某个实体集。 ）
(2) 这类约束用来确定同一个普遍化中， 一个实体是否可以属于多个低层实体集。 低层实体集可以是不相交的（不相交约束要求一个实体至多属于一个低层实体集）或有重叠的（在有重叠的概括中， 同一实体可以同时属于同一普遍化的多个低层实体集）说明: 缺省情况下， 低层实体集是可以相互重叠的， 而不相交约束必须显式地加到普遍化(或特殊化)中。
(3) 这类约束是对普遍化的全部性约束， 用来确定高层实体集中的一个实体是否必须属于某个普遍化的至少一个低层实体集。 这种约束可以是全部的（每个高层实体必须属于一个低层实体集）， 也可以是部分的（允许一些高层实体不属于任何低层实体集）。 由于通过普遍化产生的高层实体集通常只包括低层实体集中的实体， 因而对于普遍化产生的高层实体集来说， 其全部性约束一般是全部的。 如果全部性约束是部分的， 则高层实体就可以不出现在任何低层实体集中。
全部性约束和不相交约束彼此并没有依赖关系， 约束的模式也可以是部分-不相交的或全部―可重叠的。 由于对普遍化或特殊化运用了某些约束， 因而可能产生某些插入和删除操作。 例如， 当全部性约束是全部时， 一个实体被插入到高层实体集中， 那么它至少同时还必须被插入到一个低层实体集中。 在条件定义的约束中， 所有满足条件的高层实体必须被插入到相应的低层实体集中。 此外， 从高层实体集删除的实体也必须从所有它所属的相应低层实体集中删除。
4． 聚集(aggregation) 在基本E-R数据模型中， 只有实体才能参与联系， 不允许联系参与联系。 在扩充E―R数据模型中， 可以把联系看成由参与联系的实体组合而成的新的实体， 其属性为参与联系的实体的属性和联系的属性的并。 这种新的实体称为参与联系的实体的聚集。 有了聚集这个抽象概念， 联系也可以参与联系， 如图2.10所示。 聚集是一种抽象， 通过这种抽象， 联系被当作高层实体来看待。
图2.10 含有聚集的扩充E―R数据模型图例
5． 范畴(category) 在模拟现实世界时， 有时要用到由不同类型的实体组成的实体集， 例如车主这个实体集的成员可能是单位， 也可能是个人。 这种由不同类型实体组成的实体集不同于前面所定义的实体集被称为范畴。 设E1, E2, …, En是n个不同类型的实体集， 则范畴T可定义为: T(E1∪E2∪…∪En) 其中E1, E2, …, En也称为T的超实体集。 如图2.11所示， 圆圈中的∪表示并操作。
图2.11 范畴 (a) 范畴； (b) 实例
范畴也继承其超实体集的属性， 但与子实体集的继承规则不一样。 子实体集继承所有超实体集的属性， 而范畴的继承是有选择性的， 称为选择性继承(selective inheritance)。 范畴与具有多个超实体集的子实体集在形式上有些相似， 但意义完全不同。 范畴是超实体集并的子集， 而子实体集是超实体集交的子集。 实体―联系方法是抽象和描述现实世界的有力工具。 用E-R图表示的概念模型独立于具体的DBMS所支持的数据模型， 它是各种数据模型的共同基础， 因而比数据模型更一般、 更抽象、 更接近现实世界。
【例】 我们假设考察一个学校教学管理系统的模型。 已知每个学生要记录其学号， 姓名， 身份证号， 性别， 出生日期， 年龄， 籍贯， 入学时间， 所学专业和所属系别、 班级， 是本科生还是专科生。 每个教师要记录其工作证号， 姓名， 身份证号， 性别， 出生日期， 年龄， 籍贯， 职称， 联系电话号码， 参加工作时间， 所属系别和教研室。 学校开设的课程要记录课程号， 课程名， 学分， 学期， 上课教师姓名， 课程类型， 需先修的课程; 另外， 要记录每个学生的选课情况和成绩。
上述学校教学管理系统模型用E―R图表示如图2.12所示(图中省略了属性和角色标识)。 图中的六个实体所含属性如下: 学生（学号， 姓名， 身份证号， 性别， 出生日期， 年龄， 籍贯， 入学时间， 系号， 学籍类型号， 专业号， 班级号）教师（工作证号， 姓名， 身份证号， 性别， 出生日期， 年龄， 籍贯， 职称， 电话号码， 参加工作时间， 系号， 教研室号）
课程（课程号， 课程名， 学分， 学期， 教师姓名， 课程类型， 先修的课程号） 教研室（教研室号， 教研室名） 系（系号， 系名， 地址， 电话号码） 班级（班级号， 班级名）
图2.12 学校教学管理系统的E―R模型
2.2 关 系 模 型 关系模型是目前最重要的一种数据模型。 关系数据库系统就是采用关系模型作为数据的组织方式。 2.2 关 系 模 型 关系模型是目前最重要的一种数据模型。 关系数据库系统就是采用关系模型作为数据的组织方式。 1970年美国IBM公司的研究员E．F．Codd首次提出了数据库系统的关系模型， 开创了数据库关系方法和关系数据理论的研究， 为数据库技术奠定了理论基础。 20世纪80年代以来， 计算机厂商新推出的数据库管理系统几乎都支持关系模型， 非关系系统的产品也大都加上了关系接口。 数据库领域当前的研究工作也都以关系方法为基础。
关系数据模型是以集合论中的关系(relation)概念为基础发展起来的数据模型。 在关系模型中， 无论是实体还是实体之间的联系， 均由单一的结构类型即关系(表)来表示。 关系数据库具有坚实的理论基础。 这一理论有助于关系数据库的设计和用户对数据库信息需求的有效处理。
2.2.1 关系数据模型的基本概念 在关系模型中， 现实世界的实体以及实体间的各种联系均用关系来表示。 从用户的角度来看， 关系模型中数据的逻辑结构是一张二维表， 它由行和列组成。 表中的一行称为一个元组， 表中的一列称为一个属性， 元组中的一个属性值为元组的一个分量。 关系模型是建立在集合代数的基础上的。 下面从集合论角度给出关系数据结构的形式化定义, 并介绍关系模型及有关的基本概念。
1． 属性和域 在现实世界中， 要描述一个事物， 常常取其若干特征来表示， 这些特征称为属性 (attribute)。 例如大学生可用姓名、 学号、 性别、 出生年份、 籍贯、 系别等属性来描述。 每个属性对应一个值的集合， 作为其可以取值的范围， 称为该属性的域(domain)。 换句话说， 域是一组具有相同数据类型的值的集合。 例如， 姓名的域是指所有合法姓名的集合， 学号的域是指若干位字符所组成的字符串的集合， 性别的域是{男， 女}， 出生年份和入学年份这两个属性的域是四位十进制整数的集合。
在数学中， 有些域可能是无限集合， 但在计算机中， 所有数据都是离散化了的数据， 且表示的长度都是有限的。 因而， 所有的域都可以看成是有限的集合。 在关系数据模型中， 对域还加了一个限制， 即所有域都应是原子数据(atomic data)的集合。 所谓原子数据是指那些就关系数据模型而言已不可再分的数据， 例如整数、 字符串等(不包括组合数据(aggregated data)， 如集合、 记录、 数组等)。 这种限制称为第一范式条件， 一般商用关系数据库都遵守这个限制。 域可以用数据类型、 值的集合或数据格式表示， 例如INT、 FLOAT、 CHAR(n)、 {男， 女}等。
在数据库中， 某些属性值可能是未知的或在某些场合下是不适用的。 在此情况下， 关系数据模型有条件地允许使用空缺符NULL。 NULL虽然有时也称为空值(null value)， 但严格地说， 它不是值， 而是一个标记， 说明该属性值是空缺的。
2． 关系和元组 一个对象可以用一个或多个关系来描述。 设有一个命名为R的关系， 它有属性A1, A2, …, An， 其对应的域分别为D1， D2， …， Dn， 则关系R可表示为: R=(A1/D1， A2/D2, …， An/Dn） 或R=(A1， A2， …， An) 称为关系R的模式。 n是R的属性的个数， 称为关系的目(Degree)。
当n=1时， 称该关系为单元关系(Unary Relation)。 当n=2时， 称该关系为二元关系（Binary Relation）。 Ai(1≤i≤n)是属性名(Attribute)， 在同一关系中不能同名。 但在同一关系中， 不同的属性可以有相同的域， 例如出生年份与入学年份的域相同， 但作用不同。 R的值用r或r(R)表示， 它是n目元组(ntuple)的集合， 即r={t1， t2， …， tm}。
关系中的每个元素是关系中的元组， 通常用t表示。 每个元组t可表示为: t=〈v1， v2, …， vn〉 其中vi∈Di， 1≤i≤n， 即 ti∈D1×D2×…×Dn， 1≤i≤m。 也就是R的值r是属性域的笛卡尔乘积的子集， 即 r D1×D2×…×Dn。
(1) 笛卡尔积(Cartesian Product)。 给定一组域D1， D2， …， Dn， 这些域中可以有相同的。 D1, D2， …， Dn的笛卡尔积为: D1×D2×…×Dn={(d1， d2， …， dn)|di∈Di, i=1， 2， …， n} 其中每一个元素(d1， d2， …， dn)叫做一个元组(n-tuple)或简称元组(Tuple)。 元素中的每一个值叫做一个分量(Component)。
若Di(i=1， 2， …， n)为有限集， 其基数(Cardinal Number)为mi(i=1， 2， …， n)， 则D1×D2×…×Dn的基数M为: 笛卡尔积可表示为一个二维表。 表中的每行对应 一个元组， 表中的每列对应一个域。
(2) 关系(Relation)。 笛卡尔积D1×D2×…×Dn的子集叫做在域D1， D2， …， Dn上的关系， 表示为 R(D1， D2， …， Dn) 其中R表示关系的名字， n是关系的目。 关系是笛卡尔积的有限子集， 所以关系也是一个二维表， 表的每行对应一个元组， 表的每列对应一个域。 由于域可以相同， 为了加以区分， 必须对每列起一个名字， 称为属性。 n目关系必有n个属性。
属性也可以看成函数(映射)Ak: r→Dk， 即对于r中的一个元组ti， 属性Ak在域Dk中取属性值Ak(ti)。 有时为了表示方便， 在不引起混淆时可略去属性间的逗号， 例如R(ABCD)表示R是具有A、 B、 C、 D四个属性的关系模式。 关系名有时也用来代表它的值， 例如: R.A表示关系R的属性A。
一个关系包含若干元组， 这些元组的集合称为关系所取的值。 一般说来， 关系模式是相对稳定的， 而关系的值是相对变化的。 有些文献借用逻辑中的概念， 称关系模式为关系的内涵(intension)， 关系的值为关系的外延(extension)。 值得注意的是， 在数学中， 元组中的值是有序的， 而在关系数据模型中对属性的次序是不作规定的， 例如R(A1， A2)和R(A2， A1)两种表示是等价的。 当然， 关系的属性总要按一定的次序存储在数据库中。 但这仅仅是物理存储的顺序， 而在逻辑上， 属性在关系模式中出现的次序是无关紧要的。
从形式上看， 关系相当于一个表(table)。 不过， 关系所对应的表是一种简单的二维表， 不允许表中出现组合数据， 更不允许表中再嵌入表。 另外， 关系是元组的集合， 按集合的定义， 元组在集合中应是无序的， 而且互不相同。 这就意味着在关系所对应的表中， 表的行应该是无序的且互不相同。 总之， 关系是一个加以适当限制的表。 因此， 在关系数据模型中， 关系与表这两个术语可以互相通用。 与此相适应， 属性又称为列(Column)， 元组又称为行(Row)。
有时需要取一个关系或元组的部分属性的值， 这称为关系或元组在这些属性上的投影， 分别表示为R［X］和t［X］， 其中X{A1， A2， …, An}。 关系可以有三种类型: 基本关系(通常又称为基本表或基表)、 查询表和视图表。 基本表是实际存在的表， 它是实际存储数据的逻辑表示。 查询表是查询结果对应的表。 视图表是由基本表或其他视图表导出的表， 是虚表， 不对应实际存储的数据。
按照关系的定义， 关系可以是一个无限集合。 由于笛卡尔积不满足交换律， 所以按照数学定义， (d1， d2， …， dn)与(d2， d1， …， dn)是不相等的。 所以， 当关系作为关系数据模型的数据结构时， 需要给予如下的限定和扩充; (1) 无限关系在数据库系统中是无意义的。 因此， 限定关系数据模型中的关系必须是有限集合。
(2) 通过为关系的每个列附加一个属性名的方法取消关系元组的有序性， 即(d1， d2， …， di， dj， …， dn)=(d1， d2， …, dj， di, …， dn)(i, j=1， 2， …， n)。 因此， 基本关系具有以下六条性质: ① 列是同质的(Homogeneous)， 即每一列中的分量是同一类型的数据， 来自同一个域。 ② 不同的列可出自同一个域， 称其中的每一列为一个属性， 不同的属性要给予不同的属性名。
③ 列的顺序无所谓， 即列的次序可以任意交换。 由于列顺序是无关紧要的， 因此在许多实际关系数据库产品中(例如Oracle)， 增加的新属性永远插至最后一列。 ④ 任意两个元组不能完全相同。 ⑤ 行的顺序无所谓， 即行的次序可以任意交换。 ⑥ 分量必须取原子值， 即每一个分量都必须是不可分的数据项。
3． 键 如前所述， 关系的每个元组是互不相同的。 但是， 不同的元组在部分属性上的投影可能相同， 例如关系学生中， 不同的元组在年龄属性上的投影可能相同。 但是， 元组在有些属性上的投影是不能相同的， 例如关系学生中学号属性。 (1) 候选键（Candidate Key， 简称为键）: 如果关系的某一属性或属性组的值惟一地决定其他所有属性的值， 也就是惟一地决定一个元组， 而其任何真子集无此性质， 则这个属性或属性组称为该关系的候选键。
(2) 超键(Super Key): 若属性组虽然可决定其他属性的值， 但它的真子集也具有此性质， 这种属性组称为超键。 (3) 主键(Primary Key): 一个关系至少有一个候选键， 也可能有多个候选键， 一般从候选键中选一个作为主键。 主键的值可以用来识别和区分元组， 它应该是惟一的， 即每个元组的主键的值是不能相同的。
在最简单的情况下， 候选键只包含一个属性。 在最极端的情况下， 关系模式的所有属性组是这个关系模式的候选键， 称为全键(All―Key)。 包含在任何一个候选键中的属性称为主属性(prime attribute)。 在关系模式中， 常在主键的主属性下加下划线， 以标出主键。 不包含在任何候选键中的属性称为非主属性(non-prime attribute)。 例如在关系学生中， 只有学号是主属性， 而其他属性都是非主属性。 姓名虽然有时用来识别学生， 但由于同名的可能， 姓名不能当作键。
(4) 外键(foreign key): 如果关系中的属性或属性组不是本关系的键， 而是引用其他关系或本关系的键， 则称为此关系的外键。 更形式化的定义如下: 设F是基本关系R的一个或一组属性， 但不是关系R的键, 如果F与基本关系S的主键Ks相对应， 则称F是基本关系R的外键， 并称基本关系R为参照关系(Referencing Relation)， 基本关系S为被参照关系(Referenced Relation)或目标关系(Target Relation)。 关系R和S不一定是不同的关系。
显然， 目标关系S的主键Ks和参照关系的外键F必须定义在同一个(或一组)域上。 需要指出的是， 外键并不一定要与相应的主键同名。 不过， 在实际应用当中， 为了便于识别， 当外键与相应的主键属于不同关系时， 往往给它们取相同的名字。 例如: 考察学校教学管理系统的模型的下述几个关系模型: 学生（学号， 姓名， 身份证号， 性别， 出生日期， 年龄， 籍贯， 入学时间， 系号， 学籍类型， 专业号， 班级）
课程（课程号， 课程名， 学分， 学期， 教师姓名， 课程类型， 先修课程号）选课（学号， 课程号， 成绩） 从语义可知， 课程号是课程的主键， 学号是学生的主键， {学号， 课程号}是选课的主键。 而学号、 课程号是选课的两个外键。 如果关系数据库模式是基于E-R模式导出的表， 那么就可以由导出关系数据库模式的实体集和联系集的主键确定关系模式的主键， 其原则如下: ① 强实体集的主键为关系的主键;
② 弱实体集的主键是由强实体集的主键和弱实体集的分辨符共同组成的; ③ 对于联系集， 相关实体集的主键共同构成关系的超键。 如果从A到B联系是多对多的， 则此超键也就是主键。 如果从A到B联系是一对多或多对一的， “多”方实体集的主键成为关系的主键(即， 如果联系集从A到B是多对一的， 则A的主键是关系的主键)。 对一对一的联系集来说， 关系的构造如同多对一联系集那样， 不同的是， 任一实体集的主键都可以被选作关系的主键， 因为它们都是候选键。
2.2.2 关系模式 关系数据库中， 关系模式是型， 关系是值， 这两者是有区别的。 关系模式是对关系的描述， 那么一个关系需要描述哪些方面呢? 首先， 关系实质上是一张二维表， 表的每一行为一个元组， 每一列为一个属性。 一个元组就是该关系所涉及的属性集的笛卡尔积的一个元素。 关系是元组的集合， 因此关系模式必须指出这个元组集合的结构， 即它由哪些属性构成， 这些属性来自哪些域， 以及属性与域之间的映象关系。
其次， 一个关系通常是由赋予它的元组语义来确定的。 元组语义实质上是一个n目谓词(n是属性集中属性的个数)。 凡使该n目谓词为真的笛卡尔积中的元素(或者说凡符合元组语义的那部分元素)的全体就构成了该关系模式的关系。 现实世界随着时间在不断地变化， 因而在不同的时刻， 关系模式的关系也会有所变化。 但是， 现实世界的许多已有事实限定了关系模式所有可能的关系必须满足一定的完整性约束条件。 这些约束或者通过对属性取值范围的限定， 或者通过属性值间的相互关联(主要体现于值的相等与否)反映出来。 关系模式应当刻划出这些完整性约束条件。
因此， 一个关系模式应当是一个5元组， 它是关系的描述。 它可以形式化地表示为: R(U， D， dom， F) 其中R为关系名， U为组成该关系的属性名集合， D为属性组U中属性所来自的域， dom为属性间域的映象集合， F为属性间数据的依赖关系集合。
【例】 我们仍以学校教学管理系统的模型为例， 其对应的关系模式如下: 学生（学号， 姓名， 身份证号， 性别， 出生日期， 年龄， 籍贯， 入学时间， 系号， 学籍类型号， 专业号， 班级号）课程（课程号， 课程名， 学分， 学期号， 教师姓名， 课程类型号）先修课程（课程号， 先修课程序号， 先修课程号）教师（工作证号， 姓名， 身份证号， 性别， 出生日期， 年龄， 籍贯， 参加工作时间， 系号， 教研室号， 职称， 电话号码）系（系号， 系名， 地址， 电话号码）
选课（学号， 课程号， 成绩） 班级（班级号， 班级名） 职称（职称号， 职称名） 学籍类型（学籍类型号， 学籍类型名） 课程类型（课程类型号， 课程类型名） 学期（学期号， 学期名） 教研室（教研室号， 教研室名） 专业（专业号， 专业名）
关系是关系模式在某一时刻的状态或内容。 关系模式是静态的、 稳定的， 而关系是动态的、 随时间不断变化的， 因为关系操作在不断地更新着数据库中的数据。 但在实际中， 人们常常把关系模式和关系统称为关系， 这不难从上下文中加以区别。 关系数据库也有型和值之分。 在一个给定的应用领域中， 所有实体及实体之间联系的关系的集合构成一个关系数据库。 关系数据库的型也称为关系数据库模式， 是对关系数据库的描述， 它包括若干域的定义以及在这些域上定义的若干关系模式。 关系数据库的值是这些关系模式在某一时刻对应的关系的集合， 通常称为关系数据库。
2.2.3 约束 关系模式， 不仅说明了关系的语法， 而且说明了关系R的属性间数据的依赖关系。 此外， 一个合乎语法的元组还要受到语义的限制。 例如， 一个大学生的年龄一般不能大于100岁或小于5岁等， 这些都是语义上的限制。 数据的语义不但会限制属性的值， 而且还会制约属性间的关系。 例如， 关系的主键(或其他任一候选健， 下同)的值决定关系中其他属性的值， 因此， 主键的值在关系中不能重复出现或为NULL。
而一个属性或一组属性能否成为一个关系的主键， 完全决定于数据的语义， 而不是语法。 语义还给不同关系中的数据带来一定的限制， 例如学生所选课程应该是学校所开出的课程。 以上所举的例子， 都是语义施加在数据上的限制， 统称为完整性约束。 设r是某关系R在给定时间的元组的集合， 即R的值， r1为所有满足完整性约束的元组的集合， 显然有下面的关系: rr1D1×D2×…×Dn 语义完整性约束可以由用户来检查， 也可以由系统来检查。 完整性约束检查只有在做数据库更新操作时才需进行。
下面将关系数据模型完整性约束分4类介绍。 1． 域完整性约束(domain integrity constraint) 属性值应是域中的值， 这是关系模式规定了的。 除此之外， 一个属性能否为NULL， 这是由语义决定的， 也是域完整性约束的主要内容。 域完整性约束是最简单、 最基本的约束。 在当今的关系DBMS中， 一般都有域完整性约束检查功能。
2． 实体完整性约束(entity integrity constraint) 实体完整性约束是对关系的主键及其取值的约束: 每个关系应有一个主键， 每个元组(相当于一个实体)的主键的值应是惟一的。 主键的值不能为NULL。 实体完整性约束要求关系遵循实体完整性规则: 若属性是基本关系的主属性， 则属性不能取空值。 说明: (1) 实体完整性规则规定, 基本关系的所有主属性都不能取空值， 而不仅是主键整体不能取空值。 例如学生选课关系中选课(学号， 课程号， 成绩)中， “学号, 课程号”为主键， 则“学号”和“课程号”两个属性都不能取空值。
(2) 实体完整性规则是针对基本关系而言的。 一个基本关系通常对应现实世界的一个实体集。 现实世界中的实体是可区分的， 即它们具有某种惟一性标识。 相应地， 关系模型中以主键作为惟一性标识。 (3) 主键中的属性即主属性不能取空值。 所谓空值就是“不知道”或“无意义”的值。 如果主属性取空值， 就说明存在某个不可标识的实体， 即存在不可区分的实体， 这与现实世界中的实体具有某种惟一性标识相矛盾。
目前， 大部分DBMS支持实体完整性约束检查， 但不是强制的和彻底的。 如果用户的数据模式中说明了主键， 则DBMS可以进行这项检查。 但是， 有些DBMS也允许用户在数据模式中不说明主键， 则在此情况下就无从进行实体完整性约束检查。 甚至当插人大量元组时， 为了改善性能， 有些DBMS手册还推荐用户在此时暂且撤销主键的说明， 这等于要用户暂时置实体完整性约束于不顾。
3． 参照完整性约束(referential integrity constraint) 参照完整性约束是不同关系之间或同一关系的不同元组间的约束。 它要求关系中的外键与主键之间遵循参照完整性规则: 若属性(或属性组)F是基本关系R的外键， 它与基本关系S的主键Ks相对应(基本关系R和S不一定是不同的关系)， 则对于R中每个元组在F上的值必须为取空值(F的每个属性值均为空值), 或者等于S中某个元组的主键值。 现实世界中的实体之间往往存在某种联系， 在关系模型中实体及实体间的联系都是用关系来描述的。 这样就自然存在着关系与关系间的引用。
【例 1】 学生实体和专业实体可以用下面的关系表示， 其中主键用下划线标识: 学生（学号， 姓名， 身份证号， 性别， 出生日期， 年龄， 籍贯， 入学时间， 系号， 学籍类型号， 专业号， 班级号） 专业(专业号， 专业名) 这两个关系之间存在着属性的引用， 即学生关系引用了专业关系的主键“专业号”。 显然， 学生关系中的“专业号”值必须是确实存在的专业的专业号， 即专业关系中有该专业的记录。 这也就是说， 学生关系中的某个属性的取值需要参照专业关系的属性取值。
【例 2】 学生、 课程、 学生与课程之间的多对多联系可以如下三个关系表示: 学生（学号， 姓名， 身份证号， 性别， 出生日期， 年龄， 籍贯， 入学时间， 系号， 学籍类型号， 专业号， 班级号） 课程(课程号， 课程名， 学分) 选修(学号， 课程号， 成绩)
这三个关系之间也存在着属性的引用， 即选修关系引用了学生关系的主键“学号”和课程关系的主键“课程号”。 同样， 选修关系中的“学号”值必须是确实存在的学生的学号， 即学生关系中有该学生的记录; 选修关系中的“课程号”值也必须是确实存在的课程的课程号，即课程关系中有该课程的记录。 换句话说， 选修关系中某些属性的取值需要参照其他关系的属性取值。 不仅两个或两个以上的关系间可以存在引用关系， 同一关系内部属性间也可能存在引用关系。
【例 3】 假设在关系学生（学号， 姓名， 身份证号， 性别， 出生日期， 年龄， 籍贯， 入学时间， 系号， 学籍类型号， 专业号， 班级号）中增加“班长”属性， “学号”属性是主键， “班长”属性表示该学生所在班级的班长的学号， 它引用了本关系“学号”属性， 即“班长”必须是确实存在的学生的学号。 显然, 参照完整性规则就是定义外键与主键之间的引用规则。
例如， 对于学生关系中每个元组的“专业号”属性只能取下面两类值: 空值， 表示尚未给该学生分配专业; 非空值， 这时该值必须是专业关系中， 某个元组的“专业号”值， 表示该学生不可能分配到一个不存在的专业中。 即被参照关系“专业”中一定存在一个元组， 它的主键值等于该参照关系“学生”中的外键值。 说明: 参照完整性规则中， R与S可以是同一个关系。 例如学生关系中“班长”属性值可以取两类值: 空值， 表示该学生所在班级尚未选出班长; 非空值， 这时该值必须是本关系中某个元组的学号值。
4． 用户定义的完整性约束（User defined Integrity） 任何关系数据库系统都应该支持实体完整性和参照完整性。 除此之外， 不同的关系数据库系统根据其应用环境的不同， 往往还需要一些特殊的约束条件， 用户定义的完整性就是针对某一具体关系数据库的约束条件。 它反映某一具体应用所涉及的数据必须满足的语义要求。 例如某个属性必须取惟一值， 某些属性值之间应满足一定的函数关系, 某个属性的取值范围在0～100之间等。 关系模型应提供定义和检验这类完整性的机制， 以便用统一的系统的方法处理它们， 而不要由应用程序承担这一功能。
关系模型的完整性规则是对关系的某种约束条件。 域完整性约束、 实体完整性约束和参照完整性约束是关系数据模型的三个最基本、 最普遍的完整性约束。 其中实体完整性和参照完整性是关系模型必须满足的完整性约束条件， 被称作是关系的两个不变性， 应该由关系系统自动支持。 用户定义的完整性是应用领域需要遵循的约束条件， 体现了具体领域中的语义约束。
其他的语义约束与数据的具体内容有关， 数量很大， 要说明、 管理和检查这些约束，开销太大。 目前， 在有些DBMS中， 允许用户对个别数据说明一些约束和违反约束时的处理过程， 但迄今还没有一个关系DBMS产品可以全面实现用户定义完整性这种一般性完整性约束检查功能。
2.2.4 关系操作和关系数据语言 关系模型也给出了关系操作的能力， 但不对DBMS语言给出具体的语法要求。关系模型中常用的关系操作包括: 选择(Select)、 投影(Project)、 连接(Join)、 除(Divide)、 并(Union)、 交(Intersection)、 差(Difference)等查询(Queue)操作和增加(Insert)、 删除(Delete)、 修改(Update)操作两大部分。 查询的表达能力是其中最主要的部分。 关系操作的特点是集合操作方式， 即操作的对象和结果都是集合。
这种操作方式也称为一次一集合(set-at-a-time)的方式。 相应地， 非关系数据模型的数据操作方式则为一次一记录(record-at-a-time)的方式。 早期的关系操作能力通常用代数方式或逻辑方式来表示， 分别称为关系代数和关系演算。 关系代数是用对关系的运算来表达查询要求的方式。 关系演算是用谓词来表达查询要求的方式。 关系演算又可按谓词变量的基本对象是元组变量还是域变量分为元组关系演算和域关系演算。 关系代数、 元组关系演算和域关系演算三种语言在表达能力上是完全等价的。
关系代数、 元组关系演算和域关系演算均是抽象的查询语言， 这些抽象的语言与具体的DBMS中实现的实际语言并不完全一样。 但它们能用作评估实际系统中查询语言能力的标准或基础。 实际的查询语言除了提供关系代数或关系演算的功能外， 还提供了许多附加功能， 例如集函数、 关系赋值、 算术运算等。
关系语言是一种高度非过程化的语言， 用户不必请求DBA为其建立特殊的存取路径， 存取路径的选择由DBMS的优化机制来完成， 此外， 用户不必求助于循环结构就可以完成数据操作。 另外， 还有一种介于关系代数和关系演算之间的语言SQL(Structured Query Language)。 SQL不仅具有丰富的查询功能， 而且具有数据定义和数据控制功能， 是集查询、 DDL、 DML和DCL于一体的关系数据语言。 它充分体现了关系数据语言的特点和优点， 是关系数据库的标准语言。
关系数据语言可以分为三类: (1) 关系代数语言， 例如ISBL。 (2) 关系演算语言， 包括元组关系演算语言(例如APLHA， QUEL)和域关系演算语言 (例如QBE)。 (3) 具有关系代数和关系演算双重特点的语言， 例如SQL。 这些关系数据语言的共同特点是: 语言具有完备的表达能力; 是非过程化的集合操作语言; 功能强， 能够嵌入高级语言中使用。
2.3 面向对象的数据模型 20世纪80年代以来， 数据库的应用领域迅速扩展， 出现了大量的新一代数据库应用, 且数据库技术在商业领域取得巨大成功。 计算机应用对数据模型的要求是多种多样的， 而且是层出不穷的。 为适应用户不同的新需求， 设计一种可扩充的数据模型， 由用户根据需要定义新的数据类型及相应的约束和操作的方法受到人们的重视。
面向对象数据模型(object-oriented data model， 简称OO data model)就是一种可扩充的数据模型， 又称对象数据模型(object data model)。 它吸收了语义数据模型和知识表示模型的一些基本概念， 同时又借鉴了面向对象程序设计语言和抽象数据类型的一些思想。 在1991年， 美国国家标准协会(ANSI)的一个面向对象数据库工作组(Object-Oriented Data bases Task Group， 简称OODBTG)提出了第一个有关OODB标准化的报告。 由于面向对象数据模型是在发展中逐步形成的， 不是一开始就有明确的定义， 因此现有文献中有关这方面的术语仍不统一。 以面向对象数据模型为基础的DBMS称为O-ODBMS或对象数据库管理系统(ODBMS)。
2.3.1 OO模型基础 一个OO模型是用面向对象观点来描述现实世界实体(对象)的逻辑组织、 对象间限制、 联系等的模型。 一系列面向对象核心概念构成了OO模型的基础。 概括起来， OO模型的核心概念有如下一些: 1． 对象(Object)与对象标识OID(Object Identifier) 现实世界的任一实体都被统一地模型化为一个对象， 每个对象有一个惟一的标识， 称为对象标识(OID)。
2． 封装(Encapsulation) 。 每一个对象是其状态与行为的封装， 其中状态是该对象一系列属性(attribute)值的集合， 而行为是在对象状态上操作的集合， 操作也称为方法(Method)。
3． 类(Class) 共享同样属性和方法集的所有对象构成了一个对象类(简称类)， 一个对象是某一类的一个实例(instance)。 例如， 学生是一个类， 李勇、 刘立晨、 张敏等是学生类中的对象。 在数据库系统中， 要注意区分“型”和“值”的概念。 在OODB中， 类是“型”， 对象是某一类的一个“值”。 类属性的定义域可以是任何类， 即可以是基本类(如整数、 字符串、 布尔型)， 也可以是包含属性和方法的一般类。 特别地， 一个类的某一属性的定义也可是这个类自身。
4． 类层次(结构) 在一个面向对象数据库模式中， 可以定义一个类(如C1)的子类(如C2)， 类C1称为类C2的超类(或父类)。 子类(如C2)还可以再定义子类(如C3)。 这样， 面向对象数据库模式的一组类形成一个有限的层次结构， 称为类层次。 一个子类可以有多个超类， 有的是直接的， 有的是间接的。 例如， C2是C3的直接超类，C1是C3的间接超类。 一个类可以继承类层次中其直接或间接超类的属性和方法。
5． 消息(Message) 由于对象是封装的， 对象与外部的通信一般只能通过显式的消息传递， 即消息从外部传送给对象， 存取和调用对象中的属性和方法， 然后在内部执行所要求的操作， 操作的结果仍以消息的形式返回。
2.3.2 OO模型的核心概念 1. 对象结构 对象是由一组数据结构和在这组数据结构上的操作的程序代码封装起来的基本单位。 对象之间的界面由一组消息定义。 一个对象包括以下几个部分（如图2.13）:
图2.13 对象的组成
(1) 属性集合(又称为变量集合): 所有属性合起来构成了对象数据的数据结构。 属性描述对象的状态、 组成和特性。 对象的某一属性可以是单值的或值的集合。 进一步地， 一个对象的属性也可以是一个对象， 即对象可以嵌套。 这种嵌套可以继续， 从而组成各种复杂对象。
(2) 方法集合: 方法描述了对象的行为特性。 方法的定义包括两部分: 方法的接口和方法的实现。 方法的接口用以说明方法的名称、 参数和结果返回值的类型， 也称之为调用说明。 方法的实现是一段程序代码， 用以实现方法的功能， 即对象操的算法。 (3) 消息集合: 消息是对象向外提供的界面， 消息由对象接收和响应。 面向对象数据模型中的“消息”与计算机网络中传输的消息的含义不同。 它是指对象之间的操作请求的传递， 而不考虑操作实现细节。
例如， 假定教职员工employee的工资对于不同的员工有不同的计算方法， 如教师可能依据工作量来获得课时津贴， 而行政人员则根据他们工作绩效得到奖金。 在概念上可以将计算每个教职员工工资的代码封装为一个方法annual-salary， 当响应一个计算工资消息时就执行这个方法。 每一个employee对象都响应annual-salary消息， 但是他们响应的途径不同。 通过将如何计算年薪的信息封装到对象内部， 所有的雇员对象都提供了相同的接口。 由于一个对象所提供的惟一外部接口是对象所响应的消息集合， 因此可以做到在修改方法和变量的定义时不影响系统的其余部分。
2. 对象标识 面向对象数据库中的每个对象都有一个惟一的、 不变的标识, 称为对象标识(OID)。 对象通常与实际领域的实体对应。 在现实世界中， 实体中的属性值可能随着时间的推移会发生改变， 但是每个实体的标识始终保持不变。 相应的， 对象的部分(或全部)属性、 对象的方法会随着时间的推移发生变化， 但对象标识不会改变。 两个对象即使属性值和方法都完全相同， 如果OID不同, 则认为是两个不同的对象， 它们只是值相等而已。 对象标识的概念比程序设计语言或传统数据模型中所用到的标识概念更强。 下面是常用的几种标识:
(1) 值标识: 用值来表示标识。 例如， 关系数据库中使用的就是值标识。 在关系数据库中， 一个关系的元组是用它们的主键值来区分的， 如主键值学号8202110标识了学号为8202110的学生元组。 (2) 名标识: 用一个名字来表示标识。 例如， 文件系统中的文件， 不管文件的内容是什么， 每个文件都被赋予一个名称来惟一标识。 程序变量使用的也是名标识， 程序中的每个变量被赋予一个名字， 变量名惟一地标识每个变量。
(3) 内标识。 以上两种标识是由用户建立的， 内标识建立在数据模型或程序设计语言中， 不要求用户给出标识。 例如， 面向对象数据库系统使用的就是内标识， 每个对象在创建时被系统自动赋予一个标识符。
3. 封装 OO模型的一个关键概念就是封装。 每一个对象是其状态与行为的封装。 封装是对象的外部界面与内部实现之间实行清晰隔离的一种抽象， 外部与对象的通信只能通过消息。 这是OO模型的主要特征之一。
封装的意义在于将对象的实现与对象应用互相隔离， 从而允许对操作的实现算法和数据结构进行修改而不影响接口， 不必修改对象的应用， 这有利于提高数据独立性。 对象封装对用户而言, 对象内部实现是不可见的， 这就隐藏了在实现中使用的数据结构与程序代码等细节。 此外, 对象封装后成为一个自含的单元， 对象只接受已定义好的操作， 其他程序不能直接访问对象中的属性， 从而可以提高程序的可靠性。
但是， 对象封装之后查询属性值必须通过调用方法， 不能像关系数据库系统那样(用SQL)进行随机的、 按内容的查询， 这就不够方便灵活， 失去了关系数据库的重要优点。 因此，在OODB中必须在对象封装方面做必要的修改或妥协。
4. 类和类层次 在OO数据库中相似对象的集合称为类。 每一个对象称为它所在类的一个实例。 一个类中的所有对象共享一个定义， 它们的区别仅在于属性的取值不同。 可以看到， 类的概念类似于关系模式， 类的属性类似关系模式中的属性， 对象类似于元组的概念， 类的一个实例对象类似于关系中的一个元组。
可以把类本身也看作一个对象， 称为类对象(Class Object)。 面向对象数据库模式是类的集合。 在一个面向对象数据库模式中， 会出现多个相似但又有所不同的类。 例如， 一个有关学校应用的面向对象数据库， 其中有教职员工和学生两个类， 这两个类都有身份证号， 姓名、 年龄、 性别、 住址等属性， 也有一些相同的方法和消息。 当然， 教职员工对象中有一些特殊的属性、 方法和消息， 如工龄、 工资、 办公室电话号码、 家庭员等。 用户希望统一定义教职员工和学生的公共属性、 方法和消息部分， 分别定义各自的特殊属性、 方法和消息部分。 为此， 面向对象的数据模型提供了一种类层次结构， 它可以实现上述要求。
图2.14 学校数据库的一个类层次
例如有关学校应用的面向对象数据库的例子， 可以定义一个类“人”。 人的属性、 方法和消息的集合是教职员工和学生的公共属性、 公共方法和公共消息的集合。 教职员工类和学生类定义为人的子类。 教职员工类只包含教职员工的特殊属性、 特殊方法和特殊消息的集合， 学生类也只包含学生的特殊属性、 特殊方法和特殊消息集合。 图2.14给出了学校数据库的一个类层次。 其中类及其对应的属性如下:
人(Person): 身份证号、 姓名、 年龄、 性别、 住址 教职员工(Employee): 工龄、 工资、 办公室电话号码、 家庭成员 教师(Teacher): 职称、 职务、 专长 行政人员(Officer): 职务、 职责、 办公室地址 工人(Worker): 工种、 级别、 所属部门 学生(Student): 入学年份、 专业 本科生(Undergraduate Student): 已修学分、 平均成绩 研究生(Graduate Student): 研究方向、 导师
为了叙述简单， 没有给出这些类的方法。 在这个类层次中， 教职员工和学生是人的子类， 教员、 行政人员、 工人是教职员工的子类。 教员、 行政人员、 工人中实际只有它本身的特殊属性、 方法和消息， 同时它们又继承教职员工类和人的所属性、 方法和消息。 因此， 逻辑上它们具有人、 教职员工和本身的所有属性、 方法和消息。 同样， 本科生和研究生是学生的子类。
上述超类/子类之间的关系体现了“IS A”的语义， 例如， 图中教员“IS A”教职员工(即“教员 is a教职员工”)， 教职员工“IS A”人。 因此， 超类是子类的抽象或普遍化， 子类是超类的特殊化或具体化。 在类层次中， 超类/子类之间的关系还会显示对象间的包含关系， 体现了“IS PART OF”的语义， 考虑一汽车结构数据库。 每一个汽车结构包括车轮、 车架、 发动机和齿轮。 车轮又包括一个轮框和一个轮胎。 结构的每一个构件都描述为一个对象， 同时构件间的包含也可以用对象间的包含来描述。
包含其他对象的对象称为复杂对象或复合对象。 这种情形就产生了对象间的包含层次， 如图2.15中所示。 复合对象可以存在多层包含。 在某些应用中， 一个对象可能要包含在多个对象中， 这时包含关系要用一个有向无环图（DAG）而不是用层次来表示， 如图2.16所示。
图2.15 对象之间的多层包含
图2.16 对象包含的有向无环图
5. 继承 类层次可以动态扩展， 一个新的子类能从一个或多个已有类导出。 根据一个类能否继承多个超类的特性， 将继承分成了单继承和多重继承。 若一个子类只能继承一个超类的特性(包括属性、 方法和消息)， 这种继承称为单继承: 若一个子类能继承多个超类的特性， 这种继承称为多重继承。 例如， 在学校中实际还有在职研究生， 他们既是教员又是学生， 在职研究生继承了教职员工和学生两个超类的所有属性、 方法和消息， 如图2.17所示。
图2.17 子类对超类的多重继承
单继承的层次结构图是一棵树（如图2.15）， 多继承的层次结构图是一个带根有向无环图(如图2.16)。 继承性有两个优点。 第一， 它是建模的有力工具， 提供了对现实世界简明而精确的描述。 第二， 它提供了信息重用机制。 由于子类可以继承超类的特性， 这就可以避免许多重复定义。
当然, 子类除了继承超类的特性外还要定义自己特殊的属性、 方法和消息。 在定义这些特殊属性、 方法和消息时可能与继承下来的超类的属性、 方法和消息发生冲突。 例如在教职员工类中已经定义了一个操作“打印”， 在教师子类又要定义一个操作“打印“， 用来打印教师的姓名、 年龄、 性别， 职称和专长， 这就产生了同名冲突。 这类冲突可能发生在子类与超类之间， 也可能发生在子类的多个直接超类之间。
这类冲突通常由系统解决， 在不同的系统中使用不同的冲突解决方法， 便产生了不同的继承性语义。 例如对于子类与超类之间的同名冲突， 一般是以子类定义的为准， 即子类的定义取代或替换由超类继承而来的定义; 对于子类的多个直接超类之间的同名冲突， 有的系统是在子类中规定超类的优先次序， 首先继承优先级最高的超类的定义， 有的系统则指定继承其中某一个超类的定义。 子类对父类既有继承又有发展， 继承的部分就是重用的成分。 由封装和继承还导出面向对象的其他优良特性， 如多态性、 动态联编等。
2.3.3 OO模型与E―R模型的概念对应关系 1．对象结构 粗略地讲， 一个对象对应着E―R模型中的一个实体。 面向对象模型的基础是将一个对象的相关数据和代码封装为一个单元。 在概念上, 一个对象和系统其余部分的所有交互都要通过消息， 因此， 对象和系统其余部分的接口定义为一个所允许的消息的集合。 一般来讲， 一个对象包含如下三个相关内容:
(1) 一个包含对象数据的变量集合。 每个变量对应于E―R模型中的一个属性。 (2) 一个对象所响应的消息集合。 每个消息可能有零个、 一个或多个参数。 (3) 一个方法集合。 每个方法是实现一个消息的代码段; 一个方法返回一个值作为对消息的响应。 对象的方法可以分为只读与更新。 只读方法不影响对象中变量的值， 更新方法则可能改变变量的值。
同样， 对象所响应的消息也可以根据实现这些消息的方法分成只读与更新。 在E―R模型中， 一个实体的派生属性在面向对象模型中可以表示为只读消息。 例如， 学生实体的派生属性年龄可以表示为一个学生对象的年龄消息， 实现这个消息的方法可以用当前日期减去学生的出生日期而得到其年龄。
严格来讲， 在面向对象模型中， 实体的任何属性都必须表示为相应对象中的一个变量和一对消息。 变量用来保存属性的值。 一对消息中其中一个用来读取属性值， 另外一个则用来更新这个值。 例如， 实体学生的属性籍贯可以表示为: 一个籍贯变量; 一个读籍贯消息， 回答籍贯是什么; 一个写籍贯消息， 接受一个参数， 更新籍贯内容。
2． 对象类 在数据库中通常有很多相似的对象。 这里所说的相似， 是指它们响应相同的消息， 使用相同的方法， 并且有相同名称和类型的变量。 对每个这样的对象单独进行定义是很浪费精力的。 因此， 我们将相似的对象分组形成一个类， 每个这样的对象称为类的一个实例， 一个类中的所有对象共享一个公共的定义， 尽管它们对变量所赋予的值不同。
面向对象数据模型中类的概念对应于E―R模型中实体集概念。 下面给出了用伪码写的学生类的简化定义。 这个定义显示了类的变量和类的对象所响应的消息(处理这些消息的方法在这里并没有给出)。
Class student /变量/ { string number; string name; string address; date date; /消息/ string number(); string get-name();
string get-address(); string set-address(string new-address); int age(); };
以上的定义中， 每个student类对象都包含如下变量: 字符串类型的number、 name和address， 日期类型的date。 每个对象都响应所列出的5个消息: number、 get-name、 get-address、 set-address和age。 每个消息名前面的类型名表示对消息的应答的类型。 同时， 我们也看到消息set-address接受一个参数new-address， 用来指定地址的新取值。
3． 继承 一个面向对象数据库的模式通常需要很多类， 然而经常有些类是相似的。 举例来说， 假定对于学校应用有一个面向对象数据库， 可以认为学生类与教师类相似， 因为它们都定义了name、 address等变量。 不过， 也有些变量是学生类所特有的或教师类所特有的。 为了能直接表示类之间的相似性， 需要使用类层次的概念。 类层次的概念对应于实体―联系模型中特殊化的概念。
例如， 学生类与教师类可以表示成由人类特殊化形成的类， 学生特有的变量和方法在学生中， 教师特有的变量和方法在教师中， 学生和教师都具有的变量和方法在人类中。 下面给出了用伪码写的类层次定义的简化定义。
Class person{ string name; string address; }; class student { string class-number; class teacher{ date start-date; int salary;
方法的继承方式与变量的继承方式相同。 在面向对象系统中， 继承性的一个重要好处是所谓可置换性: 一个类的方法， 比如A(或者是接受A类的对象作为参数的函数)， 可以等价地被属于A的任何子类B的任何对象来引发。 这种特性带来了代码重用的好处， 因为对于类B不必再重写这些方法和函数。 例如， 如果为类person定义了get-name()方法， 它就可以被一个person对象引发， 或者也可以被person的任何子类的任何对象所引发， 如student或teacher对象。
4． 多重继承 在多数情况下， 类的树形结构组织足以用来描述应用。 在这些树形结构中， 一个类的所有超类都在层次结构中互相作为祖先或后代(也就是说， 任何两个超类之间都是祖先和后代的关系)。 然而， 有些情况用树形结构类层次并不能很好地表达。 为了能直接表示一个类具有从多个超类中继承变量和方法的能力， 需要使用多重继承的概念。 在多重继承的情况下， 类―子类的关系可以用一个有向无环图来表示， 其中一个类可以有多于一个的超类。
多重继承概念对应于实体―联系模型中“角色”的概念。 再看学校的例子， 类person的多个子类， 如student、 teacher等。 一个对象可以同时属于这些类别中的多个， 每一个这样的类别被称为一个角色， 如有的教师可能在职学习， 他也是学生。 因此， 可以使用多重继承来创建诸如student-teacher等子类， 用以表达一个对象可能同时具有多种角色。
小 结 本章介绍抽象现实世界数据特征的数据模型。 主要讨论了常用的三种数据模型: 实体―联系模型、 关系数据模型和面向对象的模型的基本概念， 详细介绍了这三种数据模型在模型化数据和信息中的方法和应注意的事项， 并结合一个设计实例将前面介绍的理论知识加以应用。 其中的重点是概念模型， 这是数据库设计的基础。 学习这一章， 要努力掌握描述数据模型的基本概念， 并能运用这些概念设计出符合应用需求的数据模型。
习 题 2 1． 解释主键、 候选键和超键这些术语， 并说明彼此之间的区别。 2． 解释强实体集和弱实体集的差别。 习 题 2 1． 解释主键、 候选键和超键这些术语， 并说明彼此之间的区别。 2． 解释强实体集和弱实体集的差别。 3． 设计一个医院的E―R图。 医院有很多病人和医生， 同每个病人相关的是一系列检查和测试的记录。 4． 设计一个车辆保险公司的E―R图。 该公司有很多客户， 每个客户有一辆或多辆车， 每辆车可能发生0次或任意多次事故。
5． 将习题3、 4的E―R图转换成关系表。 6． 说明聚集的概念并举出两个例子。 7． 讨论用二元联系表示多元联系的的优点。 8． 面向对象程序设计的基本思想是什么? 它的主要特点是什么? 9． 解释OO模型中以下核心概念: 对象与对象标识、 封装、 类、 类层次。 10． OO模型中对象标识与关系模型中的“键”有什么区别？ 11． 请给出几个OO数据库类层次(包括各类对应的属性)实例。 12． 举例说明超类和子类的概念。