Il termine data warehouse o ESD (o database decisionale ; in inglese, data warehouse o DWH ) indica un database utilizzato per raccogliere, ordinare, registrare e archiviare informazioni anche da database operativo e fornire una base per il supporto decisionale negli affari.
Un data warehouse è un database che riunisce alcuni o tutti i dati funzionali di un'azienda. Rientra nell'ambito della business intelligence ; il suo obiettivo è fornire un insieme di dati che fungono da riferimento unico, utilizzato per il processo decisionale in azienda attraverso statistiche e report prodotti attraverso strumenti di reporting . Da un punto di vista tecnico, viene utilizzato principalmente per 'scaricare' i database operativi con query che potrebbero influire sulle loro prestazioni.
Da un punto di vista architettonico, ci sono due modi per capirlo:
La definizione più comunemente accettata è un misto di questi due punti di vista. Il termine “ data warehouse ” racchiude il contenitore e il contenuto: designa da un lato il database di dettaglio che è la fonte dei dati all'origine dei Datamart, e dall'altro l'insieme costituito da questo database di dettaglio e dai suoi Datamart. Allo stesso modo, gli attuali metodi di progettazione tengono conto di questi due approcci, privilegiando alcuni aspetti in base ai rischi e alle opportunità insiti in ciascuna azienda.
Infatti, i dati che alimentano il data warehouse sono eterogenei, provenienti da diverse applicazioni produttive, anche da file cosiddetti “flat” ( file Excel , file di testo, XML, ecc.). Si tratta quindi di integrarli, omogeneizzarli e dar loro un significato unico che possa essere compreso da tutti gli utenti. La trasversalità desiderata sarà tanto più efficace quando il sistema informativo sarà realmente integrato nella sua interezza. Questa integrazione richiede in particolare:
Il problema dell'integrazione si basa sulla standardizzazione dei dati interni all'azienda, ma anche dei dati esterni (ad esempio di clienti o fornitori).
È solo a costo di una profonda integrazione che possiamo offrire una visione omogenea e veramente trasversale dell'azienda. Ciò presuppone che il sistema informativo dell'azienda a monte sia ben strutturato, ben controllato e beneficia già di un sufficiente livello di integrazione. In caso contrario, la scarsa qualità dei dati potrebbe impedire l'implementazione del data warehouse.
La storicizzazione di un Datawarehouse si basa sul principio della conservazione dei dati (o non volatilità dei dati). Al fine di mantenere la tracciabilità delle informazioni e delle decisioni prese, i dati una volta inseriti in magazzino sono stabili, di sola lettura e non modificabili dagli utenti. La stessa query lanciata più volte in momenti diversi deve quindi restituire gli stessi risultati. Non appena un dato è qualificato per essere introdotto nel data warehouse, non può più essere alterato, modificato o cancellato (fino a un certo periodo di eliminazione). Diventa, infatti, parte integrante della storia dell'azienda.
Il principio della non volatilità contrasta con la logica dei sistemi produttivi, che molto spesso aggiornano i dati tramite “cancella e sostituisci” ad ogni nuova transazione. Ad ogni dato raccolto viene assegnata una data o un numero di versione per evitare di coprire informazioni già presenti nel database e per consentirne l'evoluzione nel tempo. In questo modo si conserva la storia.
Da un punto di vista funzionale, questa proprietà consente di seguire l'evoluzione degli indicatori nel tempo e di effettuare analisi comparative (ad esempio, vendite da un anno all'altro). Pertanto, in un data warehouse, è necessario un unico repository.
Il data warehouse integra le informazioni provenienti da più applicazioni operative in un unico database. Si passa così da una visione verticale dell'azienda, dettata da vincoli tecnici, ad una visione trasversale, dettata dall'esigenza aziendale, che permette di incrociare funzionalmente le informazioni. L'interesse di questa organizzazione è quello di avere tutte le informazioni utili su un argomento il più delle volte trasversale alle strutture funzionali (servizi) dell'azienda. Diciamo che il data warehouse è "business oriented", in risposta alle diverse attività di business dell'azienda per cui prepara l'analisi. Quando il data warehouse è cross-funzionale si parla poi di "Datawarehouse", quando il data warehouse è specializzato in un'area di business (Finanza, Acquisti, Produzione, ecc.), si parlerà poi di "Datamart".
Da un punto di vista concettuale, i dati di un Data Warehouse possono essere interpretati sotto forma di indicatori distribuiti per assi (o dimensioni): ad esempio il numero di clienti (indicatore) distribuiti per giorno di vendita, negozio o segmento di clienti (assi). Tecnicamente, la modellazione del data warehouse può materializzare questa organizzazione sotto forma di tabelle dei fatti o tabelle di repository .
Il data warehouse ha una struttura dati che in generale può essere rappresentata da un modello dati standardizzato 3FN ( 3NF (en) ) per dati di dettaglio e/o stella o fiocco di neve per dati aggregati e questo in un DBMS Relazionale (soprattutto quando si tratta di dati non -aggregated elementare o unità di dati ). La traduzione tecnica di questo modello viene spesso eseguita all'interno di un cubo OLAP .
Il data warehouse è progettato per contenere dati in linea con le esigenze dell'organizzazione e rispondere centralmente a tutti gli utenti. Non esiste quindi una regola unica in termini di archiviazione o modellazione.
Pertanto, questi dati possono quindi essere conservati:
A monte del data warehouse tutta la fornitura logistica data warehouse:
Questo feed di data warehouse si basa sui dati di origine dei sistemi di produzione transazionale, sotto forma di:
La creazione di una fornitura affidabile del sistema di data warehouse è spesso la voce di bilancio più costosa in un progetto di intelligence .
A valle del data warehouse (e/o data mart ) vanno tutti gli strumenti di restituzione e analisi dei dati ( BI ):
La progettazione dei data warehouse è quindi un processo in continua evoluzione. Da questo punto di vista, possiamo finalmente vedere il data warehouse come un'architettura decisionale in grado di gestire sia l'eterogeneità che il cambiamento e la cui sfida è trasformare i dati in informazioni direttamente fruibili dagli utenti del business interessato.
| Caratteristica | Database di produzione | Data warehouse | Datamart |
|---|---|---|---|
| Chirurgia | gestione quotidiana, produzione | repository, analisi ad hoc | analisi ricorrenti, strumento di gestione, supporto alle decisioni |
| Modello di dati | entità / relazione | 3NF, stella, fiocco di neve | fiocco di neve stellato |
| Standardizzazione | frequente | massimo | raro (ridondanza di informazioni) |
| Dati | attuale, grezzo, dettagliato | storicizzato, dettagliato | storicizzato, aggregato |
| Aggiornare | immediato, in tempo reale | spesso differito, periodico | spesso differito, periodico |
| Livello di consolidamento | debole | debole | Alunno |
| Percezione | verticale | trasversale | orizzontale |
| Operazioni | letture, inserimenti, aggiornamenti, cancellazioni | letture, inserimenti, aggiornamenti | letture, inserimenti, aggiornamenti, cancellazioni |
| Formato | in gigabyte | in terabyte | in gigabyte |
Queste differenze sono dovute al fatto che i magazzini consentono query che possono essere complesse e potrebbero non essere necessariamente basate su un'unica tabella. Possiamo riassumere le conseguenze della trasformazione di un Data Warehouse in un Datamart come segue: un guadagno di tempo di elaborazione e una perdita di potenza d'uso .
Esempi di query OLAP :
Le risposte alle query OLAP possono richiedere da secondi a minuti o addirittura ore.
Il concetto di data warehousing risale alla fine degli anni '80, quando i ricercatori IBM Barry Devlin e Paul Murphy svilupparono il "business data warehouse". In sostanza, il concetto di data warehousing aveva lo scopo di fornire un modello architetturale per il flusso di dati dai sistemi operativi agli ambienti di supporto alle decisioni .
Il concetto ha tentato di affrontare i vari problemi associati a questo flusso, principalmente i costi elevati ad esso associati. In assenza di un'architettura di archiviazione dei dati, era necessaria un'enorme quantità di ridondanza per supportare il supporto decisionale di più ambienti . Nelle grandi aziende, era comune che diversi ambienti di supporto alle decisioni operassero in modo indipendente. Sebbene ogni ambiente servisse utenti diversi, spesso richiedeva l'archiviazione di gran parte degli stessi dati. Il processo di raccolta, pulizia e integrazione dei dati da una varietà di fonti, in genere sistemi operativi esistenti a lungo termine (tipicamente denominati sistemi legacy ), è stato in genere parzialmente replicato per ciascun ambiente. Inoltre, i sistemi operativi sono stati frequentemente rivisti quando sono emerse nuove esigenze di supporto alle decisioni. Spesso, nuovi requisiti richiedevano la raccolta, la pulizia e l'integrazione di nuovi dati da "data mart " progettati per un facile accesso da parte degli utenti.
Inoltre, con la pubblicazione di The IRM Imperative (Wiley & Sons, 1991) di James M. Kerr, l'idea di gestire e assegnare un valore monetario alle risorse di dati di un'organizzazione, e quindi riportare tale valore come una risorsa in un bilancio è diventato popolare. Nel libro, Kerr ha descritto un modo per popolare i database di dominio con dati derivati da sistemi basati sulle transazioni per creare un repository in cui i dati di riepilogo potrebbero essere ulteriormente sfruttati per informare il processo decisionale esecutivo. Questo concetto è servito a promuovere ulteriori riflessioni su come un Data Warehouse potrebbe essere sviluppato e gestito in modo pratico all'interno di qualsiasi azienda.
Principali sviluppi nei primi anni di data warehousing: