|
|
知识路径： > 数据库技术 > 数据库标准语言—SQL > SQL-99所支持的对象关系模型 >
|
被考次数：1次
被考频率：低频率
总体答错率：48%
知识难度系数： 
|
由 软考在线 用户真实做题大数据统计生成
|
|
相关知识点：17个
|
|
|
|
|
继承可以在类型的级别上进行，也可以在表级别上进行，下面分别介绍。
|
|
|
|
|
|
如希望在数据库中对那些是学生和教师的人分别存储一些额外的信息。
|
|
|
|
由于学生和教师是人，所以可以使用继承。在SQL-99中定义学生和教师类型如下：
|
|
|
|
|
|
Student和Teacher都继承了Person的属性，即name和address。Student和Teacher被称为Person的子类型，Person是Student的超类型，同时也是Teacher的超类型。像属性一样，结构类型的方法也被它的子类型继承。不过，子类型可以通过在一个方法声明中使用overriding method（重载方法）取代原method（方法）的方式重新声明方法，以重定义该方法的作用。
|
|
|
|
现在假定要存储关于助教的信息，这些助教既是学生又是教师，甚至可能是在不同的系里。可以利用多重继承（multiple inheritance）的方法来做。SQL-99标准不支持多重继承，然而SQL-99标准是提供多重继承的，尽管SQL-99最终版中忽略了它，但SQL标准的未来版本可能会引入它。基于SQL-99标准的草案来讨论问题。
|
|
|
|
TeacherAssistant将继承Student和Teacher的所有属性。由于name和address属性实际上是从同一个来源即Person继承来的，因此同时从Student和Teacher中都继承这两个属性不会引起冲突。但是，一个助教既可能是某个系的学生同时又是另一个系的教师，所以department属性在Student和Teacher中分别都有定义。为了避免两次出现的department之间的冲突，我们可以使用as子句将它们重新命名，如下面的TeachingAssistant类型定义所示：
|
|
|
|
|
|
注意SQL-99只支持单继承，即一个类型只能继承一种类型，使用的语法如例8.35。TeachingAssistant例子中的多重继承在SQL-99中是不支持的。SQL-99标准还需要在类型定义的尾部有一个特别的字段，取值为final或not final。其中，关键字final表示不能从给定类型创建子类型，not final表示可以创建子类型。
|
|
|
|
SQL中的一个结构类型的值必须恰好只有一个“最明确类型（most-specific type）”，即每一个值被创建时必须关联到一个确定的类型，称为它的最明确类型。依靠继承，它也与它的最明确类型的每个超类型相关联。举例来说，假定一个实体具有类型Person，同时又具有类型Student，那么这个实体的最明确类型为Student，因为Student是Person的子类型。然而一个实体不能同时既具有类型Student又具有类型Teacher，除非这个实体具有一个如TeacherAssistant那样既是Student子类型又是Teacher的子类型的类型。
|
|
|
|
|
|
SQL-99中的子表（subtable）对应的是E-R概念中的特殊化／一般化。子表的类型必须是父表类型的子类型，因此，父表中的每一个属性均出现在子表中。
|
|
|
|
|
|
|
|
当我们声明students和teachers作为people的子表时，每一个students或teachers中出现的元组也隐式存在于people中。如果一个查询用到people表，它将查找的不仅仅是直接插入到这个表中的元组，而且还包含插入到它的子表（也就是students和teachers）中的元组。但是，只有出现在people中的属性才可以被访问。
|
|
|
|
多重继承也可在表进行。例如，创建一个类型为TeachingAssistant的表：
|
|
|
|
|
|
作为声明的结果，每一个在teaching-assistants中出现的元组也隐式地在表teachers和students中出现，从而也出现在people表中。SQL-99允许在查询中使用“only people”代替people来查询只在people中而不在它的子表中的元组。
|
|
|
|
对子表的一致性要求。如果一个子表和一个父表中的元组对于所有的继承属性具有同样的值，则称子表中的元组符合（correspond to）父表中的元组。因此，相符合的元组表示同一个实体。子表的一致性需求为：
|
|
|
|
.父表的每个元组至多可以与它的每个直接子表的一个元组符合。
|
|
|
|
.SQL-99有一个附加的约束，所有相符合的元组必须由一个元组派生（插入到一个表中）。
|
|
|
|
例如，若没有第一个条件，我们就可能在students（或teachers）中有两个元组与同一个人符合。第二个条件排除了people中的一个元组分别符合students和teachers中的一个元组的情况，除非所有这些元组都隐式出现。这是由于一个元组会被插入到一个既是teacher的子表又是students的子表的teaching-assistants表中。
|
|
|
|
由于SQL-99不支持多重继承，所以第二个条件实际上阻止一个人既是老师又是学生。即使支持多重继承，这个问题在没有子表teaching-assistants时也会出现。显然，建立一个即使没有teaching-assistants子表也可以让一个人既是老师又是学生的环境是很有用的。因此，去掉第二个一致性约束是有用的。
|
|
|
|
子表可以采用无须复制所有的继承字段的有效方式进行存储，通常有如下两种方式：
|
|
|
|
.每一个表只存储主码（可能是从父表中继承来的）和局部定义的属性。继承属性（主码之外的）不需要存储，因为它可以基于主码与父表连接得到。
|
|
|
|
.每一个表存储所有继承的和局部定义的属性。当插入一个元组时，它仅仅存储在它被插入的那个表中，在它的每个父表中推断它的出现。因为不需要连接，所以可快速访问元组的所有属性。不过，一旦没有第二个一致性约束（即一个实体可能出现在两个子表中而不在它们的公共子表中出现），这种表达将导致信息重复的问题。
|
|
|
