Introduzione alla realizzazione di Data Warehouse con Microsoft SQL Server www.devleap.it.

Presentazione sul tema: "Introduzione alla realizzazione di Data Warehouse con Microsoft SQL Server www.devleap.it."— Transcript della presentazione:

1 Introduzione alla realizzazione di Data Warehouse con Microsoft SQL Server

2 Chi siamo www.DevLeap.it Un gruppo di 5 persone con tanta voglia di
Studiare a fondo le tecnologie Capire il “behind the scenes” Implementare soluzioni reali Confrontarsi con le problematiche reali Sperimentare nuove idee Facciamo Corsi, Conferenze, Training

3 Agenda Modellazione di un DataWarehouse Data Warehouse e Data Mart
Componenti di un modello di Data Warehouse Differenze tra DB relazionali normalizzati e Data Warehouse Star Schema e Snowflake Schema

4 Modellazione Data Warehouse

5 Data Warehouse Magazzino di dati a livello di impresa
Insieme di strumenti per convertire un vasto insieme di dati in informazioni utilizzabili dall’utente Obiettivi: Possibilità di accedere a tutti i dati dell’impresa, centralizzati in un solo database Coerenza e consolidamento dei dati Velocità nell’accesso alle informazioni Supporto per l’analisi dei dati

6 Data Mart Magazzino di dati a livello dipartimentale
E’ un segmento di un Data Warehouse E’ fisicamente realizzato come un Data Warehouse, ma con una finalità più ristretta: I dati coprono solo alcune aree aziendali (ad es. vendite) Minori costi di realizzazione Risultati più vicini nel tempo

7 Data Warehouse vs. Data Mart
Il Data Warehouse è un progetto più vasto, complesso e costoso, ma garantisce maggiore coerenza dei dati Da un Data Warehouse si possono ricavare velocemente dei Data Mart (top-down) Si può costruire un Data Warehouse unendo più Data Mart realizzati nel tempo (bottom-up)

8 Finalità di un Data Warehouse
Strumento di supporto decisionale Base informativa per costruire sistemi di analisi e previsione: Reports On-Line Analytical Processing (OLAP) Data Mining

9 Report Report che analizzano i dati con una certa profondità storica
Possono richiedere tempi di elaborazione elevati se i dati vanno aggregati Spesso ottenibili con soluzioni OLAP (minore tempo di elaborazione)

10 Cosa è OLAP OLAP: On Line Analytical Processing
È una tecnologia di Business Intelligence Sinonimo di termini usati in precedenza: DSS: Decision Support System EIS: Executive Information System OLAP = vista multidimensionale sui dati

11 On-Line Analytical Processing (OLAP)
I dati, strutturati per dimensioni, vengono esaminati a diversi livelli di dettaglio (tramite aggregazione e drill-down) Viene anche chiamata analisi multi-dimensionale dei dati Può produrre report stampati, ma è prima di tutto una funzionalità interattiva (come le Pivot Table) Consente di verificare velocemente ipotesi formulate dall’utente

12 Data Mining Tecniche per aiutare gli utenti ad estrarre informazioni utili da grandi database L’utente finale non deve essere un esperto di statistica Utilizzato per generare ipotesi

13 Caratteristiche di un Data Warehouse
E’ un archivio di dati con le seguenti caratteristiche: subject oriented integrated nonvolatile time variant

14 Definizione di un Data Warehouse
E’ il processo più lungo e costoso: Identificare gli obiettivi di business Raccogliere ed analizzare informazioni Definire il modello di dati Identificare le fonti di dati Definire le trasformazioni necessarie a consolidare i dati Stabilire profondità temporale, creare una base storica

15 Identificare gli obiettivi
Il Data Warehouse è uno strumento di supporto alle decisioni: l’utente è in genere il management aziendale Bisogna individuare i fatti di rilievo per i decision-maker, non per l’operatività quotidiana Acquisire la visione aziendale del management

16 Raccogliere informazioni
Spesso le informazioni necessarie sono già raccolte e presentate in qualche report Chiedere ai decision-maker di compilare tabelle excel con le informazioni che vorrebbero avere

17 Definire il modello di dati
Identificare gli eventi da misurare: Vendite Chiamate al customer-service Interventi di assistenza Produzione Mantenere flessibilità per il futuro: Nuovi prodotti Nuovi centri assistenza Nuove linee di produzione

