Vue d'ensemble des connexions aux bases de données¶

Table des matières¶

1. Comment fonctionnent les connexions
2. Guides par technologie
3. Prérequis : installer le pilote ODBC sur l'hôte digna
4. Créer une connexion à une base de données
5. Propriétés ODBC
6. Chiffrer les valeurs des propriétés
7. Tester une connexion
8. Quelle base de données la connexion voit
9. Mode de profilage et Work Schema
10. Utiliser un DSN à la place
11. Dépannage

Comment fonctionnent les connexions¶

digna atteint chaque technologie source via ODBC. Une connexion est une liste de propriétés ODBC que vous saisissez sous forme de paires clé/valeur. Lorsque digna ouvre la connexion, il assemble ces paires en une chaîne de connexion — Key=Value, séparées par ;, dans l'ordre où vous les avez listées — et la transmet au gestionnaire de pilotes ODBC de l'hôte digna.

C'est le fait de saisir vous-même les propriétés qui rend la configuration sans DSN : la connexion porte tout ce dont le pilote a besoin, de sorte qu'aucune source de données ODBC (DSN) n'a à être enregistrée sur l'hôte. C'est la manière recommandée de configurer digna, car la définition de la connexion réside entièrement dans digna et se déplace avec lui.

Pourquoi ODBC¶

Les versions antérieures offraient le choix entre un pilote par technologie et ODBC, sélectionné au moyen d'un commutateur Use ODBC. À partir de la version 2026.06, digna s'appuie uniquement sur ODBC. Une interface unique et standard apporte plus qu'un ensemble de pilotes sur mesure :

• Authentification — l'authentification fait partie d'ODBC ; une connexion peut donc utiliser tout ce que son pilote prend en charge : mots de passe, jetons et PAT, Kerberos et Active Directory, MFA et authentification unique via navigateur, identités cloud, certificats client et TLS. Les nouvelles méthodes arrivent avec une mise à jour du pilote, sans attendre une version de digna.
• Pilotes maintenus par les éditeurs de bases de données — le pilote de l'éditeur suit les nouvelles versions du serveur et les correctifs de sécurité, et vous pouvez le mettre à jour à votre propre rythme, indépendamment de digna.
• Une seule façon de tout configurer — chaque technologie est une liste de propriétés clé/valeur, avec la même interface, le même chiffrement des valeurs sensibles et le même dépannage, au lieu d'un jeu de champs différent par source.
• Réglage et portée — les options du pilote telles que les délais d'attente, les paramètres TLS, les proxys et la taille des lots sont disponibles pour toutes les sources, et toute technologie disposant d'un pilote ODBC conforme peut être connectée, y compris celles pour lesquelles digna ne publie pas de guide dédié.

Guides par technologie¶

Les noms des propriétés diffèrent selon le pilote, et chaque technologie présente un ou deux détails que les autres n'ont pas. Les guides ci-dessous couvrent cette partie ; cette page couvre la partie digna, qui est la même pour toutes.

Prérequis : installer le pilote ODBC sur l'hôte digna¶

digna ouvre les connexions sources depuis le serveur qui exécute le backend digna, pas depuis le navigateur. Le pilote ODBC doit donc être installé sur cette machine, et son nom enregistré auprès du gestionnaire de pilotes local.

odbcinst -q -d

odbcinst -q -d

À la place d'un nom enregistré, tous les gestionnaires de pilotes courants acceptent également le chemin complet vers la bibliothèque du pilote, par exemple Driver=/opt/simba/spark/lib/64/libsparkodbc_sb64.so. C'est utile lorsque le pilote est installé mais non enregistré.

Créer une connexion à une base de données¶

Ouvrez l'Admin Panel, allez dans l'onglet Database Connections et cliquez sur Add DB Connection. L'écran demande cinq éléments :

Une connexion est administrée de façon centralisée puis affectée à un ou plusieurs projets, de sorte que la même connexion peut desservir plusieurs projets.

Propriétés ODBC¶

Cliquez sur Add Property pour chaque propriété et renseignez Key, Value et, pour les secrets, la case Encrypted. Chaque guide de technologie liste un jeu d'exemple pour la technologie concernée, que vous adaptez à votre version de pilote et à votre serveur — voir la note ci-dessus.

Quel que soit le pilote, un jeu de propriétés couvre les mêmes quatre éléments :

• Driver — le nom du pilote enregistré, comme décrit ci-dessus.
• L'adresse du serveur — la clé diffère selon le pilote : SERVER, HOST, DBCNAME, Server ou, pour Oracle, le descripteur de connexion DBQ.
• Les identifiants — généralement UID et PWD ; Snowflake utilise UID plus un token, et Databricks l'utilisateur littéral token plus le jeton d'accès personnel dans PWD.
• La base ou le catalogue dans lequel travailler, lorsque la technologie en possède un — voir Quelle base de données la connexion voit.

Tout ce que le pilote documente par ailleurs peut être ajouté de la même manière — pool de connexions, délais d'expiration de socket, paramètres Kerberos, paramètres de proxy. digna n'interprète pas les propriétés ; il ne fait que les transmettre.

Chiffrer les valeurs des propriétés¶

Cochez Encrypted pour chaque propriété contenant un secret — PWD, token, un secret client. La valeur est alors chiffrée avant d'être stockée dans le référentiel digna, masquée à l'écran, et déchiffrée uniquement au moment de l'assemblage de la chaîne de connexion.

Les propriétés qui ne sont pas secrètes — nom du pilote, hôte, port, base de données — sont à laisser de préférence non chiffrées, afin qu'elles restent lisibles pour la personne qui maintiendra la connexion par la suite.

Tester une connexion¶

Cliquez sur Test dans la boîte de dialogue Add DB Connection avant d'enregistrer. Le test utilise les valeurs actuellement présentes dans le formulaire et effectue une véritable connexion ; il signale donc exactement ce qu'une inspection rencontrerait — un nom de pilote erroné, un mot de passe rejeté, un hôte injoignable. Rien n'est stocké : la connexion de test est annulée qu'elle réussisse ou échoue.

Pour une connexion déjà existante, survolez sa ligne dans l'onglet Database Connections et cliquez sur l'icône prise pour la retester. C'est le moyen le plus rapide de vérifier qu'une source est joignable après une rotation de mot de passe ou une modification de pare-feu.

Quelle base de données la connexion voit¶

Lorsque vous ajoutez une source de données, digna propose les catalogues, schémas et tables que la connexion peut atteindre. L'étendue dépend de la technologie :

Mode de profilage et Work Schema¶

Le mode de profilage détermine comment digna traite les données et calcule les métriques :

• Standard : les métriques sont calculées directement sur les tables sources, sans copier les données.
• Permanent : les données du jour inspecté sont copiées dans une table permanente, et les métriques sont calculées sur les données copiées.
• Session : les données sont copiées dans une table de session ou temporaire, et les métriques sont calculées sur ces données temporaires.

Le mode détermine ce que l'utilisateur de la connexion doit être autorisé à faire :

Standard se contente de lire, ce qui en fait le mode à choisir lorsque digna ne dispose que d'un accès en lecture seule. Work Schema n'est lu que pour Permanent, mais il vaut la peine de le renseigner malgré tout afin que la connexion continue de fonctionner si le mode est modifié par la suite.

Utiliser un DSN à la place¶

Un DSN fonctionne toujours — DSN n'est qu'une propriété parmi d'autres :

Key: DSN        Value: my_registered_dsn
Key: UID        Value: <user>
Key: PWD        Value: <password>        [Encrypted]

Le DSN doit être enregistré sur l'hôte digna, pour le compte utilisateur qui exécute le backend digna, et en tant que System DSN lorsque digna s'exécute comme service. Tout ce qui est configuré dans le DSN peut être remplacé en l'ajoutant également comme propriété.

Le mode sans DSN est la valeur par défaut documentée parce qu'il évite cet état côté hôte : la connexion est entièrement décrite dans digna, et un nouvel hôte digna a besoin du pilote installé, mais de rien de configuré.

Dépannage¶

Nom de source de données introuvable / aucun pilote par défaut spécifié¶

Symptômes : - Le bouton Test signale une erreur mentionnant data source name not found, alors même que la configuration est sans DSN

Causes et solutions : 1. La valeur de Driver ne correspond à aucun nom de pilote enregistré — comparez-la avec l'onglet Drivers de l'Administrateur de sources de données ODBC (64 bits), ou avec odbcinst -q -d 2. Le pilote est installé sur votre poste de travail mais pas sur l'hôte digna 3. Le pilote est en 32 bits alors que digna est en 64 bits — installez le pilote 64 bits 4. La propriété Driver est totalement absente, et aucun DSN n'a été fourni non plus 5. Sous Linux et macOS, le pilote est installé mais non enregistré — indiquez plutôt le chemin complet vers la bibliothèque du pilote, ou enregistrez-le dans odbcinst.ini

