Sei sulla pagina 1di 82

2011

BASI DI DATI

Appunti Teoria

Michele Mariani
Università degli Studi di Milano
Appunti di teoria presi da me dalle slide di Basi di dati fornite dalla professoressa Castano nell’anno
accademico 2011/12
Sommario
1 BASI DI DATI ........................................................................................................................................ 7
1.1 INFORMAZIONE ...................................................................................................................................... 7
1.2 DATO ...................................................................................................................................................... 7
1.3 DBMS ...................................................................................................................................................... 7
FUNZIONALITA’......................................................................................................................................... 7
APPROCCIO BD VS FS ................................................................................................................................ 7
1.4 ATTORI .................................................................................................................................................... 8
2 CONCETTI E ARCHITETTURA DI UN SISTEMA DI BASI DI DATI ................................................................. 9
2.1 MODELLO DEI DATI ................................................................................................................................. 9
TIPI DI MODELLO ...................................................................................................................................... 9
2.2 SCHEMA DELLA BASE DI DATI ............................................................................................................... 10
2.3 INSIEME DELLE ISTANZE ....................................................................................................................... 10
2.4 LIVELLI DI ASTRAZIONE ......................................................................................................................... 10
2.5 INDIPENDENZA DEI DATI ...................................................................................................................... 10
2.6 LINGUAGGI PER BD ............................................................................................................................... 11
2.7 TRANSAZIONI........................................................................................................................................ 11
2.8 COMPONENTI DBMS ............................................................................................................................ 11
2.9 ARCHITETTIURA DBMS ......................................................................................................................... 11
CENTRALIZZATA ...................................................................................................................................... 11
DISTRIBUITA ........................................................................................................................................... 12
2.10 CLASSIFICAZIONE DBMS ..................................................................................................................... 13
2.11 EVOLUZIONE DBMS ............................................................................................................................ 13
3 MODELLO RELAZIONALE .................................................................................................................... 15
3.1 BD RELAZIONALE .................................................................................................................................. 15
RELAZIONE MATEMATICA ...................................................................................................................... 15
RAPPRESENTAZIONE TABELLARE ............................................................................................................ 15
LIVELLO INTENSIONALE .......................................................................................................................... 16
3.2 INFORMAZIONE ICOMPLETA ................................................................................................................ 16
3.3 CHIAVE.................................................................................................................................................. 16
CHIAVE PRIMARIA .................................................................................................................................. 16
3.4 VINCOLI DI INTEGRITÀ .......................................................................................................................... 17
TIPI DI VINCOLI ....................................................................................................................................... 17

1
3.5 PRIMA FORMA NORMALE .................................................................................................................... 17
TIPI DI ATTRIBUTI:................................................................................................................................... 17
4 ALGEBRA RELAZIONALE ..................................................................................................................... 19
4.1 OPERATORI ........................................................................................................................................... 19
OPERATORI INSIEMISTICI........................................................................................................................ 19
OPERATORI UNARI.................................................................................................................................. 20
OPERATORI BINARI ................................................................................................................................. 20
4.2 OTTIMIZZAZIONI DELLE INTERROGAZIONI............................................................................................ 22
QUERY TREE............................................................................................................................................ 22
EURISTICHE DI TRASFORMAZIONE ......................................................................................................... 22
REGOLE DI TRASFORMAZIONE ............................................................................................................... 22
USO DI EURISTICHE PER OTTIMIZZAZIONE DI QUERY ............................................................................. 22
4.3 ESERCIZI ................................................................................................................................................ 23
SOLUZIONI .............................................................................................................................................. 23
5 LINGUAGGIO SQL .............................................................................................................................. 25
5.1 INTERROGAZIONI.................................................................................................................................. 25
WHERE.................................................................................................................................................... 25
SELECT .................................................................................................................................................... 25
ALIAS DI RELAZIONE ............................................................................................................................... 26
JOIN INTERNI ED ESTERNI ....................................................................................................................... 26
VALORI NULLI ......................................................................................................................................... 27
ORDINAMENTO DEL RISULTATO ............................................................................................................. 27
OPERATORI AGGREGATI ......................................................................................................................... 28
RAGGRUPPAMENTI ................................................................................................................................ 28
INTERROGAZIONI DI TIPO INSIEMISTICO ................................................................................................ 29
INTERROGAZIONI NIDIFICATE ................................................................................................................. 29
5.2 MANIPOLAZIONE DEI DATI ................................................................................................................... 31
INSERIMENTO ......................................................................................................................................... 31
MODIFICA ............................................................................................................................................... 31
CANCELLAZIOONE .................................................................................................................................. 31
VISTE....................................................................................................................................................... 32
TRIGGER E BASI DI DATI ATTIVE.............................................................................................................. 33
6 PROGETTAZIONE DI BASI DI DATI RELAZIONALI .................................................................................. 35
6.1 RACCOLTA E ANALISI DEI REQUISITI ..................................................................................................... 35
6.2 PROGETTAZIONE .................................................................................................................................. 35
2
NELLA PROGETTAZIONE DI BD ................................................................................................................ 35
6.3 ASTRAZIONE ......................................................................................................................................... 35
ASTRAZIONE DI CLASSIFICAZIONE .......................................................................................................... 36
ASTRAZIONE DI AGGREGAZIONE ............................................................................................................ 36
ASTRAZIONE DI GENERALIZZAZIONE ...................................................................................................... 36
7 MODELLO ENTITÀ RELAZIONE (ER) ..................................................................................................... 37
7.1 COSTRUTTI FONDAMENTALI ................................................................................................................ 37
TIPO DI ENTITÀ ....................................................................................................................................... 37
ENTITÀ .................................................................................................................................................... 37
TIPI DI ASSOCIAZIONE............................................................................................................................. 37
ASSOCIAZIONE ........................................................................................................................................ 37
ATTRIBUTO ............................................................................................................................................. 38
CARDINALITÀ DELLE ASSOCIAZIONE ....................................................................................................... 38
CARDINALITÀ DEGLI ATTRIBUTI .............................................................................................................. 39
IDENTIFICATORE ..................................................................................................................................... 39
GERARCHIE ............................................................................................................................................. 40
ATTRIBUTI COMPOSTI ............................................................................................................................ 41
7.2 DOCUMENTAZIONE DI SCHEMI E-R ...................................................................................................... 41
8 RACCOLTA DEI REQUISITI ................................................................................................................... 43
8.1 FONTI .................................................................................................................................................... 43
8.2 REGOLE GENERALI ................................................................................................................................ 43
9 PROGETTAZIONE CONCETTUALE ........................................................................................................ 45
9.1 GENERAZIONE DI UNO SCHEMA ........................................................................................................... 45
STRATEGIA TOP-DOWN .......................................................................................................................... 45
STRATEGIA BOTTOM-UP......................................................................................................................... 46
STRATEGIA INSIDE-OUT .......................................................................................................................... 47
STRATEGIA MISTA................................................................................................................................... 47
9.2 QUALITÀ DI UNO SCHEMA CONCETTUALE ........................................................................................... 48
LEGGIBILITÀ ............................................................................................................................................ 48
MINIMALITÀ ........................................................................................................................................... 48
COMPLETEZZA ........................................................................................................................................ 48
CORRETTEZZA ......................................................................................................................................... 48
9.3 PROGETTAZIONE DI TRANSAZIONI ....................................................................................................... 48
10 PROGETTAZIONE LOGICA ................................................................................................................. 49
10.1 ATTIVITÀ ............................................................................................................................................. 49
3
RISTRUTTURAZIONE DI SCHEMI ER ......................................................................................................... 49
GENERAZIONE DELLO SCHEMA RELAZIONALE ........................................................................................ 53
10.2 NORMALIZZAZIONE DI SCHEMI RELAZIONALI..................................................................................... 57
LE FORME NORMALI ............................................................................................................................... 57
PRIMA FORMA NORMALE ...................................................................................................................... 57
RIDONDANZA ......................................................................................................................................... 57
DIPENDENZA FUNZIONALE(FD) .............................................................................................................. 58
SECONDA FORMA NORMALE ................................................................................................................. 58
DIPENDENZA FUNZIONALE TRANSITIVA ................................................................................................. 59
TERZA FORMA NORMALE ....................................................................................................................... 59
FORMA NORMALE DI BOYCE-CODD ....................................................................................................... 60
11 PROGETTAZIONE FISICA ................................................................................................................... 63
11.1 MEMORIZZAZIONE FISICA DEI DATI .................................................................................................... 63
11.2 ORGANIZZAZIONI PRIMARIE E SECONDARIE ...................................................................................... 63
11.3 INDICI.................................................................................................................................................. 63
ACCESSO CON INDICE ............................................................................................................................. 64
INDICI SPARSI E DENSI ............................................................................................................................ 64
INDICI PRIMARI E SECONDARI ................................................................................................................ 64
INDICI MULTI-LIVELLO ............................................................................................................................ 65
INDICI IN SQL .......................................................................................................................................... 66
PROGETTAZIONE FISICA DI BD ................................................................................................................ 66
SCELTA DI INDICI PER RELAZIONI ............................................................................................................ 66
INDICI PER RELAZIONI............................................................................................................................. 66
PROGETTAZIONE FISICA DI BD ................................................................................................................ 67
12 SICUREZZA DELLE BASI DI DATI......................................................................................................... 69
12.1 OBIETTIVI ............................................................................................................................................ 69
12.2 TECNICHE DI SICUREZZA ..................................................................................................................... 69
CONTROLLO DELL’ACCESSO .................................................................................................................... 69
12.3 MODELLI PER IL CONTROLLO DELL’ACCESSO A BASI DI DATI RELAZIONALI ........................................ 74
MODELLO DI AUTORIZZAZIONE DEL SYSTEM R ...................................................................................... 74
OPERAZIONE DI GRANT .......................................................................................................................... 74
CATALOGHI SYSAUTH E SYSCOLAUTH .................................................................................................... 75
OPERAZIONE REVOKE ............................................................................................................................. 76
AUTORIZZAZIONE SU VISTE .................................................................................................................... 78
SICUREZZA NEI DBMS COMMERCIALI ..................................................................................................... 78
4
13 TRANSAZIONI .................................................................................................................................. 79
13.1 PROPRIETÀ.......................................................................................................................................... 79
ATOMICITÀ ............................................................................................................................................. 79
CONSISTENZA ......................................................................................................................................... 80
ISOLAMENTO .......................................................................................................................................... 80
PERSISTENZA .......................................................................................................................................... 80
13.2 GESTIONE ........................................................................................................................................... 80

5
6
1 BASI DI DATI
Una base di dati è una collezione di dati che rappresentano le informazioni relative a una realtà di interesse
Rappresenta una determinata realtà di interesse detta Universo del discorso: i dati contenuti devono essere
sempre aggiornati.

1.1 INFORMAZIONE
Tutto ciò che produce variazioni nel patrimonio conoscitivo di un soggetto.

1.2 DATO
Registrazione della descrizione di una qualsiasi caratteristica della realtà su un supporto che ne garantisce
la conservazione, comprensibilità, reperibilità
Informazione = dato + contesto interpretativo

1.3 DBMS
Software che supporta la
 Definizione
o Specificare tipi, strutture e vincoli
 Costruzione
o Popolare la BD
 Manipolazione
o Interrogazione
o Aggiornamento
o Generazione di report
 Condivisione
o Accesso contemporaneo da parte di più utenti
di Basi di dati

Fornisce un contesto interpretativo ai dati, trasformandoli in informazioni

FUNZIONALITA’
 Gestione delle interrogazioni
o Fornisce linguaggi e funzionalità per la formulazione di interrogazioni di alto
livello (query)
o Assicura l’esecuzione efficiente delle query collegando tra loro i dati nei diversi
file su disco
 Accesso efficiente a grandi quantità di dati persistenti
 Gestione delle transazioni
o Controllo della concorrenza per garantire che transazioni concorrenti operino
correttamente sui dati
o Funzionalità di salvataggio e ripristino per garantire che non ci siano perdite di
dati

APPROCCIO BD VS FS
 Struttura BD è memorizzata separatamente dai programmi del catalogo (indipendenza
tra programmi e dati)
 BD condivisa da molteplici programmi applicativi
 BD ha molti utenti
 DBMS realizza
o Controllo della concorrenza
o Controllo dell’affidabilità

7
1.4 ATTORI
 Amministratore
o Autorizzare l’accesso alla BD
o Coordinare e monitorare l’uso
o Manutenere il sistema BD
 Progettista
o Individuare i dati da memorizzare
o Scegliere le strutture adeguate
o Comunicare con gli utenti finali per comprenderne le esigenze
 Analista e programmatore
o Sviluppare le specifiche per le necessarie transazioni
o Realizzare, testare, documentare e manutenere i programmi che implementano le
specifiche
 Utenti finali
o Usare sistematicamente la base di dati attraverso le transazioni
 Utenti occasionali
o Richieste non predefinite
o Interfacce grafiche di facile uso

8
2 CONCETTI E ARCHITETTURA DI UN SISTEMA DI BASI DI DATI

2.1 MODELLO DEI DATI


 Insieme di costrutti utilizzati per definire la struttura dei dati
 una notazione per specificare i dati tramite i costrutti del modello
 Insieme di operazioni per interrogare e manipolare i dati secondo quel modello

L’uso di un modello dei dati nei DBMS è il mezzo attraverso il quale si realizza l’astrazione dei dati,
nascondendo agli utenti i dettagli sulla loro memorizzazione fisica

Qualsiasi modello possiede 2 aspetti fondamentali


 Come rappresentare oggetti
 Come rappresentare legami

TIPI DI MODELLO
 Modello gerarchico: uso di strutture ad albero (anni ’60)
 Modello reticolare: uso di grafi (inizio anni ’70)
 Modello ad oggetti: estende alle BD il paradigma della programmazione ad oggetti
