サーバー設定¶
[サーバー設定] ダイアログからは Data Catalog サーバーのすべての設定を構成できます。このダイアログの機能は以下のタブごとにまとめられています。
VDP サーバー: ログインページから利用できる Virtual DataPort サーバー と、すべてのクエリが使用する 接続設定 を構成できます。
認証: Data Catalog で Kerberos を使用したシングルサインオン を有効化できます。
データベース: Data Catalog のメタデータを保管する 外部データベース を構成できます。
権限: 追加タスクを実行する権限を パワーユーザーに付与 できます。
AI Integration: ビュー詳細タブで使用できる アシスト付きクエリ 機能を構成します。
Virtual DataPort サーバーの構成¶
[VDP サーバー] タブの [サーバー] セクションから、ログインダイアログに表示される Virtual DataPort サーバーを構成できます。
注釈
VDP サーバーの構成は Agora では無効化されます。

ログインページに列挙される Virtual DataPort サーバーを構成するダイアログ¶
Virtual DataPort サーバーを新規追加するには、[サーバーの追加] ボタンをクリックし、以下の値を入力します。
名前: ログインページに表示する、このサーバーの名前。
URL: サーバーの接続 URL。
//<host>:<port>/<database>
というパターンに従って指定します。入力の際は以下の点を考慮してください。Data Catalog に接続できるのは、データベースへの
CONNECT
権限を持つユーザーのみです。特定のデータベースに対する LDAP 認証をサーバーで構成している場合、URL でこのデータベースを使用します。
説明: サーバーの説明。

Virtual DataPort サーバーの新規追加ダイアログ¶
注釈
保存されたクエリ は、ユーザーおよび Virtual DataPort サーバーごとに保存されます。Virtual DataPort サーバーは内部 ID によって識別されるため、サーバーを編集しても、そのサーバーに関連付けられたクエリはそのまま維持されますが、サーバーを削除するとクエリも削除されます。
注釈
自動クラウドモード の場合、$DENODO_HOME/conf/data-catalog/DataCatalogBackend.properties ファイルで次のプロパティを編集することで、デフォルトのサーバーを構成できます。
com.denodo.dc.vdp.port=<port>
com.denodo.dc.vdp.host=<hostname>
com.denodo.dc.vdp.servername=<servername>
Virtual DataPort サーバーへの接続設定の構成¶
[VDP サーバー] タブの [接続設定] セクションでは、Virtual DataPort サーバーに対してクエリを実行するために作成されるグローバル接続パラメータを構成できます。

Virtual DataPort サーバーへの接続設定の構成ダイアログ¶
パラメータの内容は以下のとおりです。
クエリアイムアウト: クエリがステートメントの完了を待つ最大時間 (ミリ秒単位)。指定されていない場合 (または値に 0 を指定した場合)、クエリは実行が完了するまで待機します。デフォルトは 900,000 ミリ秒です。
チャンクタイムアウト: クエリが新しい結果のチャンクの到着を待つ最大時間 (ミリ秒単位)。この時間を超過すると、Virtual DataPort はその時点までに抽出された結果を返します。この値が指定されていない場合 (または値に 0 を指定した場合)、Virtual DataPort はステートメントの実行終了時にすべての結果をまとめて返します。デフォルトは 90,000 ミリ秒です。
チャンクサイズ: 結果のチャンクを構成する結果の数。Virtual DataPort ツールは結果をこの数だけ取得すると、[Chunk timeout] の値に達していなくても Data Catalog に結果を返します。デフォルトは 1,000 行です。
Kerberos を使用したシングルサインオンの有効化¶
[認証] タブから、Data Catalog での Kerberos を使用したシングルサインオン を有効化できます。
注釈
Agora では SSO が自動的に構成されるため、Kerberos の構成は無効化されます。

