Corso di laurea: Ingegneria Elettronica

Anna Maria Carminelli Gregori: Appunti su d.b. parte1 A.A. 2005











A.A. 2005

Appunti su data base
di:


Anna Maria Carminelli Gregori ([email protected])

Parte 1
Sez.1
Parte 1
Sez. 2
Programma, Obiettivi del Corso & Esempio di DBMS
Introduzione a d.b. Progetto & utilizzo, tratti essenziali
Gestione di d.b. Strumenti necessari con richiami a
SORT & Complessita’
db & DBMS
fasi di progettazione dei d.b.
DBMS: modelli, architettura, composizione…
Modello Relazionale &
Basi di Dati Relazionali: aspetti essenziali
Algebra Relazionale
Normalizzazione e Forme Normali
Caratteristiche dei Relational D.B.M.S.
SQL: indicazioni sintetiche
1
Anna Maria Carminelli Gregori: Appunti su d.b. parte1 A.A. 2005

2
Anna Maria Carminelli Gregori: Appunti su d.b. parte1 A.A. 2005
Corso di laurea: Ingegneria Elettronica
Indirizzo:
Calcolatori Elettronici
Insegnamento: Basi di Dati
A.A.
2005
Docente: A.M.Carminelli Gregori
Finalita’:
Il corso intende fornire le conoscenze necessarie per l' analisi, il progetto e lo sviluppo di Software in ambienti
dotati di sistemi informativi e sistemi di elaborazione di vario tipo.
L' impostazione prevede una particolare attenzione ai dati, con approfondimenti sulla loro organizzazione,
memorizzazione ed elaborazione ottimale tramite appositi algoritmi, strutture, relazioni, forme normali, vincoli,
linguaggi, modelli di sicurezza, possibile condivisione e distribuzione. In questo ambito verranno trattati i modelli di
dati su cui si basano i Sistemi di Gestione di Basi di Dati con riferimento ai Sistemi piu’ in uso.
Schema di Programma:
Il Corso verte sul Progetto e la Realizzazione di Software utile nella costruzione di Sistemi Informativi trattando
ed illustrando gli argomenti seguenti:
_ Caratteristiche essenziali delle basi di dati e loro gestione. Strumenti necessari e relativi Algoritmi. Richiamo del
Sort con Algoritmi risolutivi di Complessita’ diversa dipendente dalla Struttura di Dati utilizzata;
_ Basi di Dati, Modelli dei dati (Relazionale e riferimenti al Gerarchico ed al Reticolare, con cenni sul paradigma
Object_ Oriented);
_ Sistemi di Gestione di Basi di Dati (S.G.B.D. con esempi in Access, Oracle, MySql), loro architettura, utilizzo,
Linguaggi;
_Aspetti di progettazione di Basi di Dati con utilizzo del modello di progettazione Entity-Relationship, cenno al
modello UML (Umiform Modeling Languaege), problemi di sicurezza, integrita’, condivisione e gestione
distribuita dei dati con possibili soluzioni & architetture (centralizzata, client-server, distribuita) ed uso dei
relativi strumenti software;
_ Aspetti di implememtazione: caratteristiche fondamentali;
_ Strutture ed Insiemi di Dati di tipo lineare, gerarchico, non lineare, multidimensionale: relativi Algoritmi, loro
Complessita’, implementazioni.
Durante il corso e’ previsto lo svolgimento di una tesina (cfr. Nota).
Testi:
P.Atzeni, S.Ceri, S. Paraboschi, R. Torlone: “Basi di dati Modelli e linguaggi di interrogazione” McGraw-Hill, 2002
“
“
“
“
, P. Fraternali: “Basi di dati Architetture e linee di evoluzione”, McGrawHill, 2003
Riferimenti:
S.Haag, M.Cumming, D.J.McCubbrey: “Sistemi Informativi aziendali”, McGraw-Hill, 2004
N.Wirth: "Algorithms + Data Structures = Programs", Prentice-Hall, INC.
A.C. Lorents, J.N. Morgan: “Database systems”, The Dryden Press,
C.J.Date: "An Introduction to Database Systems", Addison-Wesley Pub.Company
G.Martella, Castano, Samarati: "Sicurezza delle basi di dati", mondadori informatica
B.Fadini, C.Savy: "Fondamenti di informatica Fondamenti teorici", Liguori Editore
Appunti e articoli consigliati durante lo svolgimento del corso.
Nota:
Come si puo’ dedurre dal programma, il Corso vuole fornire le nozioni fondamentali per:
1) progettare Basi di Dati usando il modello di progettazione Entity-Relationship;
2) realizzare un Sistema software con riferimento ad una Base di Dati particolare, partendo da un progetto ed
utilizzando le Strutture dati scelte in base alle caratteristiche logiche e fisiche piu’ idonee per il funzionamento
del Sistema stesso.
Questo e’ il lavoro da svolgere come tesina, che nell' anno corrente viene realizzato sugli elaboratori del Laboratorio
del DEEI con l’ utilizzo di software applicativo, di rete e di S.G.B.D. come Access, MySql, Oracle con l’ obiettivo
di applicare le nozioni apprese ed anche realizzare strumenti utili in ambienti vari.
Indirizzi degli appunti e degli esempi
http://webdeei/didattica/Informatica/basi di dati/db2005
//serving4/arc_stud/Carmin/ db2005
3
Anna Maria Carminelli Gregori: Appunti su d.b. parte1 A.A. 2005
basi di dati o data base (d.b.)
Il Corso vuole evidenziare 2 aspetti fondamentali del d.b.
ossia Progetto ed Uso.
PRIMO il progetto che comporta un’ analisi approfondita
dell’ ambiente che si vuole “rappresentare”. Il d.b. si puo’
intendere come la “rappresentazione ben formata” di un
ambiente (una Scuola, una Chiesa, un gruppo di lavoro….)
con le sue funzioni primarie (COSA si vuole realizzare in
quell’ ambiente) ed i suoi dati fondamentali (Studenti,
Praticanti, Utenti …)
POI l’ uso ossia l’ utilizzo di Software per memorizzare e
gestire la rappresentazione “ben formata”. Il PRIMO e’ l’
aspetto concettuale, l’ altro e’ l’ aspetto pratico che
comporta l’applicazione di un Software che puo’ essere
complesso e particolare. Occorre conoscere entrambi ossia
il Corso vuol far conoscere:
 Come si progetta un d.b.
 Come e’ fatto e come si usa il software di gestione del
d.b
 Le strutture informative utilizzabili dal software di
gestione
Per iniziare due domande:
A chi serve? Può servire a tutti: Aziende e Privati cittadini,
hoppisti, collezionisti …
A che serve? Meglio un esempio per rispondere a questa
domanda. L’ ing. Alex viene incaricato di controllare la
situazione del magazzino della Società dove lavora. Non
essendo un’ esperto di ”Software di gestione di basi di dati“
4
Anna Maria Carminelli Gregori: Appunti su d.b. parte1 A.A. 2005
decide di fare un programma in C++, ma dopo alcuni
tentativi non riusciti desiste.
Un amico gli suggerisce di usare Access, spiegandogli
approssimativamente come funziona e suggerendogli di
iniziare a progettare un piccolo d.b. che gli serva per il
controllo. Cosa mettere nel d.b. ossia quali dati serviranno
al controllo? Ci sono:
Prodotti che vengono usati nella Società;
Fornitori che riforniscono la Società in base ad Ordini
precisi;
Ordini dei Prodotti in fase di esaurimento da inviare a
Fornitori.
Prodotti, Fornitori, Ordini, appaiono come 3 oggetti da
prendere in considerazione. Ogni Prodotto non è un “dato
atomico”, ma “strutturato” nel senso che per essere
identificato avrà bisogno di un Codice identificativo e poi
di altri “attributi” o caratteristiche come il suo nome, la
quantità presente nel Magazzino e la quantità minima
(soglia) che indica la necessità di un rifornimento: queste
caratteristiche sono i campi che vengono a formare un
“record“. L’ insieme di questi record si può percepire come
una “tabella” di record.
Così Alex pensa di progettare il suo piccolo d.b. come
formato da 3 tabelle: Prodotti, Fornitori, Ordini. Ogni
Fornitore avrà un Codice identificativo, un nome, un
indirizzo… Ogni Ordine avrà il Codice identificativo del
Fornitore al quale inviarlo, il Codice identificativo del
Prodotto da ordinare, la data di invio. Per testare che tutto
funzioni Alex inserisce nelle 3 tabelle qualche valore di
prova.
5
Anna Maria Carminelli Gregori: Appunti su d.b. parte1 A.A. 2005
Queste 3 tabelle si possono vedere nel Primodb fatto in
Access: il loro contenuto compare anche alla pagina
seguente. Si puo’ notare che tra i prodotti solo uno é al
limite di soglia e quindi va ordinato... e questo si potrebbe
fare anche a mano, ma come detto, si tratta solo di una
situazione di prova con pochi dati!
Per procedere in modo generale (che vada bene anche per
tanti prodotti) occorre costruire un’ “interrogazione” ad
Access (una “query”) del tipo: “Seleziona quei Prodotti
che hanno raggiunto la quota minima e con un Ordine
preciso congiungili ai rispettivi Fornitori”. E’ proprio la
Query che si vede nel Primodb e si ritrova alla pagina
seguente. Il risultato della query può servire per inviare l’
ordine con una letterina di accompagnamento come appare
6
Anna Maria Carminelli Gregori: Appunti su d.b. parte1 A.A. 2005
anche alla pagina seguente dove appare un “report” di
Access la cui composizione è molto semplice. E per
aggiornare Ordini? Si può fare con un’ altra query di accodamento,
come Ordini Query, ma subito è necessaria una considerazione essenziale:
perché occorre tirare in ballo la tabella Ordini ?
Proprio per come è stato pensata la struttura del d.b. in cui
la tabella Ordini contenendo sia il Codice identificativo del
Fornitore, sia quello del Prodotto fa da tramite tra le 2 altre
tabelle come si vede nella Struttura della query, che in
questo caso è pure quella del d.b. ed è riportata anche alla
pagina seguente (figura 2).
Ci sono tante altre cose da dire tra cui una importante
riguarda i Codici identificativi che esistono per Prodotti e
Fornitori, ma NON per Ordini in quanto un Ordine è
identificato univocamente dai Codici Identificativi di
Prodotti, Fornitori e dalla data come si vede nella Struttura
della Tabella Ordini. Qui i 3 Codici suddetti sono
contrassegnati da una Chiave: la Chiave Primaria che per
Fornitori e Prodotti è semplicemente il relativo Codice
Identificativo, mentre per Ordini è “composta …. ma se ne
riparlerà! L’ esempio vuole indicare
1. le possibilità e la facilità d’ uso di Access e
2. (soprattutto) che ogni problema va risolto usando gli
strumenti appropriati.
7
Anna Maria Carminelli Gregori: Appunti su d.b. parte1 A.A. 2005
8
Anna Maria Carminelli Gregori: Appunti su d.b. parte1 A.A. 2005
… l’ esempio può ampliarsi considerado Clienti interessati ai Prodotti, ma
che non devono ficcare il naso tra i Fornitori. Come fare ? Si vedrà, ma
intanto alcune domande introduttive e le relative risposte da scegliere
domande
risposte
*Che cos'e' un d.b.? 1) un sistema 2) un insieme di archivi integrati 3)
software
Motivazioni ?
1) correlare i dati
2) accessi piu’ rapidi 3) facilita’
d’ uso
Che cos'e' un File System ?
1) sistema di file 2) un file di S.O.
Che cos'e' un Data Base Management System ?
1) un file 2) data base per S.O.
3) sistema per
gestire file
3) sistema per
gestire il d.b.
Che cos'e' un Sistema Informativo?
1) un file di S.O. 2) sistema per gestire file 3) un sistema per
organizzare e gestire informazioni
**Che cos'e' un Sistema Informatico?
1) sistema per gestire file 2) tipo di Sistema Informativo 3) parte
automatizzata del Sistema Informativo
DEDUZIONI
Per progettare un d.b. (che è un … cfr.* )
occorre un’ analisi approfondita del pre-esistente ambiente in cui il d.b.
deve essere inserito ossia un’ analisi del ...(cfr.**) preesistente.
In sostanza lo scopo e’ AUTOMATIZZARE in modo OTTIMALE la
gestione di informazioni.
NOTA su Dati & Informazioni:
i Dati descrivono un oggetto come la temperatura dell’ aria, il costo di
un’ automobile, mentre per Informazioni si intendono i Dati che
consentono di acquisire conoscenza (più o meno esatta), di fatti o di
situazioni. Per es. dovendo acquistare un’ automobile il suo costo
9
Anna Maria Carminelli Gregori: Appunti su d.b. parte1 A.A. 2005
rappresenta un’ Informazione per l’ acquirente, mentre la temperatura.
dell’ aria è un Dato che non ha significato in questo contesto.
base di dati e i suoi 2 Aspetti fondamentali:
1. Progettazione della base di dati;
2.Utilizzo del Sistema di gestione di basi di dati.
1. Progettazione (IMPORTANZA FONDAMENTALE)
 Cosa si vuole ottenere (i Desiderata);
 Cosa occorre memorizzare per ottenere i Desiderata.
2. Utilizzo
Come usare i Sistemi a disposizione (manuali, help …)
Che cos'e' il D.B.? in prima approssimazione:
 e’ un insieme di dati persistenti (archivi, file di dati ossia
informazioni codificate),
 condivisibili,
 organizzati in modo integrato,
 eliminando le ripetizioni di informazioni
(ridondanza
0 indipendentemente dal loro volume.
Motivazioni:
 compattezza & correlazione tra i dati,
 velocita’ di recupero dei dati,
 facilita’ di gestione e di aggiornamento con (parziale o totale)
eliminazione del lavoro di manutenzione dei file,
 funzionante anche in modo concorrente, in rete.
File System (F.S.) e Data Base Management System:
per le Motivazioni precedenti un File System/O.S. non basta:
occorre un D.B.M.S. (Data Base Management System) ossia un
Sistema Gestore del d.b. che estenda le funzioni del F.S. come
indicato anche in seguito.
10
Anna Maria Carminelli Gregori: Appunti su d.b. parte1 A.A. 2005
Intuitivamente i programmi di gestione del d.b. possono elaborare ed
organizzare i Dati secondo le necessità dei fruitori del prodotto finale. In
pratica è quindi possibile conservare Dati di diverso tipo, ma attraverso
opportuni strumenti di interrogazione, identificare solamente quelli
effettivamente voluti, ovvero le Informazioni” nel senso già indicato.
Schema del Software di Sistema:
Utenti del
d.b.
Programmatori
di Sistema
d.b.
b management system
Utenti Ling.
alto livello
Utenti
interattivi
Programma
nel ling.
Interprete
.
Metodo di Accesso
Buffer Manager / Scheduler
Chiamate di Sistema
GESTORE I/O
Il Software di Sistema fornisce metodi di accesso:
_ utilizzabili direttamente dai “ programmatori di
Sistema”;
_ che diventano servizi base per la gestione di d.b.
_ integrabili con altri strumenti (come il Buffer
Manager e lo Scheduler) tipici dei D.B.M.S.
11
Anna Maria Carminelli Gregori: Appunti su d.b. parte1 A.A. 2005
AUTOMATIZZARE UN AMBIENTE: il suo SIGNIFICATO e’
illustrato con lo schizzo seguente:
Porzione del
Mondo Reale
Definizione dei TIPI
di oggetti e di funzioni
Astrazione  Tipizzazione; Oggetti  Dati (atomici o composti)
(NOTA: informazione codificata  dato !!)
Tipizzazione: aiuta a risolvere il problema dell’ ambiguita’
in quanto impone regole nella costruzione/interpretazione
(codifica/decodifica) di ogni tipo di dato. E’ questo il
problema tipico del riconoscimento di oggetti in grafica,
robotica,…
Tipico esempio di ambiguita’ e’ anche quello che si ritrova
negli ambigrammi = sequenze ambigue di segni grafici
ambigui (vedere l’ ambigramma originale di Hofstadter
Siena=Palio !)
12
Anna Maria Carminelli Gregori: Appunti su d.b. parte1 A.A. 2005
…perche’ strutturare i dati ?
Le motivazioni si possono cosi’sintetizzare:
 elaborazione +efficiente  minore complessita’
algoritmo;
 elaborazione +razionale  indipendenza “fisica” e
“logica” dei dati ossia indipendenza dallo loro posizione
e rappresentazione. Cio’ si puo’esprimere anche cosi’:
“Le applicazioni non devono essere modificate in seguito
a modifiche dell’ organizzazione fisica ne’ a modifiche
dell’ organizzazione logica dei dati” (Albano-Orsini :
“Basi di dati”, Boringhieri) … ma come si fa? con filtri
di rappresentazione aggiuntivi! La maggiore razionalita’
si puo’ anche semplicemente intendere come la
possibilita’ di svincolarsi dalla sequenzialita’ fisica: cio’
e’ necessario quando i dati devono apparire con
sequenzialita’ diverse;
 possibilita’ di scegliere tra molteplici tipi e modelli di
strutture informative o strutture dati:
tipo statico
(es. array a dimensione fissa);
“ dinamico (“ file “ “
variabile)
modelli omogenei e non, lineari, gerarchici …
Tipizzazione dei dati e relativa strutturazione con Scelta, analisi,
verifica dei TIPI di dati: I criteri di scelta di un tipo o di un modello
sono basati su parametri di valutazione come:
 Caratteristiche del modello strutturale (es. cardinalita’ fissa o variabile);
 Memoria disponibile e sua permanenza/volatilita’ (es. dimensioni
memoria, tipo di memoria …);
 Operazioni da effettuare e loro frequenza.
Esempio: in C.M. si sceglie una struttura statica (array) quando non si
prevedono frequenti modifiche (cancellazioni, inserzioni) altrimenti si
13
Anna Maria Carminelli Gregori: Appunti su d.b. parte1 A.A. 2005
sceglie una struttura dinamica. Quale tipo di struttura dinamica ? La scelta
e’ fatta in base ai parametri di valutazione come i seguenti.
 Caratteristiche del modello (sequenziale come un testo? gerarchico
come un organigramma?);
 Memoria disponibile (1, 2, … k puntatori ?);
 Operazioni da effettuare e loro frequenza (ricerche? solo copie ?).
Modelli di strutture informative dinamiche:
 (unidirez.) semplice: |__|->|____|->|____|->|____| Lista lineare e
doppia con i puntatori nei due sensi;
 albero binario (2 direzioni per nodo cfr. db2005p3):
d
/
\
b
f
/
\
/ \
a
c e
g
 albero a n vie (n direzioni per nodo cfr. db2005p3);
25
30 40
10 20
5 7 8 9 13 15
21 24
27 28
32 38
41 50
 grafo (rete) = { alberi | array }
Per grafi da rappresentare con alberi cfr. 1 pagina da J. Martin.
14
Anna Maria Carminelli Gregori: Appunti su d.b. parte1 A.A. 2005
Nei linguaggi ad alto livello che utilizzano il paradigma Object
Oriented con definizione e gestione di tipi astratti come class,
actor… ad ogni tipo di dato sono associate tutte e solo le
operazioni disponibili per elaborare gli oggetti di quel tipo. (Non e’
che un’ estensione dell’ idea gia’ implementata in alcuni linguaggi di
programmazione come il Pascal, dove al tipo intero sono associate le
operazioni dell’ aritmetica intera, ed al tipo float quelle dell’ aritmetica non
intera!)
Le operazioni piu’ comuni sulle strutture informative, anche
aggregate (o tra loro o in array o in file), sono le seguenti:
1. Accesso al singolo elemento o nodo della struttura per
interrogazioni e/o per aggiornamenti;
2. Inserzione di un nuovo nodo;
3. Cancellazione di un nodo;
4. Ricerca di un nodo di data chiave=campo identificatore;
5. Ordinamento dei nodi; (esempio in primodb!)
6. Copiatura dei nodi;
7. Fusione (merging) di 2 o + strutture informative;
15
Anna Maria Carminelli Gregori: Appunti su d.b. parte1 A.A. 2005
8. Suddivisione di una struttura informativa in 2 o + strutture
informative.
 L’operazione 2 inserendo i nodi costruisce la struttura
informativa. L’ inserimento puo’ essere fatto con diversi criteri
costruttivi, per esempio lineare per una lista lineare dove i nodi
si inseriscono uno dopo l' altro o gerarchico per gli alberi dove i
nodi ai livelli piu’ alti possono risultare privilegiati (come per la
ricerca di un nodo di data chiave cfr. db2005p3).
 Facilita’ di inserimenti e cancellazioni in liste e alberi: basta
“aggiornare” 2 indirizzi, ma per la lista c’e’ un unico tipo di
accesso e ricerca di un elemento: sequenziale ! SEGUE che:
 l’operazione 4 risulta “penalizzata” in una lista lineare. Si
deduce che la lista lineare e’ valida per elaborazioni sull’ intera
struttura (come la 6 = Copiatura). Per ricerche: necessita’ di un
altro modello !! a meno di un numero limitato di nodi (100).
In generale per scegliere la struttura informativa da adottare
si usa come parametro di valutazione P = lunghezza di
ricerca media di un nodo della struttura (pari al numero medio di
nodi attraversati per raggiungere quello cercato).
In lista lineare di n nodi: P = O(n)
“ albero: P = O(h) con h = altezza dell’ albero.
La differenza e’ dovuta al criterio costruttivo che negli
alberi puo’ produrre un cammino di ricerca che non
attraversi tutti i nodi, ma solo alcuni, in media un numero
pari all’altezza dell’ albero.
… occorre diminuire l’ altezza dell’ albero e renderla
una funzione logaritmica di n come si vedra’ in db2005p3.
In Memoria centrale comunque la lista e’ una struttura valida per
elaborazioni globali dell’ oggetto che rappresenta (es. perimetro
16
Anna Maria Carminelli Gregori: Appunti su d.b. parte1 A.A. 2005
di una figura di n vertici da copiare sul video), l’ albero (binario in
Memoria centrale, a n rami su disco) e’ da preferire per ricerche
di un nodo, specialmente se il Numero Totale di nodi supera il
centinaio.
fornisce l’ indicazione della complessita’ della struttura
legata alla complessita’ degli algoritmi che l’utilizzano.
P
I dati devono avere strutture adeguate per essere memorizzati e gestiti
efficientemente, come indica il titolo del testo di N. Wirth (Prentice-Hall):
Algorithms + Data Structures = Programs.)
Tutte queste considerazioni devono essere “implementate”
nei DBMS per facilitare le 8 operazioni viste sulle strutture
informative usate  i DBMS devono mettere a disposizione
degli utenti strumenti validi ossia realizzati con algoritmi
efficienti. Tipico strumento sempre presente ed usato in ogni
DBMS e’ il SORT per l’ordinamento di una struttura: la sua
complessita’ verra’ quindi discussa in ambito generale.
COMPLESSITA' DI PROBLEMI, DI ALGORITMI E
DI PROGRAMMI (richiami)
Relativamente ai problemi decidibili interessa la COMPLESSITA'
computazionale indicata nel seguito (in una semplice impostazione
intuitiva) semplicemente come COMPLESSITA':
Dato un problema X con specifica S
per risolverlo, si possono trovare N algoritmi A
e M programmi P
La COMPLESSITA' di un problema, con delimitazioni inferiore e
superiore, si puo’ collegare alla COMPLESSITA' degli algoritmi (e
programmi) risolutivi: per definirla si usa un modello di “costo” di
programmi e algoritmi che si precisa nel seguito. Intanto:
efficienza di A (= complessita’ computazionale):
17
Anna Maria Carminelli Gregori: Appunti su d.b. parte1 A.A. 2005
indipendente dall’ elaboratore
efficienza di P: dipendente dall’ elaboratore.
e : EFFICIENZA DEL PROGRAMMA P
dipende da:
 efficienza del relativo algoritmo (che e’ quindi interessante!)
 spazio di memoria S
 tempo di calcolo T (legato a quello di ogni istruzione)
 efficienza del software di sistema (traduttore, supporto runtime,…)
