关系数据库的查询优化始终是一个重要而实际的问题，在那些以查询为主的应用系统中，这几乎是一个成败攸关的问题。但迄今为止，关于这个问题的讨论中所提出的种种解决方案大致可分为两大类，即利用硬件体系结构上的优势及DBMS对并行处理的支持能力的一类方案及完全由应用设计来处理的方案。在本文作者以前所发表的文章中曾推荐过利用临时中介表和表更新方法和快查询处理的策略。在同一篇文章中，我们也曾提到有可能利用程序变换支持查询优化的想法。所有这些建议和想法都属于应用设计类的处理办法，这些方法从某种意义上说有一定的一般性。但是，实际应用不断地提出这样或那样难而“怪”的问题，这些问题极富挑战性，用常规方法往往要以很昂贵的系统资源为代价才有望解决。
本文的目的是向读者介绍一种由E.Birger等人首先提出的方法，即加速查询处理的特征函数法。这个方法适用于大多数SQL的数据库系统，如果这类系统还包括为数不多的几个（最少为2个）内部函数，如abs（）及sign（）等，则这个方法就是直接可用的了。在E．Birger等人关于这个方法的研究报告中，曾给出很多极有难度而又很典型的查询要求及其求解办法，其中包括分技条件查询、求行内量的边界值、求直方图、表转置、求中位值、有序集的等段截分以及去边界值问题等。这些问题的共性是，若用常规方法求解，系统无论在存储开销上还是处理开销上都很大，而某些问题（如中值）的求解还相当难。本文将重述这些有趣的查询问题及其解决方案。同时，我们还将讨论“特征函数”作为一种使能技术的其他一些应用可能。
在这里，任意元素x是否属于集合S，决定函数取不同的值。同时，这里也隐含了一个前提，即任何元素的集合S为范围的归属是完全确定的，不存在元素x的归属不明的情况。显而易见，特征函数是一种识别（或判定）装置。正是这一特性，使它能够成为数据库查询中选择准则的一种等价（和更有效的）替换成分。因此，我们说特征函数是加速查询的实施技术。
众所周知，一般关系数据库采用三值逻辑，即布尔表达式有可能取不确定值（“maybe”）。但为了简化表达并因此突出特征函数在加速查询中的本质作用，本文不考虑表属性取不确定值的情形。另外，实现特征函数的数据库（内部）函数（我们称之为特征函数的“元函数”）会因系统和我们主观选择上的不同而不同。例如，Sybase的Transact SQL有两个很有用的内部函数abs（）和sign（），可以直接作为特征函数的元函数。若A和B是任意两个表属性，则:
这里的A和B是表属性，为非空数值量。等式（5）给出了6个最简单的特征函数的元函数表示，但这并不是唯一的表示，还可能其他的表示方法。等式（6）是布尔算子的一般导出规则。对于由最简型式的关系表达式构成的布尔表达式而言，等式（5）和（6）就构成其特征函数的实现规则。对于一般布尔表达式，等式（5）和（6）也是导出其特征函数的基础。一般而言，由（5）和（6）可以推演出一个特征函数类，某些特征函数直接对应于SQL的选择算子。例如，形如d ［A<＝X<＝B］的特征函数显然与判定变量X是否在闭区间［A，B］中有关。利用（5）中的第4个特征函数及（6）中的第2个导出规则:
d ［A<＝X<＝B］
＝d ［(A<＝X)AND(X<＝B)］
＝d ［A<＝X］*d ［X<＝B］
＝sign(1－sign（A－X））*sign(1－sign(x－B）） (7)
显而易见，等式（7）右端的区则算术表达式恰是选择算子BETWEEN的一种等价表达。可以仿照上述方法得到其他三个与区间值有关的特征函数，即δ［A
3． 实例分析
为了说明以上引入的特征函数在加速查询处理中的作用，让我们具体分析一个实例。
试考察一个描述学生收入状况的表 Students（name，status，parentincome，selfincome）（8）
其中name是主键，属性status是一种标法量，当status取值1时，表明学生的收入完全来自父母，当status取值0时，表明学生的收入完全是自己劳动所得。针对这个表，假定我们想得到形如（name，income）的查询结果，其中income或为学生自己的收入（当相应的status取0值时）或是来自父母的收入（当相应的status取值为1时）。
从表students的结构及查询结果的语义分析，完成查询的常规方法应当是:
SELECT name，income=parentincome
FROM student
WHERE student=1 UNION (9)
SELECT name , income=selfincome
FROM student
WHERE student=0
这是一个很自然、很直白的查询表达，但同时也是一个非常低效和非常耗费资源的表达。执行这个查询的一般过程是：首先分别执行由算子UNION所连结的两个子查询，然后产生一个存放查询中间结果的临时表并将两个子查询的结果存入以这个临时表中，第3步对临时表作排序以便消除可能存在的重复值。至此，才得到最终的查询结果。在这样的处理中，除对整个表students要遍历两次而且要对中间结果作排序处理，处理上的烦杂和资源的消耗都是显而易见的。查询（9）唯一的优点，是它表达上的自然直白，谁都想得到。
对本例而言，还有更紧凑和更有效的查询表达。例如，不难验证以下的查询:
SEIECT name，income=parentincome*status+selfincome*(1-status)
FROM students； （10）
从语义上与查询（9）完全等价。但查询（10）不但消耗的存储少而且处理上要有效得多，因为它只遍历一次表students而且避免了可怕的排序操作。这个例子说明，对同一个查询结果，不同的查询表达在处理效率和资源消耗上可能会相去甚远。因此，寻求有效的查询表达方式，不但是必要的而且是可行的。
查询表达（10）与像（9）那样的常规表达不同之处在于，后者的查询条件由两个WHERE子句和算子UNION显式给出，首者将查询条件间接地隐藏在SELECT子句的算术表达式中。无论查询表达采用什么形式，本例都属于“条件检索”的查询类型。如果对照一下查询要求和查询表达（10），不难发现只所以能给出如此简洁而正确的回签，实在是有点“事有凑巧”。如果问题稍作些许改变（例如，属性student取0和1以外的值，或者student取两个以上的标法值，如此等等）问题就不会这么简单了。因此，是否有一种很一般、很系统的解决方案，能让我们对任何显式表达在WHERE子句和相关算子中的选择条件找到与之语义等价的算术表达式？答案是肯定的。
来源:网络