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 — une copie qu’elle peut surcharger —, 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.
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, Apache Doris et SQLite. La tuile Serveur FHIR est visible mais désactivée, marquée « bientôt disponible ». Vient ensuite la configuration, en trois onglets : Général, Connexion et Métadonnées.
Ajouter une base de données
Choisir un type de connexion
Serveur FHIRbientôt disponible
Connexion à un endpoint FHIR R4
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, MySQL et Apache Doris supposent un serveur qui ouvre la connexion réseau à votre place, ils n’apparaissent donc qu’en mode serveur. Ce que ce serveur doit avoir installé pour les joindre est décrit dans Connecteurs de bases de données.
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. |
| Apache Doris | Les mêmes champs (port 9030 par défaut), plus le Port Arrow Flight SQL, qui accélère les gros résultats. |
C’est aussi ici qu’on choisit le schéma de la base — voir la section suivante. En mode serveur, une base PostgreSQL propose en plus Autoriser Linkr à écrire dans cette base : c’est ce qui permet d’y dériver une cohorte vers un nouveau schéma SQL, sans jamais toucher aux tables existantes. 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é, âges par sexe, 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 et de sa version. 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 Un schéma, plusieurs bases.
Le mapping d’une base
L’onglet Mapping d’une base montre sa copie du mapping, avec en tête le schéma et la version dont elle vient. C’est le même éditeur que sur la page du schéma — mêmes sous-onglets, mêmes blocs, même fenêtre SQL, voir Mapper un schéma — avec une différence : ce que vous y changez ne vaut que pour cette base.
Une relation modifiée ici devient une surcharge : elle remplace, pour cette base seule, la relation du schéma — ou en ajoute une. C’est la réponse au cas fréquent d’un établissement dont le modèle suit OMOP, sauf pour une table rangée à sa façon. La fenêtre SQL y contrôle et prévisualise directement sur la base.
linkr_event_mesuresSurchargéeDéfinie en SQL. Colonnes remplies :
omoplinkr_event_diagnosticscondition_occurrencepatient_id*person_idconcept_id*condition_concept_idstart_datetime*condition_start_datetimevisit_idvisit_occurrence_idend_datetimecondition_end_datetimeomop- Surchargée — le badge d’une relation propre à la base. Un triangle d’alerte s’y ajoute quand le schéma a modifié cette relation depuis : la surcharge mérite alors d’être vérifiée.
- Revenir au preset — abandonne la surcharge ; la base relit la relation du schéma.
- Remonter dans le preset — reporte la surcharge dans le schéma lui-même, qui en profite pour toutes ses bases ; celle-ci suit de nouveau le schéma. Il faut pouvoir modifier le schéma.
- Mettre à jour depuis le preset — n’apparaît que si le schéma a changé depuis la copie. Il remplace la copie par la version actuelle du schéma et conserve les surcharges ; la fenêtre de confirmation dit lesquelles le schéma a modifiées entre-temps.
Une surcharge remplace ou ajoute une relation : elle ne peut pas en retirer une du schéma.
Changer de schéma, c'est repartir de zéro
Choisir un autre schéma dans Modifier refait la copie et abandonne toutes les surcharges. Pour suivre les évolutions du même schéma, c’est Mettre à jour depuis le preset qu’il faut utiliser.
La page de détail
Cliquer une carte ouvre la base, sur sept onglets. Ouverte depuis un projet, la même page est en lecture seule : voir Les bases d’un projet.
Les statistiques n'ont pas encore été calculées
Les compteurs ci-dessous affichent « — » tant qu'elles ne sont pas chargées. Sur de grosses bases cela peut être lent : elles ne sont donc calculées qu'à la demande.
Readme
MIMIC-IV démo (OMOP)
Extrait de démonstration de MIMIC-IV converti en OMOP CDM 5.4 : 100 patients, leurs séjours en réanimation, leurs mesures et leurs prescriptions.
- Source : MIMIC-IV Clinical Database Demo 2.2 (PhysioNet)
- Dates décalées par patient, comme dans MIMIC
- Vocabulaires : SNOMED, LOINC, RxNorm, ICD-10
À propos
Connexion
/srv/linkr/data/databases/mimic_iv_demo.duckdb412,3 Mo
- Aperçu — les compteurs, le readme, et des cartes latérales : À propos (auteur, organisation, licence, version), Dérivée d’une cohorte quand la base a été découpée dans une autre, le schéma rattaché, et la connexion — statut, moteur, identifiant, chemin du fichier.
- Statistiques — répartition par sexe, âges et durées de séjour, distribution des âges par sexe, chronologie des admissions, et le nombre de lignes de chaque table.
- Schéma — un explorateur à trois volets : les tables avec leur nombre de lignes, les colonnes de la table choisie avec leur type et leur complétude, et les statistiques de la colonne choisie — valeurs distinctes, min/max, distribution, valeurs les plus fréquentes. Copier SELECT copie une requête listant toutes les colonnes. La base doit être connectée.
- Mapping — la copie du mapping du schéma, et ses surcharges : voir Le mapping d’une base.
- SQL — une console, voir Écrire du SQL sur une base.
- Cohortes — les cohortes propres à la base, construites sur elle et non dans un projet. C’est depuis l’une d’elles qu’on dérive une sous-base.
Le menu Plus regroupe Readme, Licence, Versioning et l’action Exporter. 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’onglet SQL d’une base est une console : on y écrit une requête, on l’exécute avec Exécuter, Ctrl/⌘ + Entrée (sélection ou ligne courante) ou Ctrl/⌘ + Maj + Entrée (tout l’éditeur), et le résultat s’affiche dessous avec le nombre de lignes, la durée, et la date et l’heure d’exécution. Rien n’y est enregistré : pour conserver des requêtes, utilisez une collection de scripts SQL.
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 des collections de scripts SQL a alors, dans sa barre d’outils, un bouton Copier la référence du schéma pour SQL.
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
- Les bases d’un projet — lier une base à un projet, et ce qu’on en voit depuis le projet.
- 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.