18 Identificare le fonti dati
In una grande azienda sono spesso fonti eterogenee Molti dati possono risiedere su archivi non strutturati: Fogli Excel Individuare le modalità di accesso periodico alle fonti dati per alimentare il Data Warehouse

19 Consolidare i dati Decidere le trasformazioni da applicare ai dati per eliminare le differenze di: valuta notazione metrica fiscali memorizzazione fisica (tipo dei dati) Definire un processo automatico e ripetibile di trasformazione dei dati

20 Base storica Prima che il Data Warehouse diventi operativo, è probabile che esistano delle operazioni una-tantum per creare una base storica iniziale Le trasformazioni iniziali possono differire da quelle periodiche di un sistema in produzione: mole di dati da trasferire aggiornamento completo vs. incrementale

21 Il Data Warehouse al lavoro
Data Marts Data Warehouse Source OLTP Systems Clients Retrieve Data Populate Populate Query Transform Data Data Warehouse Data Marts Data 1 2 3 4 5

22 Da OLTP a OLAP Passando da un sistema transazionale ad un sistema di analisi, cambiano le caratteristiche di: normalizzazione prestazioni su query e modifica dei dati profondità storica complessità delle query dettaglio degli eventi rilevati

23 Database OLTP Caratteristiche di un database per un ambiente operativo: Normalizzazione completa Alto numero di tabelle e di associazioni Dati memorizzati al minimo livello di granularità Interrogazioni richiedono join di molte tabelle La struttura dei dati non varia di frequente Ottimizzato per inserimento dei dati

24 Database OLAP Caratteristiche di un database per un ambiente analitico: Entità denormalizzate Disegno del database più semplice (meno tabelle e meno associazioni) per una comprensione più facile da parte dell’utente I dati memorizzati possono essere aggregati (riassuntivi) Le interrogazioni richiedono poche join Ottimizzato per la consultazione, per l’utente è read-only

25 Ottimizzare i database OLAP
Una base dati per OLAP è prima di tutto denormalizzata Esistono dei modelli generici pensati per queste esigenze: Star Schema Snowflake Schema Un database OLAP può essere realizzato sfruttando un generico database relazionale, ma esistono soluzioni specifiche diverse (OLAP Server)

26 Componenti di un modello DW
Comune Prodotto Tempo Unità Fatturato Tabella delle Dimensioni Comuni Prodotti Tabella dei Fatti Misure Fatti Dimensioni

27 Componenti di un modello DW
Tabella dei fatti Contiene misure numeriche che descrivono un evento di business, come una vendita o una transazione bancaria Fatto Una riga nella tabella dei fatti; contiene uno o più valori numerici che misurano un evento Misura Una colonna numerica della tabella dei fatti Dimensione Una entità di business che descrive il quando, chi, dove, come di un fatto (tempo, prodotto, cliente, ...)

28 Star Schema Lo Star Schema è la modellizzazione più semplice ed efficace dei componenti di un data warehouse Ogni tabella dei fatti è associata ad N tabelle dimensionali Relazioni gerarchiche all’interno di una dimensione (per es. anno/mese/giorno) vengono mantenute in una sola tabella dimensionale

29 Star Schema Employee_Dim Time_Dim Product_Dim Customer_Dim Shipper_Dim
EmployeeKey EmployeeID . Time_Dim TimeKey TheDate Product_Dim ProductKey ProductID Customer_Dim CustomerKey CustomerID Shipper_Dim ShipperKey ShipperID Sales_Fact RequiredDate Multipart Key Measures Dimensional Keys

30 Star Schema La tabella dei fatti può contenere misure che si riferiscono a livelli di dettaglio differenti, in funzione della dimensione La tabella dei fatti può contenere lo stesso dato più volte (a livello di riepilogo giornaliero, mensile ed annuale)

31 Primary Dimension Table
Snowflake Schema Secondary Dimension Tables Sales_Fact TimeKey EmployeeKey ProductKey CustomerKey ShipperKey RequiredDate . Product_Brand_Id Product Brand Product Category ID Product_Category_Id Product Category Product_Dim Product Name Product Size Product Brand ID Primary Dimension Table 59

32 Scelta dello schema Star Snowflake Comprensibilità del modello Easier
More Difficult Numero di tabelle Less More Complessità query Simpler More Complex Prestazioni query Quicker Slower

33 Granularità del modello
Determinare i requisiti di analisi Scegliere il livello di dettaglio più basso Richiede più spazio su disco Maggiore tempo di elaborazione Fornisce capacità analitiche con maggiore dettaglio Conformare le misure alla granularità definita

