JDBC ソース

ここでは、JDBC データソースを作成し、つづいてそれらに対する基本ビューを作成する方法について説明します。この JDBC データソースからデータを取得するために、これらの基本ビューに対してクエリを実行します。ここで取り上げるトピックは次のとおりです。

JDBC ソースのインポート

JDBC ソースからデータを取得するデータソースを作成するには、[Server Explorer] のデータベースを右クリックして、[New] > [Data source] > [JDBC] の順にクリックします。

データソースを作成するためのダイアログが表示されます。

[Connection] タブ

JDBC data source: “Connection” tab

JDBC データソース: [Connection] タブ

  • Name: Virtual DataPort での新しいデータソースの名前。ここの例では、電話サービステーブルのデータソースの名前として phone_ds を使用し、インターネットサービスインシデントテーブルのデータソースの名前として internet_ds を使用します。

  • Database adapter: データベースに接続するために使用するアダプター。Virtual DataPort には、データベース管理システム (DBMS) に接続するためのアダプターが用意されていて、各アダプターは、データベースでサポートされている機能を認識しています。このような機能として、データベースで使用できる演算子や関数、サポートされている句などがあります。

    正式にサポートされているデータベースのリストについては、付録「 サポートされている JDBC データソース 」を参照してください。

  • Driver class path: アダプターとして [Generic] を選択した場合を除いて、デフォルトのオプションのままにします。

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

  • Driver class: アダプターとして [Generic] を選択した場合を除いて、デフォルト値のままにします。これは、JDBC ドライバーの Java クラス名です。たとえば、MySQL データベースの場合、この値は com.mysql.jdbc.Driver です。

  • Database URI: データベースにアクセスするための URI。ここの例の場合、両方のインシデントテーブルは、acme マシンに置かれている MySQL サーバーの incidents_center データベースに格納されています。したがって、この URI は jdbc:mysql://acme/incidents_center です。

  • Authentication: 以下のオプションがあります。

    • Use login and password: データソースは、ユーザーが入力したログインとパスワードを使用してデータベースに接続します。

    • Use Kerberos: データソースは、Kerberos を使用してデータベースに接続します。詳細については、「 Connecting to a JDBC Source with Kerberos Authentication 」を参照してください。

    • Use Pass-through session credentials: このオプションを選択している場合は、このデータソースを使用するビューに対してクライアントからクエリを実行すると、Virtual DataPort サーバーはユーザーの資格情報を使用してこのデータベースに接続します。この動作は、Virtual DataPort サーバーに接続するために使用する認証方法に応じて異なります。

      • クライアントが Kerberos 認証を使用して Virtual DataPort サーバーに接続している場合、Virtual DataPort サーバーでは、このユーザーの代わりにデータベースに接続するために Kerberos チケットを要求します。このオプションが機能するには、データベースでも Kerberos 認証をサポートしている必要があります。

      重要

      パススルーセッションの資格情報を有効にして、Active Directory で Virtual DataPort サーバーのユーザーアカウントを、制約付き委任を使用するように構成しているとします。そのユーザーが Kerberos 認証を使用して Virtual DataPort サーバーに接続している場合、このデータソースを指定したクエリは失敗する可能性があります。詳細については、「 Connecting to a JDBC Source with Kerberos Authentication 」を参照してください。

      • クライアントがログインとパスワードを使用して Virtual DataPort サーバーに接続している場合、その Virtual DataPort サーバーはそのログインとパスワードを使用してデータベースに接続します。データベースが Kerberos 認証のみをサポートしている場合は、[This data source requires Kerberos authentication] オプションを選択すると、Virtual DataPort サーバーはログインとパスワードを使用して、データベースに接続するための Kerberos チケットを取得します。

    • Use AWS IAM Credentials (Amazon AthenaAmazon Redshift 専用): データソースは、AWS IAM 資格情報を使用してデータベースに接続します。この資格情報を構成するには、以下の 2 つの方法があります。

      1. [AWS access key ID] と [AWS secret access key] を指定します。必要に応じて、[AWS IAM role ARN] を入力できます。データソースへの接続に必要な権限を取得するロールが AWS ユーザーにあることが前提となります。ロール ARN は、前提とする IAM ロールの Amazon リソースネームです。ロール ARN は、 arn:aws:iam::<awsAccountId>:role/<roleName> のように指定します。

      2. この Virtual DataPort サーバーが動作している AWS インスタンスからデータベースの資格情報を自動的に取得します。そのためには、[AWS access key ID] フィールドと [AWS secret access key] フィールドを空のままにします。必要に応じ、 AWS IAM role ARN を指定して、データベースへの接続に必要な権限を取得することもできます。

      Amazon Redshift の場合、[Database user]を入力することもできます。これは、接続する際に使用する Redshift ユーザー名です。このコネクションは、そのデータベースユーザーの権限を持ちます。

      AWS IAM のユーザーまたはロールには、データベースに接続するために以下の権限が必要です。

      • Amazon Athena: Athena に接続して Amazon S3 バケットにアクセスするための権限が必要です。「 AWSQuicksightAthenaAccess 管理ポリシー.」に記述されているすべてのアクションが IAM 権限ポリシーで許可されていることを確認します。必要に応じて、 AmazonAthenaFullAccess 管理ポリシー に記述されているアクションを追加すると、Athena へのフルアクセスを付与できます。

      • Amazon Redshift: GetClusterCredentials 操作の呼び出しに対する認可が必要です。そのためには、 redshift:DescribeClustersredshift:GetClusterCredentialsredshift:CreateClusterUser 、および redshift:JoinGroup の各権限が必要です (詳細については、「 Amazon Redshift ドキュメント 」を参照)。

    「パススルーセッション資格情報」の機能はクエリ専用です。Virtual DataPort サーバーがイントロスペクションプロセス (データソースの「Create base view」ウィザードでデータベースのテーブルやビューを表示するプロセス) でデータベースに接続するために使用する資格情報を指定する必要があります。この認証方法を使用すると [Use other type of authentication to create base view] チェックボックスが自動的にチェックされ、チェックをはずせなくなる理由はこの点にあります。

    このオプションを指定してデータソースを作成し、Virtual DataPort サーバーへの接続に使用した資格情報とは異なる資格情報でそのデータソースのビューに対してクエリを実行する場合、 USERNAMEPASSWORD の両パラメーターをクエリの CONTEXT に追加します。この 2 つのパラメーターは、[Pass-through session credentials] オプションをチェックしてデータソースを作成した場合にのみ考慮されます。

    たとえば、このオプションを有効にして JDBC データソースから作成した view1 に以下を実行するとします。

    SELECT *
    FROM view1
    CONTEXT(
        USERNAME = 'admin'
      , PASSWORD = 'd4GvpKA5BiwoGUFrnH92DNq5TTNKWw58I86PVH2tQIs/q1RH9CkCoJj57NnQUlmvgvvVnBvlaH8NFSDM0x5fWCJiAvyia70oxiUWbToKkHl3ztgH1hZLcQiqkpXT/oYd' ENCRYPTED)
    

    Virtual DataPort サーバーは、ユーザーが Virtual DataPort サーバーへの接続に使用した資格情報を無視し、ユーザー名「admin」とパスワード「password」を使用してビューのデータソースに接続します。

    トークン ENCRYPTED を追加して、暗号化したパスワードを入力することは必須です。パスワードを暗号化するには、 ENCRYPT_PASSWORD ステートメントを使用します。以下に例を示します。

    ENCRYPT_PASSWORD 'my_secret_password';
    

    このオプションを指定してデータソースを作成している場合、そのデータソースを指定したクエリを実行する新しいユーザーごとに Virtual DataPort サーバーによってコネクションプールが作成されます。当初は、多数のコネクションが作成されないように、これらのプールに存在するコネクションは 1 つのみとなっています。各プールの最大コネクション数は、コネクションプールの [Max Active] フィールドの値です。後述する [Connections Pool Configuration] ダイアログの説明を参照してください。

    警告

    パススルー資格情報が有効なデータソースを使用するビューに対してキャッシュを有効にする場合は注意が必要です。このような場合に発生することが考えられる問題については、付録「 データソースをパススルー資格情報を使用して構成する場合の検討事項 」を参照してください。

    注釈

    データベースが Oracle の場合、[Pass-through session credentials] の代わりに、[Use Oracle Proxy authentication] オプションの使用を検討してください。Oracle に対して開くコネクションの数が少なくなる可能性があるからです。

  • Use other type of authentication to create base views: イントロスペクションプロセス (データソースの「Create base view」ウィザードでデータベースのテーブルやビューを表示するプロセス) で、別の認証方法を使用してデータベースに接続する場合にチェックします。

  • Use Oracle Proxy Authentication (Oracle アダプターを使用する場合のみ): Oracle の「プロキシ認証」機能を使用する場合にチェックします。この機能の仕組みについては、「 Oracle プロキシ認証の仕組み 」を参照してください。

    このオプションはイントロスペクションには影響しません。つまり、[Create base view] をクリックすると、データソースは、現在のユーザーのユーザー名ではなく、データソースの資格情報を使用してデータベースに接続し、ビューのリストを取得します。

  • Transaction isolation: このデータソースのデータベースで実行するトランザクションとクエリの分離レベル。選択可能なオプションを以下に示します。

    • Database default: Virtual DataPort サーバーは、データベースのデフォルトの分離レベルを使用します。

    • No transactions: トランザクションサポートを無効にします。

    • Read uncommitted: コミットされていないデータをトランザクションで読み取ることができます (ダーティリード)。たとえば、トランザクション A でビューに行を挿入し、トランザクション B でその新しい行を読み取った後、トランザクション A で行の挿入をロールバックします。

    • Read committed: トランザクション終了までデータベースによって書き込みロックが維持されるので、そのトランザクションではコミットされたデータのみを読み取ることができ、ダーティリードは不可能です。ただし、 SELECT 操作が終了するとデータベースによってただちに読み取りロックが解除されるので、同じトランザクションで SELECT クエリを繰り返すたびに異なる結果が得られることがあります (ノンリピータブルリード)。

      たとえば、ある行をトランザクション A で読み取り、トランザクション B でその行を変更したとします。トランザクション A でもう一度その行を読み取ると、前と異なる値が取得されます。

    • Repeatable read: トランザクション終了までデータベースによって読み取りロックと書き込みロックが維持されます。したがって、この分離レベルでは、ダーティリードとノンリピータブルリードが回避されます。ただし、ファントムリードは回避されません。あるトランザクションで条件を使用して一定範囲の行に対してクエリを実行すると同時に、別のトランザクションで同じ範囲に行を挿入できる場合に、この問題が発生します。

    • Serializable: 最上位の分離レベル。一定範囲の行またはテーブル全体をロックすることによって、ダーティリード、ノンリピータブルリード、およびファントムリードが回避されます。

  • [Test Connection] がチェックされている場合、Virtual DataPort サーバーは、ソースがアクセス可能であることを確認するために、ソースに接続しようとします。