(anni ‘90)
 Modello object-relational (relazionale-a oggetti): estensione del modello relazionale
con alcune caratteristiche dei modelli a oggetti
 Modello Relazionale (anni ’70 ’80)

9
MODELLO RELAZIONALE
E’ basato su un singolo costrutto, la relazione.
 Una relazione consente di organizzare i dati in insiemi di record a struttura fissa.
 Una relazione può essere vista come una tabella in cui
o le righe rappresentano i singoli record
o le colonne corrispondono ai campi del record
o l’ordine delle righe/colonne è irrilevante

2.2 SCHEMA DELLA BASE DI DATI


Descrizione delle caratteristiche dei dati facendo uso di un modello dei dati

Lo schema fornisce una descrizione intensionale del contenuto della base di dati ( invariante nel tempo)

1) La definizione dello schema è il primo passo dello sviluppo di una vasi di dati

2.3 INSIEME DELLE ISTANZE


L’insieme dei dati presente in un dato momento in una base di dati
L’insieme delle istanze è variabile nel tempo per riflettere tutti gli aggiornamenti apportati. La BD ha uno
stato corrente.
Il DBMS garantisce che ogni stato sia valido, ovvero verifichi struttura e vincoli specificati nello schema.

2) L’inserimento dei dati nella base di dati rappresenta il passo successivo nello sviluppo di una base di
dati.

2.4 LIVELLI DI ASTRAZIONE


 Schema Logico
o descrizione dell’intera BD per mezzo del modello logico dei dati
 Schema Fisico
o Descrizione dello schema logico per mezzo di strutture fisiche di memorizzazione e di
accesso
 Schema Esterno o Vista
o porzione dell’intera base di dati limitata ai dati che costituiscono la specifica visione di
singoli utenti o gruppi di utenti
o Possono essere definite più viste di una stessa base di dati.

per accedere ai dati non è necessario conoscere le strutture fisiche stesse.


Il DBMS mantiene anche le corrispondenze (o mapping) fra gli schemi dei 3 livelli.

2.5 INDIPENDENZA DEI DATI


 Indipendenza fisica
o Consente di interagire con il DBMS in modo indipendente dalla struttura fisica dei dati.
 Indipendenza logica
o Interazione a livello esterno indipendentemente dal livello logico.

10
2.6 LINGUAGGI PER BD
 DDL
o Definizione schemi logici, esterni e le autorizzazioni di accesso ai dati
 DML
o Interrogazione e aggiornamento delle istanze della base di dati
o Supporta operazioni di:
 Ricerca
 Inserimento
 Cancellazione
 Aggiornamento
L’accesso può avvenire mediante
 Linguaggi testuali interattivi (SQL)
 Interfacce amichevoli (phpPgAdmin)
 Comandi come quelli del linguaggio interattivo immersi (C,C++)

2.7 TRANSAZIONI
Rappresenta la tipica unità di lavoro di un DBMS a cui si vogliono associare caratteristiche di correttezza,
robustezza e isolamento
I DBMS sono sistemi transazionali ovvero mettono a disposizione un meccanismo per al definizione e
l’esecuzione di transazioni
Nell’esecuzione devono essere garantite proprietà ACIDe (Atomicità, Consistenza, Isolamento, Durabilità)

2.8 COMPONENTI DBMS


 Ottimizzatore: seleziona la strategia di accesso ai dati
 Gestore accesso ai dati: esegue la strategia
 Gestore buffer: gestisce gli accessi alle pagine
 Sottosistema di recovery: gestisce i malfunzionamenti
 Sottosistema di controllo della concorrenza: gestisce le interferenze nell’accesso concorrente
ai dati

2.9 ARCHITETTIURA DBMS


 Centralizzata
 Distribuita
o 2 tier
o 3 tier

CENTRALIZZATA
Mainframe + terminali
Tutte le funzionalità del DBMS eseguite su una sola macchina dove risiedono anche il DBMS e i
programmi applicativi.
Vantaggi: gestibile da un amministratore centrale
Svantaggi: la gestione dell’interfaccia grafica sottrae potenza di calcolo alla gestione della BD

11
DISTRIBUITA
 Processo client:
o richiede servizi;
o dedicato a interagire con l’utente finale;
o ruolo attivo perché genera richieste di servizi.
 Processo server:
o offre servizi;
o reattivo perché svolge una computazione solo a seguito di una richiesta da parte di
un qualunque client.
o Ogni processo server può rispondere a (molte) richieste da parte di processi client.

Interazione Client-Server richiede la definizione di una interfaccia di servizi che elenca i servizi messi
a disposizione dal server

MACCHINE:
 Macchina client:
o adatta all’interazione con l’utente.
o Generalmente si utilizza un PC dotato di strumenti per office automation con le
applicazioni che richiedono l’uso della BD;
o collegate ai server attraverso una rete di comunicazione (e.g., LAN, WAN)
 Macchina server (DBMS server, database server):
o adatta per le funzionalità transazionali e di interrogazione;
o dimensionato in funzione dei servizi che deve offrire e del carico transazionale
o Ampia memoria principale (gestione dei buffer) e dispositivi di memoria di massa
ad elevata capacità (per memorizzare tutta la BD)

Client e server non per forza su macchine diverse

TWO-TIER
 Thin
o Client ha funzione di interfaccia
o Server gestione dell’applicazione e gestione dei dati
 Thick
o Client funzione di interfaccia e gestione dell’applicazione
o Server gestione dati

THREE-TIER
 2 server e 1 client
o Client si occupa solo dell’interfaccia
o Application server responsabile della gestione della applicazione
o Server per la gestione dei dati

Architettura tipica delle applicazioni Web

Caratteristiche:
 Interconnessione di sistemi eterogenei
 I client sono thin (browser web)
 Integrazione dei dati gestita nel livello intermedio (resta il problema
metodologico del “come”)
 Scalabilità: si possono aggiungere anche macchine a livello intermedio
(impossibile nel caso thick client)
 Riuso

12
2.10 CLASSIFICAZIONE DBMS
 Modello dei dati:
o DBMS relazionali
o DBMS object-relational
o DBMS Object-Oriented
o DBMS reticolari
o DBMS gerarchici
 Numero di utenti:
o DBMS mono-utente (tipicamente su PC)
o DBMS multi-utente (più utenti concorrentemente)
 Numero di siti su cui la BD è distribuita:
o BD centralizzata: tutta la BD risiede su un solo server
o BD distribuita: la BD risiede su molteplici server; le transazioni coinvolgono più server

2.11 EVOLUZIONE DBMS


 ANNI ’60: DBMS commerciali gerarchici e reticolari
 1970: modello relazionale (Codd) a superamento dei limiti dei modelli dei dati precedenti
 ’70/’80: DBMS relazionali commerciali
 1990: i DBMS relazionali sono uno standard aziendale
 ’80/’90: DBMS ad oggetti
 Dal 1990 ad oggi: continua evoluzione della tecnologia basi di dati in molteplici direzioni

13
14
3 MODELLO RELAZIONALE
Proposto da E. F. Codd nel 1970 per favorire l’indipendenza dei dati
Basato sulla nozione di relazione matematica, intesa come sottoinsieme del prodotto cartesiano di due o
più insiemi di dati detti domini
Definisce un insieme di vincoli sui dati ed è associato al linguaggio denominato algebra relazionale

Relazione come base matematica


Tabella come struttura dati per rappresentare le relazioni

3.1 BD RELAZIONALE
Una BD è rappresentata come una collezione di tabelle
Ogni tabella ha un unico nome
 Ogni colonna ha associato un nome distinto di attributo ; per ogni c’è un insieme di
possibili valori detto dominio
 Ogni riga è una ennupla ordinata di valori ( )con appartenente al dominio del
corrispondente attributo

RELAZIONE MATEMATICA
Una relazione matematica su è un sottoinsieme del prodotto cartesiano

sono i domini della relazione. Una relazione su n domini ha grado n


Il numero di ennuple è la cardinalità della relazione

RAPPRESENTAZIONE TABELLARE
Si associa ad ogni occorrenza di dominio nella relazione un nome univoco detto attributo che descrive il
ruolo del dominio nella relazione
Una ennupla su un insieme di attributi X è una funzione che associa a ciascun attributo A in X un valore
del dominio associato all‘attributo A

 I valori di ciascuna colonna sono fra loro omogenei: i valori di un attributo appartengono allo
stesso dominio
 Le righe sono diverse fra loro: una relazione non contiene mai ennuple identiche (orientamento
ai valori:)
o I riferimenti fra i dati in relazioni diverse sono rappresentati per mezzo di valori dei
domini che compaiono nelle ennuple
 L‘ordinamento delle colonne è irrilevante poiché esse sono sempre identificate per nome e non
per posizione
 L‘ordinamento delle righe è irrilevante poiché sono identificate per contenuto e non per
posizione

15
LIVELLO INTENSIONALE
 Schema di relazione
( )
o Un nome di relazione R e un insieme di attributi
 Schema di base di dati
* ( ) ( )+
o Insieme di schemi di relazioni
 Istanza di relazioni su uno schema R(X)
o Insieme r di ennuple su X
 Istanza di base di dati su uno schema
* ( ) ( )+
o Insieme di relazioni * + con relazioni su

3.2 INFORMAZIONE ICOMPLETA


Valore NULL denota l’assenza di un valore del dominio
Non è un valore del dominio, indica solo che il valore
 Sconosciuto
 Inesistente
 Senza informazione

Vanno evitati, se il numero è eccessivo bisogna porsi dubbi sulla significatività e sull’identità delle tuple
nella relazione

3.3 CHIAVE
Insieme di attributi che identificano univocamente le ennuple di una relazione

Un insieme K di attributi è detto superchiave per una relazione r se r non contiene ennuple distinte
con , - , -
K è una chiave per r se è una superchiave minimale per r (cioè non contiene altre superchiavi)

Una relazione non può contenere ennuple distinte ma uguali


Ogni relazione ha come superchiave l’insieme degli attributi su cui è definita e quindi ha (almeno) una
chiave
Una relazione può avere più chiavi, dette chiavi candidate

L’esistenza delle chiavi garantisce l’accessibilità a ciascun dato della base di dati

La presenza di valori nulli nelle chiavi deve essere limitata

CHIAVE PRIMARIA
Una relazione può avere più chiavi candidate (ne ha almeno una)
E’ opportuno che almeno una chiave consenta di identificare univocamente OGNI ennupla della
relazione e quindi non ammetta valori nulli (vincolo di entity integrity)
Chiave primaria: chiave su cui non sono ammessi valori nulli

16
3.4 VINCOLI DI INTEGRITÀ
Proprietà che deve essere soddisfatta dalla istanze che rappresentano informazioni corrette per
l’applicazione
Il vincolo è una funzione booleana che associa ad ogni istanza il valore vero o falso

TIPI DI VINCOLI
 Vincoli intrarelazionali
o Vincoli su valori (o di dominio)
o Vincoli di ennupla
 Vincoli interrelazionali (o di chiave)

VINCOLI DI ENNUPLA
Esprimono condizioni sui valori di ciascuna ennupla, indipendentemente dalle altre ennuple

VINCOLI DI DOMINIO
Vincoli di ennupla che coinvolgono un solo attributo

VINCOLI INTERRALAZIONALI
Un vincolo di integrità referenziale (“foreign key”) fra gli attributi X di una relazione e un’altra
relazione impone ai valori su X in di comparire come valori della chiave primaria di

Questo perché:
Informazioni in relazioni diverse sono correlate attraverso valori comuni
 in particolare, valori delle chiavi (primarie)

3.5 PRIMA FORMA NORMALE


Uno schema di relazione R(X) è detto in prima forma normale (1NF o “flat”) se ogni
attributo appartenente a X è un attributo semplice.
 Altrimenti lo schema è in forma strutturata o “nested”.

TIPI DI ATTRIBUTI:
 Attributo semplice: a valori atomici
 Attributo multivalore: in cui un possibile valore è un insieme di valori
o Esame---> {Sistemi, Analisi, Fisica}
 Attributo strutturato: in cui un possibile valore è una ennupla di valori
o DatiEsame ---> <Sistemi, Rossi, 25>

Nel modello relazionale la 1NF deve essere garantita per ogni relazione che risulta così semplice da
interpretare e da gestire

17
18
4 ALGEBRA RELAZIONALE
Linguaggio procedurale per interrogazioni di BD relazionali.
 Il risultato di un’interrogazione è una relazione che può essere manipolata utilizzando gli operatori
dell’algebra stessa

4.1 OPERATORI
OPERATORI INSIEMISTICI

UNIONE ( )
insieme delle ennuple appartenenti a r OR a s.

Compatibilità all’unione
( ) ( )sono compatibili all’unione se
1) R e S hanno lo stesso grado
2) ( ) ( ) per ogni i = 1, … , n

DIFFERENZA ( )
r-s : insieme delle ennuple appartenenti a r AND NOT a s.

INTERSEZIONE ( )
insieme delle ennuple appartenenti a r AND a s.

RIDENOMINAZIONE (Ρ)
Operatore che cambia il nome degli attributi nelle interrogazioni (contenuto delle relazioni
inalterato)
ρNuovoNome ←Nome(R)

19
OPERATORI UNARI

SELEZIONE ( )
Restituisce una relazione contenente l’insieme delle ennuple della relazione operando che
soddisfano particolari condizioni, espresse mediante una formula proposizionale(uso costanti, nomi
di attributo, operatori di confronto e connettivi logici AND, OR, NOT)
Chiamata anche decomposizione orizzontale

PROIEZIONE ( )
Restituisce come risultato una relazione contenente l’insieme delle ennuple della relazione
operando limitate su particolari attributi.
Chiamata anche decomposizione verticale

