データベース接続の概要¶
目次¶
- 接続の仕組み
- テクノロジー別ガイド
- 前提条件: digna ホストに ODBC ドライバーをインストールする
- データベース接続を作成する
- ODBC プロパティ
- プロパティ値の暗号化
- 接続のテスト
- 接続から見えるデータベース
- プロファイリングモードとワークスキーマ
- 代わりに DSN を使用する
- トラブルシューティング
接続の仕組み¶
digna はすべてのソーステクノロジーに ODBC 経由で接続します。接続とは、キーと値のペアとして入力する ODBC プロパティのリストです。digna が接続を開くとき、それらのペアを接続文字列に結合し(Key=Value を ; で区切り、 入力した順序のまま)、digna ホスト上の ODBC ドライバーマネージャーに渡します。
プロパティを自分で入力することで、セットアップは DSN レス になります。接続にはドライバーが必要とするすべての情報が 含まれているため、ホスト上に ODBC データソース (DSN) を登録する必要はありません。接続の定義がすべて digna の中にあり、 digna と一緒に移行できるため、これが digna の推奨される設定方法です。
ODBC を採用する理由¶
以前のリリースでは、テクノロジー専用のドライバーと ODBC のどちらかを Use ODBC スイッチで選択できました。 Release 2026.06 以降、digna は ODBC のみに基づいています。単一の標準インターフェースは、個別に作り込んだドライバー群 よりも多くの利点をもたらします。
- 認証 — 認証は ODBC の一部であるため、接続ではドライバーがサポートする任意の方式を利用できます。パスワード、 トークンと PAT、Kerberos と Active Directory、MFA とブラウザーベースのシングルサインオン、クラウド ID、 クライアント証明書と TLS などです。新しい方式は digna のリリースを待たずに、ドライバーの更新とともに利用可能になります。
- データベースベンダーが保守するドライバー — ベンダー自身のドライバーは新しいサーバーバージョンやセキュリティ修正に 追従しており、digna とは独立して、ご自身のスケジュールで更新できます。
- すべてを同じ方法で設定 — ソースごとに異なる入力フィールドを使うのではなく、すべてのテクノロジーがキーと値の プロパティのリストで表され、同じインターフェース、同じ機密値の暗号化、同じトラブルシューティングが適用されます。
- チューニングと適用範囲 — タイムアウト、TLS 設定、プロキシ、フェッチサイズなどのドライバーレベルのオプションを すべてのソースで使用でき、準拠した ODBC ドライバーがあるテクノロジーであれば、digna が専用ガイドを公開していない ものも含めて接続できます。
インターフェースの変更点
Use ODBC スイッチと、ホスト、ポート、データベース、ユーザー、パスワードの個別フィールドは廃止されました。 まだ ODBC を使用していない接続は、ODBC プロパティを入力するまで再び動作しません。 データベース接続を作成する を参照してください。
テクノロジー別ガイド¶
プロパティ名はドライバーごとに異なり、各テクノロジーには他にはない細かな点が 1~2 個あります。以下のガイドはその部分を 扱います。このページは、すべてのテクノロジーで共通の digna 側の設定を説明します。
ガイドのプロパティセットは例です
各ガイドは、動作が確認されている組み合わせ(digna のテストで使用しているもの)を 1 つ示しています。 これは出発点であり、仕様ではありません。プロパティは ODBC ドライバーに属するものであり、どのプロパティが存在し、 どのような名前で、どの値を受け付けるかは、ドライバーのバージョンやベンダー、Windows・Linux・macOS の違い、 そしてソースサーバーの構成(認証方式、TLS、ゲートウェイ、ポート)によって異なります。値を 1~2 個調整する 必要があると考え、インストールしたドライバーバージョンのドキュメントを正としてください。
| テクノロジー | ガイド | 知っておくべきこと |
|---|---|---|
| Azure Synapse Analytics | Azure Synapse | サーバーレスプールではホスト名に -ondemand が必要で、Standard プロファイリングのみサポート |
| Databricks | Databricks | トークン認証: UID=token、PWD に PAT |
| Apache Hive | Hive | カタログはクエリではなくドライバーから取得される |
| Netezza | Netezza | ドライバー名は波括弧で囲む: {NetezzaSQL} |
| Oracle | Oracle | DBQ には完全な接続記述子または tnsnames.ora のエイリアスを指定 |
| PostgreSQL | PostgreSQL | SSLMode はサーバーの要求と一致させる必要がある |
| Snowflake | Snowflake | テスト済みの認証方式はプログラムによるアクセストークン |
| MS SQL Server | MS SQL Server | DATABASE によって digna が参照できるスキーマが決まる |
| Teradata | Teradata | ホストは DBCNAME に指定。データベースはスキーマとして扱われる |
前提条件: digna ホストに ODBC ドライバーをインストールする¶
digna はソース接続をブラウザーからではなく、digna バックエンドを実行しているサーバー から開きます。そのため、 ODBC ドライバーはそのマシンにインストールされ、その名前がローカルのドライバーマネージャーに登録されている必要があります。
ベンダーの 64 ビットドライバーをインストールし、ODBC Data Source Administrator (64-bit) を開いて Drivers タブに切り替えます。そこに表示される名前が、Driver プロパティに使用できる値そのものです。
unixODBC とベンダーのドライバーをインストールし、登録済みのドライバー名を一覧表示します。
角括弧内に表示される名前が、Driver プロパティに使用できる値です。これらは /etc/odbcinst.ini (または odbcinst -j が示すファイル)から読み込まれます。
ドライバー名は 1 文字ずつ正確に一致している必要があります
Driver はそのままドライバーマネージャーに渡されます。ドライバーマネージャーにとって Simba Spark ODBC Driver と Simba Spark ODBC Driver 64 は別のドライバーであり、登録されていない名前を 指定すると、DSN を使っていないにもかかわらず data source name not found エラーになります。
登録名の代わりに、一般的なドライバーマネージャーはいずれもドライバーライブラリへのフルパスも受け付けます。例: Driver=/opt/simba/spark/lib/64/libsparkodbc_sb64.so。これはドライバーがインストールされているものの登録されていない 場合に便利です。
データベース接続を作成する¶
Admin Panel を開き、Database Connections タブに移動して Add DB Connection をクリックします。 画面では次の 5 項目を入力します。
| フィールド | 説明 |
|---|---|
| Name | 接続の名前。他の画面で接続を参照する際に使用されます。 |
| Technology | Postgres、Oracle、SQL Server、Databricks、Teradata、Netezza、Snowflake、Hive のいずれか。digna が生成する SQL の方言を決めるため、ドライバーではなくソースに一致させる必要があります。Azure Synapse Analytics は SQL Server 接続です。 |
| ODBC Properties | ODBC プロパティ で説明するキーと値のペア。 |
| Profiling Mode | Standard、Permanent、Session のいずれか。プロファイリングモードとワークスキーマ を参照してください。 |
| Work Schema | Permanent プロファイリング用のワークテーブルを保持するスキーマ。 |
接続は一元管理され、1 つ以上のプロジェクトに割り当てられるため、同じ接続を複数のプロジェクトで利用できます。
ODBC プロパティ¶
プロパティごとに Add Property をクリックし、Key と Value を入力します。シークレットの場合は Encrypted チェックボックスもオンにします。各テクノロジー別ガイドにはそのテクノロジー用のプロパティセットの例が 掲載されているので、ドライバーのバージョンとサーバーに合わせて調整してください。上記の注記 を 参照してください。
ドライバーが何であれ、プロパティセットは次の 4 つを扱います。
Driver— 上記 で説明した、登録済みのドライバー名。- サーバーのアドレス — キーはドライバーごとに異なります:
SERVER、HOST、DBCNAME、Server、 Oracle の場合はDBQ接続記述子。 - 認証情報 — 通常は
UIDとPWD。Snowflake はUIDとtokenを使用し、Databricks はリテラルのユーザーtokenと、PWDに個人用アクセストークンを使用します。 - 作業対象のデータベースまたはカタログ(テクノロジーにその概念がある場合)— 接続から見えるデータベース を参照してください。
ドライバーのドキュメントに記載されているその他の項目も、同じ方法で追加できます。接続プーリング、ソケットタイムアウト、 Kerberos 設定、プロキシ設定などです。digna はプロパティを解釈せず、そのまま渡すだけです。
値はエスケープされません — セミコロンを含むものは波括弧で囲んでください
プロパティは ; で結合されるため、値自体に ; が含まれていると、接続文字列が誤った位置で分割されます。 そのような値は波括弧で囲んでください: PWD={p@ss;word}。= や先頭の空白を含む値も同様です。 これが、{NetezzaSQL} や {SnowflakeDSIIDriver} のように、一部のドライバーを慣例的に波括弧付きで記述する 理由でもあります。
プロパティ値の暗号化¶
シークレットを保持するすべてのプロパティ(PWD、token、クライアントシークレット)で Encrypted をオンにします。 値は digna リポジトリに保存される前に暗号化され、画面上ではマスクされ、接続文字列を組み立てるときにのみ復号されます。
ヒント
暗号化された値は、UI からも API からも読み戻すことはできず、置き換えることしかできません。 シークレットはご自身のパスワードマネージャーにも保管してください。
ドライバー名、ホスト、ポート、データベースなど機密でないプロパティは、後で接続を保守する人が読めるよう、 暗号化しないでおくことをお勧めします。
接続のテスト¶
保存する 前に、Add DB Connection ダイアログで Test をクリックします。テストはフォームに現在入力されている値を 使って実際に接続するため、インスペクションで発生するのとまったく同じ問題(誤ったドライバー名、拒否されたパスワード、 到達できないホスト)を報告します。何も保存されず、テスト接続は成功しても失敗してもロールバックされます。
既存の接続については、Database Connections タブでその行にカーソルを合わせ、プラグ アイコンをクリックすると 再テストできます。パスワードの変更やファイアウォールの変更の後に、ソースに到達できるかを確認する最も手早い方法です。
接続から見えるデータベース¶
データソースを追加するとき、digna は接続から到達できるカタログ、スキーマ、テーブルを提示します。その範囲は テクノロジーによって異なります。
| テクノロジー | 提示されるカタログ |
|---|---|
| PostgreSQL, MS SQL Server, Oracle, Snowflake | 接続の 現在の データベースのみ |
| Teradata, Netezza, Databricks | ユーザーが参照を許可されているすべてのデータベースまたはカタログ |
| Hive, Impala | ドライバーが報告するもの |
1 つの接続に 1 つのデータベース
PostgreSQL、SQL Server、Oracle、Snowflake では、プロパティがソーススキーマを保持するデータベースを指している 必要があります。DATABASE=…、Database=…、または Oracle の DBQ 内のサービス名です。別のデータベースの テーブルにはその接続では到達できないため、そのための 2 つ目の接続を追加してください。
プロファイリングモードとワークスキーマ¶
プロファイリングモードは、digna がデータを処理しメトリクスを計算する方法を決定します。
- Standard: データをコピーせず、ソーステーブル上で直接メトリクスを計算します。
- Permanent: インスペクション対象日のデータを永続テーブルにコピーし、コピーしたデータでメトリクスを計算します。
- Session: データをセッションテーブルまたは一時テーブルにコピーし、この一時データでメトリクスを計算します。
モードによって、接続ユーザーに必要な権限が決まります。
| モード | 書き込み内容 | 接続ユーザーに必要な権限 |
|---|---|---|
| Standard | なし | ソーステーブルの読み取り |
| Permanent | Work Schema 内にデータソースごとに 1 つのテーブル | Work Schema でのテーブルの作成と削除 |
| Session | セッション終了時にデータベースが削除する一時テーブル | 一時テーブルの作成 — Work Schema は使用されません |
Standard は読み取りのみを行うため、digna に読み取り専用のアクセス権が付与されている場合に選ぶべきモードです。 Work Schema は Permanent の場合にのみ参照されますが、後でモードを変更しても接続が動作し続けるよう、入力しておく 価値があります。
代わりに DSN を使用する¶
DSN も引き続き使用できます。DSN は単なるプロパティの 1 つです。
DSN は digna ホスト上で、digna バックエンドを実行するのと同じユーザーアカウントに対して登録されている必要があり、 digna がサービスとして実行される場合は System DSN として登録する必要があります。DSN で設定されている項目は、 プロパティとして追加することで上書きすることもできます。
DSN レスがドキュメント上の標準であるのは、このようなホスト側の状態を避けられるためです。接続は digna の中で完全に 記述され、新しい digna ホストにはドライバーのインストールだけが必要で、それ以外の設定は不要です。
トラブルシューティング¶
Data source name not found / no default driver specified¶
症状: - セットアップが DSN レスであるにもかかわらず、Test ボタンで data source name not found を含むエラーが報告される
原因と対処法: 1. Driver の値が登録済みのドライバー名と一致していない — ODBC Data Source Administrator (64-bit) の Drivers タブ、または odbcinst -q -d の出力と比較してください 2. ドライバーがご自身のワークステーションにはインストールされているが、digna ホストにはインストールされていない 3. ドライバーが 32 ビットで digna が 64 ビットである — 64 ビットドライバーをインストールしてください 4. Driver プロパティがまったくなく、DSN も指定されていない 5. Linux と macOS で、ドライバーはインストールされているが登録されていない — 代わりにドライバーライブラリへの フルパスを指定するか、odbcinst.ini に登録してください
接続テストがタイムアウトする¶
症状: - Test が応答しなくなり、約 30 秒後に失敗する
原因と対処法: 1. digna ホストからホストまたはポートに到達できない — ファイアウォールを確認し、クラウドソースの場合は IP 許可リストも確認してください 2. ホスト名は正しいが、ポートが別のサービスのものである 3. ソースが接続を受け付けるのに既定の 30 秒以上かかる — config.toml の [base] セクションで DIGNA_SOURCE_LOGIN_TIMEOUT_SEC を引き上げ(0 は無期限に待機)、バックエンドを再起動してください 4. サーバーレスのエンドポイントがアイドル状態から再開中である — 再試行し、これが日常的に起こる場合は上記のとおり ログインタイムアウトを引き上げてください
認証情報が正しいのに認証に失敗する¶
症状: - ドライバーが無効な認証情報を報告するが、同じユーザーが別の SQL クライアントでは使用できる
原因と対処法: 1. パスワードに ; が含まれている — 値を波括弧で囲んでください: {p@ss;word} 2. 値の末尾に空白がコピーされている 3. ドライバーが特定の認証メカニズムを要求している — 例えば Hive と Databricks のドライバーでは AuthMech、 Snowflake では authenticator 4. 値が暗号化して保存された後に編集された — 暗号化された値は読み戻せないため、シークレットを最初から入力し直してください 5. トークンの有効期限が切れている — 個人用アクセストークンとプログラムによるアクセストークンには有効期限があります
データソース画面に想定したデータベースやスキーマが表示されない¶
症状: - データソースを追加するときに、カタログ、スキーマ、またはテーブルが表示されない
原因と対処法: 1. 接続が別のデータベースを指している — 接続から見えるデータベース を参照してください 2. 接続ユーザーにスキーマまたはデータディクショナリの読み取り権限がない 3. Technology がソースと一致しておらず、digna が誤ったデータディクショナリを照会している 4. Snowflake で、ユーザーに既定のウェアハウスが割り当てられておらず、Warehouse プロパティも指定されていないため、 メタデータクエリを実行できない
接続テストは成功するがプロファイリングが失敗する¶
症状: - Test は成功するが、ワークテーブルの作成時にインスペクションが失敗する
原因と対処法: 1. Permanent プロファイリングが選択されており、接続ユーザーが Work Schema にテーブルを作成できない — 権限を付与するか、Session または Standard に切り替えてください 2. Permanent プロファイリングが選択されているのに、Work Schema が空であるか、存在しないスキーマを指定している 3. Session プロファイリングが選択されており、接続ユーザーが一時テーブルを作成できない 4. 長時間実行されるプロファイリングクエリがクエリタイムアウトに達している — config.toml の [base] セクションで DIGNA_SOURCE_QUERY_TIMEOUT_SEC を引き上げてください(既定値は 3600 秒、0 でタイムアウトを無効化)
ベストプラクティス¶
推奨:
- 接続を設定する前に、digna ホストにドライバーをインストールして登録する
- すべてのパスワードとトークンで Encrypted をオンにする
- 保存する前に Test をクリックし、パスワードの変更後にも再テストする
- 接続にはソースと環境にちなんだ名前を付ける(例:
sales_dwh_prod) - digna には専用のデータベースユーザーを割り当て、Standard プロファイリングで十分な場合は読み取り専用にする
- ソースデータベースごとに 1 つの接続を保ち、既存の接続を切り替えるのではなく 2 つ目の接続を追加する
非推奨:
- シークレットを暗号化せずに保存する、または 1 つのデータベースユーザーを digna と他のツールで共有する
- 64 ビットの digna インストールで 32 ビットのドライバーを使用する
- digna がサービスとして実行されているときに User DSN に頼る — 参照できません
;を含む値を波括弧なしでプロパティに入力する- Work Schema にソースデータを保持するスキーマを指定する
サポート¶
データベース接続についてサポートが必要ですか?
- メール: support@digna.ai
- ドキュメント: https://docs.digna.ai
- ウェブサイト: https://www.digna.ai
Release: 2026.06
© 2026 digna GmbH — www.digna.ai