最初の SQL ステートメント¶

データソースの構成で、実際のクエリを実行する前にデータソースが実行する SQL ステートメントを指定できます。つまり、実行エンジンがこのデータソースでクエリを実行するたびに、このデータソースは、実際のクエリの直前に、その 最初の SQL ステートメント を実行します。データソースが最初のステートメントを実行するのに使用するコネクションは、実際のクエリと同じです。

これは、データベースのセッション属性を初期化するのに役立ちます。

最初の SQL ステートメント を定義するには、データソースの構成で [Initial SQL sentences] をクリックし、ステートメントを入力します。これらのステートメントには補間変数 (@VARIABLE_NAME など) を含めることができます。補間変数は、実行時にクエリのコンテキストで取得可能な変数値で置き換えられます。

これらのステートメントで参照されているすべての変数に対応する値が実行コンテキストに含まれていない場合、どのステートメントも実行されません。

実行エンジンは、以下の補間変数を自動的にクエリの実行コンテキストで定義します。

クエリのコンテキストで追加の変数を定義する方法を以下に示します。

1. 関数 SETVAR を使用する。

2. Resource Manager を使用する。クエリのコンテキストに変数を追加する「制限」を使用して「プラン」を定義する方法については、「 プランの定義 」のページを参照してください。

3. クエリの CONTEXT 句に追加する。以下に例を示します。

   SELECT *
   FROM customer360
   CONTEXT('var ds_jdbc_accelerator' = '1')
   

複数の方法を使用して変数を定義している場合、上記の順序が変数を置き換える優先順位になります。

SQL ステートメントでこれらのカスタム変数を参照できます。

コネクションプール¶

データベースへのコネクションを最適化するために、Virtual DataPort は、デフォルトでデータソースごとにデータベースへのコネクションプールを 1 つ作成します (JDBC データソースごとにプール 1 つ)。このプールを用意すると、コネクションがすでに開いているので、このデータベースにクエリを送信するたびに新しいコネクションを開く必要がないという利点が得られます。これにより、クエリの応答時間が短くなります。

このコネクションプールの詳細については、『VQL ガイド』の「 JDBC データソースのコネクションプール 」で、以下の情報を参照してください。

• VQL ステートメントでのみ変更可能で、グラフィカルな方法では変更できないプール設定情報

• Denodo サーバーを実行しているホストとデータベースの間にファイアウォールが存在する場合に有効にする必要があるオプション

[Connections Pool Configuration] ダイアログを開いて、Virtual DataPort が外部データベースへのアクセスを最適化するために使用するコネクションプールの各種パラメータを構成します。

• Initial Size: プールの初期化に使用するコネクション数。この数のコネクションを確立し、「アイドル」状態にして、いつでも使用できるようにします。

  注釈

  [Pass-through session credentials] をチェックしてデータソースを作成した場合、このフィールドに入力した値は無視されます。Virtual DataPort サーバーは、このデータベースに接続するユーザーアカウントごとにコネクションプールを 1 つずつ作成します。不要なコネクションが過剰に作成されないように、プールに最初に用意されるコネクションは、[Initial size] に設定した数ではなく、1 つのみです。

• Maximum number of active connections: このデータベースに対してプールから開く、アクティブなコネクションの最大数。この制限値に到達すると、このデータベースに対するクエリ送信を使用する次のリクエストは、別のクエリが完了するまで待機する必要があります。

  • -1 を入力すると、このデータソースへのアクティブなコネクションの最大数の制限がなくなります。プールに作成するコネクションの数は制限されません。

  • 0 を入力すると、プールが無効になります。

• Ping Query: コネクションプールから返されたコネクションに対して SQL クエリを実行し、返されたコネクションが引き続き有効で、陳腐化していないことを確認します。

• Test Connection: このチェックボックスをチェックし、ping クエリを指定している場合、コネクションプールから取得した各コネクションが ping クエリの実行によって検証されます。

  重要

  コネクションの検証は、[Ping query] フィールドにクエリを 指定している場合にのみ 実行されます。クエリを指定していない場合は、このチェックボックスをチェックしていても検証は実行されません。

[Read & Write] タブ¶

JDBC データソース: [Read & Write] タブ¶

• Fetch size (rows): 多くの行をデータベースからフェッチする必要がある場合に、このオプションは、その行数に関するヒントを JDBC ドライバーに示します。このパラメータはあくまでもヒントにすぎず、ドライバーによっては無視されることがあります。

• Stream tuples (MySQL アダプターを使用する場合のみ): このオプションをチェックした場合、このデータソースのビューに対してクエリを実行すると、MySQL から結果が一度に 1 行ずつ Virtual DataPort サーバーにストリーミング送信されます。チェックしていない場合は、クエリが終了するまで MySQL からはクエリの結果が Virtual DataPort サーバーに送信されません。

  大きなデータセットが返される可能性があるクエリをこのデータソースに対して実行するとき、そのデータセットが Virtual DataPort サーバーの Java 仮想マシンのヒープ領域に収まらない可能性がある場合は、このチェックボックスをチェックします。そのような状況ではない場合は、このチェックボックスのチェックをはずします。実行時間が短くなることが考えられるからです。

• Ignore trailing spaces: このオプションをチェックすると、このデータソースのビューから返される結果のうち、 text 型の値の末尾にある空白文字が Virtual DataPort サーバーによって削除されます。

• Delimiter identifier (optional) (アダプターとして [Generic] を使用する場合のみ): アダプターとして [Generic] を使用する場合、データベースに送信されるクエリで ID を囲む文字はデフォルトで " (二重引用符) です。別の文字を使用するには、その文字をこのボックスに入力します。

• End delimiter identifier (optional) (アダプターとして [Generic] を使用する場合のみ): アダプターとして [Generic] を使用する場合、データベースに送信されるクエリで ID を囲む文字はデフォルトで " (二重引用符) です。別の末尾文字を使用するには、その文字をこのボックスに入力します。このボックスが空で、[Delimiter identifier] ボックスで文字が使用されている場合、その文字が先頭と末尾に使用されます。

• Batch insert size (rows): このデータソースがデータの移動先である場合、Virtual DataPort サーバーによって、別のデータソースから取得したデータがこのデータソースに挿入されます。データを高速で移動するために、複数の INSERT ステートメントがバッチ単位で実行されます。このプロパティの値は、バッチごとに設定する INSERT ステートメントの数です。

  ソースの [Supports batch inserts] 構成プロパティの値が [no] の場合 (デフォルト値は [yes])、この値は無視されます。

  データ移動の詳細については、「 データ移動 」を参照してください。

  このプロパティは、このデータソースの基本ビューに送信される INSERT リクエストには影響しません。そのようなリクエストはバッチ単位では実行されないからです。

• UTF-8 data types: Virtual DataPort サーバーでデータを移動するとき、このデータソースが移動先になる場合、そのデータベースに、他のデータソースから取得するデータを格納するテーブルが Virtual DataPort サーバーによって作成されます。このチェックボックスをチェックする場合としない場合の影響は、テーブルのフィールドの型とサブタイプに応じて異なります。

  • サブタイプが定義されているフィールドの場合、Virtual DataPort サーバーによってターゲットテーブルにそのフィールドが定義されるときに、そのサブタイプが使用されます。たとえば、テキストフィールドのサブタイプが VARCHAR で、そのサイズが 200 の場合、そのフィールドは VARCHAR(200) として定義されます。

  • サブタイプが定義されていないフィールドの場合:

    • フィールドの型が テキストではない 場合、それらを格納するデータ型は、このチェックボックスをチェックしているかどうかに関係なく、必ず元の型と同じです。Virtual DataPort サーバーは、キャッシュに使用するデータベースに応じて適切な型を使用しますが、同じデータベースであれば元と同じ型になります。

    • サブタイプが定義されていないテキスト型フィールドの場合は、以下のどちらかになります。

      1. [UTF-8 data types] を チェックしている 場合、Virtual DataPort サーバーは、ターゲットテーブルにフィールドを定義する際に、すべての UTF-8 文字を格納できるデータ型を使用します。これらのデータ型は、標準のテキストデータ型よりもデータベースで多くの領域を使用します。

      2. [UTF-8 data types] を チェックしていない 場合、フィールドは VARCHAR として定義されます。

  フィールドにサブタイプが定義されているかどうかは、ビューの [Summary] タブで [Field type] 列のヒントに表示されます。フィールド型 (int、text、date など) のみが表示される場合、サブタイプは定義されていません。ヒントに [Source type properties] ラベルも表示される場合、フィールドのサブタイプが定義されています。

  すべての UTF-8 文字を格納できるデータ型は、データベースでより多くのディスク領域を使用します。

