JP4785833B2

JP4785833B2 - 永続的でユーザアクセス可能なビットマップ値を有するデータベース管理システム

Info

Publication number: JP4785833B2
Application number: JP2007505024A
Authority: JP
Inventors: インフ; ティモシーチョルマ; シーマスンダラ; ユージンインソクション; スーリプリヤダス; ジャガンナサンスリニヴァサン
Original assignee: オラクル・インターナショナル・コーポレイション
Priority date: 2004-03-26
Filing date: 2005-03-17
Publication date: 2011-10-05
Anticipated expiration: 2025-03-17
Also published as: AU2005233925B2; CN101036141A; WO2005101250A3; US20050216518A1; JP2007531115A; CA2560453A1; AU2005233925A1; WO2005101250A2; CA2560453C; CN101036141B; EP1735727A2

Description

発明の背景
１．発明の分野
本発明は、データベース管理システムに関し、特に、データベース管理システムにおいてビットマップ値を使用して1セットのオブジェクトのサブセットを表すことに関する。

２．関連技術の説明
以下の「関連技術の説明」ではまず、現代のデータベース管理システムによって実現されている組込みインデックス付けシステムについて説明し、次に、現代のデータベース管理システムがさらに、ユーザが独自の種類のインデックス付けシステムをデータベース管理システムによって使用できるように定義するのをどのように可能にしているかについて説明する。

インデックス全般
大量の情報は、インデックスを含めることによってさらにいっそう使いやすくなる。たとえば、アメリカ革命戦争の歴史がインデックスを有し、この歴史のある読者が1776年3月17日にイギリス人をボストンから避難させた際のヘンリー・ノックス将軍の役割に関心を抱いている場合、この読者は、インデックスにおける「ヘンリー・ノックス」を参照するだけでよく、この読者は、ノックス将軍について述べられている歴史の本のページのリストを見ることができる。インデックスがない場合、この読者は、探していることを見つけるために本の大部分を走査する必要がある。以下の議論で使用される用語において、アメリカ革命の歴史は1セットの情報を定義しており、この歴史の読者は、この1セットの情報の一部にのみ関心を抱くことが多く、この部分をこの情報のサブセットと呼ぶ。したがって、この歴史のインデックスによって、情報のサブセットの位置が指定され、それによって、ユーザはインデックス付けされたサブセットに迅速にアクセスすることができる。

組込みインデックス付けシステム
データベース管理システムは、大量の情報を管理しそれにアクセスできるようにするために存在しており、予想されるように、データベース管理システムはインデックスを有している。リレーショナルデータベース管理システムでは、情報の集合はテーブル（tables）として構成される。データベーステーブルは、いくつかの列（columns)を有し、かついくつかの行（rows）を有してよい。各行は、各列に対応するフィールド（field）を有する。列に対応するフィールドの値は、その列に必要な種類の値を有する。たとえば、以下の簡単なテーブル「従業員（Employees)」は4つの列および2つの行を有している。

各行は、従業員を表している。列「行id（Rowid）」は、テーブル内の各行の、データベースシステムによって割り当てられた行識別子がフィールドに含まれる組込み列である。この行識別子は、データベース管理システムにおいて行を一意に識別する。列「名前（Name）」に対応するフィールドは、行で表された従業員の名前を含む。性別（Gender)に対応するフィールドは、従業員の生物学的な性別を含み、最後に、肩書きに対応するフィールドは従業員の肩書き（Job_Title)を含む。ユーザは、テーブルから情報を得る場合、情報が取り込まれる行およびそれらの行から取り込まれる情報を記述したクエリー（query）をデータベース管理システムに与える。たとえば、
SELECT Name FROM Employees WHERE Job_Title = Manager
というクエリーは、肩書きフィールドが値「責任者（Manager）」を有する行、すなわち、行idが1である行を「従業員（Employees）」から選択し、その行から名前（Name)フィールドの値、すなわち、スミス（Smith)）を返す。冒頭の議論に関して、クエリーは、「従業員（Employees）」に含まれる1セットの情報のサブセットを指定し、指定されたサブセットを返す。

「従業員（Employees）」のインデックスを作成してもほとんど価値がないが、作成することは可能である。実際、「従業員（Employees）」が10,000行のテーブルである場合に、インデックスを作成することに価値があることは明確である。たとえば、「従業員（Employees）」上の名前（Name)列の値によるインデックスは、ジョーンズ2、スミス1のようなものである。インデックスは、名前をアルファベット順に有し、各名前の後に、その名前が現れる行の行idが位置する。カリフォルニア州レッドウッド・シティのオラクル社によって製造されているOracle 9i（登録商標）データベース管理システムのような現代のデータベース管理システムは、ユーザが上記の例で名前インデックスを指定するのを可能にする組込みインデックス付け機能を含む。データベース管理システムにおけるこのようなインデックスの指定は以下のようになる。
CREATE INDEX employees_name_index ON Emproyees(Name)
この指定に応じて、データベース管理システムは、インデックスを作成し、このインデックスが属するテーブルが変更されたときにインデックスを更新し、このインデックスを使用してテーブルに関するクエリーを迅速化する。たとえば、上記のインデックスおよび以下のクエリーが与えられたと仮定すると、
SELECT Job Title FROM Employees WHERE Name = Smith
データベース管理システムはこのインデックスを使用して、名前(Name)フィールドが値「スミス(Smith)」を有する行を見つけるまでテーブルを読み進めるのではなく、スミス(Smith)の行が行1であるかどうかを判定する。したがって、クエリーでインデックスを使用することは、歴史の本の読者が各人間ごとにインデックスを使用することによく似ている。

現代のデータベース管理システムによって作成されるインデックスの1種にビットマップインデックス(bitmap index)がある。ビットマップ(bitmap)は、1セットのオブジェクトにマップされたビットのシーケンスである。各ビットは、そのセット内の1つのオブジェクトに対応する。ビットマップ値(bitmap value)は、1セットのオブジェクトのサブセットを指定するように各ビットがセットされたビットマップである。あるオブジェクトがそのサブセットに属する場合、ビットマップ値内のそのオブジェクトに対応するビットがセットされる。現代のデータベース管理システムに使用されるビットマップインデックスでは、ビットマップは、テーブル内の各行を表す1セットの行idにマップされている。たとえば、テーブル「従業員(employees)」には2つの行があり、したがって、1セットの行idは2つのメンバーを有し、ビットマップは2つの値を有する。発明者の例では、ビットマップの第1のビットは行id1にマップされ、第2のビットは行id2にマップされる。ビットマップ内の各ビットがテーブル内の行idにマップされるので、ビットマップ値はテーブルのインデックスとして使用することができる。たとえば、テーブル「従業員(employees)」内の1セットの行idを表すビットマップ値を使用して、性別（Gender）フィールド内に値Mを有するテーブル内のすべての行を示すことができる。このようなビットマップ値では、テーブルの所与の行idを表すビットは、行の性別（Gender）フィールドにMが存在するときには値1を有し、そうでない場合には0を有する。「従業員(employees)」内の性別フィールド内の値Mのビットマップ値の例としては、0、1が挙げられる。値Mは、ビットマップのキー（key）と呼ばれる。値Mを有する行を見つける場合、データベース管理システムはそのキーのビットマップ値を参照し、1がビットマップ値の第2のビットであることから、この値を有する行は、行id2を有する行であると判定する。

オラクル9iデータベース管理システムは、ユーザが、テーブルの列についてビットマップインデックスを作成することを指定するのを可能にする。データベース管理システムは、列の各フィールドのそれぞれの可能な値のビットマップ値を含むビットマップインデックスを作成することによってこのような指定に応答する。たとえば、性別（Gender)列内の各フィールドは2つの値のみ、すなわち、MおよびFを有することができる。したがって、この列については、データベース管理システムは2つのビットマップ値を作成し、すなわち、キーM用に一方の値を作成し、キーF用に他方の値を作成する。オラクル9iデータベース管理システムにこのようなインデックスを作成させる指定は以下のようになる。
CREATE BITMAP INDEX Gender_index ON Employees(Gender)
Mキーのビットマップ値は、上述のように0、1であり、Fキーのビットマップ値は1、0である。したがって、Mキーのビットマップ値は、行id2を有する行を含む、テーブル「従業員（Employees）」の行のサブセットを指定し、Fキーのビットマップ値は、行id1を有する行を含むサブセットを指定する。

ビットマップインデックスの利点は、ビットマップインデックスが占有する空間が非常に狭く、クエリー中のAND、OR、NOTなどの論理演算を、ビットマップ値に対して実行することによって、ビットマップインデックスを有するフィールドに対して非常に高速に実行できることである。たとえば、クエリー
SELECT Name FROM Employees WHERE Gender = 'M' OR Gender = 'F'
は、キーがMである性別(Gender)のビットマップ値、すなわち、1、0とキーがFである性別のビットマップ値、すなわち、0、1の論理和をとり、「従業員(Employees)」におけるあらゆる行を選択することを指定するビットマップ値1、1を生成する。オラクル9iデータベース管理システムによって実現される組込みインデックス付けシステムは、2002年にオラクル社から発行され、オラクル社から部品番号A96524-01として市販されているOracle 9i Database Concepts, Release 2の10〜28ページのインデックスの節から詳しく記載されている。この記載は参照として本特許出願に組み入れられる。

ユーザ定義インデックス付けシステム
組込みインデックス付けシステムが設計されたデータベース管理システムでは、データベース管理システムのテーブルの各フィールドに含まれる値は、少数の組込みデータタイプのうちの1つに属する必要があった。組込みデータタイプには通常、名前および語用の文字データタイプ、10進数用の10進数データタイプ、全数用の整数データタイプ、およびデータベース管理システムのメタデータ、すなわち、テーブルを定義するデータに使用されるシステム値のデータタイプが含まれていた。テーブル「従業員(Employees)」の例では、行idはこのようなシステムデータである。他のフィールド内のデータは文字データタイプを有する。より最近では、データベース管理システムは、ユーザが自分自身のデータタイプを定義し、これらのデータタイプを有する値をデータベース管理システムのテーブル内のフィールドで使用するのを可能にする構成を含んでいる。ユーザ定義データタイプは、ユーザが興味を持つドメインで使用される。たとえば、写真に興味を持つユーザは、そのドメインに適したデータタイプを定義することができる。一例としてデータタイプ「写真(Photograph)」が挙げられる。写真(Photograph)の定義は、最低でも、タイプ「写真(Photograph)」の値がデータベース管理システムでどのように表されるかを指定する。定義は、この種の値に対して実行できる演算を指定することもできる。たとえば、ドメインにおいて写真同士を比較する必要がある場合、定義は、2つの写真を比較し、類似性の尺度である結果を返すLike演算を指定することができる。最後に、定義は、タイプ「写真」の値用のインデックス付けシステムを指定することができる。このためには、ユーザは、インデックスがどのように定義されるか、インデックスがどのように維持されるか、およびインデックスがどのように読み取られるかを指定しなければならない。オラクル9iデータベース管理システムにおいてユーザ定義タイプおよびそれに対する演算を定義するのに使用される機構は、オラクル社から市販されているOracle 9i Data Cartridge Developer's Guide, Release 2(9.2), Part No. A96595-01に記載されている。ユーザ定義インデックス付けの議論は、第7章「ドメインインデックスの作成」に記載されている。この参照全体が参照として本出願に組み入れられる。