必要に応じて、[Driver properties] をクリックすると、コネクションのドライバーのプロパティを設定できます。表示されるダイアログには、ドライバーがサポートするすべてのプロパティがそのデフォルト値と共に表示されます。ドライバーによっては、各プロパティの説明と設定できる値も提供しており、このダイアログではそれがヒントとして表示されます。プロパティのデフォルト値を復元するには、その現在の値を消去します。

JDBC data source: “Driver properties” dialog

JDBC データソース: [Driver Properties] ダイアログ


データベースへのコネクションを最適化するために、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] フィールドにクエリを 指定している場合にのみ 実行されます。クエリを指定していない場合は、このチェックボックスをチェックしていても検証は実行されません。

注釈

本番環境では、[Test connection] チェックボックスをチェックして、[Ping query] にクエリを定義することが強く推奨されます。

  • [Read & Write] タブ

JDBC data source: “Read & Write” tab

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

  • Fetch size (rows): データベースからより多くの行をフェッチする必要がある場合に、その行数に関するヒントを JDBC ドライバーに示します。このパラメーターはあくまでもヒントにすぎず、ドライバーによっては無視されることがあります。たとえば、SQL Server の Microsoft JDBC ドライバーでは、このヒントが無視されます。これは、SQL Server の jTDS アダプターを使用することで回避できます。

  • 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 を囲む文字はデフォルトで " (二重引用符) です。別の文字を使用するには、その文字をこのボックスに入力します。

  • 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 の使用については、「 データ一括読み込み 」を参照してください。

  • 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] タブ

