Introduzione alla realizzazione di Data Warehouse con Microsoft SQL Server

MCSD MCAD MCSE+I MCSA MCDBA MCT

www.devleap.it

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

www.devleap.it

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

www.devleap.it

Modellazione Data Warehouse

www.devleap.it

Data Warehouse
Magazzino di dati a livello di impresa Insieme di strumenti per convertire un vasto insieme di dati in informazioni utilizzabili dallutente Obiettivi:
Possibilit di accedere a tutti i dati dellimpresa,

centralizzati in un solo database Coerenza e consolidamento dei dati Velocit nellaccesso alle informazioni Supporto per lanalisi dei dati

www.devleap.it

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

www.devleap.it

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 (bottomup)

www.devleap.it

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

www.devleap.it

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)

www.devleap.it

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

www.devleap.it

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 multidimensionale dei dati Pu produrre report stampati, ma prima di tutto una funzionalit interattiva (come le Pivot Table) Consente di verificare velocemente ipotesi formulate dallutente
www.devleap.it

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

www.devleap.it

Caratteristiche di un Data Warehouse

E un archivio di dati con le seguenti caratteristiche:
subject oriented
integrated nonvolatile

time variant

www.devleap.it

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

www.devleap.it

Identificare gli obiettivi

Il Data Warehouse uno strumento di supporto alle decisioni: lutente in genere il management aziendale Bisogna individuare i fatti di rilievo per i decision-maker, non per loperativit quotidiana Acquisire la visione aziendale del management

www.devleap.it

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

www.devleap.it

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

www.devleap.it

Identificare le fonti dati

In una grande azienda sono spesso fonti eterogenee Molti dati possono risiedere su archivi non strutturati:
Fogli Excel

E-mail

Individuare le modalit di accesso periodico alle fonti dati per alimentare il Data Warehouse

www.devleap.it

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

www.devleap.it

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

www.devleap.it

Il Data Warehouse al lavoro

Source OLTP Systems Data Marts

Data Warehouse

Clients

Retrieve Data 2 Transform Data

Populate Data Warehouse

Populate Data Marts

Query Data

www.devleap.it

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

www.devleap.it

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

www.devleap.it

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 dellutente I dati memorizzati possono essere aggregati (riassuntivi) Le interrogazioni richiedono poche join Ottimizzato per la consultazione, per lutente read-only

www.devleap.it

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)

www.devleap.it

Componenti di un modello DW
Tabella delle Dimensioni
Comuni

Dimensioni

Tabella dei Fatti

Comune Prodotti Prodotto Tempo Unit

Misure

Fatturato

Fatti

Tempo

www.devleap.it

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, ...) www.devleap.it

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 allinterno di una dimensione (per es. anno/mese/giorno) vengono mantenute in una sola tabella dimensionale

www.devleap.it

Star Schema
Employee_Dim
EmployeeKey EmployeeID

. . .

Time_Dim
TimeKey TheDate

Sales_Fact
Dimensional Keys TimeKey TimeKey EmployeeKey ProductKey CustomerKey ShipperKey RequiredDate

Product_Dim
ProductKey ProductID Multipart Key

. . .

. . .

Shipper_Dim
ShipperKey ShipperID

. . .

Measures

Customer_Dim
CustomerKey CustomerID

. . .

. . .

www.devleap.it

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)

www.devleap.it

Snowflake Schema
Primary Dimension Table
Sales_Fact
TimeKey EmployeeKey ProductKey CustomerKey ShipperKey RequiredDate

Product_Dim
ProductKey Product Name Product Size Product Brand ID

. . .

Secondary Dimension Tables

Product_Brand_Id
Product Brand Product Category ID

Product_Category_Id
Product Category Product Category ID
www.devleap.it

Scelta dello schema

Star Comprensibilit del modello Numero di tabelle Complessit query Prestazioni query Easier Less Simpler Quicker

Snowflake More Difficult More More Complex Slower

www.devleap.it

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

www.devleap.it

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

www.devleap.it

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 luso 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
www.devleap.it

Gerarchie nelle Dimensioni

Gerarchia Consolidata
Localit Negozio Continente Paese Regione Citt Negozio

Gerarchia Separata
Localit Negozio Continente Continente Paese Paese Regione Regione Citt Citt Negozio Negozio 01

www.devleap.it

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. dei fatti

Dettaglio limitato alla granularit della tabella

Dimensione geografica Dimensione prodotto Dimensione cliente

www.devleap.it

Condividere le dimensioni tra i Data Mart

Production
One instance exist and is shared among data marts Time Multiple instances exist in individual data marts

Sales

Purchasing
www.devleap.it

Definire la tabella dei fatti

Applicare la granularit definita Garantire la consistenza tra le misure Usare valori numerici e aggregabili

www.devleap.it

Minimizzare dimensione tabella fatti

Ridurre il numero di colonne
Dati ridondanti

Dati non richiesti per lanalisi

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
www.devleap.it

Implementare uno Star Schema

Stima dimensioni Data Warehouse Creare database Creare tabelle Creare constraint

Creare indici

www.devleap.it

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 Value 10,000 x 4 x 365 x 5 73,000,000 (7 IDs x 4 bytes) + (5 measures x 4 bytes) ~ 48 bytes ~3.5 GB 48 bytes x 73,000,000 rows
www.devleap.it

Creare Database
Usare opzioni CREATE DATABASE
SIZE

MAXSIZE
FILEGROWTH

Impostare opzioni Database

Trunc. log on chkpt. (Recovery Model: Simple)

www.devleap.it

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

www.devleap.it

Creare constraints
Usare PRIMARY 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

www.devleap.it

Uso di Foreign Key

FOREIGN KEY Constraint
product_key customer_key order_date_key

FOREIGN KEY Constraint

customer_dim_key

time_dim_key

FOREIGN KEY Constraint

product_dim_key

www.devleap.it

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

www.devleap.it

Conclusioni
Il Data Warehouse un mezzo, non un fine
Facilmente interrogabile dallutente

Fonte dati per Analysis Services (OLAP)

Modellazione denormalizzata secondo canoni precisi

Star Schema

Alimentazione non continua

Di solito giornaliera, settimanale o mensile

www.devleap.it

Altre Informazioni
Dove posso ottenere maggiori informazioni
http://www.microsoft.com/sql

http://www.microsoft.com/sql/evaluation/bi
http://msdn.microsoft.com

Developer resources
Microsoft Developer Network http://www.devleap.it http://www.sqljunkies.com

www.devleap.it