組込みおよびユーザ定義インデックス付けシステムの制限
組込みインデックス付けシステムは使いやすく効率的であるが、インデックスの種類の数が限定されている。たとえば、オラクル9iデータベース管理システムは現在、以下の組込みインデックス付け方式を提供している。
・Bツリー・インデックス
・Bツリー・クラスタ・インデックス
・ハッシュ・クラスタ・インデックス
・逆キー・インデックス
・ビットマップ・インデックス
・ビットマップ結合インデックス
さらに、これらのインデックス付け方式を使用してもインデックス付けできないある種の組込みデータタイプがあり、組込みインデックス付け方式はユーザ定義タイプとの使用が限定されている。組込みインデックス付け方式の最後の欠点は、ユーザが、データベース管理システムがインデックスを作成する方法をほとんど制御できず、また内部インデックス付けデータにはアクセスできないことである。

たとえば、ビットマップインデックスでは、システムは常に、値がキーとして使用されるフィールドのあらゆる可能な値用のビットマップを作成する。システムはさらに、キーとして使用される値が相互に排他的であり、かつインデックスが作成される列の値がシステム定義タイプに属することを必要とする。しかし、ユーザがあるキー値のみのインデックスまたは値の重複した範囲用のインデックス、あるいはユーザ定義タイプ用のインデックスに関心を抱く多数の状況があり、組込みビットマップインデックスはこれらの状況では役に立たない。さらに、データベース管理システムがビットマップ値を作成して操作するのに使用するプリミティブ演算にユーザがアクセスすることはできない。たとえば、ユーザは、ユーザ定義クエリーによって返される行idを表すビットマップ値を作成することができない。

ユーザはもちろん、インデックス付けされるデータのドメインに役立つ任意のインデックス付けシステムを使用するユーザ定義インデックス付けシステムを作成することができる。このようなユーザ定義インデックス付け方式の欠点は、ユーザがインデックス付け方式を設計しプログラムするのにかなりの労力を必要とすることである。このようなインデックス方式を設計しプログラムするのに必要な労力を増大させることの1つは、プログラマがインデックス付けプリミティブを利用できないことである。

上述のように、ビットマップ値は、数セットのオブジェクトのコンパクトな表現であるためインデックス付け方式に使用される。数セットのオブジェクトのコンパクトな表現を必要とする他の状況でビットマップ値を使用するのは可能ではない。なぜなら、データベース管理システムを使用しているプログラマがビットマップ値自体にアクセスすることもそのプリミティブ演算にアクセスすることもできないからである。

MySQLオープンソースリレーショナルデータベースシステムは、数セットの最大で64個のユーザ定義オブジェクトを表すのに使用されるSET組込みデータタイプを有する。SETタイプの値は、ユーザ定義された特定の1セットのオブジェクトのサブセットを表し、このサブセットは、このユーザ定義された特定の1セットのオブジェクト上にマップされ、このサブセットに属する各オブジェクトにセットされたビットを有するビットマップ値で表されるMySQLは、SETタイプの値用のプリミティブ演算を実現するが、セット内のオブジェクトの数が64に限定されているため、MySQLは、大きな数セットのオブジェクトのサブセットを表すことのできるビットマップ値を必要とするアプリケーションには役に立たない。このようなアプリケーションの1つの主要なクラスはもちろんビットマップインデックスある。

前述のことから分かるように、プログラマが大きな数セットの値のサブセットを指定するビットマップ値およびビットマップ用のプリミティブ演算にアクセスできるデータベース管理システムは、ビットマップインデックスを使用できる状況の数を大幅に増加させ、ビットマップインデックスを、ユーザ定義クラスを有するオブジェクトと一緒に使用するのを可能にし、ビットマップ値を使用して一般に大きな数セットのオブジェクトのサブセットを表すのを可能にする。本明細書で開示される本発明の目的は、このようなデータベース管理システムを提供することである。

発明の概要
本発明の目的は、改良されたデータベース管理システムによって実現される。データベース管理システムは、ビットストリングの表現内のセットされたビットが、定義がデータベース管理システムに組み込まれる1セットのオブジェクトを指定する、ビットマップ値を有する。データベース管理システムは、ビットマップ値に対するユーザアクセス可能演算も有する。演算には以下のうちの少なくとも1つが含まれる。
・ビットマップ値が所与の1セットのオブジェクトから算出されるセット・ツー・ビットマップ演算
−算出される値が、所与の1セット内のオブジェクトを指定する新しいビットマップ値である、セット・ツー・ビットマップ演算、
−算出される値が、所与の1セット内のオブジェクトを指定することになる既存のビットマップ値である、セット・ツー・ビットマップ演算、および
−算出されるビットマップ値が、もはや所与の1セット内のオブジェクトを指定しない既存のビットマップ値である。
・所与のビットマップ値に指定された1セットのオブジェクトが所与のビットマップ値から算出される、ビットマップ・ツー・セット演算、
・所与のビットマップ値によって指定された1セット内のオブジェクトの数が所与のビットマップ値から算出されるビットマップ・ツー・カウント演算、
・所与のオブジェクトが所与のビットマップ値で表される1セットのオブジェクトに属するときに論理値TRUEを表す値が返される存在演算、
・ビットマップ値で表されるビットストリングに対する論理演算であって、AND演算、OR演算、XOR演算、およびMINUS演算を含む論理演算、
・2つのビットマップ値が同じ1セットのオブジェクトを指定するときに論理値TRUEを表す値が返されるビットマップEQUAL演算、および
・ビットマップソース値がターゲットビットマップデータ項目に代入されるビットマップ代入演算。
本発明の他の局面では、ビットマップ値は、データベース管理システムにおいて永続的であり、データベース管理システムにおけるテーブル内のフィールドの値であってよい。ビットマップ値内のビットストリングは圧縮することができる。

定義がデータベース管理システムに組み込まれるオブジェクトは、データベース管理システムに存在する他のオブジェクト用の識別子であってよい。識別子は行識別子であってよく、ビットマップ値で表される行識別子は、データベース管理システムで実行されるユーザ定義クエリーによって返すことができる。定義がデータベース管理システムに組み込まれるオブジェクトは、データベース管理システムの外部に存在する他のオブジェクトの識別子であってもよい。本発明の一局面では、識別子は製品品目用のEPCである。

他の局面では、本発明は、データベース管理システムにおいて第1セットのオブジェクトを表すのに使用されるビットマップ値である。第1のオブジェクトは、データベース管理システムの外部に存在する。第1セットのオブジェクトのメンバーは、データベース管理システムに定義されている第2セットの第2のオブジェクトの各メンバー上にマップされる。ビットマップ値は、マッピング指定子およびビットのストリングの表現を含む。マッピング指定子は、表現されるビットのストリングを第2セットのサブセットにマップする。ビットは、そのビットにマップされる第2セットのメンバーが、それにマップされる第1セットのメンバーを有するときに、表現されるビットのストリングにおいてセットされる。

第2セットのオブジェクトは順序付けることができ、そのセットのメンバーの順序は各メンバーの値に対応してよい。このような状況では、マッピング指定子は、順序付けされた第2セットのメンバーの値の1つまたは複数の範囲を指定し、ビットのストリングの表現は、これらの範囲に対応するビットのストリングを表す。これらの範囲は、開始値および終了値ならびに／またはプレフィックス値によって指定することができる。ある種のビットマップ演算は、範囲指定子およびそれに対応するビットストリングの表現を変更することができる。

他の局面では、本発明は、データベース管理システムに定義された行識別子の第1のサブセットを表すビットマップ値である。このビットマップ値は、マッピング指定子およびビットストリング表現を含み、データベース管理システムによって実行されたユーザ定義クエリーによって行idの第1のサブセットが返される。行識別子のサブセットを表すビットマップ値を使用して、データベース管理システムのテーブルに記憶することのできる任意の1セットのオブジェクトの属性値によってインデックスを作成することができる。

他の局面では、本発明は、1セットのEPCの表現である。この表現は、この1セットのメンバーを含むEPCの範囲を指定する範囲指定子と、範囲指定子によって指定された範囲にマップされるビットストリング表現とを含む。この表現は、1セットのEPCの空間効率的な表現が必要であるときはいつでも使用することができる。

本発明が関する当業者には、以下の「詳細な説明」および図面を検討したときに他の目的および利点が明らかになろう。

図面中の参照番号は、3つ以上の数字を有し、右側の2つの数字は、残りの数字で示される図面内の参照番号である。したがって、参照番号203を有する項目は最初に、図2の項目203として現れる。

詳細な説明
以下の詳細な説明ではまず、数セットの行idを表すビットマップ値を使用して作成されるインデックスについて概略的に説明し、次に、データベース管理システムにおいてビットマップ値をどのように定義したらよいかと、ビットマップ値に対して実行できる演算について概略的に説明し、最後に、2つの異なる種類のビットマップ値、すなわち、ビットマップ値が数セットの行id上にマップされる種類とビットマップ値が数セットのEPC（ePC）上にマップされる他の種類について説明する。現在、バーコードなどの製品コードは、製品の種類、たとえば、チューブ入り歯磨きのブランドおよび味を識別しているに過ぎない。その味を有するそのブランドの各チューブ入り歯磨きは、その種類のバーコードを保持している。個々の製品上のePCは、製品の種類を識別するだけでなく、個々の製品品目も一意に識別する。したがって、各チューブ入り歯磨きはそれ自体のePCを有する。

ビットマップ値の概要：図1
図1は、行idビットマップ値111を第1のテーブル103内の1セットの行にどのように関係付けたらよいかと、第1のテーブルの各行に含まれる情報用のインデックスとして働く第2のテーブル115でビットマップ値をどのように使用したらよいかを101に示している。図1では、テーブル列は、参照番号によって識別され、行は、その行の行idを表す整数によって識別され、行内のフィールドは、そのフィールドの列の参照番号およびその行idの整数によって識別され、したがって、テーブル103の行id1を有する行内の行id列105に属するフィールドは、フィールド105(1)として識別される。フィールドに含まれるものはもちろん、フィールドが属する列について指定されるタイプの値である。

まず、テーブル103から説明すると、テーブル103は、レジュメのテーブルであり、各レジュメは探索可能な電子ドキュメントである。本議論では、レジュメテーブル103は2つの列、すなわち、各行の行idを含む行id列105と、レジュメを含むレジュメ列107とを有する。オラクル9iデータベース管理システムに定義されているように、行idは、特定のオラクル9iデータベース管理システムにおける行を一意に識別する。ここでは、行idは大きな整数とみなすことができる。オラクル9iデータベース管理システムではテーブル内の各行に行idがあり、したがって、あらゆるオラクル9iテーブルは、行idが実際にテーブルの定義に現れるかどうかにかかわらず、行idの仮想列を有するとみなすことができる。行id列105の仮想性は、テーブル103内で行id列を定義するのに使用されている点線で示されている。