注釈

現在、 Design Studio で [Source Configuration] メニューを使用できませんが、今後の更新で現在のオプションを拡張して段階的に追加する予定です。

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

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

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

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

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

注釈

ほとんどの場合、これらのオプションのデフォルト値は適切です。したがって、このダイアログが効果的になるのはきわめて特殊な環境のみです。

JDBC data source: “Source Configuration” tab

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

[Metadata] タブ

[Metadata] タブでは、データソースの格納先フォルダーと説明を設定できます。

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

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

データベース固有の情報

ここでは、以下のデータベースのいずれかにデータソースを作成する際に考慮を必要とする情報について説明します。

Amazon Athena と Presto

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

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

フィールド名

フィールド型

id

VARCHAR(50)

name

VARCHAR(50)

address

VARCHAR(100)

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

SELECT *
FROM customer
WHERE id < 200;

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

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

Cassandra

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

Elasticsearch

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

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

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

id

text

1

Lorem ipsum dolor sit

2

amet, consectetur

3

adipiscing elit. Nullam

NULL

NULL

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

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] に、それぞれ設定します。

Azure SQL Data Warehouse

このソースから取得したデータを統合する場合、Azure SQL Data Warehouse の以下の制限を考慮します。

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

  • 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

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

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


Oracle からデータを取得する JDBC データソースを作成して、そのデータソースでそのシノニムを表示する必要がある場合は、 includeSynonyms プロパティを追加して、その値を 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' と指定します。

