数据库查询方法的进步
Clement Yu,
芝加哥伊利诺大学
Weiyi Meng,
纽约州立大学
对于用户来说，一个数据库系统最重要的是能够使用户能够简单快速地获得他们想要的信息。能否满足用户要求取决于数据库系统、所存储数据的类型和数据库系统支持的查询。例如，如果数据存储在一个单一的表中，那么大多数查询（除了包含数量很多的连接操作）能够高效地响应，任何一个熟悉结构化查询语言的用户都能够轻松获得所需信息。
然而，当数据分布在网络上不同站点的几个关系数据库中时，高效率地检索数据会很难。因为这个过程与每个站点的进程；有关，也与站点之间的操作有关。另外，当数据存储在不同类型的数据库系统中时，例如关系型数据库与面向对象型数据库，检索数据会变得更加困难。因为每一个数据库系统的复杂性和独立性都必须考虑。
现在的数据库系统也可能混淆数据类型：例如在文档型数据库系统中，用户可以用自然语言作为查询条件，但查询结果通常不都准确。在图形数据库系统中，查询结果中匹配的信息就更少了。
帮助用户在关系型、面向对象型、文本型、图形型数据库协同工作的复杂环境中简捷高效地获取信息还有很多工作要做。在这篇文章中，我们列举了在分布式关系型数据库和多类型数据库中查询所取得的进步。
分布式关系型数据库
在分布式关系型数据库系统中，关系可被划分成几个部分。每一部分都是关系集合中的一个子集。同一关系的各个部分通常是分散存储在多个站点。这些组织在一起的数据支持局部查询。
进行这样的查询通常需要在各个站点间传输数据和各个局部站点的配合。因此一个分布式系统的查询的总体消费是数据传输和局部进程的和。总体耗费和响应时间是评判分布式数据库系统查询优劣的标准。
提高分布式数据库系统的查询效率有很多方法。我们有选择地列举一些。
鉴别局部进程的机会。确定一个局部查询过程能否在一个局部完成，而不需要数据传输，这时一个分布附属表就是一个很重要的信息来源。一个现实世界分布附属表的例子就是分布银行系统。如果客户在银行分支系统登录和访问他们的帐号，那么在分支银行和客户之间有一个关于分支名称的分布附属表。
假设你知道数据库的内部分布属性：关系
Ri
有两个方面
Fi1
和
Fi2
分别位于站点
1
和站点
2
，如果下列情况得到满足
F11
∞
A
F22=Φ
和
F12
∞
A
F21=
Φ
那么关于属性
A
在
R1
和
R2
之间有一个分布附属表。这里
∞
是并集符号，Φ是空集符号。
通过分配附属表系统现在可以把查询
R1
∞
A
R2
转换成两个局部查询：
F11
∞
A
F21
在站点
1
和
F12
∞
A F22
在站点
2
。结果系统不需要传输任何数据就能完成查询，除非要查询某个特定部分。
分方面和重定位。如果在关于属性
A
上
R1
、
R2
之间没有分配附属表，要完成
R1
∞
A
R2
，系统必须传输一些数据。这时分方面重定位系统选择保留段的一个关系，然后搜索包含第一个关系的段的每一个站点。例如如果
R1
是保留段，那么
F21
将被传输到站点
1
，这样在两个站点都有一个
R2
的拷贝。现在，原始查询就被分解为两个局部查询
,F11
∞
R2
在站点
1
和
F12
∞
R2
在站点
2
。这两个查询并行处理，从而节省了查询响应时间。
为了优化这个过程，你必须估计出最小消耗来，决定哪一个段被保留。还有一个更困难的你必须决定的问题是在哪一个站点上进行这个查询。
分步骤和重定位。有时你可以把一个不能分解的关系分成几步来通过这几部分在不同站点并行执行来缩短查询时间。分布重定位的策略就是把一个关系分成平行并列的几步，由这几步配合来完成查询。为了优化这个过程，你必须决定把哪一个关系分步，在哪一个站点上进行这个查询和每一步的合适大小。
哈希分步。哈希分步把每一个参考关系都进行分步，而不是仅把不能分段的一个关系分步。哈希分步需要关系的分配附属表，因为你可能在合并时取相同的哈希函数，这样确保不同关系对应不同站点。为了使这个策略正常工作，有一点必须做到就是关系必须分成大约相等的大小。当合并属性值不对称时，很难确保分段的平衡。一个基于哈希函数的处理方法正在一个非共享多处理器环境中高速地研究。