e = e (S,T)
Per programmi funzionalmente equivalenti generalmente risulta:
S1 > S2  T1 < T2
(tipico esempio: packed array)
Quando S e’ noto e/o costante
e = e (T)
fornisce una misura del “running time” t di P.
18
Anna Maria Carminelli Gregori: Appunti su d.b. parte1 A.A. 2005
Per misurare l' efficienza ossia il COSTO di un programma si considera il
suo "running time" t che in ipotesi semplificative dipende da:
 n: dimensione dei dati;
 v: valore dei dati (alcuni valori innescano cicli?)
 t= funz(n,v) ......
ma un programma e' fatto di istruzioni e comprende m classi di istruzioni
(rispetto ai Cicli di CPU usati) con:
_ni istruzioni della classe i (comunque dipendenti da n e v )
_t i tempo medio di esecuzione di 1 istruz. della classe i
m
t (n) =
 (n i t i)
i =1
Piu' interessante e' C = Complessita' (Costo) DI ALGORITMO !
Ipotesi semplificative:
 C = c (t)
(solo dipendenza temporale);
 i costi delle istruzioni semplici (assegnazione, lettura/scrittura,
confronto) sono tutti uguali e posti = 1;
 i costi delle istruzioni composte sono = SOMMA dei costi delle
istruzioni semplici o numero delle volte che viene eseguita l’
istruzione “dominante”: (spesso si usa il concetto di istruzione
“dominante” avente frequenza maggiore delle altre e proporzionale al
costo dell’ algoritmo -per es. il confronto nel problema del sort-)
 costo ~ numero di istruzioni da eseguire che e' funzione dell'
insieme {I} dei dati in ingresso;
 n: dimensione dei dati che caratterizza {I}.
In queste ipotesi il "running time" t (e quindi C ) si puo’ esprimere con:
t (n) = a + b f(n)
forma binomiale data da:
 una parte costante a; (inizializzazione)
 "
" dipendente da n (il ciclo, la scansione …) tramite la funzione
f (detta funzione di complessita') che attiene al tipo di elaborazione (
scansione lineare ? ciclo al quadrato ? …), e un fattore = “tempo di
esecuzione b” costante per ogni unita' di dato.
Interessa soprattutto valutare il
Costo per n ELEVATO = COSTO ASINTOTICO  lim t(n)
n

e NEL CASO PEGGIORE (meno spesso nei casi migliore e medio!)
19
Anna Maria Carminelli Gregori: Appunti su d.b. parte1 A.A. 2005
COMPLESSITA' DI PROBLEMI, DI ALGORITMI E
PROGRAMMI
COMPLESSITA' DI PROBLEMI:
delimitazioni: inferiore (intrinseca)
e superiore legata al
Costo degli algoritmi risolutivi
Esempio del SORT: n log2n
n2
COSTO = Funzione che utilizza un modello dipendente (solo
asintoticamente ed a meno di costanti
moltiplicative) dal numero delle istruzioni
necessarie ad arrivare nel caso peggiore
al risultato finale per un volume di dati pari a n.
Il numero delle istruzioni necessarie puo’
essere sostituito da quello che indica quante
volte viene eseguita l’istruzione dominante con
frequenza > delle altre e proporzionale al
costo dell’ algoritmo.
… ma quali sono le possibili Funzioni ?
Funzioni f(n)
logaritmiche:
log2 n
(n log2 n)
polinomiali:
ni
esponenziali:
in
…
(per es. 2n)
la complessià esponenziale E’ "NON trattabile"
20
Anna Maria Carminelli Gregori: Appunti su d.b. parte1 A.A. 2005
COMPLESSITA': DELIMITAZIONE SUPERIORE
Definizione
Un algoritmo ha complessita’ (superiore, ma spesso l’
aggettivo e’ omesso) O( f(n) ) se
nel caso peggiore ha un costo
costo < a + b f(n)
(sono note le risorse sufficienti per es. S)
f(n) delimita superiormente il costo
- interessa f(n) minima
es. 1) Complessita’ algoritmo Quick_Sort:
caso peggiore f(n) = n2
Un problema ha complessita’ (superiore) O(f(n)) se
almeno uno degli algoritmi risolutivi ha costo a + b f(n)
es. 2)
Problema del Sort: tanti algoritmi risolutivi:
Bubble sort;
sort selection;
Quick_Sort …
per questi nel caso peggiore f(n) = n2
la complessita’ superiore = O(n2)
… anche se per l’ algoritmo di Heap_sort nel caso
peggiore: f(n) = n log2 n
21
Anna Maria Carminelli Gregori: Appunti su d.b. parte1 A.A. 2005
COMPLESSITA': DELIMITAZIONE INFERIORE
Definizione
Un algoritmo ha almeno complessita’ ( g(n) ) se
nel caso migliore ha un costo
costo  c g(n)
(sono note le risorse necessarie )
g(n) delimita inferiormente il costo
- interessa g(n) massima
es. 1) Complessita’ algoritmo Quick_Sort:
caso migliore g(n) = n log2 n
Un problema ha complessita’ inferiore (g(n)) se
tutti gli algoritmi hanno costo almeno g(n)
es. 2) Problema del Sort: tanti algoritmi risolutivi:
Bubble sort;
sort selection;
Quick_Sort …
per tutti questi algoritmi nel caso peggiore f(n) = n2
nel caso migliore g(n)  n log2 n
la complessita’ superiore = O(n2)
la complessita’ inferiore =  (n log2 n)
NON ESISTE un algoritmo risolutivo con
COMPLESSITA’ < n log2 n
PER tutti  e’ la complessita’ “intrinseca” del problema.
22
Anna Maria Carminelli Gregori: Appunti su d.b. parte1 A.A. 2005
La complessita’ minimale del problema e’ detta intrinseca.
Se per un problema la complessita’ di un algoritmo
risolutivo coincide con la complessita’ intrinseca del
problema l’ algoritmo e’ ottimale. (Per es. l’ heap sort).
Piu’ formalmente un algoritmo A che risolve il problema P
si dice ottimale se:
 l’ algoritmo A risolve il problema P con un costo
O(g(n));
 la complessita’ del problema P ha una delimitazione
inferiore (g(n)).
Trovare la complessita’ intrinseca e’ un problema
matematico.
Come esempio di Complessita' intrinseca si esamina il
problema del SORT e la sua Complessita' intrinseca
considerando 
 il problema matematico,
 la sua soluzione,
 l’ albero di decisione.
23
Anna Maria Carminelli Gregori: Appunti su d.b. parte1 A.A. 2005
ES. del SORT: dovendo ordinare n elementi vale il
seguente risultato matematico:
IL NUMERO DI CONFRONTI NECESSARIO E’
ALMENO log2n!
(Perche? n! esprime tutti i possibili ordinamenti tra gli n elementi confrontati a 2 a 2)
MA log2n! si puo’ cosi’ trattare:
 n!  n(n-1)(n-2)…(n/2)  (n/2) (n/2)
 log2n!  log2 (n/2) (n/2)= n/2 log2 (n/2)  n/2 log2 n =
= n/2 log2 n(1/2) = n/4 log2 n .
purche’ risulti n  4.
(Perche’? Se n  4 risulta: n/2  n )
Quindi a meno della costante 4 la delimitazione inferiore
del SORT e’  (n log2 n).
Per rappresentare i confronti e i possibili ordinamenti di n=3 variabili a,b,c,
si puo’ considerare un “albero di decisione” ossia un modello di albero
binario esteso (cfr. db2005p3) cosi’ fatto:
Nell’ albero binario esteso ci sono 2 tipi di nodi:
ab?
si /
\ no
b  c?
si /
abc
intermedi e terminali (con i caratteri in corsivo). I
nodi intermedi e la radice contengono un confronto, gli
ac?
\ no
si /
altri un possibile ordinamento ottenuto sul
\ no
ac? b<ac
si /
\ no
si /
cammino relativo a ciascuno di essi.
bc?
\ no
L’ insieme dei cammini (=3!)
individua tutti i possibili
24
Anna Maria Carminelli Gregori: Appunti su d.b. parte1 A.A. 2005
acb
c<ab
bc<a
c<b<a
ordinamenti, mentre il cammino
+lungo individua h (= altezza dell’ albero di decisione) che risulta hlog2n! 
L’ albero di decisione con n=3, fornisce la rappresentazione del significato di
log2n! (=lunghezza del cammino).
Considerazioni:
COMPLESSITA' DI PROBLEMI decidibili: correlata alla
COMPLESSITA' degli algoritmi risolutivi;
COMPLESSITA' algoritmo  t(n) = a + b f(n)
con f funzione lineare quadratica, logaritmica …
esponenziale (differenza notevole!! cfr. tabella
Funzioni)
ed n dimensione dell’ input.
Semplicita’
Complessita’
Attributo richiesto
agli algoritmi per:
facilita’ di comprensione,
verifica di correttezza,
facilita’ di correzione,
…
Efficienza
Attributo richiesto agli
algoritmi per esecuzioni
+veloci; comporta:
rappresentazioni e
procedimenti +razionali,
+sofisticati
Costo umano minore
Importante se dimensione
input limitata (n < 30)
ed inoltre se frequenza di
esecuzione bassa.
Costo macchina minore
25
Anna Maria Carminelli Gregori: Appunti su d.b. parte1 A.A. 2005
Per completare l’esempio del SORT si ricordano ora (col fine di metterne in luce
l’ analisi di complessità) alcuni metodi e ALGORITMI DI ORDINAMENTO di
TIPO diverso secondo le dimensioni dell’ insieme da ordinare e riguardano:
 costruzione array ordinato in C.M. dall'inizio &
riordinamento in C.M. degli elementi di un array: detti di SORT interno;
 riordinamento elementi di un file sequenziale detto di SORT esterno.
