Dimension table
La tabella user-facing del warehouse in cui ogni riga è un'entità (un utente, un prodotto): la forma pulita di una tabella di sostantivi.
Una dimension table è una tabella user-facing di un data warehouse in cui ogni riga corrisponde a un sostantivo: un’entità come un utente, un post, un commento, un prodotto. È la forma pulita e usabile di una tabella di entità, e per convenzione il suo nome inizia con dim_ (dim_users, dim_products). Il suo complemento è la fact table, in cui ogni riga corrisponde a un evento.1
Il test dim contro fact
Sahar Massachi, nella serie “Stop using Slowly-changing Dimensions!” su DataExpert.io, riduce la distinzione a una regola lapidaria: “Is there one row per noun in the table? Dim. One row per ‘a thing happened’? Fact. That’s it”. Poiché le dimension possono contenere informazioni derivate dagli eventi e le fact contengono contesto sulle entità, la distinzione non sta nel contenuto ma nella granularità: una riga per entità da un lato, una riga per evento dall’altro.1
Cosa contiene
Una dimension non si limita agli attributi anagrafici. dim_users può includere, oltre a id, data di creazione e ultimo accesso, anche dati aggregati dagli eventi: totale dei post scritti, commenti negli ultimi 7 giorni, giorni di attività nell’ultimo mese, visualizzazioni di ieri. Il principio di Massachi: se un analista vorrebbe costantemente quel dato, va aggiunto alla tabella, perché una piccola modifica alla pipeline risparmia ore di attesa a settimana. “Data processing done while everyone is asleep is much better than data querying done while people are on the clock and fighting a deadline”.1
Il limite pratico, riconosce Massachi, non è tecnico ma di cultura interna e tooling: contro la tabella “unusably wide” si può separare una dim_user_extras con le informazioni più marginali, da incrociare quando serve, o usare tipi di dato complessi per ridurre il numero di colonne.1
La dimension datestampata
La Parte 2 della serie mostra cosa significa applicare il date stamping a una dimension: invece di una riga per utente che si sovrascrive ogni giorno, o di più righe con valid_from e valid_to come nelle Slowly Changing Dimensions Type-2, si tiene una riga per utente per giorno, marcata con la colonna ds:2
| user_id | followers | ds |
|---|---|---|
| 123 | 150 | 2024-10-01 |
| 123 | 180 | 2024-10-02 |
| … | … | … |
| 123 | 1200 | 2025-01-16 |
Lo stato al primo ottobre è WHERE ds='2024-10-01'. Per incrociare più dimension storiche (utenti, dispositivi, relazioni) ognuna filtra sulla propria ds e il join avviene su ds: niente BETWEEN, niente logica di validità. La regola operativa che ne segue: per la maggior parte delle dimension datestampate ogni giorno si ricalcola da raw, indipendente dagli altri (in Airflow, depends_on_past=False); l’eccezione sono le dimension con metriche cumulative, dove la dipendenza dal giorno precedente è strutturale.2
L’aneddoto della tabella virale
Da junior a Facebook, Massachi costruì una dimension per tracciare gli upgrade dell’app per utente, dispositivo e giorno, pensata per il proprio team. Il suo manager gli fece notare che era utile a tutta l’azienda: bastava rinominarla e farla conoscere. Divenne un piccolo successo virale interno, e anni dopo Massachi riceveva ancora richieste su quella tabella da colleghi mai incontrati. L’aneddoto, sviluppato nella voce data engineer come product owner, illustra che la differenza tra una tabella ignorata e un asset aziendale può essere di comunicazione, non tecnica.3
Voci correlate
- Fact table — il complemento: una riga per evento
- Date stamping — il principio che sostituisce le SCD nelle dimension
- Slowly Changing Dimensions — la pratica storica di gestione del cambiamento
- Backfilling — banale con dimension datestampate
- Data warehouse — il sistema di cui le dimension sono output
- Analytics engineering — il processo che modella le tabelle per l’usabilità
- Portale: Data engineering
Bibliografia e sitografia
- Sahar Massachi, The data warehouse setup no one taught you (Stop using Slowly-changing Dimensions! Part 1), DataExpert.io, 24 ottobre 2025. blog.dataexpert.io
- Sahar Massachi, SCD-2 considered harmful! (Stop using Slowly-changing Dimensions! Part 2), DataExpert.io, 4 novembre 2025. blog.dataexpert.io
- Sahar Massachi, Junior data engineers build pipelines. Seniors build trust, DataExpert.io, 30 giugno 2026. blog.dataexpert.io
- Metabase, Analytics engineering for fact tables, Metabase Learn. metabase.com