特開 2024-86707 グラフおよびリレーショナルデータのための統一されたクエリエンジン

(19)【発行国】日本国特許庁(JP)

(12)【公報種別】公開特許公報(A)

(11)【公開番号】P2024086707

(43)【公開日】2024-06-27

(54)【発明の名称】グラフおよびリレーショナルデータのための統一されたクエリエンジン

(51)【国際特許分類】

   G06F 16/28 20190101AFI20240620BHJP

   G06F 16/903 20190101ALI20240620BHJP

【ＦＩ】

G06F16/28

G06F16/903

【審査請求】未請求

【請求項の数】13

【出願形態】ＯＬ

【外国語出願】

(21)【出願番号】P 2023212808

(22)【出願日】2023-12-18

(31)【優先権主張番号】22306926.1

(32)【優先日】2022-12-16

(33)【優先権主張国・地域又は機関】EP

(71)【出願人】

【識別番号】500102435

【氏名又は名称】ダッソー システムズ

【氏名又は名称原語表記】ＤＡＳＳＡＵＬＴ ＳＹＳＴＥＭＥＳ

(74)【代理人】

【識別番号】110001243

【氏名又は名称】弁理士法人谷・阿部特許事務所

(72)【発明者】

【氏名】ジャン－フィリップ サウト ディザーン

(72)【発明者】

【氏名】フレデリック ラバーテ

(72)【発明者】

【氏名】アルバン ルーリエ

(72)【発明者】

【氏名】エリック ヴァレ グレニッソン

【テーマコード（参考）】

5B175

【Ｆターム（参考）】

5B175AA02

5B175CA09

5B175CA11

(57)【要約】

【課題】リレーショナルデータおよびグラフデータを含むデータベース上でクエリエンジンによって問い合わせるためのコンピュータ実装方法を提供する。
【解決手段】本開示は、特に、リレーショナルデータおよびグラフデータを含むデータベース上でクエリエンジンによって問い合わせるためのコンピュータ実装方法に関する。本方法は、クエリエンジンによってクエリを受信するステップであって、クエリは、一階論理パラダイムと互換性のある言語でのクエリである、ステップを含む。本方法は、中間表現（ＩＲ）を生成するステップであって、ＩＲは、一階論理パラダイムと互換性がある、ステップをさらに含む。本方法は、クエリの中間表現を使用して、データベースのリレーショナルデータおよびグラフデータに対してクエリを実行するステップをさらに含む。
【選択図】図１

【特許請求の範囲】

【請求項1】

リレーショナルデータおよびグラフデータを含むデータベース上でクエリエンジンによって問い合わせるためのコンピュータ実装方法であって、前記方法は、
クエリエンジンによってクエリを受信するステップ（Ｓ１０）であって、前記クエリは、一階論理パラダイムと互換性のある言語でのクエリである、ステップと、
中間表現（ＩＲ）を生成するステップ（Ｓ２０）であって、前記ＩＲは、一階論理パラダイムと互換性がある、ステップと、
前記クエリの前記中間表現を使用して、前記データベースの前記リレーショナルデータおよび前記グラフデータに対して前記クエリを実行するステップ（Ｓ３０）と
を含む方法。

【請求項2】

前記クエリがＳＰＡＲＱＬクエリである場合、前記生成された中間表現は前記ＳＰＡＲＱＬクエリの一階論理の述語計算に変換される、
前記クエリがＳＱＬクエリである場合、前記生成された中間表現は前記ＳＱＬクエリの一階論理の述語計算に変換される、及び／または、
前記データベースの前記リレーショナルデータは、１つもしくは複数のテーブルを含み、前記データベースの前記グラフデータは、１つもしくは複数の隣接行列を含む、請求項１に記載の方法。

【請求項3】

前記クエリは第１のＳＱＬクエリであり、前記クエリの前記中間表現を使用して、前記データベースの前記グラフデータに対して前記クエリを実行するステップは、
前記データベースの前記グラフデータに対してＳＰＡＲＱＬ ＳＥＬＥＣＴクエリを実行して、それにより、タプルを出力するステップと、
前記実行されたクエリのマテリアライズドビューを作成するステップと、
前記作成されたマテリアライズドビューに対して前記第１のＳＱＬクエリを実行するステップとを含む、請求項１または２に記載の方法。

【請求項4】

第２のＳＱＬクエリを受信するステップをさらに含み、
前記第２のＳＱＬクエリの実行は、前記第１のＳＱＬクエリの前記作成されたマテリアライズドビューに基づく、請求項３に記載の方法。

【請求項5】

前記マテリアライズドビューを作成するステップは、テーブルを作成するステップを含み、
前記テーブルの行は、前記タプルに関連付けられ、
前記テーブルの列は、前記クエリのそれぞれの変数に関連付けられる、請求項３または４に記載の方法。

【請求項6】

前記受信されたクエリは、ＳＰＡＲＱＬまたはＳＱＬにおいて少なくとも１つのＪＯＩＮ句を有し、前記生成された中間表現は、以下の型のバッカス－ナウア記法（ＢＮＦ）文法、
<joined table> ::=
<cross join>
| <qualified join>
| <left paren> <joined table> <right paren>
<cross join> ::=
<table reference> CROSS JOIN <table reference>
<qualified join> ::=
<table reference> [ NATURAL ] [ <join type> ] JOIN <table reference>
[ <join specification> ]
<join type> ::=
INNER
| <outer join type> [ OUTER ]
| UNION
<outer join type> ::= LEFT | RIGHT | FULL
<join specification> ::= <join condition> | <named columns join>
<join condition> ::= ON <search condition>
<named columns join> ::= USING <left paren> <join column list> <right paren>
<join column list> ::= <column name list>
で記述される、請求項１乃至５のいずれか一項に記載の方法。

【請求項7】

前記受信されたクエリは、ＳＰＡＲＱＬまたはＳＱＬにおいてＦＲＯＭ句を有し、前記生成された中間表現は、以下の型のＢＮＦ文法、
<from clause> ::= FROM <table reference> [ { <comma> <table reference> }... ]
<table reference> ::=
<table name> [ <correlation specification> ]
| <derived table> <correlation specification>
| <joined table>
で記述される、請求項１乃至６のいずれか一項に記載の方法。

【請求項8】

前記ＦＲＯＭ句は、ＡＳ句を含み、前記生成された中間表現は、以下の型のＢＮＦ文法、
<correlation specification> ::=
[ AS ] <correlation name> [ <left paren> <derived column list> <right paren> ]
<derived column list> ::= <column name list>
で記述される、請求項７に記載の方法。

【請求項9】

前記受信されたクエリは、ＳＰＡＲＱＬまたはＳＱＬにおいてＷＨＥＲＥ句を有し、前記生成された中間表現は、以下の型のＢＮＦ文法、
<where clause> ::= WHERE <search condition>
<search condition> ::=
<boolean term>
| <search condition> OR <boolean term>
<boolean term> ::=
<boolean factor>
| <boolean term> AND <boolean factor>
<boolean factor> ::= [ NOT ] <boolean test>
<boolean test> ::= <boolean primary> [ IS [ NOT ] <truth value> ]
<boolean primary> ::= <predicate> | <left paren> <search condition> <right paren>
<predicate> ::=
<comparison predicate>
| <between predicate>
| <in predicate>
| <like predicate>
| <null predicate>
| <quantified comparison predicate>
| <exists predicate>
| <match predicate>
| <overlaps predicate>
で記述される、請求項１乃至８のいずれか一項に記載の方法。

【請求項10】

前記生成された中間表現は、少なくとも入力を有する少なくとも１つの第１のＦＩＮＤ演算子を含み、前記方法は、
前記第１のｆｉｎｄ演算子を第２のｆｉｎｄ演算子に置き換えることによって、前記生成された中間表現を更新するステップであって、前記第２のｆｉｎｄ演算子は、前記入力がヌルのときに未定義値を返すように構成されているステップをさらに含む、請求項１乃至９のいずれか一項に記載の方法。

【請求項11】

請求項１乃至１０のいずれか一項に記載の方法を実行するための命令を含むコンピュータプログラム。

【請求項12】

請求項１１に記載のコンピュータプログラムを記録したコンピュータ可読記憶媒体。

【請求項13】

メモリに結合されたプロセッサを備えたシステムであって、前記メモリは請求項１１に記載のコンピュータプログラムを記録している、システム。

【発明の詳細な説明】

【技術分野】

【0001】

本開示は、コンピュータプログラムおよびシステムの分野に関し、より具体的には、リレーショナルデータおよびグラフデータを含むデータベース上でクエリエンジンによって問い合わせるための方法、システム、およびプログラムに関する。

【背景技術】

【0002】

複数のシステムおよびプログラムが、オブジェクトの設計、エンジニアリング、および製造の市場に提供されている。ＣＡＤは、コンピュータ支援設計（Computer-Aided Design）の頭字語であり、例えば、オブジェクトを設計するためのソフトウェアソリューションに関する。ＣＡＥはコンピュータ支援エンジニアリング（Computer-Aided Engineering）の頭字語であり、例えば、将来の製品の物理的挙動をシミュレートするためのソフトウェアソリューションに関する。ＣＡＭはコンピュータ支援製造（Computer-Aided Manufacturing）の頭字語であり、例えば、製造プロセスおよび動作を定義するためのソフトウェアソリューションに関する。このようなコンピュータ支援設計システムでは、グラフィカルユーザインターフェースが技術の効率に関して重要な役割を果たす。これらの技術は、製品ライフサイクル管理（ＰＬＭ）システム内に組み込まれることがある。ＰＬＭとは、会社が、拡張された企業の概念にわたって、製品データを共有し、共通のプロセスを適用し、製品の開発について着想から寿命の終末まで企業知識を活用するのに役立つ事業戦略のことである。Ｄａｓｓａｕｌｔ Ｓｙｓｔｅｍｅｓによって（商標ＣＡＴＩＡ、ＥＮＯＶＩＡ、およびＤＥＬＭＩＡのもとに）提供されるＰＬＭソリューションは、製品エンジニアリング知識を編成するエンジニアリングハブ、製造エンジニアリング知識を管理する製造ハブ、およびエンジニアリングハブと製造ハブとの両方への企業の統合および接続を可能にする企業ハブを提供する。これらを合わせて、システムは、最適化された製品定義、製造準備、生産、およびサービスを促進する動的な知識ベースの製品作成および意思決定サポートを可能にするために、製品、プロセス、リソースをリンクするオープンオブジェクトモデルを提供する。

【0003】

さらに、ディスクまたはＳＳＤにデータを格納するデータベースとは対照的に、インメモリデータベース、すなわち、データ格納を主にメモリに依存する専用データベースにおいて、上記の設計システムおよびプログラムを適用するために、いくつかのデータベース管理用のシステムが提供されている。そのようなデータベース管理システム（ＤＢＭＳ）は、リレーショナルデータベース管理システム（ＲＤＢＭＳ）と、グラフデータベース管理システム（ＧＤＢＭＳ）と呼ばれる２つの主なカテゴリを含み、これらは、アプリケーションデータをモデル化する中核的なデータ構造としてグラフおよびリレーションをそれぞれ使用している。

【0004】

ＲＤＢＭＳとＧＤＢＭＳは、ユーザに訴求し得る補完的な機能を備えている。例えば、グラフとは異なり、リレーショナルモデルはバイナリ関係に制限されず、エンティティ間のｎ項関係を容易にモデル化する。同時に、リレーショナルモデルはデータの厳密な図式化を必要とするが、グラフモデルは半構造化されていることが多く、より柔軟なデータモデリングおよびデータ格納（例えば、疎なデータの格納）を提供する。他方で、ＳＱＬは標準データ解析タスクを表現するのに非常に適しているが、ＧＤＢＭＳの言語は再帰的結合でクエリを表現する表現形式のための特殊な構文を含んでいる。さらに、グラフモデルは、多くの再帰的および多対多結合を含むグラフワークロードに対して、より良好な性能を有する。

【0005】

ＧＤＢＭＳとＲＳＢＭＳの各々の長所と短所があるため、統一されたクエリアプローチのためのいくつかの解決策および方法が提案されている。

【0006】

非特許文献１は、ＳＱＬ Ｓｅｒｖｅｒ ＰＤＷ Ｖ２の特徴であるｐｏｌｙｂａｓｅを提示しており、ｐｏｌｙｂａｓｅは、標準ＳＱＬを使用してＨａｄｏｏｐクラスタに格納されたデータをユーザが管理し問い合わせることを可能にし、ＨＤＦＳ常駐データに対するクエリ演算子は、ＰＤＷクエリオプティマイザによってＭａｐＲｅｄｕｃｅジョブに変換され、次いで、Ｈａｄｏｏｐクラスタ上で実行される。

【0007】

非特許文献２は、ポリグロットクエリ用に設計されたデータ処理エンジンであるＢａｂｅｌｆｉｓｈを提示している。Ｂａｂｅｌｆｉｓｈは、異なる実装言語からのクエリを統一する中間表現を導入している。

【0008】

非特許文献３は、グラフモデリング、クエリ、および可視化機能を提供するようにＤｕｃｋＤＢ ＲＤＢＭＳを拡張するシステムであるＧｒａｉｎＤＢ実証を提示している。さらに、ＧｒａｉｎＤＢは、ＤｕｃｋＤＢの内部を修正して、システムレベルレコードＩＤ（ＲＩＤ）および隣接リスト状ＲＩＤインデックスを使用する事前定義されたポインタベースの結合など、高速結合機能のセットを提供するようにして、ＤｕｃｋＤＢをグラフワークロードでより効率的にする。

【0009】

ＲＤＦｏｘ（非特許文献４参照）は、ＲＤＦデータモデルに従って表現されたグラフ構造化データをユーザが管理し、ＳＰＡＲＱＬ１．１クエリ言語を使用してそのデータをクエリすることを可能にする、メインメモリでありスケーラブルである集中型データストアを開示している。ＲＤＦｏｘは、ＰｏｓｔｇｒｅＳＱＬまたはＯＤＢＣ（非特許文献５参照）などの外部ソースに接続することができる。

【0010】

この文脈において、リレーショナルデータおよびグラフデータを含むデータベース上でクエリエンジンによって問い合わせるための改良された方法が依然として必要である。

【先行技術文献】

【非特許文献】

【0011】

【非特許文献1】Ｄｅｗｉｔｔ ｅｔ ａｌ．，“Ｓｐｌｉｔ ｑｕｅｒｙ ｐｒｏｃｅｓｓｉｎｇ ｉｎ ｐｏｌｙｂａｓｅ．”，Ｐｒｏｃｅｅｄｉｎｇｓ ｏｆ ｔｈｅ ２０１３ ＡＣＭ ＳＩＧＭＯＤ Ｉｎｔｅｒｎａｔｉｏｎａｌ Ｃｏｎｆｅｒｅｎｃｅ ｏｎ Ｍａｎａｇｅｍｅｎｔ ｏｆ Ｄａｔａ．２０１３．ｐ．１２５５－１２６６

【非特許文献2】Ｇｒｕｌｉｃｈ ｅｔ ａｌ．，“Ｂａｂｅｌｆｉｓｈ：ｅｆｆｉｃｉｅｎｔ ｅｘｅｃｕｔｉｏｎ ｏｆ ｐｏｌｙｇｌｏｔ ｑｕｅｒｉｅｓ．”，Ｐｒｏｃｅｅｄｉｎｇｓ ｏｆ ｔｈｅ ＶＬＤＢ Ｅｎｄｏｗｍｅｎｔ，２０２１，ｖｏｌ． １５，ｎｏ ２，ｐ．１９６－２１０

