CRDFセマンティク・グラフでの仮想プライベート・データベースのサポート

注意:

Oracle Databaseリリース12c (12.1)では、RDFセマンティク・グラフでの仮想プライベート・データベース(VPD)のサポートは、ファイングレイン・アクセス制御の提供に関しては非推奨となり、今後のメジャー・リリースでは削除されます。

VPDに依存する新しいRDFセマンティク・グラフ・アプリケーションは開発しないようにし、VPDに依存する既存のRDFセマンティク・グラフ・アプリケーションを、Oracle Label Security (OLS)を使用するように移行してください。(OLSのサポートの詳細は、「RDFデータのファイングレイン・アクセス制御」を参照してください。)

詳細は、My Oracle SupportのNote 1468273.1を参照してください

RDFデータの仮想プライベート・データベース(VPD)によって、セキュリティ管理者は、特定のRDFクラスまたはプロパティのインスタンスを含むトリプルに対するユーザーのアクセスを条件付きで制限するポリシーを定義できます。VPDを使用すると、RDFモデルに格納されたデータはそのメタデータを使用して分類され、各ユーザー問合せは、アクセス制限を実施するコンテキスト依存のデータ・アクセス制約を含むようにリライトされます。

VPDの使用方法の詳細は、『Oracle Databaseセキュリティ・ガイド』を参照してください。

RDFデータでVPDとOLSのどちらを使用するかを選択する場合に考慮する要素は、次のとおりです。

OLSは、RDFデータに対して有効化されると、ネットワーク・レベルで実施されますが、VPDは個々のRDFモデルに対して実施できます。
Oracleインスタンスで同時にRDFデータに対してVPDとOLSの両方を使用することはできません。

セマンティク・データとともにVPDまたはOLSを実装するためのアプリケーション・プログラミング・インタフェース(API)は、SEM_RDFSA PL/SQLパッケージで提供されます。「SEM_RDFSAパッケージのサブプログラム」には、SEM_RDFSAパッケージのプログラムに関するリファレンス情報が示されています。

RDFデータに対するVPDおよびOLSのサポートは、Oracle DatabaseのRDFセマンティク・グラフ・サポートに含まれています。(RDFセマンティク・グラフ・サポートの有効化、ダウングレード、または削除の詳細は、「RDFセマンティク・グラフ・サポートの有効化、ダウングレードまたは削除」を参照してください。)

CDB (マルチテナント・コンテナ・データベース)環境では、RDFに対してVPDを使用できません。

C.1 RDFデータの仮想プライベート・データベース(VPD)

仮想プライベート・データベース(VPD)機能は、セキュリティ・ポリシーとアプリケーション・コンテキストを使用してリレーショナル表またはビューの特定の行に対するアクセスを制限する行レベルのセキュリティ・メカニズムです。セキュリティ・ポリシーには、ユーザー問合せに対して戻される行ごとに実施される述語を動的に生成するポリシー・ファンクションが含まれます。表に関連付けられたポリシー・ファンクションによって戻されるセキュリティ述語は、通常、表の列を使用して表現されるため、表のメタデータに依存します。実際、セキュリティ述語によって、ユーザー問合せに対して戻される行が、その行の内容に適用される追加の条件を満たすことが保証されます。

リレーショナル・データがRDFにマップされている場合、特定のリレーショナル表に格納されているデータは、特定のRDFクラスのインスタンスを記述するトリプルを表します。この表現では、リレーショナル表の列は、リソースを記述するために使用されるRDFプロパティにマップされます。このマッピングは、さらにVPDポリシーのアプリケーションに拡張できます。

RDFデータに適用されるVPDポリシーは、述語を、グラフ・パターンおよびフィルタ条件の形式でインスタンス・データに適用することによって、ユーザーのアクセスを特定のRDFクラスまたはプロパティのインスタンスに制限します。たとえば、Contract RDFクラスのインスタンスへのアクセスを特定の部門に属するユーザーのみに制限する場合に、VPDポリシーを定義できます。また、Contract RDFクラスのインスタンスと識別されるリソースのhasContractValueプロパティへのアクセスを、契約の管理者のみに制限できます。RDFデータに対するVPDサポートでは、セキュリティ条件またはデータ・アクセス制約をRDFクラスおよびプロパティに関連付けて、対応するインスタンス・データへのアクセスが制限されるようにできます。