レジュメフィールド107(h)の詳細がレジュメテーブル103の下に示されている。レジュメフィールドは、データベース管理システムがこのフィールドの内容を単にバイトの集合とみなすことを意味する、組込みタイプ「バイナリ大オブジェクト(BINARY LARGE OBJECT)」またはBLOBを有する。タイプBLOBの各フィールドに対してデータベース管理システムが実行できる演算は、フィールドに現在含まれているバイトを読み取るか、またはバイトの新しい集合をフィールドに書き込む演算だけである。BLOBの内容を適切に解釈するかどうかはデータベース管理システムのユーザ次第である。たとえば、BLOBの内容が.pdfファイルである場合、ユーザは、フィールドからBLOBの内容を読み取り、次いでアドビシステムズ社によって製造されているAcrobat(登録商標）ソフトウェアを使用して.pdfファイルを解釈または探索することができる。レジュメフィールド107(h)には、レジュメのインデックスの基礎を形成するいくつかの項目109が含まれている。これらの項目には、レジュメが属する人が慣れているコンピュータ言語の名前、ユーザが有する学位、またはその人が出席している教育機関を含めてよい。これらの項目は、アクロバットソフトウェアの一部である探索ユーティリティによってレジュメ内で見つけることができる。

各レジュメは、レジュメテーブル103の別個の行に含まれ、テーブル103の行を介してアクセス可能であるため、各レジュメは、それが属する行をレジュメテーブル103内に指定することによってインデックス付けすることができる。各行はもちろん、その行id 105によって指定することができる。組込みビットマップインデックスと同様に、ビットマップ値によって1セットの行idを指定することができる。ここで、各行idビットマップ値111は、レジュメテーブル103の指定可能な各行idのビットを有し、行idビットマップ値111内の行idを表すビットの順序は、行idの順序に対応する。レジュメテーブル103の指定可能な行idは、テーブル内の最低行idとテーブル内の最高行idとの間の行idである。行idは、レジュメテーブル103内の値では順序付けされず、テーブル103内に対応する行idがないビットがビットマップ値111内にあってよい。

レジュメインデックステーブル115は、行idビットマップ値111を使用して、様々なレジュメ内の項目109のインデックスをどのように作成したらよいかを示す。レジュメテーブル115は2つの列、すなわち、探索項目列119および項目インデックス列121と一緒に示されている。探索項目列119の各フィールドは、レジュメのインデックスが望ましい1つの項目を含む。たとえば、レジュメをコンピュータ言語および教育機関によってインデックス付けする場合、項目は、教育機関については「マサチューセッツ工科大学（Massachusetts Institute of Technology)」、「ノースカリフォルニア大学(University of North Carolina」、「ウォーセスター工業大学(Worceter Polytechnic Instiute)」などで、プログラミング言語については「C++」、「PL/SQL」、「Java」などであってよい。

項目インデックス列121は行idビットマップ値111を含む。したがって、各値は、レジュメテーブル103の各行のビットを有する。行117(i)内の項目インデックス値121(i)内のビットの設定は、その行の探索項目119(i)に指定された値を有する項目109をどのレジュメが含んでいるかを示す。たとえば、行117(x)では、探索項目は「マサチューセッツ工科大学（Massachusetts Institute of Technology)」である。3ビットの項目インデックス値121(x)がセットされ、これらのビットは、行id 105(e)、105(h)、および105(l)に対応し、これらの行内のレジュメ107(e)、(h)、および(l)が探索項目「マサチューセッツ工科大学（Massachusetts Institute of Technology)」を含むことを示している。同様に、探索項目119(y)は「PL/SQL」であり、項目インデックス値121(y)は、レジュメ107(e)および(j)がこの探索項目を含むことを示している。ユーザが、MIT学位を有しPL/SQLの知識を有する人を探している場合、データベース管理システムを使用して以下のことを実行することによってこの人を見つけることができる。
1. 「マサチューセッツ工科大学（Massachusetts Institute of Technology)」または「PL/SQL」を探索項目値119として有するレジュメインデックステーブル115内の行からビットマップ値121を得て、
2. 返されるビットマップ値の論理積をとり、セットされているビットが両方の探索項目を含むレジュメに関するビットだけである結果ビットマップ値を得て、
3. ビットが結果ビットマップにセットされている行idを判定し、
4. 行idによって指定された行内のレジュメ107を取り込む。
探索項目のビットマップ値から求めることのできるのが、ビットマップ値内のセットされているビットに対応する行idを有する行が探索項目を有するかどうかだけであることに留意されたい。ビットがセットされていないことは、そのビットの行idに対応する行がテーブル内にないか、または行内のレジュメが探索項目を有さないことを意味することができる。

前述のことから分かるように、101に示されているインデックス付け構成は、ユーザがビットマップ値を1セットのオブジェクトにマップし、そのセットのメンバーがそのメンバーに対応するビットをビットマップ値にセットさせる条件を定義し、ビットマップ値に対して必要なあらゆるビットマップ演算を実行するのを可能にする。ユーザは、ビットマップ値とそれが表す1セットのオブジェクトとのマッピングを行うことができ、かつオブジェクトがそのビットマップ値によって指定されるセットのメンバーになる条件を定義することができるため、もはやビットマップインデックスの基準となる値が低いカーディナリティ（cardinality）を有する必要はない。これによって、大きな数セットの互いに異なるパターンのオカレンスにインデックス付けするアプリケーションでビットマップインデックスを使用することができる。このようなパターンの例には、テキスト、生物測定パターン、ゲノム配列、またはOLAPキューブにおけるトークンがある。さらに、もはやビットマップインデックスの基準となる値が相互に排他的である必要はない。したがって、101に示されているインデックス付け構成は、値の重複した範囲を指定するセットにメンバーシップ条件を使用するのを可能にする。

ビットマップ値の表現の概要：図2
もちろん、1セットのオブジェクトをビットストリングにマップする任意の構成を使用してビットマップ値を定義することができる。しかし、好ましい態様では、構成は以下のようなものである。
・各オブジェクトは、非常に大きな1セットの順序付けされた一意の値にマップされる。このセットは、データベース管理システムに組み込まれる定義を有する。
・ビットマップ値のビットストリングは、一連の順序付けされた一意の値にマップされる。
したがって、ビットマップ値は、2つの部分、すなわち、順序付けされた一意の値の範囲を指定するマッピング指定子(a mapping specifier)、およびビットストリングの表現(a representation of the bitstring)を有する。ビットストリングの表現は、単なるビットストリングであっても、ビットストリングのロスレス圧縮に利用できる技術のどれかを使用して圧縮されたビットストリングであってもよい。

図2は、数セットのオブジェクトを表すビットマップ値を表す技術201を示している。オブジェクトは202に示されている。オブジェクトがビットマップ値で表されるように、オブジェクトは順序付けされた1セットの一意のオブジェクト識別子203(0..n)上にマップしなければならない。このような1つのマッピング204が示されており、オブジェクト202(b)は識別子203(i)上にマップされる。識別子203が順序付けされておりかつ一意であるため、1セットのオブジェクト202がマップされた識別子203を含むオブジェクト識別子203の範囲205を指定することによって、識別子203上にマップされた1セットのオブジェクト202を指定することができる。したがって、オブジェクト202のサブセットを指定するビットマップ値227は、2つの部分、すなわち、ビットマップがマップされる識別子203の範囲205を指定するマッピング指定子209、およびビットストリング表現225を有する。ビットストリング表現225は、範囲205内の各オブジェクト識別子に対応するビットを有し、各ビットはオブジェクト識別子と同様に順序付けされる。したがって、ビットストリング225内の各ビットと範囲205内の識別子203との間でマッピング206が行われる。マッピング204およびマッピング206のために、ビット226(j)はオブジェクト202(b)にマップされている。オブジェクト202(b)がビットマップ値227で表されるサブセット内にある場合、ビット226(j)がセットされる。ビット226(j)がセットされていない場合、それは、オブジェクト202(b)がサブセット内になく、かつビット226(j)にマップされているオブジェクト202がないことを意味することができる。ビットストリング表現225は、単純なビットストリングであってよく、または任意のロスレスビットストリング圧縮アルゴリズムを使用して圧縮し、圧縮ビットストリング231を作成することができる。

ビットマップ値の重要な属性は、ビットマップ値がマップされる順序付けされた1セットのオブジェクト識別子によって決定されるビットマップのタイプ(type)、およびビットマップ値がマップされるオブジェクト識別子の範囲によって決定されるビットマップのクラスである。したがって、マッピング指定子209によって指定される範囲205(i)にマップされるすべてのビットマップ値は、同じクラスを有する。好ましい態様では、2種類のビットマップ値、すなわち、ビットマップ値を含むデータベース管理システムにおける1セットの行id値にマップされる行idビットマップ値と、EPCを構成する1セットの値にマップされるePCビットマップ値がある。好ましい態様では、ビットマップ値または演算に必要なタイプは、ビットマップ値のフィールドの定義またはビットマップ値に対して実行される演算の定義に示される。好ましい態様におけるビットマップのクラスは、ビットマップ値のマッピング指定子209によって暗示される。他の態様では、ビットマップ値に必要なクラスをビットマップ値のフィールドの定義に示すことができる。たとえば、フィールドが属する列の定義では、ビットマップ値が、行idの範囲が行idの範囲である行idビットマップ値であることが必要になることがある。ビットマップ値のタイプおよびクラスを使用して、ビットマップに対する演算が妥当であるかどうかを判定し、かつ変換を実行することができる。たとえば、ビットマップ値が異なるタイプを有するオペランドを含む演算は妥当ではなく、いくつかの態様では、いくつかの演算のビットマップ値オペランドが同じクラスを有することが必要になることがある。オペランドが同じクラスを有する必要がない場合、演算を実行するために、オペランドを共通のクラスに変換することが必要になることがある。

さらに、図2には、ビットマップ値227の一般的な形式233と、235に示されているマッピング指定子209内の範囲を表す2つの方法が示されている。ビットマップ値227の一般的な形式は、1セットのマッピング指定子209とビットストリング表現225の対であり、順序付けされた1セットのオブジェクト識別子203の特性によって必要とされるため、または識別子へのオブジェクト202のマッピングが疎であり、したがって、マッピング指定子とビットストリング表現の複数の対を指定するのに必要な記憶空間が、マッピング指定子に指定された全範囲を含めるのに十分な大きさのマッピング指定子とビットストリング表現225の単一の対を指定するのに必要な記憶空間よりも少なくなるため、複数の対を使用することができる。

マッピング指定子209に範囲の限界を指定する1つの方法は、217に示されているように範囲の下限219および上限221を指定することである。他の方法は、223に示されているようにプレフィックス限界指定子を使用することである。いくつかの例を与えると、順序付けされた1セットのオブジェクトが100個のオブジェクト0..99を含む場合、範囲指定子20〜29によってオブジェクト20〜29を指定することができる。または、番号0..99を、各々がプレフィックス、すなわち10の桁と、サフィックス、すなわち1の桁を含むとみなすことができ、範囲20〜29をプレフィックス2で表すことができ、範囲0〜9をプレフィックス0で表すことができ、以下同様である。どちらを使用するかはもちろん、所望の範囲の種類によって決まる。たとえば、オラクル9iデータベース管理システムで使用される行idでは、行idのオブジェクト番号、ファイル番号、およびブロック番号を、オブジェクト番号によって指定されるテーブルに属するすべての行idを含む一連の行idのプレフィックスとして使用することができる。

ユーザアクセス可能なビットマップ演算の概要：図3〜6
本発明のユーザアクセス可能なビットマップ演算は4つの群に分類される。各演算は図3〜6に詳しく示されている。各演算の意味の詳細については、各図の記述を参照されたい。
1. ビットマップ値への変換およびビットマップ値からの変換を行う変換演算：図3
a. ビットマップ・ツー・セット(bitmap to set)：ビットマップ値を、ビットマップ値のビットストリング内のセットされているビットによって指定される1セットのオブジェクト識別子に変換する。
b. セット・ツー・ビットマップ(set to bitmap)：1セットのオブジェクト識別子を、そのセットを表すビットマップ値に変換する。
c. ビットマップ・ツー・カウント(bitmap to count)：ビットマップ値を、そのビットマップ内のセットされているビットの数のカウントに、したがって、そのビットマップで表されるオブジェクトのセット内のオブジェクトの数に変換する。
2. 存在演算：ビットマップ値で表される1セットのオブジェクト識別子が特定のオブジェクトのオブジェクト識別子を含むかどうかを判定する：図4
3. ビットマップ値に対する論理演算：図5
a. ビットマップAND(bitmap AND)：同じクラスを有する2つのビットマップ値の論理積を求める。
b. ビットマップOR(bitmap OR)：同じクラスを有する2つのビットマップ値の論理和を求める。
c. ビットマップXOR(bitmap XOR)：同じクラスを有する2つのビットマップ値の排他的論理和を求める。
d. ビットマップMINUS(bitmap MINUS)：あるクラスのあるビットマップ値によって指定されるセットに含まれる同じクラスの別のビットマップ値によって指定されるセット内のオブジェクト識別子を後者のビットマップ値から削除する。
4. ビットマップ値で表される1セットのオブジェクト識別子を変更する：図6
a. ビットマップ挿入(bitmap insert)：1セットのオブジェクト識別子およびビットマップ値をとり、そのビットマップ値のクラスについて指定されている範囲に含まれていないものがそのセットにある場合、範囲を拡張し、以前セットされていたビットとそのセット内のオブジェクト識別子に対応するビットとの両方がセットされる拡張された範囲について新しいビットマップ値を作成する。
b. ビットマップ削除(bitmap delete)：1セットのオブジェクト識別子およびビットマップ値をとり、そのビットマップ値のクラスについて指定されている範囲に含まれるものがそのセットにある場合、ビットマップ値内のオブジェクト識別子のビットを0に設定する。
5. ビットマップ比較：ビットマップEQUALS演算は、2つのビットマップ値を比較し、2つの値が同じ1セットのオブジェクト識別子を表しているかどうかを判定する。図4を参照されたい。
6. ビットマップ代入：ソース・ビットマップ値を、ソース値と同じタイプのビットマップ値を表すターゲット変数に代入する。図3を参照されたい。

