Capitolo 2: Data Warehousing & Modellazione OLAP

Il secondo modulo del corso approfondisce l’architettura, la modellazione logica e i processi funzionali del Data Warehouse (DW). Se i comuni applicativi gestionali permettono a un’organizzazione di svolgere le operazioni quotidiane, il Data Warehouse costituisce la memoria storica e analitica dell’ente: un’infrastruttura progettata appositamente per trasformare dati operativi frammentati in conoscenza strategica a supporto del decision making direzionale.

1. Definizione Generale e i 4 Pilastri del Data Warehouse

Natura e Finalità del Data Warehouse

Un Data Warehouse è un archivio informatico contenente grandi volumi di dati, strutturato per supportare i vertici aziendali nei processi decisionali ad alto livello (alimentando sistemi DSS — Decision Support System ed EIS — Executive Information System).

Dal punto di vista architetturale e funzionale si distingue nettamente dagli applicativi gestionali (come i software per il calcolo degli stipendi, la fatturazione, la gestione degli acquisti o delle vendite) per tre caratteristiche di base:

Separazione Fisica dagli OLTP: il Data Warehouse non risiede sui server dove girano gli applicativi operativi, ma viene installato perifericamente su sistemi autonomi dedicati. In questo modo l’esecuzione di interrogazioni analitiche pesanti (query complesse su milioni di record) non rallenta né interferisce con l’operatività quotidiana dell’azienda.
Assenza di Automazione di Routine: non è progettato per gestire le transazioni correnti di sportello o l’automazione dei processi d’ufficio.
Acquisizione e Riconciliazione: acquisisce flussi informativi sia da tutti i sistemi gestionali interni sia da fonti esterne, riconciliandoli per renderli omogenei e interrogabili.

I 4 Pilastri Architetturali (Requisiti Fondamentali)

Secondo la definizione classica, affinché una banca dati possa essere qualificata come Data Warehouse deve soddisfare contemporaneamente quattro proprietà fondamentali:

1. Integrata (Integrated)

Confluenza e riconciliazione di fonti eterogenee.
Nel Data Warehouse confluiscono dati provenienti da molteplici sistemi informativi interni ed esterni, originariamente non compatibili tra loro. L’integrazione impone di riconciliare codifiche, formati, unità di misura e denominazioni difformi in un unico schema coerente.

2. Orientata al Soggetto (Subject-Oriented)

Focus sul dato e sui temi chiave aziendali.
Mentre i sistemi gestionali sono orientati alle funzioni e all’elaborazione (processi dinamici che trasformano un input), il DW è orientato ai grandi soggetti d’analisi (Vendite, Clienti, Prodotti). Il valore aggiunto risiede nel dato statico e nella rapidità di interrogazione per viste multidimensionali.

3. Variabile nel Tempo (Time-Variant)

Ampio orizzonte temporale storico.
Tratta un orizzonte temporale molto più esteso (anni o decenni) rispetto ai gestionali operativi, conservando i dati anche quando non servono più all’operatività corrente (es. ex dipendenti ormai in pensione) per studiare i trend storici. Alimentato tramite processi batch o trigger notturni, presenta tipicamente una latenza fino a 24 ore.

4. Non Volatile (Non-Volatile)

Immutabilità e accesso in sola lettura.
Il dato viene pulito e trasformato una sola volta prima dell’inserimento; una volta archiviato nel DW non viene mai più modificato. Essendo acceduto esclusivamente in sola lettura, non soffre di anomalie da aggiornamento concorrente e non richiede il rispetto dei vincoli transazionali ACID.

All’interno di un Data Warehouse coesistono tre diversi livelli di granularità del dato, progettati per bilanciare profondità di analisi, prestazioni di calcolo e costi di archiviazione:

Dati Attuali di Dettaglio (Dettaglio Atomico Recente)
Rappresentano le informazioni al massimo livello di dettaglio atomico importate dai sistemi gestionali (dopo aver subito il trattamento preventivo di pulizia, filtraggio e ricodifica nello schema del DW) e riferite alla finestra temporale più recente.
Dati Storici di Dettaglio (Dettaglio Atomico Storico)
Sono i dati atomici che superano la finestra temporale “attuale” ma vengono mantenuti nella memoria storica del Data Warehouse. Anche se le analisi si svolgono per lo più su valori aggregati, conservare il singolo dato atomico storico è fondamentale qualora occorra effettuare un approfondimento puntuale. Poiché vengono interrogati molto raramente, questi dati sono generalmente trasferiti su supporti di archiviazione più economici (memorie ad altissima capienza ma con velocità di accesso inferiore).
Dati Aggregati (Sintesi Informative Pre-Calcolate)
Sono sintesi numeriche calcolate preventivamente a partire dai dati di dettaglio (es. il numero complessivo di dirigenti, quadri, funzionari e operai di un’azienda, oppure il fatturato mensile consolidato).
Quando un’organizzazione esegue estrazioni periodiche ricorrenti, salva direttamente il dato aggregato sotto forma di viste pre-calcolate nei Data Mart e negli ipercubi: ciò garantisce una straordinaria efficienza computazionale (evitando di ricalcolare da zero somme e conteggi a ogni query) pur mantenendo la tracciabilità completa verso il dettaglio atomico sottostante.

L’architettura del Data Warehouse solleva due importanti questioni di conformità rispetto al Regolamento UE 2016/679 (GDPR):

Il problema della duplicazione e della limitazione della conservazione: replicare i dati atomici dei sistemi gestionali all’interno del Data Warehouse e conservarli per decenni può entrare in attrito con i principi del GDPR, i quali vietano la duplicazione superflua dei dati personali e impongono che il dato personale venga cancellato una volta esaurita la finalità per cui era stato raccolto (si pensi ai dati di un dipendente che ha cessato il rapporto di lavoro: non servono più al gestionale degli stipendi, ma restano utili nel DW per analizzare l’evoluzione storica dell’organico aziendale dal 1910 a oggi).
La soluzione tecnica (Anonimizzazione e Pseudonimizzazione in fase di importazione): poiché al Data Warehouse non interessa quasi mai identificare la singola persona fisica (attività propria dei gestionali operativi), bensì compiere analisi statistiche e strutturali, la buona prassi progettuale (Privacy by Design) prevede di anonimizzare o pseudonimizzare i dati già durante la fase di estrazione e popolamento:
- Pseudonimizzazione: separazione reversibile del dato analitico dagli attributi identificativi diretti (ad esempio criptando il codice fiscale, il nome e il cognome in un contesto sicuro separato). Il dato resta formalmente sotto l’ombrello del GDPR, ma con un profilo di rischio drasticamente ridotto.
- Anonimizzazione: rimozione irreversibile di qualsiasi legame con l’identità dell’interessato; il dato cessa di essere un “dato personale” ed esce completamente dal campo di applicazione del GDPR, potendo essere conservato a tempo indeterminato per fini statistici e storici.
- Tale cautela diventa ancor più stringente qualora le banche dati sorgenti contengano dati particolari (quelli un tempo definiti dati sensibili, afferenti alla salute, all’orientamento sessuale, all’etnia, alle opinioni politiche o sindacali).

3. Modellazione Multidimensionale e Concetti di Data Cube

Dal Cubo all’Ipercubo Multidimensionale

Per consentire ai decision-maker di osservare i fenomeni aziendali da molteplici prospettive, il Data Warehouse abbandona la visione piatta delle tabelle relazionali a favore del Modello Multidimensionale, rappresentato geometricamente come un Cubo di Dati (Data Cube) quando le dimensioni di analisi sono tre, o più in generale come un Ipercubo quando le dimensioni superano le tre spaziali tradizionali.

Rappresentazione Logica di un Cubo Multidimensionale (Data Cube)

Asse X — Dimensione Tempo

Trimestri

1° Trim, 2° Trim, 3° Trim, 4° Trim

Asse Y — Dimensione Articolo

Tipo di Prodotto

Lettori DVD, Televisori, Lettori CD, Videoregistratori

Asse Z — Dimensione Luogo

Punto Vendita (Sede)

Roma-1, Roma-2, Milano-1, Milano-2

Cella Interna — Fatto & Misura

Vendita ➔ Quantità / Incasso

Valore numerico all’intersezione delle coordinate

Fatti, Misure, Dimensioni e Gerarchie

La progettazione di un Data Cube poggia su quattro concetti strutturali:

Fatto (Fact): è il fenomeno o evento aziendale centrale oggetto di studio e misurazione (es. la vendita di prodotti in una catena commerciale, oppure l’effettuazione di una telefonata per un operatore di telecomunicazioni).
Misura (Measure): è la proprietà numerica atomica quantificabile che descrive e quantifica il fatto (es. il numero di pezzi venduti o l’incasso generato; nel caso di una telefonata, la durata in secondi e il costo).
Dimensione (Dimension): è l’asse descrittivo discreto lungo il quale si vuole condurre l’analisi del fatto (es. Tempo, Prodotto, Geografia/Sede, Cliente; nel caso delle telefonate: Chiamante, Chiamato, Tariffa, Ora).
Gerarchia (Hierarchy): è la struttura multilivello di aggregazione definita all’interno di una singola dimensione, che consente di passare dal dettaglio atomico a visioni via via più sintetiche:
- Esempio sulla dimensione Tempo: Giorno ➔ Mese ➔ Trimestre ➔ Anno.
- Esempio sulla dimensione Geografia: Ufficio/Negozio ➔ Città (es. Roma) ➔ Regione (es. Lazio) ➔ Nazione (es. Italia).

Tassonomia e Comportamento delle Misure nei Data Mart

Non tutte le misure numeriche si comportano allo stesso modo quando vengono aggregate lungo le dimensioni del cubo. Per prevenire gravi errori concettuali nei report aziendali, le misure vengono classificate in tre categorie:

Tipologia di Misura	Comportamento Matematico	Esempi Pratici	Regola di Aggregazione
1. Misure Additive	Possono essere sommate liberamente lungo tutte le dimensioni dell’ipercubo mantenendo pieno significato logico.	Incasso, Quantità di articoli venduti (sommabili per tempo, prodotto, punto vendita e reparto).	Operatore standard di somma aritmetica (`SUM`).
2. Misure Semi-Additive	Possono essere sommate solo lungo alcune dimensioni, ma non lungo altre (tipicamente non lungo il tempo o non tra categorie disomogenee).	Saldo di conto corrente, Livello delle scorte, Conteggio clienti (sommabili tra filiali diverse in una data specifica, ma non sommabili tra giorni diversi lungo l’asse temporale).	Somma (`SUM`) sulle dimensioni consentite; media o valore puntuale sull’asse temporale.
3. Misure Non-Additive	Non possono mai essere sommate aritmeticamente lungo alcuna dimensione, poiché la somma risulterebbe priva di senso.	Prezzo unitario, Prezzo medio, Percentuali di sconto, Tassi di interesse (o oggetti non numerici come file immagine).	Richiedono funzioni di aggregazione complesse: media ponderata (`AVG`), massimo (`MAX`), minimo (`MIN`).

4. Gestione delle Slowly Changing Dimensions (SCD 1–3)

Il Problema dei Cambiamenti Dimensionali

All’interno di un Data Warehouse esiste una netta asimmetria evolutiva tra fatti e dimensioni:

I fatti (con le relative misure) cambiano continuamente a ogni ciclo di caricamento (ogni giorno si registrano nuove vendite e le quantità aumentano).
Le dimensioni sono invece quasi-costanti: i loro attributi vengono modificati molto raramente nel tempo (ad esempio quando un cliente cambia indirizzo di residenza, un prodotto viene riclassificato in una nuova categoria merceologica, o si decide di modificare la codifica temporale aggiungendo il giorno della settimana).

Poiché le dimensioni evolvono lentamente ma è vitale non alterare la coerenza dei report storici passati, la letteratura definisce questo fenomeno Slowly Changing Dimensions (SCD) e individua tre strategie standard di gestione:

SCD Tipo 1 — Sovrascrittura Diretta

Meccanismo: il vecchio valore dell’attributo nella tabella dimensione viene semplicemente sovrascritto con il nuovo valore.
Pro: estrema semplicità implementativa; nessuna crescita dimensionale della tabella.
Contro (Criticità): comporta la perdita irreversibile della storia passata. Tutte le vendite storiche precedenti verranno erroneamente attribuite alla nuova dimensione (es. al nuovo indirizzo o alla nuova categoria), falsando le analisi retrospettive.

SCD Tipo 3 — Aggiunta di Nuove Colonne

Meccanismo: si modifica la struttura della tabella dimensione aggiungendo nuove colonne per ciascuna versione (es. Categoria_Versione_1, Categoria_Versione_2, Categoria_Corrente).
Pro: consente di vedere sulla stessa riga sia il valore attuale sia quello immediatamente precedente.
Contro: poco scalabile; costringe a modificare lo schema della tabella aggiungendo colonne per ogni variazione e permette di tracciare solo un numero fisso e limitato di cambiamenti storici.