RDFクラスまたはプロパティに関連付けられるデータ・アクセス制約によって、問合せ結果として戻されるすべての対応するデータ・インスタンスに対して実施される必要がある、グラフ問合せパターンが指定されます。たとえば、Contractクラスのすべてのインスタンスの期限を検索するSPARQL問合せパターン({?contract :hasDueDate ?due})は、戻される情報が特定の部門に属する契約に関係することを保証するデータ・アクセス制約をアクティブにすることができます。これは、次の例に示すように、追加のグラフ・パターンを含むようにユーザーのグラフ問合せパターンを論理的にリライトすることによって、実現されます。

{ ?contract   :hasDueDate  ?due . 
  ?contract   :drivenBy    dept:Dept1 }

また、リライトされたグラフ問合せパターンにバインドされた値がセッション・コンテキストを使用して、動的アクセス制限を実施する場合があります。次の例では、トリプル・パターンの目的語の位置のsys_contextファンクションが、セッション・コンテキストに基づいて適切な部門値をバインドします。

{ ?contract   :hasDueDate   ?due . 
  ?contract   :drivenBy
             "sys_context('sa$appctx','user_dept'}"^^orardf:instruction }

リレーショナル・データ・モデルでは、メタデータは、表定義の形式で常にデータ(表に格納された行)とともに存在するため、メタデータを使用して定義されたVPDポリシーは適切に整形され、ポリシー・ファンクションの手続き型ロジックを使用してセキュリティ条件が生成されます。

ただし、RDFデータ・モデルではメタデータを伴わないデータが許可されるため、指定されたRDFグラフに対してインスタンス・データのクラス情報が必ずしも使用可能にならない場合があります。たとえば、RDFグラフで、契約として把握されるリソースが、Contractクラスのインスタンスであることを表明するトリプルを伴わない場合があります。通常、このようなトリプルの推論は、そのリソースを記述するプロパティに対して使用可能なドメインおよびレンジ指定を使用することで実行できます。

同様に、VPDポリシーは、インスタンス・データのクラス情報を導出し、適切なデータ・アクセス制約を実施するためにプロパティのドメインおよびレンジの指定に依存します。ただし、実行時にユーザー・データに依存することを避けるため、VPDポリシーは、表明および推論されたトリプルとは別に、そのディクショナリのクラス情報を導出するために必要な最低限のメタデータを保持します。これによって、VPDポリシーで保持されるメタデータは、表明されたトリプルに必要な情報が存在しない場合でも完全で、データ・アクセス制約とメタデータを保持するVPDポリシーは、自己完結型で外部の依存性なしに移行できることが保証されます。

特定のデータ・アクセス制約とRDFメタデータの指定があるVPDポリシーは、RDFモデルに格納されたデータのアクセス制限を実施するために使用できます。モデルに対して発行された各SPARQL問合せは、その問合せでアクセスされるリソースのクラス情報を推測するために分析され、適切なデータ・アクセス制約が適用されます。インスタンス・データのクラス情報のコンパイル時間分析および導出を容易にするため、バインドされていない述語のあるグラフ問合せパターンは、VPDポリシーが有効な場合は制限されます。たとえば、次の形式のグラフ・パターンがSPARQL問合せパターンのいずれかの場所に存在する場合、基礎となるモデルにVPDポリシーが含まれると例外が発生します。

{ <contract:projectHLS>  ?pred  ?obj }

VPDポリシーは、SPARQL構文に表現されたSEM_MATCH問合せに対してのみ実施されます。データ・アクセスの他のすべての形式(グラフ・パターンの従来の構文またはモデル・ビューに対する直接問合せなど)は、許可されません。

C.1.1 RDFデータのVPDポリシー

RDFデータのVPDポリシーは、1つ以上のRDFモデルに格納されたデータに対してアクセス制限を実施するために使用できる名前付きディクショナリ・エンティティです。RDFデータに定義されたVPDポリシーは、一意の特性を持ち、リレーショナル・データにセキュリティ・ポリシーを実施するために再利用できません。データベースに定義されるRDF-VPDポリシーは次のとおりです。

SPARQLユーザー問合せで参照されるデータのクラス情報を導出するために必要なRDFスキーマ文またはメタデータ
インスタンス・データに対してアクセス制限を実施するデータ・アクセス制約
実行時環境に基づいてデータ・アクセス制約のグループの条件付き組込みを可能にするアプリケーション・コンテキスト