• Use external tables for data movement (Netezza データベースのデータソースでのみ使用可能): このオプションをチェックすると、データ移動の際に、Virtual DataPort によって Netezza の「外部テーブル」機能が使用され、データが Netezza データベースに転送されます。

  すべての Netezza データソースで、その [Read settings] 設定と [Write settings] 設定の両方をチェックする必要があります。

  データ移動については、「 データ移動 」を参照してください。

  データ移動のターゲットが Netezza データベースの場合の Virtual DataPort の動作については、「 Netezza データベースとの間でのデータ移動 」を参照してください。

• Use Bulk Data Load APIs (一部のデータベースアダプターの場合にのみ使用可能): このオプションをチェックすると、このデータベースがデータ移動のターゲットになる場合、Virtual DataPort では、 INSERT ステートメントを実行するのではなく、データベースの独自 API を使用してデータをデータベースに読み込みます。

  Virtual DataPort によるこれらの API の使用については、「 データ一括読み込み 」を参照してください。

• Manage CREATE TABLES templates (一部のデータベースアダプターの場合にのみ使用可能): Denodo では、キャッシュ、データ移動、リモートテーブル、サマリテーブルで使用するテーブル作成コマンドをカスタマイズする SQL コマンドテンプレートをサポートしています。テンプレートは、いくつかのパラメータを指定する CREATE TABLE SQL ステートメントで、Denodo では文を実行する前にそのパラメータの値に置き換えます。

  テーブルの作成を管理する方法については、「 テーブル作成テンプレートの管理 」を参照してください。

• Query optimization settings (一部のデータベースアダプターの場合にのみ使用可能): 以下に示すオプションでは、他のデータソースから取得したデータを、クエリオプティマイザーでこのデータベースに挿入できるようにするかどうかを制御します。このように挿入することにより、より多くの操作を、ローカルで実行するのではなく、Virtual DataPort サーバーでこのデータベースにプッシュできるようになります。

  • Do not allow Denodo to create temporary tables in the data source for query optimization: クエリオプティマイザーは、クエリを実行するためにこのデータベースにデータを移動しません。

  • Allow creating temporary tables, only for the data movement optimization: このオプションをチェックすると、クエリオプティマイザーでは、 データ移動 先としてこのデータソースを選択できます。

  • Allow creating temporary tables to allow parallel processing of any operation (一部の並列データベースの場合専用): このオプションをチェックすると、オプティマイザーでは、データ移動先としてこのデータソースを選択できます。また、 大規模な並列処理 をこのデータベースにプッシュダウンするために、データを格納する一時テーブルを作成できます。このオプションをチェックする場合は以下の点を確認します。

    1. Virtual DataPort サーバーとデータベースとの間でデータを高速で転送できるように、両方のシステムを同じネットワークセグメントに置いていること。

    2. できる限り高速でデータがこのデータベースに挿入されるように、このデータソースに対して [Use bulk data load APIs] チェックボックスをチェックしていること。

[Source Configuration] タブ¶

このタブが表示されるのは、新しいデータソースを作成するときではなく、データソースを編集するときのみです。

このタブでは、以下のようなデータソースの固有の動作を構成できます。

• データベースにどの操作を委任するか (Virtual DataPort で実行するのではなく、データベースで実行する操作)

• このデータソースでどの操作をサポートするか

これらのプロパティの詳細については、「 データソース構成プロパティ 」を参照してください。

JDBC データソース: [Source Configuration] タブ¶

[Metadata] タブ¶

[Metadata] タブで以下の操作を実行できます。

• データソースの格納先 フォルダ を設定します。

• 説明 を入力します。

• データソースがデプロイされる インフラストラクチャ 情報を設定します。インフラストラクチャのプロバイダー名 (オンプレミス、Amazon Web Services、Microsoft Azure、Google Cloud Platform など) とリージョン名を設定できます。プロバイダー名やリージョンがリストにない場合は、カスタム名を入力できます。

データソースを編集する際、 ボタンをクリックすると、その所有者も変更できます。

このダイアログのパラメータをすべて入力した後、[Test connection] をクリックします。「 The Denodo Platform does not include the JDBC driver for this adapter 」のようなメッセージが表示された場合は、JDBC ドライバーの jar ファイルを Virtual DataPort にアップロードする必要があります。このアップロードは、[File] > [Extensions management] メニューのウィザードから実行しますが、その手順については、「 JDBC ドライバーのインポート 」を参照してください。

Amazon Athena と PrestoDB/Trino¶

Amazon Athena と PrestoDB/Trino では、データ型の暗黙的なキャストをサポートしていないので、数値フィールドとテキストフィールドを比較することはできません。この制限は、フィールドをリテラルと比較する場合やフィールドを別のフィールドと比較する場合に発生します。リテラルどうしの比較ではクエリが正しく実行されます。この制限を解決するには、どちらかの値を正しい型にキャストします。

たとえば、以下のスキーマを持つテーブル customer を考えます。

[id] フィールドは VARCHAR (テキスト)、値 200 は整数なので、以下のクエリは失敗します。

SELECT *
FROM customer
WHERE id < 200;

このクエリが正しく動作するためには、クエリを変更するか、ビューの定義を変更して、データソースに委任されるクエリが以下のようになるようにします。

SELECT *
FROM customer
WHERE CAST(id as integer) < 200;

PrestoDB は、Virtual DataPort からのメタデータとスキーマの直接操作もサポートしています。詳細については、ストアドプロシージャの COMPUTE_SOURCE_TABLE_STATS 、 REFRESH_SOURCE_TABLE_METADATA 、 CREATE_SCHEMA_ON_SOURCE 、 DROP_SCHEMA_ON_SOURCE 、 ROLLBACK_ICEBERG_VIEW_TO_SNAPSHOT 、および GET_ICEBERG_VIEW_SNAPSHOTS の説明を参照してください。

Amazon Redshift¶

Redshift を参照するデータソースの構成で、ドライバーのプロパティ「enableFetchRingBuffer」を「false」に設定することをお勧めします。これは、Redshift データソースで明示的にこのプロパティが有効になっていない場合は自動的に設定されます。

デフォルトでは、Amazon Redshift の JDBC ドライバー (バージョン 2.x) は、クエリの結果をフェッチするために別のスレッドを作成します。デフォルトでは、これらのスレッドはそれぞれクエリあたり最大 1 GB の情報を保存できます (このバッファの最大サイズはドライバーのプロパティ「fetchRingBufferSize」で制御します)。

同時クエリでは、この機能により Virtual DataPort サーバーで OutOfMemoryError が発生する可能性があるので、この機能を無効にすることをお勧めします。

これらのドライバーのプロパティの詳細については、 Amazon Redshift のドキュメント を参照してください。

Apache Impala¶

Impala には、複合データのデータ型からデータを取得する際にいくつかの制限事項があります。Impala クエリの結果セットは、常にスカラー型である必要があります。これは、複合フィールドのエレメントにアクセスするには、各エレメントが事前に「パッケージ化解除」されている必要があることを意味します。

また、Impala は、配列のデータにアクセスするために別の構文を使用しますが、これは VQL 構文と互換性がありません。そのため、Denodo から配列データにアクセスできなくなります。

構造データにアクセスするには、データソースの構成で 「Delegate compound projection」 プロパティが true に設定されていることを確認する必要があります。プロパティの意味については、管理ガイドの「 データソース構成プロパティ 」を参照してください。