OPERATORI BINARI
r definita su R(X) e s definita su S(Y), con intersezione tra X e Y vuota

PRODOTTO CARTESIANO ( )
Relazione definita su XY contenente l’insieme delle ennuple che sono combinazione delle ennuple
di r e s.

In generale è necessario operare una selezione sul risultato del prodotto cartesiano per selezionare
un sottoinsieme significativo di tuple.

È meglio dunque usare le operazioni di JOIN

20
THETA-JOIN ( )
r definita su R(X) e s definita su S(Y), con X e Y disgiunti.
θ-JOIN è una relazione definita su XY composta dalle ennuple risultato della concatenazione di
ennuple di r con ennuple di s che soddisfano le condizioni di confronto A B (A appartiene a X e B
appartiene a Y).
θ è un operatore di confronto (=, ≠, <, ≤, >, ≥)
Se il confronto è di uguaglianza, si chiama EQUIJOIN.

JOIN NATURALE ( )
r definita su R(YX) e s definita su S(XZ)
JOIN NATURALE di r e s è una relazione definita su YXZ composta dalle ennuple risultato della
concatenazione di ennuple di r con ennuple di s con valori identici sugli attributi X.
Due ennuple sono dette joinabili se contribuiscono al join.
Una ennupla che non contribuisce al join è detta dangling.
Un join è completo se nessuna delle relazioni contiene ennuple dangling.
È commutativo e associativo.
Può essere espresso in termini
 Prodotto cartesiano.
 Selezione ennuple con valori uguali per attributi in comune.
 Proiezione su attributi di r e s eliminando duplicazioni.

OUTER JOIN
Appende alle ennuple risultato del join anche quelle ennuple di una o entrambe le relazioni che non
soddisfano i criteri di join, estendendole con opportuni ‘NULL’.
 LEFT OUTER JOIN: considera solo la relaz. di sx
 RIGHT OUTER JOIN: considera solo la relaz. di dx
 FULL OUTER: considera entrambe le relazioni

DIVISIONE ( )
r su R(X) e s su S(Y)
Y ≠ ∅, Y ⊆X
Z = X – Y (insieme degli attributi di R che non sono attributi di S)
Quindi una r-tupla di R ha la forma
Chiamiamo z-tupla e s-tupla
r ÷ s è una relazione T(Z) costituita dalle z-tuple di r tale che per ogni s-tupla di s, la tupla è
in r.
21
4.2 OTTIMIZZAZIONI DELLE INTERROGAZIONI
QUERY TREE
Struttura dati ad albero che corrisponde a un’espressione algebrica
 Relazioni input alla query: nodi foglia
 Operatori dell’ algebra: nodi interni

Un’esecuzione dell’albero consiste nell’eseguire il nodo interno (i.e., l’operatore) quando i suoi
operandi sono disponibili e nel sostituire al nodo interno la relazione risultato dell’esecuzione
dell’operatore.

L’euristica principale consiste nell’applicare prima le operazioni che riducono la dimensione dei
risultati intermedi

EURISTICHE DI TRASFORMAZIONE
 Atomizzazione delle selezioni

Una selezione congiuntiva può essere sostituita da una serie di selezioni atomiche (preliminare
ad altre)
 Commutatività di

 Idempotenza delle proiezioni

REGOLE DI TRASFORMAZIONE
 Anticipazione della selezione rispetto al join

 Conversione di una sequenza ( , X ) in un join

 Anticipazione della proiezione rispetto al join

In sintesi, si possono eliminare subito gli attributi di ciascuna relazione che non sono coinvolti
nel join e non sono utilizzati nella lista degli attributi della proiezione.

USO DI EURISTICHE PER OTTIMIZZAZIONE DI QUERY


 Decomporre operazioni di selezione con condizioni congiuntive in cascate di operazioni di
select.
 Spingere il più in basso possibile ciascuna selezione (compatibilmente con gli attributi coinvolti
nella condizione).
 Riorganizzare i nodi foglia in modo che i nodi foglia con le condizioni di selezione più restrittive
siano eseguiti per primi (uso di regole di commutatività e associatività).
 Trasformare un prodotto cartesiano seguito da una selezione in un’operazione di join.
 Utilizzare le regole relative alla cascata di proiezioni e alla commutatività della proiezione con
altre operazioni per spingere il più in basso possibile le proiezioni (creando proiezioni se
necessario)

22
4.3 ESERCIZI

PRESIDENTE( NomeP, DataN, DataM, Partito, NomeMoglie, NomeStato )


CONGRESSO( NumCong, %SR,%SD,%CR, %CD )
AMMINISTRAZIONE( NumAmm, DataInsed, NomeVicePres, NomeP, DataN )
ELEZIONE( Anno, NomePerd, VotiPerd, PartitoPerd, VotiVinc, NomeP,DataN )
STATO( NomeStato, #Abit, #Votanti, NumAmm )
PARTECIPA( NomeP, DataN, NumCong )

1) Trovare lo stato di provenienza del presidente Kennedy.


2) Trovare gli anni in cui è stato eletto un presidente repubblicano dell’Illinois.
3) Nomi di tutti i presidenti texani che sono anche nomi di vicepresidenti dopo il 1950.
4) Nomi delle mogli dei presidenti provenienti dalla California eletti dopo il 1960.
5) Nomi di persone che hanno partecipato a elezioni presidenziali.
6) Data di morte del presidente dell’anno in cui la California fu ammessa negli Stati Uniti.
7) Percentuale dei repubblicani al Senato e alla Camera dei congressi tenuti da presidenti repubblicani
eletti dopo il 1945.

SOLUZIONI
1)

2)

3)

4)

5)

6)

7)

23
24
5 LINGUAGGIO SQL

5.1 INTERROGAZIONI

SELECT Lista Attributi


FROM Lista Tabelle
[WHERE Condizione]

SELECT: nomi di attributo degli attributi target i cui valori devono essere reperiti con la query
FROM: nomi di relazioni su cui la query deve essere valutata
WHERE: espressione (booleana) di ricerca che identifica le ennuple che dovranno far parte del
risultato della query

WHERE
Espressioni booleane costruite combinando predicati semplici mediante operatori logici AND, OR,
NOT (come in algebra)
 AND: selezione delle righe che rendono veri tutti i predicati
 OR: selezione delle righe per cui almeno un predicato è vero
 NOT: unario, inverte il valore di verità del predicato

ALTRI OPERATORI:
 [ NOT ] BETWEEN a AND b
 [ NOT ] IN (lista valori)
 IS [ NOT ] NULL
 [ NOT ] LIKE ‘pattern’ (matching di stringhe)
Nella specifica del pattern:
o _ rappresenta un carattere arbitrario
o % rappresenta una stringa di lunghezza arbitraria (anche 0 caratteri)

 [NOT] EXISTS

SELECT
 SELECT * (prendi tutti gli attributi)
 SELECT Nome, Cognome
 SELECT DISTINCT Indirizzo (eliminazione dei duplicati)
 SELECT Stipendio*1.1 AS NuovoStipendio (ridenominazione attributi)
 SELECT SUM(Stipendio)

25
ALIAS DI RELAZIONE

Gli alias di relazione possono essere interpretati come variabili, che assumono valori su intere
tabelle
 Imp rappresenta gli impiegati
 Smith rappresenta gli impiegati di nome Smith

JOIN INTERNI ED ESTERNI


 Sintassi per la specifica di join introdotta in SQL-2 che permette di distinguere le condizioni di
join dalle altre condizioni
 Le condizioni di join appaiono nella clausola FROM associate alle tabelle che partecipano al join
 Tipi di join
o (INNER) JOIN(interno, default coincide con il theta-join)
o NATURAL JOIN(join naturale)
o RIGHT, LEFT, FULL OUTER JOIN (join esterni)

JOIN
La condizione da imporre è l’uguaglianza dei valori di chiave esterna di Dipartimento e corrispondente
chiave primaria di Impiegato (equijoin)

 Tutte le tabelle coinvolte nel JOIN sono esplicitate nella clausola FROM
 Sul prodotto cartesiano di tali tabelle si applicano le condizioni specificate in WHERE
 Le condizioni del JOIN sono scritte in modo esplicito nella WHERE (uso dei valori di chiave
esterna per collegare tuple di tabelle diverse e combinare i loro dati nel risultato)

NATURAL JOIN
Nell’operazione NATURAL JOIN di due relazioni non viene specificata alcuna condizione di join.
•  Viene applicata una condizione implicita di equijoin per ciascuna coppia di attributi con lo stesso
nome nelle due relazioni.
•  Ogni coppia di attributi di questo tipo è inclusa una sola volta nel risultato
•  Se i nomi degli attributi non sono gli stessi nelle due relazioni, si possono ridenominare per farli
corrispondere e poi applicare NATURAL JOIN

JOIN ESTERNO (OUTER JOIN)


Esegue un join mantenendo nel risultato tutte le righe che fanno parte di una o di entrambe le relazioni
coinvolte

26
LEFT (OUTER) JOIN
Fornisce come risultato il join interno esteso con le tuple della relazione che compare a sinistra del join
per le quali non esiste una corrispondente tupla nella relazione di destra

RIGHT (OUTER) JOIN


Fornisce come risultato il join interno esteso con le tuple della relazione che compare a destra del join
per le quali non esiste una corrispondente tupla nella relazione di sinistra

FULL (OUTER) JOIN


Fornisce come risultato il join interno esteso con le tuple di ciascuna relazione per le quali non esiste
una corrispondente tupla dall’altra parte

VALORI NULLI
 Introduzione di condizioni atomiche per verificare se un valore è specificato oppure è nullo
 Predicato IS NULL: selezione delle righe con valori nulli
Attributo IS NULL
 Il predicato risulta vero se l’attributo ha valore nullo
IS NOT NULL è la negazione

ORDINAMENTO DEL RISULTATO


 Ordinamento delle ennuple risultato secondo uno o più attributi specificati
ORDER BY Attributo [ASC | DESC]
{, Attributo [ASC | DESC]}

27
OPERATORI AGGREGATI
 SQL mette a disposizione un insieme di operatori aggregati per derivare valori aggregati a
partire da insiemi di tuple di relazioni.
 Principali operatori aggregati built-in dell’SQL
o COUNT cardinalità
 COUNT (< * | [ distinct | all ] > ListaAttributi )
 COUNT(*):restituisce il numero di righe
 COUNT ALL : restituisce il numero di righe che possiedono valori diversi da
NULL per gli attributi specificati
 COUNT DISTINCT ListaAttributi: restituisce il numero di valori diversi per gli
attributi specificati

o SUM sommatoria
o MAX massimo
o MIN minimo
o AVG media

o < sum | max | min | avg > ([ distinct | all ] AttrEspr )


 L’opzione distinct considera una sola volta ciascun valore
 utile solo per le funzioni sum e avg
 L’opzione all considera tutti i valori diversi da null

 Prima si esegue l’interrogazione considerando le clausole FROM e WHERE della query


 L’operatore aggregato viene applicato al risultato ottenuto

RAGGRUPPAMENTI
 Clausola GROUP BY ListaAttributi per eseguire il raggruppamento
o Necessità di applicare operatori aggregati a sottogruppi di tuple di una relazione in
base al valore di uno o più attributi
o Prima si effettua il raggruppamento e poi si applica l’operatore aggregato a ciascun
sottogruppo individuato

È sbagliato invece usarlo così:

 Clausola HAVING che specifica una condizione su un gruppo di tuple associata al valore degli
attributi di raggruppamento
28
o Esigenza di applicare gli operatori aggregati solo su raggruppamenti che verificano a
condizioni date
o Solo i raggruppamenti che soddisfano la condizione specificata nella clausola HAVING
sono inclusi nel risultato dell’interrogazione

È sbagliato invece usarlo così:

INTERROGAZIONI DI TIPO INSIEMISTICO


 UNION: arricchisce la potenza espressiva di SQL e permette di scrivere interrogazioni altrimenti
non formulabili.

 Interrogazioni con INTERSECT e EXCEPT possono essere espresse utilizzando altri costrutti del
linguaggio (v. interrogazioni nidificate).

INTERROGAZIONI NIDIFICATE
Argomento della WHERE è un predicato in cui si confronta un valore (risultato di una espressione
valutata su una singola riga) con il risultato dell’esecuzione di una query SQL interna

 Operatori ALL, ANY Per estendere i normali operatori di confronto (=,<>,>,<,>=,<=) al


problema di confrontare un singolo valore con l’insieme dei valori risultato della query
interna.
 Interrogazioni con MIN e MAX possono essere espresse mediante query nidificate.

29
SUBQUERY CORRELATE
 Negli esempi visti ogni subquery viene eseguita una sola volta l’insieme dei valori risultante
è usato per la valutazione della clausola WHERE della query esterna.
 E’ possibile definire subquery che sono eseguite ripetutamente per ogni tupla candidata
 considerata nella valutazione della query esterna.
 Ogni volta che la query esterna considera una tupla candidata, viene invocata la subquery e
viene “passato” il nome del dipartimento dell’impiegato in esame
 La subquery calcola quindi la media degli stipendi nel dipartimento che è stato passato e
restituisce tale valore alla query esterna
 La query esterna può quindi confrontare lo stipendio dell’impiegato in esame con il valore
restituito dalla subquery

EXISTS
 Il predicato EXISTS(sq)restituisce il valore booleano TRUE se la subquery restituisce almeno
un tupla; restituisce il valore booleano FALSE altrimenti
 Il predicato NOT EXISTS(sq)restituisce il valore booleano TRUE se la subquery non
restituisce alcuna tupla; restituisce il valore booleano FALSE altrimenti

DIVISIONE
 Le subquery correlate e l’operatore di NOT EXISTS sono particolarmente utili per
implementare l’operazione di divisione in SQL
 La specifica della divisione in SQL fa uso dell’operatore NOT EXISTS e richiede di ragionare
