Skip to Content
L’échange d’apprentissage de HIC débute le 13 Juillet 2026. Voir le programme
CoursÉlément 8 sur 22 · 30 min

Introduction à la modélisation des données

Qu’est-ce que la modélisation des données

La modélisation des données est le processus qui consiste à organiser les données dans une structure facile à stocker, comprendre, interroger et analyser. Cela revient à transformer des données brutes ingérées en jeux de données structurés, fiables et prêts pour le métier, utilisables pour le reporting, l’analytique, les tableaux de bord, l’apprentissage automatique et les applications.

Dans un pipeline ELT, les données brutes arrivent d’abord — la modélisation est l’étape de transformation qui intervient après l’ingestion. L’extraction et le chargement déposent les données intactes ; la transformation les modèle en quelque chose d’utilisable. Cette étape de transformation est l’objet de ce cours.

Ce que vous apprendrez
  • Expliquer pourquoi les données brutes sont déposées intactes avant toute modélisation
  • Énumérer les cinq activités qui mènent des données brutes aux modèles prêts pour le métier
  • Profiler une table brute pour repérer les nulls, doublons et problèmes de type avant de la modéliser
  • Construire un modèle de staging qui type, renomme et déduplique les lignes
  • Combiner des modèles de staging en un modèle intermédiaire conformé avec une logique métier partagée
  • Construire des marts de faits et de dimensions prêts pour la consommation BI

Pourquoi charger le brut d’abord et transformer ensuite

ObjectifPourquoi c’est important
Préserve la fidélité du brutConserve une copie intacte des données sources pour l’audit et le rejeu.
Découple ingestion et modélisationLes équipes d’ingestion et de modélisation peuvent travailler indépendamment.
Exploite la puissance de calcul de l’entrepôtPousse les transformations dans le moteur scalable de l’entrepôt.
Permet la reproductibilitéN’importe quel modèle peut être reconstruit depuis le brut à tout moment.
Sert plusieurs consommateursUn même jeu de données brut peut alimenter de nombreux modèles en aval.
Itération plus rapide et plus soupleLa logique de transformation peut changer sans ré-extraire les données.

Les cinq activités de la modélisation des données

La modélisation vous mène des données brutes déposées à des modèles testés et prêts pour le métier en cinq étapes. L’exemple détaillé ci-dessous suit une seule table — raw.vaccine_shipments, 50 000 lignes déposées depuis le système source — à travers les cinq, avec dbt.

Valider et profiler

Passez les données brutes au crible pour repérer les problèmes de schéma, les valeurs nulles et les doublons avant de construire quoi que ce soit dessus. Le profilage de raw.vaccine_shipments révèle 120 lignes avec un facility_id nul, environ 300 valeurs de shipment_id en double, et un champ de quantité stocké en texte — '500 doses' au lieu de 500.

select count(*) filter (where facility_id is null) as null_facility_ids, count(*) - count(distinct shipment_id) as duplicate_shipment_ids, count(*) filter (where quantity !~ '^[0-9]+$') as non_numeric_quantities from raw.vaccine_shipments;

Nettoyer et standardiser en staging

Typez, renommez et dédupliquez vers un modèle de staging — une ligne propre et typée par expédition. stg_vaccine__shipments convertit quantity en entier (en retirant le suffixe ' doses'), renomme facility_id en health_facility_id, et déduplique sur shipment_id en conservant le received_at le plus récent.

-- models/staging/stg_vaccine__shipments.sql with ranked as ( select shipment_id, facility_id as health_facility_id, cast(replace(quantity, ' doses', '') as integer) as quantity_doses, received_at, row_number() over ( partition by shipment_id order by received_at desc ) as row_num from {{ source('raw', 'vaccine_shipments') }} ) select shipment_id, health_facility_id, quantity_doses, received_at from ranked where row_num = 1

Conformer et intégrer

Joignez les sources et appliquez la logique métier partagée une seule fois, à un seul endroit. int_vaccine_stock_ledger combine les expéditions (sorties et réceptions), les doses administrées et les métadonnées d’établissements, et applique partout une seule règle de stock — au lieu que chaque rapport recalcule le solde différemment.

-- models/intermediate/int_vaccine_stock_ledger.sql with shipments as ( select * from {{ ref('stg_vaccine__shipments') }} ), doses as ( select * from {{ ref('stg_immunization__doses') }} ), facilities as ( select * from {{ ref('stg_facility__master') }} ), stock as ( select * from {{ ref('stg_facility__stock_counts') }} ) select s.health_facility_id, f.district, s.received_at::date as ledger_date, s.quantity_doses as received, d.doses_administered, d.doses_wasted, -- one shared rule, applied once k.opening_balance + s.quantity_doses - d.doses_administered - d.doses_wasted as closing_balance from shipments s join doses d on d.health_facility_id = s.health_facility_id and d.dose_date = s.received_at::date join stock k on k.health_facility_id = s.health_facility_id and k.count_date = s.received_at::date join facilities f on f.health_facility_id = s.health_facility_id

Construire les marts

Créez les modèles dimensionnels que les consommateurs interrogent réellement : fct_vaccine_stock_movements (une ligne par transaction, prête pour la BI) et dim_health_facility (district, province, type d’établissement). Un analyste peut désormais répondre directement à « nombre moyen de jours de rupture de stock par province au dernier trimestre », sans jointures ni logique métier à réinventer.

-- models/marts/fct_vaccine_stock_movements.sql with ledger as ( select * from {{ ref('int_vaccine_stock_ledger') }} ), -- unpivot the daily ledger into one row per stock transaction movements as ( select health_facility_id, ledger_date, 'receipt' as transaction_type, received as quantity_doses from ledger union all select health_facility_id, ledger_date, 'administered', doses_administered from ledger union all select health_facility_id, ledger_date, 'adjustment', doses_wasted from ledger ) select movements.health_facility_id, facility.province, facility.district, facility.facility_type, movements.ledger_date, movements.transaction_type, movements.quantity_doses from movements join {{ ref('dim_health_facility') }} as facility on facility.health_facility_id = movements.health_facility_id

Tester, documenter et planifier

Ajoutez les tests de données et les descriptions de champs dans schema.yml, puis planifiez le pipeline pour que les modèles restent frais — par exemple dbt run --select vaccine_stock+ chaque nuit, afin que les tableaux de bord soient à jour chaque matin.

# models/marts/schema.yml models: - name: fct_vaccine_stock_movements columns: - name: health_facility_id description: Facility receiving or issuing the stock movement. tests: - not_null - relationships: to: ref('dim_health_facility') field: health_facility_id - name: transaction_type description: Kind of stock movement recorded. tests: - accepted_values: values: [issue, receipt, administered, adjustment] - name: dim_health_facility columns: - name: health_facility_id description: Unique identifier for the health facility. tests: - not_null - unique

La démonstration en direct de ce cours se tient pendant l’Échange sous la forme de l’Atelier 3 : Mise en place de l’infrastructure Medallion — Bronze, Silver, Gold. Le matériel de l’atelier est publié dans ce sous-module : commencez par la formation dbt, puis suivez le Lab 3 : Modélisation dbt Medallion — cas DHIS2.