【非特許文献3】Ｊｉｎ ｅｔ ａｌ．，“ＧｒａｉｎＤＢ：Ａ Ｒｅｌａｔｉｏｎａｌ－ｃｏｒｅ Ｇｒａｐｈ－Ｒｅｌａｔｉｏｎａｌ ＤＢＭＳ．”，Ｐｒｏｃｅｅｄｉｎｇｓ ｏｆ ｔｈｅ １２ｈ Ａｎｎｕａｌ Ｃｏｎｆｅｒｅｎｃｅ ｏｎ Ｉｎｎｏｖａｔｉｖｅ Ｄａｔａ Ｓｙｓｔｅｍｓ Ｒｅｓｅａｒｃｈ （ＣＩＤＲ ’２２），２０２

【非特許文献4】ｈｔｔｐｓ：／／ｗｗｗ．ｏｘｆｏｒｄｓｅｍａｎｔｉｃ．ｔｅｃｈ／

【非特許文献5】ｈｔｔｐｓ：／／ｅｎ．ｗｉｋｉｐｅｄｉａ．ｏｒｇ／ｗｉｋｉ／Ｏｐｅｎ＿Ｄａｔａｂａｓｅ＿Ｃｏｎｎｅｃｔｉｖｉｔｙ

【非特許文献6】“ＲＤＦ １．１ Ｃｏｎｃｅｐｔｓ ａｎｄ Ａｂｓｔｒａｃｔ Ｓｙｎｔａｘ”，Ｗ３Ｃ Ｒｅｃｏｍｍｅｎｄａｔｉｏｎ ２５ Ｆｅｂｒｕａｒｙ ２０１４ （ｏｒ ａｄｄｉｔｉｏｎａｌｌｙ ｔｈｅ ｄｒａｆｔ ｖｅｒｓｉｏｎ ＲＤＦ－ｓｔａｒ）

【非特許文献7】“ＲＤＦ １．１ Ｎ－Ｑｕａｄｓ，Ａ ｌｉｎｅ－ｂａｓｅｄ ｓｙｎｔａｘ ｆｏｒ ＲＤＦ ｄａｔａｓｅｔｓ”，Ｗ３Ｃ Ｒｅｃｏｍｍｅｎｄａｔｉｏｎ ２５ Ｆｅｂｒｕａｒｙ ２０１４

【非特許文献8】ｈｔｔｐｓ：／／ｗｗｗ．ｗ３．ｏｒｇ／ＴＲ／ｒｄｆ－ｓｐａｒｑｌ－ｑｕｅｒｙ／＃ｒｄｆＤａｔａｓｅｔ

【非特許文献9】ｈｔｔｐｓ：／／ｗｗｗ．ｗ３．ｏｒｇ／ＴＲ／ｓｐａｒｑｌ１１－ｑｕｅｒｙ／＃ＱｕｅｒｙＦｏｒｍｓ

【非特許文献10】ｈｔｔｐｓ：／／ｅｎ．ｗｉｋｉｐｅｄｉａ．ｏｒｇ／ｗｉｋｉ／ＳＱＬ－９２

【非特許文献11】ＲＤＦ １．１ Ｓｅｍａｎｔｉｃｓ，Ｗ３Ｃ ｒｅｃｏｍｍｅｎｄａｔｉｏｎ ｏｆ ２５ Ｆｅｂｒｕａｒｙ ２０１４

【非特許文献12】ｈｔｔｐｓ：／／ｅｎ．ｗｉｋｉｐｅｄｉａ．ｏｒｇ／ｗｉｋｉ／ＳＱＬ＃Ｐｒｅｄｅｆｉｎｅｄ＿ｄａｔａ＿ｔｙｐｅｓ

【非特許文献13】ｈｔｔｐｓ：／／ｅｎ．ｗｉｋｉｐｅｄｉａ．ｏｒｇ／ｗｉｋｉ／Ｆｉｒｓｔ－ｏｒｄｅｒ＿ｌｏｇｉｃ

【非特許文献14】ｈｔｔｐｓ：／／ｅｎ．ｗｉｋｉｐｅｄｉａ．ｏｒｇ／ｗｉｋｉ／Ｒｅｌａｔｉｏｎａｌ＿ｍｏｄｅｌ

【非特許文献15】ｈｔｔｐｓ：／／ｗｗｗ．ｗ３．ｏｒｇ／ＴＲ／ｓｐａｒｑｌ１１－ｑｕｅｒｙ／＃ｂａｓｉｃｐａｔｔｅｒｎｓ

【非特許文献16】ｈｔｔｐｓ：／／ｗｗｗ．ｗ３．ｏｒｇ／ＴＲ／ｒｄｂ－ｄｉｒｅｃｔ－ｍａｐｐｉｎｇ

【非特許文献17】ｈｔｔｐｓ：／／ｅｎ．ｗｉｋｉｐｅｄｉａ．ｏｒｇ／ｗｉｋｉ／Ｈａｓｈ＿ｊｏｉｎ

【非特許文献18】Ａｂｉｔｅｂｏｕｌ ｅｔ ａｌ．，“Ｆｏｕｎｄａｔｉｏｎｓ ｏｆ ｄａｔａｂａｓｅｓ．”，Ｒｅａｄｉｎｇ：Ａｄｄｉｓｏｎ－Ｗｅｓｌｅｙ，１９９５

【非特許文献19】Ａｎｇｌｅｓ ａｎｄ Ｇｕｔｉｅｒｒｅｚ，“Ｔｈｅ ｅｘｐｒｅｓｓｉｖｅ ｐｏｗｅｒ ｏｆ ＳＰＡＲＱＬ．”，Ｉｎｔｅｒｎａｔｉｏｎａｌ Ｓｅｍａｎｔｉｃ Ｗｅｂ Ｃｏｎｆｅｒｅｎｃｅ，Ｓｐｒｉｎｇｅｒ，Ｂｅｒｌｉｎ，Ｈｅｉｄｅｌｂｅｒｇ，２００８，ｐ．１１４－１２９

【非特許文献20】ｈｔｔｐ：／／ｗｗｗ．ｃｓ．ｒｐｉ．ｅｄｕ／～ｓｉｂｅｌ／ｃｓｃｉ４３８０／ｓｐｒｉｎｇ２０１６／ｃｏｕｒｓｅ＿ｎｏｔｅｓ／ｌｏｇｉｃ＿ｂａｇｓｅｍａｎｔｉｃｓ．ｈｔｍｌ

【非特許文献21】ｈｔｔｐｓ：／／ｗｗｗ．ｗ３．ｏｒｇ／ＴＲ／ｓｐａｒｑｌ１１－ｑｕｅｒｙ／＃ＢａｓｉｃＧｒａｐｈＰａｔｔｅｒｎｓ

【非特許文献22】ｈｔｔｐｓ：／／ｅｎ．ｗｉｋｉｐｅｄｉａ．ｏｒｇ／ｗｉｋｉ／Ｐｒｏｊｅｃｔｉｏｎ＿（ｒｅｌａｔｉｏｎａｌ＿ａｌｇｅｂｒａ）

【非特許文献23】ＰｏｓｔｇｒｅＳＱＬ：ｈｔｔｐｓ：／／ｗｗｗ．ｐｏｓｔｇｒｅｓｑｌ．ｏｒｇ／ｄｏｃｓ／ｃｕｒｒｅｎｔ／ｆｅａｔｕｒｅｓ．ｈｔｍｌ

【非特許文献24】ｈｔｔｐｓ：／／ｗｗｗ．ｗ３．ｏｒｇ／ＴＲ／ｓｐａｒｑｌ１１－ｑｕｅｒｙ／＃ｉｎｌｉｎｅ－ｄａｔａ

【非特許文献25】ｈｔｔｐｓ：／／ｇｉｔｈｕｂ．ｃｏｍ／ｐｏｓｔｇｒｅｓ／ｐｏｓｔｇｒｅｓ／ｂｌｏｂ／ｍａｓｔｅｒ／ｓｒｃ／ｂａｃｋｅｎｄ／ｐａｒｓｅｒ

【非特許文献26】ｈｔｔｐｓ：／／ｄｏｃｓ．ｍｉｃｒｏｓｏｆｔ．ｃｏｍ／ｅｎ－ｕｓ／ｓｑｌ／ｔ－ｓｑｌ／ｑｕｅｒｉｅｓ／ｓｅｌｅｃｔ－ｔｒａｎｓａｃｔ－ｓｑｌ？ｒｅｄｉｒｅｃｔｅｄｆｒｏｍ＝ＭＳＤＮ＆ｖｉｅｗ＝ｓｑｌ－ｓｅｒｖｅｒ－ｖｅｒ１５＃ｌｏｇｉｃａｌ－ｐｒｏｃｅｓｓｉｎｇ－ｏｒｄｅｒ－ｏｆ－ｔｈｅ－ｓｅｌｅｃｔ－ｓｔａｔｅｍｅｎｔ

【非特許文献27】ｈｔｔｐｓ：／／ｒｏｎｓａｖａｇｅ．ｇｉｔｈｕｂ．ｉｏ／ＳＱＬ／ｓｑｌ－９２．ｂｎｆ．ｈｔｍｌ

【非特許文献28】Ｍｅｌｔｏｎ ａｎｄ Ｓｉｍｏｎ，“Ｕｎｄｅｒｓｔａｎｄｉｎｇ ｔｈｅ ｎｅｗ ＳＱＬ：ａ ｃｏｍｐｌｅｔｅ ｇｕｉｄｅ”，Ｍｏｒｇａｎ Ｋａｕｆｍａｎｎ，１９９３）

【非特許文献29】［８］Ｄａｔｅ ａｎｄ Ｄａｒｗｅｎ，“Ａ Ｇｕｉｄｅ ｔｏ ｔｈｅ ＳＱＬ Ｓｔａｎｄａｒｄ”．Ｎｅｗ Ｙｏｒｋ：Ａｄｄｉｓｏｎ－Ｗｅｓｌｅｙ，ｔｈｉｒｄ ｅｄｉｔｉｏｎ，１９９３

【非特許文献30】ｈｔｔｐｓ：／／ｊｕｓｔｉｎｊａｆｆｒａｙ．ｃｏｍ／ｑｕｅｒｙ－ｅｎｇｉｎｅｓ－ｐｕｓｈ－ｖｓ．－ｐｕｌｌ／

【非特許文献31】ｈｔｔｐｓ：／／ｗｗｗ．ｗ３．ｏｒｇ／ＴＲ／２０１２／ＲＥＣ－ｒ２ｒｍｌ－２０１２０９２７／

【非特許文献32】ｈｔｔｐｓ：／／ｗｗｗ．ｗ３．ｏｒｇ／ＴＲ／ｒｄｂ－ｄｉｒｅｃｔ－ｍａｐｐｉｎｇ／

【非特許文献33】ｈｔｔｐｓ：／／ｗｗｗ．ｗ３．ｏｒｇ／ＴＲ／２０１２／ＲＥＣ－ｒ２ｒｍｌ－２０１２０９２７／＃ｎａｔｕｒａｌ－ｍａｐｐｉｎｇ

【非特許文献34】ｈｔｔｐｓ：／／ｅｎ．ｗｉｋｉｐｅｄｉａ．ｏｒｇ／ｗｉｋｉ／Ｍａｔｅｒｉａｌｉｚｅｄ＿ｖｉｅｗ

【非特許文献35】ｈｔｔｐｓ：／／ｃｌｏｕｄ．ｇｏｏｇｌｅ．ｃｏｍ／ｂｉｇｑｕｅｒｙ／ｄｏｃｓ／ｍａｔｅｒｉａｌｉｚｅｄ－ｖｉｅｗｓ－ｉｎｔｒｏ

【非特許文献36】ｈｔｔｐｓ：／／ｗｗｗ．ｗ３．ｏｒｇ／ＴＲ／ｒｄｆ－ｓｐａｒｑｌ－ｑｕｅｒｙ／＃ｄｏｃＲｅｓｕｌｔＤｅｓｃ

【発明の概要】

【0012】

したがって、リレーショナルデータおよびグラフデータを含むデータベース上でクエリエンジンによって問い合わせるためのコンピュータ実装方法が提供される。本方法は、クエリエンジンによってクエリを受信するステップであって、クエリは、一階論理パラダイムと互換性のある言語でのクエリである、ステップを含む。本方法は、中間表現（ＩＲ）を生成するステップであって、ＩＲは、一階論理パラダイムと互換性がある、ステップをさらに含む。次いで、本方法は、クエリの中間表現を使用して、データベースのリレーショナルデータおよびグラフデータに対してクエリを実行するステップを含む。

【0013】

本方法は、以下のうちの１つまたは複数を含むことが可能であり、すなわち、
－ クエリがＳＰＡＲＱＬクエリである場合、生成された中間表現はＳＰＡＲＱＬクエリの一階論理の述語計算に変換される、
－ クエリがＳＱＬクエリである場合、生成された中間表現はＳＱＬクエリの一階論理の述語計算に変換される、
－ データベースのリレーショナルデータは、１つもしくは複数のテーブルを含み、データベースのグラフデータは、１つもしくは複数の隣接行列を含む、
－ クエリは第１のＳＱＬクエリであり、クエリの中間表現を使用して、データベースのグラフデータに対してクエリを実行するステップは、データベースのグラフデータに対してＳＰＡＲＱＬ ＳＥＬＥＣＴクエリを実行して、それにより、タプルを出力するステップと、実行されたクエリのマテリアライズドビューを作成するステップと、作成されたマテリアライズドビューに対して第１のＳＱＬクエリを実行するステップとを含む、
－ 本方法は、第２のＳＱＬクエリを受信するステップをさらに含み、第２のＳＱＬクエリの実行は、第１のＳＱＬクエリの作成されたマテリアライズドビューに基づく、
－ マテリアライズドビューを作成するステップは、テーブルを作成するステップを含み、テーブルの行は、タプルに関連付けられ、テーブルの列は、クエリのそれぞれの変数に関連付けられる、および／または
－ 生成された中間表現は、少なくとも入力（input）を有する少なくとも１つの第１のＦＩＮＤ演算子を含み、本方法は、第１のｆｉｎｄ演算子を第２のｆｉｎｄ演算子に置き換えることによって、生成された中間表現を更新するステップをさらに含み、第２のｆｉｎｄ演算子は、上記入力がヌルのときに未定義値を返すように構成されている。

【0014】

受信されたクエリは、ＳＰＡＲＱＬまたはＳＱＬにおいて少なくとも１つのＪＯＩＮ句を有することができ、生成された中間表現は、以下の型のバッカス－ナウア記法（ＢＮＦ）文法で記述される：
<joined table> ::=
<cross join>
| <qualified join>
| <left paren> <joined table> <right paren>
<cross join> ::=
<table reference> CROSS JOIN <table reference>
<qualified join> ::=
<table reference> [ NATURAL ] [ <join type> ] JOIN <table reference>
[ <join specification> ]
<join type> ::=
INNER
| <outer join type> [ OUTER ]
| UNION
<outer join type> ::= LEFT | RIGHT | FULL
<join specification> ::= <join condition> | <named columns join>
<join condition> ::= ON <search condition>
<named columns join> ::= USING <left paren> <join column list> <right paren>
<join column list> ::= <column name list>

【0015】