5. Operazioni OLAP sui Cubi Multidimensionali

Una volta strutturati i dati all’interno di un cubo o ipercubo OLAP, l’analista può esplorare dinamicamente le informazioni attraverso sei operazioni fondamentali di navigazione:

1. Slicing (Affettamento)

Fissare il valore di una singola dimensione.
Estrae una “fetta” dell’ipercubo applicando un vincolo di uguaglianza su una sola dimensione.
Esempio: selezionare tutte le vendite per prodotto e per sede fissando Anno = 2024 (o Anno = 2014).

2. Dicing (Cubettatura)

Selezioni simultanee su più dimensioni.
Estrae un sotto-cubo più piccolo fissando condizioni di filtro su due o più dimensioni contemporaneamente.
Esempio: estrarre le vendite fissando Anno = 2014 e Sedi = Centro-Sud Italia (oppure Trimestre = Q1 e Regione = Lazio).

3. Drill-Down (Approfondimento)

Scendere nella gerarchia verso il dettaglio.
Aumenta il livello di dettaglio analitico navigando verso il basso lungo i livelli di una gerarchia dimensionale.
Esempio: passare dal fatturato aggregato per Anno al dettaglio per Mese e infine per Giorno (o da Marca a Modello).

4. Roll-Up / Drill-Up (Sintesi)

Risalire la gerarchia aggregando i dati.
Operazione inversa al Drill-Down: sintetizza i dati risalendo verso l’alto nella scala gerarchica ed eliminando un livello di dettaglio.
Esempio: aggregare le vendite giornaliere per ottenere i totali mensili e poi annuali.

Operazioni Avanzate: Drill-Across, Drill-Through e Pivoting (Rolling)

Oltre alle quattro operazioni di base, gli strumenti di visualizzazione OLAP supportano tre manovre avanzate di ispezione e riorientamento:

Drill-Across (Navigazione Orizzontale): spostamento trasversale all’interno dello stesso livello gerarchico, mantenendo costante il grado di dettaglio ma cambiando l’elemento osservato (es. passare dall’analisi dell’anno 2014 a quella del 2015 e del 2016, oppure passare dalla Famiglia Prodotti A alla Famiglia Prodotti B).
Drill-Through (Ispezione Atomica): operazione assimilabile a un Drill-Down spinto fino al livello più basso possibile, che valica il cubo OLAP aggregato per accedere direttamente al dato atomico di dettaglio (o alla base dati sorgente). È particolarmente utile quando un dirigente nota una cifra aggregata anomala e vuole ispezionare le singole transazioni elementari che l’hanno determinata.
Pivoting / Rolling (Rotazione del Cubo): riorientamento dinamico della vista multidimensionale ottenuto ruotando gli assi del cubo (scambiando righe e colonne nella matrice di visualizzazione, ad esempio passando da una vista per Anno/Prodotto a una vista per Sede/Prodotto). Permette all’analista di cambiare prospettiva in tempo reale per far emergere correlazioni non visibili nell’orientamento iniziale.

6. Schemi Logici del DW: Star Schema vs. Snowflake Schema

Come vengono memorizzati concretamente gli ipercubi all’interno di un database relazionale dedicato al Data Warehouse? Si utilizzano due schemi logici specifici: lo Star Schema e lo Snowflake Schema.

Il Ribaltamento del Paradigma della Normalizzazione (3NF)

Nei database gestionali tradizionali (modello Entità-Relazioni E/R), le tabelle vengono progettate in Terza Forma Normale (3NF): si eliminano tutte le ridondanze e le dipendenze funzionali tra i campi affinché, modificando un dato in un punto, non si rischi di dimenticare di aggiornarlo altrove generando inconsistenze e anomalie di aggiornamento.

Nel Data Warehouse questo principio viene deliberatamente capovolto:

Poiché i dati sono non volatili (scritti una sola volta e mai più modificati), non esiste alcun rischio di anomalie di aggiornamento o incoerenza in scrittura.
Si sceglie quindi di de-normalizzare le tabelle, accettando un maggior consumo di spazio su disco (risorsa abbondante ed economica nei DW) pur di ridurre drasticamente il numero di tabelle e rendere semplici e velocissime le operazioni di JOIN in lettura.

Star Schema (Schema a Stella) vs. Snowflake Schema (Schema a Fiocco di Neve)

⭐ Star Schema (Schema a Stella)

È l’architettura logica di riferimento del Data Warehouse:

Fact Table centrale: un’unica enorme tabella al centro (contiene il ~99% dei dati) che racchiude le chiavi esterne (FK) e tutte le misure numeriche dei fatti (es. Quantità, Incasso).
Dimension Tables radiali: tante tabelle collegate direttamente al centro quante sono le dimensioni (DIM_TEMPO, DIM_PRODOTTO, DIM_NEGOZIO, DIM_CLIENTE).
Totale De-normalizzazione: le tabelle dimensione non sono normalizzate; contengono al proprio interno l’intera gerarchia (es. Giorno, Mese, Anno nella stessa tabella).
Vantaggio: query estremamente veloci che richiedono un unico JOIN per lo slicing (o pochissimi JOIN diretti per il dicing).

❄️ Snowflake Schema (Schema a Fiocco di Neve)

È una variante parzialmente normalizzata dello schema a stella:

Fact Table invariata: la tabella centrale dei fatti resta identica a quella dello Star Schema.
Normalizzazione delle Dimensioni: le Dimension Tables vengono scomposte e portate in forma normale separando i livelli delle gerarchie in sotto-tabelle ramificate (es. tabella Giorno collegata a tabella Mese, collegata a tabella Anno).
Trade-off Spazio / Prestazioni: risparmia spazio di memoria eliminando le ridondanze nelle dimensioni, ma introduce catene di JOIN più complesse che rallentano le query analitiche.

Confronto Sistematico: Modello E/R (Gestionale) vs. Star Schema

Criterio Architetturale	Schema E/R (Database Relazionale Gestionale)	Star Schema (Data Warehouse)
Grado di Normalizzazione	Normalizzato (3NF): assenza di ridondanze e di dipendenze funzionali per prevenire anomalie in modifica.	Denormalizzato: accetta ridondanze e dipendenze poiché i dati non vengono mai modificati.
Complessità Strutturale	Complesso: può contare 100, 200 o 300 tabelle ramificate in tutte le direzioni.	Semplice e simmetrico: una sola tabella centrale dei fatti circondata dalle tabelle dimensione.
Obiettivo di Ottimizzazione	Ottimizzato per lo spazio su disco e per la velocità delle singole scritture transazionali.	Ottimizzato per le query analitiche di sola lettura su grandi volumi.
Estensibilità	Difficile da estendere senza impattare i vincoli di integrità referenziale esistenti.	Facilmente estensibile aggiungendo nuove dimensioni o misure.
Interrogazione (Query)	Difficile da interrogare a fini statistici (richiede query complesse con decine di `JOIN`).	Facile da interrogare: le query usano sempre le stesse chiavi e pochissimi `JOIN` diretti.
Finalità del Modello	Generalizzato: supporta l’operatività complessiva del sistema informativo.	Specifico: modellato su misura per uno specifico dominio o soggetto di analisi.

7. La Governance dei Metadati e l’Information Catalog

Il Ruolo dei Metadati (“Data About Data”)

Un metadato è letteralmente un “dato sul dato” (data about data): un’informazione aggiuntiva che descrive l’origine, il significato semantico, il formato, le regole di codifica, il valore e la storia delle trasformazioni subite da ciascun dato. Tutti i metadati vengono raccolti e organizzati in un repository centralizzato denominato Information Catalog.

Le 3 Tipologie di Metadati nel Data Warehouse

I metadati del Data Warehouse si suddividono in tre categorie corrispondenti alle diverse fasi del ciclo di vita del sistema:

Metadati di Servizio (Fase di Costruzione e Progettazione)
Vengono definiti già prima dell’inserimento dei dati, in fase di creazione del Data Warehouse. Descrivono la struttura logica e fisica delle tabelle e sono essenziali per progettare l’integrazione e la riconciliazione delle fonti operazionali.
Metadati di Controllo (Fase di Popolamento / ETL)
Vengono utilizzati durante il caricamento e la trasformazione dei dati per governare il funzionamento interno del DW e collegare le tabelle sorgenti allo schema multidimensionale.
Esempio pratico: se una banca dati sorgente chiama un attributo "Time" e un’altra lo chiama "Cronologia" (oppure una esprime le distanze in chilometri e l’altra in metri), il metadato di controllo istruisce il sistema a ricondurre entrambi gli attributi all’unica dimensione "Tempo Data Warehouse" e a convertire automaticamente le misure in un’unica unità standardizzata.
Metadati per l’Utente Finale o di Presentazione (Fase di Consultazione)
Fungono da bussola e guida orientativa per l’analista finale, descrivendo il significato di business delle dimensioni, delle misure e delle viste disponibili affinché l’utente possa navigare agevolmente nell’enorme mole di dati e costruire report e tabelle.

