Concetti di base dati

Rosario Turco

Una base dati un insieme di dati: logicamente congruenti, cio aderenti alla realt che rappresentano minimamente ridondanti Indipendenti dalla applicazione e dalla tecnologia Le basi dati sono progettate a partire dalla realt che devono rappresentare, con tecniche ER o Object Oriented, bottom up o top-down. I concetti di dato e di oggetto (entit) coincidono. La tecnologia pu fornire, invece, meccanismi diversi per la memorizzazione dei dati (persistenza, etc.) Le uniche ridondanze ammesse in modalit controllata sono: per motivazioni prestazionali: un dato viene ripetuto (o denormalizzato) per evitare sprechi di tempo per motivi di integrit: copie di backup, registrazione dei soli aggiornamenti

Nel seguito approfondiremo lAnalisi Dati.

Una base dati si realizza attraverso lANALISI DATI. LAnalisi dati produce una rappresentazione, in termini di astrazione, della realt o del mondo del cliente, in modo da descrivere: I dati coinvolti nelle funzionalit/servizi offerti dal sistema Le relazioni tra i dati Le caratteristiche quantitative e di struttura dei dati Il concetto di astrazione, determina tutte le caratteristiche/attributi della realt che possono aver senso o meno nel contesto del cliente. Ad esempio loggetto/entit auto per un meccanico avr attributi/entit di interesse come: Km percorsi dallauto (per il cambio dolio) cliente (per lemissione della fattura e il cliente non necessariamente il proprietario) Per il Registro Automobilistico per lauto avranno interesse alcuni attributi/entit come: Numero di targa Proprietario dellauto
3

LAnalisi dei dati , quindi, un processo di indagine col quale si descrive la realt, attraverso: I fenomeni in essa coinvolti Le loro inter-relazioni Per le basi dati si utilizzano tecniche di Modellizzazione a tre livelli distinti: Livello concettuale (Analisi dati) Livello logico (Progettazione dati) Livello fisico (Implementazione dati)

I database in generale sono almeno di due tipologie: Database operazionali (OLTP=Online Transactional Processing) Caratterizzati dal dettaglio di ogni operazione di business Datawarehouse (OLAP=OnLine Analytic Processing) Caratterizzati dallaggregazione dei dati e la quantificazione delle operazioni, secondo determinati fatti, viste, aspetti, con possibilit di drill-down
Tipicamente i dati di uno o pi database OLTP fanno da sorgenti ad un datawarehouse. Nel seguito faremo riferimento a database OLTP.
4

Nel livello concettuale si realizza, in ambito analisi dati, il cosiddetto Schema Concettuale, procedendo in due modalit alternative (viste): Top-down Bottom-up Top-down Nel top-down il punto di partenza sono i fenomeni che caratterizzano la realt, gli oggetti/entit con le loro propriet/attributi e le relative associazioni Fattura Cliente(Nome, Cognome, Indirizzo, PIVA) Indirizzo( Via, Citt, CAP) Bottom-up Nel bottom-up il punto di partenza sono i dati elementari che raggruppati portano allentit

Spesso per verifica e per individuare tutti i dati necessari si utilizzano entrambe le viste.

Lo schema concettuale rivolto allefficacia della base dati, nellambito dellastrazione scelta. Lo schema logico la traduzione dello schema concettuale individuato in modo Gerarchico, Relazionale, Reticolare, ad Oggetti, cio in entit/oggetti tipici del particolare DBMS (DataBase Management System) disponibile. Un DBMS un prodotto per gestire una base dati (ad esempio Oracle, MySQL, SQLServer). Lo schema logico gi rivolto in parte allefficienza dellapplicazione. Lo schema logico descritto tramite il DDL (Data Definition Language) del DBMS adottato. Lo schema fisico la traduzione dello schema logico in modo da garantire aspetti di efficienza e prestazionali, di gestione e manutenzione della base dati (partizionamenti delle tabelle, svecchiamenti, backup, etc.)

Per interagire con i dati dello schema fisico si usano istruzioni descritte tramite il DML (Data Manipolation Language).

Un linguaggio strutturato e standard lSQL (Structured Query Language, standard ANSI SQL 92 ) LSQL un linguaggio per RDBMS cio per DBMS Relazionali ed offre: Istruzioni DDL (Data Definition Language) per creare database Istruzioni DML (Data Manipolation Language) per le operazioni I,U,D,R e gestire il DB Istruzioni DQL (Data Query Language) per effettuare query Istruzioni DCL (Data Control Language) per creare, gestire strumenti di controlli dei dati Istruzioni CTL (Control Transaction Language per gestire le transazioni)