RDF-VPDポリシーは、組織のセキュリティ管理者ロールを持つユーザーによって、定義、所有および管理されます。このユーザーは、少なくともSYS.DBMS_RLSパッケージに対するEXECUTE権限を持っている必要があります。RDF-VPDポリシーの所有者は、ポリシーに関連付けられたメタデータを管理し、新しいデータ・アクセス制約を定義して、1つ以上のRDFモデルにポリシーを適用できます。

VPDポリシーを持つRDFモデルで発行されるSPARQL問合せは、分析され、問合せ結果として戻されるデータ・インスタンスがこれらの制約も満たすように、ポリシーで定義される0個以上のデータ・アクセス制約が実施されます。問合せで参照されるリソースおよびアプリケーション・コンテキストに基づいて、ユーザー問合せに対して実施される的確なデータ・アクセス制約は変わります。たとえば、マネージャのアクセスをhasContractValueプロパティに制限するポリシーを、部長ロールを持つユーザーに対しては緩和する場合があります。

適用される特定の制約は、アプリケーション・コンテキストで取得されるユーザーのロールに基づいて実行時に決定されます。VPDポリシーで定義された制約のサブセットの動的な組込みを容易にするため、データ・アクセス制約は、アプリケーション・コンテキストに基づいてアクティブ化および非アクティブ化できる名前付きグループに分類されます。問合せの分析中は、アクティブなグループに定義されている制約のみが実施対象とみなされます。

VPDポリシー内の制約グループは、アプリケーション・コンテキストおよびそのパッケージ実装を使用して管理されます。各VPDポリシーは、CREATE CONTEXTコマンドで作成されるコンテキストに対して名前空間を指定できます。そのコンテキストに関連付けられる各属性は、制約グループの名前として取り扱われ、その属性の値を1に初期化することでアクティブにできます。たとえば、VPDポリシーに関連付けられているコンテキストのMANAGER属性の値を1に設定すると、ユーザー・セッションのMANAGERグループに関連付けられている制約がアクティブ化されます。ユーザー・コンテキストに基づいて特定の制約グループを初期化するロジックは、通常、コンテキスト・タイプに関連付けられるパッケージに組み込まれます。次の例に、このようなパッケージのサンプル実装からの抜粋を示します。

CREATE CONTEXT contracts_constr_ctx using sec_admin.contracts_ctx_pack;
 
begin
  -- create the VPD policy with a context -- 
  sem_rdfsa.create_vpd_policy(policy_name    => 'CONTRACTS_POLICY',
                              policy_context => 'contracts_constr_ctx');
end;
/
 
create or replace package sec_admin.contracts_ctx_pack as
  procedure init_constr_groups;
end;
/
 
create or replace package body sec_admin.contracts_ctx_pack as
  procedure init_contr_groups is 
    hrdata EmpRole%rowtype; 
  begin
    -- specific users with FULL access to the data associated with 
    -- the policy -- 
    if (sys_context('userenv', 'session_user') = 'RDF_ADMIN') then 
      dbms_session.set_context('contracts_constr_ctx',
                                sem_rdfsa.VPD_FULL_ACCESS, 1); 
      return;
    end if; 
 
    SELECT * into hrdata FROM EmpRole WHERE guid = 
                          sys_context('userenv','session_user');
 
    if (hrdata.emprole = 'VP') then 
      -- if the user logged in has VP role, activate the constraint
      -- group named VP and keep all other groups inactive. 
      dbms_session.set_context('contracts_constr_ctx','VP', '1'); 
    elsif (hrdata.emprole = 'MANAGER') then 
      dbms_session.set_context('contracts_constr_ctx', 'MANAGER', '1'); 
    elsif ...
      ...  
    else 
      raise_application_error(-20010, 'unknown user role'); 
    end if;
 
  exception when others then 
    -- enforce constraints for all groups --
    dbms_session.clear_all_context('contracts_constr_ctx');
  end init_contr_groups; 
end;
/

デフォルトでは、名前空間がRDF-VPDポリシーに関連付けられていない場合、または特定の制約グループがセッションでアクティブ化されていない場合、ポリシーに定義されたすべての制約がアクティブになり、各ユーザー問合せに実施されます。ただし、対応する名前空間属性の値を1に設定して特定の制約グループをアクティブ化すると、そのグループに属している制約と、任意のグループに関連付けられていない他の制約のみが実施されます。特定のセッションでは、1つ以上の制約グループがアクティブ化されることがありますが、その場合、適用可能なすべての制約が結合して実施されます。