• complex_table というテーブルの struct という struct 型フィールドが、field_text と field_int の 2 つのサブフィールドで構成されているとします。このデータにアクセスする場合、以下の SELECT ステートメントを実行する必要があります。

SELECT struct.field_text , struct.field_int
FROM complex_table;

• 複合型のフィールドが「パッケージ化解除」されていない場合、以下のようなクエリは エラー を返します。

SELECT struct
FROM complex_table;

Cassandra¶

Cassandra に用意されているドライバーの制限によって、UUID 型のフィールドを使用した WHERE 条件を持つクエリは失敗します。ただし、この型の値を取得する操作は正常に動作します (この値はテキスト値として処理されます)。

Elasticsearch¶

Elasticsearch には、以下の制限があります。

• GROUP BY の結果に対するフィルタ処理: Elasticsearch は、GROUP BY を使用したサブクエリを持つクエリをサポートしていません。そのクエリでは、GROUP BY で使用されている各フィールドの値が投影されます。

  たとえば、 test ビューに以下のフィールドが存在するとします。

以下のクエリは失敗します。

SELECT *
FROM (
    SELECT id
    FROM TEST
    GROUP BY id
)
WHERE id = 3

詳細については、https://github.com/elastic/elasticsearch/issues/36939 を参照してください。

• 空の結果セットの集計: 行が存在しない結果セットに集計関数 sum を適用すると、 null ではなく、0 が返されます。

たとえば、前述のように定義した test テーブルの場合、以下のクエリは null の代わりに 0 を返します。

  SELECT SUM(id)
  FROM TEST WHERE id = 400;


Find more information at https://github.com/elastic/elasticsearch/issues/31887

• COUNT による Null 値のカウント: 6.6.0 よりも前のバージョンの Elasticsearch では、集計関数 count(column) で、本来無視されるべき null 値がカウントされます。

• 関数の Null 結果値の比較: WHERE 句に使用したスカラー関数や HAVING 句に使用した集計関数に Null 値を適用して得られた結果を、 is null 演算子または is not null 演算子で比較すると、正常に動作しません。

  たとえば、前述のように定義した test テーブルの場合、以下は正常に動作しません。

  -- It returns 0 rows but it should return 1
  SELECT id, AVG(id) FROM TEST GROUP BY id HAVING AVG(id) IS NULL;
  

  -- This query returns four rows but it should return three.
  SELECT id, AVG(id) FROM TEST GROUP BY id HAVING AVG(id) IS NOT NULL;
  

詳細については、https://github.com/elastic/elasticsearch/issues/35139 を参照してください。

• 演算子:

  • LIKE: 修飾子 "analyzer": "keyword" を使用してテキストフィールドを定義していれば、この演算子は想定どおりに動作します。フィールド解析では、個々の項が別々に考慮される (テキストフィールドを定義する場合のデフォルトの動作) のではなく、テキスト全体が考慮されるからです。

• 日付/時刻パターンのカスタマイズ: Elasticsearch は、日時型のデフォルトパターンを定義しています (以下の表の「デフォルトパターン」列を参照)。

  Elasticsearch の日時型のパターン¶

  フィールド型	デフォルトパターン	プロパティ名
  localdate	yyyy-MM-dd	com.denodo.vdb.engine.wrapper.raw.jdbc.adapter.plugins.ElasticSearchPlugin.LocalDatePattern
  time	HH:mm:ss.SSS	com.denodo.vdb.engine.wrapper.raw.jdbc.adapter.plugins.ElasticSearchPlugin.TimePattern
  timestamp	yyyy-MM-dd HH:mm:ss.SSS	com.denodo.vdb.engine.wrapper.raw.jdbc.adapter.plugins.ElasticSearchPlugin.TimestampPattern
  timestamptz	yyyy-MM-dd HH:mm:ss.SSS XXX	com.denodo.vdb.engine.wrapper.raw.jdbc.adapter.plugins.ElasticSearchPlugin.TimestampZPattern
  date (廃止)	yyyy-MM-dd HH:mm:ss.SSS	com.denodo.vdb.engine.wrapper.raw.jdbc.adapter.plugins.ElasticSearchPlugin.DatePattern

  上記以外のパターンを使用するように構成された Elasticsearch のデプロイ環境では、Virtual DataPort をそのパターンに合わせて構成します。そのためには、VQL シェルを開いて以下のコマンドを実行します。

  SET '<property>' = '<new value>'
  

  このコマンドの「<property>」を、前述の表の「プロパティ名」列の値に置き換えます。このコマンドはただちに適用されるので、システムを再起動する必要はありません。

  以下に例を示します。

  SET 'com.denodo.vdb.engine.wrapper.raw.jdbc.adapter.plugins.ElasticSearchPlugin.TimestampPattern' = 'dd/MM/yyyy HH:mm';
  

  適切なパターンの生成については、「 日付と時間のパターン文字列 」を参照してください。

IBM DB2¶

データベースが AS/400 上で動作している IBM DB2 の場合、データベースのデフォルトの照合順序が「バイナリ」であることを確認します。この照合順序がバイナリではない場合は、[Source configuration] タブに移動して、[Supports binary ORDER BY collation] プロパティを [no] に設定します。この措置を実行しないと、このソースから取得したデータをマージ結合するクエリでは、正しくない結果が得られる可能性があります。IBM DB2 では、DB2_COMPATIBILITY_VECTOR を使用して、LIMIT 句と OFFSET 句のサポートを有効または無効にできます。このソースで LIMIT と OFFSET が無効の場合は、[Source configuration] タブに移動して、[Delegate FETCH as LIMIT clause] プロパティを [no] に、[Delegate OFFSET clause] プロパティを [no] に、それぞれ設定します。

Informix¶

11.70.FC7W2 および 12.10.xC2 では、日付形式の命名規則に関する Informix のデフォルトの動作が変更されたため、下位互換性が失われ、不正な日付パターンの委任が生じます。

使用する Informix のバージョンが 11.70.FC7W2 または 12.10.xC2 以上の場合、日付パターンの委任を適切に行うには、構成パラメータを設定する必要があります。

構成プロパティを設定するには、以下のコマンドを実行します。

SET 'com.denodo.vdb.engine.wrapper.condition.informix.includeDotBetweenSecondAndFraction' = 'true';

このコマンドはすぐに適用されるため、Virtual DataPort サーバーを再起動する必要はありません。

Azure Synapse SQL¶

ここでは、「Azure Synapse SQL」データベース (旧称「Azure SQL Data Warehouse」) について説明します。このデータベースのデータソースを作成する場合、以下の点を考慮してください。

• Azure Synapse SQL 内部でデータベースごとに新しいデータソースを作成する必要があります。どのデータソースでも、それが存在する Azure Synapse SQL の同じデータベースにあるテーブルやビューにのみクエリを実行できます。

• INSERT ステートメントの値の式には定数リテラル値のみを記述できます。たとえば、以下のステートメントは失敗します。

  INSERT INTO table_name(int_column) VALUES (1+1);
  

• このソースは、 LIKE 演算子の ESCAPE 句をサポートしません。このような句を使用したクエリは失敗します。

• DDL ステートメント (テーブルを作成、変更、または削除するステートメント) は、トランザクションの中では実行できません。たとえば、トランザクションでは、このデータベースにリモートテーブルを作成できません。

• このデータソースの分離レベルは変更できません。このデータベースはダーティリードのみをサポートします。

Microsoft SQL Server¶

jTDS アダプターを使用し、JDBC データソースを作成して [Pass-through session credentials] オプションをチェックした場合、Virtual DataPort では、ユーザーの代わりに Microsoft SQL Server にログインするために、ユーザーのドメインも使用します。

ユーザーがドメインを付加して (user_name@domain など) Virtual DataPort にログインし、このデータソースを使用するクエリを実行すると、Virtual DataPort では、このユーザーの代わりに SQL Server にログインするために、付加されたドメインを使用します。ユーザーがドメインを付加しない場合 (user_name など)、Virtual DataPort ではユーザー名とパスワードのみを使用します。この場合は、ドメインの指定が必須ではないか、データソースの URL でドメインを指定する必要があるかのどちらかです。