http://it.wikipedia.org/wiki/SQL

La progettazione di una base dati basato sul modello di rappresentazione ER (Entity-Relation) di Chen e la teoria di normalizzazione di Codd. ER Il modello ER basato su tre concetti: Entit Relazione Attributo Entit Un qualsiasi oggetto, concreto o astratto, rilevante per la realt del cliente, identificato univocamente con una semplice definizione. E rappresentato graficamente con un rettangolo.

Nel linguaggio della realt individuato da un sostantivo.

Occorre distinguere tra il concetto di entit (concetto generalizzante, es: Societ) e possibili valori dellentit (valori=Fiat, Poste Italiane, Telecom, etc.), che rappresentano le occorrenze dellentit. Entit Premio, Occorrenze: Nobel, Strega, Bancarella
8

Relazione E il legame tra una o pi entit, per semplicit si disegna come un rombo, Nel linguaggio della realt individuato da un verbo. Notaio, Stipula contratti, Acquirente, Venditore (3 entit in relazione) Esame, propedeutico, Esame (relazione tra occorrenze diverse di una stessa entit) Scrittore Libro

scrive

Impiegato

lavora

Reparto

capo di
9

Il verso della relazione, se non indicato, da sinistra a destra, altrimenti viene indicato con una freccia. Si possono esprimere sia relazioni dirette che inverse. Esempio: Uno Scrittore scrive un Libro. Un libro scritto da uno Scrittore.

10

Attributo E un elemento di informazione dellEntit. Esempio: et, nome Una Entit ha uno o molti attributi. E indicato nellER con un piccolo cerchio. Occorre sempre distinguere tra attributo e valore dellattributo. cognome Cliente

nome PIVA
acqui sta

Prodotto

11

Contesto e astrazione Lastrazione (cose di interesse) dipendono dal contesto; questo condiziona anche se un fenomeno una entit o una relazione. Esempio: Contesto Direzione del Personale (HR): Un Impiegato contrae matrimonio (ad una data) con un Impiegato (es. relazione) Contesto Ufficio Anagrafe del Comune di appartenenza: Un Cittadino contrae Matrimonio (ad una data)

(es. entit)

Notare il diverso ruolo di matrimonio (prima di relazione, poi di entit) ed anche come la stessa entit abbia semantica diversa in contesti diversi (Impiegato, Cittadino)

12

Gerarchia is-a Una gerarchia is-a ( un) esplicita le specializzazioni di una entit. Pu essere completa, quando ci sono tutte le specializzazioni possibili, altrimenti incompleta.

Medico

Is-a

Pediatra

Chirurgo

13

Esempio Dipendente

cognome nome matricola salario

Is-a
qualifica Dirigente Impiegato effettua quantit straordinario

data In una gerarchia is-a la specializzazione eredita gli attributi della generalizzazione Altro es: Una Risorsa umana un dipendente o un consulente
14

Semantica delle relazioni Entit deboli Una entit debole se per definirla necessita di una relazione che la leghi ad unaltra entit. Si marca la relazione con una E accanto al rombo proprio ad indicare una relazione di esistenza e lentit debole con due sbarre verticali (una a destra e una a sinistra) nel rettangolo. Es: Persona chiede Prestito (Prestito da solo non pu esistere: debole)

Se per identificare lentit debole necessario anche di avvalersi di attributi non propri (cio non dellentit debole) allora la relazione si indica con E&I, cio di Esistenza e Identificazione.
Es: Libro ha Copia.

Qui Copia non ha senso da sola, quindi ha una relazione di E ma Copia per essere identificata ha bisogno anche di uno o pi attributi di Libro cio Titolo, Autore. Per cui la relazione E&I
15

Molteplicit E il rapporto esistente tra le occorrenze di ogni entit che partecipa alle relazioni Sono tipicamente 1:1 1:N N:M Esempi

Un Capitano comanda una Nave (1:1)

Un armatore possiede N Navi (1:N) N Nave fanno scalo in M Porto (N:M)

16

Opzionalit Una relazione opzionale nei confronti di una entit (pu e non deve) se almeno una delle sue occorrenze pu non partecipare alla relazione.

Questo vuol dire che una relazione rispetto ad una entit : Obbligatoria (deve) e indicata con un pallino nero sul rombo dal lato dellentit Opzionale (pu) senza indicare nulla
Esempio Una Persona abita in Appartamento