8. Architettura Applicativa a 5 Livelli e Pipeline ETL

Il ciclo operativo completo di un Data Warehouse è organizzato in un’architettura funzionale a 5 livelli, che abbraccia l’intera pipeline ETL (Extract, Transform, Load) fino all’analisi OLAP e alla presentazione visuale:

1. Ingestion

Extract: Query notturne, API, Web Scraping

2. Transformation

Transform: Cleansing, Reject, Ricodifica

3. Preparation & Storage

Load: Dettaglio Atomico & Data Mart

4. Interpretation & Analysis

Motori OLAP & Sintesi Decisionali

5. Presentation

Dashboard BI, Excel & Grafici

Livello 1: Data Ingestion (Extract / Estrazione)

Interrogazioni Parametrizzate: i dati vengono estratti dalle banche dati gestionali interne tramite script e flussi periodici eseguiti nelle finestre temporali di minore attività (tipicamente di notte, tramite trigger o job batch pianificati).
Acquisizione dall’Esterno: integrazione di informazioni esterne all’organizzazione mediante API dedicate, applicativi di Web Scraping o flussi IoT.
Disaccoppiamento Periferico: i flussi vengono convogliati verso i server periferici del Data Warehouse per non sottrarre risorse computazionali ai database operativi.

Livello 2: Data Transformation (Transform / Pulizia e Omogeneizzazione)

Prima di poter essere archiviati, i dati grezzi provenienti da fonti eterogenee devono superare due operazioni cruciali:

Pulizia del Dato (Data Cleansing) e Gestione dei Reject: mediante specifiche Business Rules si individuano errori, dati incompleti o “impurità” fuori dal dominio ammissibile (es. un campo Età = -3). Di fronte a un valore anomalo il sistema può adottare tre comportamenti:
- Scartare il record errato;
- Correggerlo automaticamente o manualmente (es. trasformando -3 in 3, oppure ricalcolando l’età esatta a partire dalla colonna Data di nascita);
- Segnalarlo e isolarlo (Reject): bloccare il dato incoerente in un’area di quarantena per sottoporlo a verifica umana.
Standardizzazione delle Codifiche e dei Formati: tramite i metadati di controllo si rendono i dati comparabili e omogenei:
- Conversione in un’unica unità di misura convenzionale (es. moltiplicare per $1000$ le misure espresse in chilometri per uniformarle a quelle in metri, o convertire piedi in metri);
- Uniformazione dei formati complessi (si pensi ai numerosissimi modi diversi in cui può essere scritto un indirizzo postale o una data nei vari database);
- Riconciliazione delle denominazioni difformi riferite allo stesso concetto semantico.

Livello 3: Preparation & Storage (Load / Archiviazione)

Una volta puliti e standardizzati, i dati vengono caricati nelle strutture di memoria del Data Warehouse: si archivia il dettaglio atomico non volatile e si aggiornano i Data Mart (i contenitori logici tematici che racchiudono gli Star Schema, i cubi e gli ipercubi multidimensionali).

Livello 4: Interpretation & Analysis (Confronto OLTP vs. OLAP)

È la fase a maggior valore aggiunto del Data Warehouse, in cui si eseguono le interrogazioni analitiche e le aggregazioni (mediante operatori quali COUNT, SUM, AVG) sfruttando motori OLAP (Online Analytical Processing), nettamente distinti dai sistemi OLTP (Online Transaction Processing) in uso nei database gestionali:

Caratteristica	OLTP (Online Transaction Processing)	OLAP (Online Analytical Processing)
Ambito di Utilizzo	Database dei sistemi gestionali operativi.	Data Warehouse e sistemi di supporto decisionale.
Obiettivo Principale	Gestione dei dati e delle transazioni correnti.	Analisi dei dati e creazione di sintesi decisionali.
Complessità delle Operazioni	Bassa complessità: operazioni atomiche ripetitive e predefinite.	Alta complessità: permette query articolate ad hoc non previste a priori in fase di progettazione.
Volume di Dati per Operazione	Coinvolge una piccola quantità di dati (pochi record per transazione).	Opera su grosse moli di dati storici e aggregati.
Dinamica del Dato	Continuo aggiornamento dinamico (lettura, inserimento, modifica, cancellazione).	Dati “statici” (storici e consolidati, acceduti in sola lettura).
Orizzonte e Sorgenti	Fotografa lo “stato corrente” di una singola applicazione.	Opera su dati provenienti da più fonti eterogenee con un ampio orizzonte temporale.
Proprietà ACID	Tassative: devono essere garantite Atomicità, Correttezza (Consistenza), Isolamento e Durabilità.	Non rilevanti: non essendoci modifiche concorrenti, si opera esclusivamente in sola lettura.