受信されたクエリは、ＳＰＡＲＱＬまたはＳＱＬにおいてＦＲＯＭ句を有することができ、生成された中間表現は、以下の型のＢＮＦ文法で記述される：
<from clause> ::= FROM <table reference> [ { <comma> <table reference> }... ]
<table reference> ::=
<table name> [ <correlation specification> ]
| <derived table> <correlation specification>
| <joined table>

【0016】

ＦＲＯＭ句は、ＡＳ句を含むことができ、生成された中間表現は、以下の型のＢＮＦ文法で記述される：
<correlation specification> ::=
[ AS ] <correlation name> [ <left paren> <derived column list> <right paren> ]
<derived column list> ::= <column name list>

【0017】

受信されたクエリは、ＳＰＡＲＱＬまたはＳＱＬにおいてＷＨＥＲＥ句を有することができ、生成された中間表現は、以下の型のＢＮＦ文法で記述される：
<where clause> ::= WHERE <search condition>
<search condition> ::=
<boolean term>
| <search condition> OR <boolean term>
<boolean term> ::=
<boolean factor>
| <boolean term> AND <boolean factor>
<boolean factor> ::= [ NOT ] <boolean test>
<boolean test> ::= <boolean primary> [ IS [ NOT ] <truth value> ]
<boolean primary> ::= <predicate> | <left paren> <search condition> <right paren>
<predicate> ::=
<comparison predicate>
| <between predicate>
| <in predicate>
| <like predicate>
| <null predicate>
| <quantified comparison predicate>
| <exists predicate>
| <match predicate>
| <overlaps predicate>

【0018】

さらに、本方法を実行するための命令を含むコンピュータプログラムが提供される。

【0019】

さらに、コンピュータプログラムを記録したコンピュータ可読記憶媒体が提供される。

【0020】

さらに、メモリに結合されたプロセッサを備えたシステムであって、前記メモリがコンピュータプログラムを記録しているシステムが提供される。

【図面の簡単な説明】

【0021】

ここで、添付図面を参照して非限定的な例が説明される。

【図1】本方法の例のフローチャートである。

【図2】システムの例を示す図である。

【図3】本方法による中間表現の例を示す図である。

【図4】本方法による中間表現の例を示す図である。

【図5】本方法による中間表現の例を示す図である。

【図6】本方法による中間表現の例を示す図である。

【図7】本方法による中間表現の例を示す図である。

【図8】本方法による中間表現の例を示す図である。

【図9A】本方法による中間表現の例を示す図である。

【図9B】本方法による中間表現の例を示す図である。

【図10】本方法による中間表現の例を示す図である。

【図11】本方法による中間表現の例を示す図である。

【図12】本方法による中間表現の例を示す図である。

【図13】本方法による中間表現の例を示す図である。

【図14】本方法による中間表現の例を示す図である。

【発明を実施するための形態】

【0022】

図１のフローチャートを参照すると、リレーショナルデータおよびグラフデータを含むデータベース上でクエリエンジンによって問い合わせるためのコンピュータ実装方法であって、クエリエンジンによってクエリを受信するステップと、中間表現（ＩＲ）を生成するステップと、クエリの中間表現を使用して、データベースのリレーショナルデータおよびグラフデータに対してクエリを実行するステップとを含むコンピュータ実装方法が提案されている。クエリは、一階論理パラダイムと互換性のある言語でのクエリであり、ＩＲは、一階論理パラダイムと互換性がある。

【0023】

本方法は、リレーショナルデータおよびグラフデータを含むデータベースを提供する（すなわち、取得する）ステップをさらに含むことができる。そのような例では、本方法は、オンラインクラウドを使用してデータベースを取得すること、リモートサーバからデータベースをダウンロードすること、または永続メモリ上でデータベースにアクセスすることができる。

【0024】

そのような方法は、リレーショナルデータとグラフデータとの両方のタイプを含むデータベース上でクエリを実行することができる改良された解決策を提供する。本方法は、一階論理と互換性のある言語でクエリを受信することができ、リレーショナルデータ部分とグラフデータ部分との両方に対して実行される、このクエリからのそれぞれのＩＲを形成する。言い換えれば、本方法は、ポリグロットデータベース、すなわち、いくつかの言語をサポートするデータベースのための解決策を提供する。

【0025】

特に、本方法によって提供される解決策は、コードを複製する必要がなく、また、低レベル構文への任意の変換に基づくため、異なる最適化技術が（例えば、辞書符号化からのインデックスでの結合に）適用され得る。さらに、そのような解決策では、グラフデータとリレーショナルデータの各々が、それらの本来のフォーマットで提示され得る。他方で、本方法はエミュレーションをしないので、エミュレーションの欠点、すなわち、達成困難な意味的互換性、および基礎となるモデルの追加制約を回避している。特に、本方法は、スキーマに依存しないので、データフォーマットにおける大きな柔軟性を提供し、それにより、本方法は、非構造化データを効率的に問い合わせることができる。

【0026】

クエリ、例えば、受信されたクエリは、読取りクエリ（例えば、ＳＥＬＥＣＴ）を意味する。「データベース」とは、検索（search）および取出し（retrieval）のために編成されたデータ（すなわち情報）の任意のコレクション（例えば、グラフ指向データベース）を意味する。データベースは分散されていることも、分散されていないこともある。当技術分野で知られているように、グラフ指向データベースは、グラフ理論を使用したオブジェクト指向データベースであり、したがって、ノードおよび弧を有し、データが表現および格納されることを可能にする。グラフは、ストア内のデータアイテムを、ノードとエッジのコレクションに関係付け、エッジは、ノード間の関係を表している。こうした関係は、ストア内のデータが互いに直接リンクされることを可能にし、多くの場合、１つの操作でデータが取り出されることを可能にする。グラフデータベースは、暗黙の接続によってデータをリンクする他のデータベースモデル（例えば、リレーショナルデータベース）とは対照的に、データ間の関係を優先的に保持する。メモリ（例えば、永続メモリ）上に格納された場合、グラフデータベースは、コンピュータによる迅速な検索および取出しを可能にする。特に、グラフデータベースは、様々なデータ処理操作と関連して、関係の高速な取出し、修正、および削除をするために構造化されている。グラフ指向データベースはグラフデータベースとも呼ばれ、「グラフ指向データベース」と「グラフデータベース」という表現は同義語である。

【0027】

例では、グラフデータベースはＲＤＦグラフデータベースであり得る。ＲＤＦグラフは、グラフの格納および取出しに使用される従来のデータモデルである。ＲＤＦグラフは、有向のラベル付きグラフデータフォーマットである。そのようなフォーマットは、ウェブにおいて情報を表現するために広く使用されている。グラフとして情報のＲＤＦ表現を指定するための標準仕様がＷ３Ｃによって公表されている（例えば、非特許文献６参照）。ＲＤＦグラフデータベースは何十億のタプルを有することがあり、例えば、Ｕｎｉｐｒｏｔデータセットはタンパク質配列および機能情報のリソースである。

【0028】

使用される抽象構文のコア構造は、タプルのセットであり、各タプルは述語を含む。そのようなＲＤＦタプルのセットはＲＤＦグラフと呼ばれる。

【0029】

例では、ＲＤＦタプルは、ノードおよびエッジを含む３つまたは４つの要素を含むことがある。例では、各ＲＤＦタプル（または各ＲＤＦタプルの要素）は、主語、述部、および目的語を含むトリプルであり得る。そのような例では、ＲＤＦグラフは、ノードおよび有向弧図として視覚化されてよく、そこでは、各トリプルは、ノード－弧－ノードリンクとして表される。あるいは、ＲＤＦトリプルは、主語と目的語である２つのノードと、それらを接続する述語である弧によって視覚化されてよい。

【0030】

例では、ＲＤＦタプルは、ＲＤＦクワッドであり得る。ＲＤＦクワッドは、ＲＤＦトリプルにグラフラベルを加えることによって得られる場合がある。そのような例では、ＲＤＦタプルはＲＤＦグラフを含む。ＲＤＦクワッド（Ｎ－Ｑｕａｄｓとも呼ばれる）を指定するための標準仕様がＷ３Ｃによって公表されている（例えば、非特許文献７参照）。ＲＤＦクワッドは、ＲＤＦトリプルにグラフ名を追加することで得られる場合がある。グラフ名は、空（すなわち、デフォルトもしくは無名グラフ）またはＩＲＩ（すなわち、グラフＩＲＩのいずれかであってよい。例では、グラフの述語はグラフＩＲＩと同じＩＲＩを有することがある。各クワッドのグラフ名は、該当するＲＤＦデータセットにおいてそのクワッドが部分であるグラフである。ＲＤＦデータセットは、それ自体知られているように、グラフのコレクションを表す（例えば、非特許文献８参照）。以下では、ＲＤＦタプル（またはタプル）という用語は、一方または他方の使用が明示的に言及されていない限り、ＲＤＦトリプルまたはＲＤＦクワッドを無差別に指す。

【0031】

グラフデータベースのクエリエンジンについて可能な最適化は、グラフデータベースが開世界（Open World）または閉世界（Closed World）と相互作用しているという仮定に影響される。それ自体知られているように、知識表現に使用される論理の形式的体系において、開世界仮説（ＯＷＡ）とは、文の真理値は、それが真であると知られているかどうかにかかわらず真であり得るという仮定である。これは、真であるいかなる文も真であることが知られていることが成り立つ閉世界仮説の逆である。他方で、閉世界システムでは、すべてのものを配置するために場所を必要とする（例えば、フレーム上のスロット、ＯＯクラス上のフィールド、またはＤＢ内の列）。ＯＷＡは、デフォルトで不完全な情報を仮定しており、意図的に不完全な指定をして、他者が再利用および拡張することを可能にする。セマンティックウェブは、再利用可能な形式の分散された知識およびデータである、コンピュータに理解可能なウェブの構想であり、ＲＤＦは、セマンティックウェブについてのＷ３Ｃ勧告であり、開世界仮説に従っている。それは、データモデル化およびデータ格納における柔軟性を高めることを可能にする。しかし、ＳＱＬを用いたリレーショナルモデルと同様に、閉世界仮説の制約は、どのようにデータが格納されるかについてより多くの情報を提供するので、クエリ最適化にとって有用である。例では、クエリはＳＰＡＲＱＬクエリである。ＳＰＡＲＱＬは、ＲＤＦデータの問い合わせについてのＷ３Ｃ勧告であり、ＲＤＦトリプルのパターン上に構築されたグラフマッチング言語である。後述されるＳＰＡＲＱＬクエリでは、読取りクエリは、ＳＥＬＥＣＴ、ＡＳＫ、ＤＥＳＣＲＩＢＥ、ＣＯＮＳＴＲＵＣＴであり得る（非特許文献９参照）。「ＲＤＦタプルのパターン」は、ＲＤＦグラフによって形成されるパターン／テンプレートを意味する。言い換えれば、ＲＤＦタプルのパターンは、ＲＤＦグラフ（すなわち、ＲＤＦトリプルのセット）であり、そこでは、グラフの主語、述部、目的語、またはラベルが（クエリのための）変数で置き換えられることが可能である。ＳＰＡＲＱＬは、データがＲＤＦとしてネイティブに格納されるか、またはミドルウェアを介してＲＤＦとして見られるかにかかわらず、多様なデータソースわたってクエリを表現することができるＲＤＦデータ用のクエリ言語である。ＳＰＡＲＱＬは主にグラフ準同型に基づいている。グラフ準同型は、２つのグラフの間のそれらの構造を尊重するマッピングである。より具体的には、隣接する頂点を隣接する頂点に対してマッピングする、２つのグラフの頂点セット間の関数である。

【0032】

ＳＰＡＲＱＬは、必要とされるグラフパターンおよび任意選択のグラフパターンをそれらの論理積および論理和と共に問い合わせる能力を含む。ＳＰＡＲＱＬはまた、集約、サブクエリ、否定、式による値の生成、拡張可能な値テスト、およびソースＲＤＦグラフによるクエリの制約もサポートする。これは、ＳＰＡＲＱＬクエリが、ＳＰＡＲＱＬにおいて可能な８つの異なるトリプルパターンに対して応答する必要があることを意味する。そのような８つのトリプルパターンは、（Ｓ，Ｐ，Ｏ）、（Ｓ，？Ｐ，Ｏ）、（Ｓ，Ｐ，？Ｏ）、（Ｓ，？Ｐ，？Ｏ）、（？Ｓ，Ｐ，Ｏ）、（？Ｓ，？Ｐ，Ｏ）、（？Ｓ，Ｐ，？Ｏ）、および（？Ｓ，？Ｐ，？Ｏ）を含み、パターンにおいて変数に記号？が先行する。変数は、トリプルパターンの出力であり、ＳＰＡＲＱＬクエリの出力であり得る。いくつかの例では、変数は、ＳＥＬＥＣＴクエリの出力であり得る。ＳＰＡＲＱＬクエリの出力は、変数（例えば、合計などのアグリゲータ）を使用して構築され得る。クエリにおける変数は、グラフ準同型（すなわち、クエリの結果を取得するために必要な中間ノード）を構築するために使用され得る。いくつかの例では、クエリにおける変数は、出力にも中間結果にも使用されなくてよい。基本グラフパターン（ＢＧＰ）は、上述された８つのトリプルパターンのうちの１つであってよい。さらに、ＢＧＰは、クエリ変数としてグラフのラベルをさらに有するクワッドパターンであってもよい。本方法がタプルのグループの表現として１つまたは複数の隣接行列をそれぞれ取得する特定の例では、主語と目的語が１つの隣接行列上で問い合わされ得る。言い換えれば、これらの特定の例では、ＢＧＰは、（Ｓ，Ｏ）、（Ｓ，？Ｏ）、（？Ｓ，Ｏ）、および（？Ｓ，？Ｏ）のいずれかであり得る。ＳＰＡＲＱＬは、いくつかのＢＧＰおよび場合によっては他の演算子の結果を結合することによって、より複雑なクエリを構築し得る。したがって、競争力のあるＳＰＡＲＱＬエンジンは、少なくとも、高速なトリプルパターン解法および効率的な結合方法を必要とする。さらに、ＢＧＰにおいて結合される中間結果の量を最小化する効率的な実行プランを構築するために、クエリオプティマイザが必要とされる。

【0033】

例では、グラフデータベースが既存のトリプルストアを有する。トリプルストア（ＲＤＦストアとも呼ばれる）は、当技術分野で知られているように、セマンティッククエリを介したトリプルの格納および取出しのための専用データベースである。トリプルストアは、少なくとも、上述されたＳＰＡＲＱＬの８つの基本トリプルパターンに対して応答することができる。それは、トリプルパターンと共にフィルタリング制約（例えば、「ｘ＞５」）にも応答し得る。そのようなトリプルストアは、クエリエンジンによりＳＰＡＲＱＬクエリが実行されるストレージエンジンであると考えられる。ストレージエンジン（「データベースエンジン」とも呼ばれる）は、当技術分野で知られるように、データベースからデータの作成（Create）、読取り（Read）、更新（Update）および削除（Delete）（ＣＲＵＤ）をするためにデータベース管理システム（ＤＢＭＳ）が使用する基本的ソフトウェアコンポーネントである。

【0034】

