[Power BI] Data modeling in Power BI - Pt. 1

Bloccato
Avatar utente

Enrico Galli
Messaggi: 890 | Topic creati
Iscritto il: dom 28 giu 2020, 19:03
Luogo: San Giovanni in Persiceto (BO)
Ringraziato: 325 volte
Contatta:

[Power BI] Data modeling in Power BI - Pt. 1

Messaggio da Enrico Galli »

Ciao a tutti :)
Con questa serie di tutorial vi voglio introdurre un pilastro fondamentale che sta alla base della BI, qualunque sia il software che intendiamo utilizzare. Esempi e riferimenti saranno orientati a Power BI per praticità e perché è il software più utilizzato al momento, ma i concetti possono essere estesi anche ad altre piattaforme. Parliamo quindi di data modeling
_______________________________________________

Cos'è il data modeling?
Volendo dare una definizione molto semplice, possiamo dire che il data modeling (in italiano modellazione, o forse "modellizzazione" :? dati) è la rappresentazione di una base dati in una o più tabelle (in genere è questo il caso), che possono avere delle relazioni impostate tra di loro.

Chi ha già avuto esperienze con database relazionali di qualsiasi tipo (da Access in "su"), sa benissimo di cosa stiamo parlando. Per la Business Intelligence, però, spesso si fanno scelte di modellazione (ho deciso di usare questa versione più italiana...) leggermente diverse da quelle che farebbero gli esperti di SQL, in quanto gli obiettivi di un modello BI sono principalmente:
1) prestazioni del modello
2) semplicità di navigazione del modello
mentre un database transazionale ha come prima esigenza quella dell'integrità dei dati.

Ma andiamo per gradi.
_______________________________________________

Tabelle
Le tabelle sono le entità principali di un modello di dati. Ogni tabella è formata da una o più righe, e da una o più colonne. Ogni "cella" (incrocio tra una riga e una colonna) contiene informazioni sugli oggetti del modello, ed è la più piccola unità di informazioni disponibile nel modello stesso. Ciascuna colonna ha un proprio tipo di dati (testo, numerico, data, etc.), e non possono coesistere celle con tipi di dati diversi al suo interno.

Tipi di tabella
In un modello dati generalmente si possono trovare tre tipi di tabelle:

1) Le tabelle dei fatti (fact tables)
Queste sono le tabelle che contengono i numeri che vogliamo aggregare: vendite, resi, presenze, etc. Normalmente tracciano eventi collocabili nel tempo e misurabili. Sono tipicamente le tabelle più grandi di un modello, arrivando a contenere anche decine o centinaia di milioni di record.
Oltre alle quantità da aggregare, hanno sempre dei campi che servono da chiave esterna verso le tabelle dimensionali

2) Le tabelle dimensionali (dimension tables)
Chiamate per praticità anche "dimensioni", queste tabelle sono elenchi univoci di un determinato attributo del modello. Ad esempio una tabella 'Clienti', con una riga per ciascun cliente, è una tabella dimensionale. Così come una tabella 'Negozi', 'Fornitori', 'Categoria Prodotti', etc.
La caratteristica principale, già anticipata, che deve avere una tabella dimensionale è l'univocità: ogni riga deve descrivere un oggetto diverso, senza duplicazioni.
Queste tabelle sono più piccole delle tabelle dei fatti: in genere contengono dalle decine alle migliaia di record. Ciascuna riga di questa tabella avrà un codice univoco (chiave primaria) che la metterà in relazione con una o più tabelle dei fatti.

3) Le bridge table
In modelli più complessi, può presentarsi l'esigenza di creare delle relazioni molti-a-molti (vedremo in seguito cosa sono). Il software utilizzato potrebbe fornire degli strumenti per gestire anche questo tipo di relazioni, ma una soluzione universalmente valida è quella di creare delle bridge table (bridge = ponte) che si frappongono tra le due tabelle in questione, e verso le quali hanno una relazione uno-a-molti.
_______________________________________________

Relazioni
Tra le tabelle di un modello di dati, affinché questo possa essere efficacemente analizzato, devono esistere delle relazioni. La "regina" di tutte le relazioni, quella che vedremo utilizzata nel 99% dei casi, è la relazione uno-a-molti. In questa relazione, un campo di una tabella dimensionale (la parte "uno") con valori univoci, quindi senza duplicati (chiave primaria, o primary key) viene messa in relazione con un campo di una tabella dei fatti (la parte "molti"), che invece avrà duplicazioni (chiave esterna o foreign key). Quindi un cliente (codice univoco) potrà aver fatto più ordini, un negozio può aver avuto più resi, un fornitore può avere emesso più fatture, e così via. Ma ogni ordine deve appartenere a un solo cliente, ogni reso fa capo a un solo negozio, ogni fattura a un solo fornitore.
L'unica altra tipologia di relazione di cui parleremo più avanti è quella molti-a-molti (v. bridge table). Le altre tipologie esistenti (uno-a-uno e molti-a-uno) non hanno sostanzialmente alcuna valenza in questa trattazione.
_______________________________________________

Conclusioni
La scelta degli attributi da includere in ogni tabella e il modo in cui le tabelle vengono messe in relazione tra loro è l'essenza del data modeling, e influenzerà in modo decisivo le capacità di analisi dei dati a nostra disposizione. Nel prossimo tutorial parleremo dei due tipi di modello usati principalmente nella BI: lo "star schema" (schema a stella) e il suo parente prossimo "snowflake schema" (schema a fiocco di neve). A presto! :wave:



Enrico Galli
Link utili: I nostri tutorial | Come inserire: Immagini - Codice - Risolto
Se il forum ti è stato utile, considera di supportarlo con una libera donazione
Bloccato