En résumé
Une collection est un dossier de scripts SQL, rangés en arborescence et exécutés sur une base de l’entrepôt. L’éditeur exécute une sélection, un script ou toute la collection, et ouvre à la demande un explorateur du schéma de la base. Comme toute entité Linkr, une collection s’exporte, se versionne et se publie.
Pourquoi ranger ses requêtes
Les requêtes qui interrogent un entrepôt existent déjà, en quantité. Elles sont simplement dispersées : réparties entre plusieurs dépôts git, parfois pas versionnées du tout, et surtout rarement mises en commun. Chaque équipe réécrit ce qu’une autre a déjà écrit.
Une collection les rassemble là où se trouvent les données. Elles s’exécutent sur la base concernée, elles portent un nom, et elles suivent le même chemin de partage que le reste — export, dépôt git, catalogue.
Ce n'est pas un outil de transformation
Une collection interroge. Elle ne fabrique pas de base et n’écrit nulle part : toutes les bases sont attachées en lecture seule. Pour alimenter une base à partir d’une autre, c’est un pipeline ETL.
L’éditeur
La page d’une collection a deux onglets, Aperçu — le readme — et Scripts, plus le menu Plus. L’onglet Scripts est l’éditeur : l’arborescence des scripts à gauche, la barre d’outils, puis l’éditeur et, à sa droite, les résultats.
| # | Aagender_source_value | #n |
|---|---|---|
gender_source_value... | Min Max | |
| 1 | F | 57 |
| 2 | M | 43 |
Les scripts se rangent en dossiers, comme des fichiers. Les fichiers .md sont acceptés eux aussi : une collection peut donc mêler requêtes et notes expliquant à quoi elles servent — et un fichier markdown s’ouvre en rendu, dans un onglet Aperçu, plutôt qu’en texte.
Chaque exécution ouvre son onglet Résultat, nommé d’après le script — et d’après la sélection ou la ligne quand ce n’est qu’un morceau. Les onglets de résultat se ferment un à un, ou tous d’un clic droit.
Exécuter
Quatre gestes, du plus fin au plus large :
| Action | Raccourci | Ce qui part |
|---|---|---|
| Exécuter la sélection | Cmd/Ctrl + Entrée | Le texte sélectionné |
| Exécuter la ligne courante | Cmd/Ctrl + Entrée | La ligne du curseur, quand rien n’est sélectionné |
| Exécuter le script | Bouton Exécuter | Le fichier entier |
| Exécuter tous les scripts | Cmd/Ctrl + Maj + Entrée | Toute la collection |
Le même raccourci sert pour la sélection et pour la ligne : s’il y a une sélection, c’est elle qui part, sinon c’est la ligne du curseur. C’est la convention de RStudio, et elle rend la mise au point d’une requête longue beaucoup plus directe — on exécute un morceau de WITH sans découper le fichier.
Cmd/Ctrl + S enregistre. Un bouton dans la barre d’outils affiche la liste complète des raccourcis.
L’explorateur de schéma
Explorer le schéma, l’icône de tableau à côté du sélecteur de base, ouvre une fenêtre à trois volets titrée du nom de la base — le même explorateur que l’onglet Schéma d’une base de données. À gauche, les tables avec leur nombre de lignes et un filtre ; au centre, les colonnes de la table choisie, avec leur type et leur complétude ; à droite, les statistiques de la colonne choisie.
MIMIC-IV démo (OMOP)
| Colonne | Type | Complétude | Distinct |
|---|---|---|---|
#person_id | BIGINT | 100% | 100 |
#gender_concept_id | INTEGER | 100% | 2 |
#year_of_birth | INTEGER | 100% | 58 |
birth_datetime | TIMESTAMP | 100% | 100 |
#race_concept_id | INTEGER | 100% | 5 |
Aagender_source_value | VARCHAR | 100% | 2 |
#care_site_id | BIGINT | 12% | 3 |
#location_id | BIGINT | 0% | 0 |
INTEGER
La case Stats de la barre de l’explorateur règle le calcul des statistiques de colonne : décochée, l’explorateur ne fait que lister, ce qui va plus vite sur une grosse table. Copier SELECT évite de retaper les colonnes d’une table.
Un bouton voisin, dans la barre d’outils de l’éditeur, Copier la référence du schéma pour SQL, copie le préfixe qui désigne la base dans une requête.
Ce bouton n'apparaît qu'en mode navigateur
Et c’est normal. En mode navigateur, une base est attachée sous le nom ds_<identifiant>, utile pour une requête qui croise plusieurs bases. En mode serveur, ce préfixe n’existe pas : les scripts s’écrivent avec des noms de table nus. Le bouton est masqué plutôt que de proposer une référence qui ne fonctionnerait pas. Voir Bases de données.
Choisir la base
Une collection s’exécute sur une base à la fois, choisie dans la barre d’outils. La collection mémorise une base par défaut, modifiable à tout moment.
Cela veut dire qu’une même collection peut servir sur plusieurs bases du même modèle : des scripts de contrôle OMOP écrits une fois s’exécutent sur la base de production comme sur une copie de test, en changeant simplement la base active.
En mode serveur, un résultat est plafonné à 10 000 lignes
La requête s’exécute entièrement côté serveur, mais seules les 10 000 premières lignes redescendent vers le navigateur. C’est une protection : un SELECT * sur une table de plusieurs millions de lignes ne ramène pas tout l’entrepôt dans un onglet.
Pour un volume supérieur, agrégez côté SQL, ou passez par un jeu de données — qui, lui, est fait pour porter des tables entières.
Partager une collection
Une collection est une entité comme les autres : export ZIP, dépôt git, publication au catalogue, readme et licence. Son contenu est du texte, donc elle se versionne particulièrement bien — un git diff sur une requête se lit.
C’est le format naturel pour diffuser un jeu de requêtes : des contrôles OMOP, le calcul d’un score, les requêtes d’extraction d’une étude. Voir Entités et partage.
Pour aller plus loin
- Bases de données — ce que les scripts interrogent, et comment les désigner.
- Qualité des données — pour transformer une requête de contrôle en vérification rejouable.
- Pipelines ETL — quand il faut écrire, et pas seulement lire.
- IDE — pour une analyse en R ou en Python plutôt qu’en SQL.