abita in opzionale nei confronti di Persona, perch non tutte le persone abitano in un appartamento, ma anche opzionale nei confronti di Appartamento, perch esistono appartamenti sfitti o vuoti.
Una entit pu essere opzionale o obbligatoria anche rispetto ad una sola entit della relazione.
17

Un Calciatore comanda una Squadra comanda obbligatoria nei confronti di Squadra, perch una Squadra va comandata da un tecnico; comanda opzionale rispetto a Calciatore perch non tutti i calciatori sono anche i tecnici della squadra Esercizio A di Modello Concettuale. Realt da rappresentare:

In un museo sono custodite delle opere darte di vari autori. Il museo suddiviso in sezioni. Ogni opera fa parte di una sezione darte. Una sala ha varie sezioni. Per visitare ogni sezione si paga un biglietto dal bigliettaio. Ci sono vari custodi per ogni sala. Un biglietto fa accedere ad una sala con varie sezioni.
Modellare con ER lesercizio A
18

Esercizio A - svolgimento

19

Modello Relazionale Nel seguito ci interessiamo solo del Modello Relazionale di maggiore utilizzo insieme a quello a Oggetti.

Il Modello Relazionale fu proposto da Codd e si basa sullAlgebra Relazionale, cio su un modello matematico che permette di descrivere formalmente (da un punto di vista di rigore matematico) le entit e le relazioni tra esse.
I due concetti matematici fondamentali sono:

Entit=Insieme
Relazione=Sottoinsieme del prodotto cartesiano tra N insiemi, non necessariamente distinti e i cui domini possono essere solo di tipo semplice (rappresentazione piatta). Le relazioni, quindi, non possono avere tipi aggregati o liste. Esempio Et definita sul dominio degli interi
20

Definizione formale di Relazione Siano T gli insiemi D1, ,DT, non necessariamente distinti, R allora una relazione sugli insiemi Di, se R un insieme ordinato di tuple tale che:

(d1,,dT) al prodotto cartesiano D1 x D2 x x DT Dove Dj il dominio (j=1T) T il grado della relazione R.

D1 DT

Una relazione rappresentata con una tabella come in figura.

Ogni riga della tabella una tupla o n-upla.

Ogni colonna della tabella un dominio La tabella NxT dove N il numero di righe o di tuple e T la cardinalit di R.
21

Dominio Il ruolo svolto da un dominio nellambito di una relazione si dice Attributo. Lattributo il significato che gli elementi del dominio assumono nella relazione. Caratteristiche fondamentali delle relazioni Le caratteristiche fondamentali delle relazioni sono: Atomicit dellattributo Indipendenza dallordine delle tuple nella relazione Indipendenza dallordine delle colonne nella relazione

Chiave di una relazione

Chiave candidata un attributo semplice o composto (pi attributi), che individua univocamente una ricorrenza del fenomeno della realt.

Tra le chiavi candidate si sceglier metodicamente la chiave primaria (Primary Key)

22

Chiave esterna (Foreign Key)

Siano assegnate due Relazioni R1 e R2.

Un insieme di attributi x R1 chiave esterna (Fk) in R2 se e solo se x pu assumere valori definiti per y R2 e y chiave primaria in R2.

Regole di integrit
Entity Integrity: Ogni attributo di una Pk deve sempre assumere valore noto (not null).

Referenzial Integrity: Se Fk chiave esterna in R2 (quindi anche chiave primaria in R2) allora Fk in R1 pu assumere come valori: Quelli della Pk in R2 Essere omessa, cio non c legame della tupla tra R1 e R2
23

Vincoli o Constraint I Vincoli o Constraint sono delle regole che restringono i valori ammessi dal campo della entit o della relazione. I campi di una relazione possono essere soggetti a vincoli di vario tipo: Il tipo con cui sono dichiarati Primary Key Foreign Key UNIQUE (pi righe non possono avere per quel campo lo stesso valore) NOT NULL (il campo non pu essere NULL richiede di essere valorizzato) NULL (il campo pu non essere valorizzato) CHECK (il valore deve rispettare una condizione) DEFAULT (il valore se non inserito assume un default)

24

Normalizzazione

Scopo: Rendere le tabelle indipendenti dagli aggiornamenti Rendere le basi dati indipendenti dagli applicativi Ridurre la necessit di ristrutturazione del DB quando si introducono nuovi tipi di dati Per comprendere la normalizzazione occorre introdurre delle definizioni.
Attributi funzionalmente dipendenti Un attributo B R funzionalmente dipendente da A R se ogni a A ha non pi di un valore associato in B e si indica con la scrittura: R.A -> R.B (si legge funzionalmente dipendenti)