Terminologia:
SPESSO ARRAY E FILE SONO INDICATI COME LISTE (O SEQUENZE),
SEQUENZA ORDINATA DI ELEMENTI COME "RUN".
IMPORTANTI al fine DI VALUTARE LA COMPLESSITA' dell’ ALGORITMO:
#passi e #confronti (C) ; memoria occupata(S);
#scambi (M=movimenti).
In C.M operazione DOMINANTE. = CONFRONTO, operaz. +pesante = SCAMBIO
Pardigma spesso usato: DIVIDE ET IMPERA (Divide and Conquer): finche’ la lista
da ordinare > 1 run, dividila (Splitting) in due inferiore e superiore, ordina
entrambe e quindi fondile (merging).
METODI (Algoritmi) DI ORDINAMENTO
E ELEMENTI DI TIPO:
_ semplice e ordinabile (interi, caratteri, stringhe);
_strutture con campo "chiave" (=identificatore del record) ordinabile +altri campi
1) selezione (per minimi successivi)
2
complessita’ = O(n )
2) scambi (bubble sort)
2
complessita’ = O(n )
3) inserzione
2
complessita’ = O(n )
26
Anna Maria Carminelli Gregori: Appunti su d.b. parte1 A.A. 2005
4) ad albero: doppio indice (quicksort)
heap-sort
5) distribuzione e fusione
Tutti metodi applicabili a array; metodo 5 anche e SOPRATTUTTO per file.
SCELTA DEL METODO (per liste composte da un numero di elementi >10)
cardinalita’ della lista e suo ordine parziale
dimensione della memoria
dimensione campo chiave
4
ORDINAMENTO CON DOPPIO INDICE (quicksort)
1) effettuare spostamenti in array in modo da ripartirlo in due parti
sinistra (ps) e destra (ds) che, rispetto a X (elemento di separazione), siano:
elementi ps  X  elementi ds
2) ripetere per ps e ds ricorsivamente fino all'ordinamento completo
ALGORITMO DI SEPARAZIONE
_ si sceglie un valore della lista (p.e. l'ultimo) come elemento di separazione X
_ si cerca da sinistra il primo elemen. > X e lo si sposta a destra di X se c' e’ un
elem.
_ si cerca da destra il primo elemen. < X e lo si sposta a sinistra di X se c' e’ un el.
_ si prosegue da sinistra e da destra per gli elementi successivi
finche’‚ la ricerca di sinistra non si "incrocia" con quella di destra
ESEMPIO ALGORITMO SEPARAZIONE
9
s
0
0
1
1
s
1
6
4
LISTA SIN.
5
8
2
X
7
LIS. DESTRA
3
0
d
6
1ø riordinamento
4
5
8
2
7
3
d
2ø riordinamento
6
4
5
3
2
7
8
d
s
s e d si "incrociano": separaz. Finita
9
9
COMPLESSITA' QUICKSORT
27
Anna Maria Carminelli Gregori: Appunti su d.b. parte1 A.A. 2005
2
caso peggiore:
n
“ medio:
n log2 n
non richiede extra memoria
ANALISI QUICKSORT: att.ne allo sbilanciamento!!
Dopo la scelta casuale dell’ elemento di separazione X
(perno) per una lista di N termini si eseguono n confronti,
ma nel caso medio quanti sono gli scambi ?
Se si assume che i termini siano numerati da 1 a N la
rappresentazione della lista finale ordinata e’ la seguente:
Termini < X
|X|
Termini >X
con:
numero dei Termini < X = X-1;
e
numero dei Termini X (compreso X) = N-X+1;
La valutazione del numero presunto di scambi M1,
necessario per arrivare a tale situazione, si puo’ descrivere
elementarmente nel modo seguente:
1. M1 e’ funzione della probabilita’ pertinente ad ogni
termine a sinistra di X di essere stato scambiato e quindi:
M1 = f (prob. (scambio xi con xi< X) *(X-1));
2. si e’ verificato lo scambio se: xi< X ed inoltre
xi era a destra di X;
28
Anna Maria Carminelli Gregori: Appunti su d.b. parte1 A.A. 2005
3. il termine scambiato con xi e’ finito a destra di X tra gli
N-X+1 termini X;
4. dunque al+ potranno esserci stati N-X+1 scambi (=n.o di
casi favorevoli per gli scambi);
5. il risultato e’: prob. (scambio xi con xi< X)= ( N-X+1)/N;
N
6. M1= 1/N  (N-X+1)*(X-1)/N = N/6 –1/(6*N) = O(N)
X=1
SE nel caso fortunato (liste sempre divise a meta’) il n.odi
passi = log2N si ottiene M = O(N log2N).
DEFINIZIONE HEAP (Wirth pag.72 e seg.)
Si definisce heap una sequenza di chiavi hl, hl+1, hl+2 … hr
con: l e r interi, l < r e tali che per i = l, l+1,…r/2
soddisfino alle seguenti condizioni (a): hi< h2*i; hi< h2*i+1;
allora se l=1 risulta: h1< h2; h1< h3;
h2< h4; h2< h5; … etc.
e quindi h1= min(h1, h2, h3 … hr)
La situazione si puo’ rappresentare con un albero binario
memorizzato come un array in locazioni di memoria
consecutive dalla 1 alla r
h1
/
\
h2
h3
/ \
/
\
h4
h5
h6 h7
/ \ / \ / \ / \
29
Anna Maria Carminelli Gregori: Appunti su d.b. parte1 A.A. 2005
h8 h9 ……. etc. …. h15
…………… etc. …..
Segue che gli alberi a torneo costruiti per l’ ordinamento di
una sequenza di termini in modo simile a quelli tipici dei
tornei sportivi (in cui tra le squadre che si affrontano a 2 a 2
sale alla finale solo la squadra vittoriosa sulle sue
avversarie) sono heap in quanto verificano le condizioni
(a).
Quindi trasformare una sequenza in un heap da cui si estrae
la radice puo’ dare un algoritmo di sort efficiente. L’
efficienza si deduce dall’ analisi: l’ algoritmo di Floyd
(1964) lavora “in loco” (memoria richiesta in + quasi
nulla) ed il numero di scambi necessari per l’ ordinamento
finale risulta Mmedio = N/2 log2 N.
L’ algoritmo di Floyd (Heap-Sort) si basa su 2 idee:
1. ogni sequenza di n termini dalla meta’+1 in su e’ un heap:
impossibile confutarlo! Es. data una sequenza di 8 termini:
6
72
12
55
94
18
44
67
hn/2+1 hn/2+2 … hn
non esiste il termine di indice 2*( n/2+1).
Si puo’ allora estendere l’heap ai termini della prima mezza
sequenza con n/2 passi e log2 n/2 confronti con eventuali scambi
“in loco”. Cio’ si realizza con un ciclo su i che, inizializzato a
n/2 viene decrementato di 1 ad ogni passo: in ogni passo e’
attivata una procedura sift(i,n) che ripete le seguenti operazioni:
 posto h=2i, fintantoche’ risulta h n:
 e’ scelto il minore tra i termini di indice h e h+1 (se ci sono
entrambi ! se no, e’ posto il minore = termine hesimo);
 confronto tra questo minore e il termine di indice i;
30
Anna Maria Carminelli Gregori: Appunti su d.b. parte1 A.A. 2005
 eventuale scambio e posizionamento di i=h (o h+1) e h=2i.
Dopo l’estensione la seq. dell’ esempio diventa:
6 55 12 67 94 18 44 72
2. Costruito cosi’ l’heap si estrae la radice (primo classificato) e si
scambia con il termine al posto n: l’ ordinamento totale si
ottiene in n-1 passi, attivando ancora la procedura sift(1,n-k)
con k=1,2...n-1. Al passo k si ottiene nel primo posto una
nuova radice con:
numero di scambi  log2(n-k). Poi la radice si scambia col
termine di posto n-k e si prosegue.
Con n-1 passi, il numero di scambi necessario per l’ordinamento
totale risulta:
M= log2 n/2 + log2(n-1) + log2(n-2) + ...+1  nlog2(n-1)
e in media: Mmedio = n/2 log2 n.
COMPLESSITA' - CONFRONTI
METODO
#operaz.
selezione
n(n-1)/2
O(n )
per scambi
n(n-1)/4
O(n )
inserzione
n /2
O(n )
quick(caso medio)
heap-sort
n log2 n
"
O(n log2 n)
"
distrib./fus.
n log2 n
O(n log2 n)
5
2
Complessita’
2
2
2
ORDINAMENTO CON METODO DISTRIBUZIONE & FUSIONE
liste di qualsiasi dimensione:
array o file
tempo ordine n log2 n (complessita')
extramemoria ordine n
31
Anna Maria Carminelli Gregori: Appunti su d.b. parte1 A.A. 2005
FUSIONE (merging)
date due liste ordinate L1 L2
produce L3 (= L1  L2 ) ordinata
DISTRIBUZIONE (splitting)
"distribuisce" una lista non ordinata L
in piu’ sottoliste PARZIALMENTE ordinate.
FUSIONE DI 2 ARRAY
v1 + v2 => vf
min(t1v1 , t2v2) ---> vf
SCHEMA DI PROCEDURA
procedure Fusione V
begin
while (v1 e v2 non esauriti) do
if (t1v1 < t2v2 ) then inserisci t1v1 in vf
e avanza su v1;
else inserisci t2v2 in vf e avanza su v2;
end;
if (v1 esaurito) then inserisci residui di v2
in vf;
else inserisci residui di v1
in vf;
end;
32
Anna Maria Carminelli Gregori: Appunti su d.b. parte1 A.A. 2005
FUSIONE DI 2 FILE: f1 + f2 => ff
stesso algoritmo: invece di avanzare gli indici di array avanzano i puntatori ai file
SCHEMA PROCEDURA FUSIONE FILE
procedure Fusione F (SEMPLIFICATA!!!!)
begin
while (f1 e f2 non esauriti) do
if (t1 < t2 ) then inserisci t1 in ff e avanza su f1;
else inserisci t2 in ff e avanza su f2;
end;
if (f1 esaurito) then inserisci residui di f2 in ff;
else inserisci residui di f1 in ff;
end; (per non SEMPLIFICATA vedere esempio!)
SORT-MERGE “naturale” A 4 FILE AUSILIARI
a
dopo la 1 distribuzione fonde f1 + f2 alternativamente in f3, f4
fonde f3 + f4 alternativamente in f1, f2
e cosi’ via... finche’‚ f1 e f2 (oppure f3 e f4) sono entrambi totalmente
ordinati
fonde f1 + f2 (oppure f3 + f4) in ff
a
elimina distribuzione, ad eccezione della 1
ESEMPIO A 4 FILE di sort-merge “naturale”: si avvale degli ordinamenti naturali
sia in fase di splitting che di merging: splitting di ff su f1&f2, poi merging su f3 &f4
f1
4
3
6
1
8..
ff
4
2
7
3
6
f2
2
7
5
..
..
f3
5
1
..
f4
2
8
3
4
7
1
8
..
..
..
(da distribuire)
5
6
..
MERGE di f3 & f4 su f1 e f2: quindi MERGE FINALE su ff
f1
ff
f2
1
2
3
4
5
6
7
( run ordinato)
2
3
4
5
6
7
8
1
8
..
..
..
..
(run ordinato)
(ordinamento totale)
33
Anna Maria Carminelli Gregori: Appunti su d.b. parte1 A.A. 2005
TIPI di MERGING
......… ma come si fa a calcolare il numero di passi per arrivare
all’ ordinamento totale ?
Avvalendosi degli ordinamenti naturali imprevedibili si puo’
valutare solo un limite superiore: per questo si usa spesso il sortmerge bilanciato in cui la lunghezza del run si raddoppia ad ogni
passo di merging e quindi il numero di passi diventa: log2 n.
ESEMPIO
1) SEQUENZA DI N=5000 TERMINI DA ORDINARE
E run DI LUNGHEZZA INIZIALE L0 = 1000 TERMINI
(ordinati in C.M.)
Avendo solo 3 file a disposizione (A, B, C) si ha:
il run 1o va su A
Il merge su C produce un 1o run ordinato lungo
2000
il run 2o va su B
“ “ 3o “ “ A
Il merge su C produce un 2o run ordinato lungo
2000
“ “ 4o “ “ B
“ “ 5o “ “ A
Su C va un 3o run ordinato lungo 1000 (la coda)
La distribuzione successiva di C su A e B produce:
il run 1o va su A
Il merge su C produce un 1o run ordinato lungo
4000
il run 2o va su B
“ “ 3o “ “ A
Su C va un 2o run ordinato lungo 1000 (la coda)
La distribuzione successiva di C su A e B produce:
il run 1o va su A
Il merge su C produce solo 1 run ordinato lungo
5000
il run 2o va su B
PER L' ORDINAMENTO FINALE e’ necesario un numero
di passi npassi= log2 N/ L0
34
Anna Maria Carminelli Gregori: Appunti su d.b. parte1 A.A. 2005
Per ridurre il numero di passi DUE Problemi:
1. Numero file ausiliari (quanti ?) di cui 1solo per il merge
2. ELIMINARE le fasi di distribuzione (copiatura)
1.ORDINAMENTO FILE - USO DI MEMORIA (per
ridurre file ausiliari … ma non e’ +tanto attuale )
- ordinamento parziale di f (=file) in memoria centrale
- ampiezza memoria disponibile: M
f = n blocchi S1,S2 ... Sn di dimensione  M;
Si M , ordinamento in M, M  fi(esimo file usato)
fusione f1,f2,...fn  f
I blocchi si possono trasferire a gruppi. Si avranno m
gruppi composti da p blocchi con p = n/m.
f = n blocchi
n blocchi = m gruppi di p blocchi ciascuno
(ESEMPIO n=40, m=8, p=5)
Si  M e ordinamento  fi (i= 1...p) (uso di p file)
fusione f1...fp  g1 (1 file per il merge)
Sp+i M e ordinamento  fi (i= 1...p) “ “ “ “
fusione f1...fp  g2 (1 file per il merge)
........
fusione f1...fp  gm “ “ “ “ “
fusione g1...gm  f (MERGE FINALE)
… aumentando il numero p di file diminuisce il numero di
passi necessario PER L' ORDINAMENTO FINALE e
risulta: npassi= logm (n blocchi)
Si noti: qui l’ accento non e’ posto sul numero di confronti
o scambi (da eseguire in C.M.), ma sul numero di passi
35
Anna Maria Carminelli Gregori: Appunti su d.b. parte1 A.A. 2005
perche’ trattandosi di SORT esterno l’ operazione +pesante
riguarda l’ uso di memoria di massa .
2. ELIMINARE le fasi di distribuzione (copiatura, split):
Sort in polifase e Algoritmo di GILSTAD (1964)
… ma avendo 3 soli file occorre sempre fare splitting su 2 e
merging su 1 ??
Tutto dipende dalla distribuzione iniziale dei run: con una
distribuzione particolare si puo’ evitare la fase di split
(distribuzione, copiatura) che non produce alcun incremento all’
ordinamento totale.
Una distribuzione particolare che permette di arrivare al merge
finale senza bisogno di splitting intermedi (in quanto si propaga)
si ottiene usando per 3 file la sequenza dei numeri di
Fibonacci (che lega 3 numeri) applicata al numero dei run
sui 3 file.
Fib (n) = 0, 1, 1, 2, 3, 5, 8, 13, 21 …
Es. partendo con 13 run ordinati questi si possono
distribuire su 2 file secondo la regola:
Fib(7) = Fib(6) + Fib(5)  13 = 8 + 5. Si ottiene:
N.o Tot. F1
F2
F3
Livello=npassi
13
5
8
0 merging (F1, F2)  F3
5
8
0
3
5 “
(F2, F3)  F1
4
5
3
0
2 “
(F1, F3)  F2
3
3
1
2
0 “
(F1, F2)  F3
2
2
0
1
1 “
(F2, F3)  F1
1
1
1
0
0 RISULTATO
0
Se
i file sono m>3 non si usano i numeri di Fibonacci, ma i
numeri ottenuti da Shlegel nel 1894 detti “numeri di Fibonacci di
ordine p”che legano p+2 = m numeri. L’ algoritmo che li usa e’
36
Anna Maria Carminelli Gregori: Appunti su d.b. parte1 A.A. 2005
quello di Gilstad (Wirth pag.105).  Con 6 file e 165 680 100 run in
20 passi si ottiene l’ ordinamento totale! Essendo 2201M e’ evidente il
miglioramento di Gilstad con 6 file.
Deduzioni tratte dall’ analisi degli algoritmi di SORT:
 strutturando i dati in modo diverso si ottengono algoritmi
di complessita’ diversa  dipendenza, legame tra
Complessita’ e Struttura dati usata (nel Sort la struttura
gerarchica –albero binario “ben formato” ossia “bilanciato”
come definito in db2005p3– determina minore complessita’
rispetto alla struttura sequenziale
–array esaminata
sequenzialmente–);
 necessita’ di analizzare i dati e scegliere la struttura
appropriata;
 necessita’ di conoscere i tipi di strutture e la loro
complessita’.
Il problema del SORT e’ stato esaminato proprio perche’ e’
un ESEMPIO tipico dei problemi piu’ antichi affrontati in
informatica e interviene in tanti suoi campi, tipicamente nel d.b.
D.B.
single-user (privato) & multi-users.
D.b. single-user: segue esempio tratto da Date
37
Anna Maria Carminelli Gregori: Appunti su d.b. parte1 A.A. 2005
38
Anna Maria Carminelli Gregori: Appunti su d.b. parte1 A.A. 2005
D.B.
multi-users: per rappresentare le informazioni di interesse
di un Sistema Informativo gestibili da vari utenti.
Sorgono problemi come:
moltiplicando il numero degli utenti si moltiplica il numero
degli archivi ?
l’ utente x puo’ accedere e modificare l’ archivio dell’
utente y?
......
ma chi e’ l’ utente ?
Puo’ essere un processo (programma in esecuzione) che
lavora in modo concorrente con altri; cio’ pone i problemi:
 della consistenza dei dati;
 “
protezione “ “
 degli
accessi concorrenti ai dati (parziale, totale
serializzazione ?)
Soluzione razionale ?
Software adeguato !! D.B.M.S. sempre +complesso!!
Occorre un sistema di gestione automatica … ma di cosa?
NON di archivi tradizionali, ma di informazioni di
interesse fondamentale, strutturate in modo appropriato,
da mantenere consistenti tra loro permettendone o
vietandone l’ accesso.
39
Anna Maria Carminelli Gregori: Appunti su d.b. parte1 A.A. 2005
DEFINIZIONE di d.b. e sue caratteristiche:
insieme di dati fondamentali (organizzati in archivi),
 di interesse per il Sistema Informativo (in cui il d.b. deve
essere introdotto)
 che possono avere grandi dimensioni;
 “ “
simultanei;
essere condivisi tra +utenti anche con accessi
 devono essere affidabili, consistenti tra loro, persistenti,
non ridondanti: per questo sono necessarie procedure di
salvataggio e ripristino (backup & recovery) in caso di
malfunzionamento;
 devono rispondere a requisiti di privatezza (si usano
meccanismi di controllo che salvaguardino da azioni non
autorizzate), di efficienza (complessita’ procedurale
minima), di efficacia (rendimento produttivo ottimale per le
attivita’ degli utenti). Es. processo di traduzione automatica:
l’ algoritmo di ricerca vocaboli corrispondenti deve lavorare
in sintonia con l’ Analizzatore sintattico-semantico di frase.
Obiettivo primario (virtuale): una modifica nell’ ambiente da
automatizzare deve produrre una modifica nel d.b.
Obiettivo sperimentato raggiungibile con un buon progetto:
una modifica nell’ ambiente da automatizzare non deve
propagarsi in un numero incontrollato di modifiche del d.b.
ESSENZIALE un’ attivita’ di progettazione ben fatta !!
40
Anna Maria Carminelli Gregori: Appunti su d.b. parte1 A.A. 2005
Esempio di problemi di correlazione di archivi:
in una piccola societa’ di vendita per corrispondenza
convivono 3 Uffici: Contabilita’ Clienti; Controllo Magazzino,
Ufficio Personale. Con l’ impostazione tradizionale ciascun
Ufficio aveva il suo Archivio con i relativi programmi di
gestione, come indicato nello schema:
Prg. Fatturazione
Archivio Clienti &
Fatture
Prg. Gest.
Magazzino
Archivio Ordini &
Scorte
Prg. Gest. Stipendi
Archivio Dipendenti
Problema: correlare i 3 Archivi per realizzare “incroci” (per es.
un prospetto dei Dipendenti di eta’ > 40 che hanno eseguito
meno di 1000 Fatture/Anno). Nell’ impostazione tradizionale il
problema non e’ facile da risolvere, mentre lo e’ nell’
impostazione d.b. essendoci integrazione, collegamenti tra i
dati. Un modello di collegamento e’:
Fattura
Dipendente
Cliente
Cliente
Fattura
Ordine
Ordini/Scorte
Quanti e quali collegamenti
sono necessari ?
Dipendente
41
Anna Maria Carminelli Gregori: Appunti su d.b. parte1 A.A. 2005
DBMS= Data Base Management Systems: sistema software per
gestire archivi di notevole dimensioni, persistenti, condivisibili.
Presenta una Organizzazione logica dei dati (interessante per
l' utente) che si basa su una organizzazione fisica degli archivi
dipendente dalla “distribuzione” di questi. L'Organizzazione
logica dei dati segue un modello dei dati che "e' un insieme di
concetti per organizzare i dati e descriverne la struttura". Si
dispone cosi' di meccanismi di strutturazione dei dati analoghi
ai costruttori di tipo dei linguaggi di programmazione (p.es. la
struct del C). La strutturazione segue il modello logico dei dati
disponibile nel DBMS usato (aggettivo logico -non illogicosottolinea la caratteristica sostanziale del modello che contiene
una sua organizzazione per es. gerarchica, tabellare...) I
modelli tradizionali sono: gerarchico, reticolare, RELAZIONALE
(piu' diffuso). Estensione a questo modello sono le basi di dati
ATTIVE (con possibilita’ di innescare procedimenti in reazione a dati
eventi: paradigma Evento Condizione Azione ECA) e dalla fine degli
anni 80 le basi di dati ad oggetti che utilizzano il paradigma O.O.
integrandolo nel modello relazionale (o viceversa). Di queste ultime si
accennera’ alla fine della seconda parte (il paradigma Object Oriented
si presume noto); per le basi di dati attive e’ invece importante
indicare subito che esse permettono di realizzare un terzo tipo di
indipendenza oltre all’ indipendenza “fisica” e “logica” dei dati
(indipendenza dalla loro posizione e rappresentazione): indipendenza
dalla conoscenza. Un tipo di conoscenza rappresentata per es. da
regole aziendali (di tipo comportamentale come SE RUBI TI SPEZZO), viene
codificata in trigger (reazioni o regole attive) che si innescano al
verificarsi degli eventi e delle condizioni che contengono. I trigger sono condivisi
42
Anna Maria Carminelli Gregori: Appunti su d.b. parte1 A.A. 2005
dalle applicazioni e la conoscenza cosi’ non deve essere replicata in ogni applicazione. (cfr.
Atzeni &… ed.2003 cap.7, Vol.2)
Il modello gerarchico (anni '60) ha strutture ad albero;quello
reticolare o CODASYL (da Conference on Data Systems
Languages, l' organizzazione che ne propose i fondamenti
negli anni '70) ha strutture di tipo semplici grafi, reticolari;
quello relazionale con il costruttore “relation” ossia relazione
intuitivamente rappresentata in forma tabellare (ideato da E.F.
Codd e presentato in un articolo del CACM del Giugno 1970
...) e’ il piu' importante. Questi sono stati i modelli usati nei
DBMS.
A questi si aggiungono altri modelli, detti spesso concettuali,
per descrivere i dati indipendentemente dal tipo di DBMS tesi a
descrivere i concetti dell' ambiente da automatizzare. Tipico
esempio e' il modello Entity- Relationship usato per la
progettazione di un d.b. (cfr. db2005p2) al quale si è aggiunto
ultimamente lo UML (Uniform Modeling Language ) “preso in
prestito” dal paradigma O.O.
DB & DBMS: dove si usano principalmente? in quale contesto
si inseriscono? Generalmente il contesto e' un Sistema
Informativo.
Sistema Informativo = Insieme organizzato di Risorse e
Procedure di natura diversa (umana e materiale) che
interagiscono tra loro, finalizzato alla gestione dell'
informazione in un’ azienda. (Gestione dell' informazione =
raccolta, registrazione, trasmissione, elaborazione dell' INFO.)
Sistema Informatico = (anche se il termine e' spesso sostituito
da Sistema Informativo) e' visto come un sottoinsieme del
43
Anna Maria Carminelli Gregori: Appunti su d.b. parte1 A.A. 2005
Sistema Informativo finalizzato alla gestione automatica dell'
informazione sintetizzata in dati mediante processi di
modellizzazione (aggregazione, astrazione).
Queste sono le definizioni classiche, ma ormai negli ambienti
economici attuali si parla di MIS ossia Management
Information System o Sistemi Informativi Gestionali che si
basano su tre risorse chiave: Informazioni, “Personale
Competente”, Tecnologia. Il Personale Competente viene
indicato come “knovledge worker” ossia individui che sanno
come e quando utilizzare gli strumenti tecnologoci o tecnologie
informative (IT = Information Tecnology). Gli strumenti IT
includono: telefoni cellulari per collegarsi con la Borsa,
computer (di tutti i tipi), reti per collegarsi ad altre aziende, e
per ultima, ma non ultima Internet definibile come il Sistema
Globale di Informazioni.
Progetto di un Sistema Informatico: 3 fasi.
1) Analisi: studio di fattibilità, raccolta e definizione requisiti;
2) progettazione: specifiche di progetto;
3) realizzazione con progetto logico e fisico.
Nella fase 3 "entra in gioco" l' ambiente di Gestione
(Archiviazione) dei dati con l' utilizzo di un Sistema di
Gestione di Basi di Dati (S.G.B.D. = D.B.M.S.) apposito
(Commerciale o Artigianale) e le sue regole da seguire.
Occorre sottolineare che tali regole cambiano quando si passa
da un ambiente centralizzato omogeneo ad un ambiente
eterogeneo che si vuole utilizzare anche dall’ esterno con uso
di Internet e programmi di accesso scritti per es. in Java. Quest’
44
Anna Maria Carminelli Gregori: Appunti su d.b. parte1 A.A. 2005
ultimo argomento verra’ ripreso e sviluppato nella parte 2
(db2005p2).
+in dettaglio:
Progetto di D.B. di tipo centralizzato e sua introduzione
in un Sistema Informatico.
3 Fasi
1 Analisi:
1.1 Studio di fattibilità per la definizione preliminare del
problema con la valutazione preliminare del rapporto tra
costi e benefici.
1. 2 Analisi del preesistente ossia del sistema informativo in
uso (automatico o no), capire: il suo funzionamento,la
struttura, finalita’, funzioni, attivita’ effettive, interfacce
tra aree funzionali con standardizzazione dei termini,
settori e procedure da automatizzare, possibilita’ e
convenienza, dati e loro tipo, volume, privatezza …
e porsi le seguenti domande:
 Quali sono gli oggetti informativi da aggiungere
e/o integrare per le applicazione aggiuntive
richieste?
 Quali proprietà li caratterizzano?
 In che modo i vari oggetti sono correlati?
Appropriate risposte permetteranno di dare una prima
1.3 Definizione dei requisiti del sistema informatico.
45
Anna Maria Carminelli Gregori: Appunti su d.b. parte1 A.A. 2005
2 Progettazione
costruzione del progetto di tipo semantico, concettuale del
d.b.
3 Realizzazione
definizione conforme al progetto concettuale del progetto
logico e fisico del d.b. detti anche schema logico e schema
fisico.
Ciclo di vita del software ed esempi
(da Albano e riviste)
46
Anna Maria Carminelli Gregori: Appunti su d.b. parte1 A.A. 2005
)
47
Anna Maria Carminelli Gregori: Appunti su d.b. parte1 A.A. 2005
Sintesi della MODELLAZIONE & PROGETTAZIONE di d.b. di
tipo centralizzato.
Informazioni, necessita’
dell’ utente …
concreta
Conoscenza{ implicita
(statica &dinamica)
procedurale
Modellazione:
 astrazione
 aggregazione di concetti dipendenti
Definizione di:
 Tipi Entita’ (sottotipi …)
 “ interrelazioni tra Entita’
 Requisiti
 Condizioni (Vincoli)
 Tipi Attivita’ …
Specifiche di progetto
con utilizzo di un
“Modello di Dati”
Schema logico della
Base di Dati nel
liguaggio disponibile
nel D.B.M.S.
Progetto
Concettuale
Gerarchico, Reticolare
Relazionale: deve
permettere una
descrizione dei “dati”
indipendente dalla
rappresentazione fisica
48
Anna Maria Carminelli Gregori: Appunti su d.b. parte1 A.A. 2005
Schema logico di un d.b.
 descrizione sintetica di tutti i tipi di dati,
delle interrelazzioni o legami tra i
tipi di dati,
dei vincoli tra i tipi di dati.
Puo’ essere realizzato solo dopo APPROFONDITA
ANALISI dell’ ambiente dove il d.b. deve essere inserito.
Con riferimento allo schema logico il D.B.M.S. permette e
controlla accessi e aggiornamenti dei dati.
Un primo esempio di schema logico e’ tratto da “Data
Models” di Tsichritzis-Lochovsky e rappresenta lo schema
relazionale di un “Medical d.b.”
HOSPITAL(Hospital_code, Name, Address, Phone#, # of beds)
WARD(Hospital_code,Ward_code, Name, # of beds)
STAFF(Hospital_code, Ward_code, Employee#, Name, Duty,
Shift, Salary)
DOCTOR(Hospital_code, Doctor#, Name, Speciality)
PATIENT(Registration#, Name, Address, Birthdate, Sex, SSN)
DIAGNOSIS(Registration#, Diagnosis_code, Diagnosis_type,
Complication, Precaution_info)
LAB(Lab#, Name, Address, Phone#)
TEST(Registration#, Lab#, Test_code, Type, Date_ordered,
Time_ordered, Order#, Status)
HOSPITAL_LAB(Hospital_code, Lab#)
ATTENDING_DOCTOR(Doctor#, Registration#)
OCCUPANCY(Hospital_code, Ward_code, Registration#,
Bed#)
49
Anna Maria Carminelli Gregori: Appunti su d.b. parte1 A.A. 2005
Come si arriva a stendere tale schema?
… partendo da uno Schema Concettuale …
Per avere un vero Schema Concettuale occorre usare un Modello
Concettuale dei dati come E-R ( Entity - Relathionship Model, cfr.
parte 2): quello che segue e’ solo un primo abbozzo di schema
concettuale:
Hospital
Name Address
Hospital_Code
# of beds
Phone#
……
N
Doctor
Patient
M
(Hospital_Code, Doctor#)
Name
Speciality
Registration#,
Name, Address,
Birthdate,
Sex, SSnN
…..
Ogni Entita’ dell’ ambiente da automatizzare (come
Hospital o Doctor o Patient o … altro) e’ racchiusa in un
rettangolo ed e’ collegata ai suoi attributi con simboli di
tipo diverso. Qui si ha:
per la chiave;
per altri attributi come il Name:
ogni Entita’ ha un solo nome che pero’ puo’ essere proprio
di altre Entita’;
per quell’ attributo che ogni entita’
50
Anna Maria Carminelli Gregori: Appunti su d.b. parte1 A.A. 2005
ha con una certa molteplicita’ e puo’ essere proprio di altre
entita’ (come Speciality per Doctor). Le Entita’ possono
essere anche collegate tra loro con simboli come
per es. Doctor e Patient che sono così collegati per
indicare che un Doctor cura M Patient ed un Patient ricorre
a N Doctor.
51
Anna Maria Carminelli Gregori: Appunti su d.b. parte1 A.A. 2005
Fasi di progettazione di una Base di dati con
riferimento ad una Base di dati ospedaliera (Medical d.b.):
progetto concettuale, progetto logico, progetto fisico
Come ottenerli?
1. Progettazione concettuale: usa un modello
concettuale dei dati che permette la
descrizione
dei dati col loro significato
informativo ad un
livello di astrazione alto  prodotto: schema
concettuale;
2. Progettazione
logica:
traduce
lo
schema
concettuale nelle strutture tipiche del D.B.M.S. a
disposizione (per es. relazioni del modello
relazionale)  prodotto: schema logico la cui
qualita' e' verificabile e migliorabile tramite tecniche
formali disponibili col D.B.M.S. a disposizione (per
es. la normalizzazione);
3. Progettazione fisica: specifica i parametri fisici non
menzionati nello schema logico, ma necessari per
memorizzare i dati  prodotto: schema fisico.
cfr. Atzeni & C. "Basi di dati"(1999 da pag. 165, ed. 2002 da pag. 191)
Nella fase 2) il modello (le strutture) dei dati utilizzato per
la descrizione dello schema logico deve soddisfare ad un
requisito base: indipendenza dalla rappresentazione fisica dei
dati  garanzia che ogni modifica nello schema fisico non
comporti alcuna modifica nello schema logico e quindi neppure
sulle procedure che lo usano  indipendenza fisica dei dati. Nei
modelli gerarchico e reticolare (non relazionale) il progetto logico
contiene elementi di rappresentazione fisica (per es. puntatori ...)
52
Anna Maria Carminelli Gregori: Appunti su d.b. parte1 A.A. 2005
Col modello relazionale (Codd 1970) l' indipendenza
fisica dei dati e' ottenuta con una rappresentazione
tabellare dei file indipendente dalla loro
rappresentazione fisica (sequenziale, indicizzata ...)
E' necessaria pero' anche l' indipendenza dalla
rappresentazione logica dei dati, ossia dallo schema
logico che e' la descrizione globale di tutto il data
base. Questa necessita' deriva dal fatto che quando il
numero di utenti risulta >1 ogni utente puo' avere
interessi distinti e riferirsi solo a parti del d.b. 
_ l' utente deve poter disporre di un suo
sottoschema logico o "vista d' utente" che resti
invariato da modifiche nello schema logico
_ si ottengono due livelli di schema logico (Schema
e View) ed un livello di schema fisico che danno l'
indipendenza fisica e logica dei dati.
Quindi indipendentemente dal modello occorre
conoscere sia la struttura, l’architettura Standard
di un Sistema di Gestione di Basi di Dati =
S.G.B.D. sia la sua composizione per saper cio’ che il
Sistema accettera’ in input e come rispondera’.
53
Anna Maria Carminelli Gregori: Appunti su d.b. parte1 A.A. 2005
Architettura del DBMS di tipo “centralizzato”: definita gia’
nel 1975 dal Comitato ANSI/X3/SPARC gruppo di studio sui
DBMS, e’ a 3 livelli di Schema  necessari per ottenere
“Indipendenza Fisica e Logica dei Dati” ed e’:
 Schema Esterno o Sottoschema o View (Vista d’ Utente)
 Schema Logico o Concettuale
 Schema Fisico o interno
Ogni singolo utente puo’ essere interessato ad una sola parte
del d.b. e quindi ha necessita’ di una sua parziale
rappresentazione fornita da uno degli Schemi esterni o Viste d’
utente che contengono solo la parte dei dati di interesse per i
vari utenti. Possono essere costituiti da “sottoinsiemi estesi”
dello Schema (l’ estensione riguarda organizzazioni o
collegamenti differenti). Lo Schema Esterno assicura l’
indipendenza (logica) dalla rappresentazione dei dati.
Lo Schema Logico contiene la descrizione di tutto il d.b. fatta
nel Modello Logico del DBMS ed e’ controllato dal DBA =
persona o staff Amministratore del d.b.
Lo Schema Fisico non e’ che la rappresentazione dello
Schema logico tramite apposite Strutture Fisiche di
memorizzazione: sullo Schema Fisico lavorano i “Sistemisti” (i
programmatori di Sistema) ed il DBA.
Funzionamento del DBMS Standard: ogni comando (o programma) d’
utente e’ controllato dal DBMS che fa confronti sulle informazioni
richieste e le dichiarazioni del Sottoschema pertinente e dello Schema
logico. Se ci sono discrepanze il comando e’ rigettato, altrimenti e’
54
Anna Maria Carminelli Gregori: Appunti su d.b. parte1 A.A. 2005
eseguito tramite le strutture di Accesso dello Schema fisico ed i Metodi di
Accesso del S.O. o quelli tipici del DBMS stesso (cfr. +avanti).
Segue
una vignetta sugli schemi tratta da Melchiorri-Raschetti-Occhionero, ed.
Signorelli, Roma, 1986.
55
Anna Maria Carminelli Gregori: Appunti su d.b. parte1 A.A. 2005
56
Anna Maria Carminelli Gregori: Appunti su d.b. parte1 A.A. 2005
D.B.M.S. (Data Base Management System)
sistema software per gestire archivi di notevole
dimensioni, persistenti e condivisibili con Funzioni di:
_
Data Definition ( D.D.L.= Data Definition
Language);
(per costruire lo schema)
_
Data Manipulation ( D.M.L. = Data
Manipulation Language); (per elaborazioni …)
_
Data Security & Integrity ;
_
Data Recovery & Concurrency;
_
Data Dictionary: "data about the data" 
data base of the system = METADATI ( in
DB2: Catalog = System's data base (*));
_
Performance;
_
Friendly Interface;
_
...
(*) contiene tutte le informazioni ("descriptors")
relative alle Relazioni, Attributi, Indici, Utenti, Viste,
_ del Sistema Relazionale (cfr. piu' avanti).
Composizione del D.B.M.S. (a grandi linee) 
_
interprete;
_
compilatore, se dotato di un proprio
linguaggio, altrimenti linguaggio e
compilatore ospiti per es. Cobol;
_
ottimizzatore ed esecutore accessi.
57
Anna Maria Carminelli Gregori: Appunti su d.b. parte1 A.A. 2005
Perche' un DBMS ?
Albano Orsini dal confronto tra i sistemi di
Archiviazione e DBMS trae i seguenti benefici:
1. Riduzione Ridondanza con un’ organizzazione
appropriata dei dati;
2. Riduzione degli sforzi di programmazione per
mantenare la consistenza dei dati a causa dell’
integrazione (condivisione) dei dati;
3. Terminologia migliorata con l’ uso di nomi
standard definiti nello Schema Logico;
4. Indipendenza fisica dei dati che diventano
+accessibili;
5. Privacy &Security: la riservatezza dei dati e’
aumentata;
6. Recovery: in caso di malfunzionamento il ripristino
dello stato del d.b. e’ eseguito automaticamente
garantendo affidabilita’ dei dati;
7. Concorrenza ed uso di Reti: i servizi di
trasmissione dati sono spesso favoriti.
Alcuni
DBMS Societa’ S.O.,
Modello
DB2
IBM VSE, Unix,WindowsNT Relazionale
OracleServer Oracle “
“
Windows(2000)
“esteso(*)
Access Microsoft
“
“
Relazionale
IMS
IBM
“
OS/VS, Dos/VS… Gerarchico
IDMS ComputerAssociated VSE, MVS…
Reticolare
e poi System2000, IDS II (Honewell), ADABAS, Total …
(*) esteso nel senso che permette anche l’ uso di Oggetti e reattivita’.
58
Anna Maria Carminelli Gregori: Appunti su d.b. parte1 A.A. 2005
Problema anni 90  sicurezza nelle Basi di Dati
Problema primario: protezione del D.B da accessi impropri.
 Ogni accesso e' controllato dal D.B.M.S. tramite regole
di
Autorizzazione: controlli + duri per d.b. Distribuite
 Complessita' del Controllo Accessi al D.B. >
Complessita' del Controllo Accessi a file del S.O.
Motivi:
1. occorre applicare il controllo a oggetti di
granularita' piu' fine dei file come records,
attributi, valori;
2. Nei data base le informazioni sono associate tra
loro SEMANTICAMENTE: cio' puo' permettere ad un
utente di conoscere il valore di un dato senza accedere
direttamente ad esso, ma inferendolo da altri ...
QUINDI il D.B.M.S. deve soddisfare a richieste di:
_ protezione del D.B. da inferenze;
_ integrita' del D.B. sia fisica che logica (pag. seg.);
_ protezione e trattamento speciale di "sensitive data" (*);
_ vari livelli di protezione (segretezza) (pag. seg.);
_ limitazione nei trasferimenti di info. (pag. seg.).
(*) Es. "sensitive data":
studente
|
Corso
|
Voto
voto = "sensitive data" rispetto a corso: cancellando Corso, Voto non ha
significato e non ha senso conservarlo, ma avendo:
Cliente
se si elimina Cliente si perde anche il suo indirizzo che puo’
|
risultare utile per usi futuri  meglio indicarlo come OLD.
I ndirizzo
59
Anna Maria Carminelli Gregori: Appunti su d.b. parte1 A.A. 2005
Sicurezza nelle B.D. = sicurezza delle informazioni => 3 aspetti
relativi a: Integrita' fisica, Integrita' logica, Segretezza.
Integrita' fisica: impedire distruzioni o modifiche per eventi
accidentali o manomissioni deliberate 
Integrita' fisica: {
_ verifica analitica & conto accessi
(proc. Auditing & accontability tipiche dei S.O.)
_ procedure di Recovery & Restart
Integrita' logica: garantire correttezza e consistenza logica delle
informazioni. Si distingue in: Integrita' operazionale e Integrita'
Semantica. L' Integrita' operazionale e' "garantita" dall' utilizzo di un
LOG o Journal su cui sono registrate tutte le operazioni e gli stati
del d.b. (i valori dei dati!) Se in una data transazione (*) capita un
malfunzionamento il sistema (DBMS) puo' riprendere con lo stato
(i valori dei dati) precedente la transazione. L' Integrita' Semantica
e' "garantita" da controlli sui dati ed uso di vincoli di integrita' nello
SCHEMA. 
_ consistenza dei dati (anche
Integrita' logica & {
durante transazioni concorrenti)
operazionale
_ vincoli di integrita'
Segretezza: impedire letture non autorizzate dei dati. Si distingue in:
riservatezza (se i dati sono di tipo economico-commerciale);
privatezza se i dati sono relativi a persone.
(*) Transazione: sequenza di operazioni sul data-base che trasforma uno
stato del d.b. in un altro (con modifiche sui dati): i 2 stati devono essere
consistenti (non le situazioni intermedie !! Per es. gli studenti che cambiano Facolta’,
durante gli aggiornamenti possono trovarsi in situazioni strane: importante e’ che la
60
Anna Maria Carminelli Gregori: Appunti su d.b. parte1 A.A. 2005
situzione finale sia corretta.) Di transazioni si parlera’ ancora specialmente con i
d.b. di tipo distribuito nella parte 2 (db2005p2).
L' architettura dei D.B.M.S. deve arricchirsi utilizzando: moduli di filtro e
regolamentazione accessi; modelli strutturali piu' complessi. (cfr. 1 pagina da
Martella & altri)
61
Anna Maria Carminelli Gregori: Appunti su d.b. parte1 A.A. 2005
62
Anna Maria Carminelli Gregori: Appunti su d.b. parte1 A.A. 2005
Protezione delle info. (contenute in un data base) a
livello logico. Si ottiene con controllo di: flusso, inferenza,
accesso e con controllo crittografico (*) e codifica dei
dati memorizzati impedisce che i dati risultino
comprensibili a chi li legge senza autorizzazione. Il
controllo di flusso regola la distribuzione delle info tra “gli
oggetti” (i file, le relation …) del d.b. accessibili agli utenti.
Per es. flusso di info tra 2 relation X e Y si ha quando un’
istruzione legge valori da X e li scrive in Y Il controllo
di flusso deve impedire che le info di relation protette
fluiscano esplicitamente (copiate) o implicitamente
(trasformate) in relation o altri oggetti meno protetti e
quindi leggibili da ogni utente. Per impedire flusso
indesiderato occorre specificare quale e’ il flusso
ammesso e negare l’ altro. Il controllo di inferenza
deve proteggere le info da una loro scoperta indiretta
tramite deduzioni, derivazioni, computazioni. Tipico
esempio l’ inferenza statistica. (Es. Interrogazione: Frequenza
delle persone che hanno modificato il proprio C.C. in data 2.9.’99 alle ore
12.12.00 ? Risposta: 1; Domanda: nominativi ? Risposta: NON
CONCESSI; Domanda: Residenza delle persone che … ? Risposta:
Trieste, via Roma …  Persona individuabile)
Il
controllo di accesso deve sottoporre tutti i soggetti che
accedono al sistema (interrogazioni di utenti, … processi …
con operazioni di lettura, scrittura, esecuzione di lavori) a
controlli regolati dalla politica di accesso (ingiuntiva o
discrezionale) e attivati da meccanismi (filtri) di sicurezza.
***********************************************
(*) usato oggi anche in Internet nell’ uso di chiavi
pubbliche, private, firme elettroniche, documenti riservati
...
63
Anna Maria Carminelli Gregori: Appunti su d.b. parte1 A.A. 2005
Cavalli di Troia per d.b. ***************************
Si puo’ trattare generalmante di tipi di programmi a prima vista utili per
effettuare calcoli interessanti (per es. calcoli statistici), ma contenenti in
qualche procedura, codice nascosto (mascherato) che “legge-scrive”.
Situazione tipica & semplice: l’ utente A abilitato a lavorare sul file FA di
un d.b. anche in scrittura, da’ il permesso all’ utente B (un po’ ingenuo) di
lavorare sul file FA anche in scrittura. Se l’ utente B avvia
inconsapevelmente un Cavallo di Troia (nascosto in FA) su uno dei suoi
file FB questo sara’ copiato su FA e … l’ utente A carpira’ le informazioni
di B … !!! Altre situazione tipiche & meno semplici possono capitare in
rete con mail (contenenti codice nascosto che provocano danni a
catena.**********************************
************************************************ Come
difendersi ? DIFFICILE ! In sintesi (e nel caso dei d.b.) si devono usare
politiche di protezione di tipo ingiuntivo (mandatory) che regolano
accessi a file ed a processi. Politiche di protezione che si basano su
classificazioni rigide degli utenti del D.B.M.System: solo ai soggetti
(utenti, programmi) abilitati a lettura/scrittura su tutto il d.b. e’ permesso di
usare qualsiasi processo anche quelli classificati di utilita’.
In Internet si trova il seguente articolo che riporto in quanto NON segreto:
Come creare un virus
Non e’ giusto diffondere le tecniche di creazione dei virus, ma per
difendersi e’ bene conoscerne almeno qualcuna. I trojan non sono
sempre programmi per intrufolarsi in pc altrui, ma sono
spesso programmi ideati per far danni (al contrario dei
virus worm che hanno come unico scopo diffondersi. Ma anche
questa e’ una tecnica che puo’ diventare dannosissima! ). Però resta
un gran problema: se noi vogliamo far danni ad un
qualsiasi computer con dei trojan reperibili in rete, essi
saranno sicuramente individuati da tutti gli antivirus.
Proprio per questo ho creato questo tutorial.
Ciao a tutti ragazzi, ho fatto questa guida perchè molto
spesso non si riesce a infettare un computer tramite un
virus gia esistente, ma si ha bisogno di costruirsene uno
da solo. In questa guida vi insegnerò a costruire trojan
tramite il dos.Un trojan non è necessariamente un
programma per entrare in altri computer, ma è un programma
semplice, che contiene poche righe di testo distruttivo.
Quindi, se ne fate uno prendendo spunto da questa guida,
64
Anna Maria Carminelli Gregori: Appunti su d.b. parte1 A.A. 2005
io non sono responsabile di come lo userete...
Bene, iniziamo. Innanzi tutto dovete conoscere almeno i
comandi basilari del dos. Oro ve ne illustrerò i +
importanti:
Del: cancellazione di uno o + file;
Deltree: cancellazione di un'intera directory;
Copy: copia di uno o + file in un'altra directory;
Ren: rinominare uno o + file;
@: questo è uno dei comandi + importanti che si usano per
costruire un trojan. Mettendo questo comando prima della
stringa distruttiva, il testo non verrà visualizzato al
momento dell'apertura del trojan, quindi chi lo esegue, si
rende conto solo alla fine degli effetti dopo l'apertura.
Format: questo è un comando che non può essere usato in
ambiente windows, quindi non lo usate per i vostri trojan.
Innanzi tutto, iniziamo con il dire che i nomi delle
cartelle e dei file di windows sono diversi da quelli di
Ms-dos: la cartella documenti in Windows si chiama
"Documenti", mentre in Ms-dos si chiama "DOCUME~1". Forse
questa è l'operazione un pò più pesante, perchè, da Prompt
di Ms-dos, dovete trovare la cartella prima secondo il
nome di windows (a destra), e poi, guardare quale nome
coincide con quello, nella colonna di sinistra.
Il simbolo "~" si ottiene premendo "Alt" e premendo in
successione i tasti "126", e rilasciando Alt.
Se si vogliono cancellare tutti i file contenuti nella
cartella "Documenti", si deve scrivere il seguente
comando: @Deltree /y C:\Docume~1\*.*
La @ sta per rendere il comando invisibile a chi esegue il
trojan
Deltree: cancella alcuni file
/y: serve per confermare la scelta di eliminare i file
*.* sono i file da eliminare. In questo caso tutti, xchè *
vuol dire tutti i file.
Per rendere + facile la vostra comprensione, prenderò in
esempio una vera e propria costruzione di un trojan.
Supponiamo di volerne costruire uno per la cancellazione
di tutti i file nella cartella Documenti:
Creiamo un nuovo documento di testo, nominandolo
"trojan.txt".
Apriamo il file "trojan.txt" e scriviamo normalmente il
comando "@Deltree /y C:\Docume~1\*.*", senza le
virgolette. Chiudiamo e salviamo.
Rinominiamo il file "trojan.txt" in "trojan.bat",
rendendolo così un'applicazione di Ms-dos. Gia a questo
punto il vostro trojan funziona, ma se o volete rendere
ancora più pericoloso potrete unirlo ad un qualsiasi file
exe, magari un gioco, per renderlo meno sospettabile!
Prodotto non propio
"); //-->

65
Anna Maria Carminelli Gregori: Appunti su d.b. parte1 A.A. 2005


Sez. 2
Modello Relazionale &
Basi di Dati Relazionali: aspetti essenziali
Algebra Relazionale
Normalizzazione e Forme Normali
Caratteristiche dei Relational D.B.M.S.
SQL: indicazioni sintetiche

66
Anna Maria Carminelli Gregori: Appunti su d.b. parte1 A.A. 2005
Quali sono le Politiche di protezione adottate dai D.B.M.System
attuali ? Dipende dal livello di aggiornamento del DBMS: in
Access esistono alcune possiibilità. Se il D.B. e’ accessibile da più
utenti si può mettere una password al D.B. o impostare account
per i vari utenti, magari ripartendoli in gruppi: la Guida consiglia
questa modalità come indicato qui di seguito.
Password di database
Se si utilizza una password per il database, per aprire il database è necessario che tutti gli utenti
immettano tale password. L'aggiunta di una password del database è una semplice misura che
contribuisce a evitare che il database venga aperto da utenti non autorizzati. Tuttavia, dopo
l'apertura del database non sono previste altre misure di protezione a meno che non sia stata definita
anche la protezione a livello utente.
Le informazioni relative alla password del database vengono memorizzate in formato non
crittografato. Se ciò compromette la protezione del database, non utilizzare una password per la
protezione del database e definire invece la protezione a livello utente, che contribuisce al controllo
dell'accesso ai dati riservati contenuti nel database.
Password degli account di protezione
Quando si definisce la protezione a livello utente per un gruppo di lavoro, è possibile utilizzare la
password di un account di protezione. Questo tipo di password contribuisce a evitare che un utente
non autorizzato esegua l'accesso utilizzando il nome di un altro utente.Per
impostazione
predefinita, viene assegnata una password vuota all'account
Amministratore predefinito e a qualsiasi nuovo account utente
creato nell'ambito del gruppo di lavoro. Per proteggere un
database è importante aggiungere una password per:



l'account Amministratore (per attivare la finestra di dialogo
Accesso);
l'account utente proprietario del database e delle relative
tabelle, query, maschere, report e macro;
qualsiasi account utente aggiunto al gruppo Amministratori.
È inoltre possibile aggiungere password agli account creati per gli
utenti o indicare a questi ultimi di aggiungere password proprie.
Gli utenti possono creare o modificare le loro password
67
Anna Maria Carminelli Gregori: Appunti su d.b. parte1 A.A. 2005
dell'account di protezione. Solo un account Amministratore
tuttavia può cancellare una password se l'utente la dimentica.
Comunque tutti i DBMS permettono l’introduzione di
vincoli di integrita’ a livello di schema logico per
potenziare le procedure di controllo che si dovrebbero
attivare automaticamente.
I vincoli di integrita’ possono essere di tipo diverso e
riferirsi agli attributi di una singola Entita’ generica o a
+Entita’ correlate (per es. nei DBMS Relazionali esistono
vincoli INTRA_relation o INTER_relation come indicato
+avanti). Le seguenti sono Regole di integrita’ nel modello
relazionale sempre valide. (Date da pag 12)
Ogni data base contiene dei valori che si suppongono
riflettere una parte dell’ ambiente reale in fase di studio e
modellazione.
Occorre escludere dal data base le configurazioni insensate
di valori (per es. pesi negativi).
La “definizione” del data base deve includere alcune
regole dette regole o vincoli di integrita’ che impediscano
la generazione (o per inserimenti o per aggiornamenti) di
configurazioni insensate.
Cio’ si realizza introducendo nello schema logico i vincoli
di integrita’. Alcuni vincoli di integrita’ sono specifici di un
particolare data base (voti, pesi, date …)
Nel modello relazionale pero’ esistono 2 regole di
integrita’ generali che si riferiscono alla chiave primaria ed
alle chiavi “esterne” di ogni relazione (cfr. piu’ avanti)
1) A nessuna componente della chiave primaria di una
relazione fondamentale (non di una view per es.) e’
permesso di essere vuota;
68
Anna Maria Carminelli Gregori: Appunti su d.b. parte1 A.A. 2005
2) Il data base non deve contenere alcun valore di chiavi
esterne per il quale non esista il valore corrispondente
della chiave primaria nella relazione di riferimento (per
es. voto a studente con # matricola inesistente).
Modello relazionale: caratteristica essenziale e’ che, come
dice Date, “un Sistema Relazionale e’ percepito dall’ utente
come un insieme di Tabelle”. (Nell’ uso corrente il nome
Tabella e’ diventato sinonimo di Relation).
Aspetti fondamentali 
Rappresentazione in forma tabellare dei dati e delle loro
interrelazioni permanenti (RICORDARE il SIGNIFICATO
INTRINSECO DI TABELLA O ARRAY !!!);
 Non appare alcun tipo di puntatore;
 Lo schema e’ modificabile al run-time;
 La “Navigation” tra i dati e’ realizzata con operazioni di
“giunzione” e di “proiezione” dei file = relation
 nasce in ambiente IBM: ideatore: Codd, anno & luogo
di nascita: 1970, S. Jose’ (California), prototipo: System_R
ad opera di Chamberlain, Astrahan,…
 utilizza la Relation intesa in senso matematico:
una Relazione R esprime una corrispondenza tra 2 o
+insiemi definendo un insieme di elementi che soddisfano
la corrispondenza. Esempio: si considerino i 2 insiemi
seguenti: S1={1, 3, 8, 9};
S2 = {2, 3}. Volendo
metterli in corrispondenza si puo’ definire una Relazione
binaria R(S1, S2) tra S1 e S2. La definizione di R e’
effettuata sul prodotto cartesiano S1* S2 e produce l’
insieme fatto dalle coppie seguenti:
R(S1, S2) = <s1, s2> | s1S1, s2  S2, s1 < s2.
Questo e’ lo schema o intension di R.
69
Anna Maria Carminelli Gregori: Appunti su d.b. parte1 A.A. 2005
Si ha: S1* S2 ={<1,2>, <1,3>, <3,2>, <3,3>, <8,2>,<8,3>, <9,2>,<9,3>}
Il corpo o extension di R e’: {<1,2>, <1,3>}
… gia’ nella definizione di Relation appare la potenza del
formalismo di Codd: una Relation definita su alcuni insiemi ne
definisce uno nuovo con determinate proprieta’.
Basi di dati relazionali

Definizione formale di relazione
_ n insiemi: D1,D2,...Dn
_ prodotto cartesiano P = D1* D2 *… * Dn
_ relazione R = sottinsieme di P
R  D1 * D2 * ... * Dn
_ D1,D2,...,Dn
domini delle relazione
_n
grado della relazione
R non contiene tutte le possibili ennuple di P, ma
quelle soddisfacenti le sue proprieta'
Es. D1= 1, 3, 5
D2= a, b
D1xD2 =(1,a), (1,b), (3,a), (3,b), (5,a), (5,b)
R = insieme di coppie | 1o elem. D1, 2 o elem. D2
&& 1o elem.> 1 =
=(3,a), (3,b), (5,a), (5,b)
altri es. da Date e da Atzeni…
 di nuovo appare la potenza del formalismo di Codd: la
definizione dei domini della relation puo’ essere sempre
+stringente avvalendosi di Interpretazioni +calzanti che
producono condizioni (= vincoli) tali da escludere
configurazioni non pertinenti. Cio’ si raggiunge tramite
l’uso di Ruoli che devono essere soddisfatti dagli attributi
della Relation. Es.
in paesi orientali
70
Anna Maria Carminelli Gregori: Appunti su d.b. parte1 A.A. 2005
DiplomaticiDiplomatici Europei {“ “
occidentali
nel terzo mondo
( segue 1 pag. appunti da Atzeni e da Date)
71
Anna Maria Carminelli Gregori: Appunti su d.b. parte1 A.A. 2005
RELAZIONE
_ pone in corrispondenza piu’ dati
Esempio: generalita’ di individui
generalita’  nome X cognome X data nascita X citta’
generalita’ = (Paolo, Rossi, 1/2/73, Vicenza)
(Romolo, Remo, 25/12/97, Roma)
(Gennaro, Vero, 1/1/79, Napoli)
RELAZIONE = TABELLA
Esempio: Relazione Generalita’
____________________________________
| Nome
Cognome data
Citta’
|
|___________________________________|
| Paolo
Rossi
1/ 2/73 Vicenza |
| Romolo
Remo
25/12/97 Roma
|
| Gennaro Vero
1/ 1/79 Napoli |
|___________________________________|
in generale:
|_Tab.1_______________________|
| nome-1 nome-2 .......nome-n |
|_____________________________ |
|
x1
y1
z1 |
|
x2
y2
z2 |
|
...
...
... |
|
xk
yk
zk |
|_____________________________|
RELAZIONE = TABELLA
_ riga = ennupla = tupla; _ colonna = attributo
72
Anna Maria Carminelli Gregori: Appunti su d.b. parte1 A.A. 2005
_ relazione= sottoinsieme prodotto cartesiano
_ intestazione della tabella  schema della relazione
_ contenuto della tabella = istanza di relazione
73
Anna Maria Carminelli Gregori: Appunti su d.b. parte1 A.A. 2005
Definizione:
base di dati relazionale B.D.R. e’ un insieme di relazioni;
CHIAVE DI UNA RELAZIONE:
_ insieme di attributi
_ identifica univocamente un'ennupla
_ non e’ ridondante
_ unica per ciascuna ennupla.
_ Esempio chiave strutturata
_ nome
Att. ne integrita’ referenziale
_ cognome
_ data di nascita
NOT NULL !!!!
_ Esempio chiave semplice (pag. seg.)
_ codice fiscale.
? Esiste sempre una chiave in una relazione ?
CHIAVE PRIMARIA
74
Anna Maria Carminelli Gregori: Appunti su d.b. parte1 A.A. 2005
?
Ordinamento fisico iniziale dell'archivio ?




Relazione = Insieme 
indipendente ordine tuple
ordine di caricamento
indirizzo (o posizione) tupla nell'archivio
corrispondenza tra gli insiemi I (indirizzo) e
C (chiave) rappresentata dalle coppie (i,c)
Esempio corrispondenza chiave_indirizzo
Archivio A
CAMPO
CAMPI
CHIAVE DETTAGLIO
1a ennupla
Cai
=======
2a ennupla
Bia
=======
3a ennupla
Zizi
=======
...................................................…….
10a ennupla
Ada
=======
Corrispondenza chiave_indirizzo
CHIAVE
INDIRIZZO (i)
Cai
1
Bia
2
Zizi
3
......................………..
Ada
10
75
Anna Maria Carminelli Gregori: Appunti su d.b. parte1 A.A. 2005
Operazioni su singola relazione
_relazione rappresentabile con tabella
_tabella memorizzata in archivio (file)
_tupla = riga = record
_attributo = colonna = campo
_operazioni su archivi=
operazioni sulle relazione trattate con
lo stile scelto nel modello relazionale.
OPERAZIONI DEFINITE SU ARCHIVIO
_aggiunta record
_ricerca record
_modifica record
_cancellazione record
_ripristino record
_compattamento archivio
_ordinamento logico dell'archivio
_apertura archivio
_chiusura archivio
La realizzazione delle operazioni indicate con l’utilizzo di
Access è immediata. Controllare questa affermazione!
AGGIUNTA RECORD
_inserimento nuovo record
_record accodato a quelli preesistenti
76
Anna Maria Carminelli Gregori: Appunti su d.b. parte1 A.A. 2005
_nuova coppia chiave indirizzo
RICERCA RECORD
_ricerca per posizione
_ricerca per chiave
_ ESEMPI
cerca record di chiave "Bia"
_cerca record nø 3
MODIFICA RECORD
_ricerca del record
_modifica di uno o piu' campi
_NO modifica della chiave
_per modifica della chiave
cancellazione record
aggiunta nuovo record
RIPRISTINO RECORD
_elimina cancellazione logica (pag. seg.)
COMPATTAMENTO ARCHIVIO
_esegue copia archivio
_non copia record cancellati
CANCELLAZIONE RECORD
cancellazione fisica
_eseguita periodicamente
_nuova numerazione record
_operazione lunga
cancellazione logica
_record contrassegnato come cancellato
_non visibile in normali operazioni
_non stampato
77
Anna Maria Carminelli Gregori: Appunti su d.b. parte1 A.A. 2005
ORDINAMENTO LOGICO DELL'ARCHIVIO
_archivio A puo’ avere una o piu’ chiavi usabili per il suo
ordinamento
_ordinamento logico di A rispetto a chiave c
_sequenza delle coppie {c,i}
ordinate rispetto alla chiave c =
= indice sequenziale rispetto alla chiave c
(Note piu’ generali sugli indici in ambito RDBMS sono ai luc.
114 e seg. di questa stessa parte: qui solo esempi.)
ESEMPIO INDICE SEQUENZIALE:
(ordinamento rispetto a chiave nome)
CHIAVE
INDIRIZZO (i)
Ada
10
Bia
2
Cai
1
........................
Zizi
3
ESEMPIO INDICE SEQUENZIALE:
(ordinamento rispetto a piu’ chiavi intese come attributi)
Archivio B
CHIAVE1 CHIAVE2
DETTAGLIO
1a ennupla
Cai
Roma
=======
2a ennupla
Bia
Milano
=======
3a ennupla
Zizi
Napoli
=======
4a ennupla
Roi
Milano
=======
.................…………......................................................
10a ennupla Ada
Firenze
=======
ESEMPIO INDICE SEQUENZIALE:
(ordinamento rispetto a chiave citta’)
78
Anna Maria Carminelli Gregori: Appunti su d.b. parte1 A.A. 2005
CHIAVE2
Firenze
Milano
Napoli
........................
Roma
.
INDIRIZZO (i)
10
2, 4
3
1
ORDINAMENTO RISPETTO ATTRIBUTO
(attributo non chiave primaria)
_ambiguo: piu’ record con uguali valori dell'attributo
_ per rimuovere ambiguita’: indirizzo i
per a1=a2 coppia {a1,i1} precede {a2,i2} se i1<i2
_ per rimuovere ambiguita’: chiave c
per a1=a2 coppia {a1,i1} precede {a2,i2} se c1<c2
Esempio ordinamento rispetto attributo
_chiave “primaria nell’ ordinamento”: citta’
_chiave “secondaria nell’ ordinamento”: nome
Archivio B
CHIAVE
ATTRIBUTO DETTAGLIO
1a ennupla
Cai
Roma
=======
2a ennupla
Bia
Milano
=======
3a ennupla
Zizi
Napoli
=======
4a ennupla
Roi
Milano
=======
.......................................................................…………
10a ennupla
Ada
Firenze
=======
ordinamento rispetto a: _attributo primario citta’
79
Anna Maria Carminelli Gregori: Appunti su d.b. parte1 A.A. 2005
_chiave secondaria nome
CITTA'
INDIRIZZO
Firenze
10
Milano
2
Milano
4
Napoli
3
......................………
Roma
1
Gestione sequenziale
_ordinamento vigente (fisico o logico) e record corrente
_operazioni su record corrente
visualizzazione;
modifica campi
cancellazione
_operazioni di posizionamento
su record di chiave assegnata
su record di posizione assegnata ("locate")
su primo record
su ultimo record
avanzamento di un record
arretramento di un record
_operazioni di visualizzazione
di tutto l'archivio
di n record consecutivi
RIORDINAMENTO FISICO ARCHIVIO
_sort
rispetto ad una chiave
80
Anna Maria Carminelli Gregori: Appunti su d.b. parte1 A.A. 2005
sort(archivio,chiave)
rispetto ad attributo non chiave.
sort(archivio,attributo)
APERTURA E CHIUSURA ARCHIVIO
_apertura
l'archivio viene reso disponibile dal S.O.
e’ inibito l'accesso da altri utenti
chiusura
completamento registrazioni
archivio disponibile per altri utenti
Ancora aspetti di progetto:
e’ importante puntualizzarne alcuni perche’:
una volta progettata la relation in fase di progetto semantico
(o concettuale) e poi definito il suo Schema in fase di
progetto logico, ogni suo possibile cambiamento e’
possibile, MA SCONSIGLIATO in fase di esecuzione
(per.es. al caricamento dei dati).
In fase di esecuzione aumenta ovviamente la dimensione
verticale (la CARDINALITA’) della relation ma NON la
sua dimensione ORIZZONTALE.
Per fare tali modifiche occorre tornare alla modifica dello
schema logico con tutte le implicazioni relative … per es.
una revisione di tutto il progetto.
Importanza progettazione della BASE DI DATI
che (ripetita juvant !) permette la gestione integrata dei dati.
OCCORRE la formalizzazione della conoscenza non
ambigua, rigorosamante logica e quindi
81
Anna Maria Carminelli Gregori: Appunti su d.b. parte1 A.A. 2005
analisi conoscenza di tipo statico ( di chi si tratta? tipi di
dati, sottotipi....) e dinamico (come evolve cio' ? tipi di
transazioni sui dati).
Conoscenza: concreta (Entita'  tipi di dati
Operatori  procedure);
astratta (Vincoli, Condizioni non sempre
esprimibili con tipi e interpretazione dei
ruoli, ma talvolta anche esplicitamente: es. eta’ media >
50).
COME individuare le Entita' e gli attributi ?
Entita' = oggetti fondamentali del Sistema Informativo in
analisi; Attributi di Entita' = proprieta' tipiche,
caratteristiche delle Entita'.
DIFFERENZA tra Entità e Attributi : legata al ruolo svolto.
Es. Ruota e Raggio in contesti diversi
1. Magazzino di ferramenta:
d.b. riguarda tutti i tipi di oggetti presenti  Entita’
Chiodo
Vite
Attributi possono essere:
IdentificatoreC
LunghezzaC
Chiodo
Raggio
….(altro)
IdentificatoreR
Spessore
Raggio
Vite
IdentificatoreV
N.o Spire
….
82
Anna Maria Carminelli Gregori: Appunti su d.b. parte1 A.A. 2005
Tipo_Ruota (dove puo’ essere inserito)
.…
2.Venditore di Biciclette con ricambi
d.b. riguarda tutti i tipi di oggetti presenti  Entita’ con
i loro Attributi
Manubrio
Identific.M
Tipo
Peso
Ruota
…..
Identific.R
Tipo
Diametro
Bicicletta
Identific.B
Tipo
Marca
3.MAGAZZINO di ricambi e ferramenta: il d.b. riguarda
tutte le Entita’ viste in 1. e 2. con possibili legami tra loro.
Modello di dati e processo di modellazione
Modello Relazionale usa la Relazione esprime
corrispondenza tra 2 o piu' insiemi ed obbliga all'
analisi della Conoscenza.
Esempi:
1) binaria su insiemi; es. Rappresenta(Symbol, Code)
2) ternaria su (stati ospite, diplomatici, stati origine)
Es. Europea(Europa, Consoli, Europei);
3) unaria su nominativi es.Nomi_Stato(nomi_di_stati)
Domini interpretati, ruoli, attributi.
Schema di Relazione R:
R(attributo1,attributo2,...attributoN)
con specifica della chiave primaria.
83
Anna Maria Carminelli Gregori: Appunti su d.b. parte1 A.A. 2005
Schema di Base di Dati: insieme finito di
Schemi di Relazioni e di Vincoli: E' INVARIANTE
NEL TEMPO.
Base di Dati: insieme finito di Relazioni,
VARIABILE NEL TEMPO, soddisfacenti i
Vincoli dello Schema.
Es. Studente_anag(#matr., Nome, Cogn.,Datanasc., Indirizzo)
chiaveprimaria = #matr.= NOT NULL: lo studente
"entra" in Studente_anag SOLO se ha #matr.definito
SEMANTICA della relazione: ENTITA' o LEGAME
TRA ENTITA' (per es. ESAME(Voto, Studente)
84
Anna Maria Carminelli Gregori: Appunti su d.b. parte1 A.A. 2005
Il Modello di dati puo’ essere inteso anche come strumento
per rappresentare la conoscenza ( tipi di dati, loro
proprieta’ e vincoli, loro evoluzione con le operazioni
permesse).
Nel Modello Relazionale (dove la LOGICA predomina
sulla FISICA) i Domini sono spesso definiti tramite le loro
caratteristiche ossia tramite la loro intension.
Cio’ porta ad esprimere alcune condizioni = vincoli (per es.
interi positivi >100000). In Atzeni & … per il Modello
Relazionale si distinguono:
su Domini,
Vincoli intrarelazionali {
su tuple;
Vincoli interelazionali tra Relazioni;
Tra i primi fondamentali sono i vincoli di chiave;
“ “ secondi “
“ ““
referenziali.
(Tra i vincoli c’e’ anche Unique per es. per la chiave ! )
Nei R.(elational) D.B.M.S. il simbolo NULL (nullo o
indefinito) si usa per informazioni incomplete per es.
quando un indirizzo e’ sconosciuto o incompleto oppure
quando una situazione e’ anomala, non considerata (per es.
tra nubile, celibe, divorziato, vedovo un separato, un
fidanzato come si qualifica ?) In Access per impedire l’ immissione
di NULL in campi chiave occorre impostare la relativa proprieta’ Richiesto
a SI; inoltre una stringa in un campo tipo testo puo’ avere lunghezza zero
(“” e non NULL !) se si specifica tra le proprieta’ del campo “Consenti
lunghezza zero”.
…ma cosa comporta “+Logica & -Fisica”?
Chi si ricorda la tanto decantata TRASPARENZA ?!?
Esempio su vincoli intrarelazionali:
85
Anna Maria Carminelli Gregori: Appunti su d.b. parte1 A.A. 2005
Segue un Esempio da Atzeni (1 pagina)
86
Anna Maria Carminelli Gregori: Appunti su d.b. parte1 A.A. 2005
RICORDARE ! (“+Logica & -Fisica”?)
il modo corretto per costruire la schema logico e’:
Analisi, Progetto concettuale-semantico, Schema logico.
SEMPRE COSI’? nel passato NON sempre.
In ambiente relazionale talvolta si e’ seguita la seguente
modalita’: in base al prodotto cartesiano, considerare una
Relazione Universale definita su tutte le Entita’ presenti e
poi restringersi a sottoinsiemi definiti da appropriate
relazioni.
Es. Medical d.b.
HOSPITAL(Hospital_code, Name, Address, Phone#, # of beds)
WARD(Hospital_code,Ward_code, Name, # of
beds)
STAFF(Hospital_code,Ward_code, Employee#, Name, Duty,
Shift, Salary)
DOCTOR(Hospital_code, Doctor#, Name, Speciality)
PATIENT(Registration#, Name, Address, Birthdate, Sex, SSN)
DIAGNOSIS(Registration#, Diagnosis_code, Diagnosis_type,
Complication, Precaution_info)
LAB(Lab#, Name, Address, Phone#)
TEST(Registration#, Lab#, Test_code, Type, Date_ordered,
Time_ordered, Order#, Status)
HOSPITAL_LAB(Hospital_code, Lab#)
ATTENDING_DOCTOR(Doctor#, Registration#)
OCCUPANCY(Hospital_code, Ward_code, Registration#,
Bed#)
87
Anna Maria Carminelli Gregori: Appunti su d.b. parte1 A.A. 2005
…ma come si lavora in un R.D.B.M.S.?
In teoria la risposta e’ ovvia: si usa il linguaggio che e'
la "lingua franca" di ogni R.D.B.M.S. ed e’ SQL =
Structured Query Language = D.D.L.+D.M.L.
Sinteticamente SQL:
 riunisce le possibilita' di definire e gestire i d.b.
relazionali
 e’ dotato di un interprete che ne permette l' uso
interattivo e/o ospitato in un linguaggio ospite
(Cobol, C, Pl1...HTML...);
 e’ soggetto a standardizzazione da ISO – OSI;
continuamente
aggiornato
SQL-2(’92),
SQL:1999.
In pratica pero’il suo uso interattivo diventa pesante
ed e' sostituito da applicazioni di 4GL ossia Linguaggi
di Quarta Generazione dotati di interfacce grafiche
che facilitano l'utente nel fare interrogazioni e/o
aggiornamenti a R.D.B.M.S. (es. in Access ed in
alcune versioni di Oracle): tali interrogazioniaggiornamenti sono
poi tradotti in SQL dall’
applicazione 4GL. Tipico esempio di un’ interfaccia
grafica amichevole e’ DBAStudio di Oracle8i, mentre
in Oracle9i l’ interfaccia grafica è integrata tra le
88
Anna Maria Carminelli Gregori: Appunti su d.b. parte1 A.A. 2005
componenti di accesso: se non ci fosse, l’ uso
interattivo di Oracle si complicherebbe notevolmente.
89
Anna Maria Carminelli Gregori: Appunti su d.b. parte1 A.A. 2005
Generatori di applicazioni menu’/
Tipo generalizzato forms driven  Obiettivo: realizzare
procedure a costo < 3GL
4GL Tipo specifico per applicazioni specializzate come:
Simulazioni, Pianificazioni … (per
es. Fin_Plan (Financial Planning)

Obiettivo:
Personalizzare
Software
SONO: strumenti software modulari & integrati dotati di:
 Linguaggi di interrogazione con interfaccia grafica;
 Generatori di applicazioni (per es. Maschere = Forms)
 “
“ stampe (Reports)
 “
“ grafici
 Sistemi di supporto decisionale
CONTENGONO: istruzioni procedurali e non, maschere,
menu’..
FORNISCONO:
 ambienti di sviluppo amichevoli per l’ utente con
possibilita’ di passare da un ambiente ad un altro;
 - possibilita’ di errori di programmazione;
 + facile uso e flessibilita’ anche se + lentezza;
 breve periodo di addestramento: TEST di 2 giorni per
usarli
Rispetto all’uso dei 3GL hanno prodotto aumento di: produttivita’
globale, facilita’ manutenzione e documentazione programmi.
Altre caratteristiche tipiche dei 4GL, che li differenziano dai 3GL, si
trovano nel testo di Catalano–Raddi: “INFORMIX-SQL Guida all’ uso”,
CLUP, Milano, dove tra l'altro si evidenzia come con i 4GL non sia
necessario scrivere codice, ma usare generatori di codice per costruire,
per esempio, moduli di Input/Output, menu’…
90
Anna Maria Carminelli Gregori: Appunti su d.b. parte1 A.A. 2005
Seguono esempi della frase "create...." tipica di SQL nella veste
di DDL (da Date.)
91
Anna Maria Carminelli Gregori: Appunti su d.b. parte1 A.A. 2005
92
Anna Maria Carminelli Gregori: Appunti su d.b. parte1 A.A. 2005
Con riferimento agli esempi tratti da Date si tenga presente
che:
 la frase Create puo’ essere usata non solo per la
definizione di relazioni, ma in vari altri casi, per
esempio nei casi seguenti:
Create Schema [nome_Schema] [Autorizzazioni]
Create Domain nome_Dominio Valori
Es. Create Domain S#
char(5)
“
“
Name char(20)
“
“
Status smallint
“
“
City
char(15)
…………
Con queste premesse si puo’ cosi’ definire la relazione
S: Create Table S
(S#
NOT NULL
Sname Domain(Name) NOT NULL
…..
)
Per domini “composti” si ha:
Create Domain date Month Domain(Month)
Day “
(Day)
Year “
(Year)
avendo pero’ prima definito: Create Domain Month
char(2), Day char(2), Year char(4).

Ancora in SP gli attributi S# e P# sono dichiarati nel
vincolo di integrita’ referenziale (CONSISTENZA !)
chiavi esterne:
….
93
Anna Maria Carminelli Gregori: Appunti su d.b. parte1 A.A. 2005
Foreign key (S#) Reference S
“
“ (P#) “
P
Sarebbe opportuno che il vincolo fosse esteso in modo da
premunirsi da cancellazioni e aggiornamenti di tali chiavi
nelle relation originarie. Date propone la seguente
estensione:
Foreign key (S#) Reference S
NULL [NOT] allowed (*)
on Delete of S.S# “effect”
on Update of S.S# “effect”
dove (*) NULL allowed vale per i casi come per es. l’
impiegato in attesa di sistemazione (senza ufficio) ed
“effect” puo’ essere una procedura che cancella, (o
aggiorna) o solo quella tupla o quella e le tuple correlate
della relation SP !
Sia in Access che in Oracle si puo’ applicare il vincolo di
Integrita’ referenziale a relazioni: in Access quando si crea una
relazione si apre una finestra apposita dove e’ possibile indicare
anche se si vuole fare automaticamente operazioni di
cancellazione e aggiornamento in successione per i record
correlati. (Le relative opzioni per Access sono: “Aggiorna” o
“Cancella campi o record correlati in successione” opzioni che si
possono scegliere dopo aver selezionato con un clik “Applica
Integrita’ Referenziale”). La Guida di Access indica per esteso le
regole per quando viene applicata l' integrità referenziale:
·
Non è possibile immettere un valore nel campo chiave esterna della
tabella correlata che non esiste nella chiave primaria della tabella primaria.
È’ possibile, comunque, immettere un valore Null nella chiave esterna,
specificando che i record non sono correlati. Un ordine, ad esempio, non può
essere assegnato ad un cliente che non esiste, ma può essere assegnato ad un
cliente indefinito immettendo un valore Null nel campo ID cliente.
Non è possibile eliminare un record da una tabella primaria, se esistono
record corrispondenti in una tabella correlata. (Per es.non si puo’ eliminare un
94
Anna Maria Carminelli Gregori: Appunti su d.b. parte1 A.A. 2005
record relativo ad un impiegato della tabella Impiegati se ci sono ordini
assegnati a quell'impiegato nella tabella Ordini) e Non è possibile modificare
un valore chiave primaria nella tabella primaria, se quel record dispone di
record correlati (Per es. non si puo’ modificare l’ ID di un impiegato nella
tabella Impiegati se ci sono ordini a lui assegnati nella tabella Ordini.)
Se si vuole applicare queste regole ad una relazione, occorre selezionare la
casella di controllo Applica integrità referenziale quando si crea la relazione
(il legame). Se l'integrità referenziale viene applicata e non viene rispettata una
delle regole per le tabelle correlate, verrà visualizzato un messaggio e non
verrà consentita la modifica. PER IGNORARE LE RESTRIZIONI
sull'eliminazione o sulla modifica dei record correlati, pur mantenendo
l'integrità referenziale, si selezionano le caselle di controllo Elimina campi
correlati a catena ed Aggiorna record correlati a catena. Quando è selezionata
la casella di controllo Aggiorna record correlati a catena, modificando un
valore chiave primaria nella tabella primaria, verrà automaticamente
aggiornato il valore corrispondente in tutti i record correlati. Quando è
selezionata la casella di controllo Elimina record correlati a catena,
eliminando un record nella tabella primaria, verranno eliminati tutti i record
correlati nella tabella correlata .Analoghe opzioni esistono in Oracle:
cfr. la ricca documentazione e le specifiche sintetiche nei lucidi di
2005P2.)
La rappresentazione di una situazione (ambiente) puo'
essere effettuata con piu’ schemi relazionali.
Es. situazione: Fornitore
Parte
\
/
Parte_fornita
Schema1: Fornitore(S#, Sname, Status, City, P#, Qty)
Parte(P#, Pname, Colore, Peso)
Schema2: Fornitore(S#, Sname, Status, City)
Parte(P#, Pname, Colore, Peso)
Parte_fornita(P#, S#, Qty)
a) I 2 schemi sono equivalenti? b) Quale schema e' migliore?
c) Si può passare da 1 a 2 in modo algoritmico?
Problemi non banali! Risposta per a) e b): dipende dal DBMS
usato: lo Schema1 puo' essere migliore se è pesante l’ operazione
di join (+avanti)); Risposta per c): si, con la normalizzazione,
95
Anna Maria Carminelli Gregori: Appunti su d.b. parte1 A.A. 2005
ma comunque l’imperativo categorico e’: SALVARE OGNI
INFORMAZIONE,
NESSUNA "PERDITA DI INFORMAZIONI" !!!
96
Anna Maria Carminelli Gregori: Appunti su d.b. parte1 A.A. 2005
… ma per S, P, SP e’ accettabile un altro tipo di
schema? Come ottenerlo?
Si puo’ partire da una Relazione Universale SP e poi
scinderla in S’ e P:
SP (S#, Sname, Status, City, P#, Pname, Color, Weight, Qty )
S’(S#, Sname, Status, City, P#, Qty)
P(P#, Pname, Color, Weight )
Si ottiene:
S# Sname Status
City
P# Qty
S1
Smith 20
London P1 300
S1
“
“
“
P2 200
“
“
“
“
P3 400
“
“
“
“
P4 200
“
“
“
“
P5 100
“
“
“
“
P6 100
S2
Jones 10
Paris
P1 300
“
“
“
“
P2 400
S3
Blake 10
Paris
P2 200
S4
Clark 20
London P2 200
“
“
“
“
P4 300
“
“
“
“
P5 400
Si noti: chiave primaria definita su 2 domini;
8*4 informazioni ripetute: ridondanza inutile…
ma e’ una relation piu’ aggregante, utile se le
operazioni di join sono frequenti e lunghe.
Altra Possibilita’ ?? NO ! DA ESCLUDERE:
S*( S#, Sname, Status, City, P1, Qty1, P2, Qty2, P3, Qt …)
perche’? NO MODIFICHE IN ORIZZONTALE !
97
Anna Maria Carminelli Gregori: Appunti su d.b. parte1 A.A. 2005
Associazioni tra 2 Entita' 
 "
" " Relations
COME? UNA delle Relations e' estesa collegandosi all'
altra tramite l' attributo comune.
COME? OPERAZIONI SULLE RELAZIONI
 livello concettuale: si effettuano le operazioni secondo
formalismi
matematici:
Algebra
Relazionale,
Calcolo Relazionale;
 livello utente: uso del D.M.L. fornito da R.D.B.M.S.
(p.es. frasi operative di SQL e/o applicazioni del 4GL
disponibile: in Access nelle interrogazioni si usa Query
By Exemple QbE);
 livello hardware: implementazione delle operazioni
con le strutture di accesso ai dati definite nello schema
fisico.
Algebra Relazionale e Calcolo Relazionale sono 2 formalismi di
cui e' dimostrata l'equivalenza (Codd, Ulmann): ogni espressione
algebrica e' riducibile ad un' equivalente espressione del Calcolo.
Il Calcolo e' basato sulla Logica Matematica (Calcolo dei
Predicati del Primo Ordine) ed appare +vicino a linguaggi
dichiarativi in cui si specificano le caratteristiche del risultato
piuttosto che la procedura per costruirlo come avviene con l'
Algebra appare +vicina a linguaggi procedurali. L' evoluzione nel
tempo di basi di dati relazionali puo' essere descritta tramite
OPERAZIONI relazionali (uso di Algebra o Calcolo
Relazionale). Es. di OPERAZIONI:
Ricerca ed estrazione di tuple:
 con dati valori per qualche attributo di una Relation;
 estese ad altri attributi di altre Relations;
 di una Relation o estese ad altri attributi di altre Relations e
ristrette a qualche attributo;
98
Anna Maria Carminelli Gregori: Appunti su d.b. parte1 A.A. 2005
 ...........
99
Anna Maria Carminelli Gregori: Appunti su d.b. parte1 A.A. 2005
Algebra Relazionale:
il risultato di operazioni e' SEMPRE una relation
(CHIUSURA  operazioni in cascata: output di un'
operazione diventa input di un' altra.)
DEF. Attributi compatibili: definiti su Domini uguali;
Relations compatibili: definite su Attributi
compatibili.
OPERATORI +INTERESSANTI (Atzeni e altri: da
pag.44)
I primi 3 operatori seguenti ed il Join sono definiti su 2 relazioni
r1, r2 compatibili.
Unione: R = r1  r2 usato in fusioni/inser.
Differenza: R=r1- r2 "
" cancellazioni
Intersezione: R=(r1  r2) Risultato: in R figurano le
tuple appartenenti a r1 E r2.
Proiezione  di R su un suo sottoinsieme di attributi;
(usato in estrazione di attributi (colonne) di R;)
Selezione  di R su un suo sottoinsieme di tuple che
soddisfano la condizione specificata nella
selezione; (usato in estrazione di tuple di R;)
Join ||: R=(r1 || r2) estensione di r1 con attributi di r2. (In
SQL-2 esistono join interni, esterni, completi
(*))
Ridenominazione  …. (cfr. esempio pag.31)
(*) Nota Il Join naturale da’ come risultato una relaz. R con
tuple ottenute dalle tuple di r1 e di r2 che abbiano valori uguali
sugli attributi comuni. Questa e’ anche la traccia del Join interno
(inner) che tralascia le tuple di una relazione senza controparte
nell’ altra. Il Join esterno completo (outer full) produce una relaz.
R con tutte le tuple di r1 e r2 estendendole con valori nulli;
100
Anna Maria Carminelli Gregori: Appunti su d.b. parte1 A.A. 2005
invece il join outer left estende solo le tuple di r1; il join outer
right estende quelle di r2.
Seguono esempi dal Date.
101
Anna Maria Carminelli Gregori: Appunti su d.b. parte1 A.A. 2005
102
Anna Maria Carminelli Gregori: Appunti su d.b. parte1 A.A. 2005
Nota Bene: la definizione degli operatori dell’ Algebra su
Relazioni compatibili (attributi definiti su domini uguali) puo’
essere troppo restrittiva come mostrano Atzeni & … col
seguente esempio:
Paternita’
Padre
Adamo
Adamo
Mose’
Giosue’
Figlio
Caino
Abele
Isacco
David
Maternita’
Madre
Eva
Eva
Ada
Dalila
Figlio
Caino
Abele
Saro
Rabin
Sarebbe significativa una relation Parent unione delle 2:
Genitore
Figlio
Adamo Caino
Adamo Abele
Mose’
Isacco
Giosue’ David
Eva
Caino
Eva
Abele
…
L’unione delle 2 relation diventa possibile solo se si usa la
Ridenominazione  che ha la precedenza su Unione :
genitore  padre(Paternita’)  genitore  madre(Maternita’)
103
Anna Maria Carminelli Gregori: Appunti su d.b. parte1 A.A. 2005
Dove si usano le operazioni dell’ Algebra Relazionale?
Soprattutto nella NORMALIZZAZIONE: processo di semplificazione
delle relations in forme piu’ agevoli da elaborare, tenendo sempre
presente la semantica della Relation  Entita’ o Legame (inter-relazione)
tra Entita’. Esistono varie forme di normalizzazione: si introduce il
processo con il seguente esempio di Relazione Globale o Universale.
Studente(
#matricola,
nome,
cognome,
indirizzo,
tasse,
esami_sostenuti, corso_di_laurea, facolta’, preside, …)
Si applica il criterio base nella normalizzazione: SEPARAZIONE
CONCETTI INDIPEN DENTI e si ottiene:
Stud_anag( #matricola, nome, cognome, indirizzo )
Stud_tasse( #matricola, tasse)
Stud_es( #matricola, esame, voto, data)
Stud_lau( #matricola, corso_di_laurea, #facolta’ )
Facolta’(#facolta’, preside)
NORMALIZZAZIONE:
1NF: atomicita' degli attributi => NO relation di relation
Es. Si considerino le seguenti entita’:
prodotti
ordini
clienti
con i seguenti attributi:
NP: #prodotto, DP: descrizione, QD: quantita’ disponibile
NO: #ordine, QO: quantita’ ordinata
NC: #cliente, PR: priorita’ cliente
La relation PR_OR_C (NP, DP, QD, NO, NC, PR, QO) ha la
seguente extension:
NP
101
DP
Viti
198
Dadi
QD
NO NC
120 11 1341
68 2400
50 51 1001
11 1341
70 2400
PR
2
4
3
2
4
QO
15
60
30
10
15
Per ogni NP c’e’ un gruppo di tuple  ripetizioni o sottorelazione
? NO! NON e’ una relazione 1NF !!!
104
Anna Maria Carminelli Gregori: Appunti su d.b. parte1 A.A. 2005
Per normalizzare in 1NF si applica il criterio base
SEPARAZIONE CONCETTI INDIPENDENTI estraendo da
PR_OR_C le 2 relations:
PRODOTTI (NP, DP, QD)
ORDINI (NP, NO, NC, PR, QO)
Come ? Operando sulle relations con l’ Algebra
Relazionale e precisamente con 2 proiezioni.
PRODOTTI(NP, DP, QD) =  NP, DP, QD (PR_OR_C)
ORDINI(NP,NO,NC,PR,QO)= NP,NO,NC,PR,QO (PR_OR_C)
Extension ?
PRODOTTI
NP
DP
101
Viti
198
Dadi
(Si noti: ogni tupla 1volta sola)
QD
120
50
ORDINI
NP
NO
NC
PR
QO
101
101
198
198
198
11
68
51
11
70
1341
2400
1001
1341
2400
2
4
3
2
4
15
60
30
10
15
PRODOTTI
E
ORDINI sono in
1NF, ma questa
forma non basta
ad
evitare
anomalie nel loro
trattamento.
Occorre la 2NF.
105
Anna Maria Carminelli Gregori: Appunti su d.b. parte1 A.A. 2005
2NF: 1NF + D.P.C. (Dipendenza Piena dalla chiave)
DPC e’ una Dipendenza Funzionale ! (temporanea,
variabile), NON e’ una Funzione ! (costante nel tempo)
Ordini(NP, NO, NC, PR, QO) Prodotti(NP, DP, QD)
(NP, NO)  QO
NP  DP
(NP, NO)  NC
NP  QD
NO  NC
In un dato momento
Dipendenza NON piena dalla in Prodotti per un
chiave  Anomalie! Quali ?
valore di NP esiste 1
1. 2. 3.
valore di DP associato
e analogamente per QD.
Dipend. Funzion. da NP piena
Anomalie!
INSERZIONE:
1. NON si puo’ inserire NC=0001 (Fiat) se in un dato
momento (cfr. Extension): o non si hanno Ordini
(NO=NULL , indefinito)
“ “
“ “
Prodotti
(NP= “
“
)
MODIFICA
2. Cambiare la priorita’ PR di NC provoca tante
modifiche quante sono le ripetizioni di NC
CANCELLAZIONE
3. Cancellare un cliente con ripetizione ha effetto
diverso da quello di cancellare un cliente che compare
una volta sola …(si perdono le relative info).
106
Anna Maria Carminelli Gregori: Appunti su d.b. parte1 A.A. 2005
CONSEGUENZA:
occorre ancora NORMALIZZARE le relazioni senza
D.P.C. estraendo da
Ordini(NP, NO, NC, PR, QO) le 2 relations:
ORD_CLI= NO,NC,PR (Ordini)
PRO_ORD = NP,NO,QO (Ordini)
Perdita di informazioni ? Controllo ad ogni passo !!
Per il Controllo si usa il join ||  DEVE risultare per
esempio:
PR_OR_C = ( PRODOTTI || ORDINI where
PRODOTTI.NP = ORDINI.NP)
Forma precedente
NO
Controllo
OKEY
Passo successivo
Passo successivo alla 2NF ?… si, ma PRIMA rifessioni sulla
NORMALIZZAZIONE in seconda Forma Normale:
2NF: 1NF e dipendenza piena dalla chiave
Dipendenza piena:
Siano due F.D. Functional Dependences: f, g.
 f & g NON sono funzioni matematiche ! perche’? …
107
Anna Maria Carminelli Gregori: Appunti su d.b. parte1 A.A. 2005
f&g
possono cambiare nel tempo (come cambiano le extension delle relative
Se in un punto del tempo A  B ossia per un dato
valore di A esiste un valore associato di B si dice che B e’
funzionalmente dipendente da A o che A determina B;(es. NCPR,
ma se si decide di dare a tutti la stessa priorità…?) Se poi avviene che A 
B e B  A allora A e B sono in corrispondenza 1 a 1 e si scrive:
A  B. Siano:
f: A1,A2,... An  B
g: A1,.. Am  B (Am+1, Am+2 ...An estranei a g)
Si dice: B e' parzialmente dipendente da A1,A2,... An.
Se per una data F.D. g non esiste, ed f ha le proprieta'
indicate, si dice: B e' pienamente
dipendente da A1,A2,... An
altrimenti bastano A1,.. Am a determinare
funzionalmente B.
Relation) !
Esempio gia’ visto con:
PRODOTTI(NP, DP, QD) &
ORDINI(NP, NO, NC, PR, QO)
da cui si sono ottenute per proiezione le 2 Relations:
ORD_CLI (NO,NC,PR) e PRO_ORD(NP,NO,QO)
L’analisi di PRO_ORD NP NO QO
101 11 15
101 68 60
198 51 30
198 11 10
198 70 15
produce: NP
NO
per…
QO
diagramma funzionale
… per evidenziare la F.D. piena di QO dalla chiave (NP,NO).
108
Anna Maria Carminelli Gregori: Appunti su d.b. parte1 A.A. 2005
Invece
NO
l’analisi di ORD_CLI
NC
11
68
51
70
1341
2400
1001
2400
PR
2
4
3
4
produce: NO
NC
NC
PR
e quindi: NO
NC
PR
TRANSITIVITA’
Logica: PR dipende esclusivamente da NC (separazione
concetti indipendenti!) PR deve dipendere dall’ unico
candidato chiave DIRETTAMENTE e NON tramite un
altro attributo: NO alla TRANSITIVITA’ altrimenti
ANOMALIE (per. es. PR=4 e’ duplicata come accadeva
prima in ORDINI e quindi anomalie in INSERZIONI,
MODIFICHE, CANCELLAZIONI)
3NF: 1NF+2NF ed inoltre attributi dipendenti solo dalla
chiave 3NF: una relation e’ in 3NF se e solo se e’ 1NF, 2NF e
gli attributi non chiave primaria dipendono funzionalmente da
essa e sono mutuamente indipendenti.
Proiettando ORD_CLI su: NO, NC, &
NC, PR, e definite:
ORDINI(NO, NC) e CLIENTI(NC, PR) si ha la 3NF_bd 
ORDINI
NO
11
68
51
70
NC
1341
2400
1001
2400
109
Anna Maria Carminelli Gregori: Appunti su d.b. parte1 A.A. 2005
CLIENTI
NC
1341
2400
1001
PR
2
4
3
PRODOTTI
NP
DP
QD
101 VITI 120
198 DADI 50
PRO_ORD
NP
NO
QO
101 11 15
101 68 60
198 51 30
198 11 10
198 70 15
Altro tipo di normalizzazione: dalla relazione Fornitori
che segue si deduce che essa e’ in BCNF (*) ma NON
in 3NF
Fornitori
NF
NOME
STATO
INDIRIZZO
(SIGLA)
01
GEO
Italia
Trieste
02
DIOR
Francia
Parigi
03
EVAN
Spagna
Madrid
04
THELLY
Norvegia
Oslo
110
Anna Maria Carminelli Gregori: Appunti su d.b. parte1 A.A. 2005
05
Valentino
Italia
Roma
Candidati chiave: NF, NOME (SIGLA)
Dipendenze Funzionali (che si deducono
Extension di Fornitori):
NF  NOME (SIGLA)
NF STATO
NF INDIRIZZO
NOME (SIGLA)  STATO
NOME (SIGLA)  INDIRIZZO
dall’
…TRANSITIVITA’
NF  NOME (SIGLA)  STATO  INDIRIZZO
(*) E’ la Boyce-Codd Normal Form introdotta dalla
domanda: … ma e’ conveniente il passaggio da
FORNITORI (NF, NOME, ADDR, STATO)
a
NOMI_FORNIT(NF, NOME, STATO)
STATI_ADDR(STATO, ADDR)
??
conviene la proliferazione di relations ?
Si eliminano anomalie, ma si introducono 2 Relation
con STATO in comune (problemi di consistenza !)
Boyce & Codd introducono un altro tipo di
Normalizzazione
con
la
definizione
di
111
Anna Maria Carminelli Gregori: Appunti su d.b. parte1 A.A. 2005
DETERMINANTE  ATTRIBUTO(I) da cui altri
attributi dipendono.
Forma Normale di Boyce-Codd (BCNF):
una Relation e’ in BCNF se ogni determinante e’
candidato chiave.
FORNITORI e’ BCNF
…meglio BCNF di 1NF+2NF+3NF ?
Seguono considerazioni e controesempi di BCNF:
Stu_mat_prof (NomeST, Materia, NomeProf)
NomeST
Pep
Pep
Pip
Pip
Materia
Latino
NomeProf
Verdi
Musica
Latino
Rossi
Verdi
Musica
Neri
Notare: chiave primaria composta e dipendente
parzialmente da un altro attributo …
Non ci sono anomalie per attributi NON chiave, ma ci
sono anomalie per la chiave:
SI in 3NF (attributi atomici, dip. piena da chiave, no transitiv.)
NO in BCNF perche’ NomeProf e’ determinante, ma
NON PUO’ ESSERE candidato chiave !
Per ottenere relations BCNF occorre proiettare Stu_mat_prof su
NomeST e NomeProf e su NomeProf e Materia con chiavi =
determinanti
NomeST
NomeProf
Materia
112
Anna Maria Carminelli Gregori: Appunti su d.b. parte1 A.A. 2005
Relations BCNF:
Stu_Prof (NomeST, NomeProf) (tutta chiave !)
Prof_Mat (NomeProf, Materia)
 Si evitano anomalie dovute alla chiave composta e
dipendente parzialmente da un attributo (!) (per es.
in Stu_mat_prof cancellando Pep che studia Musica
si perde l’ informazione che Rossi insegna Musica
…)
 Si introducono problemi di consistenza tra Stu_Prof
e Prof_Mat (per es. si puo’ inserire in Stu_Prof la
tupla Pip Rossi ? NO, perche’ Pip studia musica con
Neri … ma questo si scopre solo esaminando
Prof_Mat !!)
Conclusioni:
 BCNF e’ piu’ semplice: considera solo i
determinanti, ma non e’ detto che non porti anche
questa a proliferazione di relazioni e poi
 il processo 1NF, 2NF, 3NF e’ UTILE
113
Anna Maria Carminelli Gregori: Appunti su d.b. parte1 A.A. 2005
La verifica della validita’ della scomposizione senza
perdite si ottiene come sempre con il join:
Stu_Prof
NomeST
NomeProf
Pip
Verdi
Pip
Rossi
Pep
Verdi
Pep
Neri
Prof_Mat
NomeProf
Verdi
Rossi
Neri
Materia
Latino
Musica
Musica
R= Stu_Prof || Prof_Mat (Natural Join)
NomeST
NomeProf Materia
Pip
Verdi
Latino
Pip
Rossi
Musica
Pep
Verdi
Latino
Pep
Neri
Musica
Qui l’ extension di R e’ come quella di Stu_mat_prof
ma se Verdi oltre che Latino potesse insegnare anche
Greco_Antico (pur non avendo studenti…caso
anomalo) in Prof_Mat andrebbe inserita la tupla Verdi
Greco_Antico: il join darebbe una R con extension
diversa da Stu_mat_prof…
114
Anna Maria Carminelli Gregori: Appunti su d.b. parte1 A.A. 2005
Punto sul processo di normalizzazione:
AIUTA il ... buon senso!
"
ad evidenziare le F.D.
1NF+2NF+3NF  Relation senza anomalie su
attributi non chiave che
dipendono funzionalmente
da essa.
PERO'
se la chiave e' composta possono esistere anomalie
per gli attributi che compongono la chiave anche
nelle 3NF Relations.
Anomalie simili a quelle eliminate per gli attributi
non chiave dalla normalizzazione.
Questo tipo di anomalie capita in Relations non
BCNF => si possono eliminare scomponendo tali
Relations in altre normalizzate BCNF.
Se pero' il controllo che DEVE essere eseguito dopo ogni
passo di normalizzazione indica "PERDITA" o possibilita'
di "PERDITA" di informazioni, si deve tornare alla forma
precedente ossia 3NF.
…ed inoltre: perche’ usare chiavi composte ???
Punto e spunto di riflessione !
115
Anna Maria Carminelli Gregori: Appunti su d.b. parte1 A.A. 2005
MVD e 4NF
Nella
R(A,B,C)
con A,B,C disgiunti,
A multidetermina B nell' ambito di C
A  B | C
se l' insieme dei valori di B che si presentano con una
data coppia di valori di
A e C, dipende SOLO dal valore di A e non
da quello di C.
Questa dipendenza si dice a multivalore:
Multi_Valued Dependency = MVD e si indica con
.
4NF: Una Relation e' 4NF se:
(Ceri) e' in 3NF senza MVD;
(Date) in presenza di un
multideterminatore, questo e'
candidato chiave (...tutti gli
altri dipendono da lui!!)
Es. in Carriera_Employ .
116
Anna Maria Carminelli Gregori: Appunti su d.b. parte1 A.A. 2005
Carriera_Employ
E#
e1
e1
e1
e1
e2
e2
e2
e2
...
Data
1.1.70
1.1.70
1.1.73
1.1.73
1.1.78
1.1.78
1.1.81
1.1.81
....
Figli
Stipendio
Lilla
2.500.000
Lella
2.500.000
Lilla
3.000.000
Lella
3.000.000
Pippo
3.200.000
Peppa 3.200.000
Pippo
3.800.000
Peppa
3.800.000
.....
.....
Gruppi ripetitivi senza dip. incomplete e/o transitive.
Da E# dipendono Figli e Stipendio a gruppi ripetitivi.
La data vuole evidenziare la progressione temporale:
e' eliminabile!
E#  Figli | Stipendio
E#  Stipendio | Figli
E# = il MULTIDETERMINATORE
Proiezione di (Carriera_Employ) su E#,Figli
Proiezione di (Carriera_Employ) su E#,Data,Stipendio
117
Anna Maria Carminelli Gregori: Appunti su d.b. parte1 A.A. 2005
Separazione concetti indipendenti .... BUON SENSO!
Nell’ esempio seguente si noti la differenza tra la 1NF
e la 4NF dove le sottorelazioni sono “nascoste”.
118
Anna Maria Carminelli Gregori: Appunti su d.b. parte1 A.A. 2005
Employ1(E# , Figli, Stipendio)
E#
Figli
Stipendio
e1
Lilla
2.500.000
e1
Lello
2.500.000
e1
Lilla
3.0 00.000
e1
Lello
3.0 00.000
e2
Pippo
2.6 00.000
e2
Peppo
2.6 00.000
e2
Pepi
2.6 00.000
e2
Pippo
2.9 00.000
e2
Peppo
2.9 00.000
e2
Pepi
2.9 00.000
E#  Stipendio|Figli
E#
Figli
Stipendio
e1
Lilla
2.500.000
e1
3.000.000
e1
Lello
2.5 00.000
e1
3.0 00.000
e2
Pippo
2.6 00.000
e2
2.9 00.000
e2
Peppo
2.6 00.000
e2
2.9 00.000
e2
Pepi
2.6 00.000
e2
2.9 00.000
(Tutta chiave !)
E# Figli|Stipendio
E#
e1
e1
e1
e1
e2
e2
e2
e2
e2
e2
Figli
Lilla
Lello
Lilla
Lello
Pippo
Peppo
Pepi
Pippo
Peppo
Pepi
Stipendio
2.500.000
3.0 00.000
2.6 00.000
2.9 00.000
119
Anna Maria Carminelli Gregori: Appunti su d.b. parte1 A.A. 2005
Anomalie ?
Se e1 passa allo stipendio di 4.000.000 occorre inserire
tante tuple quanti sono i suoi figli e cosi’ se e2 ha un
quarto figlio Leila occorre inserire tante tuple quanti
sono gli stipendi da lui percepiti …
Employ1 e’ 1NF, 2NF, 3NF, BCNF, ma non 4NF: e’
una Relation TUTTA CHIAVE e nella chiave
compaiono multideterminatori (E#).
Si proietta sul multideterminatore e su ogni attributo
da questo dipendente. In questo caso si ottiene:
Emp1
E#
e1
e1
e2
e2
e2
Figli
Lilla
Lello
Pippo
Peppo
Pepi
Stip1
E#
e1
e1
e2
e2
Stipendio
2.500.000
3.000.000
2.600.000
2.900.000
120
Anna Maria Carminelli Gregori: Appunti su d.b. parte1 A.A. 2005
Una base di dati in 4NF e’ libera da join dependency?
NO!
5NF o PJ/NF
R e’ in 5NF se e’ libera da join dependency (+avanti)
…ma decomponendo, decomponendo si arriva ad una base
di dati UNARIA (!) ossia un insieme di archivi inversi (*)
in cui interrogazioni e ricerche potranno essere molto
efficienti, ma si avra’ … notevole pesantezza nella
ricostruzione del record attraverso “DRIVEN
join
operation”.
La normalizzazione e’ bene farla e spingerla anche al
massimo, salvo poi tornare indietro alla NF piu’
conveniente.
Misura convenienza: dipende dal tipo e dalla frequenza
delle operazioni.
(*) Archivio: insieme di record contraddistinti da una chiave
(primaria) e da tanti campi (attributi) tra cui si potranno
considerare alcune chiavi secondarie. (Queste identificano
generalmente un gruppo di record come per es. il colore che
identifica un insieme di automobili.)
 Indice su un attributo: e’ una funzione che restituisce l’
indirizzo dell’ attributo.
 Archivio Inverso: insieme di attributi indicizzati (ossia di
Indici) con scambio di ruolo tra record e attributi (da usare con
l’ originale altrimenti la gestione e’ difficile).
 Esempio: testo = archivio(informazione)
informazione = archivio-1(testo)
Indice
121
Anna Maria Carminelli Gregori: Appunti su d.b. parte1 A.A. 2005
+facile reperire le informazioni, ma –facile concatenarle
Join dependency: esempio
Articolo (#artic, Descrizione, Prezzo,
Tax)
si proietta ottenendo:
Art1(#artic, Descrizione)
Art2((#artic, Prezzo, Tax)
La Join dependency di Articolo rispetto alle 2
proiezioni deriva dalla presenza della chiave di
Articolo nelle sue proiezioni ed e’ quindi dovuta alla
dipendenza (FD o MVD) che ogni attributo ha
rispetto alla chiave. Tale dipendenza e’ detta
conseguenza della chiave della relazione.
Esistono Join dependency che NON
conseguenza di chiavi o chiavi candidate.
sono
5NF/PJ (PJ = Project Join)
La relation R e’ in 5NF/PJ se e solo se ogni
dipendenza di tipo join in R e’ una conseguenza delle
chiavi o chiavi candidate in R. (Es. Articolo e’ 5NF.)
122
Anna Maria Carminelli Gregori: Appunti su d.b. parte1 A.A. 2005
La 5NF introduce l’ indagine sulle mutue dipendenze
anche all’ interno degli attributi che eventualmente
compongano la chiave primaria.
5NF e decomposizioni possibili senza perdite.
Conseguenza della chiave primaria: Atzeni & …
danno una condizione meno stringente della
precedente (Date).
Una Relation si decompone senza perdite su
2 Relations se l' insieme degli attributi
comuni alle 2 Relations (ossia la loro intersezione) e'
chiave per almeno 1 delle Relations decomposte.
Formalmente: sia R cosi' definita:
R(X) con X=gruppo di attributi e
X1,X2 sottoinsiemi di X,
tali che X = X1  X2
e X0 = X1  X2.
Condizione per decomposizioni senza perdite:
se in R risulta X0X1 oppure X0X2 (ossia X0 e'
chiave per almeno 1 delle Relations in cui R e’
decomponibile) allora R si decompone senza perdite
su X1 e X2.
Es. CPS(Custode, Progetto, Sede)
L' analisi indica: Sede = residenza Custode
Sede = luogo di sviluppo Progetto
E si puo’ porre: X= Custode, Progetto, Sede;
123
Anna Maria Carminelli Gregori: Appunti su d.b. parte1 A.A. 2005
X1= Progetto, Sede; X2= Custode, Sede
Avendo il Vincolo_1 che una Sede possa ospitare un
solo progetto avremmo Sede  Progetto e quindi
decomponendo risulterebbe la situazione seguente:
CPS si decompone senza perdite in PS(Progetto,Sede)
e CS(Custode, Sede)
CPS
Custode
Rossi
Progetto
Marte
Sede
Roma
Verdi
Giove
Milano
Neri
Venere
Torino
PS
Progetto
Marte
Giove
Venere
CS
Custode
Rossi
Verdi
Neri
Sede
Roma
Milano
Torino
Sede
Roma
Milano
Torino
124
Anna Maria Carminelli Gregori: Appunti su d.b. parte1 A.A. 2005
qui Sede potrebbe essere anche chiave, ma l’analisi non lo
impone!
e aggiungendo in CPS: Verdi Saturno Milano??
Col Vincolo_1 non si puo’ !! Milano ospita gia’
Giove!
Si dimostra la Condizione ricostruendo la R di
partenza col join delle sue 2 proiezioni e tenendo
presente che X0 e' chiave per almeno 1 delle 2
proiezioni e determinante nella R di partenza: la tupla
ricostruita deve coincidere con quella di partenza
proprio per l’ unicita’ dei suoi valori, unicita’ dovuta
alle 2 determinazioni (X0 e' chiave e determinante !)
Si dimostra la sufficienza della condizione con la
considerazione che si hanno decomposizioni senza
perdite anche per estensioni di R che non soddisfano
la Condizione. Come esempio di cio’, tolto l’ ultimo
vincolo, l’ inserimento in CPS di: Verdi Saturno
Milano non provoca aggiunta di tuple spurie da parte
del join! (pur non essendo piu’ X0=Sede chiave in PS
…)
La Condizione stabilisce che tutte le relations che
soddisfano certe dipendenze si decompongono senza
perdite. Quindi e’ opportuno osservarla se si vuole che
le decomposizioni soddisfino le proprieta’ di essere:
1. Senza perdite di informazioni;
125
Anna Maria Carminelli Gregori: Appunti su d.b. parte1 A.A. 2005
2. Con conservazione delle dipendenze  forma di
decomposizione rispettosa delle FD e MVD e dei
vincoli.
Qualita’ delle decomposizioni !
Se l’ analisi e’ ben fatta …
Seguono esempi di relation NON in 5NF con
decomposizioni
possibili
e
opportune
e
decomposizioni impossibili.
1. Esempio JSP tratto da Date. Con: S=Supplier,
P=Part, J=Project si ha la relation tutta chiave con
Schema SPJ(S#, P#, J#) che aggrega i fornitori di
parti necessarie per qualche progetto ed ha la
seguente extension:
SPJ
S# P# J#
S1 P1 J2
S1 P2 J1
S2 P1 J1
S1 P1 J1
Le sue 3 proiezioni binarie sono: SP, PJ, JS. La
ricostruzione con il join delle coppie (per es. di SP e
PJ) non riproduce JSP.
SP
S#
S1
P#
P1
SPJ*
S1 P1 J2
S1 P1 J1
126
Anna Maria Carminelli Gregori: Appunti su d.b. parte1 A.A. 2005
S1 P2
S2 P1
PJ
P# J#
P1 J2
P2 J1
P1 J1
Join(SP, PJ)
produce SPJ
+ una tupla
spuria
Perche’?
 Ogni dipendenza in SPJ non e’ Conseguenza della
chiave primaria in ciascuma delle 3 proiezioni
non e’ presente la chiave primaria.
 In ogni coppia delle proiezioni non e’ verificata la
Condizione sufficiente  per es. l’ attributo
comune P# non e’ chiave primaria ne’ in SP ne’ in
PJ.
Tornando a SPJ e SPJ*, il join di SPJ* con JS sulla
coppia (J#, S#) che ha la seguente extension:
JS
J# S#
J2 S1
J1 S1
J1 S2
da’come risultato proprio SPJ originale (la coppia
S2,J2 della tuple spuria non c’e’ in JS)
Si puo’ affermare che risulta: SPJ=SP || PJ || JS ?
??
127
Anna Maria Carminelli Gregori: Appunti su d.b. parte1 A.A. 2005
Se in SPJ si cancella l’ ultima tupla = S1 P1 J1, restano
inalterate le sue 2 proiezioni SP e JS; restando inalterata
SP resta inalterata anche SPJ* con la tupla S1 P1 J1 ora
spuria e questa resta anche dopo il join con JS  il
risultato non e’ piu’ uguale alla nuova extension di SPJ.
Date afferma che per togliere questa incongruenza occore
un vincolo di integrita’ del tipo: la parte P# non puo’ essere
cancellata per un fornitore (S1 P1 J1) e lasciata per un altro
(S2 P1 J1) nell’ ambito dello stesso progetto J#.
Al fine di ricostruire con l’ operazione di join, una
relation dove non appaiano tuple spurie, occorre un
vincolo sulla relation originale che ne obblighi la
“completezza”.
Es. per la relation SPJ:
se esiste un fornitore di P1
in ambito J1 e
“ “
una parte fornita da S1 “ “
“ “
“ “
un progetto per la parte P1 del fornitore S1
allora deve esistere anche la tupla S1, P1, J1
ossia S1 deve fornire P1 nell’ ambito di J1.
Formalmente:
se nella relation R(A, B, C) esistono le tuple:
A1, B1, x
y, B1, C1
A1, z, C1
con x, y, z qualunque,
allora deve esistere anche A1, B1, C1.
128
Anna Maria Carminelli Gregori: Appunti su d.b. parte1 A.A. 2005
Questo e’ detto un vincolo 3D e deve controllare ogni
operazione su R.
Nell’ esempio visto, con questo vincolo su ogni operazione
su SPJ, il join delle 3 relations SP, PJ, JS coincide con SPJ
che soddisfa la join dependency (JD) ed e’ 3-decomponible
(non 2- decomponible). Tuttavia SPJ non e’ 5NF secondo
la definizione data (nelle proiezioni non c’e’ la chiave come
per es. in Articolo) e in assenza del vincolo 3-D presenta
anomalie sia in cancellazione che in inserzione.
Contestazioni:
Il vincolo 3D va bene in teoria, ma in pratica ?
Con tale vincolo se risulta:
S1
Sy
S1
allora
esiste
S1
P1 Jx
P1 J1
Pz J1
P1 J1
Ma nelle ipotesi che:
per Jx la quantita’ necessaria di P1 sia 1000 mentre
per J1 sia 2000 ed il fornitore S1 ha la parte P1 solo in
quantita’ 1000,
allora piuttosto che rinunciare fornirebbe P1 per Jx e
non per J1 …
129
Anna Maria Carminelli Gregori: Appunti su d.b. parte1 A.A. 2005
ma il vincolo vieta questa possibilita’ ossia l’
inserzione della tupla S1 P1 Jx comporta anche
quella della tupla S1 P1 J1.
Altra contestazione: cfr. es. successivo.
2. Il problema della Join dependency e del vincolo 3D
appare anche nella relation Lesson ove il vincolo 3D
non vale (VERIFICARLO !)
e quindi e’
opportuno non decomporla.
(estratto dispense 1 pagina)
130
Anna Maria Carminelli Gregori: Appunti su d.b. parte1 A.A. 2005
131
Anna Maria Carminelli Gregori: Appunti su d.b. parte1 A.A. 2005
Conclusioni sul processo di normalizzazione:
a) Fare le proiezioni opportune per eliminare le F.D.
passando per 1NF + 2NF + 3NF;
b) La relation ottenuta e' BCNF?
se lo e' tutto bene, altrimenti proiezioni e controlli;
c) Fare le proiezioni per eliminare le M.V.D.
d) "
" "
" "
o evidenziare
eventuali JD.
Ricordare che avendo la relation R(A,B,C):
per le F.D. se risulta AB e BC
(e quindi AC) e' meglio proiettare
in modo da ottenere: R1(A,B) e R2(B,C) con
rispetto della transitivita';
per le M.V.D. solo se A B e B C
va bene la decomposizione di sopra
(R1(A,B) e R2(B,C)) in quanto A e B
sono entrambi multideterminatori;
se invece multideterminatore e' solo A allora
va bene decomporre in R1(A,B) e R3(A,C)
La ricerca attuale punta a:
domini di vincoli;
normalizzaione di tipo "ortogonale" alla precedente
(Restriction-Union contro Projection-Join) in modo da
ridurre la Cardinalita'; analisi  Sistemi +furbi!
132
Anna Maria Carminelli Gregori: Appunti su d.b. parte1 A.A. 2005
Tornando alla frase Create, la si puo’ usare per costruire non solo
Relations (tabelle) normalizzate (!), ma anche Indici, Viste, …
Come gia’ indicato (lucido 69 e seg.) concettualmente l' indice
e' una funzione f(x) definita su una "variabile x" i cui valori
seguono un certo ordinamento (per es. crescente). La f(x)
restituisce il valore corrispondente della variabile
dipendente, che puo' essere definita su un insieme di pagine,
di byte, ..... Il valore restituito e' quindi l' indirizzo della pagina
o del byte relativo alla "variabile x".
ES. su relation
|_ Impiegato____________________|
|
E# Data_Assun. Nome #Ufficio |
|_____________________________|
|__TID__|
|
e1
1. 1.70
Billi
2 |
|__100__|
|
e2
1. 1.75
Pia
1 |
|__110__|
|
e3
21.10.74
Lele
1 |
|__120__|
|
e4
1. 1.78
Pippo
4 |
|__130__|
|
e5
1. 1.78
Billi
3 |
|__140__|
|
e6
1. 1.81
Pippo
8 |
|__150__|
|
e7
1. 1.81
Pia
6 |
|__160__|
|
...
....
.....
..... |
|__......__|
T.I.D = Tuple IDentifier ossia indirizzo di tupla = record
133
Anna Maria Carminelli Gregori: Appunti su d.b. parte1 A.A. 2005
Indice su E#: TID = f(E#)
|Index su E#|
|_E#____TID __|
|
e1
100
|
|
e2
110
|
|
e3
120
|
|
e4
130
|
|
e5
140
|
|
e6
150
|
|
e7
160
|
...
Unique, Clustered!
Indice su Nome: TID = f(Nome)
| Index su Nome |
|_Nome____TID______|
| Billi
100, 140 |
| Lele
120
| Pia
110, 160 |
| Pippo
130, 150 |
|
...
NOT Unique, UNClustered!
134
Anna Maria Carminelli Gregori: Appunti su d.b. parte1 A.A. 2005
... come
si implementano ? Cfr. Strutture dati (parte3 in
db2005p3)!
ACCESSO SEQUENZIALE CON INDICE
Obiettivo: rendere efficiente accesso sequenziale come l’accesso casuale.
Realizzazione: sia l' archivio A sequenziale rispetto a chiave c con record
raggruppati in blocchi dove ogni blocco contiene: al più N record e
almeno N/2 record (b*-tree Cfr. Strutture dati in db2005p3)
Inizialmente: blocchi ordinati e concatenati
Esempio: l’ archivio A contiene n record qui sintetizzati col solo nome
blocco 1
!--------------!
blocco 2
blocco 3
!------------!
!-------------!
!ABA.....CARLI!-->!CEO.....ESPO!-->!LAGO......MEO!..
!--------------!
!------------!
!-------------!
Indice T: per associare a ciascun blocco i record ivi contenuti usa la chiave (qui
il nome) del record
da ABA a CARLI blocco 1
da CEO a ESPO
blocco 2
da LAGO a MEO
Forma di T = Indice di accesso su A
blocco 3
CHIAVE
....................
INDIRIZZO BLOCCO
CARLI
1
ESPO
2
MEO
3
..........................
135
Anna Maria Carminelli Gregori: Appunti su d.b. parte1 A.A. 2005
Realizzazione di T: tabella se T entra in C.M. (o meglio albero binario
di ricerca che non decada in lista lineare modello AVL o BB-tree);
albero paginato di ordine m altrimenti (B*-tree).
Creazione di un indice in ambiente relazionale 
creazione di un indice in SQL con la frase Create gia’
usata in Create table S, P, SP.
Create {Unique} Index <name> on <table(attributes)
ES. Create Unique Index XS on S(S#)
“
“
“
XP on P(P#)
“
“
“
XSP on SP(S#,P#)
“
Index XSC on S(City)
Con Unique, due tuple dell’ Indice NON possono avere
lo stesso valore.
Ci sono altre possibili clausole, per es.
Create Index Z on T(P asc, Q desc, R) Cluster
Effetto: viene creato l’ indice Z sulla Relation T in cui i
valori di P sono considerati in ordine ascendente, i
“
“Q “
“
“ “
discendente, e quelli
di R anche in ordine ascendente, assunto per default;
questo indice gode della proprieta’ di clustering ossia
determina un ordinamento logico corrispondente alla
memorizzazione delle tuple.
Gli Indici sono automaticamente aggiornati con le
rispettive relation fino alla cancellazione o dell’ Indice o
della relation che si fa con :
Drop table T per la relation T
136
Anna Maria Carminelli Gregori: Appunti su d.b. parte1 A.A. 2005
Drop Index Z “ l’ Indice Z.
La frase Create si usa anche per costruire schemi esterni
o VISTE D’ UTENTE che per il modello relazionale e
sistemi relativi ( per es. DB2) sono Virtual Relation ossia
relazioni rappresentate in funzione di relazioni vere,
fondamentali !
Esempio
Sia la seguente vista cosi’ definita:
V =  S#, City, Qty (S || SP where S. P# = ’P2’)
dove V e’ il nome della vista e a destra dell’ uguale
c’e’ un’ espressione (qui dell’ Algebra Relazionale).
Sia il nome della vista che l’ espressione sono salvate
nel Catalogo (cfr. seguito).
Quando c’e’ una richiesta che impone l’ uso della
vista, RDBMS sostituisce al nome della vista l’
espressione che la definisce. Cosi’ avendo:
 City (V where Qty > 200)
RDBMS “traduce” in;
 City ( S#, City, Qty (S || SP where S. P# = ’P2’)
where Qty > 200)
Le espressioni (qui dell’ Algebra Relazionale) saranno
scritte nel linguaggio usato da RDBMS ossia SQL in
veste di DDL e DML con le frase tipiche Create e
Select. (cfr. seguito). Le viste sono anche usate (per es. in
137
Anna Maria Carminelli Gregori: Appunti su d.b. parte1 A.A. 2005
per effettuare interrogazioni (query) anche
nidificate con risultati immediati e incisivi.
Oracle)
138
Anna Maria Carminelli Gregori: Appunti su d.b. parte1 A.A. 2005
Ecco le viste modificabili e non nello schizzo tratto da Date.
139
Anna Maria Carminelli Gregori: Appunti su d.b. parte1 A.A. 2005
Tabelle, indici, viste compaiono nel CATALOG (Dizionario dei
Dati e relative indicazioni) del RDBMS che contiene i metadati
(dati che descrivono i dati) sotto forma di tabelle. Senza entrare in
particolari delle varie realizzazioni come SQL-2 o SQL:1999 e’
importante sottolineare la riflessivita’, caratteristica comune dei
Dizionari Dati di sist. relazionali. Questa caratteristica prevede
per i metadati la loro descrizione sia con la strutture tipiche
(tabelle) usate per i dati sia la loro descrizione all’ interno di
queste tabelle . Cosi’ le interrogazioni (non modifiche !) al Catalog
potranno essere fatte con la frase Select (cfr. seguito) usata per le
tabelle dei dati. Prendendo ancora gli esempi di DATE, segue il
Catalog del d.b. usato dove si e’ voluto evidenziare la riflessivita’
(cfr. Name SYScolumns e Tbname SYScolumns di tipo Char
all’ interno di SYScolumns)
|_ SYSTABLES_____________|
|_ SYScolumns _________|
| Name
Creator Coloncout |
| Name Tbname Coltype |
| S
Janice
4 |
| S#
S
Char
|
| P
Janice
5 |
| Sname S
Char
|
| SP
Janice
3 |
|
3 |
| P#
|SYScolumns System
…etc. ….
|
P
Char
|
|_ SYSINDEXES _________|
| Pname P
Char
|
| Name Tbname Creator
|
|
| XS
S
Janice
|
| S#
| XP
P
Janice
|
|
| XSP
SP
Janice
|
|Name SYScolumns Char |
…etc. ….
SP
…etc. ….
|
Char
|
|
140
Anna Maria Carminelli Gregori: Appunti su d.b. parte1 A.A. 2005
| XSC
S
Janice
|
|Tbname Syscolumns Char
|
etc…
Data Manipolation Language = SQL in RDBMS
Frase principale (espressa in forma sintetica) che “manipola”
le relazioni e restituisce sempre una relazione:
Select <attributi> {funzioni} //clausola Select
from <relation(s)>
// “
from
{where <condition>}
// “
where
{altre clausole come odered (= ordinati)
group by (= raggruppati per attributi)
…}
Nelle clausole Select e from si possono usare alias preceduti (o no)
da as; nel from può essere indicata esplicitamente l’ operazione di
join on come indicato di seguito. (In Access dopo il from ci può
essere la clausola into <tabella da essere creata>)
A parte l’ indicazione esplicita del join, come si distinguono le
operazioni dell’ algebra relazionale?
Proiezione  su S#, Sname  Select S#, Sname as NameSup
from S
Proiezione  su S#, Sname
e Selezione 
 Select S#, Sname
from S
where City = Paris and Status>9
Join ||: S || P su attributo  Select S.*, P.*
comune City
from S, P
where S.City = P.City
La condizione sotto where puo’ essere composta, con and, or o puo’
avere operatori > <   o puo’ mancare … tante possibilita’. In SQL-2
si puo’ esprimere il join esplicitamente nella clausola from
aggiungendo dopo il nome della prima Tabella: {[tipo Join] join
141
Anna Maria Carminelli Gregori: Appunti su d.b. parte1 A.A. 2005
Tabella_seconda on Condizione _di_Join} dove tipo Join puo’ essere:
inner (default), right outer, left outer, full outer. Nell’ esempio: Select
S.*, P.* from S join P on S.City = P.City (e volendo un ulteriore
condizione: where S.City = Paris).
Interrogazioni Nidificate (a 2 e +livelli): come semplice
esempio
tre formulazioni della stessa richiesta che vuole i nomi dei fornitori
della parte P2
1. Select Sname
from S
where S# in (‘S1’, ‘S2’, ‘S3’, ‘S4’)
significato: estrai i nomi relativi ai codici ‘S1’, ‘S2’, ‘S3’, ‘S4’
(fornitori di P2) ! Formulazione elementare!
2. Select Sname
from S
where S# in (Select S#
from SP
where P# = ‘P2’)
Relazione unaria
contenente gli S#
relativi a parte P2
significato: estrai i nomi dei fornitori della parte P2
Formulazione +vicina all’ Algebra relazionale
3. Select Sname
from S
where exists
(Select *
from SP
where S#=S.S# and
P# = ‘P2’)
142
Anna Maria Carminelli Gregori: Appunti su d.b. parte1 A.A. 2005
Formulazione +vicina al Calcolo Relazionale con uso del
quantificatore esistenziale exists che diventa True solo se la relazione
restituita dal Select che lo segue NON e’ vuota.
Interpretazione delle interrogazioni nidificate: viene costruito il
prodotto cartesiano delle tabelle ossia per ogni tupla della query
esterna e’ valutata la query nidificata e quindi il predicato (della
clausola where) rispetto alla tupla. Questa procedura puo’ essere
ripetuta per ogni livello di nidificazione.
Clausole, Operatori & Funzioni aggregate di SQL (Order
by, Group by, Having, Count, Sum, Max, Min, Avg, Like)
e le parole chiave any ed all.
Seguono alcuni esempi:
any
Select S#, Status
Order by
From S
Select S#, Status
Where City = any (Select City
From S
From P)
Where City = ’Paris’ (Significato: …dove il valore di City e’uguale ad
Order by Status Desc; almeno uno dei valori dell’attributo omonimo di P)
S#
Status
S3
30
S2
10
Sum ( )
Select Sum(Qty)
From Sp
Where P# = ’P2’;
P#
Sum(Qty)
P2
1000
Group by & Sum ( )
Select P#, Sum(Qty)
From Sp
Group by P#;
143
Anna Maria Carminelli Gregori: Appunti su d.b. parte1 A.A. 2005
P#
P1
P2
P3
P4
P5
P6
Sum(Qty)
600
1000
400
500
500
100
Esempio di Like: Condizione WHERE: [Nome Società] Like "B*"
filtra i nomi delle Società che iniziano per B.
Oltre alle funzioni aggregate,
SQL offre anche la possibilità di usare funzioni scalari (per
es. quelle temporali come current_time_stamp o le
funzioni condizionali: coalesce, nullif, case. Il case è
simile al switch del C mentre nullif e coalesce sono
“complementari”. Un esempio: la query
Select S#, Sname, Coalesce(Citta, ‘Ignoto’) from S
restituisce Ignoto se il nome di citta manca; la query
Select S#, Sname, nullif(Citta, ‘Non disponibile’) from S
restituisce il valore nullo se il nome di citta è ‘Non
disponibile’.
E poi attenzione ai duplicati ! La proiezione di SQL differisce
da quella dell’ Algebra Relazionale perche’ non elimina le
righe duplicate:
per farlo occorre inserire la clausola Distinct:
Select City
From S
City
London
Paris
London
144
Anna Maria Carminelli Gregori: Appunti su d.b. parte1 A.A. 2005
Paris
Athens
Select Distinct City
From S
City
London
Paris
Athens
In SQL esistono anche Operatori di tipo insiemistico come:
union, intersect, except, all che coinvolgono 2 relation
costruite con la frase select con possibile eliminazione dei
duplicati. Un esempio:
Select Sname from S union Select Status from S
produrrebbe una relation unaria con tutti i nomi di S, seguiti da
3 soli Stati; invece Select Sname from S union all Select
Status from S produce tutti gli Stati anche con i duplicati.
Esistono molti altri possibili modi di utilizzo delle frasi,
clausole e funzioni di SQL viste e altre frasi come Alter,
(modifica) Insert into e Update <nome di Relation> (con
ovvio significato).
Altre possibilita’ sono: i cluster (raggruppamenti) ed i trigger
(reazioni o regole attive che si innescano al verificarsi di un
evento se le condizioni in essi contenute sono soddisfatte), ma
di questi se ne parlerà con Oracle insieme ai Cluster.
Ci sono altre due caratteristiche interessanti di SQL che si
evidenziano quando SQL viene usato dall’ interno di
programmi scritti in altri linguaggi come per es. in C. Si tratta
145
Anna Maria Carminelli Gregori: Appunti su d.b. parte1 A.A. 2005
dell’uso di cursori e della specialità di SQL che può
presentarsi come statico o dinamico.
Come già indicato (luc.81) “l’ uso interattivo di SQL diventa
pesante ed e' sostituito da applicazioni di 4GL”. Però l’
interazione diventa necessaria quando occorre definire la query
da effettuare sui dati al momento dell’ esecuzione. Si parla in
questo caso di SQL dinamico. Perché dinamico? Per
contrapporlo a statico, aggettivo che si usa in analogo contesto
che è il contesto di SQL “Embedded” ossia incapsulato in
altri linguaggi di programmazione.
Incapsulamento di SQL
Incapsulare le istruzioni di SQL in un linguaggio come il C++,
il Java, il Cobol … è la prima di 2 soluzioni esistenti per usare
SQL da un programma scritto in tali linguaggi. (Con la seconda
soluzione il programma fa ricorso ad una libreria di funzioni
che permettono di interagire col DBMS ossia usa il Call Level
Interface (CLI) ... purchè il Sistema in uso ne sia dotato.)
Con l’ incapsulamento di SQL invece è necessario un
precompilatore del linguaggio ospite che riconosca le istruzioni
SQL e sostituisca ad esse le relative chiamate ai servizi del
DBMS. Per distinguerlo dalle normali istruzioni del
linguaggio, lo Standard SQL vuole che il codice SQL sia
preceduto dalla stringa: exec sql e finisca col ; . Si tratta di
una buona soluzione, ma come detto sopra occorre che nel
Sistema in uso funzioni la combinazione DBMS-ComputerLinguaggio-Precompilatore.
146
Anna Maria Carminelli Gregori: Appunti su d.b. parte1 A.A. 2005
Atzeni &…Vol.1 pag. 165 riportano un esempio di un
programma in C in cui compaiono le frasi: ….
exec sql connect to utente@librobd;
………………………….
exec sql insert into Dipartimento
.....
Non tutto si esaurisce con exec sql: per esempio oltre l’
incapsulamento di SQL anche la dichiarazione delle variabili C deve
essere racchiusa tra exec sql begin declare section; e exec sql
end declare section; dopo le variabili si possono usare come
parametri dei comandi SQL purchè siano precedute da “:”. Inoltre per
le comunicazioni tra programma in esecuzione e DBMS occorre usare
una struttura dati introdotta dal precompilatore sqlca (SQL
communication area) … insomma tutto facile, ma non immediato.
E poi c’è il problema dell’ accesso alle tabelle e del loro
aggiornamento ossia dell’estrazione o inserimento di un
insieme di tuple. SQL gestisce globalmente le tabelle, mentre i
linguaggi di programmazione usano un’ impostazione orientata
alle righe.
Anche qui le soluzioni sono 2 di cui la seconda usa modelli di
dati, interfacce, e librerie Call Level Interface (CLI) che
permettono la gestione di tabelle in modo globale come insiemi
di record. Si tratta di strumenti necessari soprattutto nei
sistemi di elaborazione distribuita o sistemi di rete di cui si
riparlerà in db2005p2 a partire da pag. 87 e seg.
La prima soluzione usa i cursori alle righe di una tabella
definendoli con un
Declare Nomecursore [scroll] cursor for Select ….
[for <read only | update[ of lista Attributi]> ]
e poi usando un insieme di comandi come:
147
Anna Maria Carminelli Gregori: Appunti su d.b. parte1 A.A. 2005
open Nomecursore,
fetch [Posizione from ]Nomecursore into lista Attributi,
dove Posizione può essere omessa ed allora è considerata la
riga corrente e può essere: next, prior, first, last … con ovvio
significato.
Una procedura C che mostra l’ uso di cursori sta in Atzeni
&…Vol.1 pag. 165. Notare che se un’ interrogazione
restituisce una sola tupla (query scalare) non occorre usare
cursori: basta usare la clausola into seguita dai nomi delle
variabili precedute da ”:”. Es. exec sql
Select Sname, Status, City
into :Nome, :Stato, :Città
from S
Where S# = :matricS;
Queste note, che vogliono solo essere indicazioni di massima
essenziali per un primo approccio a SQL, si concludono con una
sintesi.
Le frasi di SQL possono essere raggruppate nelle categorie
seguenti:
Definizione dei Dati (DDL) = Create, Alter (modificare) Drop,
Rename, Truncate, Analyze
(analisi statistiche), Grant &
Revoke (per concedere e
revocare privilegi e priorita’),
Replace Wiew, Comment.
Manipolazione dei Dati (DML) = Insert into, Delete from
(aggiungere Tuple in,
o cancellarne da, una Tabella)
Lock Table (bloccare
tabelle), Select, Update (o Alter
148
Anna Maria Carminelli Gregori: Appunti su d.b. parte1 A.A. 2005
aggiornare i valori dei dati).
Controllo delle transazioni = Commit, Rollback, Set
Transaction (stabilire le
proprieta’ di trans.), Savepoint
(fissare un punto cui risalire)
Controlli Vari (Sistema, Sessioni …)
Ci sono poi le frasi di “SQL esteso” ossia di “dialetti” di SQL tipiche dei
vari RDBMS con specifiche diverse e usate per CONNettersi ad un d.b. e
DISconnettersi, aprire un d.b. o una Table, Esportare-Importare dati …
A questo punto proprio per “sperimentare” dal vivo un RDBMS sarebbe
opportuno parlare di Oracle, ma data la sua Architettura che si pone nell’
ottica delle Architettture Client-Server a 3 livelli (d.b. di tipo “distribuito”)
il discorso e’ rimandato alla Parte2 dopo l’ introduzione a tali Architetture.
FINE Parte 1
149