作成時に、RDF-VPDポリシーに定義されたデータ・アクセス制約によって、制約グループの名前を指定できます(「データ・アクセス制約」を参照)。データベース・セッション内で、コンテキスト・パッケージによって設定されたセッション・コンテキストに基づいて、制約の適切なグループがアクティブ化されます。データベース・セッションの後続のすべてのSPARQL問合せでは、適切なセキュリティ・ポリシーを実施するために、アクティブなグループに属している制約が参照されます。

VPDポリシーを持つRDFモデル上のメンテナンス操作では、モデルのデータへの無条件のアクセスが必要です。この操作には、VPDで保護された1つ以上のモデルで使用する伴意の作成、およびロードまたはデータ操作が含まれます。VPDポリシーに関連付けられている名前空間に対して予約済の属性を初期化することで、RDFモデルに格納されたデータへの無条件のアクセス権限を付与できます。この予約済の属性はパッケージ定数sem_rdfsa.VPD_FULL_ACCESSで定義され、前の例で示したコンテキスト・パッケージ実装によってRDF_ADMINユーザーに完全なアクセス権限が付与されます。

アプリケーション表に対するDML操作は、VPD制約違反については検証されないため、対応するモデルに対する完全なアクセス権限を持つユーザーのみが、既存のトリプルを追加または変更できます。

SEM_MATCH演算子を使用すると、標準のSQL問合せでVPDポリシーのあるRDFモデルを問い合せることや、VPD対応のモデルとVPDポリシーのないモデルの組合せに対してマルチモデル問合せを実行することができます。ただし、マルチモデル問合せの複数のモデルがVPD対応の場合、それらはすべて同じVPDポリシーに関連付けられている必要があります。RDFモデルに関連付けられたVPDポリシーは、モデルから推論された任意のデータに自動的に拡張されます。推論中に複数のRDFモデルが指定される場合、そのセット内のすべてのVPD対応モデルで同じVPDポリシーを使用する必要があります。

C.1.2 VPDポリシーを実施するためのRDFメタデータ

VPDポリシーを実施するために使用されるRDFメタデータのタイプは、次のとおりです。

グラフで使用されるプロパティのドメインおよびレンジ情報
グラフのサブクラス関係
グラフのサブプロパティ関係
グラフの等価プロパティ

VPDポリシーに関連付けられているRDFメタデータは、次のプロパティURIのいずれかを使用して、1つ以上のRDFスキーマ文として指定されます。

http://www.w3.org/2000/01/rdf-schema#domain
http://www.w3.org/2000/01/rdf-schema#range
http://www.w3.org/2000/01/rdf-schema#subClassOf
http://www.w3.org/2000/01/rdf-schema#subPropertyOf
http://www.w3.org/2002/07/owl#equivalentProperty

たとえば、contracts_policyに関連付けられている次のRDFスキーマ文は、hasContractValueプロパティのドメインがContractクラスであると表明します。述語のレンジ指定は、それらが関連しない場合、またはリテラル・タイプの場合にスキップできることに注意してください。

begin
  sem_rdfsa.maint_vpd_metadata(
        policy_name => 'contracts_policy',
        t_subject   => '<http://www.myorg.com/pred/hasContractValue>',
        t_predicate => '<http://www.w3.org/2000/01/rdf-schema#domain>',
        t_object    => '<http://www.myorg.com/classes/Contract>');
end;
/

RDF-VPDポリシーによって、表明および推論されたトリプルから独立してメタデータを管理します。このメタデータは、RDFモデルおよび対応する伴意からプログラム的に導出できます。たとえば、プロパティのドメインおよびレンジ情報と、サブクラスおよびサブプロパティの関係が、表明または推論されたトリプルにすでに確立されている場合、基礎となるモデル・ビューに対するSQL問合せを使用して、RDF-VPDポリシーのメタデータを移入できます。

プロパティのドメインおよびレンジ情報は、問合せで参照される用語および非バインド変数のRDFクラス・タイプを問合せ分析で決定する場合に役立ちます。さらに、この情報は、問合せでアクセスされるデータに対して適切なデータ・アクセス制約を実施する場合に使用されます。サブクラス・プロパティに関連するメタデータの使用によって、クラス階層内の特定のクラスに定義されたデータ・アクセス制約がそのすべてのサブクラスに自動的に実施されることが保証されます。同様に、VPDポリシーのサブプロパティ指定の使用によって、プロパティに関連付けられた制約がそのすべてのサブプロパティに実施されます。

