Par Boris Delange | 15.10.2024
Dans cet article, nous allons :
Une base de données (BDD) est comme un grand tableur Excel, où chaque feuille représente une table.
Tout l’enjeu d’une base de données est :
Comment feriez-vous pour stocker dans un tableur Excel les données de biologie et les données démographiques de 5 patients ?
Mettons que l’on ait besoin de stocker le taux d’hémoglobine, les plaquettes et les leucocytes.
Le premier réflexe qui vient à l’esprit est de créer une colonne par paramètre de biologie.
Nous ajoutons une colonne date_biologie pour connaître la date de réalisation du prélèvement biologique.
| patient_id | age | sexe | date_admission | date_sortie | date_biologie | hémoglobine | plaquettes | leucocytes |
|---|---|---|---|---|---|---|---|---|
| 1 | 45 | M | 2024-10-01 | 2024-10-10 | 2024-10-03 | 13.5 | / | / |
| 1 | 45 | M | 2024-10-01 | 2024-10-10 | 2024-10-04 | / | 150,000 | 7,200 |
| 2 | 60 | F | 2024-09-25 | 2024-10-05 | 2024-09-26 | 12.8 | 180,000 | 8,000 |
| 3 | 38 | F | 2024-10-05 | 2024-10-12 | 2024-10-07 | 14.0 | 220,000 | / |
| 3 | 38 | F | 2024-10-05 | 2024-10-12 | 2024-10-08 | / | / | 6,500 |
| 4 | 52 | M | 2024-09-20 | 2024-09-30 | 2024-09-21 | 11.5 | 140,000 | 9,500 |
| 5 | 29 | F | 2024-10-08 | 2024-10-15 | 2024-10-09 | 13.2 | 170,000 | 7,800 |
| 5 | 29 | F | 2024-10-16 | 2024-10-20 | 2024-10-16 | 14.2 | / | / |
Comment lire ce tableau ?
Le patient 1 a un seul séjour (une seule date_admission) et deux dosages biologiques à deux dates différentes durant ce même séjour (deux valeurs pour date_biologie).
Le patient 5 a deux séjours (deux valeurs pour date_admission), avec une biologie prélevée par séjour (deux valeurs différentes de date_biologie).
Nous pouvons remarquer deux choses :
Si l’on revient à nos trois principes de conception (éviter les redondances, moins de cases vides et flexibilité), il semblerait que l’on puisse faire mieux.
Pourquoi ne pas créer une table (ou une feuille Excel pour continuer avec l’analogie) pour les patients ?
| patient_id | age | sexe |
|---|---|---|
| 1 | 45 | M |
| 2 | 60 | F |
| 3 | 38 | F |
| 4 | 52 | M |
| 5 | 29 | F |
On gagne ainsi de la place avec 3 lignes en moins.
Pourquoi ne pas avoir intégré les séjours dans cette table ?
Si on avait intégré les séjours dans cette table (avec les colonnes date_admission et date_sortie), nous aurions certes eu une seule ligne pour les patients 1 à 4, mais deux lignes pour le patient 5, qui a deux séjours différents.
Toujours dans une logique de diminuer le nombre de lignes, on préférera créer une table pour les séjours.
| patient_id | admission_id | date_admission | date_sortie |
|---|---|---|---|
| 1 | 1 | 2024-10-01 | 2024-10-10 |
| 2 | 2 | 2024-09-25 | 2024-10-05 |
| 3 | 3 | 2024-10-05 | 2024-10-12 |
| 4 | 4 | 2024-09-20 | 2024-09-30 |
| 5 | 5 | 2024-10-08 | 2024-10-15 |
| 5 | 6 | 2024-10-16 | 2024-10-20 |
Pour finir, nous allons créer une table pour stocker les données de biologie.
| patient_id | admission_id | date_biologie | hémoglobine | plaquettes | leucocytes |
|---|---|---|---|---|---|
| 1 | 1 | 2024-10-03 | 13.5 | / | / |
| 1 | 1 | 2024-10-04 | / | 150,000 | 7,200 |
| 2 | 2 | 2024-09-26 | 12.8 | 180,000 | 8,000 |
| 3 | 3 | 2024-10-07 | 14.0 | 220,000 | / |
| 3 | 3 | 2024-10-07 | / | / | 6,500 |
| 4 | 4 | 2024-09-21 | 11.5 | 140,000 | 9,500 |
| 5 | 5 | 2024-10-09 | 13.2 | 170,000 | 7,800 |
| 5 | 6 | 2024-10-16 | 14.2 | / | / |
OK, mais ici nous avons encore des cases vides, nous pourrions optimiser.
La solution est de créer une colonne pour le nom du paramètre biologique, et une colonne pour sa valeur. Ainsi, plus de case vide !
| patient_id | admission_id | date_biologie | paramètre | valeur |
|---|---|---|---|---|
| 1 | 1 | 2024-10-03 | hémoglobine | 13.5 |
| 1 | 1 | 2024-10-04 | plaquettes | 150,000 |
| 1 | 1 | 2024-10-04 | leucocytes | 7,200 |
| 2 | 2 | 2024-09-26 | hémoglobine | 12.8 |
| 2 | 2 | 2024-09-26 | plaquettes | 180,000 |
| 2 | 2 | 2024-09-26 | leucocytes | 8,000 |
| 3 | 3 | 2024-10-07 | hémoglobine | 14.0 |
| 3 | 3 | 2024-10-07 | plaquettes | 220,000 |
| 3 | 3 | 2024-10-07 | leucocytes | 6,500 |
| 4 | 4 | 2024-09-21 | hémoglobine | 11.5 |
| 4 | 4 | 2024-09-21 | plaquettes | 140,000 |
| 4 | 4 | 2024-09-21 | leucocytes | 9,500 |
| 5 | 5 | 2024-10-09 | hémoglobine | 13.2 |
| 5 | 5 | 2024-10-09 | plaquettes | 170,000 |
| 5 | 5 | 2024-10-09 | leucocytes | 7,800 |
| 5 | 6 | 2024-10-16 | hémoglobine | 14.2 |
Nous venons de créer une base de données !
Alors certes, cela peut paraître moins lisible au premier abord, mais quand on a des millions de données, il est nécessaire d’optimiser leur stockage.
Et vous le verrez si vous faites un peu de programmation, cette manière d’organiser les données est finalement bien plus lisible qu’un fichier Excel à 50, 100 colonnes…
Les données sont maintenant éparpillées sur plusieurs tables.
Comment les fusionner de nouveau ?
Si l’on veut fusionner plusieurs tables, on fera ce que l’on appelle une jointure.
Par exemple, si on fait une jointure entre les tables patients et séjours, en faisant une correspondance sur la colonne patient_id, nous obtiendrons cette table :
| patient_id | age | sexe | admission_id | date_admission | date_sortie |
|---|---|---|---|---|---|
| 1 | 45 | M | 1 | 2024-10-01 | 2024-10-10 |
| 2 | 60 | F | 2 | 2024-09-25 | 2024-10-05 |
| 3 | 38 | F | 3 | 2024-10-05 | 2024-10-12 |
| 4 | 52 | M | 4 | 2024-09-20 | 2024-09-30 |
| 5 | 29 | F | 5 | 2024-10-08 | 2024-10-15 |
| 5 | 29 | F | 6 | 2024-10-16 | 2024-10-20 |
On pourra joindre les données de la table biologie de la même façon, et obtenir le tableau du début de l’article.
Il existe un langage de programmation qui permet spécifiquement de requêter les bases de données.
Ce langage se nomme SQL, pour Structured Query Language.
C’est un langage assez simple et facile d’accès.
Il se compose de quelques mots clefs qui permettent d’obtenir les données que l’on veut, dont (non exhaustif) :
Par exemple :
SELECT patient_id, age, sexe
FROM patients
WHERE age > 45
On sélectionne les colonnes patient_id, age, sexe de la table patients où la valeur de la colonne age est supérieur à la valeur 45.
On a le résultat suivant :
| patient_id | age | sexe |
|---|---|---|
| 2 | 60 | F |
| 4 | 52 | M |
Ce que l’on appelle un schéma de base de données est la structure des tables qui composent une base de données.
Il spécifie :
Par exemple, OMOP est un schéma de BDD spécialisée dans les données de santé.
Le schéma de données du modèle OMOP
Cette base est assez complexe, ce qui est nécessaire pour englober toutes les données de santé.
De même que nous l’avons fait plus haut, vous pouvez retrouver la table person qui correspond aux patients et la table visit_detail qui correspond aux séjours.
Les points à retenir :
Pour aller plus loin :