sfide, opportunitàe competenze per i professionistidell ICT

Transcript

1 sfide, opportunitàe competenze per i professionistidell ICT competenze e lavoro dei Database Manager Gilberto Zampatti Gilberto.zampatti@ngi.it - gzampatti@solidq.com

2 SolidQJournal Free monthly e-magazine Registration is free Highly technical SQL Server articles Authors include: Fernando G. Guerrero, Greg Low, Enrique Catalá, Davide Mauri, Daniel A. Seara, Gianluca Hotz, Antonio Soto, Francesco de Chirico, Erik Veerman, Herbert Albert, Gilberto Zampatti

3 DB vs DW Evoluzione metodologica

4 Database e DataWareHouse: Medesima Architettura fisica Modelli logici significativamente diversi Vocazioni «quasi» antitetiche

5 Architettura fisica: Motore relazionale (Database Engine RDBMS) Software complesso Rigorosa gestione delle risorse: Storage Memoria Cpu Network Elevata capacità di interpretazione del modello dei dati Statistiche Indici Ottimizzazione delle scelte di accesso

6 Modelli logici Database: OLTP (On Line Transactional Process) Aderenza al modello matematico relazionale: Massima normalizzazione delle relazioni Riduzione estrema delle ridondanze Integrità referenziale Configurabilità di vincoli di varia natura Deve assicurare il rispetto dei quattro pilastri ACID Atomicità (efficienza mirata alla transazione) Consistenza Integrità D...urability (ovvero Persistenza)

7 Modelli logici Database: Modelli normali: Normal form Autori Definizione First normal form (1NF) Due versioni: E.F. Codd(1970), C.J. Date (2003) La tabellarappresentafedelmenteunarelazionee non presenta repeating groups Second normal form (2NF) E.F. Codd (1971) Nessun attributo non primario nella tabella risulta funzionalmente dipendente da un sottoinsieme di una chiave candidata Third normal form (3NF) Boyce Codd normal form (BCNF) E.F. Codd(1971; vedere anche la definizione equivalente ma espressa in modo diverso di Carlo Zaniolo(1982) Raymond F. Boyce ed E.F. Codd(1974) Tutti gli attributi non primari sono intransitivamente dipendenti da ogni chiave candidata della tabella Ogni dipendenza funzionale rilevante nella tabella è una dipendenza di una superchiave Fourth normal form (4NF) Ronald Fagin (1977) Fifth normal form (5NF) Ronald Fagin (1979) Domain/key normal form (DKNF) Ronald Fagin (1981) Ogni dipendenza multivalore rilevante nella tabella è una dipendenza di una superchiave Ogni dipendenza referenziale rilevante nella tabella è implicita nelle superchiavi della tabella Ogni vincolo nella tabella è una logica conseguenza dei vincoli di dominio e di chiave della tabella stessa Sixth normal form (6NF) C.J. Date, Hugh Darwen, e Nikos Lorentzos(2002) La tabella non presenta dipendenze referenziali rilevanti (in riferimento a operatori referenziali generici)

8 Modelli logici Database: Modello normalizzato

9 Modelli logici Database: Ottimizzazione delle risorse CPU: Logiche complesse agevolate da parallelismo (in presenza di più processori) Memoria: Tutta quella che si rende disponibile Storage: Massima efficienza per i Transaction Log Distribuzione dei database su più spindles (unità fisiche) Partizionamento di tabelle con molti (MOLTI) milioni di righe

10 Modelli logici Database: Requisiti NON funzionali Sicurezza e Protezione Classificazione delle Utenze Implementazione basata su ruoli Business Continuity Attenta individuazione delle finestre di manutenzione Monitoraggio preventivo Disaster Recovery Pianificazione delle strategie di recovery Scelta degli strumenti idonei High Availability Modelli di alta disponibilità

11 Modelli logici DataWareHouse: OLAP (On Line Analysis Process) Reportistica Origine prevalentemente eterogenea Parziale rinuncia al modello matematico relazionale: Ridotta normalizzazione delle relazioni «Rigenerazione» delle ridondanze Integrità referenziale relativamente abbandonata Deve assicurare efficienza al Reporting Interrogazione massiva dei dati Consistenza ed Integrità indirette D...urability (ovvero Persistenza) relativa Ruolo propedeutico al Modello Multidimensionale MOLAP ROLAP HOLAP

12 Modelli logici DataWareHouse: Star-schema

13 Modelli logici DataWareHouse: Snowflake-schema

14 Modelli logici DataWareHouse: Ottimizzazione delle risorse CPU: Logiche complesse agevolate da parallelismo (in presenza di più processori) Queries massive e logiche di ordinamento tendono ad un elevato consumo di CPU Memoria: Tutta quella che si rende disponibile Storage: Massima efficienza per i Files di dati Distribuzione dei database su più spindles (unità fisiche) Partizionamento di tabelle con molti (MOLTI) milioni di righe

15 Modelli logici DataWareHouse: Requisiti NON funzionali Dipendono in larga misura dal ruolo del Datawarehouse: Sicurezza e Protezione Classificazione delle Utenze Implementazione basata su ruoli Fondamentalmente limitate a «chi può leggere cosa»... Business Continuity Attenta individuazione delle finestre di manutenzione In massima parte si tratta di individuare il ciclo di vita più idoneo Disaster Recovery Pianificazione delle strategie di recovery Scelta degli strumenti idonei Fondamentale in presenza di SLA molto critici High Availability Modelli di alta disponibilità

16 Vocazioni antitetiche: OLTP: Efficienza transazionale (atomicità) Grandi volumi di dati Concorrenza DataWareHouse Efficienza su queries massive Volume di dati potenzialmente...enorme Minore concorrenza Grave errore: la coesistenza