25

Prima Forma Normale (PFN)

Sia W linsieme totale degli attributi di R. Una relazione R in PFN se per ogni chiave candidata k (uno o pi attributi) della relazione R risulta che: 1.Il valore di k individua univocamente la tupla (R.k -> R.W) 2.Nessun attributo di k pu essere eliminato senza violare la 1. Seconda Forma Normale (SFN) Una relazione R in SFN se 1.R in PFN 2.Ogni attributo di R non primario (non appartenente a chiave candidata) pienamente dipendente da ogni chiave candidata. Assegnati due sottoinsiemi D,E degli attributi di R, si dice che E pienamente o totalmente dipendente da D in R se E non funzionalmente dipendente da D. La dipendenza totale va indicata col simbolo -/>.

26

Esempio Prendiamo Dipendente, Reparto, Divisione Ogni dipendente lavora in un solo reparto Ogni reparto appartiene ad una sola divisione

Quindi
R.Dipendente -> R.Reparto R.Reparto -> R.Divisione C limplicazione R.Dipendente ->R.Divisione

Cio
R.(Dipendente, Reparto) -> R.Divisione dipendenza immediata

27

Esempio Seconda Forma Normale

Sia assegnata una relazione R di grado T=3

R(Fornitore, Prodotto, Citt) Si sa che: Un fornitore lavora in una sola citt Un fornitore vende pi prodotti Un prodotto venduto da pi fornitori Per esercizio: - Fare il modello ER concettuale (a carico del lettore) - Scrivere le dipende funzionali e non - Individuare la chiave primaria - Scrivere lo schema in SFN

28

R.Fornitore R.Fornitore R.Prodotto

-> -/> -/>

R.Citt R.Prodotto R.Fornitore

La chiave (Fornitore, Prodotto)

Ridurre R in SFN significa sostituirla con due sue proiezioni

R1 = Proiez(Forn, Prod) ( R ) R2 = Proiez(Forn, Citt) ( R )

29

Terza Forma Normale (TFN)

Siano A,B,C gli attributi di R, inoltre sia: R.A -> R.B R.B -/> R.A R.B -> R.C Questo implica che: R.A -> R.C R.C -/> R.A Cio C transitivamente dipendente da A (pienamente dipendente) in R. Si dice che R in TFN se: 1.R in SFN 2.Ogni attributo non primario di R non pienamente dipendente da ogni chiave candidata

30

Esempio Terza Forma Normale

Sia R una relazione di quarto grado R( Impiegato,CodiceLavoro,Direzione,Manager,TipoContratto)

Un Impiegato pu svolgere una sola mansione/attivit (CodiceLavoro) Ogni Impiegato svolge la sua attivit presso ununica Direzione Ogni Direzione ha un solo Manager Per le persone che lavorano presso una stessa direzione previsto lo stesso tipo di contratto (TipoContratto)

Svolgere lesercizio facendo: Modello ER (a carico del lettore) Dipendenze funzionali e Dipendenza piena (totale) TFN

31

Svolgimento Esercizio precedente

R.Impiegato -> R.CodiceLavoro R.Impiegato -> R.Direzione R.Direzione -> R.Manager R.Direzione->R.TipoContratto implicazioni R.Impiegato -> R.Manager R.Impiegato -> R.TipoContratto
Per rendere R in TFN dobbiamo sostituirla con due sue proiezioni: R1 = Proiez ( Impeigato, CodiceLavoro, Direzione) ( R ) R2 = Proiez (Direzione, Manager, TipoContrato) ( R )

32

Regole standard per ottenere un DB normalizzato dallo schema concettuale

A.Creare una relazione (=tabella) per ogni entit: essa eredita tutti gli attributi semplici dellentit
B.Creare una relazione per ogni attributo non semplice: i suoi attributi saranno gli attributi di tipo non semplice e la chiave primaria quella dellentit di provenienza C.Creare una relazione per ogni associazione: avr come attributi le chiave primarie dellentit collegate dalla associazione e gli eventuali attributi definiti sulla associazione stessa. D.[opzionale] Se lassociazione 1 a N si pu porre la chiave esterna dalla parte dellassociazione univoca

33

Esempi di applicazione delle regole standard pk

Attributo non semplice

C1 1 M C indi rizz o C2 N 1

Attributo semplice

Esempio 1

matr no me

te le fo ni via citt

a 1

a 2

