Fonctionnalité en construction
Cette fonctionnalité n'est pas encore disponible. Voici ce qui est prévu, pour que vous puissiez juger si elle couvrira votre besoin — et nous dire si ce n'est pas le cas.
État — à l'étude
Disponibilité prévue — navigateur et serveur
En résumé
Découper, dans l’entrepôt principal, une base de travail restreinte : on sélectionne des patients exactement comme on construit une cohorte, puis Linkr projette toutes les tables d’événements sur ces patients. Le résultat est une base interrogeable comme une autre, qui garde la trace de son origine et de ses critères — donc reconstructible.
Le besoin
Un entrepôt hospitalier contient tous les patients. Une étude n’en concerne qu’une fraction : un service, une période, une pathologie.
Aujourd’hui, deux réponses imparfaites. On travaille sur l’entrepôt entier en filtrant dans chaque requête — chaque analyse doit alors se souvenir du filtre, et il suffit qu’une l’oublie pour produire un chiffre faux. Ou bien on demande une extraction à l’équipe données, et l’on attend.
Une sous-base dérivée vise l’entre-deux : le périmètre est défini une fois, matérialisé, et tout ce qui l’interroge travaille déjà dans le bon périmètre.
Ce n'est pas la même chose qu'une cohorte
Une cohorte est une liste de patients. Une sous-base est une base complète : les mêmes tables que la base parente, avec les mêmes noms de colonnes, mais restreintes à un sous-ensemble de patients. On requête une sous-base ; on utilise une cohorte comme filtre. La frontière exacte entre les deux fait partie de ce qui reste à trancher.
Ce qui est prévu
Sélectionner comme on construit une cohorte
La moitié du travail est déjà résolue ailleurs dans Linkr : le constructeur de critères des cohortes. Mêmes types de critères, même arborescence, mêmes niveaux — patient, hospitalisation, séjour en unité, événement.
L’intention est de réutiliser ce constructeur tel quel, pas d’en écrire un second. Qui sait construire une cohorte saura définir une sous-base sans rien réapprendre.
Puis projeter toutes les tables
Une fois l’ensemble de patients arrêté, Linkr parcourt chaque table d’événements de la base parente et n’en garde que les lignes de ces patients. Le schéma est identique : une requête écrite pour la base parente fonctionne sur la sous-base, sans modification.
Deux formes possibles
Une nouvelle base
Les tables filtrées sont écrites dans une base à part.
Elle apparaît dans la liste des bases avec ses propres statistiques et son schéma hérité du parent. Rien n’est écrit dans l’entrepôt : c’est la voie qui fonctionne partout, y compris quand l’entrepôt est en lecture seule.
Un schéma dans la base parente
Les tables filtrées vivent dans l’entrepôt lui-même.
Plus économe — pas de seconde copie — mais cela suppose un droit d’écriture sur l’entrepôt de production, que beaucoup de directions des systèmes d’information refuseront. Réservé au mode serveur, et à certains moteurs seulement.
Garder la trace de ce qu’on a découpé
Une sous-base enregistrera sa base parente, l’arbre de critères qui l’a produite et sa date de construction.
C’est ce qui permet de répondre, six mois plus tard, à la question qui se pose toujours : qu’y a-t-il exactement là-dedans ? Et comme les critères sont conservés, la sous-base peut être reconstruite quand l’entrepôt a été mis à jour.
La définition — les critères et le pointeur vers le parent, jamais les données — voyagerait avec l’export de l’espace de travail, comme le reste.
Ce qui n’est pas tranché
Cette page décrit une idée, pas une décision
Plusieurs choix structurants restent ouverts. Ils sont listés ici tels quels : si l’un d’eux compte pour votre usage, c’est le bon moment pour le dire.
- Le nom. « Datamart », « sous-base », « base d’étude », « extraction » ? Le terme finira dans l’interface et dans les URL, donc il se choisit avant d’écrire le code — et il n’est pas choisi. Cette page dit « sous-base dérivée » faute de mieux.
- La frontière avec les cohortes. Une cohorte matérialisée ressemble beaucoup à une sous-base. Faut-il deux fonctionnalités, ou une seule avec deux sorties ? Le risque de doublon est réel.
- La nature de l’objet. Une sous-base sera-t-elle une base comme les autres, avec simplement un lien vers son parent — ce qui lui donnerait gratuitement la liste, les statistiques, l’explorateur de schéma et la liaison aux projets ? C’est la piste privilégiée, mais elle n’est pas arrêtée.
- Les droits d’écriture dans l’entrepôt. La seconde forme suppose une permission dédiée, et probablement un interrupteur au niveau de l’instance pour que l’administrateur puisse l’interdire d’emblée.
En attendant
Trois approches couvrent déjà une bonne partie du besoin.
Une cohorte
Définit le périmètre une fois et sert de filtre aux analyses. Voir Cohortes.
Un pipeline ETL
Fait déjà exactement cela, en écrivant les requêtes de filtrage à la main : une base cible alimentée depuis une base source. Voir Pipelines ETL.
Un jeu de données
Pour une analyse plutôt qu’un périmètre durable : une table large, déjà filtrée. Voir Jeux de données.
Pour aller plus loin
- Bases de données — ce qu’une sous-base sera, une fois construite.
- Cohortes — le constructeur de critères que cette fonctionnalité réutilisera.
- Pipelines ETL — la façon actuelle de fabriquer une base dérivée.