管理者がデータソースの URI にドメインを付加していても、ユーザーがドメインを付加して (ユーザー名として user@acme.com を入力) ログインすると、ユーザーが入力したドメインが、データソースに設定されたドメインより優先されます。

Microsoft SQL Server でパススルーセッション資格情報を使用するには、Windows 認証ではなく、ログインとパスワードに基づく認証を使用するように Microsoft SQL Server を構成する必要があります。

Oracle¶

Oracle への接続 URL には、この形式で URL を入力します。

jdbc:oracle:thin:@<host>[:<port>]/<service>

他の形式を使用する場合、 Oracleへのデータ一括読み込み に失敗することがあります。

管理ツールのウィザードで JDBC の基本ビューを作成すると、データソースでは、インポートするテーブルやビューの各列の説明を取得しようとします。つづいて、その説明を新しい基本ビューの各フィールドに設定することで、それらのフィールドが、基盤となるデータベースと同じ説明になるようにします。

データベースに Oracle を使用していて、上記のような説明を取得する場合、 remarksReporting ドライバープロパィテの値を true に設定します。このように設定しないと、Oracle はデフォルトではこれらの説明を返さないので、説明がインポートされません。

Oracle からデータを取得する JDBC データソースを作成して、そのデータソースでそのシノニムを表示する必要がある場合は、 includeSynonyms プロパティを追加して、その値を true に設定します。

Oracle 内のテーブルの列またはビューに LONG RAW 型が存在する場合、また基本ビューで、この列の型を text に設定する場合、この基本ビューのデータソースを編集します。さらに、 [Driver properties] ダイアログで「useFetchSizeWithLongColumn」を「true」に設定します。そうしない場合、データソースはこの値を取得できません。

JDBC データソースでは、Oracle に対するコネクションを開いた直後に、そのコネクション上で以下のコマンドを実行します。

ALTER SESSION SET NLS_DATE_FORMAT= 'YYYY-MM-DD';

このコマンドを実行することによって、日時値のパターンが Oracle の構成に依存しなくなります。SQL クエリから基本ビューを作成する場合、この SQL クエリの日時フィールドに対する条件を、パターン「YYYY-MM-DD」 (<year>-<month>-<day>) に従って指定する必要があります。たとえば、 hire_date >= DATE '2018-02-03' と指定します。

SAS¶

Spark SQL¶

デフォルトでは、Spark SQL アダプターを使用するデータソースに対してコネクションプールが無効になります ([Initial size] フィールドと [Maximum number of active connections] フィールドの値が 0 になります)。

セッションレベルの Spark Parquet メタデータキャッシュの特性上、セッションに対して実行するクエリは、そのセッションの開始後に追加されたデータにはアクセスできません。クエリが必ず最新のデータにアクセスできるように、コネクションプールは無効になっています。

プールでコネクションを再利用できるようにすると、マルチセッションモードを有効にした Thrift サーバーの最新データに、クエリがアクセスできなくなることがあります。詳細については、Spark のドキュメントを参照してください。

Teradata¶

Teradata データベースでは、デフォルトの照合順序をバイナリに設定します。そのように設定しないと、Virtual DataPort が Teradata から取得したデータを使用して (データベースに委任せずに) 実行するマージ結合で正しい結果が得られないことがあります。

デフォルト照合順序をバイナリに設定できない場合は、データソースを作成した後で、データソースのソース構成の Supports binary ORDER BY collation プロパティを no に設定します。

Yellowbrick¶

そのように設定しないと 以下の状況が発生します。

1. Yellowbrick のデータと別のデータソースのデータを使用するマージ結合の結合条件に、Yellowbrick から取得した UTF-8 でエンコードされていない文字が使用されていると正しくない結合結果が得られます。

2. キャッシュデータベースが Yellowbrick である場合、UTF-8 に属していても Yellowbrick が使用する文字セットに属していない文字は失われます。

SAP HANA¶

Denodo は、計算ビューで SAP HANA の入力パラメータと入力変数の両方に対応しています。

SAP HANA 入力パラメータ¶

入力パラメータを含む計算ビューをインポートする場合、それらはイントロスペクションツリーで入力値としてマークされます (以下の図の IP_O_TARGET_CURRENCY フィールドを参照)。

入力パラメータを含む SAP HANA 計算ビューのイントロスペクション¶

入力パラメータを含む基本ビューに対して実行されるクエリは、 SAP HANA 構文 に従って SAP HANA ビューをパラメータ化します。

注釈

Denodo は、入力パラメータの型が Column 、 Derived from table 、または Static List である場合、入力パラメータの指定できる値を取得しません。また、 Direct 入力パラメータである場合、任意の値を受け入れます。渡された値が指定できる値の要件を満たさない場合、SAP HANA はエラーを返します。

実行されたクエリの条件で入力パラメータが使用されていて、その値として単純なリテラルが渡された場合、出力の入力パラメータフィールドにはその値が返されます。そのクエリの条件で入力パラメータに値が割り当てられない場合、クエリ出力にはそのデフォルト値が返されます。

注釈

入力パラメータのデフォルト値は、クエリ結果に出力される際に評価されません。したがって、デフォルト値が式である場合、式はテキスト表現のまま返されます。

条件の入力パラメータに複数の値が渡される場合¶

Denodo は、入力パラメータに IN 条件を使用するクエリの実行をサポートしています。入力パラメータが複数の値を許容する場合、Denodo は PLACEHOLDER 式で条件値を委任します。許容しない場合、Denodo は自動的に、各ブランチで EQ 条件と元の IN 条件の値の 1 つを指定する UNION ステートメントを委任します。以下の 図 でこの挙動を確認できます。

SAP HANA 入力パラメータが複数の値を許容しない IN 条件の委任¶

SAP HANA 入力変数¶

入力パラメータと同様に、Denodo は SAP HANA の計算ビューから入力変数をインポートできます。これらのフィールドは、イントロスペクションツリーで入力値としてマークされます。

クエリが入力変数フィールドに対してフィルタを設定しない場合、Denodo は入力変数のデフォルト値による結果のフィルタリングを行いません。この挙動は、Virtual DataPort サーバーの構成プロパティ com.denodo.vdb.engine.wrapper.raw.jdbc.adapter.plugins.SapHanaPlugin.generateInputVariableDefaultCondition.enabled を使用して変更できます。このプロパティが有効な場合、Denodo は自動的に入力変数のデフォルト値を使用して条件を生成します。

以下の 図 では、クエリでフィルタが設定されていないため、Denodo が自動的に入力変数のデフォルト値を適用している挙動を確認できます。

入力変数にそのデフォルト値を使用する条件の実行¶

汎用アダプター¶

固有のアダプターが存在しないデータベースに接続する必要がある場合、そのデータベースの多くの部分が、アダプターが存在する別のデータベースに基づいている場合を除いて、アダプターとして Generic を選択します。

「Generic」アダプターを使用する場合、それがこのデータベースに適合するためには、[Source configuration] タブの部分的な設定変更が必要になることがあります。よく見られる問題として、データベースでサポートされていない関数を実行エンジンが実行しようとする状況が考えられます。

[Source configuration] タブの [Delegate scalar functions list] フィールドと [Delegate aggregate functions list] フィールドには、実行エンジンがデータベースにプッシュする関数のリストが表示されます。これらのフィールドに表示される名前は、Virtual DataPort での関数名であり、データベースにプッシュダウンされる関数の名前ではありません。たとえば、 getday 関数は、「Generic」アダプターを使用するデータソースに day としてプッシュダウンされます。

データベースでサポートされていない関数がこのリストにある場合は、以下の手順に従います。

1. データソースを開いて、[Source configuration] タブに移動します。

2. [Delegate scalar functions list] (ダイアログの下部にあります) の横にあるチェックボックスのチェックをはずします。