in base al concetto di controesempio.

30
5.2 MANIPOLAZIONE DEI DATI

INSERIMENTO
INSERT INTO NomeTabella [ ListaAttributi ]
VALUES (ListadiValori) | SELECTSQL

 Inserimento di singole righe

Usata per inserimento da programma con acquisizione dati utente (i.e. form).

 Inserimento di insiemi di righe

Usata per l’inserimento dati a partire da dati presenti nella BD.

MODIFICA
UPDATE NomeTabella SET
Attributo = < Espressione | SELECTSQL | NULL |
default > { , Attributo = ... }
[ WHERE Condizione ]

 Aggiornamento di uno o più attributi delle tuple di NomeTabella che verificano (se
specificata) la condizione in WHERE.
 Senza WHERE si esegue la modifica su tutte le righe.

CANCELLAZIOONE
DELETE FROM NomeTabella [ WHERE Condizione ]

 Senza WHERE: cancellazione di tutte le righe della tabella.


 Con WHERE: cancellazione selettiva di righe della tabella.
o In WHERE ci può essere una query nidificata.

31
VISTE
CREATE VIEW Nomevista [(ListaAttributi)] AS SelectSQL
[WITH [LOCAL | CASCADED] CHECK OPTION]

 Una vista in SQL è una tabella derivata a partire da altre tabelle (tabelle di base o altre
viste).
 Una Vista è una tabella virtuale: non ci sono tuple istanza della vista memorizzate nella BD
(a differenza delle tabelle definite mediante ‘CREATE TABLE’ che hanno tuple memorizzate
nella BD).

In generale, le viste sono usate per:


 Interrogazioni: la vista definisce una nuova tabella che non esiste direttamente nella BD e
che verrà utilizzata che (frequentemente) per formulare interrogazioni.
 Sicurezza: la vista definisce una tabella contenente un sottoinsieme dei dati di una o più
tabelle della BD, al fine di limitare l’accesso degli utenti a quei soli dati

INTERROGAZIONI CON VISTE

Modifica al momento dell’interrogazione


 L’interrogazione sulla vista viene modificata in un’interrogazione sulle tabelle di base su cui
la vista è definita
 Poco efficiente per viste definite tramite interrogazioni complesse

Materializzazione di viste
 Creazione di una tabella temporanea della vista quando viene eseguita per la prima volta
l’interrogazione (vista materializzata)
 Mantenimento della vista materializzata supponendo che vi saranno altre interrogazioni
 Uso di tecniche di aggiornamento incrementale per mantenere allineata la vista
materializzata rispetto ai cambiamenti in una delle tabelle di base
 Il DBMS può rimuovere una vista materializzata se non viene utilizzata per un certo periodo
di tempo.
 La vista materializzata verrà generata ex-novo quando verrà eseguita una nuova
interrogazione

32
AGGIORNAMENTO DI VISTE
 Le operazioni di aggiornamento sulle viste sono tradotte in opportuni comandi di
aggiornamento sulle tabelle di base da cui la vista è derivata
 Non sempre è possibile determinare in modo univoco come riportare l’aggiornamento sulla
vista in termini di aggiornamenti sulle tabelle di base; i problemi sorgono con viste ottenute
tramite join di più tabelle

 In generale, i sistemi considerano aggiornabili :


o Viste definite su una sola tabella che contengono la chiave primaria della tabella di
base e tutti gli attributi NOT NULL senza un valore di DEFAULT specificato
 In generale, i sistemi considerano NON aggiornabili:
o Viste definite su più tabelle con join
o Viste che usano operatori aggregati e funzioni di raggruppamento

Check option
si applica a viste aggiornabili
 Sono ammessi aggiornamenti sulle righe della vista e dopo l’aggiornamento le righe devono
continuare ad appartenere alla vista (i predicati nella clausola WHERE della definizione della
vista devono rimanere veri)
 LOCAL vs. CASCADED: profondità con cui applicare i controlli a seguito di aggiornamento
(solo ai predicati della definizione della vista più esterna oppure propagati a tutti i livelli di
definizione)

CANCELLAZIONE DI VISTE
Quando una vista non serve più viene cancellata
DROP VIEW Nomevista

TRIGGER E BASI DI DATI ATTIVE


 Trigger: regole attive, parte dello standard SQL-99
 BD con componente per la gestione di regole Evento-Condizione-Azione(regole di produzione):
o Evento: normalmente modifiche della base di dati
o Condizione: determina se la regola debba essere eseguita
o Azione: e.g., sequenza istruzioni SQL, esecuzione di programma esterno

 Le BD attive hanno comportamento reattivo(in contrasto con passivo)


o eseguono non solo le transazioni utente ma anche le regole
 I trigger “mettono a fattor comune” parte dell’applicazione che è così “condivisa”

DEFINIZIONE
Definiti con istruzioni DDL (CREATE TRIGGER)
 basati sul paradigma Evento-Condizione-Azione (ECA):
o evento: modifica dei dati (insert, delete, update)
o condizione (opzionale) predicato SQL
o azione: sequenza di istruzioni SQL (o estensioni, ad esempio PL/SQL in Oracle)
 Intuitivamente:
o quando si verifica l’evento (attivazione)
o se la condizione è soddisfatta (considerazione)
o allora esegui l’azione (esecuzione)

 Ogni trigger fa riferimento ad una tabella (target): risponde ad eventi relativi a tale tabella

33
GRANULARITÀ
  di ennupla (row-level):
o il trigger viene attivato per ogni ennupla coinvolta nell'operazione
 di operazione (statement-level):
o una sola attivazione per ogni istruzione SQL, con riferimento a tutte le ennuple
coinvolte (“set-oriented”)

MODALITÀ
 Modalità di valutazione della regola (considerazione della regola):
o immediata: il valore della condizione è valutato come parte della stessa transazione
che ha scatenato l’evento e valutato immediatamente, subito prima-before- o dopo-
after- l’evento
o differita: il valore della condizione è valutato alla fine della transazione che comprende
l’evento (a seguito del comando di commit)
o separata (detached): il valore della condizione è valutato come transazione a parte.

 Relazione tra valutazione della condizione e esecuzione della regola:


o Immediata (immediate)
o Posticipata (deferred)
o Separata (detached)

 La maggior parte dei sistemi usa l’opzione immediata, ovvero non appena viene valutato il
valore della condizione, se quest’ultima restituisce true, immediatamente viene eseguita
l’azione.

FUNZIONI
 Specificare vincoli di integrità complessi (es., regole gestionali)
 Gestione dei dati derivati
 Mantenimento della consistenza delle viste materializzate rispetto alle modifiche nelle relazioni
di base

34
6 PROGETTAZIONE DI BASI DI DATI RELAZIONALI

6.1 RACCOLTA E ANALISI DEI REQUISITI


 Comprensione degli obiettivi della base di dati.
 Interazione con gli utenti che descrivono le necessità, i problemi, gli obiettivi facendo uso del
linguaggio naturale.
 Formulazione di descrizioni “informali” dei dati (requisiti sui dati) e delle operazioni sui dati
(requisiti funzionali).

6.2 PROGETTAZIONE
 Progettazione concettuale
o Rappresentare i requisiti informali sulla realtà di interesse in termini di una descrizione
concettuale formale e completa (schema concettuale), indipendente dallo specifico DBMS
utilizzato per la gestione della BD.
 Progettazione logica
o Traduzione dello schema concettuale nel modello dei dati adottato dal DBMS scelto per la
gestione della BD. Questa attività è dipendente dallo specifico DBMS utilizzato.
 Progettazione fisica
o Lo schema logico viene completato con la specifica dei parametri fisici di memorizzazione
dei dati (organizzazione file e indici).

NELLA PROGETTAZIONE DI BD
 Modelli Concettuali:
o utilizzati nella fase di progettazione concettuale per costruire schemi concettuali,
ovvero descrizioni dei dati ad alto livello di astrazione, indipendente dallo specifico
DBMS.
o Es., modello Entity-Relationship.
 Modelli Logici:
o utilizzati nella fase di progettazione logica per ottenere schemi logici, ovvero descrizioni
dei dati processabili dal DBMS.
o Es., modello relazionale.

6.3 ASTRAZIONE
Processo mentale eseguito quando ci si concentra sulle proprietà / caratteristiche essenziali di un insieme
di oggetti, ignorando le differenze (selezione delle proprietà rilevanti di un insieme di oggetti).

Meccanismi di astrazione fondamentali utilizzati nella progettazione concettuale.


 Classificazione
 Aggregazione
 Generalizzazione

35
ASTRAZIONE DI CLASSIFICAZIONE
Meccanismo utilizzato per definire un concetto come classe di oggetti del mondo reale caratterizzati da
proprietà comuni.

ASTRAZIONE DI AGGREGAZIONE
Meccanismo utilizzato per definire una nuova classe a partire da un insieme di altre classi che
rappresentano le sue parti “componenti”

ASTRAZIONE DI GENERALIZZAZIONE
Meccanismo secondo cui si definisce una relazione di sottoinsieme tra gli oggetti di due (o più) classi.
Ereditarietà delle proprietà della generalizzazione da parte di tutte le specializzazioni.

 I tre meccanismi sono indipendenti tra loro (nessuno può essere espresso in termini degli altri).
 Forniscono un diverso meccanismo per la strutturazione delle informazioni.
 Proprietà tra concetti stabilite dai meccanismi

36
7 MODELLO ENTITÀ RELAZIONE (ER)
Introdotto da Peter Chen (ACM TODS, 1976)

7.1 COSTRUTTI FONDAMENTALI


 Entità (Entity)
 Relazione (o Associazione) (Relationship)
 Attributo
 Cardinalità (relazioni e attributi)
 Identificatore
 Attributi composti
 Gerarchie di generalizzazione
 Sottoinsiemi

TIPO DI ENTITÀ
Rappresenta una classe di oggetti della realtà di interesse aventi proprietà comuni ed esistenza
“autonoma” ai fini dell’applicazione di interesse.
 Oggetti con esistenza fisica (es., Impiegato)
 Oggetti che esistono a livello concettuale (es., Dipartimento)

Ogni tipo di entità all’interno di uno schema ha un nome che la identifica univocamente ed è
rappresentato
graficamente con un rettangolo

ENTITÀ
Una occorrenza di un tipo di entità ovvero un oggetto specifico rappresentato dal tipo di entità.
Insieme di entità: Collezione di tutte le entità di un particolare tipo di entità in un certo istante di
tempo.

TIPI DI ASSOCIAZIONE
 Rappresenta un legame logico tra due o più tipi di entità, significativo per l’applicazione di
interesse
o Es., afferenza tra Impiegato e Dipartimento

Un tipo di associazione R all’interno di uno schema ha un nome che la identifica univocamente.

Grado: nr. di tipi di entità che partecipano al tipo di associazione


 BINARIA(tra due entità).
 N-ARIA(tra N entità) con N=3 si parla di TERNARIA

Possono esistere tipi di associazione diversi tra gli stessi tipi di entità, per esprimere legami semantici
diversi

ASSOCIAZIONE
 E’ una occorrenza di un tipo di associazione R ovvero un’ennupla (e1,e2,…,en) in cui ciascun ei è
un’entità istanza del tipo di entità Ei che partecipa a R.
 Un’associazione R è una relazione matematica su E1,E2,…En, ovvero un sottoinsieme del
prodotto cartesiano E1 X E2 X…X En.
 Concretamente, ciascuna associazione ai è un legame fra entità che include esattamente
un’entità e per ciascun tipo di entità Ei che partecipa ad R.
 Ciascuna associazione ai rappresenta il fatto che le entità ei che partecipano all’associazione
sono correlate fra loro nel mini-mondo analizzato.
37
ASSOCIAZIONI RICORSIVE (AD ANELLO)
Definite tra un tipo di entità e se stesso: lo stesso tipo di entità partecipa al tipo di associazione con
ruoli diversi

ATTRIBUTO
 Descrive una proprietà elementare dei tipi di entità e dei tipi di associazione di interesse ai fini
dell’applicazione.
o Es., Cognome, Nome per Impiegato.
 Ogni entità/associazione possiede un valore per ciascuno degli attributi definiti sul
corrispondente tipo di entità/associazione
 Il valore di un attributo appartiene a un dominio dell’attributo che contiene i valori ammissibili.
o Es., Cognome, Nome hanno valori nel dominio stringa di caratteri.

CARDINALITÀ DELLE ASSOCIAZIONE


 Un vincolo di cardinalità è una coppia di valori (mc, MC), con mc <= MC
o mc è detta cardinalità minima
o MC è detta cardinalità massima
 Un vincolo di cardinalità è definito per ciascun tipo di entità E che partecipa all’associazione
 La coppia (mc, MC) regola la partecipazione delle entità occorrenza di Ei alle occorrenze
dell’associazione R.

 Le cardinalità sono definite in base alle regole che sussistono nell’applicazione di interesse o
mini-mondo.

VINCOLO DI CARDINALITÀ-MINIMA MC (EI,R)


Numero minimo di associazioni R a cui una entità occorrenza di Ei può partecipare.
 E’ detto anche vincolo di partecipazione perché specifica se l’esistenza di un’entità dipende dal
suo essere correlata a un’altra entità attraverso un’associazione di tipo R
o mc = 0 partecipazione opzionale (o parziale)
o mc >= 1 partecipazione obbligatoria (o totale), detta anche dipendenza di esistenza

VINCOLO DI CARDINALITÀ-MASSIMA MC (EI,R)


Numero massimo di associazioni di tipo R a cui una entità ei(occorrenza di Ei) può partecipare
o MC = n in generale (nr. qualunque)
38
TIPOLOGIE
In base ai valori di cardinalità massima MC si hanno le seguenti tipologie di relazioni binarie
 1:1 (Uno-a-uno): MC=1 per entrambi i tipi di entità E1 e E2
 1:N (Uno-a-molti): MC = 1 per un tipo di entità e MC=N per l’altro
 N:M (Molti-a-molti): MC = N entrambi i tipi di entità E1 e E2