Oracle プロキシ認証の仕組み

Oracle JDBC ドライバーは、 プロキシ認証 と呼ばれる機能 (別名 N 層認証) を提供します。プロキシ認証によって、クライアントアプリケーション (Virtual DataPort に接続するアプリケーション) の ID が、データベースまでのすべての段階で維持されます。

データソースで [Oracle proxy authentication] オプションが有効で、クライアントアプリケーションが Virtual DataPort に接続してクエリを実行すると、以下の処理が実行されます。

  1. 実行エンジンがデータソースのコネクションプールへのコネクションを要求します。プール側ではコネクションが選択されます。

  2. プールは、Virtual DataPort とのコネクションを開いたアプリケーションのユーザー名を使用して、このアクティブなコネクション上に「ユーザータイプ」の「プロキシセッション」を作成します。このプロキシセッションは、新しいコネクションではなく、既存のコネクション上で開きます。

  3. プールではこのコネクションを実行エンジンに返し、実行エンジンではこのコネクションを使用して Oracle でクエリを実行します。このクエリはプロキシセッションの中で動作するので、Virtual DataPort に接続しているユーザーが開いたコネクション上で実行されているように見えます。データソースで設定されたサービスアカウントを使用しているようには見えません。

  4. このクエリが完了すると、コネクションはプールに返され、プールではプロキシセッションを終了します。

たとえば、データソースを作成し、その [Login] フィールドに「denodo_svc_user」と入力して、このオプションを有効にしたとします。次に、このデータソースに対する基本ビュー「employee」を作成します。その後で、ユーザー「scott」が Virtual DataPort に接続し、基本ビュー「employee」に対してクエリを実行します。データソースでは、そのコネクションプールからコネクションを取得し、そのコネクション上でユーザー名を「scott」としたプロキシセッションを作成します。データソースはクエリを実行して結果を取得し、プロキシセッションを終了してコネクションをプールに返します。

この機能は、データソースのコネクションプールを無効にしても、同様に動作します。


この機能はクエリにのみ適用されます。データソースの資格情報は、イントロスペクションプロセス (データソースの「Create base view」ウィザードでデータベースのテーブルやビューの一覧を表示するプロセス) でデータベースに接続する際に使用されます。


このオプションは、[Pass-through session credentials] の代替手段です (両方のオプションを使用するようにデータソースを構成することはできません)。プロキシセッションの利点は、データソースでコネクションプールを 1 つ維持すればすむ点にあります。[Pass-through session credentials] を指定した場合、このデータソースの基本ビューに対してクエリを実行するユーザー名ごとにデータソースではコネクションプールが 1 つずつ保持されます ([Maximum number of active connections] の値に関係なく、プールから開くコネクションは 1 つのみです)。

プロキシ認証では、データソースに対して実行されるすべてのクエリについてコネクションプールが 1 つだけ存在するので、プールのコネクションの再利用率が向上し、Oracle に対して開くコネクションの数が少なくなる可能性があります。


アプリケーションが Kerberos 認証を使用して Denodo に接続する場合、プロキシセッションを開くために使用されるユーザー名は、Denodo サーバーの Kerberos 設定 の [Avoid domain name for authorization] 設定に依存します。たとえば、ユーザー scott@CONTOSO.COM が Denodo に接続する場合は以下のようになります。

  • [Avoid domain name for authorization] をチェックしている場合は、プロキシセッションのユーザーアカウントが scott になります。

  • チェックしていない場合は、プロキシセッションのユーザーアカウントは scott@CONTOSO.COM になります。

注釈

この機能を使用する前に、それを使用できるように、Oracle の管理者が Oracle の各ユーザーアカウントを構成する必要があります。

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

重要

Yellowbrick では、クエリの実行対象とするデータベースまたはキャッシュエンジンが使用するデータベースのエンコードを UTF-8 に設定します。

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

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

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

汎用アダプター