34 Definire le dimensioni
Definire caratteristiche delle dimensioni Identificare gerarchie Definire dimensioni convenzionali Condividere le dimensioni tra i Data Mart Definire altri tipi di dimensioni

35 Caratteristiche delle dimensioni
Applicare le caratteristiche alla tabella delle dimensioni Definire una chiave primaria Includere colonne correlate e descrittive (usare testo, non codici) Designing for Usability and Extensibility Minimizzare o evitare l’uso di codici o abbreviazioni Creare colonne utili per i livelli di aggregazione Evitare valori mancanti o NULL Minimizzare il numero di righe che cambia nel tempo

36 Gerarchie nelle Dimensioni
Gerarchia Consolidata Località Negozio Continente Paese Regione Città Negozio Gerarchia Separata 01

37 Definire dimensioni convenzionali
Dimensione Tempo (o Data – Ora) “spezzare” le informazioni sulla data in attributi individuali Rappresentare la data come giorni lavorativi, weekend, vacanza, stagione, periodo fiscale, ecc. Dettaglio limitato alla granularità della tabella dei fatti Dimensione geografica Dimensione prodotto Dimensione cliente

38 Condividere le dimensioni tra i Data Mart
Production Sales Multiple instances exist in individual data marts One instance exist and is shared among data marts Time Purchasing

39 Definire la tabella dei fatti
Applicare la granularità definita Garantire la consistenza tra le misure Usare valori numerici e aggregabili

40 Minimizzare dimensione tabella fatti
Ridurre il numero di colonne Dati ridondanti Dati non richiesti per l’analisi Ridurre la dimensione di ogni colonna Usare chiavi surrogate Assicurarsi che i campi carattere e binari siano a lunghezza variabile Strano però nella tabella dei fatti avere campi così, a meno che non siano degenerate dimension Disegno Star Schema risultante: Tabelle dei fatti – lunghe e strette Tabelle dimensioni – corte e larghe

41 Implementare uno Star Schema
Stima dimensioni Data Warehouse Creare database Creare tabelle Creare constraint Creare indici

42 Stima dimensioni Data Warehouse
Dimensioni tabella dei fatti Granularità Byte per riga Variables: Years of data = 5 Customers = 10,000 Average number of transactions per customer per day = 4 Description Number of rows in fact table Estimated row size of fact table Estimated data warehouse size Calculation Method 10,000 x 4 x 365 x 5 (7 IDs x 4 bytes) + (5 measures x 4 bytes) 48 bytes x 73,000,000 rows Value 73,000,000 ~ 48 bytes ~3.5 GB

43 Creare Database Usare opzioni CREATE DATABASE
SIZE MAXSIZE FILEGROWTH Impostare opzioni Database Trunc. log on chkpt. (Recovery Model: Simple)

44 Creare tabelle Creare una tabella Specificare NULL o NOT NULL
Quasi sempre NOT NULL Valutare uso di NULL per misure con Analysis Services Generare valori colonne

45 Creare constraints Usare PRIMARY KEY Uso di FOREIGN KEY
Non consente valori duplicati Consente creazione indici Non consente valori NULL Uso di FOREIGN KEY Tabella dei fatti punta a tabelle dimensioni Definisce un riferimento a una colonna con constraint PRIMARY KEY o UNIQUE Specifica i range di valori accettabili

46 Uso di Foreign Key FOREIGN KEY Constraint FOREIGN KEY Constraint
product_key customer_key order_date_key customer_dim_key time_dim_key FOREIGN KEY Constraint product_dim_key

47 Creare indici Creazione indici per data warehouse
Definire chiave primaria in tabelle dimensioni Dichiarare relazioni foreign key Definire chiave primaria in tabella dei fatti Con Analysis Services si può evitare multipart key Valutare uso di chiave surrogata Definire indici per ogni foreign key nella tabella dei fatti Valutare prestazioni se i dati si leggono una volta sola per alimentare i cubi di Analysis Services Usare chiavi surrogate Indici clustered, nonclustered e composti

48 Conclusioni Il Data Warehouse è un mezzo, non un fine
Facilmente interrogabile dall’utente Fonte dati per Analysis Services (OLAP) Modellazione denormalizzata secondo canoni precisi Star Schema Alimentazione non continua Di solito giornaliera, settimanale o mensile

49 Altre Informazioni Dove posso ottenere maggiori informazioni
Developer resources Microsoft Developer Network