変換演算：図3
図3は、変換演算301およびビットマップ代入の例を示している。以下の演算の例で使用されるビットマップ値のクラスが303に示されている。このクラスのビットマップ値は、オブジェクト識別子203の範囲20〜29を指定するマッピング指定子と、ビット0..9がオブジェクト識別子20..29上にマップされている10ビットのビットストリングとを有する。以下の議論では、ビットマップ値は、表記<下限-上限>:<ビットストリング>(<lower_bound-upper_bound>:<bitstring>)で表される。したがって、305に示されているように、識別子22および27に対応する1セットのオブジェクトを表すビットマップ値bitmapval_1は、ビット2および7がセットされ、表記20-29:0010000100で表される。

ビットマップ・ツー・セット演算307において、ビットマップ_ツー_セット (bitmap_to_set)演算子は単一のオペランド、すなわちビットマップ値、この場合はビットマップ値ビットマップ値bitmapval_1をとり、ビットストリングにセットされているビットによって指定される識別子、この場合は識別子(22)および識別子(27)を返す。

セット・ツー・ビットマップ演算309において、セット_ツー_ビットマップ(set_to_bitmap)演算子は、1セットのオブジェクト識別子、ここでは識別子(20)、識別子(23)、および識別子(24)で構成されたセットをとり、ビットマップ値bitmapval_2を返す。ビットマップ値bitmapval_2は、マッピング指定子が範囲20-24を指定し、これらのオブジェクト識別子に対応するビット(0)、(3)、および(4)がセットされている5ビットのビットストリングを有し、ビットマップ値20-24:10101を与える。このビットマップ値は、変数「ビットマップ値(bitmapval)_2」に代入されている。この変数は、それに代入されるソースビット値を有さなければならず、代入後にソースビットマップ値のクラスおよび値を有する。

ビットマップ・ツー・カウント演算311において、ビットマップ_ツー_カウント(bitmap_to_count)演算子は、任意のクラスのビットマップ値をとり、ビットマップにセットされているビットの数、すなわち、ビットマップで表されるセット内のオブジェクト識別子の数を返す。2つの例を示すと、ビットマップ_ツー_カウント(ビットマップ値_1)(bitmap_to_count(bitmapval_1))は、ビットマップ値に多数のビットがセットされているため2を返し、ビットマップ_ツー_カウント(ビットマップ値_2)(bitmap_to_count(bitmapval_2))は、そのビットマップ値に多数のビットがセットされているため3を返す。

存在演算およびequals演算：図4
存在演算は、ビットマップ識別子、およびビットマップ値のタイプに対応する種類のオブジェクト識別子をとり、オブジェクト識別子に対応するビットがビットマップ値にセットされている場合は1を返し、セットされていない場合は0を返す。したがって、0は、オブジェクト識別子がビットマップ値の範囲内に存在するがそのビットはセットされていないか、またはオブジェクト識別子がビットマップ値の範囲内に存在しないことを示す。図4では、ビットマップ値はビットマップ値_1(bitmapval_1)であり、オブジェクト識別子22および27を表すビットがセットされている。405に示されているように、オブジェクト_存在(object_exists)演算子は、そのオブジェクト識別子引数として識別子(26)を有する際、0を返す。これは、オブジェクト識別子(26)のビットがビットマップ値_1(bitmapval_1)にセットされていないからである。演算子は、そのオブジェクト引数として識別子(22)を有する際、1を返す。これは、識別子(22)のビットがビットマップ値_1(bitmapval_1)にセットされているからである。

equals演算は、同じタイプに属する2つのビットマップ値をとり、2つのビットマップ値が同じ1セットのオブジェクト識別子を表している場合には1を返し、表していない場合には0を返す。407に示されているように、この演算は、ビットがオブジェクト_id(22)(object_id(22))およびオブジェクト_id(27)(object_id(27))についてセットされたビットマップを返すセット_ツー_ビットマップ演算の結果とビットマップ値_1を比較したときには1を返し、ビットマップ値_1をビットマップ値_2と比較したときには0を返す。この演算では、比較を行う前に両方のビットマップ値が同じクラスに変換される。

ビットマップ値に対する論理演算：図5
これらの演算はビットストリングに対して実行される論理演算に類似している。これらの演算はすべて、同じクラスに属する2つのビットマップオペランドを有する。好ましい態様では、両方のビットマップ値が同じタイプを有する場合、一方または両方のオペランドが、範囲に両方のオペランドが含まれるクラスに変換される。ビットマップ値が互いに異なるタイプを有する場合、エラーが生じる。これらの演算およびその結果は、図5の501に示されている。オペランドはビットマップ値ビットマップ値_1およびビットマップ値_2であり、それらの値は503に示されている。これらの演算のそれぞれの開始時に、ビットマップ値_2がビットマップ値_1のクラスに変換される。ビットマップAND演算は、505に示されているように標準論理AND演算であり、ビットマップOR演算は、507に示されているように、標準論理OR演算であり、ビットマップXOR演算は、509に示されているように、標準論理XOR演算である。ビットマップXOR演算は、2つのオペランドが同一であり、したがって、ビットマップequals演算を実施するのに使用できるときには、すべて0を含むビットストリングを返す。ビットマップマイナス演算は、同じビットが第1のオペランドと第2のオペランドの両方にセットされており、結果における対応するビットがリセットされる場合を除いて、ビットが第1のオペランドと同様にセットされている結果ビットストリングを作成する。これは、論理演算bitmapval_1 AND (NOT bitmapval_2)と等価である。この演算は511に示されている。

ビットマップ値で表される1セットのオブジェクト識別子を変更する：図6
ビットマップ値で表される1セットのオブジェクト識別子を変更する際、ビットマップ値も変更しなければならない。この変更では、すでにビットマップ値のビットストリングに含まれているビットのセットおよび／またはリセットを行うだけでよいが、マッピング指定子およびビットストリングの長さを変更してもよい。ビットマップ値で表される1セットのオブジェクト識別子を変更する演算は、そのセットにオブジェクト識別子を付加するビットマップ挿入演算、およびそのセットからオブジェクト識別子を削除するビットマップ削除演算である。どちらの演算でも、オペランドは、変更すべきビットマップ値、およびビットマップ値に追加するかまたはビットマップ値から削除すべき1セットのオブジェクト識別子である。

ビットマップ挿入演算および削除演算は図6の601に示されている。ビットマップ値オペランドは、603に示されているビットマップ値_1である。ビットマップ挿入演算は605に示されている。第2のオペランドは、1セットのオブジェクト識別子{object_id(28), object_id(29)}である。これらのオブジェクトはどちらもまだ、ビットマップ値_1で表されるセットに含まれておらず、第2のオブジェクトはさらにビットマップ値_1の現在の範囲外である。したがって、ビットマップ挿入演算は、両方の新しいオブジェクトを含めることができるようにビットマップ値_1の範囲を拡張する。したがって、ビットマップ値_1の新しい値は20-33:00100001100001であり、このビットストリング表現は14ビットを表し、オブジェクト識別子22、27、28、および33を表すビットがセットされている。

ビットマップ削除演算は607に示されている。ここで、第2のオペランドは、1セットのオブジェクト識別子{object_id(27), object_id(28)}である。これらのオブジェクトはどちらも、ビットマップ値_1の範囲内であるが、ビットマップ値_1で表される1セットのオブジェクト識別子に含まれているのはオブジェクト識別子27だけであり、したがって、この演算の結果は、オブジェクト_id(27)に対応するビット7がリセットされている新しい値のビットマップ値_1である。上述のように、いくつかのビットマップ値を1セットのマッピング指定子とビットマップの対として表すことができ、これが可能であり、かつビットマップ削除演算が部分範囲内のすべてのオブジェクトを削除するときは、この部分範囲に関するマッピング指定子およびビットマップ対を1セットのマッピング指定子とビットマップの対から削除することができる。

ビットマップデータタイプを有するデータベース管理システム：図7
図7は、2つのビットマップデータタイプ、すなわち、ビットマップ値がマップされる1セットのオブジェクト識別子がデータベース管理システムにおける1セットの行idである行id(rowid)ビットマップデータタイプと、1セットのオブジェクト識別子が1セットのEPCであるePCビットマップデータタイプを実施するデータベース管理システムに属するデータベースオブジェクト701の概念的概要である。データベースオブジェクト701は、2つのクラス、すなわち、メタデータ(metadata)オブジェクト自体を含む、データベース管理システム内のすべてのオブジェクトを定義するメタデータオブジェクトと、オブジェクトを構成するデータが記憶されるデータ記憶オブジェクト732に分類される。データ記憶オブジェクト732は、ファイルシステムなどの永続的記憶域に含まれる。

メタデータオブジェクト703に続いて、テーブル定義705は、エントリがデータベース管理システム内のテーブルの定義であるテーブルである。このテーブルには、各テーブル用のエントリがある。列定義709は、エントリが、テーブルで使用される列の定義であるテーブルである。タイプ定義713は、エントリが列について指定されるデータタイプの定義であるテーブルである。本発明のデータベース管理システムでは、タイプ定義713は、システム定義タイプ715およびユーザ定義タイプ717を含む。システム定義タイプには行idビットマップタイプ718およびePCビットマップタイプ716が含まれる。各タイプには、ユーザ定義であるかシステム定義であるかにかかわらず、1セットの演算が関連付けされている。これらの演算は、演算定義テーブル721に定義されている。テーブル721には、ユーザ定義演算725の定義およびシステム定義演算723の定義が含まれている。システム定義演算には、行idビットマップ値に関する演算726およびePCビットマップ値に関する演算724が含まれる。ユーザ定義演算は、データベース管理システムに含まれるコードを使用することも、データベース管理システムの外部のコードを使用することもできる。最後に、行idテーブル729は、現在データベース管理システムに存在するすべての行の行idのテーブルである。行idは、順序正しく配置されており、各データセグメント733(i)が一連の行id 731(i)を定義している。各行idは、その行idで示される行のデータを実際に含むデータセグメント733内のスロット735を指し示す。大きなテーブルは、複数のデータセグメント733にデータを有することができる。

テーブル定義705に定義されているテーブルは、テーブル行id関係テーブル727によってテーブルの行の行idに関係付けられ、テーブル列関係テーブル707によってテーブルの列の列定義709に関係付けられている。列定義は、列−タイプ関係テーブル711によってタイプ定義に関係付けられ、タイプ定義は、タイプ−演算定義テーブル719によって演算定義に関係付けられている。これらの関係テーブルは、どの列および行が、テーブル定義705に定義されているテーブルに属するか、各列がどんなタイプを有するか、および各タイプがどんな演算を有するかを判定するのを可能にする。