固有のアダプターが存在しないデータベースに接続する必要がある場合、そのデータベースの多くの部分が、アダプターが存在する別のデータベースに基づいている場合を除いて、アダプターとして 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 関数 (数の絶対値を取得する関数) がサポートされていない場合、 absabs(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 認証による JDBC ソースへの接続

Virtual DataPort は、Kerberos 認証による JDBC データベースへの接続をサポートしています。また、制約付き委任もサポートしています。

注釈

Kerberos 認証を使用してデータベースに接続するために、Denodo サーバー で Kerberos 認証を有効にする 必要はありません 。ただし、有効にしないと、パススルー資格情報で Kerberos 認証を使用できません。

以下のアダプターのいずれかを選択すると、Kerberos 認証を使用するためにドライバーで必要とする「ドライバープロパティ」によってデータソースが自動的に構成されます。

  • Hive for Cloudera

  • Hive for Hortonworks

  • Impala

  • Oracle

  • Microsoft SQL Server (jTDS アダプターと Microsoft ドライバーの場合)

他のアダプターを選択する場合は、該当ベンダーのドキュメントを確認してください。これらのプロパティを定義するには、以下の手順に従います。

  1. データソースの編集

  2. JDBC データソースのダイアログで [Driver properties] をクリックします。

  3. [Kerberos] タブをクリックして [New] をクリックします。

Configuring the Kerberos driver properties to connect to Oracle

Oracle に接続するための Kerberos ドライバープロパティの構成

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

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

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

  • Apache Hive

  • Cloudera Impala

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

  • SAP HANA

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

重要

以下の条件が すべて 成立すると、JDBC データソースを指定したクエリは失敗します。

  • Active Directory で、Virtual DataPort サーバーのユーザーアカウントの制約付き委任が有効である。

  • JDBC データソースでのパススルーセッション資格情報が有効である。

  • データソースのアダプターが前述のリストに存在しない。

  • クライアントが Kerberos 認証を使用して Virtual DataPort に接続している。

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

重要

制約付き委任のサポートは、Active Directory から返されるチケットが「転送可能」である場合にのみ有効です。そのチケットを転送可能にするには、Denodo サーバーが動作しているホストの krb5 ファイルに以下のプロパティを追加します。

forwardable = true

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

重要

Virtual DataPort サーバーが Linux 上で動作していても、この dll をコピーします。

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

JDBC データソースからの基本ビューの作成

[Save] (image5) をクリックしてデータソースを作成した後、そのデータソースから基本ビューを作成し、その基本ビューに対してクエリを実行できるようにするか、その基本ビューのデータを他のビューのデータと組み合わせることができるようにします。

Schemas, tables and views of a JDBC source

JDBC ソースのスキーマ、テーブル、およびビュー

JDBC の基本ビューを作成するには、以下の手順に従います。

  1. [Server Explorer] で JDBC データソースをダブルクリックして開き、[Create base view] をクリックします。

    データベースのスキーマがツリー形式で表示されます。任意のスキーマをクリックして、そのテーブルとフィールドを検査します (「 Schemas, tables and views of a JDBC source 」を参照)。データベースが Oracle または Microsoft SQL Server の場合、このダイアログにはそのストアドプロシージャのリストも表示されます。ストアドプロシージャから作成する基本ビューの詳細については、「 グラフィカルな方法によるデータベースからのストアドプロシージャのインポート 」を参照してください。

    ビューまたはスキーマを検索するには、ダイアログ上部にあるボックスにその名前を入力します。リストには、ここに入力したテキストを使用した名前のエレメントのみが表示されます。

    このダイアログを開くと、管理ツールによって、データベースのスキーマの名前のみが取得されます。スキーマを展開すると、そのスキーマのビューのリストが表示されます。したがって、ビューの名前を入力すると、すでに展開しているスキーマでのみ管理ツールによってビューが検索されます。

    各スキーマのビューの名前は、ユーザーからのリクエストがあったときにのみ読み込まれます。データベースのすべてのビューの名前を一度に取得するには長時間を要するからです。

  2. 基本ビューの作成元にするテーブルの横にあるチェックボックスをチェックします。

  3. この作成元テーブルが属するスキーマとカタログの両方または一方の名前を接頭辞として基本ビューに名前を割り当てる場合は、[Prefix view names with schema and/or catalog name] チェックボックスをチェックします。さまざまなカタログやスキーマに属する同じ名前のテーブルから基本ビューを作成する場合に、このオプションが効果的で、基本ビューの名前の競合を回避できます。

  4. [View prefix] には、すべての新しいビューに適用する接頭辞を入力できます。たとえば、「internet_ds_」と入力すると、新しいビューには「internet_ds_」で始まる名前が割り当てられます。

  5. [Browse] をクリックして、基本ビューの作成先とするフォルダーを選択します。このダイアログでは、新しいフォルダーの作成、または既存のフォルダーの名前変更ができます (このダイアログを右クリックすると、この 2 つのオプションが表示されます)。

  6. [Create selected] をクリックします。

  7. データベースの複数のテーブルまたはビューを選択した場合、作成したすべてのビューのリストを表示したダイアログが開きます。

    このダイアログで、[Create associations from foreign keys] をクリックします。Virtual DataPort サーバーでは、JDBC データソースのデータベースにおいて、このデータソースの基本ビューのテーブル間またはビュー間に外部キー制約が存在するかどうかを分析します。そのような制約が存在する場合は、以下に示すようなダイアログが表示されるので、これらの外部キー制約を反映したアソシエーションを自動的に作成できます。

Listing the associations that will be created after analyzing the foreign keys of the database

データベースの外部キーを分析した後で作成されるアソシエーションの一覧表示

このダイアログの表の列について以下で説明します。

  • Name: アソシエーションの名前。名前を変更するには、名前をクリックします。

  • Database: アソシエーションの作成先となるデータベース。

  • Left End PointRight End Point: アソシエーションに関するビュー。

[Ok] をクリックするとアソシエーションが作成されます。作成する必要がないアソシエーションがある場合は、そのチェックボックスのチェックをはずします。

このようなアソシエーションの作成を強くお勧めする理由がいくつかあります。その最たるものとして、適切なアソシエーションを作成しておくと、クエリによっては実行速度が大幅に向上するものがあります。アソシエーションが重要な理由については、「 ビューどうしにアソシエーションを定義する必要がある理由 」を参照してください。


このプロセスを終了すると、[Server Explorer] の次の 2 か所に、新しい基本ビューのリストが表示されます。

  1. ビューの作成先フォルダーに表示されます。基本ビューを別のフォルダーに移動する場合は、そのフォルダーまで基本ビューをドラッグします。

  2. 基本ビューが属するデータソースの子ノードとして表示されます。このノードは、他のフォルダーに移動できません。データソースから作成された基本ビューを容易に確認できるように、このような子ノードがツリーに追加されます。


データベースから複数のテーブルまたはビューを選択していて、それらと同じ名前のビューがすでに存在する場合、以下のようなダイアログが表示されます。

Renaming new views with the same name as existing ones

既存のビューと同じ名前を持つ新しいビューの名前変更

このダイアログでは、赤で表示されているビューに新しい名前を指定するか、そのチェックボックスのチェックをはずす必要があります。[Ok] をクリックすると、新しい名前でビューが作成されるか、そのビューが作成から除外されます。

複数の基本ビューを一度に作成しようとしたとき、その多くの名前が既存のビューと同じであった場合に、それらのビューごとに新しい名前を入力しなくてもすむ方法があります。作成するビューと同じ名前を持つ既存の基本ビューをすべて選択して右クリックし、[Prefix selected views/associations] をクリックします。このオプションを使用すると、選択したすべてのビューの名前に接頭辞が付加されます。この処理の後、元のダイアログに戻って基本ビューを作成すれば、どの名前も競合することがなくなります。

この機能が効果的な、よく見られる事例として、同じスキーマによる 2 つのデータベースにデータが存在し、そのデータが異なる場合が挙げられます。たとえば、最新データを保持する Oracle データベースと履歴データを保持する Hadoop データベースがあるとします。どちらのデータベースにも互いに同じ名前のテーブルとビューが存在するので、どちらかのデータソースの基本ビューの名前を変更して、名前の競合を回避する必要があります。


例として、以下に示す 2 つの基本ビューを作成します。

  1. JDBC データソース phone_ds の電話インシデントテーブル phone_inc の基本ビュー。このビューのフィールドは以下のとおりです。

    • pinc_id: インシデントの ID。

    • taxId: インシデントを報告した顧客の納税者 ID。

    • description: 説明。

    • ttime: インシデントの発生日時。

    • inc_type: インシデントタイプ。

    • specific_field3: 追加情報フィールド。

  2. JDBC データソース internet_ds のインターネットインシデントテーブル internet_inc の基本ビュー。このビューのフィールドは以下のとおりです。

    • iinc_id: インシデントの ID。

    • taxId: インシデントを報告した顧客の納税者 ID。

    • ttime: インシデントの発生日時。

    • summary: 説明。

    • specific_field1specific_field2: 2 つの補足情報フィールド。

これらの基本ビューを作成するには、目的のデータソースを開いて [Create base view] をクリックし、テーブルを選択して [Create selected] をクリックします。

複数のテーブルを選択して基本ビューを作成する場合、他の既存のビューと同じ名前のビューに新しい名前を入力することが必要になる場合があり得ます。


一度に 1 つずつテーブルをインポートする場合は、以下の操作によって、基本ビューの作成を詳細に制御できます。

  • 新しい基本ビューの名前を変更する。

  • 新しい基本ビューの属性の名前とタイプを変更する。

  • image3 ボタンをクリックして、フィールドの [Source type properties] を編集する。このダイアログでは、フィールドの正確な型を定義できるほか、その型によっては長さと小数点以下桁数も定義できます。

    JDBC と ODBC の基本ビューの場合、これらのプロパティはデータベースから取得されるので、自動的に定義されます。他のタイプの基本ビューの場合は手動で定義する必要があります。

    これらのプロパティの詳細については、「 基本ビューのスキーマの表示 」を参照してください。

  • [Nullable] 列のチェックボックスで、このビューの各フィールドに NULL 値を入力できるかどうかを指定する。

    つまり、[Nullable] が設定されていないフィールドに NULL を設定する INSERT リクエストまたは UPDATE リクエストは、そのリクエストがデータベースに委任されることなく、ただちに失敗します。

    このプロパティのデフォルト値は、データベースから返されるメタデータから取得されるので、通常はそれを変更しないようにします。

    たとえば、基本ビューで「NULL を許可」したフィールドに、データベースでは NULL 値が許可されていないとします。そのフィールドに NULL を設定する INSERT リクエストまたは UPDATE リクエストを Virtual DataPort からデータベースに委任しようとすると、そのリクエストは失敗します。

  • ビューのプライマリキー定義を変更する。JDBC 基本ビューを作成する場合、Virtual DataPort サーバーによって、データベースからプライマリキー定義が取得され、自動的にビューのプライマリキーが設定されます (image6 が表示されているフィールド)。派生ビューおよび他のタイプの基本ビューでは、適切なフィールドを選択して [Set selected as PK] をクリックすることによって、手動でプライマリキー定義を設定する必要があります。

    ビューのプライマリキーの詳細については「 ビューのプライマリキー 」を参照してください。

  • [Metadata] タブで基本ビューの格納先フォルダーを設定し、その説明を記述する。

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

Accepting the schema of a base view

基本ビューのスキーマの受け入れ

注釈

[Create from query] をクリックすることによって、テーブルからではなく、SQL クエリから基本ビューを作成することもできます。このオプションについては「 SQL クエリからの基本ビューの作成 」を参照してください。

グラフィカルな方法によるデータベースからのストアドプロシージャのインポート

Virtual DataPort には、以下のデータベースのストアドプロシージャから基本ビューをグラフィカルに作成する機能が用意されています。

このプロセスは、データベースごとに異なります。

上記以外のデータベースの場合、クエリから基本ビューを作成する必要があります。その手順については「 SQL クエリからの基本ビューの作成 」を参照してください。

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

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

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

Importing a stored procedure from IBM DB2

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

プロシージャが動的カーソルを返す場合、[Stream output at dynamic resultset returned in position] をチェックして、カーソルのインデックスを入力します。この入力が必要な理由は、ストアドプロシージャから返される動的カーソルの情報がデータベースから提供されないことにあります。
  • 選択しているプロシージャで 1 つまたは複数のカーソル および 1 つまたは複数の非カーソル出力パラメーターを返すことが宣言されている場合、管理ツールには以下のようなダイアログが表示されます。

Importing a stored procedure that returns cursors, from IBM DB2

カーソルを返すストアドプロシージャを 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 では以下のようなダイアログが表示されます。

Importing a stored procedure that returns cursors from IBM DB2 using 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 のストアドプロシージャから基本ビューを作成するプロセスでは、そのプロシージャからどのデータを取得するかを構成するダイアログが管理ツールに表示されます。

Importing a stored procedure from 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) が存在するストアドプロシージャから基本ビューを作成できるダイアログの画面を示します。

