A 2表スキーマを使用したプロパティ・グラフの処理
比較的固定で、シンプルなデータ構造のプロパティ・グラフで、頂点およびエッジの<graph_name>VT$および<graph_name>GE$ キー/値データ表に柔軟性が必要ない場合、2表スキーマを使用してランタイム・パフォーマンスを改善することができます。
ノート:
このトピックで説明されている2表スキーマのアプローチに対するサポートは非推奨となっており、将来のリリースでは削除される可能性があります。
かわりに、Oracle Databaseのプロパティ・グラフ・スキーマ・オブジェクトで説明されているように、プロパティ・グラフ・スキーマ・アプローチを使用してグラフ・データを操作することをお薦めします。
2表スキーマのアプローチは、(Oracle Databaseのプロパティ・グラフ・スキーマ・オブジェクトで説明されている)プロパティ・グラフ・スキーマを使用する推奨アプローチの代替手段である非推奨アプローチです。
-
プロパティ・グラフ・スキーマ・アプローチは、主に異機種間や大規模なグラフに対応して設計されています。同じプロパティ名の新しい関係および場合によっては新規データ型がオンザフライでグラフ・モデルに導入および追加された動的アプリケーション・ドメインを示すためにグラフ・モデルが使用されている場合、プロパティ・グラフ・スキーマを使用することをお薦めします。
同じプロパティ名の新しい関係および場合によっては新規データ型がオンザフライでグラフ・モデルに導入および追加された動的アプリケーション・ドメインを示すためにグラフ・モデルが使用されている場合、プロパティ・グラフ・スキーマを使用することをお薦めします。
-
2表スキーマのアプローチは、同種のグラフ用に設計されています。
グラフ・モデルが一連の関係がすでに認識されているアプリケーション・ドメインを表し、個別の関係の合計数が比較的小さい場合(1000未満)、2表アプローチは潜在的なオプションです。この状況は、通常、元のデータ・ソースが1つまたは一連の既存のリレーショナル表またはリレーショナル・ビューからの場合に発生します。
2表アプローチが有効である可能性のある例として、すべてのノードが特定の組織の従業員であり、各従業員には限定され固定された属性のセットと使用可能なリレーションシップがある場合があります。2表アプローチが有効でない例として、ノードが様々な属性とリレーションシップを持つ可能性のある個人であり、属性やリレーションシップが動的に追加および変更される可能性がある場合があります。
柔軟なキー/値アプローチ(2表ではない)では、Oracle Spatial and Graphはプロパティ・グラフ・データを、頂点用に<graph_name>VT$、エッジ用に<graph_name>GE$という、柔軟なスキーマで格納します。このスキーマでは、頂点およびエッジは複数の行を使用して格納されます。各行は頂点(またはエッジ)に関係付けられたキー/値プロパティを表し、柔軟なデータ型を持ち、属性T (タイプ)により決定されます。このスキーマ・デザインでは、頂点(エッジ)が様々なプロパティ・セットまたはプロパティ値のデータ型を持つ、異機種間グラフに容易に対応できます。
一方、同種構造のプロパティ・グラフの場合、2表スキーマを使用してグラフ・データを格納できます。このアプローチでは、各頂点は名前付けされた頂点表に単一行として格納され、各エッジは名前付けされたエッジ表の単一行として格納されます。この方法では、行の各列は固定データ型のプロパティに対応します。インメモリー・アナリストはこのアプローチを使用してインメモリー・グラフを作成および管理できます。
ノート:
2表アプローチは、主に既存のブループリントに基づいたJava APIにインメモリー・アナリストのグラフ・データを提供するためであり、2表アプローチではテキストの索引付けは機能しません。
プロパティ・グラフ・スキーマ・アプローチが使用される場合のみ、グラフ・データ・チェンジ・トラッキングを使用できます。
次のトピックは、2表スキーマを使用したプロパティ・グラフの作成方法と、このデータに対する読取りおよび書込み操作の実行方法について焦点を当てます。