行idビットマップデータタイプ
行idビットマップデータタイプでは、データベース管理システムの行idは、順序付けされた1セットのオブジェクト識別子203を構成する。行idにマップすることのできるオブジェクト202は、行idで表されるデータベース行に含まれるあらゆるオブジェクトである。行idビットマップ値において、マッピング指定子209は、ビットストリング225を一連の行id上にマップする。ビットストリングの各ビットは、この範囲内の1つの行idを表す。ビットストリング225にビットがセットされているとき、セットされているビットは、行idがビットストリングにセットされているビットに対応する行内の1つまたは複数のフィールド内に特定の値が存在することを表す。以下の議論ではまず、好ましい態様における行idについて詳しく説明すると共に好ましい態様で使用される数セットの行idの表現について説明し、次に、行idビットマップ値に対する演算について概略的に説明し、最後に行idビットマップ値を使用したレジュメテーブル103およびレジュメインデックステーブル115の実現態様を開示する。

行idビットマップデータタイプの詳細：図10
行idの形式
オラクル9iデータベース管理システムでは、行idは、その行idによって指定される行の物理アドレスの基本64符号化を使用する。符号化文字は、A-Z、a-z、0-9、+、および/である。拡張行idは4ピースフォーマットOOOOOOFFFBBBBBBRRRを有する。
・OOOOOO：データベースセグメントを識別するデータオブジェクト番号。テーブルのクラスタのような同じセグメント内のスキーマオブジェクトは、同じデータオブジェクト番号を有する。
・FFF：その行を含むデータファイルのテーブル空間相対データファイル番号。
・BBBBBB：その行を含むデータブロック。ブロック番号は、テーブル空間ではなくブロック番号のデータファイルに対する番号である。したがって、同一のブロック番号を有する2つの行は、同じテーブル空間の2つの異なるデータファイルに存在することができる。
・RRR：ブロック内のその行の記憶域のオフセット。
図10は、行id 1003をデータオブジェクト番号1005、データファイル番号1007、データブロック番号1009、および行オフセット1011と一緒に示している。

行idビットマップ値
行idビットマップ値1019の一般的な形式は、図10の1019に示されている。行idビットマップ値は、1つまたは複数のマッピング指定子1021およびビットストリング表現1027のシーケンスで構成されている。行idビットマップ値において、マッピング指定子は、行id範囲開始値1023および行id範囲終了値1025を指定することによって行idの範囲を指定する。各マッピング指定子に対応する範囲ビットストリング表現があり、ビットストリングは、マッピング指定子によって指定される範囲内の各行id用のビットを有する。

複数のマッピング指定子1021および範囲ビットストリング1027が使用される1つの状況は、ビットストリングがマップされる行idの範囲に、複数のデータセグメント733内の位置を指定する行idが含まれるときである。マッピング指定子が、複数のデータセグメント703に含まれる行idにビットマップをマップする際、ビットマップ値は、ビットマップ値を行id上にマップするのに必要なすべての部分範囲について形式<セグメントa内の行idの範囲(i)のマッピング指定子>:<範囲(i)のビットマップ表現>(<mapping specifier for the range(i) of rowids in segment a>:<bitmap representation for range (i)>)、<セグメントb内の行idの範囲(j)のマッピング指定子>:<範囲(j)(<mapping specifier for the range(i) of rowids in segment b>:<bitmap representation for range (i)>のビットマップ表現>をとる。この技術はもちろん、値が連続的なシーケンスを形成しないオブジェクトをビットマップ値が表すことができるあらゆる場合に使用することができる。この技術は、関心対象のオブジェクトがオブジェクトの範囲にわたって疎に分散しているときに使用することもできる。このような状況では、各マッピング指定子がそれ自体のビットストリング表現を有する関心対象の部分範囲に関するマッピング指定子の集合が単一のマッピング指定子に必要とする記憶空間が少なくなり、かつオブジェクトが分散する範囲全体にわたって非常に大きなビットストリングを指定することが必要になることがある。

テーブル内の行idビットマップ値の列の指定
レジュメインデックステーブル115を指定するDDLは以下のようなものである。
CREATE TABLE ResumeIndexTable
(SearchTerm CHAR(30),
TermIndex ROWIDBITMAP)
好ましい態様では、列「項目インデックス(TermIndex)」の各フィールドは、行idビットマップ値を含まなければならないが、任意のクラスの行idビットマップ値を含んでよい。他の態様では、DDLは、ビットマップ値にマップされる行idが属するテーブルを指定することができ、その場合、列内のビットマップ値は、テーブルの行idにマップされるビットマップ値のクラスに属するようにデータベース管理システムによって制約することができる。

行idビットマップ値に対する演算
以下の演算は、演算定義721内の行idビットマップ値について定義される。
1) 変換演算
a) BITMAP2ROWIDS：この関数は、行idビットマップ値を対応する1セットの行idに変換する。
b) BITMAP2COUNT：この関数は、行idビットマップ値を、その行idビットマップ値においてビットがセットされている行の対応するカウントに変換する。
c) ROWIDS2BMAP：この関数は1セットの行識別子を行idビットマップ値に変換する。
2) 存在演算：ROWIDEXISTS：この関数は、行idが行idビットマップ値で表される1セットの行idに属するかどうかを判定する。
3) 論理演算：
a) BITMAP_AND：この関数は、2つの行idビットマップ値をとり、2つのオペランドの論理積である行idビットマップ値を返す。
b) BITMAP_OR：この関数は、2つの行idビットマップ値をとり、2つのオペランドの論理和である行idビットマップ値を返す。
c) BITMAP_XOR：この関数は、2つの行idビットマップ値をとり、2つのオペランドの排他的論理和である行idビットマップ値を返す。
d) BITMAP_MINUS：この関数は、第1の行idビットマップ引数から第2の行idビットマップ引数を引いた結果を返す。
4) 行idビットマップ値によって表される1セットの行idを変更する：
a) BITMAP_INSERT：この関数は、行idビットマップ値および1セットの行idを引数としてとり、そのセット内の行idに対応する行idビットマップ値内のビットをセットする。
b) BITMAP_DELETE：この演算は、行idビットマップ値および1セットの行idを引数としてとり、そのセット内の行idに対応する行idビットマップ値内のビットをリセットする。
5) BITMAP_EQUALS：この演算は、2つの行idビットマップ値を引数としてとり、ビットマップ値が同じ1セットの行idを表す場合にTRUEを表す値を返し、そうでない場合には、FALSEを表す値を返す。これらの値は、演算を行う前に同じクラスに変換することができる。
6) 代入：この演算は、ソース行idビットマップ値をテーブル内のフィールドなどの行idビットマップターゲット変数に代入する。演算の終了時に、ターゲット変数はソース値のクラスおよび値を有する。
行idビットマップ値に対する演算は、ビットマップ演算の全般的な議論で説明したように働く。好ましい態様では、ROWIDS2BMAP演算、BITMAP_INSERT演算、およびBITMAP_DELETE演算における結果ビットマップのクラスは、結果ビットマップに含まれる行idから判定される。これらの論理演算において、オペランドは、オペランドビットマップ値に指定されたすべての行idを含むクラスのビットマップに変換される。ビットマップ値の代入において、ターゲットビットマップは、ソースビットマップ値のクラスおよび値を取得する。他の態様では、ソースビットマップ値とターゲットビットマップ値が代入演算において同じクラスを有するか、またはこれらの論理演算におけるオペランドが同じクラスを有することが必要になることがある。

行idビットマップ値を有するレジュメテーブル103およびレジュメインデックステーブル115の実施
レジュメテーブル103
レジュメテーブル(ResumeTable)103は、値がユーザ定義クラス「レジュメ(Resume)」のオブジェクトである列「レジュメ(Resume)」107を有する。このクラスに重要なユーザ定義演算は、文字ストリングおよびレジュメオブジェクトをオペランドとしてとるcontains演算である。この演算は、アクロバット探索演算を使用して、レジュメが特定の文字ストリングを含むかどうかを判定する。このオペランドが存在すると、特定の文字ストリングを含むレジュメがあるかどうかをレジュメテーブル103に問い合わせることが可能になる。

レジュメインデックステーブル115
レジュメインデックステーブル(ResumeIndexTable)115は、値がレジュメテーブル(ResumeTable)103内の行の1セットの行idを表す行idビットマップ値である列「項目インデックス(TermIndex)」121と、値がテーブル103のレジュメにおける関心対象の項目である列「探索項目(SearchIndex)」119とを有する。レジュメインデックステーブル(ResumeIndexTable)115の特定の行内の項目インデックスの値によって表されるレジュメテーブル(ResumeTable)103の1セットの行idは、レジュメ(Resume)フィールド内のレジュメが、レジュメインデックステーブル(ResumeIndexTable)115の特定の行内の探索項目119の値を含む行の、レジュメテーブル(ResumeTable)103における行idで構成されている。

レジュメインデックステーブル115内のビットマップ値をセットする
レジュメインデックステーブル115内の探索項目列119の値を使用したレジュメテーブル103に関するクエリーを使用して、項目インデックス列121内のビットマップ値をセットすることができる。クエリーの一形式は以下のようなものである。
UPDATE ResumeIndexTable
SET TermIndex := ROWIDS2BITMAP( TO_SET(
SELECT roid FROM ResumeTable
WHERE contains (Resume, "Massachusetts Institute of Technology")))
WHERE SearchTerm = "Massachusetts Institute of Technology"
このクエリーは、レジュメインデックステーブル(ResumeIndxTable)の各行内の項目インデックス(TermIndex)を、探索項目(SearchTerm)によって指定された探索項目を有するレジュメがレジュメ(Resume)フィールドに含まれるレジュメテーブル(ResumeTable)内の列の行idに対応するビットマップ値に設定する。これらの行idは、ユーザ定義contains関数を使用するSELECTクエリーによって見つけられ、クエリーの結果はTO SET演算によって1セットの行idに変換され、この1セットの行idはROWIDS2BITMAPによってビットマップ値に変換される。

ビットマップ値を使用してレジュメテーブル103内のレジュメを見つける
項目「マサチューセッツ工科大学"Massachusetts Institute of Technology"」と項目「PL/SQL」の両方が現れるレジュメテーブル(ResumeTable)113のレジュメを作成するクエリーは以下のようなものである。
SELECT resume FROM ResumeTable
WHERE rowid IN BITMAP2ROWIDS(BITMAP_AND(
(SELECT TermIndex FROM ResumeIndexTable WHERE
SearchTerm = "Massachusetts Institute of Technology"),
(SELECT TermIndex FROM ResumeIndexTable WHERE
SearchTerm = "PL/SQL")))
このクエリーでは、レジュメは、レジュメインデックステーブル(ResumeIndexTable)内のビットマップ値が、探索項目「マサチューセッツ工科大学"Massachusetts Institute of Technology"」および「PL/SQL」をどちらも含むレジュメを有することを示す行idに基づいてレジュメテーブル(ResumeTable)から選択される。クエリーの1番下から、2つの探索項目を使用して項目インデックス(TermIndex)ビットマップ値が選択されていき、この場合、これらのビットマップ値はBITMAP_AND演算のオペランドであり、BITMAP_AND演算の結果として得られるビットマップ値は、レジュメ(Resume)フィールドが両方の探索項目を含むレジュメテーブル(ResumeTable)内のあらゆる行の行idについてセットされているビットを含む。次に、結果ビットマップ値は、BITMAP2ROWIDS演算のオペランドとして使用され、結果ビットマップ値に指定された1セットの行idが生成され、これらの行idを使用して、所望のレジュメを含むレジュメ(resume)フィールドが選択される。