当技術分野で知られているように、グラフデータベースの他に、リレーショナルデータベースが存在する。リレーショナルデータベースは、データのリレーショナルモデルに基づくデータベースである。リレーショナルモデルは、データを、列と行の１つまたは複数のテーブル（または「リレーション」）に編成し、一意のキーが各行を識別する。ＳＱＬは、リレーショナルデータベースの事実上標準の言語である。以下では、ＳＱＬの様々なバリエーションの中で、ＳＱＬ－９２標準（非特許文献１０参照）が意図され、これは、本方法によるクエリエンジンによってサポートされる厳密な最低レベルである。業界の大半はリレーションを取り入れており、表形式のリレーションには暗黙のスキーマがあり、それが、リレーショナルデータベースのテーブルからグラフデータベースのグラフへの移行（または変換）を複雑にしている。

【0035】

より一般的なデータベースの分野では、データベース理論の基礎は一階論理に基づいている。一階論理は、関係計算（ひいてはＳＱＬ）を構成するが、再帰はしない。

【0036】

図１に戻ると、ステップＳ１０において、本方法は、クエリエンジンによってクエリを受信するステップであって、クエリは、一階論理パラダイムと互換性のある言語でのクエリである、ステップを含んでいる。本方法は、任意の既知の方法に従ってクエリを受信してよい。「一階論理パラダイムと互換性のある言語」は、一階論理述語を使用してその構文が書き換えられることができる言語を意味する。それ自体知られているように、「一階論理」（一階述語計算または一階関数計算としても知られる）は、各文すなわちステートメントが、特定の要素間の関係を主張する述語に分解される記号化された推論である。例えば、述語は、主語の特性を修正または定義することができる。一階論理の構文は、定数記号のセット、関数記号のセット、および述語記号のセットからなるシグネチャに対して定義される。例では、クエリは、ＳＱＬ言語またはＳＰＡＲＱＬ言語でのクエリであり得る。

【0037】

本方法は、次いで、ステップＳ２０において、中間表現（ＩＲ）を生成する。データベース管理およびコンピュータ科学の分野で知られているように、ＩＲはクエリに対応する演算子の有向非巡回グラフ（Direct Acyclic Graph：ＤＡＧ）である。そのような演算子のＤＡＧ自体は、クエリのクエリプランに対応する。言い換えれば、演算子ＤＡＧは、「演算子」と呼ばれるノードが実行子の基本操作を表す、演算子のグラフである。さらに、「クエリプラン」または「クエリ実行プラン」は、（リレーショナルまたはグラフ）データベース管理システムにおけるデータにアクセスするために使用される一連のステップを意味する。それ自体知られているように、演算子のグラフは、ノード（すなわち頂点）およびエッジを含み、各ノードは演算子のシーケンス内の演算子に対応し、各エッジは、そのエッジによって接続された２つの演算子間のリレーションを定義する。演算子ＤＡＧは、単一のルート（すなわち、グラフの始点）および単一のリーフ（すなわち、グラフの終端）を有し得る。単一の葉は、ｅｍｉｔ演算子である。単一のルートおよび単一のリーフ以外で、演算子のグラフ内の他のノードの各々（すなわち、各演算子）は、先行するノードから入力を受信し、その出力を後続するノードに提供する。以下では、ＤＡＧおよびグラフという語は、演算子に適用されたとき、互換的に使用され得る。それ自体知られているように、演算子のそのようなグラフは、クエリエンジンによって生成されて実行可能である。実行は、一般にマルチスレッド化される。言い換えれば、タプルバッファ（すなわち、バッチにグループ化された各演算子によるタプルの形成されたストリームは、次の演算子によって直ちに消費され、または後で実行するためにキューに入れられることがあり、また、対応する演算子を実行する別のアイドルスレッドによって「盗まれる」（すなわち、引き継がれる）こともある。

【0038】

演算子のＤＡＧ内の演算子は、クエリ実行の基本要素に対応し、すなわち、各演算子は、タプルバッファ、すなわち、一般にバッファと呼ばれるバッチにグループ化されたタプルのストリームを生成する。次いで、各演算子のバッファは、ＤＡＧ内の次の演算子によって消費される。演算子実行は、基礎となるトリプルストアの呼出し、ＲＤＦターム（RDF Terms）での一般的な計算（すなわち、算術演算、文字列変換など）に対応する。ＲＤＦタームは、非特許文献１１に提示されている。ＳＱＬ事前定義データ型については、非特許文献１２を参照されたい。

【0039】

中間表現は、上述されたＤＡＧに加えて、ＩＲに含まれるすべての定数値およびインデックスを含む定数テーブルを備え、したがって、ＩＲは、それらを単純な整数によって参照することができる。これにより、計算コストのかかり得るＩＲ ＤＡＧ自体に何度も値を格納することを回避する。生成されたＩＲは、一階論理パラダイムと互換性がある。言い換えれば、生成されたＩＲは、一階論理構文を使用して書き換えられることが可能である。ＩＲの生成は、特に、クエリプランにおける構文解析ステップを含み得る。

【0040】

本方法は、ステップＳ３０において、クエリの中間表現を使用して、データベースのリレーショナルデータおよびグラフデータに対してクエリを実行する。言い換えれば、本方法は、クエリエンジンによってＤＡＧの基本演算子の各々を実行することができる。各基本演算子は、クエリエンジンによって１つまたは複数の呼出しに対して実行され、その結果、一般にバッファと呼ばれるバッチにグループ化されたタプルのストリームを形成することができる。その後、バッファは、ＤＡＧ内の次の演算子によって消費され得る。

【0041】

例では、（受信された）クエリがＳＰＡＲＱＬクエリである場合、生成された中間表現は、ＳＰＡＲＱＬクエリの一階論理の述語計算に変換され得る。例では、（受信された）クエリがＳＱＬクエリである場合、生成された中間表現は、ＳＱＬクエリの一階論理の述語計算に書き込まれ得る（すなわち、変換され得る）。言い換えれば、ＩＲは、一階セマンティックを使用する演算子から直接作られるので、本方法は、受信されたＳＰＡＲＱＬ／ＳＱＬクエリを解析し、次いで、一階論理の演算子を使用してＩＲを生成することができる。一階構文はＳＱＬとＳＰＡＲＱＬの両方の共通する基盤である。

【0042】

例では、データベースのリレーショナルデータは１つまたは複数のテーブルを含んでよく、データベースのグラフデータは、例えば垂直分割による、１つまたは複数の隣接行列を含んでよい。代替的または追加的に、データベースのグラフデータは、隣接行列の形式ではないグラフデータを含むことがある。これは、リレーショナルデータとグラフデータのクエリを統一して、それぞれの部分（すなわち、リレーショナルおよびグラフ）データベースをネイティブな形式で扱うことを可能にするという、改良された解決策を構成する。言い換えれば、本方法は、生成されたＩＲを使用して、任意の変換やエミュレーションを使用することなく、（例えば、テーブルの形式の）リレーショナルデータおよび（隣接行列またはグラフの形式の）グラフデータに対してクエリを実行することができる。

【0043】

例では、（受信された）クエリは、第１のＳＱＬクエリであってよく、クエリの中間表現を使用してデータベースのグラフデータに対してクエリを実行するステップは、データベースのグラフデータに対してＳＰＡＲＱＬ ＳＥＬＥＣＴクエリを実行して、それにより、タプルを出力するステップを含むことができる。次いで、本方法は、実行されたクエリのマテリアライズドビューを作成し、作成されたマテリアライズドビューに対して第１のＳＱＬクエリを実行することができる。これは、グラフデータベース上でＳＱＬクエリを高速かつ効率的に処理することができる改良された方法を構成する。言い換えれば、本方法は、データベース上のＳＰＡＲＱＬクエリの結果からマテリアライズドビューのテーブルを形成する。例では、マテリアライズドビューを作成するステップは、テーブルを作成するステップを含み、テーブルの行は、（出力された）タプルに関連付けられ、テーブルの列は、クエリのそれぞれの変数に関連付けられる。

【0044】

上記の例による方法は、第２のＳＱＬクエリを受信するステップをさらに含んでよく、第２のＳＱＬクエリの実行は、第１のＳＱＬクエリの作成されたマテリアライズドビューに基づく。それにより、本方法は、いくつかのＳＱＬクエリの作成されたマテリアライズドビューを使用することができる。これは、特にユーザとデータベースとの間のリアルタイムの対話が保証されるべきときに、クエリエンジンの性能を改善する。このような改善は、大規模データベースとのそのような対話を処理する際に特に重要である。そのような対話の使用事例については後で論じられる。

【0045】

本方法で受信されたＳＱＬクエリがＳＰＡＲＱＬ ＳＥＬＥＣＴクエリ用に開発されたＩＲによってどのように実行され得るかを提示するために、ＳＱＬのＳＥＬＥＣＴ文の例がここで説明される。これは、共通のＩＲがＳＱＬクエリとＳＰＡＲＱＬクエリの両方を実行し得ることを意味する。知られているように、ｓｅｌｅｃｔ文の論理的処理順序は、ＦＲＯＭ、ＯＮ、ＪＯＩＮ、ＷＨＥＲＥ、ＧＲＯＵＰ ＢＹ、ＨＡＶＩＮＧ、ＳＥＬＥＣＴ（クエリのｓｅｌｅｃｔ変数リスト句を適用する）、ＤＩＳＴＩＮＣＴ、ＯＲＤＥＲ ＢＹである。

【0046】

例では、受信されたクエリは、ＳＰＡＲＱＬまたはＳＱＬにおいて少なくとも１つのＪＯＩＮ句を有することができる。そのような例では、生成された中間表現は、以下の型のバッカス－ナウア記法（ＢＮＦ）文法で記述され得る：
<joined table> ::=
<cross join>
| <qualified join>
| <left paren> <joined table> <right paren>
<cross join> ::=
<table reference> CROSS JOIN <table reference>
<qualified join> ::=
<table reference> [ NATURAL ] [ <join type> ] JOIN <table reference>
[ <join specification> ]
<join type> ::=
INNER
| <outer join type> [ OUTER ]
| UNION
<outer join type> ::= LEFT | RIGHT | FULL
<join specification> ::= <join condition> | <named columns join>
<join condition> ::= ON <search condition>
<named columns join> ::= USING <left paren> <join column list> <right paren>
<join column list> ::= <column name list>

【0047】

例では、受信されたクエリは、ＳＰＡＲＱＬまたはＳＱＬにおいてＦＲＯＭ句を有することができる。そのような例では、生成された中間表現は、以下の型のＢＮＦ文法で記述される：
<from clause> ::= FROM <table reference> [ { <comma> <table reference> }... ]
<table reference> ::=
<table name> [ <correlation specification> ]
| <derived table> <correlation specification>
| <joined table>

【0048】

例では、ＦＲＯＭ句は、ＡＳ句を含むことができ、生成された中間表現は、以下の型のＢＮＦ文法で記述され得る：
<correlation specification> ::=
[ AS ] <correlation name> [ <left paren> <derived column list> <right paren>]
<derived column list> ::= <column name list>

【0049】

さらに例では、受信されたクエリは、ＳＰＡＲＱＬまたはＳＱＬにおいてＷＨＥＲＥ句を有することができ、生成された中間表現は、以下の型のＢＮＦ文法で記述され得る：
<where clause> ::= WHERE <search condition>
<search condition> ::=
<boolean term>
| <search condition> OR <boolean term>
<boolean term> ::=
<boolean factor>
| <boolean term> AND <boolean factor>
<boolean factor> ::= [ NOT ] <boolean test>
<boolean test> ::= <boolean primary> [ IS [ NOT ] <truth value> ]
<boolean primary> ::= <predicate> | <left paren> <search condition> <right paren>
<predicate> ::=
<comparison predicate>
| <between predicate>
| <in predicate>
| <like predicate>
| <null predicate>
| <quantified comparison predicate>
| <exists predicate>
| <match predicate>
| <overlaps predicate>

【0050】

「生成された中間表現は、バッカス－ナウア記法（ＢＮＦ）文法で記述される」は、ＳＱＬクエリに対して、ＩＲが、（ＳＱＬ文法である）ＢＮＦ文法から本方法によって生成され得ることを意味する。しかしながら、本方法によって生成されたＩＲは、上述されたように、ＳＱＬとＳＰＡＲＱＬと間の共通の一階論理であり、したがって、いったん生成されると、ＳＱＬクエリまたはＳＰＡＲＱＬクエリのいずれも実行することが可能である。

【0051】

例では、生成された中間表現は、少なくとも入力（input）を有する少なくとも１つの第１のＦＩＮＤ演算子を含むことができる。そのような例では、本方法は、第１のｆｉｎｄ演算子を第２のｆｉｎｄ演算子に置き換えることによって、生成された中間表現を更新するステップをさらに含むことができる。第２のｆｉｎｄ演算子は、上記入力がヌルのときに未定義値を返すように構成され得る。ＦＩＮＤ演算子に対する入力が、ＦＩＮＤ演算子の出力に対するフィルタ（すなわち条件）を形成することができる。これは、ＳＱＬとＳＰＡＲＱＬの規格の統一を改善する。より詳細に後述されるように、ＳＱＬにおける値はヌルになり得るが、ＳＰＡＲＱＬクエリの場合はそうではない。ＳＰＡＲＱＬクエリとＳＱＬクエリについてＩＲを統一するために、本方法はＮＯＴ ＮＵＬＬ制約を必要とし、ＮＵＬＬ（ヌル）と出力が存在しないこととの両方をＵＮＤＥＦ（未定義）として扱うか、または該当する入力がＵＮＤＥＦである場合にＵＮＤＥＦを出力するように入力を有するＦＩＮＤ演算子を修正する。

【0052】

本方法は、コンピュータに実装される。これは、本方法のステップ（または実質的にすべてのステップ）が、少なくとも１つのコンピュータまたは任意の同様のシステムによって実行されることを意味する。したがって、本方法のステップは、コンピュータによって、場合によっては完全に自動的に、または半自動的に実行される。例では、本方法の少なくともいくつかのステップのトリガは、ユーザとコンピュータの対話を通じて実行され得る。必要とされるユーザとコンピュータの対話のレベルは、予測される自動化のレベルに依存し、ユーザの希望を実装する必要性とバランスがとられてよい。例では、このレベルはユーザ定義および／または事前定義され得る。

【0053】

方法のコンピュータ実装の典型的な例は、この目的に適合されたシステムで方法を実行することである。システムは、メモリおよびグラフィカルユーザインターフェース（ＧＵＩ）に結合されたプロセッサを備えることができ、メモリは、本方法を実行するための命令を含むコンピュータプログラムを記録している。メモリはデータベースを格納することもできる。メモリは、そのような格納に適合された任意のハードウェアであり、場合によっては、いくつかの物理的に異なる部品（例えば、プログラム用に１つ、および場合によってはデータベース用に１つ）を備える。

【0054】

図２は、システムの例を示し、システムは、クライアントコンピュータシステム、例えば、ユーザのワークステーションである。

【0055】