VPDポリシーに関連付けられたRDFスキーマ文は、追加の文を推論するためには使用されないため、セキュリティ管理者は、推論データを使用したクロス・チェックによって、VPDポリシーで取得されたメタデータが完全であることを確認する必要があります。たとえば、サブプロパティ・スキーマ文では、スーパープロパティに指定されたドメインとレンジに基づいて、プロパティのドメインおよびレンジ情報が自動的に推論されることはありません。

表明されたトリプルの特定のOWLおよびRDFSプロパティは、チェックされないままの場合、VPDポリシーを回避するために使用できるデータを推論するために使用される可能性があります。たとえば、新しいプロパティが、特定のデータ・アクセス制約を持つプロパティのスーパープロパティとして定義されている場合、推論データによって、スーパープロパティを使用してサブプロパティのすべてのインスタンスが複製される可能性があります。VPDポリシーでスーパープロパティのアクセス制約を明示的に定義していない場合、推論データを使用して、アクセス制限を回避できます。

新しいデータを推論する機能は完全なアクセス権限を持つユーザーにのみ付与されるため、このようなユーザーは、VPDポリシーに関連付けられるメタデータが新しく推論されるデータを考慮して完全であることを確認する必要があります。具体的には、いくつかの新しいrdfs:subClassOf、rdfs:superClassOf、rdfs:subPropertyOf、rdfs:superPropertyOfまたはowl:equivalentProperty表明が推論中に生成される場合は、VPDポリシーに関連付けられたメタデータを維持する必要があります。また、推論に使用するルールベースによって導入された新規プロパティが機密情報に関連付けられている場合は、ドメインおよびレンジ指定と、データ・アクセス制約が必要にあることがあります。

VPDポリシーでは、プロパティが別のプロパティと等価であると宣言して、元のプロパティに定義された制約と同様に、ドメインおよびレンジ情報を等価プロパティに対して自動的に複製できます。ただし、VPDポリシー内では、別のプロパティと等価であると宣言されたプロパティに追加のメタデータまたはデータ・アクセス制約を直接割り当てることはできません。

C.1.3 データ・アクセス制約

VPDポリシーに関連付けられたデータ・アクセス制約は、実施されるアクセス制限のタイプに基づいて次の2つの一般的なカテゴリに分類されます。

特定のRDFクラスのインスタンスに対するアクセスを制限するもの
特定のRDFプロパティを使用する表明に制限するもの

アクセス制限は、アプリケーション・コンテキストとSPARQL問合せでアクセスされるリソースの特徴に基づいて、条件付きで実施されます。データ・アクセス制約では、リソースに関連付けられるいくつかのプロパティを使用して、アクセスをRDFクラスまたはプロパティのインスタンスに制限します。たとえば、Contractクラスのメンバーであるリソースへのアクセスを、その契約を担当するユーザーのみに制限する(そのリソースに関連付けられているhasMemberプロパティを使用して識別する)ことができます。同様に、リソースのhasContractValueプロパティへのアクセスを、同じリソースに関連付けられるhasManagerプロパティによって契約の管理者として識別されるユーザーに制限できます。

各データ・アクセス制約は、一致パターンおよび適用パターンとして識別される2つのグラフ・パターンを使用して表現されます。制約の一致パターンによって、制約が実施するアクセス制限のタイプが決定され、1つ以上の変数がユーザー問合せでアクセスされる対応するデータ・インスタンスにバインドされます。たとえば、Contractクラスのインスタンスに対して次の一致パターンを定義し、SPARQL問合せでアクセスされるこのようなインスタンスすべてに1つの変数をバインドします。