項目インデックス列121内のビットマップ値を維持する
レジュメテーブル(ResumeTable)103内の行が更新されるか、またはテーブル103に行が追加されるかもしくはテーブル103から行が削除されたときはいつでも、項目インデックス(TermIndex)行121内のビットマップ値を、レジュメテーブル(ResumeTable)103内のレジュメの現在の状態を反映するように再計算しなければならない。好ましい態様のリレーショナルデータベース管理システムでは、このような再計算は、レジュメテーブル(ResumeTable)103について書かれた1つまたは複数のトリガプログラムによって行われ、レジュメテーブル(ResumeTable)103内の行が修正されるか、このテーブルから行が削除されるか、またはこのテーブルに行が追加されたときに実行される。

この再計算を行う1つの方法は、項目インデックス(TermIndex)列121内のすべてのビットマップ値を計算するのに使用される、上記に開示されたクエリーを、トリガに実行させることである。しかし、この手法では、テーブル内のあらゆるレジュメを探索する必要があり、レジュメテーブル(ResumeTable)103のサイズが大きくなるにつれて、この手法のオーバヘッドも増大していく。このオーバヘッドは、追加された行内のレジュメを探索するだけでよいBITMAP_INSERT演算と、削除される行に相当する行idビットマップ内のビットをリセットするに過ぎないBITMAP_DELETE演算を使用して低減させることができる。レジュメテーブル(ResumeTable)103の行が更新されると、行の削除と、それに続く新しい行の挿入とみなされる。レジュメインデックステーブル(ResumeIndexTable)115に行が追加されるときに項目インデックス列121内の値を更新するレジュメインデックステーブル(ResumeIndexTable)115に対するトリガのコードは以下のようなものである。
AFTER INSERT OF Resume ON ResumeTable FOR EACH ROW
DECLARE BitmapIn ROWIDBITMAP;
BitmapOut ROWIDBITMAP
BEGIN
FOR Each Search_Term IN new: Resume
SELECT TermIndex INTO BitmapIn FROM ResumeIndexTable
WHERE contains(new :Resume, Search_Term)；
IF BitmapIn is NOT NULL
ROWID_BITMAP_INSERT (BitmapIn, TO_SET(new :Rowid), BitmapOut);
UPDATE ResumeIndexTable SET TermIndex =
BitmapOut WHERE
ResumeIndexTable.SearchTerm = Search_Term;
ELSE
INSERT INTO ResumeIndexTable VALUES (Search_Term,
ROWIDS2BMAP (TO_SET(new:rowid)));
END IF;
END LOOP;
END;
トリガ内のコードは、レジュメテーブル(ResumeTable)103に行が追加されるときにレジュメインデックステーブル(ResumeIndexTable)115の各行に対して実行される。2つのビットマップ変数は、トリガ内のビットマップ値に使用される。SELECT文は、行内のフィールド「探索項目(SearchTerm)」の値がレジュメテーブル(ResumeTable)115内のフィールド「レジュメ(Resume)」に存在するかどうかを判定する。存在する場合、レジュメインデックステーブル(ResumeIndexTable)115の行に関するフィールド「項目インデックス(TermIndex)」内のビットマップがビットマップ変数「ビットマップイン(BitmapIn)」にコピーされる。

次に、ROWID_BITMAP_INSERTを使用して、レジュメテーブル(ResumeTable)の関連する新しい行の必要に応じてビットマップイン(BitmapIn)のビットマップ値が修正される。修正されたビットマップ値はビットマップアウト(BitmapOut)に入る。行idに対応するビットがすでにビットマップイン(BitmapIn)の行id値に存在する場合、このビットは、ビットマップアウト(BitmapOut)にセットされ、ビットマップイン(BitmapIn)の行idに対応するビットがない場合、ビットマップアウト(BitmapOut)のマッピング指定子がこの行idを含むように修正され、このマッピング指定子に対応するビットマップが作成され、ビットマップイン(BitmapIn)にセットされていたビットと、新しい行idのビットが、ビットマップアウト(BitmapOut)にセットされる。次に、UPDATE文を使用して、レジュメインデックステーブル(ResumeIndexTable)115の関連する行内の項目インデックス(TermIndex)ビットマップ値が、ビットマップアウトに含まれるビットマップ値に設定される。

行idビットマップ値の他のアプリケーション
リレーショナルデータベース管理システムにおける各行は行idを有し、任意のクエリーが、そのクエリーを満たす行の行idを返すことができ、したがって、行idビットマップ値を使用して、クエリーを定義することのできるデータベース管理システムにおける任意の1セットのオブジェクトのサブセットを表すことができる。行は、多数のオブジェクトを含むため、所与の行idビットマップ値によって表される特定の1セットのオブジェクトは、行idを得るのに使用されたクエリーによって決まる。

行idビットマップ値を使用して、クエリーを定義することのできる任意の1セットのオブジェクトのサブセットを表すことができるため、以下の条件を満たす任意の1セットのオブジェクトに、図1に関して示された技術を使用して、ビットマップインデックスを作成することができる。
・そのセットに属するオブジェクトをデータベーステーブルの1つまたは複数の列として表すことができ、かつ
・そのセット内のオブジェクトが1つまたは複数の問合せ可能な属性を有する。
インデックスには、インデックス付けされるオブジェクトを値が表す列を有する1つまたは複数の一次テーブルと、値が、インデックス付けされるオブジェクトの問合せ可能な属性である列、および値が行idビットマップ値である列を少なくとも含むインデックステーブルが必要である。インデックステーブルの各行において、行のビットマップ値は、一次テーブルにおいてインデックス付けされるオブジェクトのうちのどれが、インデックステーブルの行に指定された問合せ可能な属性の値を有するかを示す。行idのビットマップを使用してインデックス付けすることのできるものに対するほぼ唯一の制限は、インデックス付けされる各オブジェクトが、データベース管理システムにおけるテーブル内にオブジェクト自体の行を必要とすることである。インデックス付けされるオブジェクトの数が非常に多い場合、行の必要な数は、データベース管理システムの能力を超えることがある。

任意の問合せ可能な属性によって、ビットマップにビットがセットされているかどうかを判定することができるため、属性の任意の特性に応じてビットマップを設定することができる。たとえば、属性値に対してgreater than演算およびless than演算を実行できる場合、クエリーを属性値のいくつかの範囲に基づいて行うことができ、かつ属性値の各範囲が異なるビットマップ値に対応することができるため、属性値の範囲同士が重複してよい。簡単な例を挙げると、インデックス付けされるオブジェクトが温度属性を有する場合、華氏範囲32-98.6および32-212のビットマップ値が存在してよい。

最も基本的なレベルでは、行idビットマップ値は、データベース管理システムにおける数セットの行の永続的な表現である。さらに、あらゆるクエリーが1セットの行idを返すため、返される1セットの行idを指定する行idビットマップ値で任意のクエリーを永続的に表すことができる。たとえば、
BitmapValue:= ROWIDS2BITMAP ( TO_SET(
SELECT rowid FROM ResumeTable
WHERE (contains (
ResumeTable.Resume,
ResumeIndexTable.SearchTerm
))));
は、ビットマップ変数「ビットマップ値(BitmapValue)」をSELECT文によって返される行idのビットマップに設定する。レジュメテーブル(ResumeTable)内の行idが変更されないかぎり、ビットマップ値(BitmapValue)を使用して、ビットマップ値(BitmapValue)が設定されたクエリーによって指定される行を検索することができる。

ePCビットマップデータタイプ
各オブジェクトが行を有するテーブルを作成することによって表すには大きすぎる1セットのオブジェクトの一例は、ePCによって識別される1セットのオブジェクトである。このため、図7のデータベース管理システムの好ましい態様は、組込みEPCビットマップデータタイプ716およびシステム定義ePCビットマップ演算724を含む。以下の議論ではまず、ePCについて詳しく説明し、次に、ePCにマップされ、したがってePCビットマップデータタイプ、ePCビットマップデータタイプの演算を有するビットマップ値について説明し、最後にePCビットマップ値の使用例について説明する。

ePC：図8
EPCまたはePCは、個々の製品品目を一意に識別する標準製品コードである。ePCの標準は依然として開発中である。参照として本明細書に組み込まれるEPC^TM Tag Data Standards Version 1.1 Rev.1.23, Last Call Working Draft on 16 February 2004, copyright 2003, EPC Globalに記載されたように、ePCは64ビットまたは96ビットを有することができる。96ビットePCの一般的な形式は図8の801に示されている。96ビット値は、4つのフィールド、すなわち、後続のフィールドのサイズおよびそれらのフィールドをどのうように解釈すべきかを定義する8ビットヘッダフィールド803と、1セットのePCコードを管理する製造業者などのエンティティを識別する総責任者フィールド805と、オブジェクトのクラス、たとえばフィールド805で識別される製造業者によって製造される製品を識別するオブジェクトクラスフィールド807と、オブジェクトクラス識別子807によって指定された製品の個々の品目を識別する通し番号フィールド809とに分割される。ePC値は、2つの部分、すなわちフィールド803〜807で構成されたプレフィックス811と、通し番号フィールド809で構成されたサフィックス813に分割されることが多い。サフィックスの長さは、ヘッダ803内の情報によって判定することができる。フィールド805、807、および809で示される10進能力から分かるように、96ビットePCは、天文学的な数のオブジェクトを識別することができる。64ビットePCはこれよりも小さいが、96ビットePCと全体的な形式は同じである。好ましい態様では、ePCの各セットを表す2種類のビットマップ値がある。96ビットePCの各セットを表すビットマップ値は一方のタイプに属し、64ビットePCの各セットを表すビットマップ値は他方のタイプに属する。ePCビットマップ値についての以下の議論は、両方のタイプのePCビットマップ値に当てはまる。

ePCビットマップ値
在庫を管理するデータベース管理システムに対するePCの問題は、各製品品目が現在、96ビット（または64ビット）の一意の識別子を有することである。オブジェクトを表す通常のデータベース管理システムを使用する場合、製品品目はテーブル内のフィールドによって識別され、各製品品目はテーブル内に行を有し、各行は製品品目のePC用のフィールドを必要とする。さらに、どの製品品目の在庫があるかを示すメッセージも、各製品品目ごとにePCを必要とする。データベース管理システム内または製品品目の在庫があることを示すメッセージ内に必要とされる空間の量は、マッピング指定子が値のビットマップを1セットのePC上にマップするビットマップ値で1セットの製品品目を表す場合、大幅に削減することができる。特定のePCが属する製品品目が一群の製品品目に存在する場合、そのePCに対応するビットがビットマップ値にセットされる。したがって、ビットマップ値はビットマップ値内のビットと同数のePCのリストに置き換わることができる。

ePCビットマップ値を実現する方法が815および816に示されている。ePCビットマップ値の最も簡単な形式815は、ePCプレフィックス811自体をマッピング指定子817として使用し、ビットストリング819は、このプレフィックスを有することのできるすべてのサフィックスを表す。サフィックスを有する品目がビットマップ値に表される1セットのePCに存在するとき、ビットマップ値内のその品目のビットがセットされる。多くの場合、関心対象の1セットのePC内の通し番号はすべて、同じ最上位ビットを有する。この場合、マッピング指定子817は、同じ最上位ビットを含むようにePCプレフィックス811を超えて拡張することができる。この場合、ビットストリングは、同じプレフィックス811および同じ最上位ビットを有する1セットのすべての通し番号を表す。