この例のクライアントコンピュータは、内部通信バス１０００に接続された中央処理装置（ＣＰＵ）１０１０、さらにバスに接続されたランダムアクセスメモリ（ＲＡＭ）１０７０を含む。さらに、クライアントコンピュータは、バスに接続されたビデオランダムアクセスメモリ１１００に関連付けられたグラフィック処理装置（ＧＰＵ）１１１０が設けられている。ビデオＲＡＭ１１００は、当技術分野でフレームバッファとしても知られている。マスストレージデバイスコントローラ１０２０は、例えばハードドライブ１０３０などのマスメモリデバイスへのアクセスを管理する。コンピュータプログラム命令およびデータを有形に具現化するのに適したマスメモリデバイスは、すべての形態の不揮発性メモリを含み、例として、ＥＰＲＯＭ、ＥＥＰＲＯＭ、およびフラッシュメモリデバイスなどの半導体メモリデバイス、内蔵ハードディスクおよび取外し可能ディスクなどの磁気ディスク、ならびに光磁気ディスクを含む。上記のいずれも、特別に設計されたＡＳＩＣ（特定用途向け集積回路）に補完され、または組み込まれ得る。ネットワークアダプタ１０５０は、ネットワーク１０６０へのアクセスを管理する。クライアントコンピュータは、カーソル制御デバイスまたはキーボードなどのハプティックデバイス１０９０を含むこともできる。カーソル制御デバイスは、クライアントコンピュータにおいて、ユーザがディスプレイ１０８０上の任意の所望の位置にカーソルを選択的に配置できるように使用される。加えて、カーソル制御デバイスは、ユーザが様々なコマンドを選択し制御信号を入力することを可能にする。カーソル制御デバイスは、システムに制御信号を入力するためのいくつかの信号生成デバイスを含む。典型的には、カーソル制御デバイスはマウスであり、マウスのボタンが、信号を生成するために使用されることがある。代替的または追加的に、クライアントコンピュータシステムは、センシティブパッドおよび／またはセンシティブスクリーンを備えることができる。

【0056】

コンピュータプログラムは、コンピュータによって実行可能な命令を含むことができ、命令は、上記システムに方法を実行させるための手段を含む。プログラムは、システムのメモリを含む任意のデータ記憶媒体に記録可能であり得る。プログラムは、例えば、デジタル電子回路、もしくはコンピュータハードウェア、ファームウェア、ソフトウェア、またはそれらの組み合わせに実装され得る。プログラムは、装置として、例えば、プログラマブルプロセッサによる実行のために機械可読ストレージデバイスに有形に具現化された製品として実装され得る。方法ステップは、入力データを操作して出力を生成することによって方法の機能を実行する命令のプログラムをプログラマブルプロセッサが実行することによって実行され得る。したがって、プロセッサは、データストレージシステム、少なくとも１つの入力デバイス、および少なくとも１つの出力デバイスからデータおよび命令を受信し、またそれらにデータおよび命令を送信するように、プログラム可能に結合され得る。アプリケーションプログラムは、高水準手続きプログラミング言語もしくはオブジェクト指向プログラミング言語で、または必要に応じてアセンブリ言語もしくは機械言語で実装され得る。いずれの場合も、言語はコンパイル言語またはインタプリタ言語であり得る。プログラムは、完全インストールプログラムまたは更新プログラムであり得る。いずれの場合も、システムへのプログラムの適用が、本方法を実行するための命令をもたらす。あるいは、コンピュータプログラムは、クラウドコンピューティング環境のサーバに格納され実行されてもよく、サーバは、１つまたは複数のクライアントとネットワークを介して通信する。そのような場合、処理ユニットは、プログラムに含まれる命令を実行し、それにより、クラウドコンピューティング環境上で本方法が実行されるようにする。

【0057】

ここで、本方法の上述された例の実装が論じられる。

【0058】

実装は、同じデータベース内のリレーショナルデータとグラフデータを問い合わせる方法に関係付けられる。それにより、実装は、１つのデータベースから構造化データ（例えば、リレーショナル）と非構造化データ（例えば、グラフ）を問い合わせる必要性に応える。特に、実装は、先行技術におけるそれらの一般的な技術的課題、すなわち、データ変換コスト、クエリ実行時間オーバーヘッド、変換されたクエリの高い複雑性、および非構造化データに対するサポートの欠如に関する、ポリグロット（polyglot）データベースのための解決策に関係付けられる。言い換えれば、実装は、構造化データと非構造化データの両方のサポートを提供しながら、データ変換やエミュレーションなしに、単一のクエリエンジン内でグラフデータとリレーショナルデータの両方を問い合わせることを可能にする。実装は、特に、読取りクエリ、例えば、ＳＥＬＥＣＴクエリに関係付けられ得る。

【0059】

実装によれば、データベースは、（例えば、隣接行列の形式の）非構造化データおよび（例えば、テーブルの形式の）構造化データのためのデータ構造を備える。

【0060】

これらのパラダイムの両方が、一階論理（非特許文献１３参照）に基づいている。したがって、ＳＱＬクエリおよびＳＰＡＲＱＬクエリは、両方のパラダイムで意味を有する中間表現を使用して、一階論理の述語計算に変換される。

【0061】

リレーショナルデータとグラフデータの両方は、それらのネイティブデータ構造を使用して（変換やエミュレーションなしで）表される。クエリエンジンは、両方のパラダイムで理解可能な中間表現を使用して統一され、それにより、ＳＱＬからＳＰＡＲＱＬ（またはその逆）の複雑なクエリ変換やエミュレーションを回避する。

【0062】

詳細には後述されるように、ＳＰＡＲＱＬと否定を伴う非再帰的で安全なＤａｔａｌｏｇとは、同等の表現力を有し、したがって、古典的な結果により、ＳＰＡＲＱＬは表現力の観点から関係代数と同等である。リレーショナルモデル（ＲＭ）は、すべてのデータがタプルで表現されリレーションにグループ化される一階述語論理と一致する構造および言語を使用してデータを管理する手法として定義され得る。リレーショナルモデルの観点から編成されたデータベースが、リレーショナルデータベースである。リレーショナルモデルの目的は、データおよびクエリを指定するための宣言的な方法を提供することである。言い換えれば、データベースがどんな情報を含み、ユーザがどんな情報をそれから欲しているかを、ユーザが直接宣言する場である（非特許文献１４参照）。知られているように、Ｄａｔａｌｏｇは宣言型論理プログラミング言語であり、構文的にはＰｒｏｌｏｇのサブセットである。それは、演繹データベース用のクエリ言語としてよく使用される。有限集合上のＤａｔａｌｏｇクエリは、終了することが保証されている。Ｄａｔａｌｏｇによるクエリ評価は一階論理に基づいており、したがって、健全で完全である。

【0063】

ＳＱＬとＳＰＡＲＱＬが両方とも宣言型言語であることは、それらを同じ論理表現に変換するのに役立つ。リレーショナルモデルが構築される一階述語論理（非特許文献１３参照）は、以下の通りである。

【0064】

一階論理は、非論理オブジェクトに対して量化された変数を使用し、変数を含む文の使用を可能にし、したがって、「ソクラテスは人間である」のような命題ではなく、「ｘはソクラテスでありｘは人間であるようなｘが存在する」という形式の表現が可能であり、「存在する（there exists）」は量化子であり、ｘは変数である。言い換えれば、ＳＱＬクエリを、タプルの集合（この集合内の所与のキーによってインデックス付けされる）において述語論理（すなわち「存在する」という量化子）を使用する宣言的方法としてみることができる。この量化子は次のように定義できる：
リレーションＲにおいて属性Ａに対して値Ｖを有するキーＫによってインデックス付けされたタプルが存在する（There Exists）。

【0065】

（上記の「ソクラテス」定義に見られるように）キー、値、および属性はすべて変数とすることができることに留意されたい。

【0066】

集合論（ＳＱＬ）からグラフ理論（ＳＰＡＲＱＬ）に切り替えると、ＳＰＡＲＱＬの基本グラフパターン（非特許文献１５参照）に沿って以下を描くことができる：
グラフＧにおいて述語Ｐについての目的語Ｏを有する主語Ｓのトリプルが存在する（There Exists）。

【0067】

主語、述語、および目的語はすべて変数にも（さらにグラフにも）なり得る。この量化子は、実装によるクエリエンジンの基礎となる。この量化は、以下では、等価的にＦｉｎｄと呼ばれる。したがって、上記の文は、次のようになる：
グラフＧにおいて述語Ｐについての目的語Ｏを有する主語ＳのトリプルをＦｉｎｄする。

【0068】

ＳＱＬの場合：
リレーションＲにおいて属性Ａについての値Ｖを有するキーＫによってインデックス付けされたタプルをＦｉｎｄする、
またはＳＱＬにおいてより一般的に使用されている用語を使用する：
テーブルＴにおいて列Ａについての値Ｖを有する主キーＫによってインデックス付けされた行をＦｉｎｄする。

【0069】

このＦｉｎｄ量化子は、クエリの抽象基本木（ＡＳＴ）から生成された中間表現（ＩＲ）の基本演算子でもある。一階述語論理の「存在する」量化子と並列に描くことにより、それは、リレーショナルモデルとグラフモデルの両方の共通する基礎となっている。これにより、実装は、同じクエリエンジンでリレーショナルデータとグラフデータの両方に問い合わせることができるようになる。

【0070】

特に、実装は（非特許文献１６におけるような）「ＳＰＡＲＱＬからＳＱＬ」または「ＳＱＬからＳＰＡＲＱＬ」の変換を行うのではなく、ＩＲによって実装された共通表現で両者の表現をする。

【0071】

リレーショナルデータはテーブルとして表現され、グラフデータは隣接行列として表現される。それらは、両方とも一級市民であり、同じ辞書符号化で圧縮され得る。同じデータベース内にあるとき、ＳＰＡＲＱＬクエリの結果からテーブルが作成された場合、隣接行列のグラフデータの修正は、表データへ容易に伝搬され得る。

【0072】

エミュレーションがなく、実装はグラフデータベース内にテーブルを作成し問い合わせることができ、それはグラフクエリに使用されるのと同じクエリエンジンを使用する。結果として、良好な性能でグラフデータと表データを結合するクエリを行うことが可能である。当技術分野で議論されている方法とは対照的に、表データは外部データから毎回フェッチされてはならず、データベース内の最適化（例えば、辞書符号化）およびデータの鮮度の利益を得ることができる。

【0073】

実装は、コードの重複を伴うグラフと表データのための統一されたクエリエンジンに関する解決策を提供し、例えば、（ハッシュテーブルがデータベースからの組み込みであることを除いて、ハッシュ結合（非特許文献１７参照）と同じ精神の）辞書符号化からもたらされるインデックスに基づく結合のような可能な最適化を有する。これらの解決策は、表データがエミュレートされず、ページネーションに使用されるときの制限が伴わないので、さらに有利である。さらに、実施例による表データはグラフデータに変換も複製もされず、これは、例えばマッピング変換を伴う解決策と比較して、使用されるストレージが少ないことを示唆する。実装は、グラフクエリ結果からマテリアライズドビューを作成することも可能にし、結果として、それがグラフデータベース内で問い合わせされ得る。

【0074】

データベース内の論理
次に、実装の理論的側面について論じられる。

【0075】

それ自体知られているように（例えば、参照により本明細書に組み込まれる非特許文献１８および／または非特許文献１９）、関係代数と否定を伴う非再帰的で安全なＤａｔａｌｏｇとは、同じ表現力を有する（すなわち、それらはクエリの全く同じセットを表現する）。ＡｎｇｌｅｓおよびＧｕｔｉｅｒｒｅｚの非特許文献１９がさらに示すように、以下の定理の形式でＳＰＡＲＱＬも同じ表現力を有する：
定理．ＳＰＡＲＱＬは、バッグセマンティクス（bag semantics）のもとで関係代数と同じ表現力を有する。

【0076】

上で引用された定理の証明は、関係代数と否定を伴う非再帰的で安全Ｄａｔａｌｏｇとが同じ表現力を有するという事実に基づいている。「バッグ」は、マルチセット、すなわち、スキーマに応じて同じタプルの複数のコピーを潜在的に含むセットを意味する（例えば、非特許文献２０参照）。

【0077】

実装は、特に、一階論理、または、言い換えれば、否定を伴う非再帰的で安全なＤａｔａｌｏｇが、ＳＰＡＲＱＬとＳＱＬの両方の基礎となる理論的根拠であるという事実を利用している。それにより、実装は、一階論理でクエリの実行を表現することにより、ＳＰＡＲＱＬとＳＱＬの両方に対処する。

【0078】

（ＲＤＦの意味でなく一階論理の意味で）基本述語は、ＳＱＬ言語とＳＰＡＲＱＬ言語の両方で、ＩＲのＦｉｎｄ演算子と等価な存在識別子（すなわち、∃）である。言い換えれば、ＳＰＡＲＱＬの場合、それは次のようになる：
グラフＧにおいて述語Ｐについての目的語Ｏを有する主語ＳのトリプルをＦｉｎｄする。

【0079】

ＳＰＡＲＱＬにおけるＦｉｎｄ基本述語は、上述されたように基本グラフパターン（非特許文献２１参照）と呼ばれる。他方で、ＳＱＬの場合、それは次のようになる：
テーブルＴにおいて列Ａについての値Ｖを有する主キーＫによってインデックス付けされた行をＦｉｎｄする。

【0080】

ＳＱＬにおけるＦｉｎｄ基本述語は、射影（非特許文献２２参照）と呼ばれる。

【0081】

ＲＤＦにはスキーマがないため、実装によるクエリエンジンはデータ形式に対して非常に柔軟である。上述された「Ｆｉｎｄ」演算子は、そのようなクエリエンジンでデータをフェッチするための基本単位である。「Ｆｉｎｄ」演算子があれば、実行の残りは、演算子のグラフの論理処理である。

【0082】

上述されたようにＳＰＡＲＱＬとＳＱＬは同じ表現力を有するので、共通の論理処理を有している。詳細には後述されるように、実装は、ＳＰＡＲＱＬ用に開発されたクエリエンジンＩＲを使用して、ＳＰＡＲＱＬクエリと同様にＳＱＬクエリも実行することができる。

【0083】

次に、ＳＱＬに関する実装の態様について論じられる。

【0084】

実装は、少なくともＳＱＬ－９２標準（非特許文献１０参照）をサポートするクエリエンジンが採用され得る。すべてのＳＱＬクエリエンジンが最新の標準（最新は２０１６年）例えば、非特許文献２３）をサポートしているわけではないので、この低い要件により、実装はより広い適用範囲を有することになる。

【0085】

ＳＱＬとＳＰＡＲＱＬの違いの１つは、ＳＱＬにはスキーマ（すなわち、暗黙のスキーム（implicit schemes））があることである。「暗黙のスキーマ（implicit schema）」は、主にワイルドカード＊の使用により、スキーマがクエリにおいて暗黙であることを意味する。言い換えれば、テーブルのすべての列を取得することおよび他の同様の要求は、これらのメタデータをデータベース内に保持することによって応答される。

【0086】

さらに、ＳＱＬにおける値はヌルとなり得る。ＳＱＬでのヌル値は、実際の値とみなされない。これは、Ｃ１を主キーとする以下の表１では、次の質問：
テーブルＴ０において列Ｃ２についての値Ｖを有する主キー２０によってインデックス付けされた行をＦｉｎｄする
に対する答えは、ヌルであり、一方、次の質問：
テーブルＴ０において列Ｃ２についての値Ｖを有する主キー４２によってインデックス付けされた行をＦｉｎｄする
に対する答えは存在しないことを意味する。

【0087】

【表1】

【0088】

しかしながら、両方の質問に対して、クエリエンジンとストレージの間のプロトコルでは、非特許文献２４に定義されるように、答えはＵＮＤＥＦ（「変数は値を有しない」ことを意味し、「境界のない値」とも定義される）である。このアプローチは、ストレージがすべてのヌル値を実体化しないようにすること、列間のヌル値に対するＪＯＩＮ演算子を許可しないようにすること、および外部結合でヌル値を追加するためにＩＲノードを追加する必要性をなくすことに役立つ。これはまた、既に引用された非特許文献１９における、ＳＰＡＲＱＬと関係代数の表現力が同じであることを保証するための選択と一致する。