CARDINALITÀ DEGLI ATTRIBUTI


Descrivono il numero minimo e massimo di valori dell’attributo associati ad ogni
entità/associazione.
 Il valore (1,1) si verifica nella maggioranza dei casi e viene omesso (default).

 Il valore di un attributo può essere nullo (sconosciuto, non applicabile) :


o cardinalità minima = 0 (attributo opzionale)
 Esistono diversi valori di un attributo associati alla stessa occorrenza di entità :
o cardinalità massima = N (attributo multivalore)

IDENTIFICATORE
 Un identificatore di un tipo di entità E è una collezione di attributi e/o tipi di entità connesse ad
E che permettono di identificare univocamente le entità istanze di E.
o (Sul libro: attributo chiave)

 Tipologie di identificatori:
o Interno
o Esterno

IDENTIFICATORE INTERNO
 Uno o più attributi di E sono sufficienti ad individuare un identificatore:
o Semplice: un solo attributo (attributo chiave)
o Composto: più attributi (attributo chiave composto)

 Uno più attributi di E non sono sufficienti ad individuare un identificatore per E -> E è detta tipo
di entità debole

39
IDENTIFICATORE ESTERNO
 si utilizzano tipi di entità con cui E ha un vincolo di dipendenza
o (i.e., si considerano tipi di associazioni binarie a cui E partecipa con cardinalità (1,1)).

GERARCHIE

TIPI DI ENTITÀ
 Un tipo di entità E è una superclasse di E1, E2, …, En, se ogni istanza di E1, E2, …, En è anche
istanza di E.
 Si dice che E1, E2, …, En sono sottoclassi di E.
 Si dice che E è padre di E1, E2, …,En e che E1, E2, …, En sono figli di E.

SPECIALIZZAZIONE
 processo di definizione di un insieme di sottoclassi E1,E2,…,En di un tipo di entità E
 Definizione di attributi aggiuntivi specifici di una sottoclasse
 Definizione di tipi di associazione specifici di una sottoclasse

GENERALIZZAZIONE
 processo di astrazione inverso della specializzazione in cui si individuano le caratteristiche
comuni di un insieme di tipi di entità E1,E2,…,En li si associa a un singolo tipo di entità E
superclasse di cui i tipi di entità originari E1,E2,…,En diventano sottoclassi

EREDITARIETA’
 Meccanismo di ereditarietà da superclasse a sottoclasse
o Ogni proprietà di una superclasse E (attributi, identificatori, associazioni) è
ereditata da una sottoclasse di E.
o Le proprietà ereditate non vanno rappresentate esplicitamente.

VINCOLI
 Totalità
o Una gerarchia è totale se ogni entità della superclasse è istanza di almeno una
sottoclasse della specializzazione; altrimenti è parziale.
 Disgiunzione
o Una gerarchia è esclusiva (o disgiunta)se un’entità può essere istanza al più di una
delle sottoclassi della specializzazione; altrimenti è sovrapposta.

Le tipologie di gerarchie che si ottengono rispetto alle due proprietà ortogonali sono
 Totale-Esclusiva TE (DEFAULT)
 Parziale-Esclusiva PE
 Totale-Sovrapposta TO
 Parziale-Sovrapposta PO

40
ATTRIBUTI COMPOSTI
 E’ possibile raggruppare attributi aventi affinità d’uso o di significato.
 L’insieme degli attributi ottenuto in questo modo prende il nome di attributo composto.
 In generale si consiglia di usare attributi composti il meno possibile, per limitare la complessità
degli schemi.
 Inoltre gli attributi composti non possono essere espressi direttamente nel modello relazionale.

7.2 DOCUMENTAZIONE DI SCHEMI E-R


Importante corredare schemi ER con documentazione di supporto
 Dizionario dei dati: documentazione testuale associata ad uno schema ER.
 Descrizione di tutte i tipi di entità dello schema descrizione, elenco attributi, identificatori (tabella
delle entità)
 Descrizione di tutti i tipi di associazione dello schema con descrizione, elenco entità coinvolte,
attributi (tabella delle associazioni)
 Descrizione dei vincoli di integrità non direttamente esprimibili nel modello ER, sottoforma di
annotazioni testuali associate allo schema.

41
42
8 RACCOLTA DEI REQUISITI
Completa individuazione dei problemi che il sistema da realizzare deve risolvere e le caratteristiche che il
sistema dovrà possedere.
 Aspetti statici (dati)
 Aspetti dinamici (transazioni/operazioni sui dati)

 Identificazione dei gruppi di utenti e delle aree applicative (interviste, questionari)


 Raccolta di documentazione esistente
o applicazioni (moduli, report, regolamenti interni, procedure aziendali)
 La raccolta è a carico del progettista;
l’interazione con gli utenti del sistema informativo gioca un ruolo importante

8.1 FONTI
 Realizzazioni preesistenti, ovvero applicazioni che si devono sostituire o che devono interagire in
qualche modo con la base dati da realizzare.
o Tracciati record, maschere, algoritmi, documentazione associata
 Interviste agli utenti principali con uso di questionari

 I requisiti sono generalmente descrizioni in linguaggio naturale; quindi sono informali e possono
risultare incompleti o presentare inconsistenze
 Scopo dell’analisi dei requisiti è il chiarimento e l’organizzazione dei requisiti raccolti
 Attività difficilmente standardizzabile perché legata all’applicazione da realizzare

8.2 REGOLE GENERALI


 Scelta del corretto livello di astrazione
o evitare termini troppo generici/specifici
 Standardizzazione della struttura delle frasi
o raggruppamento di frasi omogenee
 Evitare frasi contorte
o definizioni semplici e chiare dei vari concetti

 Identificazione dei sinonimi e omonimi e unificazione dei termini


o Sinonimi: termini diversi con lo stesso significato
 unificazione
o Omonimi: termini uguali con significato diverso
 diversificazione
 Glossario dei termini
o Per ogni termine t il glossario contiene una breve descrizione, possibili sinonimi e altri
termini del glossario con cui t possiede legami logici.

43
44
9 PROGETTAZIONE CONCETTUALE
E’ opportuno rappresentare mediante tipi di entità
 concetto con proprietà significative
 concetto che descrive classi di oggetti con esistenza autonoma
E’ opportuno rappresentare mediante attributo
 concetto con struttura semplice senza proprietà rilevanti
E’ opportuno rappresentare mediante tipi di associazione
 concetto che esprime un legame fra due (o più) tipi di entità già identificati
E’ opportuno rappresentare mediante gerarchie
 concetti che sono specializzazione di altri concetti

9.1 GENERAZIONE DI UNO SCHEMA


La produzione di uno schema segue un approccio incrementale a partire dai requisiti
Uso di strategie di progettazione
 top-down
 bottom-up
 inside-out
 mixed

STRATEGIA TOP-DOWN
Si parte da uno schema contenente astrazioni di alto livello e si procede con successivi raffinamenti
top-down
I raffinamenti aumentano il dettaglio dei concetti man mano che si procede con i raffinamenti top-
down
Uso di primitive di raffinamento top-down

45
STRATEGIA BOTTOM-UP
Si parte da uno schema contenente astrazioni di base che descrivono frammenti elementari di
realtà e si procede aggregando tali astrazioni o aggiungendone di nuove
Uso di primitive di raffinamento bottom-up

46
STRATEGIA INSIDE-OUT
Caso particolare della strategia bottom-up
Si individuano inizialmente alcuni concetti di maggiore rilevanza e da questi si procede rappresentando
via via i concetti vicini a quelli iniziali seguendo i requisiti (procedimento a “macchia d’olio”)

STRATEGIA MISTA
Combinazione delle strategie top-down e bottom-up
Definizione di uno schema scheletro contenente a livello astratto i concetti principali dell’applicazione
Su ciascuna parte dello schema scheletro si può procedere applicando o la strategia top-down
oppure quella bottom-up
Adatta a progetti di una certa complessità e/o progetti in cui non sono disponibili da subito tutti i
requisiti.

47
9.2 QUALITÀ DI UNO SCHEMA CONCETTUALE

LEGGIBILITÀ
Uno schema concettuale é leggibile quando presenta i requisiti in maniera facilmente
comprensibile
 scelta di nomi significativi e adeguati
 minimizzazione di intersezioni (elementi con più legami posizionati centralmente)

MINIMALITÀ
Uno schema concettuale è minimale quando non presenta ridondanze (es., presenza di dati
derivati), ovvero le specifiche sui dati sono rappresentate una volta sola nello schema
 si può tollerare la ridondanza come scelta progettuale ma va documentata (vedi prog.
logica)

COMPLETEZZA
Uno schema concettuale è completo quando descrive tutti i requisiti di interesse e le operazioni
possono essere eseguite a partire dai concetti contenuti nello schema
 tutti i requisiti sono rappresentati da qualche concetto nello schema
 tutti i concetti coinvolti nelle operazioni sono raggiungibili nello schema

CORRETTEZZA
Uno schema concettuale è corretto quando fa un uso proprio dei costrutti del modello concettuale
utilizzato
 errori sintattici
uso non ammesso di costrutti
(es., generalizzazione su associazioni)
 errori semantici
uso dei costrutti che non rispetta la loro definizione
(es., associazione per esprimere specializzazione)

9.3 PROGETTAZIONE DI TRANSAZIONI


Specifica delle caratteristiche funzionali delle transazioni per assicurare che lo schema comprenda tutte le
informazioni di interesse

Identificare input/output e comportamento funzionale


 Transazioni di interrogazione
 Transazioni di aggiornamento
 Transazioni miste

48
10 PROGETTAZIONE LOGICA

10.1 ATTIVITÀ
1. Ristrutturazione dello schema concettuale (ER)
2. Traduzione nello schema logico (relazionale)
3. Verifica di “normalizzazione” sullo schema relazionale ottenuto

RISTRUTTURAZIONE DI SCHEMI ER
Modifiche apportate allo schema ER sulla base di valutazioni legate ai parametri di carico della BD
Classi di modifiche:
 Analisi dei dati derivati (ridondanza)
 Eliminazione delle gerarchie di generalizzazione
 Scelta degli identificatori primari
 Eliminazione di attributi multi-valore e composti

ANALISI DEI DATI DERIVATI


Presenza di attributi il cui valore è derivato (es., valore aggregato) ovvero può essere calcolato
mediante algoritmi a partire da altri valori memorizzati nella BD
 Attributi derivabili da altri attributi della stessa entità
 Attributi derivabili da altri attributi di altre entità
 Attributi derivabili da operazioni di conteggio di occorrenze
 Cicli di associazioni

Vantaggi
 Semplificazione delle interrogazioni
 Accesso diretto al valore derivato (non viene calcolato ogni volta)

Svantaggi
 Maggiore occupazione su memoria di massa
 Maggior costo degli aggiornamenti
 Necessaria l’introduzione di vincoli di integrità

49
La convenienza del mantenimento di dati derivati va valutata confrontando i costi di esecuzione in
presenza e assenza di un dato derivato considerando i parametri sul carico applicativo
 Assenza del dato derivato:
o costo di esecuzione delle operazioni necessarie per calcolare il dato derivato
VS.
 Presenza del dato derivato:
o Costo di esecuzione delle operazioni di aggiornamento extra necessarie per mantenere
la consistenza della BD
o Memoria aggiuntiva necessaria

ELIMINAZIONE GERARCHIE DI GENERALIZZAZIONE


 I modelli logici come il relazionale non rappresentano esplicitamente le gerarchie di
generalizzazione
 Occorre rappresentarle attraverso tipi di entità e associazioni
 3 opzioni:
o Mantenimento della sola entità superclasse
o Mantenimento delle sole entità sottoclassi
o Mantenimento di tutti i tipi di entità

Mantenimento della sola entità superclasse


 Si mantiene solo la superclasse e si eliminano le sottoclassi

 Ristrutturazioni sullo schema


o Aggiunta di un nuovo attributo TIPO sull’entità generica per mantenere la distinzione
tra le varie occorrenze dell’entità generica
o Revisione delle cardinalità di associazioni/attributi definiti sulle entità sottoclasse (la
cardinalità minima diventa zero)
 Applicabilità: tutti i tipi di gerarchie

50
Mantenimento delle sole entità sottoclasse
 Si mantengono solo le sottoclassi e si elimina la superclasse

 Ristrutturazioni sullo schema


o Ereditarietà esplicita di tutti gli attributi e associazioni della superclasse sulle sottoclassi
o Non si alterano le cardinalità delle associazioni definite sulle sottoclassi

 Applicabilità: gerarchie di tipo TE

Mantenimento di tutte le entità


 Si mantengono sia la superclasse sia le sottoclassi

 Ristrutturazioni sullo schema


o Si definiscono associazioni “1:1” esplicite tra la superclasse ed ogni sottoclasse per la
rappresentazione dei legami “is-a” della gerarchia.
o Le sottoclassi sono identificate esternamente dalla superclasse
o Non si alterano le cardinalità delle associazioni preesistenti

 Applicabilità: tutti i tipi di gerarchie

 Dopo gli aggiornamenti, occorre verificare che per ogni istanza delle sottoclassi esista una
istanza dell’entità superclasse
 Per le generalizzazioni totali, occorre verificare che ad ogni istanza della superclasse
corrisponda un’istanza di qualche sottoclasse

51
Analisi delle gerarchie
 Le scelte tra le alternative sono guidate dalla tipologia di operazioni che sono eseguite sulle
entità della gerarchia.

 La maggioranza delle operazioni R usa attributi di gerarchia, senza distinzione tra entità