Importing a stored procedure from Microsoft SQL Server using the Design Studio

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

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

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

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

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

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 」を参照)。

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 レコードテーブル (複数列のテーブル) はサポートされていません。

SQL クエリからの基本ビューの作成

基本ビューはグラフィカルな方法で作成することを 強くお勧め します。これは、JDBC データソースダイアログで目的のテーブルを選択して [Create selected base views] をクリックする方法であり、他の方法よりもはるかに容易です。この方法の詳細については、「 グラフィカルな方法によるデータベースからのストアドプロシージャのインポート 」を参照してください。

ただし、クエリを実行したときに何らかの SQL クエリを実行する基本ビューの作成が必要になることも考えられます。以下に例を示します。

  • 結果を取得するために、データベースのストアドプロシージャの実行、またはストアドプロシージャを使用するクエリの実行を必要とする場合。ストアドプロシージャにクエリを入力する手順については「 ストアドプロシージャを呼び出すクエリからの基本ビューの作成 」を参照してください。

  • Virtual DataPort で実行する場合よりも優れたパフォーマンスで実行されるように調整済みの SQL クエリがある場合。

SQL クエリから基本ビューを作成するには、[Create base view] ダイアログで [Create from query] をクリックします。

Creating a base view from a SQL query

SQL クエリから基本ビューを作成