3. 関数の名前を <name of the function>(evaluate_literal) に 置き換えます 。

   たとえば、データベースで ABS 関数 (数の絶対値を取得する関数) がサポートされていない場合、 abs を abs(evaluate_literal) に置き換えます。

   別の例として、クエリに GETSESSION('user') 関数を使用して、そのクエリを実行したユーザーの名前でフィルタ処理するとします。この関数はどのデータベースにも委任されません。ただし、[Delegate scalar functions list] に getsession(evaluate_literal) を追加すると、「GETSESSION」自体ではなく、その結果がデータベースに委任されます。

このリストで名前に「(evaluate_literal)」を記述した関数が実行エンジンで実行されることはありません。代わりに、クエリがそれらの関数のいずれかを使用していて、入力パラメータがすべて値であるか (ビューのフィールドではないこと)、他の値を使用して構成された式 (たとえば「3 - 5」という式) であれば、実行エンジンによって、式自体ではなく、式の結果がプッシュダウンされます。

たとえば、 abs 関数にこの変更を適用して、以下のクエリを実行したとします。

SELECT abs(-5), id, name
FROM customer;

実行エンジンは abs(-5) を実行し、つづいて以下のクエリをデータベースで実行します。

SELECT 5, id, name
FROM customer

これは Generic アダプターで使用することを意図した方法ですが、どのアダプターでも使用できます。

すべてのアダプターは、準備済みステートメントを使用してデータベースにクエリを送信します。「Generic」アダプターを選択した場合は、データソースがクエリを実行する際に、準備済みステートメントまたは通常のステートメントのどちらを使用するかを選択できます。

デフォルトでは、「Generic」アダプターでも、準備済みステートメントが使用されます。この設定を変更するには、[Source Configuration] タブをクリックして、[Supports PreparedStatement] ボックスで [No] を選択します。このように選択すると、 Allow literal as parameter プロパティは自動的に no に設定されます。通常のステートメントはパラメータ化できないからです。

制約付き委任による Kerberos 認証¶

制約付き委任は Active Directory の機能であり、ユーザーの代わりに Kerberos チケットを取得するようにサービスアカウントを構成できますが、あらゆるサービスを利用できるわけではなく、一部のサービスを利用できるにとどまります。たとえば、Virtual DataPort サーバーに関連付けたユーザーアカウントを構成して、Impala のインスタンスに接続するチケットを他のユーザーの代わりに取得可能にすることができますが、他のデータベースに接続するチケットは取得できません。

Virtual DataPort は、以下のデータベースに接続する場合に制約付き委任をサポートします。

• Apache Hive

• Cloudera Impala

• Microsoft SQL Server (jTDS アダプターまたは Microsoft アダプターを使用する場合)

• SAP HANA

• Postgresql

• 別の Virtual DataPort サーバー (バージョン 8.0、7.0、および 6.0)

データベースの JDBC ドライバーは制約付き委任をサポートしている必要があります。サポートしていないと、ドライバーは適切な Kerberos チケットを取得できず、コネクションは失敗します。

forwardable = true

データベースが Microsoft SQL Server であり、いずれかの jTDS アダプターを選択している場合、 <DENODO_HOME>/dll/vdp/jtds/x64/ntlmauth.dll ファイルを <DENODO_HOME>/extensions/thirdparty/dll フォルダにコピーします。

Microsoft アダプターを選択している場合は、何もする必要はありません。

IBM DB2 からのストアドプロシージャのインポート¶

IBM DB2 のストアドプロシージャから基本ビューを作成するプロセスでは、そのプロシージャからどのデータを取得するかを構成するダイアログが管理ツールに表示されます。このダイアログは、選択したストアドプロシージャの特性に応じて異なります。

• プロシージャがカーソルパラメータも非カーソルパラメータも返すことを宣言していない場合、管理ツールには以下のようなダイアログが表示されます。

ストアドプロシージャを IBM DB2 からインポート¶

• 選択しているプロシージャで 1 つまたは複数のカーソル および 1 つまたは複数の非カーソル出力パラメータを返すことが宣言されている場合、管理ツールには以下のようなダイアログが表示されます。

カーソルを返すストアドプロシージャを IBM DB2 からインポート¶

このダイアログでは、ビューで次の各処理をできるようにするかどうかを選択します。

• Do not stream cursor parameters: 基本ビューには、プロシージャで宣言されているカーソルごとに配列フィールドが 1 つずつ存在します (ビューからは動的カーソルのデータが返されません)。各配列には、対応するカーソルから返されるデータがすべて格納されます。この基本ビューにクエリを実行して返される結果は 1 行のみです。

• Stream output at the specified cursor: フラット化されたカーソル 1 つのデータが返されます。ビューにはカーソルのフィールドごとにフィールドが 1 つずつ存在し、この基本ビューにクエリを実行して得られた結果には、選択したカーソルの各行に対応する行が 1 つずつ存在します。他のカーソルは、存在したとしても、無視されます。

  推奨されるオプションは [Stream output at the specified cursor] です。その理由は、もう一方のオプションを選択した場合、クエリの結果が配列で構成されることにあります。配列の行数が多い場合はメモリ消費量に影響があります。Virtual DataPort サーバーでは、カーソルのすべての行を受け取って配列全体を形成するまで、配列にある各行の処理を開始できないからです。

  一方、カーソルから返される行が少ない場合は、[Do not stream cursor parameters] をチェックしておけば、1 回のクエリだけで、すべてのカーソルからデータを取得できます。

  プロシージャで宣言されたカーソルの 1 つまたは動的カーソルを選択できます。動的カーソルを選択するには、[Procedure dynamic resultset returned in position] をチェックして、そのカーソルのインデックスを入力します。このインデックスを入力する必要がある理由は、ストアドプロシージャから返される動的カーソルの情報がデータベースから提供されないことにあります。

  プロシージャから非カーソルパラメータも返される場合は、それらのパラメータの値を基本ビューに追加できます。「 Importing a stored procedure that returns cursors from IBM DB2 using Design Studio 」では、このような値として「RETURN_VALUE」を追加しています。基本ビューには、選択した出力パラメータごとにフィールドが 1 つ追加されます。これらの出力パラメータは複合型ではないので、プロシージャからは、これらのパラメータごとに値が 1 つ返されます。したがって、このビューにクエリを実行して得られる結果には、カーソルから返される行ごとにこれらのパラメータの値が繰り返し記述されています。

Design Studio を使用してストアドプロシージャから基本ビューを作成する場合、Design Studio でストアドプロシージャを実行することによってあらゆるカーソルが特定されます。したがって、プロシージャで動的カーソルが使用されていれば、そのカーソルのインデックスをあらかじめ知っている必要はありません。プロシージャに入力パラメータが存在する場合、入力パラメータを入力するダイアログが表示されます。Design Studio では、選択しているストアドプロシージャの特性に適合したダイアログが表示されます。

• プロシージャから簡潔なデータ型のみが返される場合、Design Studio では自動的に基本ビューが作成されます。

• 選択しているプロシージャで 1 つまたは複数のカーソルを返すことが宣言されている場合または動的カーソルが返される場合、Design Studio では以下のようなダイアログが表示されます。

Design Studio を使用して、カーソルを返すストアドプロシージャを IBM DB2 からインポート¶

このダイアログは、 管理ツールのこのダイアログ と同等であり、[Output] と [Flatten] の 2 つの列があります。[Output] チェックボックスがチェックされているフィールドは、基本ビューのスキーマのフィールドになります。[Flatten] オプションを選択すると、そのフィールドの出力がストリーミングされます。一度に選択できる [Flatten] オプションは 1 つだけです。このダイアログでは、以下の操作を実行できます。

• Do not stream cursor parameters: カーソルの [Output] チェックボックスのみをチェックすることによって機能します。このようにすると、基本ビューには、プロシージャで宣言されているカーソルごとに配列フィールドが 1 つ存在するようになります (ビューからは動的カーソルのデータが返されません)。各配列には、各カーソルが返すデータがすべて格納されます。この基本ビューにクエリを実行して返される結果は 1 行のみです。[Flatten] オプションをチェックしていない場合は動的カーソルを出力に追加できません。