Data Catalog での Kerberos 認証の構成ダイアログ¶
以下の手順に従って実施してください。
[Kerberos の使用] オプションを有効化します。
[サーバープリンシパル] フィールドに Data Catalog のサービスプリンシパル名を入力します。keytab ファイルの生成に使用したものと同じ値を入力してください。
keytab ファイルを [keytab ファイル] フィールドにドラッグ & ドロップします。または、フィールドをクリックしてファイルブラウザーから選択することも可能です。
以下のいずれかの条件を満たしており、システムのデフォルトロケーションに krb5 ファイルが存在しない場合、[構成ファイル] フィールドに krb5 ファイルを追加することを検討してください。
Data Catalog を実行しているホストが Kerberos レルム (Windows Active Directory ドメインなど) に属していない場合。
Data Catalog を実行しているホストが Linux/Unix の場合。
Data Catalog 用に構成された Active Directory のサービスアカウントで、 制約付き委任 (constrained delegation) のオプションが有効になっている場合。
クロスドメインシナリオを使用している場合。つまり、組織が複数のドメインを使用している場合。
該当しない場合、フィールドは空のままで構いません。
参考
krb5 ファイルの詳細については、「 Kerberos 認証用の krb5 ファイルの提供 」を参照してください。
何らかの問題が生じた場合は、[Kerberos デバッグモードの有効化] オプションを選択してください。問題が生じていない場合は、このオプションを無効にしてください。
参考
Kerberos に関する問題のデバッグについては、「 Web アプリケーションで Kerberos をデバッグする方法 」を参照してください。
[保存] ボタンをクリックして Kerberos 構成を確定します。この構成は即座に有効になります。Data Catalog の再起動は不要です。
重要
Kerberos 認証の構成に失敗し、Data Catalog に誰もログインできなくなった場合でも、 ローカル認証 または ログインとパスワードによる認証 による接続が可能です。接続後、Kerberos 設定を変更するか、デバッグモードを有効化してください。
Data Catalog での外部データベースの使用¶
ここでは、設定を外部データベースに保存するように Data Catalog を構成する方法について説明します。Data Catalog サーバーのクラスタをセットアップして、すべてのサーバーに同じ設定とメタデータを共有させる場合には、これが必須です。
注釈
Agora では外部データベースは自動的に構成されるため、Agora から Data Catalog にアクセスした場合、このオプションは無効化されます。
デフォルトでは、Data Catalog は、グローバル設定と各ユーザーの特定の設定を組み込みデータベース (Apache Derby) に保存します。たとえば、ユーザーの保存されたクエリや、ビューの検索画面にデフォルトで表示する、管理者が選択したフィールドの設定などです。これらをすべて外部データベースに保存するように Data Catalog を構成できます。
Data Catalog は以下のデータベースをサポートします。
MySQL
注釈
MySQL (または、使用する MySQL 内のデータベース) で、MySQL 5 の場合は
Default Charset = utf8_mb4
オプションとCollation = utf8mb4_unicode_ci
オプションを、MySQL 8 の場合はCollation = utf8mb4_0900_ai_ci
オプションを構成してください。Oracle
PostgreSQL
SQL Server
MySQL 用および PostgreSQL 用の Amazon Aurora
Azure SQL Server
注釈
各データベースのバージョンの最小要件は、
MySQL 5.7
Oracle 12c
PostgreSQL 11
SQL Server 2014
MySQL 5.7 用の Amazon Aurora および PostgreSQL 11 用の Amazon Aurora
Data Catalog のメタデータを外部データベースに保存するには、以下の手順に従って実施してください。
外部データベースで、Data Catalog のメタデータ用のカタログかスキーマを作成します。
既存のスキーマを使用することも可能ですが、他のアプリケーションとはテーブルを分離するため、新規作成することをお勧めします。このスキーマには 5 GB の容量を確保することをお勧めします。ほとんどの場合、これほどの容量は不要ですが、データベースで容量不足の問題が発生しないように、大きな値を設定することをお勧めします。
このデータベースで、そのデータベースに対する作成、読み取り、および書き込みの権限を持つサービスアカウントを作成します。
稼働時間の厳しい要件を満たすために、このデータベースの高可用性機能を有効にすることを検討してください。
このデータベースの JDBC ドライバーをディレクトリ
<DENODO_HOME>/lib/data-catalog-extensions
にコピーします。以下の点を考慮してください。
Oracle 12 を使用する場合、
<DENODO_HOME>/lib/extensions/jdbc-drivers/oracle-12c
にあるojdbc8.jar
ファイルとorai18n.jar
ファイルのみをコピーしてください。Oracle 18 を使用する場合、
<DENODO_HOME>/lib/extensions/jdbc-drivers/oracle-18c
にあるojdbc8.jar
ファイルとorai18n.jar
ファイルのみをコピーしてください。Oracle 19 を使用する場合、
<DENODO_HOME>/lib/extensions/jdbc-drivers/oracle-19c
にあるojdbc8.jar
ファイルとorai18n.jar
ファイルのみをコピーしてください。Oracle 21 を使用する場合、
<DENODO_HOME>/lib/extensions/jdbc-drivers/oracle-21c
にあるojdbc8.jar
ファイルとorai18n.jar
ファイルのみをコピーしてください。SQL Server を使用する場合、2 つの異なるドライバーを利用できます。
任意のバージョンで Microsoft ドライバーを使用します。これがお勧めのオプションです。このドライバーを使用する場合、
<DENODO_HOME>/lib/extensions/jdbc-drivers/mssql-jdbc-10.x
にあるmssql-jdbc-10.2.0.jre8.jar
ファイルのみをコピーしてください。バージョン 2014 と 2016 の場合、jTDS ドライバーも使用できます。このドライバーを使用する場合、
<DENODO_HOME>/lib/extensions/jdbc-drivers/denodo-jtds-1.3.1
にあるdenodo-jtds-1.3.1.jar
ファイルをコピーしてください。
MySQL 5.7 用の Amazon Aurora を使用する場合、
<DENODO_HOME>/lib/extensions/jdbc-drivers/mariadb-2.7
にあるmariadb-java-client-2.7.1.jar
ファイルのみをコピーしてください。PostgreSQL 11 用の Amazon Aurora を使用する場合、
<DENODO_HOME>/lib/extensions/jdbc-drivers/postgresql-11
にあるpostgresql-42.7.2
ファイルのみをコピーしてください。Azure SQL Server を使用する場合、
<DENODO_HOME>/lib/extensions/jdbc-drivers/mssql-jdbc-7.x
にあるmssql-jdbc-7.2.2.jre8.jar
ファイルのみをコピーしてください。Active Directory 経由で Azure SQL Server を使用する場合、
<DENODO_HOME>/lib/extensions/jdbc-drivers/mssql-jdbc-7.x
にあるファイルmssql-jdbc-7.2.2.jre8.jar
、adal4j-1.6.7.jar
、gson-2.9.0.jar
、oauth2-oidc-sdk-8.36.2.jar
と、<DENODO_HOME>/lib/contrib
にあるファイルaccessors-smart.jar
、json-smart.jar
、javax.mail.jar
とnimbus-jose-jwt.jar
をコピーしてください。ActiveDirectoryPassword 認証方法を使用して Azure SQL Server を外部メタデータデータベースとして使用するには、すでに指定しているファイルに加えて、
<DENODO_HOME>/lib/contrib/content-type.jar
ファイルを<DENODO_HOME>/lib/data-catalog-extensions
ディレクトリにコピーします。他のデータベースの JDBC については、
<DENODO_HOME>/lib/extensions/jdbc-drivers
に存在する場合もあります。
Data Catalog に管理者アカウントでログインし、メタデータを エクスポート します。
この操作が必要なのは、Data Catalog のメタデータが現在のデータベースから新しいデータベースに自動的に転送されないためです。新規インストールであり、この Data Catalog に他の変更を加えていない場合には、この手順を省略できます。
Denodo Platform のすべてのコンポーネントを停止します。次に、
<DENODO_HOME>/bin/webcontainer_shutdown
を実行して Web コンテナーが停止していることを確認します。Data Catalog と Denodo Platform の他のコンポーネントを開始します。
管理者アカウントで Data Catalog にログインし、[管理] > [設定と管理] > [サーバー] に移動します。[データベース] タブのダイアログから、外部データベースの構成が可能です。
Data Catalog がメタデータを保管するデータベースを構成するダイアログ¶
以下の情報を入力します。
データベース: 使用するデータベースを選びます。
ドライバークラス: 使用する JDBC ドライバーの Java クラスの名前です。通常はデフォルト値のままで問題ありません。
URL: データベースへの接続 URL です。
重要
SQL Server で Microsoft ドライバー 10.x 以降を使用している場合、encrypt プロパティを false に設定する必要があります。それには、データベース URL の末尾に encrypt=false を追加します。以下に例を示します。
jdbc:sqlserver://host:port;databaseName=database;encrypt=false
認証: 外部データベースにアクセスするための認証方法です。Oracle と SQL Server 2014 のデータベースでのみ利用可能です。以下のいずれかの方法を選択します。
ログインとパスワード: デフォルトの認証方法です。データベースへの接続に使用するアカウントの資格情報を使用します。[ユーザー名] (オプション) と [パスワード] (オプション) があります。
パスワードを用いた Kerberos 認証: (Active Directory アカウントで) 指定された [ユーザー名] と [パスワード] を用いて Kerberos 認証を行います。
Keytab を用いた Kerberos: 指定された [ユーザー名] (この場合は、サービスプリンシパル名 - SPN -) と [Keytab ファイル] (パスワードは不要) を用いて、Kerberos 認証を行います。keytab ファイルを [Keytab ファイル] フィールドにドラッグアンドドロップするか、フィールドをクリックしてファイルブラウザーから選択することもできます。
Windows ユーザーを用いた Kerberos 認証: Kerberos によるシングルサインオン (SSO) を用いて、サーバーを起動したユーザーのパススルー認証を行います (ユーザー名とパスワードは不要)。
注釈
選択したデータベースが
Derby Embedded
の場合、[ドライバークラス]、[URL]、[ユーザー名]、[パスワード] のフィールドは編集できません。注釈
SQL Server 2014 で jTDS ドライバーを使用するよう構成するには、[ドライバークラス] で値
net.sourceforge.jtds.jdbc.Driver
を使用し、パターンjdbc:jtds:sqlserver://<host>:<port>/<database>
に従った URL を入力します。クエリ高速化のため、Data Catalog はデータベース接続を保持するプールを作成します。以下のオプション設定によって、プールの構成が可能です。
最大プールサイズ: データベースとの間に存在できる接続の最大数です。この値には、アイドル状態の接続と使用中の接続の両方が含まれます。
最小アイドル接続数: Data Catalog がプールに維持しようとするアイドル接続の最小数です。アイドル接続の数がこの値を下回り、なおかつ、プール内の接続の総数が [最大プールサイズ] より少ない場合、Data Catalog は新規の接続の追加を試みます。
接続タイムアウト: Data Catalog がプールからの接続を待つ最大時間 (ミリ秒単位) です。この時間を超えても接続を利用できない場合、エラーをスローします。
ping クエリ: プールから接続を使用する直前に、接続が有効であることを確認する目的で実行されるクエリです。このクエリが必要なのは、JDBC 4.0
Connection.isValid()
API をサポートしていないレガシードライバーだけです。使用するドライバーが JDBC 4.0 をサポートしている場合、このプロパティを設定しないことを強くお勧めします。注釈
Microsoft SQL Server 用の jTDS ドライバーは JDBC 3.0 しかサポートしないため、レガシーだと見なされます。Data Catalog でこのドライバーを使用するには [ping クエリ] フィールドに値を指定する必要があります。
[保存] ボタンをクリックします。
データベースに到達できること、および必要なテーブルが存在することを Data Catalog がチェックします。
選択したデータベース用の JDBC ドライバーを読み込めなかった場合、以下の警告が表示されます。
JDBC ドライバーを読み込めなかった場合の警告¶
この場合でも構成を保存できますが、JDBC ドライバーを利用できるようにしてから Data Catalog を再起動する必要があります。
何らかの理由でデータベースに到達できなかった場合、以下の警告が表示されます。
データベースに接続できなかった場合の警告¶
この場合でも構成を保存できますが、エラーを修正してから Data Catalog を再起動する必要があります。エラーを修正できない場合、構成の保存はお勧めしません。
データベースに必要なテーブルが存在しない場合、以下の警告が表示されます。
データベースでテーブルを作成するダイアログ¶
Data Catalog にテーブルを作成させるかどうかを決定してください。作成にはデータベース用に構成されたユーザーアカウントを使用するため、データベースでの DDL 権限がアカウントに必要です。あるいは、適切な権限を持つ別のユーザーアカウントを指定しても構いません。
スクリプトを手動で実行する場合は、[キャンセル] ボタンをクリックします。このスクリプトは {<DENODO_HOME>}/scripts/data-catalog/sql/db_scripts` フォルダにあります。
重要
テーブルを作成するスクリプトを手動で実行する場合、プラットフォームの今後の更新のたびに、Data Catalog を再び起動する前に、データベーススキーマを更新する可能性がある新しいスクリプトを手動で実行する必要があります。なぜなら、このケースでは、Data Catalog が自動で新しいスクリプトを実行することはできないからです。
それでもスクリプトを手動で実行する場合は、フォルダ
<DENODO_HOME>/scripts/data-catalog/sql/db_scripts/<DATABASE_TYPE>
に移動して、テーブルを作成するスクリプトを、そのために作成され、Data Catalog で構成されているスキーマで実行します。空のスキーマから始める場合、指定されたフォルダに存在する すべて のスクリプトを、バージョンの昇順に実行する必要があります。
プラットフォーム更新の場合、指定されたフォルダに存在し、それまでの更新で実行されていなかったすべてのスクリプトを、最後に実行されたスクリプトからバージョンの昇順に実行する必要があります。
Data Catalog サーバーのクラスタをセットアップする場合、すべてのサーバーが同じデータベースを共有します。そのため、データベースでのテーブルの作成は 1 回行えば十分です。
Data Catalog を再起動して変更を適用します。
データベース構成のエラーが原因で Data Catalog が起動しない場合、データベース構成を手動でデフォルトに戻すことができます。ファイル
<DENODO_HOME>/conf/data-catalog/datasource.properties
を編集して、その内容を以下に示すように (<DENODO_HOME>
を Denodo インストール環境へのパスで置換) 変更します。datasource.url.default
プロパティにデータベースへのパスが含まれているので、その内容をspring.datasource.url
プロパティにコピーできます。datasource.type=derby datasource.url.default=jdbc:derby:<DENODO_HOME>/metadata/data-catalog-database;create=true spring.datasource.driver-class-name=org.apache.derby.jdbc.EmbeddedDriver spring.datasource.url=jdbc:derby:<DENODO_HOME>/metadata/data-catalog-database;create=true spring.datasource.username= spring.datasource.password.secret=
もう一度 Data Catalog を再起動して変更を適用します。
手順 3 でエクスポートしたメタデータを インポート します。
Data Catalog のクラスタを構築している場合、同じ Web セッションのすべてのリクエストをクラスタの同じノードにリダイレクトするように (つまり、スティッキーセッション) ロードバランサーを構成します。
権限の構成¶
[権限] タブで、ロールに付与する権限を構成できます。権限は 5 つのカテゴリに分かれています。[エレメント権限]、[管理作業]、[コラボレーション]、[ユーザー]、および [Request] です。ロールに対して権限の付与または取り消しを行うには、以下を行う必要があります。
ダイアログでカテゴリを移動します。
ロールに必要な権限を選択または選択解除します。
[保存] ボタンをクリックして変更を適用します。
その後、そのロールを持つすべてのユーザーは、選択した権限に関連付けられているタスクを実行できるようになります。
各権限の詳しい説明については、「 Data Catalog 上の権限 」のセクションを参照してください。

ユーザーの権限を構成するダイアログ¶
Virtual DataPort からロールが削除されている場合、権限テーブルのロールが赤字で示されます。名前の横にある アイコンをクリックすると、Data Catalog からも削除されます。
注釈
[権限] ダイアログで権限を構成するには、ユーザーに次の権限が必要です。
Data Catalog での
Permissions
権限。これは [権限] ダイアログへのアクセスに必要です。Data Catalog での
Configure requests
権限。ユーザーがリクエスト関連の権限を構成する場合に必要です。Virtual DataPort サーバーで利用可能なすべてのロールにアクセスするために必要な以下の権限のいずれか。
Virtual DataPort のデータベースに対する
ADMIN
権限assignprivileges
ロールcreate_role
ロールdrop_role
ロールassign_all_privileges
ロールassign_all_roles
ロールmanage_policies
ロールread_all_privileges
ロール
allusers
ロールを利用できるのは、ロールassign_all_privileges
、assign_all_roles
、またはread_all_privileges
を持つユーザーのみであることを考慮してください。
デフォルトでは、[権限] タブで付与するすべての権限は、カタログ内のすべてのエレメントに適用されます。ただし、リクエストを管理するための権限については、より具体的に指定して、その権限の影響を受けるデータベース、ビュー、または Web サービスを制限できます。たとえば、ロールに Manage access
権限を付与する一方で、その対象を、特定のデータベースのエレメントが関係するリクエストのみに限定できます。[権限] タブのこの詳細ビューにアクセスするには、構成するロールの [ Advanced] 列で アイコンをクリックします。

カタログの特定のエレメントに対してのみ、ロールに権限を付与するためのダイアログ¶
ビューまたは Web サービスに権限を付与するには、単にそのエレメントに対応するチェックボックスを選択します。データベースの場合は、次のように動作が若干異なります。
データベースのチェックボックスを選択すると、現在および将来のデータベースとそのすべてのエレメントに対して権限が付与されます。
データベースに対してのみ権限を付与する場合は、チェックボックスの横にある
アイコンをクリックして、[Assigned to database] を選択します。
このダイアログのチェックボックスは、次の 4 つの状態のいずれかになります。各状態の意味について詳しく見てみましょう。
エレメントに権限は付与されていません。
権限はデータベースにのみ付与されています。データベースのエレメントは権限を継承しません。
この状態の意味は、エレメントに応じて次のように異なります。
データベースの場合、権限はデータベースとそのすべてのエレメントに付与されます。
ビューと Web サービスの場合、権限はエレメントに付与されます。
権限はエレメントに付与されています。権限はデータベースまたはグローバル権限から継承されているため、取り消せません。[権限] タブのメインダイアログから権限を付与すると、その権限はカタログ内のすべてのエレメントに影響することに留意してください。
このダイアログからわかるように、フォルダを権限のターゲットにすることはできません。ただし、フォルダを使用して、同時に複数のエレメントに対して権限を付与または取り消すことができます。フォルダ名の横にある アイコンをクリックして、[Select on all folder elements] メニューで権限の 1 つを選択すると、選択した権限をそのフォルダの下層にある現在のエレメントすべてに付与できます。[Clear on all folder elements] メニューで権限を選択すると、権限が取り消されます。
カタログに含まれるエレメントが多すぎる場合、特に 1 つのエレメントを見つけにくいことがあります。[エレメント] というタイトルのツールを使用してカタログをフィルタできます。検索バーにキーワードを入力してエレメント名でフィルタするか、 ボタンを使用してエレメントのタイプでフィルタします。
大規模言語モデル (LLM) の構成¶
[サーバー設定] 構成の [LLM Configuration] タブでは、Data Catalog の LLM 関連のコンテンツを構成できます。この構成は、以下で説明する複数のセクションに分かれています。
Provider Configuration¶
[LLM Configuration] タブの [Provider configuration] ピルでは、Data Catalog が LLM サービスを利用するために外部 API 位置に対して使用する API を構成できます。

LLM の構成パラメータ。¶
現在、プロバイダーを構成する場合、[Amazon Bedrock]、[Azure OpenAI Service]、[OpenAI]、または [カスタム] の 4 つのオプションがあります。
Amazon Bedrock: 公式の公開 Amazon Bedrock API を構成できます。
Azure OpenAI Service: 公式の公開 Azure OpenAI Service API を構成できます。
OpenAI: 公式の公開 OpenAI API を構成できます。
Custom: カスタム API を構成できます。
重要
プロバイダーを アシスト付きクエリ 機能用に構成している場合は、Denodo からモデルに提供されるプロンプトの固定部分が 3000 トークンを占め、モデルの応答用にさらに多くのトークンが予約されている必要があります。
使用されるモデルで、プロンプトの固定部分と応答の予約トークンだけでなく、相互に作用するビューのスキーマ (フィールド名とその型) に対しても十分な数のトークンをサポートしていることが極めて重要です。ビュースキーマの送信はシステムの機能上必須ですが、フィールドの説明、他のビューとのアソシエーション、値の例などの追加情報に対応するトークンの制限を設定することを強くお勧めします。
少なくとも 10,000 トークンに対応するモデルが推奨されます 。ただし、ビューのメタデータの長さ (説明文の長さなど) によっては、この制限では不十分な場合があります。必要な情報をすべて送信する際にトークンの数が不足している場合、Data Catalog ではトークン削減アルゴリズムを使用して自動的にトークンの数を減らし、ビュースキーマと必須機能の情報を優先します。
注釈
デフォルトでは、トークンの最大数は、選択したモデルで許可されているトークンの最大数です。
Amazon Bedrock プロバイダー¶
ここでは、Amazon Bedrock プロバイダーのパラメータを列挙し、それらについて説明します。

Amazon Bedrock プロバイダーの構成パラメータを示すダイアログ¶
AWS アクセスキー ID: AWS アクセスキーペアの識別子。
AWS シークレットアクセスキー: AWS アクセスキーペアのシークレットアクセスキー。
AWS ARN IAM role.AWS IAM ロール。
AWS リージョン: Amazon Bedrock サービスにアクセスできる AWS リージョン。
モデルのトークン数制限: 編集アイコンをクリックした場合、モデルのトークン数制限パラメータを構成できます。リストのデフォルトモデルを構成した場合、Data Catalog は公式モデルのトークン数制限値を使用します。カスタムモデルを選択してモデルのトークン数制限値を導入しない場合、モデルのトークン数制限のデフォルト値 16384 が割り当てられます。
参考
AWS 認証パラメータの詳細については、「 Amazon AWS セキュリティ資格情報の参照 」を参照してください。
Azure OpenAI Service プロバイダー¶
ここでは、Azure OpenAI Service プロバイダーのパラメータを列挙し、それらについて説明します。

Azure OpenAI Service プロバイダーの構成パラメータを示すダイアログ¶
Azure resource name: Azure リソースの名前。
Azure deployment name: モデルをデプロイする際に選択したデプロイ名。
API version: この操作に使用する API バージョン。これは、YYYY-MM-DD 形式に従います。
API key: API キー。
モデルのトークン数制限: デプロイしたモデルで許可されている最大トークン数。モデルのトークン数制限値を導入しない場合、モデルのトークン数制限のデフォルト値 16384 が割り当てられます。
参考
Azure OpenAI Service プロバイダーのパラメータの詳細については、 Azure OpenAI Service REST API リファレンス を参照してください。
OpenAI プロバイダー¶
ここでは、OpenAI プロバイダーのパラメータについて説明します。

OpenAI プロバイダーの構成パラメータを示すダイアログ¶
API key: OpenAI API キー。このパラメータは必須です。
Organization ID: 構成すると、API リクエストで使用する組織を指定するヘッダーが送信されます。複数の組織に属するユーザーの場合に便利です。このパラメータは必須ではありません。
Model: クエリを生成するために使用するモデル。ドロップダウンに表示される値は、Denodo によってテスト済みです。ただし、未テストの OpenAI モデルを試したい場合は、編集アイコンをクリックすると構成できます。
重要
[Model] フィールドに表示されるモデルは、組織の OpenAI アカウントによっては動作しない可能性があります。それらのモデルを使用できる場合とできない場合があります。
未テストの OpenAI モデルを構成すると、機能が誤動作する可能性があります。
モデルのトークン数制限: 編集アイコンをクリックした場合、モデルのトークン数制限パラメータを構成できます。リストのデフォルトモデルを構成した場合、Data Catalog は公式モデルのトークン数制限値を使用します。カスタムモデルを選択してモデルのトークン数制限値を導入しない場合、モデルのトークン数制限のデフォルト値 16384 が割り当てられます。
参考
OpenAI プロバイダーのパラメータの詳細については、OpenAI プロバイダーのリファレンス Web サイトを参照してください。
カスタムプロバイダー¶
Denodo Platform は、OpenAI と Azure OpenAI Service の両方によって提供される公式プロバイダーに統合できるほか、カスタムプロバイダーオプションを使用することでカスタムプロバイダーとも統合できます。その結果、この機能によってカスタムモデルのサポートが導入され、公式モデルによるデフォルトプロバイダー以外のプロバイダーも選択できるようになります。ただし、アシスト付きクエリ機能には固有の要件があることから、すべてのプロバイダーに Data Catalog との互換性があるとは限りません。この固有の要件は、カスタムプロバイダーが OpenAI チャット補完プロバイダー アプローチと Azure OpenAI Service チャット補完プロバイダー アプローチのどちらに従っているかに応じて異なります。このアプローチに応じて、[Custom compatibility mode] パラメータを適切に設定する必要があります。このパラメータについて以下で詳しく説明します。
Custom compatibility mode¶
[Custom compatibility mode] パラメータを使用すると、 OpenAI チャット補完プロバイダー アプローチまたは Azure OpenAI Service チャット補完プロバイダー アプローチに従ったカスタムプロバイダーに応じて、Data Catalog がリクエストを送信および処理できるようになります。
OpenAI チャット補完プロバイダーアプローチ: カスタムプロバイダーが公式の OpenAI チャット補完プロバイダーを実装している場合、カスタムプロバイダーはこのアプローチに従っていると定義します (
https://platform.openai.com/docs/guides/text-generation/chat-completions-api
を参照)。この場合、[Custom compatibility mode] パラメータを [OpenAI] に設定する必要があります。カスタムプロバイダーと Data Catalog の互換性のために、OpenAI チャット補完プロバイダーのすべてのパラメータが必要なわけではありません。リクエストの本文: Data Catalog は、リクエスト本文で model、messages、および temperature の各パラメータを指定してリクエストを行います。
応答の本文: Data Catalog は、応答の本文に id、object、created、choices、および usage の各パラメータを必要とします。
Azure OpenAI Service チャット補完プロバイダー: カスタムプロバイダーが公式の Azure OpenAI Service チャット補完プロバイダーを実装している場合、カスタムプロバイダーはこのアプローチに従っていると定義します (
https://learn.microsoft.com/en-us/azure/ai-services/openai/reference#chat-completions
を参照)。この場合、[Custom compatibility mode] パラメータを [Azure OpenAI Service] に設定する必要があります。カスタムプロバイダーと Data Catalog の互換性のために、Azure OpenAI Service チャット補完プロバイダーのすべてのパラメータが必要なわけではありません。リクエストの本文: Data Catalog は、リクエスト本文で messages および temperature の各パラメータを指定してリクエストを行います。
応答の本文: Data Catalog は、応答の本文に id、object、created、choices、および usage の各パラメータを必要とします。
次に、それぞれのカスタム互換性モードのパラメータについて説明します。
OpenAI¶

カスタム OpenAI プロバイダーの構成パラメータを示すダイアログ¶
認証: カスタムプロバイダーが認証を必要とするかどうかに応じて、このオプションを構成します。
API key: API キー。認証が有効な場合、このパラメータが必要です。
Organization ID: 構成すると、API リクエストで使用する組織を指定するヘッダーが送信されます。複数の組織に属するユーザーの場合に便利です。認証が有効な場合のみ使用できます。このパラメータは必須ではありません。
カスタム API URI: カスタム API の URI。このパラメータは必須です。
Model: クエリを生成するために使用するモデル。このパラメータは必須です。
モデルのトークン数制限: カスタムモデルで許可されている最大トークン数。このパラメータは必須です。
HTTP プロキシの構成¶
[LLM Configuration] タブの [Proxy configuration] ピルで、HTTP プロキシの構成を指定できます。

プロキシ構成パラメータを示すダイアログ¶
Enable proxy: このトグルは、プロシキ経由のコネクションを有効にします。これが有効な場合、API に対して実行されるリクエストはプロキシに送信されます。
Host: プロキシのホスト名 (IP または DNS 名)。プロキシを使用するには、このパラメータが必須です。
Port: ポート番号。プロキシを使用するには、このパラメータが必須です。
Proxy name: ユーザー名。
Proxy password: パスワード。
注釈
プロキシを構成した後、Data Catalog を再起動する必要があります。