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.
- 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
| Objectif | Pourquoi c’est important |
|---|---|
| Préserve la fidélité du brut | Conserve une copie intacte des données sources pour l’audit et le rejeu. |
| Découple ingestion et modélisation | Les équipes d’ingestion et de modélisation peuvent travailler indépendamment. |
| Exploite la puissance de calcul de l’entrepôt | Pousse 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 consommateurs | Un même jeu de données brut peut alimenter de nombreux modèles en aval. |
| Itération plus rapide et plus souple | La 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 = 1Conformer 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_idConstruire 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_idTester, 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
- uniqueLa 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.