• Stream output at the specified cursor: カーソルまたは動的カーソルの横にある [Flatten] チェックボックスをチェックすることによって機能します。ビューにはカーソルのフィールドごとにフィールドが 1 つ存在し、この基本ビューにクエリを実行して得られる結果には、選択したカーソルの行ごとに行が 1 つ存在します。他のカーソルまたは動的カーソルは、存在したとしても、無視されます。

  推奨されるオプションは、カーソルをフラット化することです。その理由は、もう一方のオプションを選択した場合、クエリの結果が配列で構成されることにあります。配列の行数が多い場合はメモリ消費量に影響があります。Virtual DataPort サーバーでは、カーソルのすべての行を受け取って配列全体を形成するまで、配列にある各行の処理を開始できないからです。

  一方、カーソルが返す行数が少ない場合、どの [Flatten] もチェックしないことによって、1 回のクエリだけですべてのカーソルからデータを取得できます。

  プロシージャから非カーソルパラメータも返される場合は、その [Output] チェックボックスをチェックすることで、それらのパラメータの値を基本ビューに追加できます。「 Importing a stored procedure that returns cursors from IBM DB2 using Design Studio 」では、このような値として「RETURN_VALUE」を追加しています。基本ビューには、選択した出力パラメータごとにフィールドが 1 つ追加されます。これらの出力パラメータは複合型ではないので、プロシージャからは、これらのパラメータごとに値が 1 つ返されます。したがって、このビューにクエリを実行して得られる結果には、カーソルから返される行ごとにこれらのパラメータの値が繰り返し記述されています。

Microsoft SQL Server からのストアドプロシージャのインポート¶

Microsoft SQL Server のストアドプロシージャから基本ビューを作成するプロセスでは、そのプロシージャからどのデータを取得するかを構成するダイアログが管理ツールに表示されます。

ストアドプロシージャを Microsoft SQL Server からインポート¶

プロシージャが非表示カーソルを返す場合、[Stream output at dynamic resultset returned in position] チェックボックスをチェックして、カーソルのインデックスを入力します。この入力が必要な理由は、ストアドプロシージャから返される非表示カーソルの情報がデータベースから提供されないことにあります。

Design Studio を使用していて、プロシージャが非表示カーソルを返す場合、Design Studio ではプロシージャを実行することによって非表示カーソルを特定します。したがって、使用するカーソルのインデックスをあらかじめ知っている必要はなく、Design Studio によって一連の非表示カーソルが表示されるので、目的のカーソルとそのフィールドを選択できます。プロシージャに入力パラメータが存在する場合、入力パラメータを入力するダイアログが表示され、Design Studio でそのプロシージャを実行して非表示カーソルを特定できます。

以下の 図 に、出力パラメータとして「RETURN_VALUE」、入力パラメータとして「inparam1」、および 2 つの非表示カーソル (インデックス 1 と 2) が存在するストアドプロシージャから基本ビューを作成できるダイアログの画面を示します。

Design Studio を使用して、2 つの非表示カーソルが存在するストアドプロシージャを Microsoft SQL Server からインポート¶

Oracle からのストアドプロシージャのインポート¶

Oracle のストアドプロシージャから基本ビューを作成するプロセスでは、そのプロシージャからどのデータを取得するかを構成するダイアログが管理ツールに表示されます。このダイアログは、選択したストアドプロシージャの特性に応じて異なります。

• プロシージャから簡潔なデータ型のみが返される場合、手順はテーブルから基本ビューを作成する場合と同じです。プロシージャを選択して [Create selected base views] をクリックすると、新しいビューのスキーマが表示されます。

• プロシージャから 1 つまたは複数のカーソルが返される場合、以下のビュー動作を指定する中間ダイアログが表示されます (Importing an Oracle stored procedure that returns cursors を参照)。

カーソルを返す Oracle ストアドプロシージャをインポート¶

このダイアログでは、ビューで次の各処理をできるようにするかどうかを選択します。

• Do not stream cursor parameters: 基本ビューには、プロシージャから返されるカーソルごとに配列フィールドが 1 つずつ存在します。各配列には、対応するカーソルが返すデータがすべて格納されます。この基本ビューにクエリを実行して返される結果は 1 行のみです。

• Stream output at the specified cursor: フラット化されたカーソル 1 つのデータが返されます。ビューにはカーソルのフィールドごとにフィールドが 1 つずつ存在し、この基本ビューにクエリを実行して得られた結果には、選択したカーソルの各行に対応する行が 1 つずつ存在します。他のカーソルは、存在したとしても、無視されます。

  推奨されるオプションは [Stream output at the specified cursor] です。その理由は、もう一方のオプションを選択した場合、クエリの結果が配列で構成されることにあります。配列の行数が多い場合はメモリ消費量に影響があります。Virtual DataPort サーバーでは、カーソルのすべての行を受け取って配列全体を形成するまで、配列にある各行の処理を開始できないからです。

  一方、カーソルから返される行が少ない場合は、[Do not stream cursor parameters] をチェックしておけば、1 回のクエリだけで、すべてのカーソルからデータを取得できます。

  プロシージャから非カーソルパラメータも返される場合、それらのパラメータの値を基本ビューに追加できます。上記の図 (「 Importing an Oracle stored procedure that returns cursors 」) では、このような値として「OUTPUTPARAM_3」と「OUTPUTPARAM_5」を追加しています。基本ビューには、選択した出力パラメータごとにフィールドが 1 つ追加されます。これらの出力パラメータは複合型ではないので、プロシージャからは、これらのパラメータごとに値が 1 つ返されます。したがって、このビューにクエリを実行して得られる結果には、カーソルから返される行ごとにこれらのパラメータの値が繰り返し記述されています。

Design Studio を使用して Oracle のストアドプロシージャから基本ビューを作成する場合、Design Studio では、選択しているストアドプロシージャの特性に適合したダイアログが表示されます。

• プロシージャから簡潔なデータ型のみが返される場合、手順はテーブルから基本ビューを作成する場合と同じです。プロシージャを選択して [Create selected base views] をクリックすると、Design Studio によって基本ビューが自動的に作成されます。

• プロシージャから 1 つまたは複数のカーソルが返される場合、以下のビュー動作を指定する中間ダイアログが表示されます (「 Importing an Oracle stored procedure that returns cursors using the Design Studio 」を参照)。

Design Studio を使用して、カーソルを返す Oracle ストアドプロシージャをインポート¶

• Do not stream cursor parameters: カーソルの [Output] チェックボックスのみをチェックすることによって機能します。、基本ビューには、プロシージャから返されるカーソルごとに配列フィールドが 1 つずつ存在します。各配列には、対応するカーソルが返すデータがすべて格納されます。この基本ビューにクエリを実行して返される結果は 1 行のみです。

• Stream output at the specified cursor: カーソルまたは動的カーソルの横にある [Flatten] チェックボックスをチェックすることによって機能します。つまり、ビューにはカーソルのフィールドごとにフィールドが 1 つずつ存在し、この基本ビューにクエリを実行して得られる結果には、選択したカーソルの各行に対応する行が 1 つずつ存在します。他のカーソルは、存在したとしても、無視されます。

  推奨されるオプションは、カーソルをフラット化することです。その理由は、そのようにしないとクエリの結果が配列で構成されることにあります。配列の行数が多い場合はメモリ消費量に影響があります。Virtual DataPort サーバーでは、カーソルのすべての行を受け取って配列全体を形成するまで、配列にある各行の処理を開始できないからです。

  一方、カーソルから返される行が少ない場合は、あらゆるカーソルをフラット化しなくても、1 回のクエリだけで、すべてのカーソルからデータを取得できます。

  プロシージャから非カーソルパラメータも返される場合、それらのパラメータの値を基本ビューに追加できます。上記の図 (「 Importing an Oracle stored procedure that returns cursors using the Design Studio 」) では、このような値として「OUTPUTPARAM_3」と「OUTPUTPARAM_5」を追加しています。基本ビューには、選択した出力パラメータごとにフィールドが 1 つ追加されます。これらの出力パラメータは複合型ではないので、プロシージャからは、これらのパラメータごとに値が 1 つ返されます。したがって、このビューにクエリを実行して得られる結果には、カーソルから返される行ごとにこれらのパラメータの値が繰り返し記述されています。

