Ressources
5/7
11 min

Comment sont organisées ces données

Format long, schéma en étoile, jointures — comprendre l'organisation des données d'un entrepôt pour mener un projet de recherche.

En résumé

Les données d’un entrepôt de données de santé (EDS) ne sont pas stockées comme dans un tableur Excel. Elles sont réparties dans plusieurs tables reliées entre elles, au format long : une ligne par mesure, et non une ligne par patient. Mener un projet de recherche, c’est transformer ces données pour obtenir un tableau au format large — le même format qu’un recueil manuel sur tableur.

D’Excel à la base de données

Quand un clinicien pense à des données, il pense souvent à un tableur Excel : une ligne par patient, une colonne par variable. C’est ce qu’on appelle le format large.

Prenons 5 patients de réanimation avec quelques données démographiques et biologiques :

Le tableur du clinicien

patient_iddate_naissancesexecréatinine (µmol/L)hémoglobine (g/dL)leucocytes (G/L)
11952-06-14F1429.214.2
21979-03-22M88/7.8
31961-11-08M2108.5/
41943-01-30F95/11.3
51968-09-05F7312.46.9

Ce tableau est lisible et familier. Mais il pose trois problèmes quand les données deviennent volumineuses :

1

Des cases vides

Si un patient n'a pas eu de dosage de leucocytes, la case reste vide. Avec des centaines de paramètres biologiques, le tableau se remplit de cases vides.

2

De la redondance

Si un patient a deux séjours, ses données démographiques (date de naissance, sexe) sont répétées sur chaque ligne. C'est du gaspillage d'espace.

3

De la rigidité

Si l'on veut ajouter un nouveau paramètre biologique (par exemple la CRP), il faut ajouter une colonne. Avec des milliers de paramètres possibles, ce n'est pas viable.

La solution ? Séparer les données en plusieurs tables, chacune stockant un type d’information. C’est exactement le principe d’une base de données.

L'analogie Excel

Imaginez qu’une feuille Excel est une table et que le classeur entier est une base de données. Un entrepôt de données de santé fonctionne de la même façon — mais avec des dizaines de tables interconnectées au lieu d’une seule feuille.

Format long vs format large

La distinction entre format long et format large est essentielle pour comprendre comment les données sont organisées dans un EDS.

Le format large : le tableur du clinicien

C’est le format que vous connaissez : une ligne par patient, une colonne par variable. C’est le format d’un recueil de données sur Excel, comme le tableau ci-dessus.

Le format long : le stockage de l’entrepôt

Dans un EDS, les données ne sont pas stockées ainsi. Elles sont au format long : une ligne par mesure, avec des colonnes qui indiquent quel paramètre a été mesuré, sa valeur, son unité et sa date.

Voici les mêmes données biologiques dans les deux formats :

Format large (tableur)

idcréat.hbleuco.
11429.214.2
288/7.8
32108.5/
495/11.3
57312.46.9

5 lignes · des cases vides

Format long (entrepôt)

idparamètrevaleurunité
1Créatinine142µmol/L
1Hémoglobine9.2g/dL
1Leucocytes14.2G/L
2Créatinine88µmol/L
2Leucocytes7.8G/L

12 lignes · aucune case vide

À gauche, le format large : 5 lignes, une par patient. Facile à lire, mais rigide — pour ajouter un paramètre (par exemple la CRP), il faudrait ajouter une colonne.

À droite, le format long : 12 lignes, une par mesure. Plus de lignes, mais aucune case vide, et on peut ajouter autant de paramètres qu’on veut sans modifier la structure du tableau.

Pourquoi le format long ?

Le format long résout les trois problèmes évoqués plus haut :

  • Pas de cases vides : si un patient n’a pas de dosage de leucocytes, la ligne n’existe tout simplement pas
  • Paramètres illimités : ajouter un nouveau paramètre (CRP, troponine…) ne nécessite pas de nouvelle colonne, juste de nouvelles lignes
  • Données temporelles : chaque ligne peut avoir sa propre date, ce qui permet de stocker plusieurs mesures du même paramètre au cours du temps

Le schéma en étoile

Dans un EDS, les données ne sont pas dans une seule grande table. Elles sont réparties dans des tables spécialisées, chacune stockant un type d’information : une table pour les patients, une pour les séjours, une pour la biologie, une pour les prescriptions, etc.

Ces tables sont reliées entre elles par des identifiants partagés : le patient_id identifie un patient unique, et le visit_id identifie un séjour particulier.

On parle de schéma en étoile : la table des patients est au centre, et les autres tables gravitent autour.

Patients
PKpatient_id
date_naissance
sexe
Séjours
PKvisit_id
FKpatient_id
admission
sortie
service
Biologie
FKpatient_id
FKvisit_id
paramètre
valeur
unité
datetime
Prescriptions
FKpatient_id
FKvisit_id
médicament
posologie
datetime
Diagnostics
FKpatient_id
FKvisit_id
code_cim10
libellé
Param. vitaux
FKpatient_id
FKvisit_id
paramètre
valeur
datetime

PK = clé primaire (identifiant unique) · FK = clé étrangère (lien vers une autre table)