{ ?contract  rdf:type  <http://www.myorg.com/classes/Contract> }

同様に、RDFプロパティを含む制約の一致パターンは、SPARQL問合せでアクセスされるプロパティのインスタンスと一致し、このようなインスタンスの主語および目的語の位置にあるリソースに2つの変数をバインドします。たとえば、hasContractValueプロパティの制約の一致パターンは、次のように定義します。

{ ?contract  <http://www.myorg.com/pred/hasContractValue>  ?cvalue }

データ・アクセス制約の適用パターンは、一致パターンと一致するリソースを問合せ結果の構築に使用する前に、そのリソースに適用する追加のグラフ・パターンを定義します。データ・アクセス制約の一致パターンで定義された1つ以上の変数は、識別されたリソースでのアクセス制限を実施するために、対応する適用パターンでも使用されます。たとえば、次の一致パターンおよび適用パターンの組合せでは、Andyがアクセス対象の契約の管理者である場合にのみ、契約のhasContractValueにアクセスできるようになります。

Match:  { ?contract  pred:hasContractValue  ?cvalue  }
Apply:  { ?contract  pred:hasManager        emp:Andy }

SPARQL構文で一致パターンおよび適用パターンが表現されているデータ・アクセス制約を、VPDポリシーに追加して、VPDポリシーに関連付けられているRDFモデルに格納されたデータに対してアクセス制限を実施することができます。次の例では、VPDポリシーに制約を追加しますが、そのVPDポリシーがpredおよびemp名前空間接頭辞に関して適切な名前空間マップで定義されていることを前提とします。(名前空間マップをVPDポリシーと関連付けるには、SEM_RDFSA.CREATE_VPD_POLICYプロシージャを使用します。)

begin
  sem_rdfsa.add_vpd_constraint(
          policy_name   => 'contracts_policy',
          constr_name   => 'andy_constraint_1',
          match_pattern => '{?contract  pred:hasContractValue ?cvalue }',
          apply_pattern => '{?contract  pred:hasManager       emp:Andy }', 
          constr_group  => 'andy');
end;
/

データ・アクセス制約をグループにまとめることで、前の制約がAndyに関連付けられているセッションにのみ適用されるようにできます。ただし、各ユーザーで構造的に類似した制約が増えるのを避けるには、次の例に示すように、適用グラフ・パターンの目的語の位置にあるアプリケーション・コンテキストを使用する一般的な制約を定義できます。

begin
  sem_rdfsa.add_vpd_constraint(
          policy_name   => 'contracts_policy',
          constr_name   => 'manager_constraint_1',
          match_pattern => '{?contract  pred:hasContractValue ?cvalue }',
          apply_pattern => '{?contract  pred:hasManager     
             "sys_context(''sa$appctx'',''app_user_uri''}"^^orardf:instruction }',
          constr_group  => 'manager');
end;
/

前の例では、データ・アクセス制約(manager制約グループ内で定義される)を、管理者ロールを持つユーザーが関係するすべてのセッションに対してアクティブにできます。この場合は、sa$appctx名前空間の属性app_user_uriをログインしたユーザーのURIで初期化するために、セキュアなアプリケーション・コンテキストをプログラムできます。たとえば、ユーザーAndyがアプリケーションにログインしたときに、app_user_uri属性を<http://www.myorg.com/employee/Andy>に初期化できます(この場合、制約によって、ユーザーAndyが契約を管理する場合のみ、ユーザーAndyはその契約の値を表示できるようになります)。通常、任意のグラフ・パターンの目的語の位置でsys_contextファンクションを使用して、問合せ実行時に動的なURIまたはリテラル値をバインドすることができます。コンテキストが適切に初期化されない場合、前述の制約がすべてのデータ・インスタンスに対して失敗し、事実上そのユーザーによるどのデータへのアクセスも制限されることに注意します。

VPDポリシーを使用するRDFモデルで発行されるSPARQL問合せは、そのポリシーで定義されるすべてのアクティブなデータ・アクセス制約の一致パターンを使用して分析されます。次の例では、SPARQL問合せがhasContractValueプロパティを参照するため、グループがアクティブの場合に制約が実施されます。論理的に、制約を実施することは、元のSPARQLグラフ・パターンをリライトして、ユーザー問合せからの適切な変数および語句を使用してすべての関連する制約の適用パターンを含めること同等です。hasContractValueプロパティに対して前述のアクセス制限を使用すると、SEM_MATCH演算子に渡される次のSPARQLグラフ・パターンが、次の例に示すように論理的にリライトされます。

Query:     
{ ?contr  pred:drivenBy         ?dept . 
  ?contr  pred:hasContractValue ?val }
 
Rewritten query:     
{ ?contr  pred:drivenBy         ?dept . 
  ?contr  pred:hasContractValue ?val .
  ?contr  pred:hasManager
                "sys_context('sa$appctx','app_user_uri'}"^^orardf:instruction }

RDFプロパティに対するデータ・アクセス制約の一致パターンが、ユーザー問合せでアクセスされるパターンと一致する場合、同等のVPDが適用される問合せによって、一致パターンに出現する変数および語句を使用して、対応する適用パターンがSPARQL問合せに追加されます。SPARQL問合せにネストしたグラフ・パターンがある場合、データ・アクセス制約は適切な基本問合せグラフ・パターン・ブロックに適用されます。次の例では、OPTIONALグラフ・パターンでhasContractValueプロパティが参照され、それによってこのブロックのグラフ・パターンに、対応する適用パターンが実施されます。

Query:     
{ ?contr  pred:drivenBy         ?dept . 
   OPTIONAL { ?contr  pred:hasContractValue ?val } } 
 
Rewritten query:     
{ ?contr  pred:drivenBy         ?dept . 
   OPTIONAL { ?contr  pred:hasContractValue ?val .
              ?contr  pred:hasManager
                "sys_context('sa$appctx','app_user_uri'}"^^orardf:instruction }

データ・アクセス制約の適用パターンは、複数のトリプル・パターンおよびFILTER句を持つ任意の有効な基本グラフ・パターンであることもできます。たとえば、VPロールを持つユーザーのhasContractValueプロパティに対するアクセス制約によって、そのユーザーが契約を進める部門の部長である場合にのみ、このプロパティへのアクセスが許可されることが規定されている場合があります。このような制約の一致パターンおよび適用パターンは、次のように定義できます。

Match:  { ?contract  pred:hasContractValue  ?cvalue  }
Apply:  { ?contract  pred:drivenBy          ?dept . 
          ?dept      pred:hasVP
               "sys_context('sa$appctx','app_user_uri'}"^^orardf:instruction }

RDFクラスに関連付けられるデータ・アクセス制約に定義された一致パターンは、そのクラスのインスタンスであることがわかっているすべての変数および語句を識別します。VPDポリシーで定義されているRDFメタデータを使用して各変数の型およびSPARQL問合せ内の語句が確認され、適切なアクセス制約がこれらの変数および語句に適用されます。たとえば、次のVPD制約によって、Contractクラスのメンバーであるリソースには、そのリソースとhasMember関係を持つユーザーのみがアクセス可能になります。

Match:  { ?contract  rdf:type  <http://www.myorg.com/classes/Contract> }
Apply:  { ?contract  pred:hasMember           
               "sys_context('sa$appctx','app_user_uri'}"^^orardf:instruction }

SPARQL問合せに出現する変数または語句のクラス情報は、問合せに出現するプロパティのドメインおよびレンジ情報を使用して導出されます。VPDポリシーにdrivenByプロパティのドメインはContractクラスであると表明するRDFスキーマ文がある場合、次の例のSPARQL問合せでの変数?contrはContractクラスのインスタンスを保持するとわかります。したがって、次の例に示すように、Contractクラスに対して前に定義したアクセス制限によって、このユーザー問合せは適切な適用パターンを含むようにリライトされます。

Query:     
{ ?contr  pred:drivenBy    ?dept . 
  ?contr  pred:hasDueDate  ?due } 
 
Rewritten query: 
{ ?contr  pred:drivenBy    ?dept . 
  ?contr  pred:hasDueDate  ?due  . 
  ?contr  pred:hasMember           
               "sys_context('sa$appctx','app_user_uri'}"^^orardf:instruction }

SPARQL問合せの基本グラフ・パターンが複数のデータ・アクセス制約に一致する場合、対応する適用パターンは、組み合されて結合グラフ・パターンを構成します(これは、SPARQL問合せを論理的にリライトすることで、後で特定のグラフ・パターンに対して実施されます)。特定のSPARQL問合せに対して実施されるデータ・アクセス制約が考慮される一方で、VPDポリシーに関連付けられたクラスおよびプロパティ階層が参照され、すべての適用可能な制約が自動的に実施されます。

特定のRDFクラスのインスタンスとして識別される変数または用語によって、クラスとそのすべてのスーパークラスに関連付けられている制約が実施されます。
プロパティに関連付けられた制約は、ユーザー問合せによって、そのプロパティ(またはそのサブプロパティや等価プロパティとして定義されたプロパティ)が参照される場合に実施されます。

データ・アクセス制約のsys_contextファンクションを使用すると、構造的に類似したグラフ・パターンを持つコンテキスト依存のアクセス制限を実施できます。構造的に異なるグラフ・パターンを使用して代替アクセス制限を実施するには、アプリケーション・コンテキストに基づいて、制約グループを動的にアクティブ化および非アクティブ化できます。

C.1.4 RDFVPD_POLICIESビュー

MDSYS.RDFVPD_POLICIESビューには、スキーマに定義されているすべてのVPDポリシーまたはユーザーが完全なアクセス権限を持っているポリシーに関する情報が含まれます。同じポリシーが複数のモデルに関連付けられている場合、ビューにはそのような関連ごとに1つのエントリが含まれます。このビューは、セマンティク・ネットワークとVPDポリシーが作成された後にのみ存在します。

MDSYS.RDFVPD_POLICIESビューには、表C-1に示す列が含まれます。

表C-1 MDSYS.RDFVPD_POLICIESビューの列

列名	データ型	説明
POLICY_OWNER	VARCHAR2(32)	VPDポリシーの所有者。
POLICY_NAME	VARCHAR2(32)	VPDポリシーの名前。
NAMESPACE_MAP	RDF_ALIASES	VPD制約定義で使用される名前空間エントリのマッピング。
CONTEXT_NAME	VARCHAR2(32)	制約グループを管理するために使用されるコンテキストの名前。

C.1.5 RDFVPD_MODELSビュー

MDSYS.RDFVPD_MODELSビューには、RDFモデルとそれに関連付けられたVPDポリシーに関する情報が含まれます。このビューは、セマンティク・ネットワークとVPDポリシーが作成された後にのみ存在します。

MDSYS.RDFVPD_MODELSビューには、表C-2に示す列が含まれます。

表C-2 MDSYS.RDFVPD_MODELSビューの列

列名	データ型	説明
MODEL_NAME	VARCHAR2(25)	モデルの名前。
POLICY_OWNER	VARCHAR2(32)	VPDポリシーの所有者。
POLICY_NAME	VARCHAR2(32)	VPDポリシーの名前。
OPERATION_TYPE	VARCHAR2(9)	VPDポリシーが実施される操作のタイプ: `QUERY`または`DML`。

C.1.6 RDFVPD_POLICY_CONSTRAINTSビュー

MDSYS.RDFVPD_POLICY_CONSTRAINTSビューには、現在のユーザーがアクセスできるVPDポリシーに定義された制約に関する情報が含まれます。このビューは、セマンティク・ネットワークとVPDポリシーが作成された後にのみ存在します。

MDSYS.RDFVPD_POLICY_CONSTRAINTSビューは、表C-3で表示される列を含みます。

表C-3 MDSYS.RDFVPD_POLICY_CONSTRAINTSビューの列

列名	データ型	説明
POLICY_OWNER	VARCHAR2(32)	VPDポリシーの所有者。
POLICY_NAME	VARCHAR2(32)	VPDポリシーの名前。
CONSTRAINT_NAME	VARCHAR2(32)	制約の名前。
MATCH_PATTERN	VARCHAR2(1000)	制約の一致パターン。
APPLY_PATTERN	VARCHAR2(4000)	制約の適用パターン。
CONSTRAINT_GROUP	VARCHAR2(32)	制約が属している制約グループの名前。(大/小文字は区別されません。)

C.1.7 RDFVPD_PREDICATE_MDATAビュー

MDSYS.RDFVPD_PREDICATE_MDATAビューには、VPDポリシーに関連付けられた述語メタデータに関する情報が含まれます。このビューは、セマンティク・ネットワークとVPDポリシーが作成された後にのみ存在します。

MDSYS.RDFVPD_PREDICATE_MDATAビューには、表C-4に示す列が含まれます。

表C-4 MDSYS.RDFVPD_PREDICATE_MDATAビューの列

列名	データ型	説明
POLICY_OWNER	VARCHAR2(32)	VPDポリシーの所有者。
POLICY_NAME	VARCHAR2(32)	VPDポリシーの名前。
PREDICATE	VARCHAR2(4000)	ドメインおよびレンジ情報が定義されている述語のURI。
HASDOMAIN	VARCHAR2(4000)	述語のドメインを表すURI。
HASRANGE	VARCHAR2(4000)	述語のレンジを表すURI。

C.1.8 RDFVPD_RESOURCE_RELビュー

MDSYS.RDFVPD_RESOURCE_RELビューには、VPDポリシーのリソース間に定義されているサブクラス、サブプロパティおよび等価プロパティの関係に関する情報が含まれます。このビューは、セマンティク・ネットワークとVPDポリシーが作成された後にのみ存在します。

MDSYS.RDFVPD_RESOURCE_RELビューには、表C-5に示す列が含まれます。

表C-5 MDSYS.RDFVPD_RESOURCE_RELビューの列

列名	データ型	説明
POLICY_OWNER	VARCHAR2(32)	VPDポリシーの所有者。
POLICY_NAME	VARCHAR2(32)	VPDポリシーの名前。
SUBJECT_RESOURCE	VARCHAR2(4000)	主語リソース。
OBJECT_RESOURCE	VARCHAR2(4000)	目的語リソース。
RELATIONSHIP_TYPE	VARCHAR2(4000)	主語リソースと目的語リソースの間に存在する関係。