ePCビットマップ値の形式816は、ePCプレフィックス811を、サフィックスのいくつかの範囲をマッピング指定子として指定する1セットの範囲開始値819および範囲終了値821と一緒に使用する。それぞれの一対の開始値および終了値（819(i),821(i)）は、開始値および終了値（819(i),821(i)）によって指定されるサフィックスの範囲上にマップされたビットマップを含む範囲ビットマップ823(i)に相当する。サフィックスがサフィックス値の全範囲にわたって疎に分散されている場合、形式816のビットマップ値は、ビットマップ値のサイズを大幅に小さくすることができる。もちろん、ePCビットマップ値の両方の実現態様におけるビットストリングは、任意の利用可能なロスレス圧縮技術によって圧縮することができる。さらに、範囲開始値および範囲終了値は、817に示されているような拡張マッピング指定子プレフィックスと一緒に使用することができる。

ePCビットマップ演算
ePCビットマップ演算は、ePCの性質が与えられた場合に予想されるものである。
1. 変換演算
a. EPC_BITMAP2EPCS：この関数はePCビットマップを、ePCビットマップ値によって表される1セットのePCに変換する。
b. EPCS2EPC_BITMAP：この関数は1セットのePCをePCビットマップ値に変換する。
c. EPC_BITMAP2COUNT：この関数は、ePCビットマップ値を、ePCビットマップ値内のセットされているビットの数で表されるePCのカウントに変換する。
2. 存在演算：EPC_BITMAP_EXISTS：この関数は、所与のePC（第2の引数）を表すビットがePCビットマップ値（第1の引数）にセットされているかどうかに応じて1または0を返す。
3. 論理演算：
a. EPC_BITMAP_AND：この関数は、2つのePCビットマップ値をとり、ビットマップ値の論理積を返す。
b. EPC_BITMAP_OR：この関数は、2つのePCビットマップ値をとり、ビットマップ値の論理和を返す。
c. EPC_BITMAP_XOR：この関数は、2つのePCビットマップ値をとり、ビットマップ値の排他的論理和を返す。
d. EPC_BITMAP_MINUS：この関数は、2つのePCビットマップ値をとり、第1のePCビットマップ値から第2のePCビットマップ値を引いた値を返す。
4. ePCビットマップ値で表される1セットのオブジェクトを変更する。
a. EPC_BITMAP_INSERT：この関数は、ePCビットマップ値および1セットのePCをとり、そのセット内のePCに対応するビットマップ値内のビットをセットする。
b. EPC_BITMAP_DELETE：この関数は、ePCビットマップ値および1セットのePCをとり、そのセット内のePCに対応するビットマップ値内のビットをセットする。
5. 2つのePCビットマップ値が等値であるかどうかを比較する：EPC_BITMAP_EQUALS：この関数は、2つのePCビットマップ値をとり、ビットマップ値が同じ1セットのePCを表している場合には論理値TRUEを表す値を返し、そうでない場合にはFALSEを表す値を返す。
6. ePCビットマップ値代入：ePCビットマップ値のソースが、ePCビットマップフィールドの値などのターゲットePCビットマップ変数に代入される。演算の終了時に、ターゲットはソースの値およびクラスを有する。

これらの演算は、ビットマップ演算の全般的な議論で説明したように働く。マッピング指定子がサフィックス値のいくつかの範囲を指定する場合、演算は、ePCの結果集合全体を表す結果ビットマップ値を与える必要に応じて各範囲を変更することができる。1セットのePCをePCビットマップ値に変換するかまたはePCビットマップ値に含まれる1セットのePCを修正する演算において、演算には、プレフィックスビットとみなすべきePC内のビットの数を指定するパラメータを含めてよい。

ePCビットマップ値のアプリケーション
ePCのリストをネットワークを介して転送するのに必要な帯域幅を小さくする
ePCによる在庫追跡は、格納棚などのコンテナに現在入っている製品品目のePCを追跡する追跡装置によって行われる。追跡装置は、現在コンテナにどんな製品品目が入っているかを示す総計イベントメッセージを定期的に中央在庫データベースに送信する。このようなメッセージは、在庫追跡システムにおける一種のイベントメッセージである。図9は、そのような総計イベントメッセージ(event message)を示している。メッセージはXML形式である。各メッセージ構成要素は<構成要素_名前>...</構成要素_名前>(<content_name>...</content_name>)によって区切られており、各構成要素は、入れ子にされた構成要素を含んでよい。イベントメッセージ901は総計イベント(aggregationEvent)である。メッセージの次の構成要素は、このイベントの識別子903である。次の構成要素は、イベントメッセージのソースであるコンテナの識別子である。次の構成要素は、現在コンテナに入っている製品品目のePCのリスト907である。次の構成要素は、ePCのリストが作成された時間を示すタイムスタンプ909である。

コンテナが任意のサイズであるとき、コンテナ内のePCのリストは非常に長くなる。大部分の在庫管理はePCで行われるため、メッセージ901などのメッセージの数は非常に多くなり、メッセージを伝達するネットワークに深刻な負担を課す。イベントメッセージ911は、ePCビットマップ値を使用してePCのリストを含むイベントメッセージのサイズを小さくするにはどうすればよいかを示す。913に示されているように、ePCのリスト907は、ePCビットマップ値のリスト913で置き換えられる。リスト上の各品目は、コンテナ内の1つまたは複数の品目のePCプレフィックス811を含むマッピング指定子を持つePCビットマップ値を有する。ePCプレフィックス811によって指定される種類の品目に属するサフィックスに対応するビットストリング表現内の各ビットがセットされる。コンテナ内のすべての品目が同じプレフィックスを有する場合、ePCビットマップ値リスト913には単一のエントリが存在する。そうでない場合、コンテナ内に品目が存在する各ePCプレフィックスごとにエントリが存在する。

データベース管理システムテーブルでePCビットマップ値を使用する
多くの場合、総計イベントメッセージは、データベース管理システムを使用して在庫を追跡する中央位置に送信される。ePCビットマップ値をこのような中央位置のテーブルで使用して、テーブルを縮小すると共に、ePCに対する多数の有用な演算の実行を高速化することができる。このようなテーブルの一例である在庫テーブル(InventoryTable)915が図9に示されている。このテーブルを作成するDDLは以下のようなものである。
CREATE TABLE InventoryTable
(Container_EPC RAW(12),
Product_EPC_prefix RAW(12),
Time_checked TIMESTAMP、
Item_suffix_bitmap EPC96BITMAP);
このテーブルは4つの列、すなわち、在庫が管理されているコンテナののePCを含むコンテナ_EPC(container_EPC) 917と、特定の種類の製品の品目を表すePCに関するオブジェクトクラス807である製品_EPC_プレフィックス(Product_EPC_prefix)919と、フィールド919で示される種類の、フィールド917で示されるコンテナ内の製品が、最後に検査されたのはいつかを示す時間_検査(Time_checked)921と、フィールド921で示される時間にフィールド917で示されるコンテナ内にフィールド919でしめされる製品のどの品目が入っていたかを示すePCビットマップ値を含む品目_サフィックス_ビットマップ(Item_suffix_bitmap)923とを有する。品目_サフィックス_ビットマップ(Item_suffix_bitmap))のタイプ宣言で示されるように、ビットマップ値で表されるePCの各セットは96ビットePCを含む。

ePCビットマップ演算をテーブル915で使用できるようにするための多数の方法が存在する。たとえば、特定のコンテナ内の特定の種類の製品についていくつかの品目があるかを求めるには、以下のようなEPC_BITMAP2COUNT関数を使用することができる。
item_count:= EPC_BITMAP962COUNT(TO_SET(
SELECT Item_sufix_bitmap
FROM InventoryTable
WHERE(Container_EPC = container) AND
(Product_EPC_prefix = prod_pefix)));

総計イベントメッセージ911を介して在庫情報が得られた場合、総計メッセージのタイムスタンプをフィールド921に代入し、特定のコンテナおよび製品についてのメッセージのePCビットマップをフィールド923に代入することによって、特定のコンテナおよび製品用の在庫テーブル行を更新することができる。更新中に、ビットマップ論理演算を使用して、フィールド923の古いビットマップ値と総計イベントメッセージで受信されたビットマップとの間の変化を検出することができる。古いビットマップ値と受信されたビットマップの排他的論理和を求め、結果ビットストリングがすべて「0」ビットを有する場合、棚上の製品品目は変化していない。したがって、排他的論理和を使用してEQUALS演算を実施することができる。EPC_BITMAP_ORを使用してテーブル全体にわたって製品の品目の和を求めることができ、COUNT関数を合計OR演算の結果に適用して、テーブル内にエントリを有するコンテナに存在する品目の総数を求めることができる。EPC_BITMAP_MINUSを使用して品目の挿入および削除を検出することができる。EPC_BITMAP_EXISTSをクエリーに使用して、特定のePCで示される品目がどのコンテナに位置しているかを求めることができる。

ePCのリストを含む総計イベントメッセージでは、プレフィックスによってリストをソートし、EPCS2EPC_BITMAPを使用してコンテナおよび製品のフィールド923を設定することができる。同様に、テーブル915を含むシステムが、特定のコンテナ内の特定の製品の品目のePCのリストを与える必要がある場合、システムは、コンテナおよび製品のフィールド923にEPC_BITMAP2EPCSを適用することによってそうすることができる。総計イベントメッセージが、コンテナから削除された品目のePCまたはコンテナに追加された品目のePCを報告するに過ぎない場合、EPC_BITMAP_DELETEおよびEPC_BITMAP_INSERTを使用してフィールド923内のビットマップ値を更新することができる。

ユーザ定義ビットマップデータタイプ
すでに指摘したように、行idビットマップ値は、データベーステーブルの1つまたは複数の列に記憶するのが適切な任意の1セットのオブジェクトを表すことができる。したがって、データベースシステムに記憶されている数セットのオブジェクトを表すユーザ定義ビットマップデータタイプは必要ではない。しかし、ユーザ定義ビットマップデータタイプは、ビットマップ値で表されるオブジェクトがデータベースシステムの外部に存在する場合に役立つことがある。前述のように、このようなビットマップデータタイプに必要なのは、順序付けされた1セットの識別子だけである。本発明の他の態様は、ユーザが、データベースシステムにおける1セットの識別子と、1セットの識別子を定義するビットマップデータタイプを定義するのを可能にする。ビットマップデータタイプの定義では、ビットマップデータタイプに関するマッピング指定子が定義され、このデータタイプのビットストリング表現およびビットマップデータタイプの値に対する演算の意味が定義される。

結論
上記の「詳細な説明」では、本発明のビットマップ値を作成し使用するにはどうすべきかを関連技術の当業者に開示し、さらに、本発明のビットマップ値を作成し使用する場合の、現在発明者が分かっている最良の形態を開示した。本明細書に開示された技術に関する多数の変形態様が可能であることがただちに明らかになろう。たとえば、本明細書に開示されたビットマップ値では、ビットマップ値で表されるセットにオブジェクトが存在することが、ビットストリング内のビットを1に設定することによって示され、存在しない場合は、このビットが0に設定され、いくつかの態様では、この逆になり、オブジェクトが存在する場合にはこのビットが0に設定され、そうでない場合には1に設定される。ビットストリング内の各ビットおよび範囲指定子内の各範囲は、他の態様では、目的に対して好都合な任意の技術によって表すことができ、特に、そのセットにオブジェクトが存在することに関するビットストリングに含まれる情報を保存する任意の圧縮方法を、ビットマップ値のビットストリングに適用することができる。数セットの行idおよび数セットのePCを表すビットマップ値に関して本明細書で説明した技術は、任意の大きな1セットの順序付けされたオブジェクトを表すビットマップ値を作成して使用する場合に有効に適用することができる。このようなビットマップ値の使用法はもちろん、ビットマップ値で表されるオブジェクトが属するドメインによって決まる。行idを表すビットマップ値は、ユーザ定義インデックスを作成するためだけでなく、1セットの行idのコンパクトな表現を維持すると役立つ任意の目的でも、データベース管理システムにおいて使用することができる。本明細書で説明したのと異なる意味または構文を有する開示されたビットマップ演算の形態を作成することができる。さらに、必要な演算の種類がビットマップ値で表されるオブジェクトによって決まるため、他の態様では、本明細書で説明したもの以外のビットマップ値に対する演算を定義し使用することができる。すべての上記の理由で、「詳細な説明」は、すべての点で例示的なものとみなされ、制限的なものとはみなされず、本明細書で開示された本発明の範囲は、「詳細な説明」ではなく、特許法によって許容される全範囲によって解釈したときの特許請求の範囲から決定すべきである。