基本ビューと SQL クエリの名前を入力した後、[Save] (image5) をクリックして基本ビューを作成します。そのスキーマは、通常の基本ビューと同様に編集できます。

基本ビューの SQL クエリでは以下の点を考慮します。

  1. この SQL クエリでは、Virtual DataPort の構文ではなく、クエリの実行先とするデータベースの構文を使用する必要があります。

  2. 1 行に記述されたコメント (-- <comment> のようなコメント) をクエリから削除します。以下に例を示します。

    SELECT f1 as field1 -- Remove this type of comments from the queries you use to create base views.
    FROM view
    
  3. クエリには、 補間変数 を使用できます (「 補間変数によるパスなどの値 」を参照)。これにより、指定のクエリ条件に従って、データベースに送信する SQL クエリをパラメーター化できます。

    クエリで補間変数を使用する場合は、[OK] をクリックした後、クエリで使用する各変数の値を入力します。Virtual DataPort では、それらの値を使用してクエリを実行し、基本ビューを作成するために必要なメタデータを取得します。

    各補間変数は、クエリの実行時に値を取得できるように、生成した基本ビューに属する属性に関連付ける必要があります。データソースへのアクセスに使用する SQL クエリによって、変数と同じ名前のフィールドが返される場合、その変数は基本ビューの対応する属性に関連付けられます。SQL クエリで変数と同じ名前のフィールドが返されない場合は、Virtual DataPort によって、その変数と同じ名前の新しい属性が基本ビューに追加されます。

  4. 1 つまたは複数の入力パラメーターを持ち、そのうちの少なくとも 1 つが補間変数である関数の実行結果を使用するクエリでは、そのすべての列に別名を追加します。たとえば、 SELECT ABS( ROUND( @value ) ) AS value_abs_round... とします。

    その理由は、別名を指定しないと、クエリの出力スキーマの列名が関数の入力値によって決まる可能性があるからです。たとえば、Oracle 11g データベースで SELECT ABS(<value>) FROM Dual を実行すると、列 ABS(<value>) の名前は <value> によって決まります。結果を正しく処理するには、クエリの出力スキーマを変更するわけにはいきません。

    一般に、SQL クエリのすべての列に別名を追加することが推奨されます。

  5. 補間変数を使用する PL/SQL 関数を SQL クエリで呼び出す場合、その戻り値に別名を割り当てる必要があります。以下に例を示します。

    SELECT function_test(@VAR1) AS value
    FROM internet_inc
    