【0089】

実装によれば、ＩＲはヌル伝搬を管理し、つまり、変数が「ヌル」であるという事実は、ＩＲによって演算子のすべてのＤＡＧに伝搬される。

【0090】

実装はさらに、ＳＱＬパーサおよびＳＱＬ抽象構文木（ＡＳＴ）をクエリエンジンに組み込んでいる。これは、当技術分野で知られている方法（例えば、非特許文献２５）に従って行われてよい。

【0091】

次に、ＩＲとその表記法を提示するために表２に関して例が考察される：

【0092】

【表2】

【0093】

ごく基本的なＳＱＬ文は、テーブルからすべての行をフェッチしてユーザに返すクエリである。言い換えれば、次のようになる：
ＳＥＬＥＣＴ ＊
ＦＲＯＭ Ｔ１
このクエリは、単純にテーブルＴ１からすべての行をフェッチする。クエリエンジンは、Ｔ１テーブルのすべての列名をストレージに要求することで開始し、｛Ｃ１，Ｃ２｝を入手する。また、ここではＣ１である主キーに対応する列も要求する。ＳＥＬＥＣＴ句とＦＲＯＭ句については後述される。

【0094】

ＳＱＬ文を論理ＩＲに変換するために、実装は上述された量化子を次のように使用する：
テーブルＴにおいて属性についての値Ｖを有する主キーＫによってインデックス付けされた行をＦｉｎｄする。

【0095】

図３は、ＩＲ表記法を使用するＳＱＬクエリを提示する。図３は、実行それ自体を説明しているのではなく、ＩＲ、すなわち実行される演算子の流れを説明している。（Ｏｐ＃１）は、ＩＲ演算子および参照事項のための任意選択の識別子である。言い換えれば、それは実行のいかなる順序も意味しない。ワイルドカード＊は、演算子によって生成された変数を表し、それらの名前は出力（output）［ｉ０，ｉ１］で与えられ、これはＳＥＬＥＣＴ句の変数ではなく、列インデックスである。この表記法において、列インデックスは、ｉプレフィックスで提示され、ｖは値を参照するために使用される。この表記法において、クエリの定数（すなわち、変数／列インデックスではない）は、リテラルでは引用符（「．．．」）の間にあり、それ以外では＜．．．＞の間にある。

【0096】

図４は、列Ｃ２の値をフェッチするのに必要とされる演算子を提示する。演算子（Ｏｐ＃２）は、行の主キーを表す変数ｉ０を入力（input）として取り、所与の行のすべての値を一緒にグループ化するために必要とされる。このステップまでは、インデックスのみが使用されている。

【0097】

図５は、実際の値を取得し、それを出力（emit）して結果のレコードを作成することを提示する。これで実行のフローを完了させる。

【0098】

実装は、以下に従って実行のフローを実行する。演算子（Ｏｐ＃１）は、入力がなく、表３に従って２つの行についての列Ｃ１におけるキーおよび値を出力する。

【0099】

【表3】

【0100】

この例では、整数のみが存在するため、インデックスを値として考えることができる。次に、演算子（Ｏｐ＃２）が｛ｉ０，ｉ１｝を入力とし、Ｃ２の対応する値をｆｉｎｄするために入力列ｉ０を主キーとして使用する。その出力は、ｉ２と呼ばれる結果列に追加されたＣ２の値である。以降のステップでは、ｉ０は不要となり、実装はそれを保持しない。出力は表４に従う。

【0101】

【表4】

【0102】

（Ｏｐ＃３）ＧｅｔＶａｌｕｅの役割は、インデックスを値に変換することである。この例では、インデックスは値と同じとみなされるので、ＧｅｔＶａｌｕｅはｎｏ－ｏｐである。最後の演算子（Ｏｐ＃４）は、レコードを作成して呼出し元のアプリケーションコードに渡すポストプロセッサに、値を出力するものである。

【0103】

図６は、図５に提示されたＩＲの別バージョンを、簡略化された表記法を使用して提示する。この簡略化された表記法は以下で使用される。

【0104】

ヌル値でＦｉｎｄする
上記のようにすべての行がＮＯＴ ＮＵＬＬ制約で作成されなくてよい例において、いずれのＦｉｎｄもｕｎｄｅｆ値（未定義値）を生成することができる。Ｆｉｎｄは入力としてｕｎｄｅｆを有することができないので、実装は、入力を有する任意のＦｉｎｄを、ｉｆ ｕｎｄｅｆ条件を有するオプションのＦｉｎｄで置き換える。言い換えれば、オプションのＦｉｎｄは、値が見つけ出されない場合（すなわち、ヌルとｕｎｄｅｆが等しいとみなされるため、ヌルの場合）を管理し、ｉｆ ｕｎｄｅｆ条件は、ｕｎｄｅｆ入力をフィルタリングする。

【0105】

例えば、図７はＩＲグラフを示す。実装は、図７のＩＲグラフを図８の対応するもので置き換える。言い換えれば、これらの実装によるＩＲは、Ｆｉｎｄ演算子への入力がｕｎｄｅｆの場合、ｕｎｄｅｆを出力するように置き換えられる。図８の「ＦｉｎｄＯｐｔｉｏｎａｌ」演算子は、「Ｆｉｎｄ」演算子と同じであり得る。

【0106】

図９Ａ～図９Ｂは、演算子のＤＡＧを最適化する新しいノード「ＦｉｎｄＩｆＤｅｆ」をＩＲに導入することによるＩＲグラフの単純化を示す。そのような演算子の最適化されたＤＡＧは、ＩＲ内のノードがより少なくなり得る。したがって、使用される列がＮＯＴ ＮＵＬＬ制約で作成されない場合、実装は、入力を有する任意の「Ｆｉｎｄ」演算子をＦｉｎｄＩｆＤｅｆで置き換えることができる。以下では、そのような「Ｆｉｎｄ」演算子の各々が「ＦｉｎｄＩｆＤｅｆ」としても解釈されるべきである。これは、ＩＲグラフのセマンティックを変更しない。さらに、「ｉ０ ｉｓ ｕｎｄｅｆ」は、ＩＲにおける「ＦｉｌｔｅｒＢｏｕｎｄ」と呼ばれる演算子である。

【0107】

ＳＱＬ文：クエリ仕様
以下では、ＳＱＬのクエリ仕様（すなわち、ＳＥＬＥＣＴ文）に関係付けられた実装の例について論じられる。そのような例は、ＳＱＬ文からＩＲへの変換を詳細に示す。ｓｅｌｅｃｔ文の論理的処理順序は、ＦＲＯＭ、ＯＮ、ＪＯＩＮ、ＷＨＥＲＥ、ＧＲＯＵＰ ＢＹ、ＨＡＶＩＮＧ、ＳＥＬＥＣＴ、ＤＩＳＴＩＮＣＴ、ＯＲＤＥＲ ＢＹである（非特許文献２６参照）。この順序が、１つのステップで定義されたオブジェクトが、後続のステップの句にいつ利用可能になるかを決定する。

【0108】

例は、非特許文献２７の標準におけるＢＮＦ表現形式に基づいて提示されている。ＳＥＬＥＣＴクエリは、この標準に従って次のように記述され得る：
<query specification> ::=
SELECT [ <set quantifier> ] <select list> <table expression>
ＦＲＯＭ：テーブル式
テーブル式は、ベーステーブル（すなわち、データベースに物理的に格納されているもの）、マテリアライズドビュー（ＳＱＬでは、より一般的に「ビュー」と呼ばれる）、または他の句（例えば、ｊｏｉｎ）からの出力として与えられる仮想テーブルのいずれかである。

【0109】

ＢＮＦ文法におけるテーブル式は、以下の通りである：
<table expression> ::=
<from clause>
[ <where clause> ]
[ <group by clause> ]
[ <having clause> ]
ＦＲＯＭ句は、この式では常に必要とされる。

【0110】

上述の順序の最初の６つの文すべて（すなわち、ＦＲＯＭ、ＯＮ、ＪＯＩＮ、ＷＨＥＲＥ、ＧＲＯＵＰ ＢＹ、ＨＡＶＩＮＧ）と同様に、上記式における各句は、入力を受け取り、出力を生成する演算子として機能する（それ自体知られており、例えば、非特許文献２８を参照されたい）。各句は仮想テーブルを生成し、ＦＲＯＭ句の入力は１つまたは複数のテーブル（例えば、ベーステーブルまたはビュー）である。このテーブル参照は、ＪＯＩＮ式（後述される）、テーブル名、括弧内のテーブル式のいずれかである。

【0111】

テーブル参照がテーブル名である場合、テーブル参照は任意選択でＡＳ句も含むことがある。テーブル参照がテーブル名である場合、テーブル参照はＡＳ句を含まなければならない。例えば、ＦＲＯＭ Ｔ ＡＳ ＭＹＴＡＢＬＥの場合、ＢＮＦは以下の通りである：
<from clause> ::= FROM <table reference> [ { <comma> <table reference> }... ]
<table reference> ::=
<table name> [ <correlation specification> ]
| <derived table> <correlation specification>
| <joined table>
<correlation specification> ::=
[ AS ] <correlation name> [ <left paren> <derived column list> <right paren> ]
<derived column list> ::= <column name list>

【0112】

上記の式では、ＡＳ句は構文糖衣（すなわち、構文的に任意選択）であり、省略されてよい。このＡＳ句は範囲変数を導入している。標準では相関名を使用するが、範囲変数はオーソドックスな用語であり、論理の意味で変数を意味する。論理の意味とは、通常のプログラミング言語の意味ではないということであり、その範囲は、いくらかのリレーションにおけるタプルのセット（ＳＱＬ用語では、いくらかのテーブルの行のセット）に及ぶ。この範囲変数は、上の例のように暗黙的に宣言されることが可能であり、その範囲は、テーブルのすべての行にわたる。この変数のスコープは、ＩＲにおいて変数決定性を定義するために重要である。決定的変数は、後でクエリによりトリプルパターンによって読み込まれる変数である。この変数のスコープは次のように定義される：テーブル参照がＦＲＯＭ句オペランドを表す場合、スコープはそのＦＲＯＭ句を直ちに含む選択式（すなわち、ＳＥＬＥＣＴ句、ＦＲＯＭ句自体、もしあればＷＨＥＲＥ句、もしあればＧＲＯＵＰ ＢＹ句、もしあればＨＡＶＩＮＧ句）であるが、別の範囲変数が同じ名前で導入される元の選択式内のいずれかにネストされる任意の選択式または結合式を除外する。

【0113】

したがって、実装はスコープを計算してＩＲ変数決定性を決定し（すなわち、ＩＲのどの変数が決定的であるかを決定し）、ＳＰＡＲＱＬのようにストレージから既存のテーブルに従ってテーブル名をフィルタリングする。

【0114】

ＦＲＯＭ句の上記のＢＮＦ文法：
<table reference> ::=
<table name> [ <correlation specification> ]
| <derived table> <correlation specification>
| <joined table>
においては、単純なテーブル名の後に派生されたテーブルおよび結合されたテーブルが来る。結合されたテーブルの例については後述される。

【0115】

ＪＯＩＮ，ＯＮ式
実装は、マテリアライズドビュー上でクエリを実行するために結合を必要としない。これは後述される使用事例でも同じで、ページネーションはＳＰＡＲＱＬクエリの結果によって作成されたビューだけを有する。

【0116】

それ自体知られているように、結合テーブル式は、２つのテーブル間のある種の明示的な結合を表し、その各々はテーブル参照によって表される（非特許文献２９参照）。より正確には、結合式はクロス結合か、明示的または暗黙的なｊｏｉｎ型を含む結合のいずれかである。

【0117】

これは、以下の文法に対応する：
<joined table> ::=
<cross join>
| <qualified join>
| <left paren> <joined table> <right paren>
<cross join> ::=
<table reference> CROSS JOIN <table reference>
<qualified join> ::=
<table reference> [ NATURAL ] [ <join type> ] JOIN <table reference>
[ <join specification> ]
<join type> ::=
INNER
| <outer join type> [ OUTER ]
| UNION
<outer join type> ::= LEFT | RIGHT | FULL
<join specification> ::= <join condition> | <named columns join>
<join condition> ::= ON <search condition>
<named columns join> ::= USING <left paren> <join column list> <right paren>
<join column list> ::= <column name list>

【0118】

Ｃｒｏｓｓ ｊｏｉｎ
第１の最も単純な結合はクロス結合で、これは単にデカルト積の別名である。Ａ ＣＲＯＳＳ ＪＯＩＮ Ｂという式は、ａｂがＡからの行ａとＢからの行ｂの連結であるように、すべての可能な行ａｂから構成されるテーブルを評価する。それは意味論的に以下に等しい。

【0119】

ＳＥＬＥＣＴ ＊
ＦＲＯＭ Ａ，Ｂ
Ｃｒｏｓｓ Ｊｏｉｎアルゴリズムは、両方のテーブルのすべての行を受け取り、デカルト積を行い、または言い換えれば、両方のリレーションのすべてのタプルを受け取り、デカルト積を行う。前述されたＦｉｎｄ演算子を使用して、次のように言い換えられ得る：
テーブルごとに、テーブルの各列について、すべての行をｆｉｎｄして、各テーブルの出力のデカルト積を行う必要がある。

【0120】

図１０は、列｛Ｃ１１，．．．，Ｃ１ｎ｝および｛Ｃ２１，．．．，Ｃ２ｎ｝を有するテーブルＴ１およびＴ２について、ＩＲ規約を使用する例を提示する。

【0121】

上述されたようにＩＲ実行はマルチスレッド化され得るので、実装は、Ｓｙｎｃｈｒｏｎｉｚｅ（同期化）演算子およびＢｕｆｆｅｒｉｚｅ（バッファ化）演算子を使用することがある。Ｓｙｎｃｈｒｏｎｉｚｅ Ｃａｒｔｅｓｉａｎ演算子は、他のすべてのスレッドが終了するまで待ってから、それらの出力をデカルトマネージャ（cartesian manager）にマージする。他のすべてのスレッドはそれらの結果をバッファリングし、したがって、Ｂｕｆｆｅｒｉｚｅ演算子である。ここで、ＣｒｅａｔｅＢｕｆｆｅｒ演算子は、ＢｕｆｆｅｒｉｚｅとＳｙｎｃｈｒｏｎｉｚｅ間の同期が行われるフラグｆ０を宣言する。これら３つの演算子は、ＳＰＡＲＱＬ ＯＰＴＩＯＮＡＬパターンについてのＳｙｎｃｈｒｏｎｉｚｅおよびＢｕｆｆｅｒｉｚｅのより複雑なバージョンであり、実装はＩＲにこれら３つを追加する必要があり得る。ＣｒｅａｔｅＢｕｆｆｅｒにより作成されたフラグは、ＳＰＡＲＱＬのＯＰＴＩＯＮＡＬによって使用されるものとは少し意味が異なる。実装では、ｓｙｎｃｈｒｏｎｉｚｅ Ｃａｒｔｅｓｉａｎステップを行う前にすべての結果をバッファリングすることを意味する。

【0122】

ＩＲにおいてＢｕｆｆｅｒｉｚｅ演算子を使用することは、Ｂｕｆｆｅｒｉｚｅが中間仮想テーブルを作成するので、すべての中間結果を仮想テーブルとして表現するというＳＱＬ哲学と一貫している。実装は、この演算子を効率的に実装することができる。

【0123】

