La progettazione del livello riconciliato mette in moto tre attività parallele: analisi e riconciliazione, progettazione del cleaning e progettazione della trasformazione. Partono dagli stessi due ingressi — gli schemi sorgenti operazionali e i campioni dei dati — ma non lavorano sullo stesso oggetto, ed è essenziale non confonderle:
Il prodotto della prima è lo schema riconciliato con il mapping verso le sorgenti operazionali, che finisce nei meta-dati; il prodotto delle altre due sono le procedure per gli strumenti ETL. In questo capitolo ci occupiamo della prima; le altre due sono il capitolo 13.
Schema e dati richiedono strumenti diversi. Un conflitto di schema — la stessa cosa modellata come attributo qui e come entità là — si risolve ragionando sulle dipendenze funzionali e riscrivendo il modello. Un conflitto di dati — «Bologna» scritto in tre modi diversi — si risolve con dizionari, regole e join approssimati a tempo di caricamento. Confonderli è uno degli errori più costosi di un progetto.
Il progettista, confrontandosi con gli esperti del dominio applicativo, acquisisce un'approfondita conoscenza delle sorgenti operazionali attraverso due attività:
| Attività | Definizione |
|---|---|
| Ricognizione | Un esame approfondito degli schemi locali mirato alla piena comprensione del dominio applicativo |
| Normalizzazione | Ha l'obiettivo di correggere gli schemi locali al fine di modellare in modo più accurato il dominio applicativo |
Un punto spesso trascurato: ricognizione e normalizzazione devono essere svolte anche qualora sia presente una sola sorgente dati; qualora esistano più sorgenti, l'operazione dovrà essere ripetuta per ogni singolo schema. Non sono cioè un'attività di «integrazione»: sono un'attività di comprensione, che serve anche quando non c'è nulla da integrare.
Il caso canonico è un'entità che ha inglobato gli attributi di un concetto autonomo. Nello schema di partenza l'entità PRODOTTO porta con sé descrizioneCategoria, nomeCategoria, codiceCategoria oltre ai propri descrizioneProd, nomeProd, codiceProd. La normalizzazione riconosce che quei tre attributi dipendono funzionalmente da codiceCategoria e non da codiceProd, e li estrae in un'entità CATEGORIA collegata da un'associazione (1,1)–(1,n).
Un esercizio classico presenta uno schema logico operazionale che descrive pagamenti di acquisti effettuati con carta di credito, con l'avvertenza esplicita che lo schema include alcune dipendenze funzionali spurie:
ACQUISTI(CodTrans, Data, Importo, TipoValuta, Cambio,
NumCarta:CARTECREDITO, CodNegozio:NEGOZI)
CARTECREDITO(NumCarta, TipoCarta:TIPICARTE,
CodTitolare:TITOLARI, DataScadenza, LimiteUtilizzo)
TITOLARI(CodTitolare, Nome, Cognome, DataNascita,
Professione, FasciaReddito, Qualita)
TIPICARTE(TipoCarta, Circuito, Emittente, Indirizzo,
Nazione, NomeCarta, Colore)
NEGOZI(CodNegozio, Denominazione, Indirizzo, Nazione, Zona,
SitoWeb, Email, Tipologia)
-- dipendenze funzionali spurie:
-- Indirizzo -> Nazione
-- Nazione -> Zona
-- Professione, FasciaReddito -> Qualita
-- Emittente -> Indirizzo«Spurie» significa che quelle dipendenze esistono nel dominio ma non sono rappresentate dallo schema: la relazione NEGOZI non è in terza forma normale, perché Zona dipende da Nazione che dipende da Indirizzo che dipende dalla chiave, e non direttamente dalla chiave. La normalizzazione le fa emergere come entità autonome: nascono NAZIONE (con la sua Zona), una QUALITA determinata dalla coppia (Professione, FasciaReddito) — che è una dipendenza funzionale composta, e diventerà un attributo cross-dimensionale nel DFM — e un EMITTENTE con il proprio indirizzo.
Nel compito scritto la richiesta è quasi sempre nella forma: «Dopo avere effettuato la ricognizione e normalizzazione dello schema, si individui un fatto di interesse e se ne disegni lo schema concettuale secondo il DFM e lo schema logico per un'implementazione ROLAP». La ricognizione e normalizzazione non sono un preambolo facoltativo: sono la parte che determina la forma delle gerarchie. Ogni dipendenza funzionale spuria che non fate emergere è un livello di gerarchia che perderete nello schema di fatto.
L'integrazione di un insieme di sorgenti dati eterogenee (basi di dati relazionali, file dati, sorgenti legacy) consiste nell'individuazione delle corrispondenze fra i concetti rappresentati negli schemi locali e nella risoluzione dei conflitti evidenziati, finalizzate alla creazione di un unico schema globale i cui elementi possano essere correlati con i corrispondenti elementi degli schemi locali (mapping).
Le slide aggiungono due precisazioni importanti. La prima: la fase di integrazione non si deve limitare a evidenziare le differenze di rappresentazione dei concetti comuni a più schemi locali, ma deve anche identificare l'insieme di concetti distinti, memorizzati in schemi differenti, che sono correlati attraverso proprietà semantiche (le cosiddette proprietà interschema). La seconda: per poter ragionare sui concetti espressi negli schemi delle diverse sorgenti è necessario utilizzare un unico formalismo, in modo da fissare i costrutti utilizzabili e la potenza espressiva.
Il flusso completo, per due sorgenti, è quindi il seguente: da ciascuno schema logico locale si passa, tramite ricognizione e normalizzazione, a uno schema concettuale locale trasformato; i due schemi concettuali vengono fusi dall'integrazione degli schemi in un unico schema concettuale globale riconciliato; infine la definizione della corrispondenza con le sorgenti produce lo schema logico globale riconciliato e il mapping, entrambi registrati nei meta-dati.
La fase di analisi dei requisiti ha l'obiettivo di raccogliere le esigenze di utilizzo del data mart espresse dai suoi utenti finali. Ha un'importanza strategica perché influenza le decisioni da prendere riguardo a cinque cose:
La fonte principale da cui attingere i requisiti sono i futuri utenti del data mart (business users). Le slide non nascondono la difficoltà: la differenza nel linguaggio usato da progettisti e utenti, e la percezione spesso distorta che questi ultimi hanno del processo di warehousing, rendono il dialogo difficile e a volte infruttuoso.
Per gli aspetti più tecnici sono invece gli amministratori del sistema informativo e/o i responsabili del CED a fungere da riferimento per il progettista. In questo caso i requisiti da catturare riguardano principalmente vincoli di varia natura imposti sul sistema di data warehousing.
Le due fonti danno requisiti di natura opposta: gli utenti dicono che cosa vorrebbero sapere, gli amministratori dicono che cosa il sistema non potrà fare. Un'analisi dei requisiti che ascolta solo i primi produce un data mart bellissimo e inalimentabile — che è precisamente lo svantaggio dell'approccio demand-driven visto nel capitolo 5.
Le slide descrivono due tecniche di intervista, e la cosa interessante è che il criterio di scelta non è tecnico ma psicologico: dipende dall'atteggiamento dell'intervistato.
| Tecnica | Approccio | Come funziona | Quando usarla |
|---|---|---|---|
| A piramide | Induttivo | L'intervistatore parte da domande molto dettagliate per poi ampliare l'argomento mediante domande aperte che richiedono risposte più generali | Permette di superare la riluttanza di un intervistato scettico, poiché inizialmente non richiede un forte coinvolgimento da parte dell'intervistato |
| A imbuto | Deduttivo | L'intervistatore parte da domande molto generali per poi restringere l'argomento a temi specifici | Utile quando l'intervistato è emozionato o eccessivamente deferente: le domande generali, normalmente in forma aperta, non prevedono una risposta «sbagliata» e alleviano la tensione |
Le domande di esempio delle slide, ordinate dal dettaglio al generale, danno l'idea concreta della piramide: «Ritiene interessante vedere in quali negozi i prodotti vengono venduti a prezzi più alti della media?» → «Quali altre informazioni le interessa associare a una vendita?» → «Ci sono altri fatti che ritiene utili ai fini del processo decisionale?» → «In quale modo pensa che le tecniche di data warehousing potranno giovare al suo reparto?». Percorse nell'ordine inverso, le stesse domande formano un imbuto.
Sono domande sul perché: servono a capire quali fatti hanno davvero rilevanza strategica, e quindi quale data mart prototipare per primo.
Sono le domande più produttive per il progettista: «soggetti coinvolti» dà le dimensioni, «come misuri il successo» dà le misure, «livello di dettaglio» dà la granularità, «quanta informazione storica» dà l'intervallo di storicizzazione.
Sono domande sui vincoli, non sui desiderata: alimentano la progettazione dell'ETL e la valutazione di applicabilità dell'approccio supply-driven.
Dato l'atteggiamento dell'intervistato, scegliete la tecnica.
I fatti sono i concetti su cui gli utenti finali del data mart baseranno il processo decisionale; ogni fatto descrive una categoria di eventi che si verificano in azienda.
Da questa definizione discendono due decisioni delicate.
La granularità. Fissare le dimensioni di un fatto è importante poiché significa determinarne la granularità, ovvero il più fine livello di dettaglio a cui i dati saranno rappresentati. La scelta della granularità nasce da un delicato compromesso fra due esigenze contrapposte: quella di raggiungere un'elevata flessibilità d'utilizzo e quella di conseguire buone prestazioni. Più si scende nel dettaglio, più domande si potranno fare e più il sistema sarà lento e voluminoso.
L'intervallo di storicizzazione. Per ogni fatto occorre definire l'arco temporale che gli eventi memorizzati dovranno coprire. È il parametro che, moltiplicato per il numero di eventi al giorno, determina il volume dati del capitolo 10.
Le slide danno una mappa di data mart e fatti tipici per settore. È utilissima all'esame, perché quasi ogni traccia d'esame cade in una di queste righe.
| Settore | Data mart | Fatti |
|---|---|---|
| Commerciale / manifatturiero | approvvigionamenti | acquisti, inventario di magazzino, distribuzione |
| produzione | confezionamento, inventario, consegna, manifattura | |
| gestione domanda | vendite, fatturazione, ordini, spedizioni, reclami | |
| marketing | promozioni, fidelizzazione, campagne pubblicitarie | |
| Finanziario | bancario | conti correnti, bonifici, prestiti ipotecari, mutui |
| investimenti | acquisto titoli, transazioni di borsa | |
| servizi | carte di credito, domiciliazioni bollette | |
| Sanitario | scheda di ricovero | ricoveri, dimissioni, interventi chirurgici, diagnosi |
| pronto soccorso | accessi, esami, dimissioni | |
| medicina di base | scelte, revoche, prescrizioni | |
| Trasporti | merci | domanda, offerta, trasporti |
| passeggeri | domanda, offerta, trasporti | |
| manutenzione | interventi | |
| Telecomunicazioni | traffico | traffico in rete, chiamate |
| CRM | fidelizzazione, reclami, servizi | |
| Turismo | gestione domanda | biglietteria, noleggi auto, soggiorni |
| CRM | frequent-flyers, reclami | |
| Gestionale | logistica | trasporti, scorte, movimentazione |
| risorse umane | assunzioni, dimissioni, promozioni, incentivi | |
| budgeting | budget commerciale, budget di marketing |
Scorrete la colonna dei fatti: sono tutti sostantivi che denotano eventi — vendite, ricoveri, chiamate, assunzioni — mai oggetti statici come «cliente», «prodotto», «negozio». Quelli sono dimensioni. È la stessa distinzione che nel capitolo 9 diventerà la regola operativa per scegliere il fatto sullo schema sorgente: archivi frequentemente modificati sono buoni candidati, archivi quasi-statici no.
Il prodotto dell'analisi dei requisiti è un documento informale: il glossario dei requisiti. Per ogni fatto candidato registra le possibili dimensioni, le possibili misure e la storicità.
| Fatto | Possibili dimensioni | Possibili misure | Storicità |
|---|---|---|---|
| inventario di magazzino | prodotto, data, magazzino | quantità in magazzino | 1 anno |
| vendite | prodotto, data, negozio | quantità venduta, importo, sconto | 5 anni |
| linee d'ordine | prodotto, data, fornitore | quantità ordinata, importo, sconto | 3 anni |
Il riconoscimento di fatti, dimensioni e misure è strettamente collegato all'identificazione di un carico di lavoro preliminare. Oltre che dall'interazione diretta con l'utente, indicazioni al riguardo potranno essere ricavate da un esame della reportistica correntemente in uso in azienda — una fonte spesso sottovalutata e quasi sempre disponibile.
In questa fase il carico di lavoro può essere espresso in linguaggio naturale; sarà comunque utile per valutare la granularità dei fatti e le misure di interesse, nonché per iniziare ad affrontare il problema dell'aggregazione.
| Fatto | Interrogazione |
|---|---|
| inventario di magazzino | Quantità media di ciascun prodotto presente mensilmente in tutti i magazzini |
| Prodotti per i quali è stata esaurita la scorta contemporaneamente in tutti i magazzini in almeno un'occasione durante la settimana passata | |
| Andamento giornaliero delle scorte complessive per ciascun tipo di prodotto | |
| vendite | Quantità totali di ciascun tipo di prodotto vendute durante l'ultimo mese |
| Incasso totale giornaliero di ciascun negozio | |
| Per un dato negozio, incassi relativi alle diverse categorie di prodotti durante un certo giorno | |
| Riepilogo annuale degli incassi per regione relativamente a un dato prodotto | |
| linee d'ordine | Quantità totale ordinata annualmente presso un certo fornitore |
| Importo giornaliero ordinato nell'ultimo mese per un certo tipo di prodotto | |
| Sconto massimo applicato da ciascun fornitore durante l'ultimo anno per ciascuna categoria di prodotto |
Imparate a leggere una frase di carico di lavoro come una specifica. «Riepilogo annuale degli incassi per regione relativamente a un dato prodotto» contiene tutto: il fatto è vendite; la misura è incasso aggregata con SUM; il group-by set è {anno, regione}; la selezione è su prodotto. Nel capitolo 10 questa lettura diventa la base per decidere quali viste materializzare, e nel capitolo 14 è esattamente il formato con cui l'esame di laboratorio specifica le query Power BI.
Per ciascuna richiesta d'utente identificate fatto, group-by set, misura e selezione; poi confrontate con la soluzione.
Accanto ai requisiti informativi, l'analisi ne raccoglie altri sei gruppi — quelli che vengono soprattutto dagli amministratori del sistema informativo:
| Gruppo | Contenuto |
|---|---|
| Vincoli di progettazione logica e fisica | Per esempio lo spazio disponibile |
| Progetto dell'alimentazione | Periodicità dell'alimentazione |
| Architettura del sistema | Tipo di architettura da implementare, numero dei livelli, presenza di data mart dipendenti o indipendenti, materializzazione del livello riconciliato |
| Applicazioni per l'analisi dei dati | Disamina delle tipologie di interrogazioni e dei rapporti analitici normalmente richiesti |
| Piano di avviamento | Come il sistema entra in esercizio |
| Piano di formazione | Come gli utenti imparano a usarlo |
Gli ultimi due gruppi sembrano estranei alla progettazione, e sono invece quelli che decidono se il sistema verrà usato. Ricordate il capitolo 5: fra i quattro gruppi di fattori di rischio ce n'è uno interamente dedicato all'organizzazione, e uno dei difetti fatali dell'approccio top-down era proprio il venir meno dell'interesse degli utenti.
La fase di integrazione è incentrata sulla componente intensionale delle sorgenti operazionali, cioè riguarda la consistenza degli schemi che le descrivono. Pulizia e trasformazione dei dati operano invece a livello estensionale, cioè coinvolgono direttamente i dati veri e propri. La prima produce lo schema riconciliato e il mapping; le seconde producono le procedure per gli strumenti ETL.
La ricognizione è un esame approfondito degli schemi locali mirato alla piena comprensione del dominio applicativo. La normalizzazione ha l'obiettivo di correggere gli schemi locali per modellare in modo più accurato il dominio. Vanno svolte anche in presenza di una sola sorgente; con più sorgenti, l'operazione va ripetuta per ogni singolo schema.
Nell'individuazione delle corrispondenze fra i concetti rappresentati negli schemi locali e nella risoluzione dei conflitti evidenziati, per creare un unico schema globale i cui elementi possano essere correlati con quelli degli schemi locali (mapping). Non deve limitarsi alle differenze di rappresentazione dei concetti comuni: deve anche identificare concetti distinti memorizzati in schemi differenti ma correlati da proprietà semantiche (proprietà interschema). Richiede l'uso di un unico formalismo.
Cinque: lo schema concettuale dei dati; il progetto dell'alimentazione; le specifiche delle applicazioni per l'analisi dei dati; il piano di avviamento e formazione; le linee guida per la manutenzione e l'evoluzione del sistema. Per questo ha importanza strategica.
La fonte principale sono i futuri utenti del data mart (business users), con la difficoltà data dalla differenza di linguaggio fra progettisti e utenti e dalla percezione spesso distorta che questi hanno del processo di warehousing. Per gli aspetti più tecnici il riferimento sono gli amministratori del sistema informativo e i responsabili del CED, da cui si raccolgono soprattutto vincoli imposti sul sistema.
L'intervista a piramide segue un approccio induttivo: parte da domande molto dettagliate per poi ampliare l'argomento con domande aperte più generali; permette di superare la riluttanza di un intervistato scettico, perché all'inizio non richiede un forte coinvolgimento. L'intervista a imbuto segue un approccio deduttivo: parte da domande molto generali per restringere a temi specifici; è utile con un intervistato emozionato o eccessivamente deferente, perché le domande generali in forma aperta non prevedono risposte «sbagliate» e alleviano la tensione.
Un fatto è un concetto su cui gli utenti finali baseranno il processo decisionale, e descrive una categoria di eventi che si verificano in azienda. Fissare le dimensioni di un fatto significa determinarne la granularità, cioè il più fine livello di dettaglio a cui i dati saranno rappresentati; la scelta nasce da un delicato compromesso fra elevata flessibilità d'utilizzo e buone prestazioni.
L'arco temporale che gli eventi memorizzati dovranno coprire, da definire per ogni fatto. Nel glossario dei requisiti compare come colonna «storicità»: per esempio 1 anno per l'inventario di magazzino, 5 anni per le vendite, 3 anni per le linee d'ordine. Insieme al numero di eventi determina il volume dati.
Per ogni fatto candidato: le possibili dimensioni, le possibili misure e la storicità. È una rappresentazione informale dei requisiti — l'analisi dei requisiti li rappresenta informalmente proprio «per mezzo di appositi glossari» — e serve da ponte verso la progettazione concettuale.
Serve a valutare la granularità dei fatti e le misure di interesse e a iniziare ad affrontare il problema dell'aggregazione. In questa fase può essere espresso in linguaggio naturale. Le indicazioni si ricavano dall'interazione diretta con l'utente e anche da un esame della reportistica correntemente in uso in azienda.
Sei gruppi: vincoli di progettazione logica e fisica (per esempio lo spazio disponibile); progetto dell'alimentazione (periodicità); architettura del sistema di data warehousing (tipo, numero dei livelli, data mart dipendenti o indipendenti, materializzazione del livello riconciliato); applicazioni per l'analisi dei dati (tipologie di interrogazioni e rapporti analitici richiesti); piano di avviamento; piano di formazione.