[发明专利]关系型数据库管理系统中删减聚类表的磁盘块

说明书

技术领域

本发明涉及关系型数据库管理系统，并且更具体地，涉及用于在关系型数据库管理系统中聚类(cluster)表的技术。

背景技术

在本节中描述的方法是可以实行的方法，但不一定是先前已被构想或实行的方法。因此，除非另外指出，否则不应当假设本节中描述的任何方法仅仅因为它们被包括在本节中就被算作为现有技术。

在数据库系统的上下文中，“维度”是为数据提供类别的值的列表。维度充当用于识别变量的值的索引。例如，如果销售数据具有每个月单独的销售数字，则该数据具有MONTH维度。即，该数据通过月进行组织。维度类似于关系型数据库中的键。通过两维或更多维组织的数据被称为“多维数据”。

多维变量中的任何数据项都可以通过为变量的每个维度指定一个成员来进行唯一且完全地选择。例如，如果sales变量通过MONTH、PRODUCT和MARKET标出维度，则为MONTH维度指定“January”、为PRODUCT维度指定“Stereos”和为MARKET维度指定“Eastern Region”就为该变量唯一地指定了单个值。因此，维度提供了简明和直观的组织和选择数据的方式，用于检索、更新和执行计算。

多维数据可以存储在关系型数据库系统中。当多维数据存储在关系型数据库系统中时，应用通过提交符合关系型数据库系统支持的数据库语言的命令访问数据，最常见的数据库语言是结构化查询语言(SQL)。

关系型数据库系统以关联表的形式存储数据，其中每个表都具有一列或多列以及一行或多行。用于在关系型数据库系统中存储多维数据的常规机制是将数据存储在表中，其中表以被称为星型架构(star schema)的方式进行布置。在关系型数据库系统中，星型架构的特点是存在一个或多个相对较大的表和若干个相对较小的表。较大的表没有重复较小表中包含的信息，而是引用较小表中的行。在星型架构中，较大的表被称为“事实表”，而较小的表被称为“维度表”。图1说明了具有两个维度的示例性星型架构。

参考图1，它说明了包括表102、104和106的数据库100。表102被命名为“stores(商店)”并且包含关于其中可能发生销售的每个商店的信息。stores表102中每一行包含唯一的store-id和关于对应于该store-id的特定商店的信息。表104被命名为“products(产品)”并且包含关于可以在任何商店销售的每种类型产品的信息。products表104中每一行包含唯一的product-id以及关于特定产品的信息。

表106被命名为“sales(销售)”并且包含在stores表102中表示的每个商店中的每笔销售的信息。sales表106中每一行包括以美元为单位的amount(量)、指示做出销售的商店的store-id、指示在销售中售出的产品的product-id以及销售的日期。通常，销售的数量将远远高于做出销售的商店的数量和由商店具有的产品数量。关于在销售中包含的商店和产品的详细信息不必存储在sales表106的行中，因为这些详细信息分别可以从stores表102和products表104中得到。相反，表106的行包含引用在其它表102和104中存储的信息的值(store-id和product-id)。因此，表102、104和106构成星型架构，其中表106是事实表并且表102和104是维度表。

存储在事实表106中的数据只有两个维度，事实表106具有两个列(STORE-ID和PRODUCT-ID)专门为这些维度存储外键值(foreign key value)。通常，事实表专门用一列为与事实表中存储的多维数据相关联的每个维度存储外键值。通过在事实表中存储引用维度表中的行的外键值，事实表中的行可以保持在相对较小的尺寸并且事实表的列的数量可以保持在相对较小的数量。例如，sales表106不是包含stores表102的MANAGER(管理员)、CITY(城市)和STATE(州)列中的值和products表104的SOURCE(来源)、PARTS(件数)和COST(成本)列中的值，而是sales表106在两个列中包含外键值，一列引用stores表102中的行并且另一列引用products表104中的行。典型的事实表中行的数量可以是数十亿或者更多。作为对照，维度表中行的数量通常少得多(例如，数十、数百或数千)。相应地，典型的星型架构被构造成最小化在事实表的每一行中储存的数据量。