実装は、デカルト積に必要とされる両方のテーブルのすべての中間結果メモリをメモリに保持しない可能性がある。ＩＲの実行がマルチスレッド化されると、実装は、結果の２つのストリーム間の同期メカニズムを使用し得る。実装のバリエーションでは、例えば次のようなデカルト積に似たＳＰＡＲＱＬクエリがあり得る：
SELECT ?a ?b
WHERE {
<x> <p> ?a .
<y> <q> ?b
}

【0124】

実装の別のバリエーション（コンピュータ科学の分野でのいわゆるＶｏｌｃａｎｏ（モデル）実装であり、例えば、非特許文献３０を参照）は、１番目の入力ごとに第２のパターンを再実行する。さらに、ＩＲに基づくベクトル化実装は、入力バッファによって第２のパターン（Ｆｉｎｄ演算子に対応する）を１回実行することにより、そのような実装を最適化する。

【0125】

これら２つのバリエーションでは、デカルト積に必要とされる中間結果はメモリに保持されないが、代償として第２の演算子が多数回実行される。２つのアルゴリズムは、ＣＰＵ、メモリ、および同期の間の通常のトレードオフを伴って可能である。言い換えれば、Ｖｏｌｃａｎｏ実装では、メモリおよび同期はより少なくてすむが、ＣＰＵコストはより高くなる。一方、ベクトル化された実装は、より少ないＣＰＵコストでより多くのメモリを必要とするとともに、追加の同期化作業を必要とする。

【0126】

Ｎａｔｕｒａｌ ｊｏｉｎ
文法における次の結合は自然結合（natural join）であり、これは２つのテーブルにおいて同じ名前を共有するすべての列に基づく。Ｃ１が両者の主キーである２つのテーブルＴ１（以下の表５に示される第１および第２の列）およびＴ２（以下の表５に示される第３および第４の列）を考えると、次の操作の結果：
ＳＥＬＥＣＴ ＊
ＦＲＯＭ Ｔ１ ＮＡＴＵＲＡＬ ＪＯＩＮ Ｔ２
は、以下の表６に従う。

【0127】

【表5】

【0128】

【表6】

【0129】

言い換えれば、実装に従う自然結合は、すべての共通の列に基づいて一致する行を出力するが、同じ名前の列は一度しか現れない。

【0130】

実装は、両方のテーブルのすべての列名を事前にフェッチし、交差を計算することによって、それをＩＲに変換することができる。次いで、実装は、Ｔ１の共通列のすべての行をフェッチし、共通列上のＴ２の行と交差させ、選択された行で残りの列の値をフェッチする。

【0131】

図１１は、実装による、Ｆｉｎｄ演算子を使用する上記例のＩＲを提示する。Ｏｐ＃１は、以下の表７に従って、列Ｃ１についてのすべての主キーおよびＴ１の値をフェッチする。

【0132】

【表7】

【0133】

次に、Ｏｐ＃２において、実装は、テーブルＴ１のものと同じ値を有する列Ｃ１について、Ｔ２の主キーを取得するステップを実行する。そこで結合が起きる。そのような操作の結果が以下の表８に提示される。

【0134】

【表8】

【0135】

Ｏｐ＃３では、以下の表９に提示されるように、実装は、Ｏｐ＃１（ｉ１）で見つけ出されたＴ１の主キーを使用して、Ｔ１における列Ｃ２の値を取得する。

【0136】

【表9】

【0137】

次いで、実装は、以下の表１０に提示されるように、Ｏｐ＃２（ｉ３）の主キーを使用してＴ２のＣ４の値を取得する。

【0138】

【表10】

【0139】

実装では主キーが必要なくなったため、それぞれの列は出力に破棄された。リテラル「ＢＢ」がそのインデックス（４２）に置き換えられていることに留意されたい。最後に、実装は値を抽出する。抽出された値は、以下の表１１に提示される。

【0140】

【表11】

【0141】

上図では、共通列：｛Ｃ１｝のリスト、ならびにＴ１：｛Ｃ２｝およびＴ２：｛Ｃ４｝の残りの列のリストを計算するためのストレージに対する要求を示していないことに留意されたい。これは、ストレージエンジンＡＰＩに追加される必要があるスキーマプロトコルに基づいている。このスキーマプロトコルはＳＱＬに特有であり、そのようなスキーマがＳＱＬクエリにおいて暗黙的であるため、必要とされる。

【0142】

他の例では、実装は自然結合を採用して、他の結合型のいくつかであるｉｎｎｅｒ、ｏｕｔｅｒ、およびｕｎｉｏｎを修飾することができる。

【0143】

条件結合
実装は、自然結合のように暗黙的に結合を行う代わりに、ＯＮ句を使用してテーブルの結合が適用される列を指定することができる。

【0144】

ＳＥＬＥＣＴ ＊
ＦＲＯＭ Ｔ１ ＪＯＩＮ Ｔ２
ＯＮ Ｔ１．Ｃ１ ＝ Ｔ２．Ｃ３
ＯＮの代わりに、ＵＳＩＮＧは同じ目的を有する構文糖衣である：
ＳＥＬＥＣＴ ＊
ＦＲＯＭ Ｔ１ ＪＯＩＮ Ｔ２
ＵＳＩＮＧ （Ｃ１，Ｃ２）
説明された両方の場合とも、自然結合アルゴリズムの適応である。後述されるようにＷＨＥＲＥ句が指定されることも可能である。

【0145】

これまで説明された結合操作は、内部結合としても知られている。ｉｎｎｅｒ ｊｏｉｎというキーワードは、構文糖衣として前の例の結合を置き換えることができる。

【0146】

Ｏｕｔｅｒ ｊｏｉｎ
内部結合とは対照的に、外部結合（outer join）オペレーションは、使用されるキーワードであるｌｅｆｔ、ｒｉｇｈｔ、またはｆｕｌｌに応じて、片方または両方のテーブルから一致されない行を保持する。言い換えれば、内部結合は特定の検索条件が満たされない任意の行を除外するのに対し、外部結合は一致されないデータの一部またはすべてを保持する。表５のＴ１およびＴ２の例を考えると、
ＳＥＬＥＣＴ ＊
ＦＲＯＭ Ｔ１ ＬＥＦＴ ＯＵＴＥＲ ＪＯＩＮ Ｔ２
ＯＮ Ｔ１．Ｃ１ ＝ Ｔ２．Ｃ３
の結果は、以下の表１２のようになる。

【0147】

【表12】

【0148】

定義により、左外部結合の入力（表５）の各行は結果テーブルに含まれる。Ｃ３＝２０となるＴ２の行がないため、第２の行はヌル値を有する。

【0149】

左外部結合と右外部結合は、意味論的にＳＰＡＲＱＬ ＯＰＴＩＯＮＡＬパターンと同等であるが、ＯＰＴＩＯＮＡＬがＳＰＡＲＱＬにおいて値をｆｉｎｄしない場合、変数はワイルドカードになるという違いがある。ＳＱＬでは、ヌル値が返された場合、それらはヌルのままであり、ヌルと任意の値を結合するとヌルをもたらす。したがって、実装は、次の演算子がオプショナル（すなわち、ワイルドカードありまたはなし）の結果に依存し得るという事実を扱うために、ＯＰＴＩＯＮＡＬのすべてのメカニズムを必要としない。

【0150】

図１２は、実装による上記の例のＩＲを提示する。破線は、Ｏｐｔｉｏｎａｌ ｆ０の第２の子に対応する。

【0151】

テーブルＴ１から開始して、最初の演算子Ｏｐ＃１は、以下の表１３のように列Ｃ１について出力する。

【0152】

【表13】

【0153】

ＩＲは左結合を有するので、以下に帰着するように、Ｏｐ＃１の主キーｉ０を使用して、Ｏｐ＃２を適用すると、すべての列Ｃ２が結果に現れる：

【0154】

【表14】

【0155】

次の演算子は、フラグｆ０を作成するオプション演算子であり、それが決してセットされない場合、破線が実行される。この場合、演算子Ｏｐ＃６が使用され、ｉ３列およびｉ４列をすべてｕｎｄｅｆに設定する。さもなければ、Ｏｐ＃３を使用して実際の結合を行い、Ｔ１．Ｃ１と同じ値を有するＴ２．Ｃ３のすべての行を取得する。これらの値は、Ｏｐ＃１によってｉ１として計算される。結果は、以下の表１５である。

【0156】

【表15】

【0157】

テーブルＴ２の列Ｃ３に主キー２０を有する応答がないため、ｉ３の２行目にｕｎｄｅｆがある。結果が見つけ出されないときにこのｕｎｄｅｆを取得するために、実装は、単純なＦｉｎｄの代わりにＦｉｎｄＯｐｔｉｏｎａｌを使用する。単純なＦｉｎｄは、一致が見つけ出されない場合に出力行を生成しないからである。

【0158】

次に、実装はＯｐ＃４を実行する。結合の結果は既に見つけ出されているので、フラグが設定され、Ｏｐ＃６は実行されない。Ｏｐ＃５は、主キーｉ３を有する列Ｃ４の値を取得する。ｉ３にはｕｎｄｅｆがあるので、ＳＰＡＲＱＬではワイルドカードに変わってしまうため、それは起こり得ない。対照的に、ＳＱＬはそうすることなく、代わりに０はｕｎｄｅｆのままである。したがって、実装は、ｕｎｄｅｆ事例を異なる扱いをするためにＩＲにおいてＩＦを取得する。実際に、Ｆｉｎｄはｕｎｄｅｆを入力として受け付けない。このステップの結果は以下の表１６の通りである。

【0159】

【表16】

【0160】

表１６の結果において、ｉ０は必要なくなったので破棄されている。次いで、インデックス４２が「ＢＢ」を意味し、ｕｎｄｅｆがヌルに変換されるので、実装は、以下の表１７のように最終的な値を取得する。

【0161】

【表17】

【0162】

外部結合は連想的ではなく、右外部結合は左外部結合の対称である。完全外部結合は左外部結合と右外部結合の組み合わせであり、したがって、表５と同じテーブルＴ１およびＴ２を有し、
ＳＥＬＥＣＴ ＊
ＦＲＯＭ Ｔ１ ＦＵＬＬ ＯＵＴＥＲ ＪＯＩＮ Ｔ２
ＯＮ Ｔ１．Ｃ１ ＝ Ｔ２．Ｃ３
の結果は、表１８のようになる。

【0163】

【表18】

【0164】

図１３は、左／外部結合とクロス結合との間の混合である上記のクエリのＩＲ変換を提示する。クロス結合のデカルト積と同様に、ＩＲはフラグｆ０を有するバッファを作成することから開始する。次いで、ＩＲは、Ｔ２のすべての行（Ｏｐ＃４、Ｏｐ＃５）を取得し、それをバッファリングする一方、Ｔ１からすべての行を取得する。次いで、ＩＲは、Ｏｐ＃２とＯｐ＃６からもたらされるバッファの各行に対して、ｉ３＝ｉ４という条件で外部結合を行い、Ｏｐ＃３においてＴ１タスクをＴ２タスクと同期させる。これは、各行について、ｉ３＝ｉ４の場合、ＩＲは（以下の表１９のように）行を結合することを意味する：

【0165】

【表19】

【0166】

そうでない場合、表２０のように、Ｏｐ＃２からの値がｕｎｄｅｆで補完されて１行が追加される：

【0167】

【表20】

【0168】

そして、表２１のように、Ｏｐ＃６からの値がｕｎｄｅｆで補完されて上記の結果に１行が追加される：

【0169】

【表21】

【0170】

これは、任意のＯＮ検索条件で一般化され得る。

【0171】

検索条件のＳｙｎｃｈｒｏｎｉｚｅ ＯｕｔｅｒＪｏｉｎは、ＩＲに追加される必要のある新しいノードである。それは、クロス結合によって既に導入されたのと同じＣｒｅａｔｅＢｕｆｆｅｒノードおよびＢｕｆｆｅｒｉｚｅノードを使用する。このＢｕｆｆｅｒｉｚｅノードについては、いつ使用できるのか、いつ削除できるのかという２つの情報が知られるべきである。そのため、それが実際のＩＲ実装におけるフラグの一般化のように見られる。

【0172】

Ｕｎｉｏｎ ｊｏｉｎ
統合結合（union join）は、上述された完全外部結合と同様に作用するが、列一致を指定できないという違いがある。代わりに、統合結合は以下を行う：
・ ソーステーブルからのすべての列の統合を有する新しい仮想テーブルを作成し、
・ 新しいテーブルの行を各ソーステーブルのそれぞれの列の値を用いて作成し、他方のテーブルの各行内の列にヌル値が割り当てられる。

【0173】

したがって、表５のテーブルＴ１およびＴ２について、
ＳＥＬＥＣＴ ＊
ＦＲＯＭ Ｔ１ ＵＮＩＯＮ ＪＯＩＮ Ｔ２
の結果は、以下の表２２のようになる。

【0174】

【表22】

【0175】

図１４は、完全外部結合のＩＲ変換が次に単純なバッファ連結として統合結合のために単純化できることを提示する。

【0176】

スコープ
ＪＯＩＮオペランドでは、（先に定義されたような）範囲変数のスコープはその結合を直ちに含む結合式であるが、別の範囲変数が同じ名前で導入される元の結合式内のいずれかにネストされる任意の選択式または結合式を除外する。すべての列は名前を持つ必要があり、必要に応じて名前が割り当てられ得る。

【0177】

派生テーブル
ＢＮＦにおいてＦＲＯＭ句があることを思い出す：
<from clause> ::= FROM <table reference> [ { <comma> <table reference> }... ]
<table reference> ::=
<table name> [ <correlation specification> ]
| <derived table> <correlation specification>
| <joined table>

【0178】

次のテーブル参照は、次のように定義される派生テーブルである：
<derived table> ::= <table subquery>
<table subquery> ::= <subquery>
<subquery> ::= <left paren> <query expression> <right paren>
<query expression> ::= <non-join query expression> | <joined table>
<non-join query expression> ::=
<non-join query term>
| <query expression> UNION [ ALL ] [ <corresponding spec> ] <query term>
| <query expression> EXCEPT [ ALL ] [ <corresponding spec> ] <query term>
<non-join query term> ::=
<non-join query primary>
| <query term> INTERSECT [ ALL ] [ <corresponding spec> ] <query primary>

【0179】

ここで、式であるＵＮＩＯＮ、ＥＸＣＥＰＴ、ＩＮＴＥＲＳＥＣＴは非結合クエリ式であり、集合論の和演算、差演算、交差演算に基づいている。

【0180】

基本的なクエリ式は、ＳＰＡＲＱＬにおけるそれらと同等のものにマッピングされる。それは、派生テーブル以外のＵＮＩＯＮ、ＥＸＣＥＰＴ、ＩＮＴＥＲＳＥＣＴの場合である。ＳＰＡＲＱＬにおけるＵＮＩＯＮ、ＦＩＬＴＥＲ ＥＸＩＳＴ／ＮＯＴ ＥＸＩＳＴと同様に、上で詳述されたように、一階論理の量化子にマッピングされる両言語の演算子がごく自然に存在する。

【0181】