Chaque table satellite est au format long : elle ne contient que les informations de son domaine, avec une ligne par mesure ou par événement. C’est grâce aux identifiants partagés (patient_id, visit_id) que l’on peut relier les tables entre elles.

Voici à quoi ressemblent concrètement trois de ces tables pour nos 5 patients. Cliquez sur les onglets pour naviguer :

patient_iddate_naissancesexe
11952-06-14F
21979-03-22M
31961-11-08M
41943-01-30F
51968-09-05F

Remarquez que le patient_id apparaît dans les trois tables : c’est lui qui permet de relier les informations d’un même patient. Le visit_id relie chaque mesure au séjour correspondant.

patient_id et visit_id

Ces identifiants sont le fil conducteur qui relie toutes les tables de l’entrepôt. patient_id identifie un patient unique. visit_id identifie un séjour particulier. Quand on fusionne des tables, c’est toujours sur ces identifiants partagés que l’on s’appuie.

Les jointures : fusionner les tables

Les données sont maintenant réparties dans plusieurs tables. Comment les rassembler pour obtenir un tableau exploitable ?

C’est ce que l’on appelle une jointure : fusionner deux tables en faisant correspondre les lignes qui partagent le même identifiant.

Prenons un exemple concret. On veut obtenir, pour chaque patient, sa date de naissance (dans la table Patients) et ses résultats biologiques (dans la table Biologie). On fusionne les deux tables sur patient_id :

Patients

patient_iddate_naissance
11952-06-14
21979-03-22
31961-11-08
patient_id

Biologie

patient_iddatetimeparamètrevaleur
12024-03-10 08:15Créatinine142
12024-03-10 08:15Hémoglobine9.2
22024-03-12 06:30Créatinine88

Résultat

patient_iddate_naissancedatetimeparamètrevaleur
11952-06-142024-03-10 08:15Créatinine142
11952-06-142024-03-10 08:15Hémoglobine9.2
21979-03-222024-03-12 06:30Créatinine88

La jointure a combiné les informations des deux tables en une seule, en faisant correspondre les lignes grâce à patient_id. En pratique, ces opérations s’écrivent dans un langage appelé SQL (Structured Query Language).

Du format long au format large : le pipeline de recherche

Nous avons vu que l’EDS stocke ses données au format long, réparties dans des tables reliées. Mais pour analyser ces données, le clinicien a besoin d’un tableau au format large : une ligne par patient, une colonne par variable.

Ce passage du format long au format large est le cœur d’un projet de recherche sur EDS. Et c’est précisément là qu’interviennent les quatre dimensions définies dans l’article 2 : le concept, l’ancrage temporel, la fenêtre temporelle et la fonction d’agrégat.

Un exemple concret

À partir de la table de biologie au format long, on peut construire la variable « créatinine maximale dans les 24 premières heures » en appliquant les 4 dimensions :

  • Concept : créatinine (µmol/L)
  • Ancrage : admission en réanimation
  • Fenêtre : H0 à H24
  • Agrégat : maximum

Le résultat est une seule valeur par patient — une colonne dans le tableau d’analyse.

En répétant cette opération pour chaque variable (hémoglobine à l’admission, leucocytes max à H24, date de naissance, sexe…), on construit progressivement le tableau d’analyse au format large.

Et voici la clé : ce tableau d’analyse est exactement le même format que celui qu’on obtient par recueil manuel sur tableur. Les deux chemins — recueil manuel et extraction depuis l’EDS — convergent vers le même résultat.

Recueil manuel

à partir du dossier patient

4 dimensions

Entrepôt (format long)

tables reliées, 1 ligne / mesure

4 dimensions

Tableau d’analyse (format large)

1 ligne par patient · 1 colonne par variable

= même format

Voici le tableau d’analyse qu’on obtient — qu’il vienne d’un recueil manuel ou de l’EDS :

patient_iddate_naissancesexecréat_max_H24hb_admissionleuco_max_H24
11952-06-14F1429.214.2
21979-03-22M8813.17.8
31961-11-08M2108.518.9
41943-01-30F9510.811.3
51968-09-05F7312.46.9

Les noms de colonnes reflètent les 4 dimensions : concept + agrégat + fenêtre (ex. créat_max_H24 = créatinine maximale, H0-H24).

C'est ce que fait le Lab de Linkr

Le module Lab de Linkr travaille sur des jeux de données au format large : une ligne par patient, une colonne par variable. La transformation du format long au format large est gérée en amont par les scripts du data scientist. Le clinicien travaille directement sur le tableau d’analyse, dans le même format qu’un tableur.

Ce qu’il faut retenir

  • Les données d'un entrepôt sont organisées en tables reliées entre elles, connectées par des identifiants partagés (patient_id, visit_id).
  • L'entrepôt stocke les données au format long (une ligne par mesure), alors que le clinicien travaille au format large (une ligne par patient).
  • Un projet de recherche consiste à transformer le format long en format large, en appliquant les quatre dimensions (concept, ancrage, fenêtre, agrégat).
  • Le résultat est identique à un recueil manuel sur tableur — les deux approches convergent vers le même format d'analyse.