Oracle のストアドプロシージャのインポートに関して、いくつかの制限事項があります。

• PL/SQL 以外の複合型である、Oracle のテーブル型とレコード型はサポートされていません。

• Oracle の PL/SQL のレコードはサポートされていません。

• Oracle の PL/SQL レコードテーブル (複数列のテーブル) はサポートされていません。

PostgreSQL からのストアドプロシージャのインポート¶

PostgreSQL のストアドプロシージャから基本ビューを作成するプロセスでは、そのプロシージャからどのデータを取得するかを構成するダイアログが管理ツールに表示されます。このダイアログは、選択したストアドプロシージャの特性に応じて異なります。

• プロシージャから簡潔なデータ型のみが返される場合、手順はテーブルから基本ビューを作成する場合と同じです。プロシージャを選択して [Create selected base views] をクリックすると、新しいビューのスキーマが表示されます。

• プロシージャから 1 つまたは複数のカーソルが返される場合、中間ダイアログが表示されます (「 カーソルを返す PostgreSQL ストアドプロシージャをインポート 」を参照)。

このダイアログでは、ビューで次の各処理をできるようにするかどうかを選択します。

• Do not stream cursor parameters: 基本ビューには、プロシージャから返されるカーソルごとに配列フィールドが 1 つずつ存在します。各配列には、対応するカーソルが返すデータがすべて格納されます。この基本ビューにクエリを実行して返される結果は 1 行のみです。

• Stream output at the specified cursor: フラット化されたカーソル 1 つのデータが返されます。ビューにはカーソルのフィールドごとにフィールドが 1 つずつ存在し、この基本ビューにクエリを実行して得られた結果には、選択したカーソルの各行に対応する行が 1 つずつ存在します。他のカーソルは、存在したとしても、無視されます。

  推奨されるオプションは [Stream output at the specified cursor] です。その理由は、もう一方のオプションを選択した場合、クエリの結果が配列で構成されることにあります。配列の行数が多い場合はメモリ消費量に影響があります。Virtual DataPort サーバーでは、カーソルのすべての行を受け取って配列全体を形成するまで、配列にある各行の処理を開始できないからです。

  一方、カーソルから返される行が少ない場合は、[Do not stream cursor parameters] をチェックしておけば、1 回のクエリだけで、すべてのカーソルからデータを取得できます。

  プロシージャから非カーソルパラメータも返される場合、それらのパラメータの値を基本ビューに追加できます。上記の図 (「 カーソルを返す PostgreSQL ストアドプロシージャをインポート 」) では、「out_param_3」があります。基本ビューには、選択した出力パラメータごとにフィールドが 1 つ追加されます。これらの出力パラメータは複合型ではないので、プロシージャからは、これらのパラメータごとに値が 1 つ返されます。したがって、このビューにクエリを実行して得られる結果には、カーソルから返される行ごとにこれらのパラメータの値が繰り返し記述されています。

Design Studio を使用して PostgreSQL のストアドプロシージャから基本ビューを作成する場合、Design Studio では、選択しているストアドプロシージャの特性に適合したダイアログが表示されます。

• プロシージャから簡潔なデータ型のみが返される場合、手順はテーブルから基本ビューを作成する場合と同じです。プロシージャを選択して [Create selected base views] をクリックすると、Design Studio によって基本ビューが自動的に作成されます。

• プロシージャから 1 つまたは複数のカーソルが返される場合、Design Studio に中間ダイアログが表示されます (「 Design Studio を使用してカーソルを返す PostgreSQL ストアドプロシージャをインポート 」を参照)。

このダイアログでは、ビューで次の各処理をできるようにするかどうかを選択します。

• Do not stream cursor parameters: カーソルの [Output] チェックボックスのみをチェックすることによって機能します。、基本ビューには、プロシージャから返されるカーソルごとに配列フィールドが 1 つずつ存在します。各配列には、対応するカーソルが返すデータがすべて格納されます。この基本ビューにクエリを実行して返される結果は 1 行のみです。

• Stream output at the specified cursor: カーソルまたは動的カーソルの横にある [Flatten] チェックボックスをチェックすることによって機能します。つまり、ビューにはカーソルのフィールドごとにフィールドが 1 つずつ存在し、この基本ビューにクエリを実行して得られる結果には、選択したカーソルの各行に対応する行が 1 つずつ存在します。他のカーソルは、存在したとしても、無視されます。

  推奨されるオプションは、カーソルをフラット化することです。その理由は、そのようにしないとクエリの結果が配列で構成されることにあります。配列の行数が多い場合はメモリ消費量に影響があります。Virtual DataPort サーバーでは、カーソルのすべての行を受け取って配列全体を形成するまで、配列にある各行の処理を開始できないからです。

  一方、カーソルから返される行が少ない場合は、あらゆるカーソルをフラット化しなくても、1 回のクエリだけで、すべてのカーソルからデータを取得できます。

  プロシージャから非カーソルパラメータも返される場合、それらのパラメータの値を基本ビューに追加できます。上記の図 (「 Design Studio を使用してカーソルを返す PostgreSQL ストアドプロシージャをインポート 」) では、「out_param_3」があります。基本ビューには、選択した出力パラメータごとにフィールドが 1 つ追加されます。これらの出力パラメータは複合型ではないので、プロシージャからは、これらのパラメータごとに値が 1 つ返されます。したがって、このビューにクエリを実行して得られる結果には、カーソルから返される行ごとにこれらのパラメータの値が繰り返し記述されています。

PostgreSQL のストアドプロシージャのインポートに関して、いくつかの制限事項があります。

• PL/SQL 以外の複合型はサポートされていません。

• PostgreSQL の PL/pgSQL のレコードはサポートされていません。

• PostgreSQL の PL/pgSQL レコードテーブル (複数列のテーブル) はサポートされていません。

WHEREEXPRESSION 変数の使用¶

すでに説明したように、基本ビューの作成に使用する SQL クエリでは、 補間変数 (「 補間変数によるパスなどの値 」を参照) を使用して SQL クエリをパラメータ化できます。

Virtual DataPort には、SQL クエリから容易に基本ビューを作成できるようにする補間変数として WHEREEXPRESSION があらかじめ定義されています。そのようなクエリを実行すると、Virtual DataPort サーバーによって、 WHEREEXPRESSION が基本ビューに送信する条件に置き換えられます。

以下に示す SQL クエリを使用して基本ビュー VIEW1 を作成するとします。

SELECT StorProc(FIELD1), FIELD2, FIELD3, FIELD4 AS ALIAS4
FROM TABLE1
WHERE @WHEREEXPRESSION

このクエリの SELECT 句ではストアドプロシージャを使用しているので、この基本ビューの作成では SQL クエリを使用する必要があります。

[OK] をクリックした後で、使用している変数の値を入力する必要があります。入力すると Virtual DataPort によってクエリが実行され、基本ビューを作成するために必要なメタデータが得られます。以下に例を示します。

FIELD2='f2' AND FIELD4='f4'

Virtual DataPort サーバーでは、このクエリを実行してデータベースから必要なメタデータを取得します。つづいて、生成される基本ビューのフィールドが管理ツールに表示されます (「 Creating a JDBC base view from a SQL query with WHEREEXPRESSION 」を参照)。クエリの SELECT 句で使用している別名には、実際に使用するフィールドの名前を指定する必要があります。たとえば、前述のクエリでは、 FIELD4 に別名 ALIAS4 を定義しているので、 ALIAS4 属性に FIELD4 の値を指定する必要があります。

次に、[Save] () をクリックして、基本ビューを作成します。