ＷＨＥＲＥ
ＷＨＥＲＥ句は、条件のセットを満たす特定の行を取り出すための手段である。それは、検索条件、すなわち、ＡＮＤ、ＯＲ、およびＮＯＴと組み合わされた（ＲＤＦの意味ではなく述語論理の意味での）１つまたは複数の述語を必要とする。
<where clause> ::= WHERE <search condition>
<search condition> ::=
<boolean term>
| <search condition> OR <boolean term>
<boolean term> ::=
<boolean factor>
| <boolean term> AND <boolean factor>
<boolean factor> ::= [ NOT ] <boolean test>
<boolean test> ::= <boolean primary> [ IS [ NOT ] <truth value> ]
<boolean primary> ::= <predicate> | <left paren> <search condition> <right paren>
<predicate> ::=
<comparison predicate>
| <between predicate>
| <in predicate>
| <like predicate>
| <null predicate>
| <quantified comparison predicate>
| <exists predicate>
| <match predicate>
| <overlaps predicate>

【0182】

次に、上記の文法で使用されている述語型のリストが説明される。

【0183】

Ｃｏｍｐａｒｉｓｏｎ
比較（ｃｏｍｐａｒｉｓｏｎ）述語は、通常の自明な＜，＝，＞＝，．．．であり、等しくないことは＜＞である。ｂｅｔｗｅｅｎ述語は、以下の形式を有する比較述語の変形である：
ｖａｌｕｅ１ ＢＥＴＷＥＥＮ ｖａｌｕｅ２ ＡＮＤ ｖａｌｕｅ３
ｖａｌｕｅ１ ＮＯＴ ＢＥＴＷＥＥＮ ｖａｌｕｅ２ ＡＮＤ ｖａｌｕｅ３
これらは、以下と同等である：
ｖａｌｕｅ１＞＝ｖａｌｕｅ２ ＡＮＤ ｖａｌｕｅ１＜＝ｖａｌｕｅ３
ＮＯＴ（ｖａｌｕｅ１＞＝ｖａｌｕｅ２ ＡＮＤ ｖａｌｕｅ１＜＝ｖａｌｕｅ３）
ＩＲはこれらの操作のためのバイトコードを生成し、ＲＤＦタームを比較する。「Ｒ２ＲＭＬ：ＲＤＢ ｔｏ ＲＤＦ Ｍａｐｐｉｎｇ Ｌａｎｇｕａｇｅ」（非特許文献３１参照）を使用するＷ３Ｃ勧告「Ａ Ｄｉｒｅｃｔ Ｍａｐｐｉｎｇ ｏｆ Ｒｅｌａｔｉｏｎａｌ Ｄａｔａ ｔｏ ＲＤＦ」（非特許文献３２参照）に基づいて、実装は、ＳＱＬ値の自然なマッピング（natural mapping）（非特許文献３３参照）を有する：
ＳＱＬデータ値に対応する自然なＲＤＦリテラルは、以下のステップを適用した結果である：
・ ＳＱＬデータ値のＳＱＬデータ型をｄｔとする。

【0184】

・ ｄｔが文字列型（Ｃｏｒｅ ＳＱＬ ２００８では：ＣＨＡＲＡＣＴＥＲ、ＣＨＡＲＡＣＴＥＲ ＶＡＲＹＩＮＧ、ＣＨＡＲＡＣＴＥＲ ＬＡＲＧＥ ＯＢＪＥＣＴ、ＮＡＴＩＯＮＡＬ ＣＨＡＲＡＣＴＥＲ、ＮＡＴＩＯＮＡＬ ＣＨＡＲＡＣＴＥＲ ＶＡＲＹＩＮＧ、ＮＡＴＩＯＮＡＬ ＣＨＡＲＡＣＴＥＲ ＬＡＲＧＥ ＯＢＪＥＣＴ）である場合、結果は言語タグなしのプレーンリテラルとなり、その字句形式はＳＱＬデータ値である。

【0185】

・ そうではなく、ｄｔが以下の表にリストされている場合、結果は、データ型ＩＲＩが、ｄｔと同じ行のＲＤＦデータ型列に示されたＩＲＩである、型付きリテラルである。字句形式は、ＲＤＦデータ型の定義に従って、ＳＱＬデータ値と同じ値を表す任意の字句形式であり得る。同じ値を表す利用可能な複数の字句形式がある場合（例えば、１、＋１、１．０、および１．０Ｅ０）、選択は実装に依存する。しかしながら、選択は、目標ＲＤＦデータ型および値が与えられると、同じ字句形式が一貫して選択されるようにされる必要がある（例えば、ＩＮＴＥＧＥＲ ５とＢＩＧＩＮＴ ５は、両方ともＲＤＦデータ型ｘｓｄ：ｉｎｔｅｇｅｒにマッピングされ、等しい値であり、同じ字句形式にマッピングされなければならない。一方を５に、他方を＋５にマッピングすることはエラーとなる）。正規の字句表現ＸＭＬＳＣＨＥＭＡ２ ＭＡＹが選択される（Ｓｕｍｍａｒｙ ｏｆ ＸＳＤ Ｌｅｘｉｃａｌ Ｆｏｒｍｓも参照されたい）。

【0186】

・ そうでない場合、結果は言語タグなしのプレーンリテラルとなり、その字句形式は文字列にキャストされたＳＱＬデータ値である。

【0187】

概要が以下の表２３に提示されている。

【0188】

【表23】

【0189】

ＩＮＴＥＲＶＡＬの変換は、その変換が複雑であるために未定義のままとなっている。ＳＱＬ１４では、ＩＮＴＥＲＶＡＬからｘｄｔ：ｙｅａｒＭｏｎｔｈＤｕｒａｔｉｏｎおよびｘｄｔ：ｄａｙＴｉｍｅＤｕｒａｔｉｏｎへの変換が記述されている。

【0190】

実装によるデータベースは、ｘｓｄ：ｎｕｍｅｒｉｃに基づく数値の実装定義を有する。ＳＱＬおよびＳＱＬ２では、多くのＳＱＬデータ型の精度は固定されず、実装に定義がまかされる。したがって、ＸＭＬ Ｓｃｈｅｍａデータ型へのマッピングは、ｘｓｄ：ｄｅｃｉｍａｌ、ｘｓｄ：ｉｎｔｅｇｅｒ、およびｘｓｄ：ｄａｔｅＴｉｍｅなどの任意精度型に依存しなければならない。マッピングの実装者は、これらのＸＳＤ型のサポートされる精度の上限を設定することを望むかもしれない。ＸＭＬスキーマ仕様は、無限データ型ＸＭＬＳＣＨＥＭＡ２のそのような部分実装を可能にし、特定の最小要件を定義する。

【0191】

したがって、実装はｘｓｄ：ｎｕｍｅｒｉｃと同じであり、同じ規則が適用される。

【0192】

ＲＤＦタームは、データ型、字句形式、および正規形式を有することができる。規則は、以下の通りである：
ＳＱＬデータ型に対応する自然なＲＤＦデータ型は、上記の表２３のＳＱＬデータ型に対応する行におけるＲＤＦデータ型列の値である。ＳＱＬデータ値に対応する自然なＲＤＦ字句形式は、その対応する自然なＲＤＦリテラルの字句形式であり、ＸＭＬＳＣＨＥＭＡ２ ＳＨＯＵＬＤの正規の字句表現が選択されるという追加の制約を有する。ＳＱＬデータ値に対応する正規のＲＤＦ字句形式は、その対応する自然なＲＤＦリテラルの字句形式であり、正規の字句表現ＸＭＬＳＣＨＥＭＡ２ ＭＵＳＴが選択されるという追加の制約を有する。

【0193】

ＧＲＯＵＰ ＢＹ
入力テーブルは、１つまたは複数のグループに分割され、グループの数は、各グループ化列参照について、どのグループの２行もそのグループ化列に対して異なる値を持たないような最小数である。すなわち、結果でグループ化されたテーブルのどのグループについても、そのグループ内のすべての行はグループ化列に同じ値を有する。文法は以下の通りである：
<group by clause> ::= GROUP BY <grouping column reference list>
<grouping column reference list> ::=
<grouping column reference> [ { <comma> <grouping column reference> }... ]
<grouping column reference> ::= <column reference> [ <collate clause> ]
<collate clause> ::= COLLATE <collation name>
<collation name> ::= <qualified name>

【0194】

これはＳＰＡＲＱＬと同じ挙動である。ＣＯＬＬＡＴＥ句は、順序付けに使用される照合（例えば、ＳＱＬ＿Ｌａｔｉｎ１＿Ｇｅｎｅｒａｌ＿ＣＰ１＿ＣＳ＿ＡＳ）を指定するために使用され得る。これは、ＩＲではサポートされていない。実装は、単純化のために、照合なしでＧＲＯＵＰ ＢＹをサポートする。

【0195】

ＨＡＶＩＮＧ
ｈａｖｉｎｇ句は、前の句の結果のグループ化されたテーブルに、すなわち、ｇｒｏｕｐ ｂｙがあればその結果、そうでなければｗｈｅｒｅ句（またはＷＨＥＲＥ句がなければｆｒｏｍ句、ＦＲＯＭは必須である）の結果に適用される別のフィルタである。これらの最後の２つの場合では、入力は、正確に１つのグループを有するグループ化されたテーブルとして扱われる。ｈａｖｉｎｇ句が参照できる入力テーブルの列は、列がセット関数（例えば、ｃｏｕｎｔ、ｍａｘ、ａｖｇなど、専用セクションを参照）で使用されない限り、グループ化列のみである。これは、ＳＰＡＲＱＬと同じ挙動である。文法は以下の通りである：
<having clause> ::= HAVING <search condition>

【0196】

ＳＥＬＥＣＴリスト
ＳＥＬＥＣＴ文は、ｓｅｌｅｃｔリストで始まるクエリ仕様を与える。このリストの前に集合量化子を置くことができ、ＡＬＬは重複を排除しないことを意味し、ＤＩＳＴＩＮＣＴは冗長な重複を排除することを意味する。ｓｅｌｅｃｔリストは、テーブル式に対応するテーブルの一部であるすべての列に対するアスタリスクとされ得るか、または明示的なｓｅｌｅｃｔサブリストが使用され得る。選択サブリストは、派生列、または修飾子（先に見られたように、修飾子は、テーブル名、もしくは特定のスコープ内のテーブルを識別する相関名（範囲変数）のいずれかである）にピリオドおよびアスタリスクが続くもの：ｔ．＊であり得る。
<query specification> ::=
SELECT [ <set quantifier> ] <select list> <table expression>
<select sublist> ::= <derived column> | <qualifier> <period> <asterisk>
<derived column> ::= <value expression> [ <as clause> ]
<as clause> ::= [ AS ] <column name>
<set quantifier> ::= DISTINCT | ALL

【0197】

派生列は値式（例えば、列名）であり、任意選択でキーワードＡＳおよび列名が続く。値式は明示的でない名前（例えば「ｐｒｉｃｅ／２」）を有することができる。この場合、標準は、実装が名前を割り当てなければならないことを明示的に要求する。

【0198】

これは、ＳＰＡＲＱＬにおけるのと同じ挙動である。

【0199】

ＤＩＳＴＩＮＣＴおよびＯＲＤＥＲＢＹもＳＰＡＲＱＬとＳＱＬにおいて同じである。

【0200】

使用事例
態様では、実装は、大規模データベース、例えば、大規模な表データとの対話に関連付けられ得る。具体的には、実装は、各行について数列を有する部品表（ＢＯＭ）（例えば、１００万のオーダのウェブテーブル）のインスタンスの大きなテーブルの対話スクロールを提供することができる。ＢＯＭは、セマンティックグラフ（例えばＲＤＦ）を使用して記述される。ユーザは、所与のある瞬間に画面上の限られた行数（例えば、１００行）を見ることがあるため、リスト上で対話的にスクロールしようとする。

【0201】

リレーショナルデータベースにおける従来のアプローチでは、クエリ全体を一度だけ実行するために、マテリアライズドビュー上でページネーション（例えば、最初に１行から１００行、次いで１０１行から２００行など）を使用する。そのようなアプローチでは、ｏｒｄｅｒｂｙ句のみを含む（すなわち、ｏｆｆｓｅｔ句およびｌｉｍｉｔ句を含まない）クエリの結果のマテリアライズドビュー（非特許文献３４参照）を作成する。次いで、ユーザは、オフセット／リミットを用いてビューに問い合わせることができる。このアプローチの例については、非特許文献３５で説明されている。

【0202】

上述されたアプローチは、入力データがテーブルに格納されるリレーショナルデータである場合、クエリの出力データはテーブルの行として見られ得るタプルであるため、うまく機能する。そのような出力タプルは、これらのタプルからマテリアライズドビューを作成するために使用され、テーブルとして格納され得る。テーブルは、ＳＱＬによってネイティブに問い合わされ表示され得る。

【0203】

しかしながら、ＢＯＭがセマンティックグラフを使用して記述された場合、行はインスタンス名（例えば、列の１つ）で順序付けられる。したがって、次の行（例えば、１００行）を表示させるためにオフセットする前にすべての行をソートすることが必須である。ＳＰＡＲＱＬクエリの結果も、テーブルの行として見られ得るタプル（非特許文献３６参照）である。しかしながら、従来のアプローチであるＧＤＢＭＳは、これらの結果をテーブルとして格納することができず、グラフクエリ言語を使用してＳＰＡＲＱＬでネイティブにテーブルに問い合わせることもできない。一般的なルールとして、双方向性は、応答時間が約３００ｍｓまでと考えられており、そのようなクエリの計算は、双方向性が考えられるには遅すぎる可能性がある。例えば、テーブルが１００万行で８列を有する場合、クエリ全体で約３秒かかる。そのような使用事例を扱う解決策は、スクロール時にクエリを再評価することなく、リスト内で後方または前方に進む能力を必要とする。リスト内のすべてのデータは一貫していなければならない。言い換えれば、すべてのデータはデータベースの同じ状態を反映しなければならない（例えば、状態の一部が書込みトランザクションの前で、状態の一部が書込みトランザクションの後とはならない）。そのため、ｏｒｄｅｒｂｙ／ｏｆｆｓｅｔ／ｌｉｍｉｔを有する標準的ＳＰＡＲＱＬクエリは、（再評価を必要とするため、）この目的には効率的ではない。ＲＤＦｏｘのようにカーソルを使用しても、カーソルが後方に移動できず、すべての動きは前方であるため、役に立たない。

【0204】

この使用事例の実装は、以下のようにＳＰＡＲＱＬで定義され、ＳＱＬに類似する「ＣＲＥＡＴＥ ＶＩＥＷ」句によって、ＳＰＡＲＱＬを拡張することができる；
<create view> ::= CREATE VIEW <view name> AS <SELECT QUERY>
ここで、「ｖｉｅｗ ｎａｍｅ」はＩＲＩであり、「ＳＥＬＥＣＴ ＱＵＥＲＹ」は標準のＳＥＬＥＣＴ ＳＰＡＲＱＬクエリである。

【0205】

上述されたように、ＳＥＬＥＣＴクエリの結果は、タプルのテーブルである。実装は、これらのタプルからテーブルを作成し、テーブルの列はＳＥＬＥＣＴの出力変数であり、行はタプルである。実装は、タプルをインデックスとして保持し、格納コストを低くするために、値は保持しない。

【0206】

このテーブルを作成すると、インタラクション（例えば、ユーザによるスクロール）により、ｌｉｍｉｔ／ｏｆｆｓｅｔを有するＳＱＬクエリを発行してページネーションを行い、ユーザに行を表示することができる。実装によれば、ビューの作成は約３秒を要し、ページネーションクエリは約１００ｍｓを要する。

【図1】

【図2】

【図3】

【図4】

【図5】

【図6】

【図7】

【図8】

【図9A】

【図9B】

【図10】

【図11】

【図12】

【図13】

【図14】

【外国語明細書】