Riassunto esame Digital trasformation, Prof. Za Stefano, libro consigliato Sistemi informativi di impresa / internet of things, Bracchi/Francalaci/Motta - Za Stefano

RAPID WAREHOUSING METHODOLOGY (SAS INSTITUTE, 1998)

Accertamento: (piani cazione) veri care che l’azienda sia e ettivamente pronta ad a rontare ilprogetto; determinarne gli scopi, i rischi e i bene ci.

Requisiti: (de nizione dei requisiti e speci ca delle applicazioni utente) raccolta delle speci chedi analisi, di progetto e di architettura per l’intero sistema.

Progettazione: attenzione concentrata su un solo sottoprogetto per volta. Le speci che dianalisi vengono ra nate per generare il progetto logico e sico dei dati e il progettodell’alimentazione; selezionati gli strumenti di implementazione.

Costruzione: DW implementato e popolato, applicazioni UI sviluppate e collaudate.

Attuazione: sistema consegnato e avviato, trainingfi ffi fi à fi fi à fi à fi fi à ffi òfi fi fi fi fi fifi àfi ù fi fi à fi fi fi ff fi fi fi ff fi fi.

Amministrazione e manutenzione: estensione, ridimensionamentodell’architettura, controllo della qualit dei dati.

Riesame:

1. veri ca dell’implementazione
2. conferma accettazione sistema da parte dell’organizzazione
3. misura i bene ci e ettivi

ANALISI E RICONCILIAZIONE FONTI DATI (informazioni disponibili):

• De nire e documentare lo schema di livello dei dati operazionali livello dei dati riconciliati (ricognizione)
• Individuare ed analizzare gli schemi dei DB esistenti relazioni non espresse
• Individuare (normalizzazione)care porzioni utili
• Identi per il DWH
• Omogeneizzazione ed integrazione schemi DB
• Gli amministratori dei DB sono importantissimi in questo step

ANALISI DEI REQUISITI (informazioni necessarie):

• raccolta requisiti utente nale informazioni centrali
• concentrazione su per i processi decisionali
• Identi cazione di fatti e misure anche in linguaggio naturale
• forte responsabilità dell'utente nale
• de nizione intervallo di storicizzazione (compromesso tra velocità e necessità informativa).
• de nizione granularità

PROGETTAZIONE CONCETTUALE schema

Utilizzo dei...

requisiti raccolti per disegnare a partire dal livello dei dati riconciliato uno concettuale per il Data Mart Dimensional Fact Model: - Creazione di uno schema di fatto per ogni fatto di interesse per gli utenti - L'insieme degli schemi di fatto lo schema concettuale per il Data Mart - Ra namento del carico di lavoro e validazione schema concettuale: - Formulazione delle interrogazioni a partire dallo schema concettuale - Veri ca dell'effettiva possibilità di eseguire tutte le interrogazioni PROGETTAZIONE LOGICA Scelta del modello logico di riferimento: - ROLAP vs MOLAP - ROLAP più di uso: - Star schema PROGETTAZIONE FISICA - Scelta degli indici per ottimizzare le prestazioni del DBMS - Identificazione di uno speci co-ottimizzazioni dipendenti dal DBMS PROGETTAZIONE DELL'ALIMENTAZIONE De nizione del processo automatico di alimentazione di: - Livello riconciliato dei dati - Data Warehouse/Data Mart - Scelta dell'intervallo di aggiornamento periodico dei

Approcci metodologici

Guidati dai dati (supply driven):

• Analisi dettagliata delle sorgenti operazionali
• Si basano su quali dati utilizzare e come strutturarli
• I requisiti utente servono a capire secondo il modello dimensionale

Guidati dai requisiti (demand driven):

• Si basano sui requisiti utente dei Data Mart
• Successivamente si valuta come mappare questi requisiti con i dati disponibili (ETL)

SUPPLY-DRIVEN: VANTAGGI E SVANTAGGI

• Semplicità della progettazione di procedure ETL
• Progettazione concettuale semi-automatica (svolta insieme alla rilevazione dei requisiti)
• Ruolo secondario dei requisiti utente
• Scarso supporto al progettista per l'identificazione di fatti, dimensioni e misure
• Non applicabili se non c'è approfondita conoscenza delle fonti dati
• Pre-requisiti: sorgenti dati
• Conoscenza approfondita delle sorgenti dati normalizzate
• Schemi delle sorgenti dati non complesse (buon grado)

