En résumé
Une base de données est une connexion vers vos données, déclarée une fois dans l’espace de travail puis liée aux projets qui en ont besoin. On lui rattache un schéma pour que Linkr sache lire ses tables, et sa page de détail donne ses statistiques et l’exploration de ses colonnes. Linkr lit vos données : il n’y écrit jamais, et un export de base ne contient jamais de données.
Une base appartient à l’espace de travail
C’est le point qui surprend le plus au début : on ne crée pas une base « dans un projet ». On la déclare une fois dans l’entrepôt de l’espace de travail, et chaque projet qui en a besoin s’y lie.
Depuis l’espace de travail
La base se crée, se modifie, s’exporte et se versionne.
C’est le seul endroit où l’on touche à la connexion elle-même. La suppression y est définitive : elle retire les fichiers, les statistiques en cache, et délie tous les projets concernés.
Depuis un projet
La base se lie et se délie — rien de plus.
La page projet est en lecture seule : on y consulte l’aperçu, les statistiques et le schéma. Délier ne supprime rien, la base reste dans l’entrepôt.
Le bouton Lier une base d’un projet ne propose que les bases du même espace de travail pas encore liées. S’il n’y en a aucune, il ouvre directement la création — la nouvelle base est alors rattachée au projet dans la foulée.
Ajouter une base
Depuis Entrepôt de données › Bases de données, le bouton Ajouter une base ouvre deux possibilités.
Ajouter une connexion
Pointer vers des données qui existent déjà : un fichier, un dossier de Parquet, ou un serveur de base de données.
Nouveau depuis un schéma
Créer une base vide dont les tables sont fabriquées à partir du DDL d’un schéma installé. C’est la cible naturelle d’un pipeline ETL.
Le bouton Importer à côté accepte un ZIP de base exporté, ou installe une base publiée depuis le catalogue de données.
Choisir un type de connexion
L’assistant demande d’abord le type. Aujourd’hui, un seul est ouvert : Base de données, qui couvre DuckDB, PostgreSQL, MySQL et SQLite. La tuile Serveur FHIR est visible mais désactivée, marquée « bientôt disponible ».
Les moteurs disponibles dépendent du mode
En mode navigateur, seuls DuckDB et SQLite sont proposés : ce sont des fichiers, et le navigateur sait les lire. PostgreSQL et MySQL supposent un serveur qui ouvre la connexion réseau à votre place, ils n’apparaissent donc qu’en mode serveur.
Nommer et identifier
L’onglet Général demande trois choses, dont une seule est obligatoire.
- Nom — obligatoire, et unique dans l’espace de travail.
- Identifiant — un slug court, dérivé automatiquement du nom. C’est le nom sous lequel vos requêtes SQL désignent la base.
- Description — facultative, mais c’est elle qui s’affiche sur la carte.
L'identifiant est figé après la création
Il devient le nom de catalogue DuckDB de la base. Le changer orphelinerait tous les scripts et requêtes qui l’utilisent : le champ est donc en lecture seule dès que la base existe. Autant le choisir correctement du premier coup — et en donner un distinct à chaque base.
Configurer la connexion
L’onglet Connexion s’adapte au moteur choisi.
| Moteur | Ce qu’on fournit |
|---|---|
| DuckDB | Un fichier .duckdb, ou un dossier de Parquet — le mode d’import se choisit avec deux boutons. |
| SQLite | Un fichier .sqlite ou .db. |
| PostgreSQL, MySQL | Hôte, port, base, schéma, identifiant, mot de passe. |
C’est aussi ici qu’on choisit le schéma de la base — voir la section suivante. L’onglet Métadonnées ajoute des badges libres et un numéro de version ; l’onglet Attribution, disponible à la modification, porte l’auteur et l’organisation.
Les mots de passe ne sont jamais renvoyés
En mode serveur, un mot de passe est chiffré avant d’être stocké et n’est déchiffré que le temps d’ouvrir une connexion. L’API ne le renvoie jamais, et modifier les autres champs d’une base ne l’efface pas. Il ne sort pas non plus à l’export : voir Configuration du serveur.
Fichiers : où vivent-ils ?
C’est la différence la plus concrète entre les deux modes de déploiement.
Mode navigateur
Les données sont copiées dans le navigateur, avec un plafond.
Un avertissement apparaît vers 500 Mo et l’import est bloqué au-delà de 2 Go. Sur Chrome et Edge, l’accès direct contourne la limite : Linkr lit le fichier sur place sans rien copier. Il faut alors reconnecter la base après un rechargement de page, le navigateur ne conservant pas l’autorisation.
Mode serveur
Les fichiers montent vers le serveur par morceaux, sans plafond.
Une seconde option apparaît : Choisir sur le serveur, qui pointe vers un fichier ou un dossier déjà présent — rien n’est copié. La page de détail affiche alors le chemin absolu, copiable, pour lire la même base depuis un script R ou Python hors de Linkr.
Ne fermez pas la fenêtre pendant un import
Tant qu’un transfert est en cours, la boîte de dialogue refuse de se fermer — croix, Échap et clic à l’extérieur sont neutralisés. Un import interrompu ne reprend pas : il faut le recommencer.
Rattacher un schéma
Une base sans schéma reste interrogeable en SQL, mais Linkr ne sait pas ce que ses tables représentent. Le champ Schéma de l’onglet Connexion répond à cette question, en proposant les schémas installés dans l’espace de travail.
Le choix est facultatif — l’option Aucun schéma (accès SQL brut) est légitime pour une base qu’on ne veut qu’interroger. Mais il conditionne une bonne partie de l’entrepôt :
| Sans schéma | Avec un schéma |
|---|---|
| Le nombre de lignes par table | Patients, hospitalisations, séjours en unité, pyramide des âges, chronologie des admissions |
| L’exploration SQL libre | Les concepts, les cohortes, les données patient, les contrôles qualité |
La base copie la définition du schéma plutôt que d’y renvoyer, tout en gardant trace de son origine. Une base importée sur une instance où le schéma n’est pas installé reste donc lisible : Linkr affiche simplement « Schéma (non installé) ». Voir Schémas.
La page de détail
Cliquer une carte ouvre la base. Trois onglets sont toujours là ; depuis l’espace de travail, un menu Plus en ajoute trois autres et l’action d’export.
Aperçu
Les compteurs, le readme, et trois cartes latérales : À propos (auteur, organisation, licence, version), le schéma rattaché, et la connexion — statut, moteur, identifiant, chemin du fichier.
Statistiques
Répartition par sexe, pyramide des âges, durées de séjour, chronologie des admissions, et le nombre de lignes de chaque table.
Schéma
Un explorateur à trois volets — tables, colonnes, statistiques de colonne : complétude, valeurs distinctes, min/max, distribution, valeurs les plus fréquentes. La base doit être connectée.
Les trois autres onglets, réservés à l’espace de travail, sont Readme, Licence et Versioning. L’onglet actif est inscrit dans l’URL : un lien vers une base pointe donc vers le bon onglet.
Les statistiques ne se calculent qu'à la demande
Se connecter à une base ne déclenche aucun comptage — sur un entrepôt volumineux ce serait long et inutile. Les compteurs affichent « — » jusqu’à ce que vous cliquiez sur Charger les statistiques. Le résultat est ensuite mis en cache, avec la date du dernier calcul et un bouton Actualiser.
Écrire du SQL sur une base
L’identifiant de la base sert à la désigner dans vos requêtes, mais on en a moins besoin qu’on ne le croit : une requête qui ne touche qu’une seule base s’écrit avec des noms de table nus.
SELECT person_id, year_of_birth
FROM person
WHERE year_of_birth > 1980Le préfixe ne devient nécessaire que pour une requête qui croise plusieurs bases, et seulement en mode navigateur — où la base est attachée sous le nom ds_<identifiant>. L’éditeur SQL propose alors un bouton pour copier la référence exacte.
SELECT a.person_id
FROM "ds_mimic_iv_raw".person a
JOIN "ds_registre_local".inclusion b USING (person_id)Dans un pipeline ETL, n'écrivez jamais ce préfixe
Les scripts ETL désignent leurs bases par leur rôle — source., target., vocab. — que Linkr remplace par le vrai schéma à l’exécution. Un script qui code en dur ds_quelque_chose cesse de fonctionner dès que le pipeline est exporté vers un autre établissement, où cet identifiant n’existe pas. Voir Pipelines ETL.
Ce que Linkr ne fait pas à vos données
Un export de base ne contient jamais de données
L’export d’une base emporte sa documentation, son schéma et ses métadonnées — jamais ses données. C’est délibéré : une base exportée ne peut pas être le chemin par lequel des données patient quittent un établissement.
La conséquence pratique : réimporter une base exportée donne une coquille vide, signalée par un bandeau. Il faut ensuite la repointer vers les fichiers, via Modifier.
Dans le même esprit, les bases sont attachées en lecture seule. Ni une requête d’exploration, ni un widget, ni un script d’analyse ne peuvent écrire dans une base source. Seule la cible d’un pipeline ETL est ouverte en écriture, et uniquement pendant son exécution.
Le sens de circulation, lui, reste ouvert : une base publique — MIMIC-IV demo, des données synthétiques — s’installe depuis le catalogue avec ses données. Rien ne sort, tout peut entrer.
Voir une base réelle
La démo contient deux bases d’exemple issues de MIMIC-IV, l’une brute et l’une convertie en OMOP. Ouvrez-en une pour parcourir ses statistiques et son explorateur de tables.
Entretenir une base
Quelques actions ne servent qu’occasionnellement, mais valent d’être connues.
- Retester la connexion — une base en erreur le reste jusqu’à ce qu’on la reteste. En mode serveur, les bases en erreur sont retentées automatiquement au chargement.
- Recréer depuis le schéma — remplace le contenu par des tables vides. Destructif et irréversible.
- Compacter — en mode serveur, sur une base gérée par Linkr : réécrit le fichier pour rendre l’espace laissé par des tables supprimées. Les données ne changent pas, mais l’opération demande de l’espace disque libre et il ne faut pas écrire pendant.
Pour aller plus loin
- Schémas — définir comment Linkr lit les tables d’une base.
- Pipelines ETL — transformer une base source en base cible.
- Qualité des données — contrôler ce que contient une base.
- Collections de scripts SQL — ranger et partager les requêtes.