En résumé
Un pipeline ETL remplit une base cible à partir d’une base source, avec des scripts SQL. Les scripts ne nomment jamais les bases directement : ils écrivent source. et target., que Linkr remplace à l’exécution. C’est ce qui permet de reprendre le pipeline de conversion OMOP d’un autre établissement et de le faire tourner sur vos propres bases. Les scripts s’écrivent à la main ou se génèrent depuis les schémas des deux bases et depuis un projet d’alignement.
Le seul endroit qui écrit
Partout ailleurs, Linkr lit. Les bases sont attachées en lecture seule, les widgets et les scripts d’analyse ne peuvent rien modifier.
Un pipeline ETL est l’exception, et elle est étroite : seule la base cible est ouverte en écriture, et seulement pendant l’exécution. La source et le vocabulaire restent en lecture seule dans la même connexion, si bien qu’un script peut lire l’une et écrire l’autre — INSERT INTO target.person SELECT … FROM source.patients — sans jamais pouvoir modifier ce qu’il lit.
À ne pas confondre avec le pipeline d'un projet
Un pipeline ETL vit dans l’entrepôt et va d’une base à une base : c’est là qu’on convertit un modèle source vers OMOP.
Le pipeline d’un projet part de l’entrepôt et produit des jeux de données pour l’analyse — du format long vers le format large. Le premier construit l’entrepôt, le second l’exploite.
Les trois rôles
Un pipeline connaît ses bases par leur rôle, jamais par leur nom.
source. — d’où viennent les données
Votre base métier : l’export du dossier patient, les tables d’un logiciel de réanimation. En lecture seule.
target. — où elles vont
Typiquement une base OMOP vide, créée depuis un schéma avec Nouveau depuis un schéma. La seule ouverte en écriture.
vocab. — la terminologie de référence
Le vocabulaire ATHENA d’un projet d’alignement, pour traduire vos codes locaux en concepts standard. Facultatif, en lecture seule.
INSERT INTO target.person (person_id, gender_concept_id, year_of_birth)
SELECT p.id, v.target_concept_id, EXTRACT(year FROM p.birth_date)
FROM source.patients p
LEFT JOIN vocab.concept_relationship v ON v.source_code = p.sex_codeN'écrivez jamais le nom réel d'une base dans un script ETL
C’est la règle la plus importante de cette page. Le nom technique d’une base contient un identifiant propre à votre instance : un script qui le code en dur cesse de fonctionner dès qu’il est exporté ailleurs, où cet identifiant n’existe pas.
Les rôles survivent au voyage. Celui qui importe votre pipeline resélectionne ses deux bases dans les menus déroulants, et tous les scripts fonctionnent — sans qu’une seule ligne de SQL soit modifiée.
La substitution est faite au moment d’exécuter, pas au moment d’enregistrer : ce qui part dans git reste portable. Elle est aussi prudente — un source. à l’intérieur d’une chaîne de caractères, d’un commentaire ou d’un identifiant plus long n’est pas touché.
Dans ce guide
Un pipeline se crée depuis la page Pipelines ETL de l’entrepôt, puis se règle onglet par onglet. La première page suit le parcours de bout en bout : les onglets, l’écriture des scripts, l’exécution et le contrôle qualité. La seconde détaille les deux générateurs qui écrivent l’essentiel d’une conversion vers OMOP :
Construire et exécuter un pipeline
Les onglets, l’écriture des scripts, l’exécution pas à pas — pause, arrêt, erreurs — et le contrôle qualité de ce qui a été chargé.
Générer les scripts
Les scripts de chargement OMOP déduits des mappings de schéma, et les scripts de vocabulaire tirés d’un projet d’alignement.
Partager un pipeline
Un pipeline s’exporte, se versionne et se publie comme les autres entités — et c’est là que les rôles prennent tout leur sens.
Ce qui voyage, ce sont les scripts, jamais les données. Un établissement qui a converti son modèle local vers OMOP peut publier ce travail ; un autre l’installe, rebranche ses deux bases, et lance. C’est probablement la forme la plus directement réutilisable de tout Linkr : une conversion OMOP représente des mois de travail, et elle se transmet en un export.
Les fichiers de données sont exclus du versioning par défaut
Un pipeline manipule parfois des fichiers auxiliaires — tables de correspondance, référentiels. Ils sont ignorés par git par défaut, et se réintègrent un par un, explicitement. La règle par défaut est que la donnée ne part pas ; l’inclure est une décision consciente, prise fichier par fichier.
Pour aller plus loin
- Construire et exécuter un pipeline — les onglets, les scripts, l’exécution et le contrôle qualité.
- Générer les scripts — les scripts de chargement OMOP et de vocabulaire, écrits par Linkr.
- Bases de données — créer la base cible vide depuis un schéma.
- Alignement de concepts — produire les correspondances que le vocabulaire consomme.
- Qualité des données — contrôler la base cible une fois remplie.
- Pipeline d’un projet — l’autre pipeline, celui qui produit des jeux de données.