DEMAND-DRIVEN: VANTAGGI E SVANTAGGI

• Supporto diretto ai requisiti utente
• Progettazione concettuale basata sui requisiti utente
• Identificazione di fatti, dimensioni e misure in base ai requisiti utente
• Richiede una buona comprensione dei requisiti utente e delle fonti dati disponibili

1. Svantaggi:
• Partono dai bisogni dell'utente a posteriori
• Si verifica solo se ci sono dati sufficienti
• Solo per quanto richiesto
• Elevato sforzo del progettista nella progettazione dell'alimentazione (ETL)
• Rischio effetto sorpresa
• Diminuzione della fiducia nel progettista
• Svantaggi meno rilevanti se già sono presenti sistemi di reportistica
2. Approccio Misto:
• Analisi requisiti e sorgenti effettuate in parallelo:
1. Definizione formale dei requisiti utente
2. Definizione del livello riconciliato dei dati
• Progettazione concettuale semi-automatica
• Complessità dell'alimentazione intermedia
• Raccomandabile quando il livello riconciliato dei dati è esteso e complesso
3. Questioni sulla modellazione concettuale:
• Il modello Entity/Relationship è molto di uso nelle imprese come strumento concettuale per la documentazione standard delle basi di dati relazionali e per la loro progettazione
• Il modello E/R mal si presta a essere adottato nel caso dei data mart

ècostruzione di un data mart sul livello logico, In molti casi i progettisti fondano la ovverode niscono direttamente gli schemi a stella che costituiscono l’implementazione standard delmodello multidimensionale nei sistemi relazionali. Equivale a progettare un database relazionale senza disegnare prima uno schema Entity/Relationship Diversi approcci originali alla modellazione di data mart: - alcuni dei quali basati su estensioni del modello Entity/Relationship, - altri su estensioni di UML, - altri sul modello ad oggetti, - o altri modelli sviluppati ad hoc MODELLAZIONE CONCETTUALE: IL DIMENSIONAL FACT MODEL (DFM) un modello concettuale speci camente concepito per fungere da supporto allaprogettazione di data mart, obiettivi: ed ha i seguenti -dare supporto progettazione concettuale; e cace alla -creare un ambiente in cui le interrogazioni utente possano essere formulate in modointuitivo; -rendere possibile la comunicazione tra il progettista e l’utente nale con l’obiettivo dira

Le speci che dei requisiti sono:

• Costituire una piattaforma stabile per la progettazione logica
• Fornire una documentazione di progetto espressiva e non ambigua

LE COMPONENTI DEL DFM insieme di schemi di fatto,

La rappresentazione concettuale generata dal DFM consiste in un insieme di seguenti elementi:

1. Un fatto concetto di interesse per il processo decisionale; un tipicamente modella un insieme di eventi che accadono nell'impresa.
2. Una misura ne descrive un aspetto quantitativo una proprietà numerica di un fatto e di interesse per l'analisi.
3. Una dimensione proprietà con dominio finito di un fatto (e le relative gerarchie) una e ne descrive una coordinata di analisi.
4. Un evento primario occorrenza di un fatto, una particolare individuata da una ennu-pla costituita da un valore per ciascuna dimensione. A ciascun evento primario associato un valore per ciascuna misura.

COME IDENTIFICARE UN FATTO?

Il fatto e le sue dimensioni vengono identificate grazie alle informazioni avute dalle

1. Who (people, groups, organizations) is of interest to the user?
2. What (functions) is the user trying to analyze?
3. Why does the user need the data?
4. When (for what point in time) does the data need to be recorded?
5. Where (geographically, organizationally) do relevant processes occur?
6. How do we measure the performance or state of the functions being analyzed?

GERARCHIA TRA GLI ATTRIBUTI DIMENSIONALI

Gli attributi dimensionali sono le dimensioni e gli eventuali altri attributi, sempre a valore che le descrivono.

Discreti:

Per esempio, un prodotto descritto dal suo tipo, dalla categoria cui appartiene, dalla sua marca, dal reparto in cui venduto; il loro rapporto basato su una gerarchia.