基本ビューの SQL ステートメントで WHEREEXPRESSION を使用すると、この基本ビューに対して実行するクエリのパフォーマンスが向上する可能性があります。たとえば、結合ビューで NESTED 実行メソッドを使用していて、結合の右辺のビューが SQL ステートメントタイプである場合、このビューは、クエリに WHEREEXPRESSION を使用して作成するべきです。そのように作成することにより、SQL ステートメントに WHEREEXPRESSION を使用した場合にのみ使用できる最適化を Virtual DataPort サーバーで適用できるからです。

WHEREEXPRESSION を使用して SQL クエリから JDBC の基本ビューを作成¶

ここの例では、以下の VQL クエリを実行するとします。

SELECT *
FROM VIEW1
WHERE FIELD2 = 'f2' AND ALIAS4 = 'f4'

Virtual DataPort サーバーによって、変数 WHEREEXPRESSION がクエリの WHERE 句の条件に置き換えられます。

SELECT StorProc(FIELD1) AS ALIAS1, FIELD2, FIELD3, FIELD4 AS ALIAS4
FROM TABLE1
WHERE FIELD2 = 'f2' AND FIELD4 = 'f4'

投影できないフィールドを扱っている WHERE 条件を設定した SQL クエリ基本ビューの結果をフィルタ処理する場合、ダイアログの一番下のボックスにそれらのフィールドの名前をカンマ区切りで入力します。これらのフィールドは基本ビューに属していますが、Virtual DataPort サーバーではそれらの値が投影されません。それらのフィールドは、この基本ビューを指定したクエリの WHERE 句でのみ使用するべきであり、それらのフィールドに指定する値は、データベースに送信するクエリを生成する目的でのみ使用されます。

たとえば、以下の SQL クエリがあり、このビューに対してクエリを実行する際に [FIELD1] フィールドでフィルタ処理できるようにするには、ダイアログの一番下のボックスに FIELD1 を追加する必要があります。

SELECT COUNT(*)
FROM TABLE1
WHERE @WHEREEXPRESSION

ここの例では、基本ビューに COUNT と FIELD1 の 2 つのフィールドが追加されます。

新しい基本ビューに対して以下のクエリを実行するとします。

SELECT *
FROM TABLE1
WHERE FIELD1 = 'f1'

データベースに送信されるクエリは以下のようになります。

SELECT COUNT(*)
FROM TABLE1
WHERE FIELD1 = 'f1'

これらの例では、基本ビュー VIEW1 に実行するクエリに WHERE 句を使用する必要があります。それを使用しない場合、Virtual DataPort サーバーでは以下のクエリを実行しようとします。

SELECT ... FROM TABLE1 WHERE

このクエリには WHERE 句がありますが、条件が指定されていないので、実行すると失敗します。

クエリに必ず WHERE 句を使用することが強制されないように、Virtual DataPort には 補間関数 ExecuteIfIsNotNull が用意されています。この関数の構文は以下のとおりです。

^ExecuteIfIsNotNull( <prefix if the variable is not NULL>
    ,@<variable name>
    ,<suffix if the variable is not NULL>
    [,<value if the variable is NULL> ] )

実行時に変数の値を定義していない場合は、この関数によって @<variable name> が変数の値に置き換えられ、それに接頭辞と接尾辞が付加されます。

• 関数のパラメータの間には空白を置かないようにする必要があります。

• 一重引用符ではなく、二重引用符でパラメータを囲みます。

• 2 番目のパラメータに、補間変数の名前を、中括弧で囲まない構文 @VARIABLE_NAME で指定する必要があります。他の状況では、構文 @{VARIABLE_NAME} で変数を指定する場合がありますが、この関数ではこの構文は使用しません。

基本ビューの SQL クエリでこの関数を以下のように使用することによって、前述の例を改善できます。

SELECT StorProc(FIELD1), FIELD2, FIELD3, FIELD4 ALIAS4
FROM TABLE1
^ExecuteIfIsNotNull("WHERE ",@WHEREEXPRESSION,"")

実行時にこのビューに対して実行するクエリで WHERE 句を使用している場合、 @WHEREEXPRESSION は、接頭辞として WHERE 、接尾辞として空文字列が付加されたクエリ条件で置き換えられます。

Virtual DataPort サーバーでは、以下のようなクエリが実行されることになります。

SELECT StorProc(FIELD1), FIELD2, FIELD3, FIELD4 ALIAS4
FROM TABLE1 WHERE FIELD2 = 'f2'

このクエリで WHERE 句を使用しない場合、関数は実行されないので、生成されるクエリは以下のようになります。

SELECT StorProc(FIELD1), FIELD2, FIELD3, FIELD4 ALIAS4
FROM TABLE1

ExecuteIfIsNotNull の 4 番目のパラメータ (省略可能) を設定した場合、この関数は必ず実行されます。補間変数の値が NULL の場合、この関数はこの 4 番目のパラメータの値を返します。たとえば、以下の SQL クエリを使用して基本ビューを構築しているとします。

SELECT StorProc(FIELD1), FIELD2, FIELD3, FIELD4 ALIAS4
FROM TABLE1
^ExecuteIfIsNotNull('WHERE ',@WHEREEXPRESSION,'','WHERE FIELD2 is not NULL')

実行時にこのクエリで WHERE 句を使用していない場合、Virtual DataPort サーバーは、データベースで以下のクエリを実行します。

SELECT StorProc(FIELD1), FIELD2, FIELD3, FIELD4 ALIAS4
FROM TABLE1 WHERE FIELD2 is not NULL

ストアドプロシージャを呼び出すクエリからの基本ビューの作成¶

ストアドプロシージャを呼び出す SQL クエリから JDBC 基本ビューを作成する場合、その SQL クエリは、以下の条件を満たす必要があります。

• プロシージャの入力パラメータの値には、定数または補間変数 (@VARIABLE_NAME など) を指定できます。

• 入力パラメータの型がテキストである場合、そのパラメータ値の定数または補間変数を引用符で囲む必要があります。

• ストアドプロシージャの出力フィールドにはすべて疑問符を使用します。

• ビューの構築に使用する SQL クエリでは、Virtual DataPort の構文ではなく、データベースの構文を使用する必要があります。これは、データベースのストアドプロシージャを呼び出すこのクエリだけではなく、他のタイプのクエリにも当てはまります。

以下のクエリは、DB2 と Oracle の構文を使用しています。

CALL schema.stored_procedure_name(
      @INPUT_VALUE_INTEGER, '@INPUT_VALUE_TEXT', ?, ?, ?)

• @ 文字を付加して、 INPUT_VALUE_INTEGER と INPUT_VALUE_TEXT を補間変数にします。補間変数は、実行時にその値で置き換えられます。

• INPUT_VALUE_TEXT 変数は文字列を表すので、引用符で囲む必要があります。

• 疑問符は、ストアドプロシージャの出力フィールドであることを表します。

このクエリから作成される基本ビューには、2 つの必須フィールドとして INPUT_VALUE_INTEGER と INPUT_VALUE_TEXT が追加されます。実行時に、クエリの WHERE 句でこれらのフィールドの値を渡す必要があります。

入力パラメータの値が NULL になる状況も考えられます。この場合は、前の節で説明した ExecuteIfIsNotNull 関数を使用します。

以下のクエリは、2 つのオプションパラメータを持つストアドプロシージャを Microsoft SQL Server で呼び出します。

exec stored_procedure_name
     \@param1 = ^ExecuteIfIsNotNull("",@input_val_p1,"","null")
   , \@param2= ^ExecuteIfIsNotNull("",@input_val_p2,"","null")

文字 @ に続く単語が補間変数の名前ではない場合、 @ を \ でエスケープする必要があります。

このクエリから作成した基本ビューでは、[param1] フィールドと [param2] フィールドは Null 値を使用できるフィールドになります。したがって、 WHERE param1 = NULL and param2 = NULL のような条件は有効です。

ただし、値を NULL にすることができても、これらのフィールドが必須であることは変わりません。これらを省略可能にするには、ビューを作成した後、ビューの [Options] ダイアログを開いて [Search Methods] タブをクリックし、これら 2 つのフィールドの [Mandatory] 列で [OPT] を選択します。