Editing the value of the interpolation variables

補間変数の値の編集

注釈

SQL クエリが SELECT クエリである場合、ビューを作成した後で、ビューの Delegate SQL sentence as subquery プロパティを yes に設定することが推奨されます。これにより、基本ビューに対するより多くのクエリが、Virtual DataPort によってデータベースに委任されるようになります。

このプロパティの値を変更するには、以下の手順に従います。

  1. ビューを作成した後で、そのビューを開きます。

  2. [Options] をクリックします。

  3. [Search Methods] タブをクリックします。

  4. ダイアログの一番下までスクロールして、[Wrapper source configuration] をクリックします。

  5. [Delegate SQL sentence as subquery] プロパティで [yes] を選択します。

このプロパティの詳細については「 ビュー構成プロパティ 」を参照してください。

WHEREEXPRESSION 変数の使用

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

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

注釈

ODBC データソースでは、補間変数 WHEREEXPRESSION を使用できません。JDBC データソースでのみ使用できます。

以下に示す 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] (image5) をクリックして、基本ビューを作成します。

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

Creating a JDBC base view from a SQL query with WHEREEXPRESSION

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

ここの例では、基本ビューに COUNTFIELD1 の 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

注釈

これらの例では、変数 WHEREEXPRESSION に補間変数 ExecuteIfIsNotNull のみを組み合わせていますが、他の補間変数と組み合わせて使用することもできます。

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

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

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

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

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

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

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

DB2 と Oracle でストアドプロシージャを呼び出すクエリ
CALL schema.stored_procedure_name(
      @INPUT_VALUE_INTEGER, '@INPUT_VALUE_TEXT', ?, ?, ?)
  • @ 文字を付加して、 INPUT_VALUE_INTEGERINPUT_VALUE_TEXT を補間変数にします。補間変数は、実行時にその値で置き換えられます。

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

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

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

注釈

Microsoft SQL Server または Oracle のデータベースのストアドプロシージャを呼び出す基本ビューをグラフィカルな方法で作成することもできます。そのためには、データソースを開き、プロシージャを含むスキーマを展開して、[Stored procedures] を展開します。つづいて、インポートするプロシージャを選択して [Create selected] をクリックします。

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

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

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] を選択します。

注釈

ビューをどのように変更した場合でも、この手順を実行する必要があります。