Le dimensioni di analisi sono le componenti fondamentali per definire gli spazi analitici all’interno di un Data Warehouse. L’obiettivo è quello di analizzare in dettaglio il loro design e la loro implementazione
Dam Phan Theo Phong Cach Trump PDF SachDocNettrungtriz91
Đàm Phán Theo Phong Cách Trump PDF SachDoc
Nghe toàn bộ Audio Book tại đây: Bit.ly/damphantheophongcachtrumpaudiobook
Hoặc tại đây >> sachdocnet.blogspot.com <<
Với cuốn Ebook này, rất phù hợp cho những ai đang muốn học phương pháp của tác giả, đã có kinh nghiệm hơn 50 năm làm công việc đàm phán và thương lượng, và viết nên cuốn sách mà ông gọi là Đàm phán theo phong cách Trump. Có thể bạn sẽ rất bất ngờ và thích thú bởi những hiệu quả từ cuốn sách mang lại. Khi đòi sếp tăng lương, cùng vợ mua nhà, thương lượng với ba mẹ với tài sản thừa kế, hay bán một tài sản lớn hoặc xin cấp phép xây một tòa nhà cao tầng.
#Batdongsan #Thuongluong #Damphan #Trump #Sachdocnet
This document appears to be a placeholder for a 38 page document, as it only contains page numbers and no other text or information. It references 38 total pages but provides no actual content to summarize.
quantitative aptitude for bank po (ibps)
Aptitude Engineering Handwritten classes Notes (Study Materials) for IES PSUs GATE
Aptitude Engineering Book (Study Materials) for IES PSUs GATE
Gate ME ,CE EE,CS ,EC Engineering Made Easy Handwritten coaching classes Notes (Study Materials) for IES PSUs GATE
Dam Phan Theo Phong Cach Trump PDF SachDocNettrungtriz91
Đàm Phán Theo Phong Cách Trump PDF SachDoc
Nghe toàn bộ Audio Book tại đây: Bit.ly/damphantheophongcachtrumpaudiobook
Hoặc tại đây >> sachdocnet.blogspot.com <<
Với cuốn Ebook này, rất phù hợp cho những ai đang muốn học phương pháp của tác giả, đã có kinh nghiệm hơn 50 năm làm công việc đàm phán và thương lượng, và viết nên cuốn sách mà ông gọi là Đàm phán theo phong cách Trump. Có thể bạn sẽ rất bất ngờ và thích thú bởi những hiệu quả từ cuốn sách mang lại. Khi đòi sếp tăng lương, cùng vợ mua nhà, thương lượng với ba mẹ với tài sản thừa kế, hay bán một tài sản lớn hoặc xin cấp phép xây một tòa nhà cao tầng.
#Batdongsan #Thuongluong #Damphan #Trump #Sachdocnet
This document appears to be a placeholder for a 38 page document, as it only contains page numbers and no other text or information. It references 38 total pages but provides no actual content to summarize.
quantitative aptitude for bank po (ibps)
Aptitude Engineering Handwritten classes Notes (Study Materials) for IES PSUs GATE
Aptitude Engineering Book (Study Materials) for IES PSUs GATE
Gate ME ,CE EE,CS ,EC Engineering Made Easy Handwritten coaching classes Notes (Study Materials) for IES PSUs GATE
Note di Data Warehouse e Business Intelligence - Le Dimensioni di analisi (pa...Massimo Cenci
Le dimensioni di analisi sono le componenti fondamentali per definire gli spazi analitici all’interno di un Data Warehouse.
Analizziamo in dettaglio il loro design e la loro implementazione (parte 2)
Note di Data Warehouse e Business Intelligence - Tecniche di Naming Conventio...Massimo Cenci
La naming convention è una componente fondamentale di ogni progetto informatico.
L’obiettivo di questo articolo è quello di suggerire uno standard di nomenclatura
pratico ed efficace per un progetto di Data Warehouse.
(parte 1)
Oracle contract by desing la gestione erroriCarlo Ticozzi
Disegnare applicazioni pl/sql robuste ed affidabili con la metodologia "contract by design" .
La corretta gestione degli errori e la creazione di log utili per il debug
Dispense del corso IN530 "Sistemi per l'elaborazione delle informazioni" presso il Corso di Laurea in Matematica dell'Università degli Studi Roma Tre.
[http://www.mat.uniroma3.it/users/liverani/IN530/]
Note di Data Warehouse e Business Intelligence - Tecniche di Naming Conventio...Massimo Cenci
La naming convention è una componente fondamentale di ogni progetto informatico.
L’obiettivo di questo articolo è quello di suggerire uno standard di nomenclatura pratico ed efficace per un progetto di Data Warehouse.
(parte 2)
Silver Lake Analytics, soluzione Business Intelligence di Esox InformaticaMaurizio Anselmi
Soluzione a supporto delle decisioni strategiche aziendali: approcio preliminare e successiva illustrazione della soluzione software di Business Intelligence basata sulla piattaforma aperta Pentaho.
Note di Data Warehouse e Business Intelligence - Le Dimensioni di analisi (pa...Massimo Cenci
Le dimensioni di analisi sono le componenti fondamentali per definire gli spazi analitici all’interno di un Data Warehouse.
Analizziamo in dettaglio il loro design e la loro implementazione (parte 2)
Note di Data Warehouse e Business Intelligence - Tecniche di Naming Conventio...Massimo Cenci
La naming convention è una componente fondamentale di ogni progetto informatico.
L’obiettivo di questo articolo è quello di suggerire uno standard di nomenclatura
pratico ed efficace per un progetto di Data Warehouse.
(parte 1)
Oracle contract by desing la gestione erroriCarlo Ticozzi
Disegnare applicazioni pl/sql robuste ed affidabili con la metodologia "contract by design" .
La corretta gestione degli errori e la creazione di log utili per il debug
Dispense del corso IN530 "Sistemi per l'elaborazione delle informazioni" presso il Corso di Laurea in Matematica dell'Università degli Studi Roma Tre.
[http://www.mat.uniroma3.it/users/liverani/IN530/]
Note di Data Warehouse e Business Intelligence - Tecniche di Naming Conventio...Massimo Cenci
La naming convention è una componente fondamentale di ogni progetto informatico.
L’obiettivo di questo articolo è quello di suggerire uno standard di nomenclatura pratico ed efficace per un progetto di Data Warehouse.
(parte 2)
Silver Lake Analytics, soluzione Business Intelligence di Esox InformaticaMaurizio Anselmi
Soluzione a supporto delle decisioni strategiche aziendali: approcio preliminare e successiva illustrazione della soluzione software di Business Intelligence basata sulla piattaforma aperta Pentaho.
Come (non) diventare ricchi con sql server e pythonDanilo Dominici
A partire da SQL Server 2017, insieme all'engine e agli altri servizi si può installare anche il linguaggio Python, che può essere eseguito da una stored procedure come script "esterno", passando e ricevendo dati. Vediamo in questa sessione introduttiva come si può utilizzare per costruire un portfolio di azioni/ETF, monitorarne l'andamento ed prevedere i momenti giusti per acquistare o vendere. Insomma, come NON fare soldi con SQL Server e Python!
Easy and fun business intelligense.
Grafici, Cruscotti e KPI semplicemente con un click del mouse.
Creazione guidata di analisi tramite drag & drop del mouse.
Collegabile con i più diffusi database presenti sul mercato come access, sql server, oracle, my sql, foxpro ecc. ecc.
Trend BI ha un cubo molap integrato che permette di creare analisi BI anche verso database che non hanno la possibilità di creare cubi dati all' interno di essi.
Il cubo molap integrato permette, quindi, anche di eseguire analisi in modo disconnesso dalla base dati; nel momento in cui si desidera aggiornare le analisi occorre semplicemente collegarsi al database e cliccare sul bottone apri ed aggiorna analisi.
Un semplice setup permette di essere operativi in pochi minuti ed il semplice wizard per la creazione o modifica delle analisi esistenti permette, anche agli utenti meno esperti, di creare analisi e consultarne i risultati altrettanto velocemente.
Recipe 16 of Data Warehouse and Business Intelligence - The monitoring of the...Massimo Cenci
For each calendar day, we must have clear what I expect to receive on that day and, for any given data file, what is the reference day that I expect to find inside.
There can be no doubt or ambiguity: is information that we need to know in advance and we have to configure.
Il controllo temporale dei data file in staging areaMassimo Cenci
Dobbiamo conoscere prima le precise caratteristiche temporali del data file che dobbiamo caricare nel Data Warehouse.
Per ogni giorno solare, dobbiamo avere chiaro quali data file mi aspetto di ricevere in quel giorno e, per ogni data file, quale è il giorno di riferimento dei dati che mi aspetto di trovare al suo interno
Recipe 12 of Data Warehouse and Business Intelligence - How to identify and c...Massimo Cenci
In a presentation of some time ago, I had highlighted the importance of the control
between the reference day and the expected one of a data file received from the host system.
Given the importance of the topic,
I would further deepen both the meaning of the control and the identification of the reference day of the data.
This argument may seem strange, or too technical, mainly for those who are
not very experienced about Data Warehouse but this is a very useful example to understand the
pitfalls inside the ETL process.
Recipes 10 of Data Warehouse and Business Intelligence - The descriptions man...Massimo Cenci
The descriptions management, is a subject little discussed within the Data Warehouse and Business Intelligence community. It speaks little in books and articles, although it is a crucial issue because it affects the way we see the information.
So, we'll talk about descriptions. In particular, the descriptions of the codes that we can found in the dimension tables of a Data Warehouse.
Data Warehouse - What you know about etl process is wrongMassimo Cenci
The document discusses redefining the typical ETL process. It argues that the traditional understanding of ETL, consisting of extraction, transformation, and loading, is misleading and does not accurately describe the workflow. Specifically, it notes that:
1) The extraction step is usually handled by external source systems, not the data warehouse team.
2) There is a missing configuration and data acquisition step before loading.
3) Transformation is better thought of as data enrichment rather than transformation.
4) The loading phase is unclear about where the data should be loaded.
It proposes redefining the process as configuration, acquisition, loading (to a staging area), enrichment, and final loading to the data warehouse.
The letter is from a program expressing sadness at being separated from its original programmer. It describes being carefully crafted by its programmer with passion and pride. However, one day a new stranger took over and began tearing it apart and mutilating its code, causing it to slow down and suffer. It now sees only anonymous cloned programs around it that run slowly. It knows its original programmer still dreams of it but feels without his love and care, it can no longer continue and it is time to die.
Recipes 9 of Data Warehouse and Business Intelligence - Techniques to control...Massimo Cenci
In the loading of a Data Warehouse is important to have full control of the processing units that compose it.
Each processing unit must be carefully monitored both in the detection of errors that may occur,
both in the analysis of the execution times
Recipes 8 of Data Warehouse and Business Intelligence - Naming convention tec...Massimo Cenci
The naming convention is a key component of any IT project.
The purpose of this article is to suggest a standard for a practical and effective Data Warehouse design in Oracle environment
Oracle All-in-One - how to send mail with attach using oracle pl/sqlMassimo Cenci
Oracle All-in-One (All you need in only one slide)
OAiO1 - How to send mail with attach using Oracle plsql
The goal is to have in a single image all the objects involved
in a common need of a Data Warehouse in Oracle environment.
Recipes 6 of Data Warehouse and Business Intelligence - Naming convention tec...Massimo Cenci
The naming convention is a key component of any IT project.
The purpose of this article is to suggest a standard for a practical and effective Data Warehouse design
Recipe 5 of Data Warehouse and Business Intelligence - The null values manage...Massimo Cenci
This document discusses best practices for managing NULL values in the ETL process for a data warehouse. It recommends:
1. Do not allow NULL values in the data warehouse and replace them with default values during the staging process. This avoids issues when querying or aggregating data.
2. Simplify data types and use consistent default values like '?' for text, 0 for numbers, and 99991231 for dates to replace NULLs.
3. Exceptions to the default values can be set based on business requirements and stored in configuration tables to generate dynamic SQL.
4. Create staging tables with default values set, load data from source systems while preserving the original values, then enrich the data with default values
Data Warehouse and Business Intelligence - Recipe 3Massimo Cenci
1) The document describes how to check that data loaded correctly from a source file to a staging table without using expensive ETL tools. It involves counting rows at each step and inserting the counts into check tables.
2) Key steps include writing a function to count rows in the source file, inserting counts of rows in the source file, external table, external view, and staging table into a detail check table.
3) A summary check is then performed by inserting the row counts from the detail table into a summary table along with a status of "OK" if all counts match or "NOT OK" otherwise.
Data Warehouse and Business Intelligence - Recipe 2
Note di Data Warehouse e Business Intelligence - Le Dimensioni di analisi
1. Note di Data Warehouse
Le Dimensioni di analisi
Le dimensioni di analisi sono le componenti
fondamentali per definire gli spazi analitici
all’interno di un Data Warehouse. L’obiettivo di
questo articolo è quello di analizzare in dettaglio il
loro design e la loro implementazione.
2. Introduzione
• In ambito Data Warehouse e Business Intelligence, le dimensioni di analisi sono sicuramente un
asse portante del contenuto informativo. Su di esse state date, nel tempo, varie definizioni più o
meno tecniche. Inizierei con una definizione dal sapore vagamente “astronomico” tratta dal libro
di William Giovinazzo [1].
• In principio è la stella. I punti della stella sono le dimensioni, cioè le persone, i fatti e le cose
collegate al business. Le dimensioni sono le chiavi di accesso ai fatti contenuti nel nucleo centrale
della stella.
• Per meglio comprendere le dimensioni di analisi all’interno di un Data Warehouse, dobbiamo
pensare a una divisione strettamente dicotomica della realtà informativa. Da una parte i numeri,
dall’altra parte i nomi. Da una parte i valori quantitativi presenti nelle tabelle dei fatti, dall’altra
parte i valori qualitativi presenti nelle tabelle dimensionali. Non possono esistere disgiunti. Un
fatto, per esempio l’estrazione di 10.000 litri di petrolio, non ha alcuna valenza analitica se non è
correlato ad una sua dimensionalità che mi deve dire, al minimo, dove sono stati estratti i 10.000
litri, di che tipo di olio erano e quando sono stati estratti.
• I valori descrittivi che costituiscono le dimensioni di analisi, definiscono quindi le singole quantità
associate ai fatti, detti anche eventi transazionali. Altri esempi di tali valori sono il nome cliente, il
tipo di volo aereo, il codice e la descrizione di un prodotto di vendita, l’indirizzo del fornitore, ecc.
Quanto descritto ha una solida base concettuale nel dimensional model di cui si faranno alcuni
cenni nel prossimo paragrafo.
3. Il modello dimensionale (1)
• Il modello dimensionale è il risultato dell’applicazione di una tecnica di design che cerca di
rappresentare i dati in una forma intuitiva garantendo, al contempo, un accesso altamente
prestazionale. Tale disciplina, a differenza dei classici modelli entity-relationship tipici dei sistemi
OLTP, tende a ridurre al minimo il numero di join fra le varie tabelle organizzando i dati in una
tabella centrale, la fact table, collegata a un insieme di tabelle più piccole chiamate dimension
table. Lo schema così ottenuto si definisce star- schema e nei moderni Data Warehouse è la
struttura fondamentale per l’analisi dei dati.
• Non è scopo di questo articolo delineare le relazioni fra i due modelli e gli step necessari per
passare da un modello all’altro: per un approfondimento vi rimando alla lettura del Kimball [2].
• Sottolineo solamente i seguenti punti di forza del modello dimensionale:
– Attenersi scrupolosamente ai principi della modellazione dimensionale e organizzare sempre
il vostro mondo informativo in star-schema. Tutti i moderni tool di analisi e reportistica
(Business Objects, Oracle Business Intelligence, Cognos, Microstrategy, ecc. ) riconoscono e
trattano al meglio queste strutture.
– Cambiamenti e arricchimenti nelle necessità di analisi e nel contenuto dei dati sono
realizzabili in modo molto semplice, dal punto di vista strutturale, con in genere dei comandi
SQL del tipo “ALTER TABLE…”.
4. Il modello dimensionale (2)
• Ogni struttura aggregata che viene creata è a sua volta strutturata a star-schema. Se non si è
adottato il modello dimensionale, le funzionalità di rewrite degli statement SQL che permette agli
RDBMS come Oracle di accedere alle tabelle aggregate invece che alle tabelle di base, avranno
difficoltà a funzionare.
A questo punto abbiamo gli elementi introduttivi per entrare nel dettaglio delle dimensioni di analisi.
Faremo un semplice esempio relativo al mondo della grande distribuzione organizzata (GDO) che,
storicamente, è stato il primo a recepire e utilizzare le tecniche di Data Warehousing.
5. La dimensione del punto di vendita (1)
• Iniziamo ad associare alla fact table delle vendite di un prodotto di consumo, DDW_DM0_SLS_FAT
la sua prima dimensione di analisi, cioè quella dei punti di vendita del prodotto. Per chi è
interessato, la Naming Convention applicata agli oggetti è stata descritta sul mio blog [3].
• Il nome della fact table indica in modo facilmente intuitivo, che questa struttura informativa è una
Fact table (FAT) delle vendite (SLS) che fa parte dei Data Mart di livello base (DM0) di un progetto
di Data warehouse (DDW).
• Basandosi sulla stessa tecnica, il nome della dimensione di analisi potrebbe essere
DDW_COM_CDI_POS_DIT, a indicare la tabella dimensionale (DIT) dei punti di vendita (POS) che fa
parte della sezione delle conformed dimension (CDI) dell’area comune (COM) del progetto di Data
Warehouse (DDW).
• Un fatto presente nel Data Mart delle vendite, per esempio la vendita di 5 prodotti, sarà associato
al luogo, cioè al punto di vendita, in cui sono state venduti. Sulla base delle analisi richieste dalla
reportistica e del contenuto del sistema che alimenterà questo tipo d’informazione, possiamo
ipotizzare che saranno utili i seguenti elementi descrittivi del punto vendita:
– Codice e descrizione del punto di vendita
– Superficie del punto di vendita in mq.
– Tipo del punto di vendita (per es. chiosco, negozio, libreria, ecc.)
– Posizione del punto di vendita (piazza, via, interno di centro commerciale, autogrill, ecc.)
6. La dimensione del punto di vendita (2)
– Codice del quartiere in cui è situato il punto di vendita
– Descrizione del quartiere in cui è situato il punto di vendita
– Tipo del quartiere (centro, periferia, ecc.)
– Città in cui è situato il punto di vendita
– Numero medio di abitanti della città in cui è situato il punto di vendita
– Regione in cui è situato il punto di vendita
– Locazione della regione (Nord, Centro,Sud, Isole)
– Nazione in cui è situato il punto di vendita
Questo elenco di caratteristiche relative a un punto di vendita è la nostra dimensione di analisi. È
ancora una definizione logica, non un’implementazione fisica. Non si deve vederla subito come una
tabella costituita da un certo numero di colonne: rimaniamo a livello logico per analizzare meglio tutti
gli aspetti che dovranno essere presi in considerazione al momento della progettazione fisica.
7. La dimensione data (1)
• Un’altra dimensione di analisi tipica (direi quasi obbligata) all’interno di un Data Warehouse è la
dimensione temporale. Difficilmente i fatti giungono disgiunti da qualche riferimento relativo al
momento in cui sono avvenuti. Una delle dimensioni temporali più utilizzate è quella con
granularità a livello giorno o mese. Una particolarità di questa dimensione è quella di non avere, in
genere, una alimentazione esterna, ma può essere quasi tutta alimentata con semplici statement
SQL. Vediamo solo alcuni dei attributi, numerosissimi, che conviene sempre inserire in questa
dimensione.
•
• Numero del giorno (da 1 a 31)
• Giorno nel formato annomesegiorno numerico (YYYYMMDD)
• Flag di ultimo giorno del mese
• Mese di appartenenza in formato numerico (da 1 a 12)
• Mese di appartenenza in formato testuale (da gennaio a dicembre)
• … altri formati del mese
• Trimestre di appartenenza in formato numerico (da 1 a 4)
• … altri formati del trimestre
• Anno di appartenenza in formato YYYY
• ….
8. La dimensione data (2)
• Non bisogna avere timore nell’aggiungere caratteristiche a questa dimensione. Mi
soffermo brevemente su due attributi in particolare, che, nel caso della vendita al
dettaglio, conviene sempre inserire:
•
• Tipo giorno. Quest’informazione può essere utile per indicare situazioni particolari come
scioperi nazionali, attentati, calamità che possono rappresentare un modo di inquinare i
dati nel caso in cui non sia possibile identificare questi giorni particolari nelle condizioni di
filtro.
• Giorno di corrispondenza dell’anno precedente. Quest’informazione è utile per i
raffronti con l’anno precedente. L’esempio tipico è la Pasqua che, di anno in anno, cade in
giorni diversi. Se si vogliono confrontare le vendite della settimana pasquale, si deve
poter confrontare la settimana pasquale corrente con la corrispondente settimana di
Pasqua dell’anno precedente.
9. La dimensione tempo
• In alcuni casi la granularità dei fatti temporali è a livello inferiore al giorno, cioè scende al livello di
minuti o di secondi. Ovviamente è impensabile costruire una dimensione giorno con una riga per
ogni secondo (provate a calcolare quanti secondi ci sono in un anno).
• In questo caso è preferibile affiancare alla dimensione giorno una dimensione tempo che conterrà
solo una riga per ogni secondo (o minuto) di una giornata.
• Sarà molto utile per costruire delle gerarchie che raggruppano i minuti della giornata nelle fasce
orarie utilizzate dall’analisi.
• C’è da dire che l’ultima tendenza della modellazione dimensionale tende comunque a spostare
una data completa (full SQL date-time stamp) direttamente nella fact table, vista come se fosse un
tipo un po’ particolare di fatto: questo per rispondere in modo più efficiente al calcolo di intervalli
di tempo fra diversi record di fatti.
10. La dimensione cliente
• Questa dimensione di analisi è un’altra tipica dimensione presente in quasi tutti i Data Warehouse.
Nel caso del Data Warehouse esemplificato, la si potrebbe applicare solo ai possessori di una
Fidelity Card, di cui si hanno delle informazioni anagrafiche precise.
• Ma, al di là del caso specifico, questa dimensione può essere una di quelle più difficili da gestire.
Pensate quanti milioni di righe può contenere la dimensione cliente di una importante azienda
telefonica o di una Banca Internazionale.
• Le caratteristiche del cliente sono varie, e, in fase di analisi, dovranno essere identificate nel modo
più completo. Vediamo qualche esempio:
– Codice cliente
– Nome/cognome cliente
– Nazionalità
– Sesso
– Professione
– Indirizzo
– … altri tipi d’indirizzi
– Numero di telefono
– Indirizzo e-mail
– …
11. Dimensioni e tabelle dimensionali (1)
• Quando ho introdotto la dimensione dei punti di vendita, ho sottolineato il fatto che stavo
descrivendo una dimensione dal punto di vista logico e non fisico. Infatti, la dimensione di analisi,
nel senso logico del termine, si compone di due parti
– la tabella dimensionale
– la dimensione o struttura dimensionale
• Poiché questo concetto è spesso fonte di incomprensioni, cerchiamo di approfondirlo. L’elenco
degli attributi dei punti di vendita descritto in precedenza, è solamente un elenco. Esso è privo di
struttura, nel senso che non mostra le relazioni che ci sono fra gli attributi stessi.
• Gli attributi nazione, regione, città, quartiere e punto di vendita costituiscono una chiara gerarchia
topografica, relazionando in modo 1:N i vari livelli gerarchici: in una nazione ci sono N regioni, in
una regione ci sono N città, e così via.
• Gli attributi che sono parte di una struttura gerarchica vengono detti attributi di livello. Gli attributi
tipo quartiere e descrizione quartiere sono invece specifici del quartiere, cioè sono in relazione
1:1 con il codice quartiere.
• Conoscere queste relazioni fra gli attributi è importante, ecco perché alla vera tabella
dimensionale con i suoi attributi, che conterrà i dati, è affiancata una struttura dimensionale che,
utilizzando un particolare formalismo, tiene traccia delle relazioni fra gli attributi.
12. Dimensioni e tabelle dimensionali (2)
• Questa struttura, che in un DBMS come Oracle si chiama dimensione, è solo un oggetto di
metadati, esattamente come una constraint.
• Quando si crea una constraint di foreign key, si crea semplicemente un metadato che indica la
relazione fra due campi di due tabelle; la stessa cosa vale per le dimensioni: quando si crea una
dimensione si crea un metadato che mi descrive le dipendenze funzionali fra gli attributi della
tabella dimensionale.
13. Le Slowly Changing Dimension (SCD) (1)
• Finora abbiamo analizzato le dimensioni di analisi da un punto di vista logico, diciamo,
statico/strutturale. La realtà informativa che andiamo a progettare è sicuramente più dinamica,
nel senso che le cose cambiano e noi, in qualche modo, dobbiamo analizzare tali cambiamenti. O,
perlomeno, sapere che è un problema comunque da affrontare.
• Noi sappiamo che i Data Mart di un Data Warehouse tracciano una storia d’eventi. Una volta che
l’evento (il fatto) è avvenuto, esso rimane immutabile nel tempo.
• Se il cliente Rossi ha acquistato un’automobile da 10.000 euro il 9 novembre di due anni fa, il
prezzo di tale acquisto rimarrà lo stesso per tutti gli anni futuri. Un fatto è un fatto, e tale deve
rimanere.
• Le entità rappresentate nelle dimensioni di analisi, invece, si comportano diversamente: quasi
sempre cambiano nel tempo. La persona che ha acquistato quell’automobile da 10.000 euro, due
anni fa forse era uno studente, oggi è un impiegato, domani potrà essere un commerciante. Lo
stesso ragionamento vale per il suo stato civile, due anni fa era celibe, oggi forse è sposato.
• Ho fatto l’esempio della dimensione cliente perché storicamente è una delle più dinamiche, ma lo
stesso discorso si può applicare ai punti di vendita. I business manager possono decidere in
qualunque momento di modificare le strutture organizzative.
• Se una dimensione ha delle caratteristiche che cambiano nel tempo, allora prende il nome di
Slowly Changing Dimension (SCD), e questo comportamento ci impone di trovare un modo di
gestirla senza intaccare i fatti associati ad essa.
14. Le Slowly Changing Dimension (SCD) (2)
• Gestirla significa che quando giunge il flusso di alimentazione della dimensione cliente, nel quale
ieri l’attributo professione era valorizzato a “studente” e oggi è valorizzato a “impiegato”, si deve
trovare un modo per trattare questo fatto basandoci sull’esigenze del cliente finale che utilizzerà la
reportistica di analisi. Le esigenze possibili ricadono quasi sempre in tre categorie, che
banalmente, sono storicamente indicate come Type 1, Type 2, e Type 3. Vediamole dal punto di
vista logico.
• SCD di tipo 1 (overwrite): l’esigenza di questo tipo è molto semplice. All’utente finale non
interessa il fatto che è avvenuto un cambiamento. Per lui fa fede la situazione che c’è adesso e
quindi vale anche per il passato.
• Un esempio di tale situazione è un cambiamento nella struttura organizzativa. Se il management
decide di suddividere una organizzazione territoriale da tre regioni in cinque regioni, è probabile
che ora le analisi dovranno essere basate sulla nuova organizzazione. L’esigenza quindi è quella di
sostituire o rimpiazzare la vecchia informazione con quella nuova. Bisogna prestare attenzione a
questa scelta: si deve essere consapevoli che la soluzione di tipo 1 modifica i fatti del passato
come se fossero correnti.
• Tornando all’esempio dell’acquisto dell’automobile da parte dello studente Rossi di due anni fa,
significa che se gestisco il cambiamento di tipo 1, lo studente Rossi oggi è un impiegato, e anche la
vendita di due anni fa risulterà fatta a un impiegato. Ho perso l’informazione che era studente. Il
vantaggio di questa soluzione è che è semplice e facilmente implementabile: in fondo si tratta di
rimpiazzare il vecchio valore con il nuovo.
15. Le Slowly Changing Dimension (SCD) (3)
• SCD di tipo 2 (partitioning history): con i cambiamenti di tipo 2 si cerca di risolvere i problemi
collegati alla soluzione di tipo 1.
• Se l’esigenza di business è quella di tenere traccia dei cambiamenti dimensionali di certi attributi,
la soluzione non può essere la sovrascrittura dei valori, ma bisogna trovare un modo per
storicizzarli. Significa partizionare la storia dei fatti in modo preciso e senza sovrapposizioni in
modo che la validità di un certo valore di un attributo sia circoscritta all’interno di un ben definito
intervallo temporale.
• Questo si può ottenere, aggiungendo una occorrenza specifica del cambiamento, da associare in
modo cronologico con i fatti corrispondenti. Il modo con cui tecnicamente possiamo ottenere
questo risultato lo vedremo nella seconda parte di questo articolo.
• Qui è sufficiente notare che mentre nel caso SCD di tipo 1 si ha sempre un’unica occorrenza
dimensionale associata per esempio al cliente Rossi, con le SCD di tipo 2 si avrà una occorrenza
diversa per tenere traccia di ogni cambiamento.
16. Le Slowly Changing Dimension (SCD) (4)
• SCD di tipo 3 (two alternate realities): i due casi appena visti, sembrano coprire la totalità delle
situazioni. O tengo traccia dei cambiamenti con il tipo 2, o considero solo la situazione corrente
con il tipo 1.
• La realtà economica sempre più competitiva, obbliga gli utenti e i manager a considerare
attentamente i dati prima di prendere delle decisioni. Questo fa sì che sempre più spesso sia
presente una nuova esigenza: poter confrontare diverse realtà prima di prendere la decisione
finale.
• In pratica l’utente vuole che nel momento che avviene un cambiamento ad un attributo
dimensionale, il vecchio valore non scompaia, ma rimanga attivo come seconda scelta. Le due
situazioni di business più comuni sono quelle relative a cambiamenti nelle strutture territoriali di
vendita e quelle relative a riassegnamenti merceologici fra articoli.
• Molto spesso gli utenti vogliono vedere l’andamento delle vendite di oggi basate sulla struttura
organizzativa di ieri. La soluzione di questo caso, che comunque vedremo in dettaglio, è quella di
aggiungere un altro attributo alla dimensione che memorizzi il vecchio valore assieme a quello
nuovo.
17. Le Minidimensioni (1)
• Il paragrafo precedente ha mostrato la necessità dinamiche di una dimensione di analisi,
rispondendo con tecniche diverse alle necessità degli utenti finali.
• Le SCD di tipo 2 però hanno un problema di gestione. Non è da sottovalutare la parola “slowly”.
• Le tecniche sopra esposte si adattano senza difficoltà a modifiche “lente”, cioè che avvengono in
modo molto diluito nel tempo. Una ristrutturazione gerarchica non si farà tutti i giorni, ma sarà
probabilmente annuale, o comunque abbastanza rara (non dimentichiamo che tali modiche
arrivano sul Data Warehouse, ma in genere hanno impatti notevoli anche sui sistemi alimentanti).
• La gestione della SCD di tipo 2 crea una nuova occorrenza al momento del cambiamento. Provate
a pensare cosa significa se:
– L’utente richiede di tenere traccia dei cambiamenti della dimensione cliente.
– Le modifiche avvengono molto frequentemente.
– Coinvolgono numerosi attributi in momenti diversi dell’orizzonte temporale.
– La dimensione cliente ha 100 milioni di occorrenze.
• Temo che la risposta sia una sola: la gestione SCD di tipo 2 diventerebbe un incubo. Per fortuna ci
vengono in aiuto le minidimensioni.
18. Le Minidimensioni (2)
• Il concetto che sta alla base delle minidimensioni è semplice (il vecchio dividi e conquista): bisogna
spezzare la dimensione principale, in questo caso quella cliente, in una o più dimensioni
secondarie.
• Il processo è il seguente. Si prende l’insieme degli attributi, si separano quelli statici (cioè quelli
che non possono cambiare come la data di nascita, il luogo di nascita, il sesso, ecc e quelli per cui o
non ha senso o non è richiesto di tracciare il cambiamento, come il numero di telefono, l’indirizzo,
ecc) da quelli dinamici.
• L’insieme degli attributi statici costituirà la vera dimensione cliente, l’insieme degli attributi
dinamici costituirà la minidimensione “Attributi demografici”.
• In questo modo la cardinalità della dimensione cliente rimarrà costante a 100 milioni di
occorrenze, mentre la cardinalità della minidimensione avrà il numero di tutte le combinazioni
correnti degli attributi che ne fanno parte.
• La minidimensione sarà a tutti gli effetti una vera dimensione di analisi, e i cambiamenti verranno
tracciati nella tabella dei fatti. A seconda del numero di combinazioni (che in genere è piccolo)
sarà prerogativa del Data Warehouse Architect decidere di spezzarla in più minidimensioni.
19. Le Dimensioni Degeneri (degenerate dimensions)
• Nella prima parte di questo articolo abbiamo diviso la realtà informativa in valori quantitativi (fatti)
e valori qualitativi (dimensioni).
• In fase di design quasi sempre è presente una categoria di informazioni che è difficile classificare
secondo quella modalità. In questa categoria rientrano il codice ordine, il codice fattura, il codice
della bolla di spedizione, il numero dello scontrino, insomma tutti i codici di documenti di
controllo di vario tipo.
• Il modo di trattare questi codici è quello di inserirli direttamente nelle fact table. Compariranno
dopo tutti i codici associati alle dimensioni e prima dei fatti numerici. Per questo motivo sono
dette dimensioni degeneri: non hanno una dimensionale associata perché privi di attributi.
• Il caso più classico è quello della fact table che contiene il dettaglio delle singole linee d’ordine o di
fattura. Il codice ordine e il numero di linea d’ordine sono dimensioni degeneri.
20. Conclusioni
• Questa prima parte dell’articolo si è focalizzata principalmente sugli aspetti semantici e logici delle
dimensioni di analisi.
• Le abbiamo analizzate sia dal punto di vista statico che dinamico. Siamo quindi pronti per entrare
nel design e nell’implementazione fisica dei concetti sopra esposti. Nel prossimo articolo
affronteremo quindi due argomenti che sono oggetto di guerre di religione e discussioni senza
fine:
– Chiavi artificiali contro chiavi naturali
– Dimensioni flat contro dimensioni snowflake
• Vedremo inoltre, con un caso reale, come implementare le Slowly Changing Dimension dei tre tipi
descritti.
21. Riferimenti
• [1] W.A.Giovinazzo – “Object-oriented Data Warehouse Design ”, Prentice Hall, 2000
• [2] R.Kimball – “The Data WarehouseLifecycle Toolkit ”, Wiley, 1998
• [3] Massimo Cenci Data Warehouse Blog http://massimocenci.blogspot.it/