Le test de connexion expire¶

Symptômes : - Test se bloque puis échoue au bout d'environ une demi-minute

Causes et solutions : 1. L'hôte ou le port sont injoignables depuis l'hôte digna — vérifiez le pare-feu et, pour les sources cloud, la liste d'adresses IP autorisées 2. Le nom d'hôte est correct mais le port appartient à un autre service 3. La source a besoin de plus que les 30 secondes par défaut pour accepter une connexion — augmentez DIGNA_SOURCE_LOGIN_TIMEOUT_SEC dans la section [base] de config.toml (0 attend indéfiniment) et redémarrez le backend 4. Un point de terminaison serverless sort de veille — réessayez, et si cela se produit régulièrement, augmentez le délai de connexion comme ci-dessus

L'authentification échoue alors que les identifiants sont corrects¶

Symptômes : - Le pilote signale des identifiants non valides, mais le même utilisateur fonctionne dans un autre client SQL

Causes et solutions : 1. Le mot de passe contient ; — encadrez la valeur d'accolades : {p@ss;word} 2. Un espace en fin de chaîne a été copié dans la valeur 3. Le pilote attend un mécanisme d'authentification précis — par exemple AuthMech pour les pilotes Hive et Databricks, ou authenticator pour Snowflake 4. La valeur a été stockée chiffrée puis modifiée — les valeurs chiffrées ne peuvent pas être relues, ressaisissez donc le secret dans son intégralité 5. Un jeton a expiré — les jetons d'accès personnels et les jetons d'accès programmatique sont émis avec une date d'expiration

L'écran des sources de données ne propose pas la base ou le schéma attendu¶

Symptômes : - Des catalogues, schémas ou tables manquent lors de l'ajout d'une source de données

Causes et solutions : 1. La connexion pointe vers une autre base — voir Quelle base de données la connexion voit 2. L'utilisateur de la connexion n'a pas les droits de lecture sur le schéma ou sur le dictionnaire de données 3. Technology ne correspond pas à la source, digna interroge donc le mauvais dictionnaire de données 4. Pour Snowflake, aucun entrepôt par défaut n'est affecté à l'utilisateur et aucune propriété Warehouse n'a été fournie, de sorte que les requêtes de métadonnées ne peuvent pas s'exécuter

Le profilage échoue alors que le test de connexion réussit¶

Symptômes : - Test réussit, mais une inspection échoue au moment de créer les tables de travail

Causes et solutions : 1. Le profilage Permanent est sélectionné et l'utilisateur de la connexion ne peut pas créer de tables dans Work Schema — accordez les droits, ou passez à Session ou Standard 2. Work Schema est vide ou nomme un schéma inexistant, alors que le profilage Permanent est sélectionné 3. Le profilage Session est sélectionné et l'utilisateur de la connexion n'a pas le droit de créer des tables temporaires 4. Une requête de profilage de longue durée atteint le délai d'expiration des requêtes — augmentez DIGNA_SOURCE_QUERY_TIMEOUT_SEC dans la section [base] de config.toml (3600 secondes par défaut, 0 désactive le délai)

Bonnes pratiques¶

À FAIRE :

• Installer et enregistrer le pilote sur l'hôte digna avant de configurer la connexion
• Cocher Encrypted pour chaque mot de passe et chaque jeton
• Cliquer sur Test avant d'enregistrer, et retester après une rotation de mot de passe
• Nommer les connexions d'après la source et l'environnement, par exemple sales_dwh_prod
• Donner à digna un utilisateur de base dédié, en lecture seule lorsque le profilage Standard suffit
• Conserver une connexion par base source, et en ajouter une seconde plutôt que de modifier la première

À NE PAS FAIRE :

• Stocker des secrets en clair, ou partager un utilisateur de base entre digna et d'autres outils
• Utiliser un pilote 32 bits avec une installation digna 64 bits
• Compter sur un DSN utilisateur lorsque digna s'exécute comme service — il ne sera pas visible
• Placer une valeur contenant ; dans une propriété sans accolades
• Faire pointer Work Schema vers un schéma qui contient des données sources

Support¶

Besoin d'aide pour une connexion à une base de données ?

• E-mail : support@digna.ai
• Documentation : https://docs.digna.ai
• Site web : https://www.digna.ai

Release: 2026.06
© 2026 digna GmbH — www.digna.ai