Gerarchia:

Una un albero direzionato i cui nodi sono attributi dimensionali e i cui archi modellano associazioni molti-a-uno tra coppie di attributi dimensionali. Essa racchiude una

dimensione,posta alla radice dell'albero, e tutti gli attributi dimensionali che la descrivono.-Per esempio, nella gerarchia sulla dimensione prodotto, si avrà un arco da prodotto a tipo per esprimere il tipo di ciascun prodotto, un arco da prodotto a marca per esprimerne la marca, un arco da tipo a categoria per esprimere il fatto che tutti i prodotti di tipo bibita appartengono alla categoria alimentari, un arco da categoria a reparto..prodotto tipo, prodotto marca, tipo categoria, categoria reparto ...→ → → →Sono dipendenze funzionali, per cui vale la proprietà transitiva→ → →(prodotto tipo; tipo categoria) ==> prodotto categoria

SCHEMA DI FATTO ARRICHITO

Tutti gli attributi dimensionali all'interno di uno schema di fatto devono avere nomi diversi tra loro. Nomi uguali possono essere differenziati quali candoli con il nome di un attributo dimensionale che li precede

nella gerarchia (per esempio, città del negozio e città della marca).

GERARCHIE E EVENTI SECONDARI

Dato un insieme di attributi dimensionali (in genere appartenenti a gerarchie distinte), ciascuna ennupla di loro valori individua un evento secondario che aggrega tutti gli eventi primari corrispondenti.

A ciascun evento secondario è associato un valore per ciascuna misura, che riassume tutti i valori della stessa misura negli eventi primari corrispondenti.

ESEMPIO DELLE VENDITE

Scegliamo città del negozio, prodotto e mese come attributi dimensionali per l'aggregazione e consideriamo in particolare l'ennupla (città del negozio: 'Roma', prodotto: 'Brillo', mese: '10/2001').

Questa ennupla individua un evento secondario che aggrega tutte le vendite del prodotto Brillo effettuate nell'ottobre 2001 nei negozi di Roma. ¡ Tutti gli eventi primari corrispondenti a ennuple in cui il valore di prodotto 'Brillo', il valore di negozio uno.

anto un attributo che fornisce ulteriori informazioni o dettagli su un attributo dimensionale. Ad esempio, nell'esempio sopra, l'attributo descrittivo potrebbe essere il nome del negozio di Roma. Le convergenze si verificano quando due o più attributi dimensionali si combinano per formare un nuovo attributo. Ad esempio, potremmo avere un attributo dimensionale per la data e un altro attributo dimensionale per il tipo di evento, e la convergenza potrebbe essere l'evento secondario che si è verificato il 31/10/2001. Le gerarchie condivise si verificano quando più attributi dimensionali condividono la stessa gerarchia. Ad esempio, potremmo avere una gerarchia che va dal negozio alla regione alla nazione, e sia il negozio di Roma che il negozio di Milano condividono la stessa gerarchia. Le gerarchie incomplete si verificano quando alcuni livelli di una gerarchia non sono presenti. Ad esempio, potremmo avere una gerarchia che va dal negozio alla regione alla nazione, ma non abbiamo informazioni sulla regione in cui si trova il negozio di Roma. Le gerarchie ricorsive si verificano quando un attributo dimensionale può avere una relazione con se stesso. Ad esempio, potremmo avere una gerarchia che va dal dipendente al supervisore al supervisore del supervisore, e un dipendente potrebbe essere il supervisore di un altro dipendente. Gli archi multipli si verificano quando ci sono più relazioni tra gli attributi dimensionali. Ad esempio, potremmo avere una relazione tra il negozio e il dipendente, e un'altra relazione tra il negozio e il cliente. Gli archi opzionali si verificano quando una relazione tra gli attributi dimensionali può essere presente o assente. Ad esempio, potremmo avere una relazione tra il negozio e il fornitore, ma non tutti i negozi hanno un fornitore. La somma degli incassi relativi a tutte le vendite aggregate da un negozio di Roma nel periodo compreso tra il 1/10/2001 e il 31/10/2001 sarà espressa come il valore della misura incasso nell'evento secondario in questione.