Dimensione è un termine usato in data management e in data warehousing per indicare raggruppamenti logici nei dati come la collocazione geografica, informazioni sui clienti o sui prodotti. Le Slowly Changing Dimensions sono dimensioni i cui attributi hanno valori che possono variare lentamente nel tempo.
Poniamo il caso di una dimensione, nel vostro database che memorizzi i record delle vendite dei vostri commessi. Creare reports sulle vendite è semplice finché un commesso non viene trasferito da un negozio all'altro. Come viene registrato questo cambiamento nella vostra dimensione? La comparazione fra le performance dei diversi commessi può dare risultati falsati, ad esempio perché il commesso potrebbe passare da un negozio che fa molte vendite ad uno dove queste sono scarse. Nella comparazione con i suoi nuovi colleghi il commesso risulterebbe, incorrettamente, il migliore.
Per risolvere problemi di questo tipo si utilizzano metodi per la gestione delle Slowly Changing Dimensions cui si fa riferimento come Tipo 0, 1, 2, 3, 4 e 6. Le SCD di tipo 6 sono anche dette ibride.
Tipo 0
[modifica | modifica wikitesto]Il tipo 0 è un metodo d'approccio passivo per la gestione dei cambiamenti nei valori delle dimensioni in cui non si prende nessun provvedimento. I valori rimangono quelli che erano al momento del primo inserimento del record della dimensione. Anche se in alcune circostanze può capitare di utilizzare il tipo 0 per la storicizzazione, i tipi SCD di ordine superiore sono impiegati più spesso dal momento che il tipo 0 fornisce un controllo minimo o nullo sulla gestione delle slowly changing dimensions.
I tipi più comuni di slowly changing dimensions sono il tipo 1, 2 e 3.
Tipo 1
[modifica | modifica wikitesto]Il metodo di Tipo 1 sovrascrive i vecchi dati con i nuovi, e quindi non tiene assolutamente traccia dei dati storici. Si tratta del metodo più appropriato per correggere alcune tipologie di errore sui dati (ad esempio errori ortografici, caso in cui non c'è nessuna necessità di tenere traccia di come il dato fosse errato in precedenza).
Segue un esempio di una tabella di database che contiene informazioni sui fornitori:
| ID_FORNITORE | CODICE_FORNITORE | NOME_FORNITORE | STATO_FORNITORE |
|---|---|---|---|
| 123 | ABC | Acme Supply Co | CA |
In questo esempio, CODICE_FORNITORE è la chiave naturale e ID_FORNITORE è una chiave surrogata. Sul piano tecnico, la chiave surrogata non è necessaria, poiché la chiave naturale è già di per sé univoca (CODICE_FORNITORE). {Comunque, i join saranno più performanti se effettuati su un campo numerico piuttosto che su una stringa|senza fonte}
Ora immaginate che questo fornitore trasferisca in Illinois la sede centrale. L'aggiornamento della tabella sovrascriverebbe semplicemente la riga:
| ID_FORNITORE | CODICE_FORNITORE | NOME_FORNITORE | STATO_FORNITORE |
|---|---|---|---|
| 123 | ABC | Acme Supply Co | IL |
L'evidente svantaggio di questo metodo è che non rimane traccia dei dati storici sul data warehouse. Ad esempio non sarete in grado di dire se i vostri fornitori hanno la tendenza a trasferirsi nel Midwest. Ma il vantaggio del Tipo 1 è che è davvero molto facile da gestire.
Se avete delle tabelle aggregate che sommano le misure dei fatti per stato del fornitore, sarà necessario ricalcolarle in occasione di ogni modifica al campo STATO_FORNITORE.