a Li 4 st a

34

Regola A X ( matr, nome) Y (a1, a2, a4) Regola B X1 ( matr, via, citt) X2 ( matr, telefono) Y1 (a1, a3) Regola C C ( matr, a1, c1,c2)

35

pk

Attributo non semplice

C1 1 M C N 1

Attributo semplice

Esempio 2

a1

a2 a3

b 1

b 2

36

Regola A A ( a1, a2,a3) B ( b1, b2) Regola C C ( a1,b1, c1)

In realt potremmo avere nel caso N a M anche A(a1,a2,a3,b1,b2,c1)

La scelta della soluzione dipende anche dalla performance che si vuole ottenere.

37

pk

Attributo non semplice

C1 1 1 C N 1

Attributo semplice

Esempio 2

a1

a2 a3

b 1

b 2

38

Regola A e D A ( a1, a2,a3, b1,c1) B ( b1, b2) Processo classico DAFNE Per ottenere la giusta soluzione nella modellazione del database si devono mettere insieme quattro viste, con rispettiva integrazione: Analisi delle funzionalit richieste Analisi dei dati Disegno delle funzionalit Disegno dei dati Integrazione dati e funzionalit (in analisi e disegno)

39

Processo DAFNE

Analisi Funzioni

Analisi Dati

Disegno Funzioni

Disegno Dati

40

ANALISI DATI Input: Requisiti Interviste Specifiche di processo Specifiche di architettura Specifiche funzionali Output: Modello ER dei dati e Schema Concettuale Specifica di ogni entit e sua lista di attributi Specifica di ogni relazione tra entit e lista di attributi della relazione LANALISI DATI iterativa: nella prima fase si individua lo schema concettuale in base allanalisi del sistema di alto livello; poi lo schema concettuale si affina grazie alle ulteriori specifiche che si aggiungono nel processo produttivo.

41

INTEGRAZIONE DATI-FUNZIONE Input: Specifiche funzionali Output: Matrice dati-funzioni; dove: 1. Le righe della matrice evidenziano le transazioni del sistema 2. Le colonne della matrice evidenziano e descrivono le entit e le relazioni 3. Le caselle di incrocio della matrice indicano il tipo di accesso allentit o alla relazione (I=insert, R=read, U=update, D=Delete)

LANALISI DATI iterativa: nella prima fase si individua lo schema concettuale in base allanalisi del sistema di alto livello; poi lo schema concettuale si affina grazie alle ulteriori specifiche che si aggiungono nel processo produttivo.

42

DISEGNO LOGICO Input: Schema concettuale Matrice Dati-Funzione Specifiche funzionali

Output: Schema logico 1. Descrizione in DDL delle tabelle 2. Descrizione delle chiavi (pk, fk, indici) 3. Descrizione dei vincoli di integrit dei campi e delle relazioni
Anche il Disegno Logico iterativo

43

DISEGNO FISICO Input: Schema Logico Specifiche funzionali Specifiche di dettaglio Esigenze prestazionali Esigenze di operativit di esercizio (svecchiamento dati, etc)

Output:
1. Descrizione in DDL di particolari indici, partizionamento, dimensionamenti di oggetti del DB e del DBMS (memoria, parametri di sistema, etc) 2. Creazione trigger, funzioni e procedure 3. Implementazione di store-procedure (PL-SQL, etc) che implementino delle funzionalit, sia ad utilizzo del sw del sistema, sia come job automatico del DBMS 4. Analisi delle query (EXPLAIN) e loro ottimizzazione 5. Tuning del database, dei volumi e delle transazioni Anche il Disegno Fisico iterativo. . In queste fasi sono molto importanti strumenti di sviluppo e test (editor, test dei dati, di EXPLAIN etc )

44

Tutto quello finora esaminato il cosiddetto processo forward, cio che nasce dallanalisi e ci permette di arrivare allo schema fisico. A supporto della metodologia necessario avere strumenti di modellazione che consentino anche di produrre automaticamente le DDL in base al DBMS scelto (es: TOAD Data Modeler per Oracle o altri Open Source). Questo permette lanalista di concentrarsi sul modello e se, lo stesso modello viene passato al DBA (DataBase Administrator), questultimo dettagliando il tutto in grado a partire dal modello di prodursi le DDL. Spesso serve fare il processo di reverse di uno schema fisico presente in produzione, oppure il reverse a fine degli sviluppi per ridocumentare il tutto. Anche qui conviene avere strumenti che lo consentano (ad esempio Toad Data Modeler).