本発明のビットマップ値を使用して作成されたユーザ定義インデックスの概念的な概要である。好ましい態様におけるビットマップ値を表すのに使用される技術の概要である。ビットマップ値に対して実行することのできる変換演算を示す。ビットマップ値に対して実行することのできるオブジェクト存在演算を示す。ビットマップ値に対して実行することのできる論理演算を示す。オブジェクトを表すビットをビットマップ値に挿入し、オブジェクトを表すビットをビットマップ値から削除する演算を示す。本発明が実施されるデータベース管理システムにおけるメタデータオブジェクトを示す。 EPC、および数セットのEPCを表すビットマップ値を示す。 ePCビットマップ値を含む総計イベントメッセージと、ePCビットマップ値を含むデータベーステーブルとを示す。好ましい態様のデータベース管理システム内の行idと、数セットの行idを表すビットマップ値とを示す。

Claims

データベース管理システムであって、
演算手段と、
第１のテーブルおよび第２のテーブルを格納する記憶手段とを備え、前記第１のテーブルは、複数のビットマップ値を保持しており、
前記ビットマップ値は、ビットストリングの表現を有しており、
当該表現のセットされたビットは、１セットのオブジェクトを指定し、
前記オブジェクトは、前記第２のテーブルのそれぞれの行を識別する複数の行識別子を含み、
前記演算手段は、１つ以上の行識別子に対応する１以上の行がユーザ定義クエリーを満たす場合に、前記複数の行識別子のうち当該１つ以上の行識別子を表現するビットマップ値を返し、それにより、
前記演算手段は、ユーザによって指定され、１つ以上のオペランドを有する指令に応答して、１つ以上のプリミティブビットマップ演算を実行し、当該１つ以上のオペランドは、１つ以上のビットマップ値、または、１つ以上のセットのオブジェクトを含み、前記１つ以上のプリミティブビットマップ演算は、前記データベース管理システムのユーザ、および、前記データベース管理システムによってアクセス可能である、データベース管理システム。
前記プリミティブビットマップ演算は、オペランドで指定された１セットのオブジェクトからビットマップ値が導出されるセット・ツー・ビットマップ（set-to-bitmap）演算を少なくとも含む、請求項１記載のデータベース管理システム。
前記導出されるビットマップ値は、指定されたセット内のオブジェクトを指定する新しいビットマップ値である、請求項２記載のデータベース管理システム。
前記導出されるビットマップ値は、指定されたセット内のさらなるオブジェクトを新たに指定する既存のビットマップ値である、請求項２記載のデータベース管理システム。
前記導出されるビットマップ値は、指定されたセット内のもはやいずれのオブジェクトも指定しない既存のビットマップ値である、請求項２記載のデータベース管理システム。
前記プリミティブビットマップ演算は、少なくとも、オペランドで指定されたビットマップ値で指定されたセットのオブジェクトを当該指定されたビットマップ値から導出するビットマップ・ツー・セット（bitmap-to-set）演算を含む、請求項１〜５のいずれか１項記載のデータベース管理システム。
前記プリミティブビットマップ演算は、少なくとも、オペランドで指定されたビットマップ値で指定されたセット内のオブジェクトの数を当該指定されたビットマップ値から導出するビットマップ・ツー・カウント（bitmap-to-count）演算を含む、請求項１〜６のいずれか１項記載のデータベース管理システム。
前記プリミティブビットマップ演算は、少なくとも、オペランドで指定されたオブジェクトがもう１つのオペランドで指定されたビットマップ値で表されるセットのオブジェクトに属するときに論理値ＴＲＵＥを表す値を返す存在演算を含む、請求項１〜７のいずれか１項記載のデータベース管理システム。
前記プリミティブビットマップ演算は、少なくとも、オペランドで指定された第１のビットマップ値からの第１のビットストリングと、もう１つのオペランドで指定された第２のビットマップ値からの第２のビットストリングとに関する論理演算を含む、請求項１〜８のいずれか１項記載のデータベース管理システム。
前記プリミティブビットマップ演算は、少なくとも、オペランドで指定された第１のビットマップ値ともう１つのオペランドで指定された第２のビットマップ値とが同じセットのオブジェクトを指定するときに論理値ＴＲＵＥを表す値を返す、第１のビットマップ値および第２のビットマップ値に関する比較演算を含む、請求項１〜９のいずれか１項記載のデータベース管理システム。
前記ビットマップ値は、設定可能なビットマップ値を含み、かつ
前記プリミティブビットマップ演算は、少なくとも、オペランドで指定されたターゲット設定可能ビットマップ値を、もう１つのオペランドで指定されたソースビットマップ値からセットする代入演算を含む、請求項１〜１０のいずれか１項記載のデータベース管理システム。
前記ビットマップ値は、データベース管理システムにおいて永続的なビットマップ値を含む、請求項１〜１１のいずれか１項記載のデータベース管理システム。
前記永続的なビットマップ値は、前記データベース管理システムのテーブルのユーザ指定のフィールド内のビットマップ値を含む、請求項１２記載のデータベース管理システム。
前記ビットマップ値における前記ビットストリングは、圧縮されている、請求項１〜１３のいずれか１項記載のデータベース管理システム。
前記他のオブジェクトは、前記データベース管理システムに存在する、請求項１〜１４のいずれか１項記載のデータベース管理システム。
前記他のオブジェクトは、前記データベース管理システムの外部に存在する、請求項１〜１４のいずれか１項記載のデータベース管理システム。
前記データベース管理システムの外部に存在するオブジェクトの識別子は、製品品目の電子製品コード（ＥＰＣ（Electronic Product Codes））である、請求項１６記載のデータベース管理システム。
コンピュータシステムで実行されたときに、請求項１〜１７のいずれか１項記載のデータベース管理システムを実現するコードを含むことを特徴とするデータ記憶装置。
データベース管理システムであって、
以下の処理を実行するように適合された演算手段を備え、当該以下の処理は、
複数のビットマップ値を保持する第１のテーブルを識別または判断する処理を含み、前記ビットマップ値は、ビットストリングの複数のビットの各々についての値を有しており、当該以下の処理はさらに、
複数のオブジェクトの定義を保持する第２のテーブルを識別または判断する処理を含み、前記ビットマップ値は、前記複数のオブジェクトの第１のセットを表現し、当該以下の処理はさらに、
前記第１のオブジェクトのセット内の第１のオブジェクトを、オブジェクトの第２のセット内の第２のオブジェクトにマッピングする処理を含み、前記ビットマップ値は、
当該ビットマップ値に表現されている複数ビットのストリングを、前記第２のセットの一部にマップするマッピング指定子と、
前記複数ビットのストリングの表現とを含み、前記第１のセットのメンバーに対応するビットに前記第２のセットのメンバーがマッピングされると、当該複数ビットのストリングの表現においてビットがセットされ、
前記演算手段は、少なくとも、
第１のユーザ指定指示に応答して、前記複数ビットのストリングの前記第２のセットの当該一部へのマッピングを指定するための第１の演算と、
第２のユーザ指定指示に応答して、前記第１のセットに対応する複数ビットのストリング内の１つ以上のビットをセットする第２の演算を実行する、データベース管理システム。
前記第２のオブジェクトのセットは、順序付けされている、請求項１９記載のデータベース管理システム。
前記第２のオブジェクトのセットの順序は、前記第２のオブジェクトのセット内のオブジェクトの値に対応し、
前記マッピング指定子は、前記複数ビットのストリングがマップされるオブジェクトの値の１つまたは複数の範囲を指定することによってマッピングを指定し、
前記複数ビットのストリングの表現は、当該範囲に対応する複数ビットのストリングを表す、請求項２０記載のデータベース管理システム。
前記マッピング指定子は、開始値および終了値を指定することによって前記オブジェクトの値の範囲を指定する、請求項２１記載のデータベース管理システム。
前記ビットマップ値は、前記オブジェクトの値の範囲を決定するプレフィックスを含み、
前記マッピング指定子は、当該範囲のためプレフィックスを指定することによって前記オブジェクトの値の範囲を指定する、請求項２１記載のデータベース管理システム。
前記マッピング指定子は、前記プレフィックスによって指定された範囲の１つまたは複数の部分範囲を指定するため、開始値および終了値を使用して値の範囲をさらに指定する、請求項２３記載のデータベース管理システム。
前記オブジェクトは、ＥＰＣである、請求項１９記載のデータベース管理システム。
前記ビットマップ値のいくつかは、前記データベース管理システムにおいて永続的である、請求項１９記載のデータベース管理システム。
前記永続的であるビットマップ値は、前記データベース管理システムのテーブルのユーザ指定のフィールドのビットマップ値を含む、請求項２６記載のデータベース管理システム。
前記ビットストリングの表現は、当該ビットストリングの圧縮表現である、請求項１９記載のデータベース管理システム。
前記演算手段は、前記ビットマップ値に関するユーザアクセス可能な演算をさらに実行する、請求項１９記載のデータベース管理システム。
前記演算手段は、表現された複数ビットのストリングを演算に必要な第２のサブセットにマップする必要に応じて、範囲指定子およびビットストリングの表現を変更する、請求項２９記載のデータベース管理システム。
コンピュータシステムで実行されたときに、請求項１９または２０記載のデータベース管理システムを実現するコードを含むことを特徴とするデータ記憶装置。
データベースシステムで使用される方法であって、前記データベースシステムは、ビットマップ値を保持する第１のテーブルと、オブジェクトの定義を含む第２のテーブルとを含み、前記ビットマップ値は、前記オブジェクトの第２のサブセットに含まれる第１のサブセットを表し、
前記ビットマップ値は、
複数ビットのストリングを前記第２のサブセットにマップするマッピング指定子と、
前記複数ビットのストリングの表現とを含み、各ビットは、当該ビットにマップされる第２のサブセットのメンバーが、前記第１のサブセットに属するときに、当該表現された複数ビットのストリングにおいてセットされ、前記方法は、演算手段によって実行される処理を含み、当該処理は、
ユーザ指定指示に応答して、前記複数ビットのストリングのマッピングを前記第２のサブセットに指定するための第１の演算を実行する処理と、
前記演算手段が、ユーザの直接的な指定に応答して、前記第１のサブセットに対応する複数ビットのストリングの複数ビットをセットする第２の演算を実行する処理とを備える、データベースシステムで使用される方法。
前記オブジェクトは、ＥＰＣを含む、請求項３２記載の方法。
前記オブジェクトは、順序付けされており、
前記第１の演算を行う処理は、
前記オブジェクトの範囲を指定する範囲指定子を作成する処理と、
前記複数ビットのストリング内のビットを、前記範囲指定子によって指定される範囲にマップする処理とを含む、請求項３２記載の方法。
前記範囲指定子を作成する処理は、いずれも範囲を指定する、開始値および終了値を作成する処理を含む、請求項３４記載の方法。
前記範囲指定子を作成する処理は、範囲を指定するプレフィックス値を作成する処理を含む、請求項３４記載の方法。
前記ビットストリングを圧縮する処理をさらに含む、請求項３２記載の方法。
コンピュータシステムで実行されたときに、請求項３２〜３７のいずれか１項記載の方法を実現するコードを含むことを特徴とする、データ記憶装置。