superclasse e sottoclasse -> conviene alternativa 1
 La maggioranza delle operazioni usa contemporaneamente attributi dell’entità superclasse ed
attributi di singole sottoclassi e la gerarchia è di tipo “(t,e)”-> conviene alternativa 2
 La maggioranza delle operazioni usa attributi dell’entità superclasse e di sue sottoclassi, non
contemporaneamente -> conviene alternativa 3

SCELTA DEGLI IDENTIFICATORI PRIMARI


Operazione necessaria per la successiva fase di traduzione in relazionale
CRITERI DI SCELTA IN ER
Identificatori con possibili valori nulli non possono essere scelti come primari
Un identificatore semplice è da preferire ad identificatori composti
Identificatore usato da molte operazioni è da preferire
Se nessuno degli identificatori soddisfa questi requisiti, si introduce un identificatore “ad hoc” (e.g., ID,
codice)

ELIMINAZIONE DI ATTRIBUTI MULTIVALORE


Un attributo multivalore “a” di un tipo di entità E è rappresentato mediante un nuovo tipo di entità E’ e
una associazione R tra E’ con E, con
Card(E, R) = Card(a)

Eliminazione di attributi composti


 Alternativa 1: si considerano tutti gli attributi componenti come attributi dell’entità

 Alternativa 2: si considera l’attributo composto come un unico attributo (con dominio stringa
di caratteri), unione di tutti i componenti.

52
GENERAZIONE DELLO SCHEMA RELAZIONALE
 Processo di traduzione
 Regole base
o Le entità sono tradotte in relazioni definite sui loro stessi attributi
o Le associazioni sono tradotte in relazioni definite sugli identificatori delle entità che
partecipano e sugli (eventuali) attributi propri dell’associazione
o Dagli identificatori dell’ER derivano i vincoli di chiave
o Si introducono vincoli di integrità referenziale per le relazioni che provengono da
associazioni
o Dalle cardinalità degli attributi derivano vincoli di NOT NULL

GENERAZIONE DELLO SCHEMA RELAZIONALE – ENTITA’


 Un tipo di entità E={K, W}con
o K={a1, a2, …, at} identificatore di E
o W={a(t+1), …, am} attributi descrittivi di E
è tradotto in una relazione con schema
E(a1,a2, …, at, a(t+1), …, am) = E(K, W)

 K diventa la chiave primaria

GENERAZIONE DELLO SCHEMA RELAZIONALE - ASSOCIAZIONI


 Per la trasformazione di associazioni occorre considerare:
o Tipo di associazione (binaria, N-aria)
o Vincoli di integrità:
 cardinalità massime(‘1:1’, ‘1:N’, ‘N:M’)
 cardinalità minime
(partecipazione opzionale/obbligatoria)

Associazioni “n:m”
 R tra E1={K1, W} e E2={K2, X} e
Max-Card(E1, R)= n e
Max-Card(E2, R)= n , con
o K1 identificatore di E1
o W insieme di attributi descrittivi di E1
o K2 identificatore di E2
o X insieme di attributi descrittivi di E2
o C={c1, …, cq} attributi descrittivi di R (se definiti)

 E’ trasformata in una relazione con schema:


R(K1, K2, C)
con chiave primaria K1 K2
 Valutare se C può diventare parte della chiave primaria, (es.: Serie storiche)
 Se C = ∅, lo schema di relazione R possiede solo gli attributi chiave delle entità partecipanti

53
Associazioni “1:1”
 R tra E1={K1, W} e E2={K2, X} e
Max-Card(E1, R)= 1 e
Max-Card(E2, R)= 1 , con
o K1 identificatore di E1
o W insieme di attributi descrittivi di E1
o K2 identificatore di E2
o X insieme di attributi descrittivi di E2
o C attributi descrittivi di R (se definiti)

 R è rappresentata mediante chiave esterna in uno dei due schemi di relazione definiti per E1 ed
E2:
o E1(K1, W, K2, C)
o E2(K2, X)
oppure
o E1(K1, W)
o E2(K2, X, K1, C)

54
Associazioni “1:n”
 R tra E1={K1, W} e E2={K2, X} e
Max-Card(E1,R)=1 e
Max-Card(E2,R)= N(o viceversa) con
o K1 identificatore di E1
o W insieme di attributi descrittivi di E1
o K2 identificatore di E2
o X insieme di attributi descrittivi di E2
o C attributi descrittivi di R (se definiti)

 R è rappresentata aggiungendo la chiave esterna K2 nello schema di relazione definito per E1,
dove si aggiunge anche l’insieme C
o E1(K1, W, K2, C)
o E2 (K2, X)
 Se C = ∅, si aggiunge solamente K2

Entità con identificatore esterno


 E1={K1, W} entità debole E2={K2, X} entità forte, con
R tra E1 e E2, Max-Card(E1, R)= 1, con
o K1 K2 identificatore esterno di E1
o W insieme di attributi descrittivi di E1
o K2 identificatore di E2
o X insieme di attributi descrittivi di E2
 La chiave primaria dell’entità debole è composta e contiene l’identificatore dell’entità forte:
o E1={K1, K2, W}
o E2={K2, X}

55
ASSOCIAZIONI N-arie
 R associazione N-aria tra E1, E2, …, Ep con
E1={K1, W}, E2={K2, X}, …, Ep={Kp, Z},con
C(eventuale) insieme di attributi descrittivi di R

 Si procede in maniera analoga alle associazioni binarie “N:M”


 R è trasformata in una relazione con schema:
E(K, C)
 con chiave primaria K = K1 K2 … Kp o un suo sottoinsieme (necessaria verifica di
minimalità)
 Se C = ∅, lo schema di relazione R possiede solo gli attributi chiave delle entità partecipanti

Associazioni ricorsive
 R ricorsiva su E={K, W}

 “N:M”
o R è di tipo “N:M”, è trasformata in una relazione con schema:
R(K’, K’’)
o dove K’ e K’’ coincidono con K, ma sono opportunamente ridenominati per evidenziare
il ruolo di E nei due rami di R

 “1:N”
o R è di tipo “1:N”, due alternative:
o Come sopra
R(K’, K’’)
con chiave primaria K’, ridenominata da K per il ramo con Max-Card = 1 in R
o Si segue la regola delle “1:N”
R(K, W, K’’)
con K’’ chiave ridenominata secondo il ramo con Max-Card = N in R

56
10.2 NORMALIZZAZIONE DI SCHEMI RELAZIONALI

LE FORME NORMALI
 Per scegliere fra i vari schemi che possono modellare uno stesso frammento di realtà, quello
‘ottimo’
 Il criterio di ottimalità, oggetto delle forme normali, è legato alla capacità dello schema di
evitare il verificarsi di un certo numero di anomalie di comportamento a fronte di operazioni
sui dati

PRIMA FORMA NORMALE


Uno schema di relazione R è in ‘prima forma normale’ se non contiene attributi strutturati e/o
valori multipli.
Il modulo d’ordine non verifica la 1NF → violazione

NORMALIZZAZIONE (RIMEDIO):
Formare nuove relazioni per ogni attributo non-atomico

RIDONDANZA
In ORDINE-PRODOTTO i dati relativi ad un prodotto sono ripetuti in ogni ennupla contente un
ordine per quel prodotto

Fonte di anomalie (il diffondersi di una modifica oltre il suo campo di azione per la presenza di
dipendenze implicite tra i dati)

ANOMALIE
 AGGIORNAMENTO: se cambiano le informazioni su un prodotto (o su un fornitore),
devono essere aggiornate più ennuple
 INSERIMENTO: non è possibile inserire informazioni su un prodotto (o fornitore) se non
c’è un ordine per quel prodotto o fornitore
 CANCELLAZIONE: l’eliminazione degli ordini relativi a un prodotto (o fornitore) causa la
perdita di informazioni su quel prodotto o fornitore

In generale il verificarsi di anomalie è dovuto al fatto di avere rappresentato in un’unica relazione


concetti diversi che interessano anche individualmente
57
DIPENDENZA FUNZIONALE(FD)
 Vincolo di integrità a livello di schema
 Dati due insiemi di attributi A e B di R, A determina funzionalmente B, A → B se per ogni coppia
di tuple t1 e t2 in R, con t1[A]=t2[A] si deve avere t1[B]=t2[B]
A→B
 A: parte sinistra della dipendenza
 B: parte destra della dipendenza

NORMALIZZAZIONE
 Processo di analisi degli schemi di relazione forniti, basato sulle loro dipendenze funzionali e
sulle chiavi primarie per raggiungere le proprietà desiderate di:
o minimizzazione della ridondanza
o minimizzazione delle anomalie

 Attributo chiave (o primo) di una relazione R: attributo che appartiene a qualche chiave
candidata di R
 Attributo non-chiave (o non-primo): attributo che non appartiene ad alcuna chiave candidata
di R
 Dipendenza funzionale completa: d: X → Y è completa se la rimozione di qualsiasi attributo A
da X comporta che d non sussiste più
 Dipendenza funzionale parziale: d: X → Y è parziale se è possibile rimuovere qualche attributo
A da X e d continua a sussistere

SECONDA FORMA NORMALE


 Uno schema di relazione R(X) è in 2NF se:
o 1NF
o ogni attributo non-chiave di R(X) dipende funzionalmente e completamente dalla
chiave primaria di R(X)
 In altri termini, la 2NF impone che per le relazioni in cui la chiave primaria contiene più
attributi, non ci siano dipendenze parziali da un sottoinsieme della chiave primaria (ovvero
attributi non-chiave funzionalmente dipendenti da una parte della chiave primaria stessa)

58
NORMALIZZAZIONE (RIMEDIO)
 Decomporre e preparare una nuova relazione per ogni dipendenza parziale con i suoi attributi
dipendenti
 Assicurarsi di mantenere una relazione con la chiave primaria originale e tutti gli attributi
funzionalmente dipendenti in modo completo da essa

DIPENDENZA FUNZIONALE TRANSITIVA


 B dipende transitivamente da A in R se esiste un altro insieme di attributi Z di R tale che:
o A→ Z
o Z→ B
 dove Z non è né chiave candidata né un sottoinsieme di una chiave di R
 In base a queste dipendenze, A → B in modo Transitivo

TERZA FORMA NORMALE


 Uno schema di relazione R(X) è in terza forma normale 3NF se:
o È in 2NF
o Ogni attributo non-chiave di R(X) è dipendente in modo non transitivo dalla chiave
primaria di R(X)
 La relazione non deve contenere attributi non-chiave determinati funzionalmente da altri
attributi non-chiave.
Ovvero, non deve esserci nessuna dipendenza transitiva di un attributo non-chiave dalla chiave
primaria →
 Con la 3NF, ogni attributo non-chiave non dipende né parzialmente né transitivamente dalla
chiave primaria

59
NORMALIZZAZIONE (RIMEDIO)
Decomporre e preparare una nuova relazione che comprenda gli attributi non-chiave che determinano
funzionalmente altri attributi non-chiave

FORMA NORMALE DI BOYCE-CODD


Uno schema di relazione R(X) è in forma normale di Boyce-Codd(BCNF) se per ogni
dipendenza A → B (dove B non è un sottoinsieme di A), l’insieme di attributi A contiene una chiave per
R, cioè è superchiave

Il procedimento di decomposizione:
 Non deve causare perdita di informazioni
Si può ricostruire la relazione non normalizzata sulla base delle relazioni in forma normale
ottenute dal processo di decomposizione senza informazioni spurie
 Deve conservare le dipendenze
Le relazioni decomposte hanno la capacità di rappresentare gli stessi vincoli di integrità definiti
sulla relazione originaria

60
DECOMPOSIZIONE SENZA PERDITA
 Non si riesce a ricostruire TUTTE E SOLE le informazioni della relazione originaria
 Ci sono delle tuple spurie per effetto del join
 Una relazione R definita su un insieme X= X1 X2 di attributi si decompone senza perdita su X1
e X2 se il join delle due proiezioni R1 e R2 è uguale a R stessa (cioè non contiene tuple spurie)

 Sia R relazione su X e siano X1 e X2 sottoinsiemi di X tali che X1 X2 = X. Sia X0 = X1∩X2


 Se R soddisfa la dipendenza funzionale X0 → X1 oppure X0 → X2 allora R si decompone senza
perdita su X1, X2
 In altre parole, una relazione R si decompone senza perdita su due relazioni se l’insieme degli
attributi comuni alle due relazioni è chiave per almeno una delle due relazioni decomposte

CONSERVAZIONE DELLE DIPENDENZE


 Affinché si possano conservare le dipendenze dopo una decomposizione, è bene che ciascuna
dipendenza dello schema originario coinvolga attributi che compaiono tutti insieme in uno
degli schemi decomposti.
 Così lo schema decomposto garantisce il soddisfacimento degli stessi vincoli soddisfatti dallo
schema originario

Se non si può decomporre in BCNF garantendo entrambe le proprietà, allora


 Ci si ferma alla 3NF tollerando la ridondanza che si genera in qs. schema (il corso di un docente
è ripetuto per ogni esame tenuto dal docente)
 Si sceglie la decomposizione senza perdita sapendo che non si possono controllare tutti i vincoli
(non si può vietare l’inserimento di un esame di un corso nello stesso giorno di un altro esame
dello stesso corso)

61
62
11 PROGETTAZIONE FISICA

 Input
o Schema logico (i.e., relazionale) della BD
o Caratteristiche del DBMS scelto
o Previsioni sul carico applicativo
 Output
o Schema fisico della BD in termini di:
o file in cui memorizzare le relazioni
o strutture fisiche di accesso utilizzate per accedere ai record in maniera efficiente e relativi
parametri

 Il processo di progettazione fisica è molto complesso perché prevede la definizione di numerosi