Livello 5: Data Presentation Layer e Regole di Visualizzazione

L’ultimo strato dell’architettura espone i risultati delle analisi agli utenti finali attraverso tre categorie di strumenti di front-end:

Strumenti Specialistici di Business Intelligence: Query builder, OLAP viewer dedicati e Dashboard Web interattive per esplorare, affettare e ruotare dinamicamente l’ipercubo.
Strumenti di Office Automation: interoperabilità diretta con i software d’ufficio (es. esportazione immediata su fogli di calcolo Excel con generazione del relativo grafico o integrazione con word processor).
Strumenti di Grafica e Publishing: generazione automatizzata di prospetti grafici e reportistica periodica per il management.

Scelta del Diagramma in base all’Obiettivo Analitico

Nella presentazione visuale dei dati, la scelta della tipologia di grafico non è estetica ma dipende rigorosamente dalla relazione logica che si intende evidenziare:

Confronto (Comparison) ➔ Grafici a Barre

I Bar Charts (orizzontali o verticali) sono lo strumento ideale per comparare grandezze tra categorie discrete (es. confrontare il volume di vendite realizzato dalla sede di Milano rispetto a quella di Napoli).

Relazione (Relationship) ➔ Scatter Plot

I Grafici a Dispersione (Scatter Plot) (o i Bubble Chart per tre variabili) sono indicati per analizzare l’esistenza di correlazioni e dipendenze tra due variabili continue.

Distribuzione (Distribution) ➔ Istogrammi

Gli Istogrammi e le curve di distribuzione (es. la curva Gaussiana) permettono di rappresentare la distribuzione di frequenza di una variabile continua e individuare dove si concentrano i valori.

Composizione (Composition) ➔ Grafici a Torta

I Grafici a Torta (Pie Charts) (insieme a Stacked Bar e Tree Map) sono riservati a mostrare in modo immediato la composizione interna e le proporzioni percentuali delle singole parti rispetto a un totale.

9. Aree Applicative Aziendali: DSS, EIS e Domini Operativi

Sistemi DSS vs. Sistemi EIS

Il Data Warehouse alimenta due famiglie principali di sistemi direzionali a supporto del management:

DSS (Decision Support System): sistemi informativi progettati e modellati per supportare i decisori nella risoluzione di problemi specifici e ben circoscritti (es. decidere il piano di riordino scorte di una specifica linea logistica).
EIS (Executive Information System): sistemi direzionali ad alto livello che non creano una struttura rigida legata a un singolo problema, ma mettono a disposizione dell’alta direzione l’intero patrimonio informativo integrato per garantire una circolazione continua e flessibile di informazioni strategiche generali.

Le 4 Aree Operative di Successo

Nella prassi aziendale, finanziaria e istituzionale, l’impiego del Data Warehouse trova applicazione elettiva in quattro domini strategici:

Controllo di Gestione
Costituisce la piattaforma centrale per il reporting direzionale, la definizione dei budget preventivi e consuntivi e l’analisi dettagliata della redditività aziendale per centro di costo o linea di prodotto.
Risk e Asset Management
Consente la simulazione dei portafogli finanziari, l’analisi storica per la valutazione e la prevenzione dei rischi operativi o di credito e la produzione del reporting regolamentare richiesto dalle autorità di vigilanza.
Supporto alle Vendite e Marketing
Guida la pianificazione di campagne promozionali mirate, lo studio delle abitudini di acquisto e l’erogazione di servizi di Customer Care avanzato.
Knowledge Base (Base di Conoscenza)
Permette di strutturare e conservare una base di sapere completa relativa allo specifico settore economico, culturale, giuridico o didattico dell’organizzazione: un patrimonio conoscitivo strutturato che può essere successivamente valorizzato anche per addestrare o alimentare sistemi di Intelligenza Artificiale.