parametri (e.g., dimensione iniziale dei file, possibilità di espansione, quantità e dimensione delle
aree di transito per scambio di info tra memoria principale e secondaria)
 Tali scelte sono connesse con lo specifico DBMS utilizzato e difficilmente generalizzabili

11.1 MEMORIZZAZIONE FISICA DEI DATI


 La BD è memorizzata in file di dati su dispositivi di memoria secondaria
 Esecuzione di query/aggiornamenti: accedere velocemente ad uno o più record facendo uso di una
chiave di ricerca
 Evitare la scansione sequenziale dei file (SCAN)

11.2 ORGANIZZAZIONI PRIMARIE E SECONDARIE


 Organizzazioni primarie
Il criterio secondo cui le tuple (i record) vengono collocati nel file, tipicamente
o File non ordinati
o File ordinati
o File hash (accesso calcolato)
 Organizzazioni secondarie
o strutture ausiliarie, denominate indici, usate per velocizzare la ricerca di record in risposta
a determinate condizioni di ricerca

11.3 INDICI
 Gli indici sono strutture ausiliarie separate dai file di dati
 Un indice è costruito su un campo chiave K dei record nel file di dati e introduce un ordinamento
dei record nel file in base ai valori di K →
 Permette l’accesso associativo alle tuple di R in base ai valori di K
 Essendo definito sui valori di K, un indice occupa molto meno spazio in termini di blocchi disco
rispetto al corrispondente file di dati

Un indice può essere pensato come una collezione di coppie della forma dove:
 è un valore dell’indexing field
 è un “riferimento” al record (eventualmente il solo) con valore di chiave k

63
ACCESSO CON INDICE
 Si consideri un indice su un certo attributo. La ricerca del record con chiave prevede le
seguenti operazioni:
o accesso all’indice ricerca della coppia
o accesso al/ai record con chiave nel file dati utilizzando
 A seconda delle modalità con cui si organizza l’insieme delle coppie si hanno diverse
modalità di implementazione dell’indice

INDICI SPARSI E DENSI


 Indice denso
indice il cui nr. di coppie è uguale al nr. di valori del campo K
 Indice sparso
Indice il cui nr. di coppie è minore del nr. di valori del campo K

INDICI PRIMARI E SECONDARI


 Indice primario
o indice (sparso) definito su un su attributo che assume valori unici (UNIQUE) rispetto al
quale il file di dati è ordinato
o spesso, è l’indice definito sulla chiave primaria di ciascuna relazione.
 Indice secondario
o Indice denso che può essere definito su un attributo che è chiave candidata per una
relazione R (i.e.,UNIQUE) oppure su un campo non-chiave con valori duplicati.
o Fornisce un ulteriore modalità di accesso ad un file per il quale esiste già un accesso
primario.

64
INDICI MULTI-LIVELLO
 Possiamo trattare un indice come un file di dati e costruire un indice sull’indice
o Indice originario: indice di primo livello
o Indice successivo: indice di secondo livello
 Il processo può essere ripetuto fintantoché l’indice di livello più alto è costituito da un insieme
di valori che possono essere contenuti in un blocco disco.
 Se un indice (e.g., primario, secondario) occupa più di un blocco disco, si può creare un indice
multi-livello

 Gli indici multi-livello così organizzati hanno la forma di un albero di ricerca


 Tuttavia l’inserimento e la cancellazione di valori nell’indice è un problema serio poiché ciascun
livello dell’indice è un file ordinato

 I DBMS relazionali implementano indici multi-livello dinamici utilizzando strutture dati ad


albero di tipo B-tree o B+-tree
 Tali strutture ad albero hanno le seguenti caratteristiche:
o Ogni nodo corrisponde a un blocco disco a livello di file system e buffer manager
o Ogni nodo ha spazio per contenere nuovi valori
o Ogni nodo ha un numero di discendenti abbastanza grande al fine di mantenere il
numero di livelli limitato, in cui la maggioranza dei blocchi sono occupati da nodi foglia
o Gli alberi sono bilanciati, ovvero la lunghezza del cammino dal nodo radice a qualunque
foglia è costante (mantenere l’albero bilanciato è importante perché garantisce che
nessun nodo richiederà molti accessi a blocchi durante la ricerca)

65
INDICI IN SQL
 Create [unique] index NomeIndice on NomeTabella(lista attributi)
o Creazione di un indice denominato NomeIndice sulla tabella NomeTabella operante
sugli attributi in lista attributi (l’ordinamento delle tuple viene effettuato rispetto
all’ordine degli attributi in lista attributi)
 Unique specifica che nella tabella non sono ammesse tuple che abbiano lo stesso valore per gli
attributi che compaiono nella lista
 La definizione di un indice in SQL a livello di DDL corrisponde a definire opportune strutture di
accesso ad albero
 Cancellazione di un indice: Drop index NomeIndice

PROGETTAZIONE FISICA DI BD
 Assumiamo che il DBMS scelto preveda file non ordinati con possibilità di definizione di indici
 In tale contesto, il processo di progettazione fisica può essere ricondotto ad una attività di
individuazione degli indici da definire su ciascuna relazione
 Daremo linee guida principali, che possono essere considerate sufficienti per BD di dimensioni
non enormi o con carichi di lavoro non particolarmente complessi

SCELTA DI INDICI PER RELAZIONI


 La scelta degli indici è eseguita in modo da rendere più efficienti le operazioni più delicate
o selezione: accesso ad uno o più tuple (record) sulla base dei valori di uno o più attributi
o join: combinazione delle ennuple di relazioni diverse sulla base dei valori di uno o più
attributi di ciascuna di tali relazioni

INDICI PER RELAZIONI


Impiegato (Matricola, Nome, Cognome, Dipartimento)
Dipartimento (Codice, Nome)
 Si vuole effettuare una ricerca degli impiegati dato il numero di matricola (selezione su
Matricola)
o Con indice su Matricola: la ricerca può procedere con un accesso diretto (efficiente)
o Senza indice: accesso sequenziale (poco efficiente, costo proporzionale alla dimensione
del file)

 Occorre definire un indice per ciascuno degli attributi su cui si intende effettuare una ricerca
 Ad esempio, la selezione su Cognome sarà più efficiente se si definisce un indice su tale
attributo, indipendentemente dal fatto che sia stato definito un indice su Matricola

 Equi-join di Impiegato e Dipartimento per collegare ciascun impiegato con il corrispondente


dipartimento è effettuato in modo molto efficiente se è definito un indice sulla chiave Codice
della relazione Dipartimenti
o Con indice il join è effettuato come segue:
 scansione sequenziale della relazione Impiegati (tutte le ennuple partecipano al
join)
 per ciascuna ennupla di impiegato si effettua un accesso diretto alla relazione
Dipartimenti mediante l’indice definito.
o Senza indice: l’accesso a Dipartimento è inefficiente penalizzando tutto il join

66
 È ragionevole definire un indice sulla chiave di ciascuna relazione (molti dei join che si
presentano nelle applicazioni sono equi-join e per almeno una delle relazioni i campi coinvolti
formano la chiave)
 Possono essere definiti ulteriori indici per attributi su cui:
o vengono effettuate operazioni di selezione
o è richiesto un ordinamento in uscita (un indice ordina logicamente i record in un file
rendendo nullo il costo dell’operazione)

PROGETTAZIONE FISICA DI BD
 Sperimentazione del comportamento dell’applicazione utilizzando gli indici definiti sulla base di
questi criteri
 Se le prestazioni dovessero essere insoddisfacenti, si può valutare l’aggiunta di altri indici
(tuning)
o warning: un numero eccessivo di indici può produrre un aggravio del carico per far
fronte alle operazioni di modifica
 È buona norma dopo l’aggiunta di un indice verificare che le interrogazioni ne facciano uso
(e.g., invocazione del comando show plan del DBMS che mostra la strategia di accesso scelta
dal DBMS)

67
68
12 SICUREZZA DELLE BASI DI DATI

12.1 OBIETTIVI
 Segretezza: protezione delle informazioni da letture non autorizzate
 Integrità: protezione dei dati da modifiche o cancellazioni non autorizzate
 Disponibilità: garanzia che non si verifichino casi in cui ad utenti legittimi venga negato l’accesso ai
dati

Importanza assegnata a tali obiettivi varia a seconda del sistema considerato

12.2 TECNICHE DI SICUREZZA


 Autenticazione: meccanismi per verificare l’identità dell’utente che si connette al sistema
 Controllo dell’accesso: meccanismi che, per ogni richiesta di accesso ai dati, verificano che l’utente
sia autorizzato a compiere l’accesso
 Crittografia: meccanismi che consentono di cifrare i dati in modo che possano essere decifrati solo
da utenti autorizzati

Noi ci concentreremo sul controllo dell’accesso (responsabilità del DBMS).

CONTROLLO DELL’ACCESSO
 Regola le operazioni che si possono compiere sulle informazioni e le risorse in una base di dati
 Lo scopo è limitare e controllare le operazioni che gli utenti effettuano, prevenendo azioni
accidentali o deliberate che potrebbero compromettere l’integrità e la segretezza dei dati
 Le risorse sono costituite dai dati, memorizzati in oggetti a cui si vuole garantire protezione
 I soggetti sono agenti (utenti o programmi in esecuzione) che richiedono di poter esercitare
privilegi (come lettura, scrittura o esecuzione) sui dati

 Politiche di sicurezza: norme e principi che esprimono le scelte di fondo dell’organizzazione


relativamente alla sicurezza dei propri dati
 Sono implementate mediante traduzione in un insieme di regole di autorizzazione che
stabiliscono le operazioni ed i diritti che gli utenti possono esercitare sui vari oggetti del sistema
 Il Reference Monitor è un meccanismo di controllo che ha il compito di stabilire se l’utente può
essere autorizzato (totalmente o parzialmente) a compiere l’accesso

POLITICHE DI SICUREZZA
 La politica di sicurezza adottata dipende principalmente da fattori organizzativi, quali
l’ambiente di installazione, le esigenze degli utenti, i regolamenti dell’organizzazione, o i vincoli
di natura legale.
 Due classi fondamentali:
o Politiche per l’amministrazione della sicurezza
o Politiche per il controllo dell’accesso ai dati

Politiche per l’amministrazione


 Stabiliscono chi concede e revoca i diritti di accesso
o Centralizzata: un unico autorizzatore, detto DBA, controlla l’intera base di dati.
o Decentralizzata: più autorizzatori responsabili del controllo di porzioni diverse della
base di dati.

69
 Ownership: l’utente che crea un oggetto (il proprietario) gestisce le
autorizzazioni sull’oggetto

Politiche per il controllo dell’accesso


 Le politiche per il controllo dell’accesso stabiliscono se e come i soggetti possono accedere a
quali dati contenuti nel sistema, e se e come possono venire trasmessi i diritti di accesso

LIMITAZIONE DEGLI ACCESSI

 Need-To-Know (minimo privilegio)


o Molto restrittiva, permette ad ogni utente l’accesso solo ai dati strettamente necessari
per eseguire le proprie attività
 Maximized Sharing (massima condivisione)
o Consente agli utenti il massimo accesso alle informazioni nella base di dati,
mantenendo comunque informazioni riservate

Need to know
 offre ottime garanzie di sicurezza ed è adatta a basi di dati con forti esigenze di protezione
 può portare ad un sistema eccessivamente protetto, negando accessi che non
comprometterebbero la sicurezza del sistema

Maximed sharing
 soddisfa il massimo numero possibile di richieste di accesso
 viene utilizzata in ambienti in cui esiste una certa fiducia tra gli utenti ed in cui non è sentita
una forte esigenza di protezione

Sistema aperto
 l’accesso è permesso a meno che non sia esplicitamente negato
 le regole di autorizzazione indicano per ogni soggetto i diritti che egli non può esercitare sugli
oggetti del sistema
 questi diritti sono i soli che gli saranno negati

Sistema chiuso
 l’acceso è permesso solo se esplicitamente autorizzato
 le regole di autorizzazione indicano per ogni soggetto i diritti che egli può esercitare sugli
oggetti del sistema
 questi diritti sono i soli che verranno accordati dal meccanismo di controllo

SISTEMI APERTI E CHIUSI


 Un sistema chiuso implementa la politica del minimo privilegio, un sistema aperto implementa
 la politica della massima condivisione.
 Un sistema chiuso offre maggiori garanzie di sicurezza: una regola inavvertitamente cancellata
o non inserita restringe ulteriormente l’accesso, mentre un sistema aperto permette accessi
non autorizzati.
 La maggior parte delle basi di dati oggi esistenti sono sistemi chiusi.

70
GRANULARITA’ DEL CONTROLLO
 Granularità a cui il controllo dell’accesso deve essere effettuato
 Requisito minimo: possibilità di specificare nelle regole di autorizzazione sugli oggetti a cui
l’utente può accedere → nelle BD relazionali una relazione o attributi di relazione

Tipologia di controllo
 Controllo dipendente dal nome
l’accesso è basato sul nome dell’oggetto
 Controllo dipendente dal contenuto
l’accesso è subordinato al valore di uno o più attributi dell’oggetto (es., l’utente X può accedere
ai dati degli impiegati il cui stipendio è inferiore a una certa soglia).
 Controllo dipendente dal contesto
l’accesso è subordinato al valore di variabili di sistema (es., data, tempo). (es., i dati sugli
impiegati possono essere acceduti solo in orario di lavoro).
 Controllo dipendente dalla storia degli accessi
l’accesso è subordinato alla storia degli accessi eseguiti precedentemente (es., un utente può
accedere ad un determinato dato solo se il numero di accessi da lui compiuti su quel dato in un
determinato intervallo di tempo non supera una certa soglia)

LE POLITICHE
 Politiche Discrezionali (DAC)
 Politiche Mandatorie (MAC)

Politiche discrezionali
 Richiedono che vengano specificati i diritti che ogni soggetto possiede sugli oggetti del sistema,
sottoforma di regole di autorizzazione
 Il meccanismo di controllo esamina le richieste di accesso accordando solo quelle che sono
autorizzate da una regola
 Gli utenti possono a loro discrezione concedere o revocare i diritti di accesso sugli oggetti

 Vantaggio
sono estremamente flessibili ed adatte a numerosi contesti applicativi
 Svantaggio
non impongono restrizioni sull’uso che viene fatto del dato una volta acceduto ovvero non
forniscono alcun controllo sul flusso di informazioni nel sistema
o Si ha un flusso tra un oggetto X e un oggetto Y quando si effettua una lettura del valore
di X e una scrittura del valore in Y.

Politiche mandatorie
 Per basi di dati governative le politiche discrezionali non sono sufficienti
o Informazioni vitali, diversi livelli di sensitività, i controlli sul flusso di dati sono essenziali
o Attacchi sofisticati da parte di utenti determinati (es. Cavallo di Troia)

71
72
 Si usano: Politiche mandatorie basate su classificazione di dati ed utenti.

 Regolano l’accesso ai dati mediante la definizione di classi di sicurezza per i soggetti e gli
oggetti del sistema
 Le classi di sicurezza sono ordinate (es., TS>S>C>U)
 La classe di sicurezza assegnata ad un oggetto rappresenta il livello di sensitività dell’oggetto:
maggiore è la classe assegnata ad un oggetto, più ingente sarà il danno derivante dal rilascio
delle informazioni in esso contenute a soggetti non autorizzati
 La classe di sicurezza assegnata ad un soggetto è una misura del grado di fiducia che si ha nel
fatto che tale soggetto non commetta violazioni

 Il controllo dell’accesso è regolato da una serie di assiomi di sicurezza che stabiliscono le


relazioni (in base al modo di accesso considerato) che devono essere verificate fra la classe di
un soggetto e quella di un oggetto affinché al primo sia concesso di esercitare un modo di
accesso sul secondo
 In particolare, sono vietati flussi da oggetti ad elevata classificazione in oggetti a bassa
classificazione
 Queste politiche sono applicate in ambienti, quali quello militare, dove la quantità di
informazioni da proteggere è elevata, ci sono forti esigenze di protezione ed è possibile
classificare rigidamente gli elementi del sistema
 I sistemi che adottano una politica mandatoria sono spesso indicati come sistemi multilivello
 Possono essere classificate anche come politiche per il controllo del flusso, poiché evitano che
le informazioni una volta accedute vengano trasferite verso oggetti con classificazione inferiore
e quindi più accessibili (vedere esempio Cavallo di Troia)
 C’è un controllo completo sul sistema di autorizzazione
 La flessibilità è però ridotta e la circolazione di informazioni tra gli utenti è più difficile

 Le politiche mandatorie e discrezionali non sono mutuamente esclusive, possono cioè essere
 applicate insieme.
 La politica mandatoria non controlla più le richieste di accesso ma le autorizzazioni che
vengono assegnate ad un soggetto, mentre alla politica discrezionale è affidato il compito di
controllare le richieste di accesso

73
12.3 MODELLI PER IL CONTROLLO DELL’ACCESSO A BASI DI DATI RELAZIONALI

MODELLO DI AUTORIZZAZIONE DEL SYSTEM R


 Il modello implementa una politica di tipo discrezionale e supporta il controllo dell’accesso in
base sia al nome che al contenuto.
 Il sistema è un sistema chiuso: un accesso è concesso solo se esiste una esplicita regola che lo
autorizza.
 L’amministrazione dei privilegi è decentralizzata mediante ownership: quando un utente crea
una relazione, riceve automaticamente tutti i diritti di accesso su di essa ed anche la possibilità
di delegare ad altri tali privilegi.

OPERAZIONE DI GRANT
GRANT Lista Privilegi | ALL[PRIVILEGES]
ON Lista Relazioni | Lista Viste
TO Lista Utenti | PUBLIC
[WITH GRANT OPTION]

MODELLO DEL SYSTEM R


 Gli oggetti di protezione sono relazioni e viste
 I privilegi previsti sono:
o Delete
o Insert
o Select
o Update
 Solo il proprietario può cancellare un oggetto

OPERAZIONI DI GRANT
 Le parole chiave ALL (o ALL PRIVILEGES) consentono di concedere con un solo comando tutti i
privilegi su una determinata relazione. Non possono essere utilizzate su viste.
 Con un unico comando di GRANT si possono concedere più privilegi su una stessa relazione e
concedere privilegi sulla stessa relazioni a più utenti (in entrambi i casi l’ordine è irrilevante).
 Un comando di GRANT con soggetto PUBLIC è equivalente ad una concessione di privilegi a
tutti gli utenti.

 La delega dei privilegi avviene mediante la grant option:


se un privilegio è concesso con grant option l’utente che lo riceve può non solo esercitare il
privilegio, ma anche concederlo ad altri.
 Un utente può concedere un privilegio su una determinata relazione solo se è il proprietario
della relazione, o se ha ricevuto tale privilegio da altri con grant option.
 Se la clausola WITH GRANT OPTION non è specificata l’utente che riceve i privilegi non può
concederli ad altri utenti.
 I privilegi che ogni utente possiede sono divisi in:
o delegabili: privilegi concessi con grant option
o non delegabili: concessi senza grant option

74
CATALOGHI SYSAUTH E SYSCOLAUTH
 Le regole di autorizzazione specificate dagli utenti sono memorizzate in due cataloghi di
sistema di nome sysauth e syscolauth, implementati come relazioni

CATALOGO SYSAUTH
 Ogni colonna relativa ad un tipo di privilegio in Sysauth contiene un timestamp che denota il
tempo in cui il privilegio è stato concesso.
 Il valore 0 indica che l’utente non ha quel privilegio
 Un valore t ≠ 0 indica che privilegio è stato concesso (GRANT) all’utente al tempo t.
 Privilegi garantiti con lo stesso comando di GRANT hanno lo stesso timestamp

75
CATALOGO SYSCOLAUTH
 Le colonne su cui il privilegio di update può essere esercitato sono contenute nel catalogo
SYSCOLAUTH
 SYSCOLAUTH contiene una tupla (id_utente, nome, colonna, grantopt) per ogni colonna della
relazione nome su cui l’utente identificato da id_utente può esercitare il privilegio di update

CATALOGHI SYSAUTH E SYSCOLAUTH


 Quando un utente u esegue un comando di GRANT, il meccanismo di controllo accede ai
cataloghi SYSAUTH e SYSCOLAUTH per determinare se u ha il diritto di delegare i privilegi
specificati nel comando.
 L’insieme dei privilegi delegabili che l’utente u possiede è intersecato con l’insieme dei privilegi
specificati nel comando di GRANT.
 Se l’intersezione è vuota, il comando non viene eseguito.
 Se l’intersezione coincide con i privilegi specificati nel comando, vengono concessi tutti i
privilegi specificati.
 Altrimenti il comando viene eseguito parzialmente, cioè solo i privilegi contenuti
dell’intersezione vengono accordati

OPERAZIONE REVOKE
REVOKE Lista Privilegi | ALL[PRIVILEGES]
ON Lista Relazioni | Lista Viste
FROM Lista Utenti | PUBLIC

 Un utente può revocare solo i privilegi che lui ha concesso.


 È possibile revocare più privilegi con un comando di REVOKE, ed un unico comando di REVOKE
può essere utilizzato per revocare gli stessi privilegi sulla stessa relazione ad utenti diversi

76
 Quando si esegue una operazione di revoca, l’utente a cui i privilegi vengono revocati perde tali
privilegi, a meno che essi non gli provengano anche da altre sorgenti indipendenti da quella che
effettua la revoca.

REVOCA RICORSIVA
 L’operazione di revoca di un privilegio è ricorsiva:
 Revoca del privilegio oggetto del comando di REVOKE
 Revoca anche di tutti i privilegi che non avrebbero potuto essere concessi se l’utente
specificato nel comando di REVOKE non avesse ricevuto il privilegio revocato
 Un’operazione di revoca ricorsiva del privilegio m sulla relazione R all’utente u1 da parte
dell’utente u2 ha l’effetto di modificare il sistema portandolo in uno stato equivalente a quello
in cui si sarebbe trovato se u2 non avesse mai concesso a u1 il modo di accesso m sulla
relazione R.
 È utilizzata dalla maggior parte dei DBMS relazionali oggi in commercio (ad esempio Oracle,
DB2).

77
AUTORIZZAZIONE SU VISTE
 Le viste permettono di supportare il controllo dell’accesso basato su contenuto
esempio: per autorizzare un utente a selezionare solo le tuple della relazione Impiegato relative
ad impiegati che non guadagnano più di 2000 euro, si definisce una vista che seleziona dalla
relazione Impiegato le tuple che soddisfano tale condizione e si concede all’utente il privilegio
di select sulla vista.
 Le viste permettono di:
o delegare privilegi su singole colonne di relazione:
o basta definire una vista come proiezione sulle colonne su cui si vogliono concedere i
privilegi
o delegare privilegi statistici (media, somma, ecc.).

 I privilegi che l’utente che crea una vista può esercitare sulla vista dipendono da:
1. La semantica della vista, ovvero la sua definizione in termini della relazione o viste
componenti
2. Le autorizzazioni che l’utente possiede sulle relazioni o viste componenti

 Un privilegio sulla vista è delegabile solo se il creatore della vista ha il diritto di delegare tale
privilegio su tutte le relazioni componenti.

 Vista V definita su una singola relazione R


o Il proprietario di V ha su V gli stessi privilegi che ha su R ad eccezione dei privilegi che
non si possono esercitare sulla vista a causa della sua semantica
 Vista V definita su più relazioni
o Il proprietario di V ha su V l’intersezione dei privilegi che l’utente ha sulle relazioni
componenti ad eccezione dei privilegi non eseguibili sulla vista (Spesso si hanno viste a
sola lettura)

SICUREZZA NEI DBMS COMMERCIALI


 Privilegi
o USAGE (per dominio o insieme di caratteri)
o SELECT
o INSERT
o UPDATE [ (nome_colonna) ]
o DELETE
o REFERENCES [ (nome_colonna) ]

 Concetto di gruppo di utenti e supporto alla gestione di gruppi


78
13 TRANSAZIONI
 Unità elementare di lavoro svolta da un programma applicativo, cui si vogliono associare particolari
caratteristiche di correttezza, robustezza e isolamento.
 Sintatticamente, una transazione è l’insieme delle istruzioni compresa tra i due comandi
o begin transaction
o end transaction

 Altri comandi particolari nel codice di una transazione


o commit work (o commit)
o rollback work (o abort)
 L’effetto di questi due comandi è decisivo per l’esito della transazione
o commit ==> la transazione va a buon fine
o abort ==> la transazione fallisce

 ESEMPIO/* operazione bancaria di trasferimento tra due c/c */


begin transaction
c/c1 := c/c1-10;
c/c2 := c/c2+10;
commit work;
end transaction

13.1 PROPRIETÀ
 Tutto il codice compreso tra begin transaction e end transaction gode delle cosiddette proprietà
ACIDe
o Atomicità
o Consistenza
o Isolamento
o Durability (Persistenza)

ATOMICITÀ
 una transazione rappresenta una unità indivisibile di esecuzione.
 vengono resi visibili tutti i suoi effetti nella BD, oppure la t. non ha nessun effetto sulla BD
(approccio “tutto-o-niente”).
 In altre parole, non è possibile che la BD venga lasciata in uno stato intermedio attraversato
durante l’elaborazione della transazione.

CONSEGUENZE SUL PIANO OPERATIVO


 La corretta esecuzione dell’operazione di commit fissa il momento in cui la t. va a buon fine e i
suoi effetti possono essere visibili nella BD.
 Se si verifica un errore e qualche operazione (lettura/scrittura) della t. fallisce prima
dell’operazione di commit, il DBMS deve essere in grado di ricostruire la situazione della BD
all’inizio della t. disfacendo il lavoro compiuto fino a quel momento dalla t. (operazione di
UNDO)
 Dopo l’esecuzione del commit, il DBMS deve assicurare che la t. lasci la bd nel suo stato finale.
Questo può richiedere di dover rifare (operazione di REDO) alcune operazioni.

79
CONSISTENZA
 l’esecuzione di una t. non deve violare i vincoli di integrità definiti sulla BD.
Quando il DBMS rileva che una t. in esecuzione sta violando un vincolo (ad es., viene inserita
una tupla in una tabella con un valore di chiave già presente nella tabella), interviene per
annullare la t. o per correggere la violazione al vincolo.

ISOLAMENTO
 l’esecuzione di una t. deve essere indipendente dalla contemporanea esecuzione di altre t.
 Si richiede che l’esecuzione concorrente di un insieme di t. sia analogo al risultato che le stesse
t. otterrebbero nel caso in cui ciascuna di esse fosse eseguita da sola.
 Si evita che il rollback di una t. causi il rollback di altre t. (effetto domino). Questo potrebbe
accadere se una t. leggesse i dati modificati da un’altra t. che non abbia ancora eseguito il
comando di commit e che non termina correttamente (abort).

PERSISTENZA
 l’effetto di una t. che ha eseguito il commit correttamente non deve essere più perso. In altre
parole, i dati contenuti nella BD non devono essere persi per nessun motivo.

13.2 GESTIONE
 Atomicità e persistenza → garantite dal sottosistema del DBMS denominato “controllore
dell’affidabilità” (recovery manager)
 Isolamento → garantito dal sottosistema del DBMS denominato “controllore della concorrenza”
 Consistenza → gestita dal compilatore DDL, che introduce opportuni controlli di consistenza e
opportune procedure per la loro verifica in fase di esecuzione delle transazioni.

80