Basi di Dati Relazionali
Dario Colazzo
Università di Pisa
Dipartimento di Informatica
Corso Italia, 40
Pisa, 56125
email: [email protected]
telefono: +39 050 887265
Cos’è un database
Un databse (relazionale) e’ l’insieme degli
strumenti per memorizzare e manipolare dati in
modo “efficiente ed efficacie” allo scopo do
ottenere informazioni utili in un preciso contesto.
Il concetto di dato e’ diverso dal concetto di
informazione
Fino a 30 anni fa, i database venivano creati dal
nulla (sistemi di archiviazione)
Oggi abbiamo i sistemi di gestione di basi di dati
o DBMS (data base management system).
Basi di dati
Dario Colazzo
2
Database relazionali
In questo corso ci occuperemo dei
database piu’ comunemente
utilizzati: i database relazionali.
I sistemi di gestione di basi di dati
relazionali vengono chiamati RSGBD.
Basi di dati
Dario Colazzo
3
Terminologia dei database
relazionali
Un database relazionale modella alcuni aspetti
del mondo reale. La parte del mondo reale
modellata e’ detta spazio del problema
La definizione piu’ precisa e rigorosa dello spazio
del problema, é detto modello concettuale.
La definizione del modello concettuale con tutti i
meccanismi che il SGBD mette a disposizione è
chiamato schema di database (nela caso di
RSGBD e’ costituito da tabelle, chiavi primarie ed
esterne, ecc...).
Basi di dati
Dario Colazzo
4
Motore di database
Quando realizziamo un database, ci
fermiamo all schema del database.
L’effettiva implementazione è poi affidata
al motore di database
Si occupa della effettiva memorizzazione
dei dati, dei loro legami, di strutture per
aumentare l’efficienza del recupero dei
dati.
Importante: non include l’applicazione
Basi di dati
Dario Colazzo
5
Sistema di database
Applicazioni: maschere e report
utilizzati dalgi utenti
Motore di database: non fa
parte del database
Database: implementazione fisica
dello schema e dei dati
Schema
logico di
database
Modello
concettuale
Spazio del problema
Basi di dati
Dario Colazzo
6
Il modello relazionale (E. F.
Codd, IBM)
Si basa su un insieme di principi
matematici, introdotti per la
memorizzazione e manipolazione di dati.
Importante: il modello indica solo come i
dati devono essere concettualmente
rappresentati e quali siano le operazioni.
Come abbiamo gia visto, l’effettiva
realizzazione fisica è a carico del motore
di database.
Basi di dati
Dario Colazzo
7
Aspetti principali
Ogni sistema di database relazionale
presenta le seguenti caratteristiche:
I dati sono concettualmente rappresentati
attraverso relazioni; spesso una relazione è
chiamata tabella.
Ogni valore in corrispondenza di una
riga/colonna di una relazione è uno scalare;
in particolare una relazione non può contenere
altre relazioni.
Ogni operazione ha come input relazioni e
restituisce sempre una relazione (chiusura).
Basi di dati
Dario Colazzo
8
Terminologia relazionale: i
componenti di una relazione.
attributi
intestazione
corpo
tupla
Basi di dati
Dario Colazzo
9
Osservazioni
E’ possibile avere relazioni che non
corrispondono a nessuna realizzazione
fisica effettiva, ma sono definite
estraendo dati da altre relazioni (viste o
views).
Il principio della chiusura è molto
importante. Grazie ad esso si possono
comporre le operazioni: i risultati di una
operazione possono essere utilizzati come
input per un’altra operazione.
Basi di dati
Dario Colazzo
10
Valori scalari
Un valore è scalare se non è composto da altri valori.
Attenzione, il fatto che un valore sia scalare o meno è
soggettivo, in effetti dipende dal significato e dal ruolo che
deve assumere nello spazio del problema.
Esempio: ci possono essere realtà modellate da database
in cui il valore “Nome” di una persona può essere
rappresentato con una sola stringa (“Mario Rossi”)
In altre invece può essere necessario scomporlo in due
valori, “Nome” e “Cognome” (in questo caso avremo
“Mario” e “Rossi”).
Torneremo su questo aspetto quando parleremo di
attributi.
Basi di dati
Dario Colazzo
11
Relazioni: cardinalità,
grado,….
La cardinalità di una relazione è data dal
numero delle tuple che la compongono.
Il numero di attributi di ogni tupla determina il
grado della relazione.
Ogni relazione, contiene un insieme non ordinato
di tuple; in altre parole, due relazioni che
differiscono solo per l’ordine delle tuple, sono la
stessa relazione.
In particolare, non si possono fare interrogazioni
del tipo: “visualizza il prima tupla il cui campo
“FirstName” è diverso dal valore ‘Russel’.
Basi di dati
Dario Colazzo
12
Schema concettuale
1/2
Abbiamo visto che i database modellano
una porzione della realtà detta spazio del
problema.
Sarebbe improponibile partire dallo spazio
del problema e arrivare direttamente all
definizione dello schema di database.
Esiste un passo intermedio, la costruzione
del modello dei dati.
Attraverso lo schema concettuale,
traduciamo lo spazio del problema in
termini di entità, attributi, domini e
Basi
di dati
Dario Colazzo
13
associazioni.
Schema concettuale
2/2
La visione del mondo reale di interesse in
termini di entità, attributi, domini e
associazioni, permette di dare una prima
impostazione logica e precisa della realtà
da trattare, senza preoccuparsi della
definizione dello schema.
La corrispondenza tra modello
concettuale dei dati e schema logico è
abbastanza naturale.
Basi di dati
Dario Colazzo
14
Entità
In prima istanza, possiamo dire che
un’entità è qualunque fenomeno,
concreto o astratto, presente nello spazio
del problema di cui ci interessa
memorizzare i relativi dati.
Esempi: ‘Clienti’, ‘Impiegati’, ‘Libri’,…
(concrete)
Ma anche: ‘Acquisto’, ‘Accredito’,….
(astratte)
Basi di dati
Dario Colazzo
15
Entità
Osservazione: individuare le entità di
interesse non è sempre immediato.
Ad esempio, l’acquisto di un prodotto non
costituisce necessariamente una entità a
se.
Potrebbe rappresentare due eventi
distinti: l`acquisto da parte di un cliente e
la vendita da parte di un venditore
Basi di dati
Dario Colazzo
16
Sottotipi
Supponiamo che tra le entità rilevate abbiamo
Persona, rappresentata da tutte le informazioni
sulle generalità di una persona.
Inoltre abbiamo anche Impiegato e Dirigente
(generalità + dati specifici)
In effetti abbiamo che ogni Impiegato o
Dirigente è anche una Persona.
In questo caso si dice che sia Impiegato che
Dirigenti sono entità sottotipo di Persona.
E’ necessario tenere conto delle relazioni di
sottotipo tra entità per definire uno schema più
semplice, coerente con la realtà ed efficiente.
Basi di dati
Dario Colazzo
17
Attributi
Ogni dato di una entita che ci interessa
rappresentare nel database e un attributo
dell’entità.
Se nel database abbiamo l’entità Cliente,
sicuramente ci interesserà memorizzare il nome e
indirizzo: questi sono due attributi dell’entità
cliente.
Stabilire ciò che può essere considerato un
attributo di un’entità è un processo semantico: gli
attributi vanno determinati in base al significato
dei dati e del loro uso.
Basi di dati
Dario Colazzo
18
Determinare gli attributi
1/6
Principio generale: ridurre gli attributi a valori
non ulteriormente scomponibili.
Esempio, l’ attributo Indirizzo andrebbe
suddiviso in Via, Città, Codice, Stato.
L’idea che è alla base di questo principio è che i
dati strutturati sono più semplici da manipolare.
Ad esempio, in questo modo posso fare
interrogazioni in base al valore dell’attributo
Stato.
Se considerassi un unico attributo Indirizzo,
questo richiederebbe la scrittura di codice
appropriato per l’estrazione della componente
Stato.
Basi di dati
Dario Colazzo
19
Determinare gli attributi
2/6
2/6
Non sempre la cosa milgiore e’ seguire il criterio
generale.
Esempio di un caso: società di vendita per
corrispondenza via Internet. Per motivi fiscali,
questa società deve far riferimento allo stato nei
quali risiedono i clienti.
Si potrebbe allora pensare ad una suddivisione
Via, Città, Codice, Stato.
Cosa accade quando la società ha a che fare con
clienti il cui indirizzo non rispetta questa
suddivisione?
Basi di dati
Dario Colazzo
20
Determinare gli attributi
3/6
Si pensi ad esempio ad un indirizzo di un cliente
del tipo: 4/32 Grifen Avenue, Bondi Beach,
Australia.
Molto probabilmente vi saranno utenti del
database che non sanno che 4/32 significa
Appartamento 4, Numero civico 32.
Dal momento che l’unica esigenza dell’azienda
segnalata è conoscere lo stato, un buon
compromesso è dividere Indirizzo in
Stato+(parte restante: Via,…ecc)
Ricordare che i costi di cambiamento di schema
sono proibitivi.
Basi di dati
Dario Colazzo
21
Determinare gli attributi
4/6
Come gia detto, la scelta dipende dal significato
dei dati e dall’uso che se ne farà.
E’ importante: tenere presente il risultato finale
e non rendere il progetto più complesso del
necessario.
Se ad esempio l’unico utilizzo che si farà degli
indirizzi e quello di indirizzo di spedizione, allora
la cosa migliore è un unico attributo Indirizzo.
Ricordare: rendere il modello meno complesso
possibile, allegerisce molto le applicazioni (poche
eccezioni) e il lavoro degli utenti (che non si
trovano di fronte maschere di immissione dati
con molti campi separati da riempire).
Basi di dati
Dario Colazzo
22
Determinare gli attributi
5/6
Un altro aspetto da considerare è quello di fare
uno studio su possibili future esigenze.
Ad esempio, potrebbe essere molto probabile
che una società voglia ordinare gli indirizzi per
codice postale per poter gestire sconti sulle
tariffe postali.
In questo caso, anche se l’esigenza non è
rilevata nel momento dell’analisi dello spazio del
problema, è bene prevedere un attributo a parte
CodicePostale.
Le vere esigenze a cui il database deve rispondere non sono solo quelle che l’organizzazione vi
chiede.
Basi di dati
Dario Colazzo
23
Determinare gli attributi
6/6
Un altro aspetto importante è quello della
distinzione tra attributo o entità.
Ad esempio, nulla vieta di vedere gli indirizzi
come entita a sé, e raggruppare tutti gli indirizzi
di un sistema in una unica relazione.
Questo potrebbe essere accettabile solo quando
l’uso di tutti gli indirizzi e pressoché il
medesimo.
E’ difficile, ad esempio, che in una società gli
indirizzi dei clienti abbiano lo stesso utilizzo e
formattazione degli indirizzi degli impiegati.
Basi di dati
Dario Colazzo
24
Domini
Il dominio di un attributo specifica
l`insieme dei valori che l`attributo può
validamente contenere.
I domini non vanno confusi con i tipi di
dato, in genere messi a disposizione dai
linguaggi di programmazione (VB, Java,
C++,…)
I tipi definiscono insiemi di valori come ad
esempio l’insieme di tutte le stringe, degli
interi…ecc.
Basi di dati
Dario Colazzo
25
Tipi e domini
1/2
I tipi sono al livello della realtà fisica di un
database.
I domini invece sono al livello del modello
dei dati, e quindi ad un livello
concettuale.
Se consideriamo ad esempio il dominio di
NomeProvincia, i possibili valori del
dominio non è dato dal tipo text{20}, ma
dall`insieme {Aosta, Aquila,…Milano,…..,
Venezia}, tutte le possibile provincie.
Basi di dati
Dario Colazzo
26
Tipi e domini
2/2
Si può pensare ai domini come ad una
combinazione di un tipo di dato e regole
di convalida.
E’ bene ricordare che la convalida è un
problema riguardante l’integrità dei dati e
non il modello dei dati.
Come vedremo la validità del valore di un
attributo (dominio) può dipendere dal
valore di altri attributi.
Basi di dati
Dario Colazzo
27
Compatibiltà tra due domini
Due domini sono compatibili se ha senso
confrontare valori del primo con valori del
secondo.
Esempio: su di un db di un supermarket si
potrebbe avere NomeImpiegato=NomeCliente
per ottenere i nomi dei clienti che sono anche
impiegati nell’organizzazione.
Quindi i domini dei due attributi sono
compatibili.
Sicuramente non avrebbe senso confrontare
NomeImpiegato con DataUltimoAcquisto.
Basi di dati
Dario Colazzo
28
Perchè occuparsi dei domini
Oltre ad individuare gli attributi è
importante capire quali sono i valori che
possono assumere.
Domande come
questi due attributi sono interscambiabili?
ci sono regole che si applicano ad uno ma non
all’altro?
sono importanti ai fini della progettazione
Basi di dati
Dario Colazzo
29
Associazioni (introduzione)
1/2
Le entità rilevate nello spazio del
problema sono in genere in associazione
tra di loro.
Esempio, gli Impiegati sono in relazione
con i Reparti: ogni impiegato corrisponde
ad uno (o più) Reparti, e viceversa.
In questo caso abbiamo che esiste una
associazione tra Impiegati e Reparti.
Basi di dati
Dario Colazzo
30
Associazioni (introduzione)
2/2
Modellare le associazioni è di
fondamentale importanza.
Da come questo viene fatto dipende la
capacità del db di rispondere a
interrogazioni, di eliminare ridondanze, e
di mantenere informazioni aggiuntive tra i
legami oltre al fatto che questi esistano
nello spazio del problema.
Le associazioni sono importanti per
modellare inclusioni di sottotipo tra
entità: Impiegati è sottotipo di Persone.
Basi di dati
Dario Colazzo
31
Associazioni: terminologia
Le entità coinvolte in una associazione
sono dette partecipanti.
Nel precedente esempio, i partecipanti
sono Impiegati e Reparti.
Il grado di una associazione è dato dal
numero delle entità che vi partecipano:
Grado 1:
Grado 2:
Grado 3:
Basi di dati
associazione unaria
associazione binaria
associazione ternaria
Dario Colazzo
32
Associazioni binarie
L’associazione Impiegati-Reparti è
binaria, tra le più comuni.
Le associazioni binarie si classificano
in
Basi di dati
uno-a-uno
uno-a-molti
molti-a-uno
molti-a-molti.
Dario Colazzo
33
Direazione delle
Associazioni
In genere le associazioni vengono distinte
con un nome; nel nostro esempio
possiamo utilizzare “è situato in”
L’associazione va da Impiegati a Reparti
(verso o direzione)
L’associazione inversa, lega ogni reparto
ad un certo numero di impiegati (uno-amolti) è può essere chiamata “ospita”
Vedremo che non è necessario dare un
nome alla associazione (dipende dal
verso)
Basi di dati
Dario Colazzo
34
Associazioni totali
Una associazione e’ totale se le entità di
partenza non possono esistere senza essere
associate.
L’esistenza di un impiegato è subordinata al
collegamento di un reparto dove questo svolge
la sua attività.
Anche il viceversa è vero, in genere ogni reparto
ha degli impiegati.
In seguito vedremo che nel caso di associazioni
totali, particolare attenzione deve essere
dedicata alla modifica della base di dati.
Basi di dati
Dario Colazzo
35
Associazioni parziali
Consideriamo le due entità Impiegati e
MansioniSpeciali, con l’associazione
“svolge”
Un impiegato non svolge necessariamente
mansioni speciali, quindi può esistere pur
non essendo necessariamente associato ad
una mansione speciale.
In questo caso si dice che l’associazione è
parziale
Basi di dati
Dario Colazzo
36
Associazione ternarie
Consideriamo le associazioni binarie “i
clienti vendono prodotti” e “clienti
acquistano prodotti”
L’associazione ternaria “i venditori
vendono prodotti ai clienti” stabilisce quali
venditori vendono certi prodotti a quali
clienti.
Questa informazione non è esplicitamente
disponibile se consideriamo solo le due
associazioni binarie
Basi di dati
Dario Colazzo
37
Diagrammi E/R
(P. P. Shan Chen,
1976)
Essenzialmente, una rappresentazione
E/R schematizza informazioni riguardanti
quali entità vi sono nel modello e quali
associazioni, specificando per queste
ultime anche la loro tipologia (uno-a-uno,
uno-a-molti,...).
In particolare, nella rappresentazione non
vengono considerati i domini degli
attributi, e spesso conviene specificare a
parte questi ultimi.
Basi di dati
Dario Colazzo
38
Esempio di diagramma E/R
attributi
entità
Basi di dati
associazione
Dario Colazzo
39
Simbologia diagrammi E/R
Per le associazioni useremo la
seguente simbologia
Basi di dati
Dario Colazzo
40
Prossimo argomento
Il prossimo argomento di cui ci occuperemo
tratta della struttura delle relazioni
Una volta definito il modello dei dati, il passo
successivo è quello di definire le relazioni che
conterranno le entità
Inoltre, le relazione devono essere
opportunamente strutturate
Questo al fine di garantire che le relazioni
permettano di rispondere a tutte le
interrogazioni che possono essere poste e, allo
stesso tempo, minimizzare la ridondanza dei
dati.
Basi di dati
Dario Colazzo
41
Ridondanza
La ridondanza dei dati si ha quando
gli stessi dati vengono ripetute più
volte ina una data relazione o tra più
relazioni
I problemi sono due:
Sprego di risorse
Complica la vita
Basi di dati
Dario Colazzo
42
Relazione con ridondanza
Immaginiamo che questo recordset contenente le
fatture emesse dagli impiegati, sia presente come
relazione nel databse (non è il risultato di una query)
Basi di dati
Dario Colazzo
43
Ridondanza, problemi
I valori HireDate TelephoneExtension sono elencati
diverse volte per ciascun impiegato
Primo problema: ogni volta che immettete una nuova
fattura dovete immettere nuovamente i valori per
questi due campi, con possibilità di commettere
errori.
Secondo, non potete immettere la data di assunzione
o il numero di telefono per un nuovo impiegato fino a
quando questo non emette una fattura.
Terzo, se le fatture di un anno vengono archiviate e
tolte dal database, perdete le informazioni relative
alla data di assunzione e al numero di telefono.
Basi di dati
Dario Colazzo
44
Ridaondanza tra + relazioni
Questi problemi, normalmente chiamati
anomalie di aggiornamento, sono anche peggiori
se la ridondanza è distribuita in più relazioni
Basi di dati
Dario Colazzo
45
Ridaondanza tra + relazioni
Se il numero di telefono di “Around the
Horn” cambia, le modifiche devono essere
apportate ad entrambe le relazioni.
Nulla vieta di fare questo, ma i problemi
sono ancora la possibilità di commettere
errori, e di dimenticarsi un
aggiornamento.
Basi di dati
Dario Colazzo
46
False ridondanze
Consideriamo le due relazioni
In questo caso la rodondanza dei valori relativi ai prezzi
unitari è apparente
Nella prima tabella si tratta dei prezzi di vendita corrente
Nella seconda, dei prezzi all’atto dell’emissione della
fattura.
Basi di dati
Dario Colazzo
47
Ridondanza di attributi
1/3
Osserviamo la seguente tabella
Per rispondere all’interrogazione:”quali studenti
frequentano il corso di biologia?” è necessario
far riferimento a tutti e 5 i periodi
Basi di dati
Dario Colazzo
48
Ridondanza di attributi
2/3
L’interrogazione corrisponde alla
seguente query in SQL
SELECT StudentID
FROM Enrollments
WHERE Period1 = "Biology"
OR Period2 = "Biology" OR Period3 = "Biology
OR Period4 = "Biology" OR Period5 = "Biology
OR Period6 = "Biology";
Basi di dati
Dario Colazzo
49
Ridondanza di attributi
3/3
Con la seguente tabella la
query ha una più semplice
formulazione.
Inoltre il modello è più
flessibile: se i periodi
saranno sei basterà
cambiare un vincolo di
integrità e non aggiungere
un attributo.
La query diventa:
SELECT StudentID FROM Enrollments WHERE Class = "Biology";
Basi di dati
Dario Colazzo
50
Normalizzazione
In seguito formuleremo delle proprietà
strutturali delle relazioni che danno una
buona probabilità di assenza di anomalie
di aggiornamento
Queste proprietà sono chiamate forme
normali, ne esamineremo 4
Il processo che porta ad una struttura che
soddisfa le forme normali è detto
normalizzazione.
Basi di dati
Dario Colazzo
51
Assenza di perdite
Essenzialmente la normalizzazione si basa
sulla suddivisione di relazioni
È importante garantire l`assenza di
perdita di informazioni durante la
suddivisione.
In altre parole, la suddivisione deve
portare a relazioni che possono essere
ricombinate senza perdere informazioni.
Basi di dati
Dario Colazzo
52
Esempio di divisione
relazione non
normalizzata
Basi di dati
Dario Colazzo
53
Chiavi candidate
In precedenza, abbiamo definito una
relazione come un insieme non ordinato
di zero o più tuple
Ogni membro di un insieme è unico
Per ciascuna relazione, quindi, deve
esistere una combinazione di attributi che
identifica univocamente una tupla
Questo insieme di uno o più attributi è
detta chiave candidata
Basi di dati
Dario Colazzo
54
Proprietà delle chiavi
Ogni relazione può avere più chiavi
candidate
Ogni chiave candidata deve identificare
univocamente ciascuna tupla
Questo non vale per una specifica istanza
di una relazione, ma per tutte le possibili
tuple
Le chiavi candidate dipendono dalla
semantica del modello dei dati
Basi di dati
Dario Colazzo
55
Chiavi candidate, esempio
Consideriamo la relazione
CustomerId è univoco nell’esempio,
ma non può essere una chiave
candidata: sicuramente ci saranno
più ordini relativi allo stesso cliente
Basi di dati
Dario Colazzo
56
Classificazione delle chiavi
Per la caratterizzazione insiemistica
delle relazioni, ognuna di esse
possiede almeno una chiave
candidata: l’insieme di tutti gli
attributi.
Chiavi semplici, un solo attributo
Chiavi composte, più attributi
Basi di dati
Dario Colazzo
57
++++++++++++++++++++++++Chiavi candidate
Irriducibilità
Ogni chiave deve essere tale che se eliminiamo
uno o più attributi, gli attributi restanti non
formano una chiave.
Esempio
CategoryId è una chiave, mentre {CategoryId,
CategoryName} non lo è: può essere ridotto ad
un solo attributo.
Basi di dati
Dario Colazzo
58
Classificazione delle chiavi
Per la caratterizzazione insiemistica
delle relazioni, ognuna di esse
possiede almeno una chiave
candidata: l’insieme di tutti gli
attributi.
Chiavi semplici, un solo attributo
Chiavi composte, più attributi
Basi di dati
Dario Colazzo
59
++++++++++++++++++++++++Chiavi candidate
Irriducibilità
Ogni chiave deve essere tale che se eliminiamo
uno o più attributi, gli attributi restanti non
formano una chiave.
Esempio
CategoryId è una chiave, mentre {CategoryId,
CategoryName} non lo è: può essere ridotto ad
un solo attributo.
Basi di dati
Dario Colazzo
60
Generatore automatico di
identificatori
Quando tutte le chiavi hanno troppi attributi è
possibile delegare al motore la generazione di
valori univoci (marche) per le tuple.
L`attributo contenete questi valori sarà la
chiave.
I valori, in genere, sono generati casualmente; è
conveniente attribuirgli nessun significato
ulteriore.
Ad esempio, un errore potrebbe essere quello di
vedere ogni valore di OrderID come il numero
dell’ordine, e magari fare anche delle
computazioni in base a tale significato.
Basi di dati
Dario Colazzo
61
Chiave primaria
Nel caso di esistenza di più chiavi
candidate, una di esse viene scelta come
chiave primaria.
Le restanti sono dette chiavi alternative
Questa distinzione non riguarda il livello
logico (modello concettuale dei dati). A
tale livello interessano solo le chiavi
candidate.
Basi di dati
Dario Colazzo
62
Scelta delle chiavi candidate
La scelta delle chiavi è un processo semantico, la
scelta dipende dal significato del modello
Non sempre è immediata
In una relazione che contiene le generalità dei
dipendenti di una azienda, potrebbe essere
naturale scegliere {Nome, Cognome} come
chiave
Questa scelta è errata.
Andrebbe bene CodiceFiscale, qualora tale
attributo fosse previsto nella relazione
Basi di dati
Dario Colazzo
63
Dipendenze funzionali
Data una tupla T, con due insiemi di
attributi A={X1,…X } e B={Y1,…Y },
allora B è funzionalmente
dipendente da X se:
n
m
per qualunque valore valido di A
esiste un solo valore valido per B
Basi di dati
Dario Colazzo
64
Simbologia
A?B
“A determina funzionalmente B”
Graficamente, per A={CategoryID}
e B={CategoryName, Description}
Basi di dati
Dario Colazzo
65
Dipendenze funzionali,
interpretazione pratica
Da un punto di vista pratico, una
dipendenza funzionale esprime un
concetto importante:
esiste un insieme di attributi che è univoco
per ciascuna tupla, e conoscendolo è
possibile determinare quegli attributi che
non sono univoci
Basi di dati
Dario Colazzo
66
Dipendenze e
normalizzazione
Se A è una chiave candidata allora tutti
gli attributi B, devono necessariamente
dipendere da A.
In generale, se A?B, e A non è una chiave
ne B contiene A, allora la relazione è
necessariamente ridondante.
In un certo senso, normalizzare significa
avere relazioni dove tutte le dipendenze
funzionali partono dalle chiavi candidate.
Basi di dati
Dario Colazzo
67
Prima forma normale
Una relazione è in prima forma normale se tutti i
domini, sui quali i suoi attributi sono definiti, sono scalari
L`attributo Items non è scalare
Un caso classico è la data: se è necessario lavorare
singolarmente sui giorni, mese, anno, allora può essere
conveniente memorizzare i dati separatamente.
In genere non conviene memorizzare più informazioni in
uno stesso attributo (ref0010398, 10001100..); quando
questo accade nella relatà modellata è conveniente
scomporre i dati in fase di immissione.
Basi di dati
Dario Colazzo
68
Prima forma normale:
gruppi a ripetizione
Esaminate la relazione
C’è un gruppo di attributi che si
ripete; abbiamo già visto un caso
simile e quali sono gli inconvenienti.
Basi di dati
Dario Colazzo
69
Seconda forma normale
Una relazione è in seconda forma normale se è nella prima
forma normale e se, inoltre, tutti i suoi attributi sono
dipendenti dalla sua chiave candidata
Questa relazione non è nella seconda forma normale
Chiave: {ProductName, SupplierName}, ma PhoneNumber
dipende solo da SupplierName, questo provoca
ridondanza.
Basi di dati
Dario Colazzo
70
Seconda forma normale,
divisione
Al livello logico il problema nella
relazione precedente, è che due
entità distinte (prodotti e fornitori)
sono rappresentati da una sola
relazione
La seguente divisione risolve il
problema (scomposizione senza
perdita)
Basi di dati
Dario Colazzo
71
Esempio di scomposizione
Attenzione: per non avere perdita di
informazioni, è necessario introurre un
campo SupplierId nella relazione Products
Basi di dati
Dario Colazzo
72
Seconda forma normale,
vantaggi
Vantaggio: possiamo reperire
informazioni sui fornitori prima di
ottenere informazioni sui prodotti
Nella forma precedente ciò non era
possibile: era necessario avere un valore
per il campo ProductName
Il valore di un campo chiave non può
essere vuoto.
Basi di dati
Dario Colazzo
73
Seconda forma normale,
svantaggio
Questa relazione
è in sfn, ma si
basa sul
presupposto che
ogni fornitore
abbia un solo
indirizzo
Questo potrebbe
non verificarsi in
futuro
Basi di dati
Dario Colazzo
74
Terza forma normale
Una relazione è in terza forma normale se
è in sfn, e se inoltre tutti gli attributi che
non sono chiave sono mutuamente
indipendenti.
Nella relazione del successivo slide, vi è
una dipendenza tra Region e Salesperson
Entrambi non possono essere chiavi
candidate
Basi di dati
Dario Colazzo
75
Relazione non in tfn
Basi di dati
Dario Colazzo
76
Esempio scomposizione per
tfn
Questa relazione non è strettamente in tfn
In effetti, PostalCode è basato sui valori City e
Region;
Basi di dati
Dario Colazzo
77
Tfn, possibile divisione
In fase di immissione dati, il
codice postale può essere
ricavato automaticamente,
risparmiando digitazioni e
possibilità di errori
Basi di dati
Dario Colazzo
78
Relazione non in tfn
Basi di dati
Dario Colazzo
79
Esempio scomposizione per
tfn
Questa relazione non è strettamente in tfn
In effetti, PostalCode è basato sui valori City e
Region;
Basi di dati
Dario Colazzo
80
Tfn, possibile divisione
In fase di immissione dati, il
codice postale può essere
ricavato automaticamente,
risparmiando digitazioni e
possibilità di errori
Basi di dati
Dario Colazzo
81
Boyce-Codd
La forma normale di Boyce/Codd, è
cosiderata una variante della tfn
Presupposti:
Due o più chiavi candidate
Almeno due devono essere composte
Le chiavi candidate devono avere attributi
sovrapponibili
Essenzialmente, la fn di Boyce/Codd
afferma che non devono esistere
dipendenze funzionali tra le chiavi
candidate.
Basi di dati
Dario Colazzo
82
Boyce-Codd, esempio
1/2
Consideriamo la seguente relazione
Le due chiavi candidate in questo
caso sono {SupplierId, ProductId} e
{SupplierName, ProductId}
Basi di dati
Dario Colazzo
83
Boyce-Codd, esempio
2/2
Diagramma delle dipendenze:
Abbiamo
{SupplierID}{SupplierName},
quindi la relazione non è in
forma normale di BC
Da un punto di vista logico,
l`anomalia è rappresentata
dal fatto che le informazioni
sui fornitori non dovrebbero
essere presenti nella relazione
Basi di dati
Dario Colazzo
84
Boyce-Codd,
normalizzazione esempio
Le due tabelle
danno una
versione
completamente
normalizzata del
precedente
esempio
Basi di dati
Dario Colazzo
85
Quarta forma normale
Consideriamo la relazione
Non è in prima forma normale,
l’attributo Packsize non è scalare
Basi di dati
Dario Colazzo
86
Esempio precedente in pfn
Prima forma normale
Esistono ridondanze, il mantenimento
dell’integrità dei dati potrebbe essere
difficoltoso.
È in forma normale di Boyce-Codd?
Basi di dati
Dario Colazzo
87
Qfn, dipendenze multivalore
La ridondanza presente nella relazione
precedente è dovuta ad una particolare
dipendenza: dipendenza multivalore.
Una dipendenza multivalore è costituita
da due insiemi di attributi A e B
mutuamente indipendenti.
A multidetermina B, se per ogni valore
valido di A esistono uno o più valori validi
di B.
Notazione: A?>B
Basi di dati
Dario Colazzo
88
Qfn, normalizzazione
Nell`esempio in questione la dipendenza
è
{ProductName}?>{PackSize}|{SupplierName}
Si legge: Product multidetermina
PackSize e SupplierName
Informalmente, la qfn richiede che le
dipendenze multivalore devono essere
divise in più tabelle
Basi di dati
Dario Colazzo
89
Esempio in qfn
È importante osservare che la qfn entra in gioco
solo se gli attributi possiedono più valori
Nel caso esaminato, se ogni prodotto possedesse
solo una singola confezione o un singolo
fornitore, non si applicherebbe la qfn.
Basi di dati
Dario Colazzo
90
Associazioni
Associazioni
Dopo le relazioni, le associazioni
costituiscono un’altra parte
fondamentale del modello dei dati
Come per le relazioni, per
determinare le associazioni è
fondamentale comprendere la
semantica dello spazio del problema.
Basi di dati
Dario Colazzo
92
Associazioni, terminologia
(richiamo)
Prtecipanti: entità tra le quali esiste
una associazione
Grado: unarie, binarie, ternarie,…
Totali: le entità non possono esistere
a meno di partecipare
all`associazione
Parziali: altrimenti
Basi di dati
Dario Colazzo
93
Entità deboli e normali
Una entità debole può esistere solo in
associazione con altre entità
Una entità normale può esistere anche
senza essere associato ad altre.
Esempio e simbologia
Clienti
Basi di dati
Ordini
Dario Colazzo
94
“is a” e “has a”
Talvolta è utile classificare le
associazioni in is a e has a
Un Impiegato è un (is a) membro di
una SquadraDiCalcio
Un Impiegato ha un (has a) ordine
di vendita
Basi di dati
Dario Colazzo
95
Cradinalità
La cardinalità di una associazione è
il numero massimo di entità che
possono essere associate ad una
entità
Tre tipi: uno-a-uno, uno-a-molti,
molti-a-molti
Basi di dati
Dario Colazzo
96
Cardinalità, simbologia nei
diagrammi E/R
Le associazioni sono rappresentate come linee tra rettangoli
Le entità sono indicate all`interno dei rettangoli
Basi di dati
Dario Colazzo
97
Modellare le associazioni
Nella rappresentazione E/R si indicano le
entità e le associazioni tra queste
individuate
Il passo successivo è quello di modellare
le associazioni
Questo viene fatto rappresentando le
entità coinvolte nelle asociazioni,
elencando anche gli attributi di queste
Basi di dati
Dario Colazzo
98
Modellare le associazioni,
un esempio
Le associazioni non vengono
etichettate, in genere le etichette
dipendono dalla direzione in cui si
legge l’associazione
Basi di dati
Dario Colazzo
99
Implementazione nel
modello relazionale
Come vedremo, le associazioni vengono
effettivamente modellate attraverso
particolari attributi delle entità coinvolte.
Dal momento che le chiavi candidate
individuano univocamente le istanze di
entità, il collegamento viene fatto
attraverso le chiavi candidate
Il fatto di rappresentare le associazioni
mostrando gli attributi è utile per
evidenziare quali delle chiavi candidate
sono utilizzate dall’associazione.
Basi di dati
Dario Colazzo
100
Chiavi interne ed esterne
chiave esterna,
(nota: copia della
chiave di Orders)
chiave interna
relazione primaria
relazione esterna
Nella coppia chiave candidata/chiave esterna che modella
l`associazione non vi deve essere necessariamente la chiave
primaria della relazione primaria; dovrebbe essere usata la
chiave candidata più significativa dal punto di vista
semantico
Basi di dati
Dario Colazzo
101
Determinare la relazione
primaria
Se l’associazione è uno-a-molti, la
relazione primaria è quella sul lato
uno (la sua chiave candidata è
aggiunta alla relazione esterna)
Nel caso esistano dubbi (es. uno-a
uno) la scelta dipende dalla
semantica dei dati e dall’uso
dell’associazione
Basi di dati
Dario Colazzo
102
Proprietà dell’associazione
È possibile modellare attributi di una
associazione, esempio:
relazione
astratta
Una alternativa potrebbe essere quella di
includere gli attributi in una delle relazioni
partecipanti (non molto pulita e pesante
con molti attributi)
Basi di dati
Dario Colazzo
103
Transizione di stato
Ad esempio, se ci interessa sapere
che
John e Mary Smith nel 1953 erano
sposati e hanno divorziato nel 1972,
e che Mary si è risposata nel 1975
è vanataggioso introdurre una
relazione astratta tra entità per
mantenere traccia delle transizioni
Basi di dati
Dario Colazzo
104
Associazioni uno-a-uno
Ogni istanza dell`entità X può essere associata
con una sola istanza dell’entità Y
Associazione uno-a-uno tra Office e Employee
Osservazione: il modello potrebbe non essere
adatto nel caso in cui gli impiegati cambiano
reparto:
Se state modellando un sistema per recapitare la posta,
volete sapere quale sia il suo ufficio attuale, e non
quello di tre mesi fa
Potrebbe interessare una statistica sulla frequenza di
cambiamento dei reparti da parte degli impiegati
Basi di dati
Dario Colazzo
105
Associazioni uno-a-uno per
modellare attributi specifici
Supponiamo di avere delle entità Orders, potremo avere il
seguente modello per catturare gli attributi specifici di ogni
categoria di prodotto
Problema del modello: se vogliamo ricercare il codice di un
prodotto, dobbiamo verificare se esiste nella relazione x, o
nella relazione y,…. (le categorie possono essere molte)
Inoltre, cosa accade se la categoria di un prodotto cambia?
Basi di dati
Dario Colazzo
106
Sottoclassi
Per ovviare ai problemi prima evidenziati, risulta
conveniente adottare il seguente modello
Si possono trattare le informazioni specifiche per
le diverse categorie senza perdere la capacità di
trattare i prodotti come tipo generico.
Basi di dati
Dario Colazzo
107
Soluzione alternativa
Se tutto ciò che interessa riguardo ai prodotti è
quello di produrre report con raggruppamento
per categoria, è sufficiente il seguente modello:
Products cattura gli attributi per tutti i prodotti,
gli attributi relativi alle bevande sono
intrinsicamente diversi da quelli per condimenti.
Basi di dati
Dario Colazzo
108
Associazioni uno-a-uno, relazione
primaria e secondaria
Nel caso di sottoclassi, l’entità generica diventa
la relazazione primaria, e ciascuna sottoclasse
diventa la una relazione esterna
Importante: quasi sempre, la chiave che le
sottoclassi acquisiscono è anche la loro chiave
candidata. Raramente hanno una chiave propria.
Negli altri casi la scelta è arbitraria; se esiste un
lato facoltativo (raramente entrambi i lati lo
sono), allora questa può essere la relazione
esterna (entità debole).
Basi di dati
Dario Colazzo
109
uno-a-molti
È la più comune, inoltre la maggioranza delle
tecniche di normalizzazione viste si risolvono
cone questo tipo di associazione
In genere, si ritiene che solo il lato molti possa
essere facolativo; non vero, esempio:
L’AgenteServizioClienti può avere zero o più
clienti, un AgenteServizioClienti di un cliente, se
ne è stato assegnato uno, deve essere presente
nella relazione AgenteServizioClienti.
Basi di dati
Dario Colazzo
110
uno-a-molti, relazione
primaria e secondaria
L’entità sul lato uno è sempre la relazione
primaria
La chiave candidata della relazione sul
lato uno viene copiata nulla relazione sul
lato molti, che diventa la relazione
esterna
La chiave candidata della relazione
primaria spesso costituisce parte della
chiave candidata della relazione sul lato
molti
Basi di dati
Dario Colazzo
111
molti-a-molti
Esempio:
gli studenti frequentano molti
corsi, i corsi sono frequentati
da molti studenti
Non possono essere implementate
direttamente in un database
relazionale
Basi di dati
Dario Colazzo
112
molti-a-molti,
implementazione
Si untroduce una relazione
intermediaria che possiede una
associazione uno-a-molti con
ognuno dei partecipanti
La relazione intermediaria è
normalmente chiamata tabella
unione, anche al livello del modello
dei dati quando si parla di relazioni
(entità) e non di tabelle.
Basi di dati
Dario Colazzo
113
molti-a-molti, esempio
L’associazione molti-a-molti
...diventa
tabella unione
relazioni primarie
Quali attributi contiene la tabella unione?
Basi di dati
Dario Colazzo
114
Associazioni unarie
Una relazione è associata con se stessa
Sono modellate come le relazioni binarie,
con la differenza che relazione primaria e
esterna coincidono.
Possono avere qualunque cardinalità,
quelle molti-a-molti richiedono
ugualmente una tabella unione.
Basi di dati
Dario Colazzo
115
Associazioni unaria uno a
molti
Sono utilizzate per modellare le gerarchie
gerarchia
Impiegati-Manager
oss: parziale sul
lato uno, i direttori
generali non
hanno un dirigente
Basi di dati
Dario Colazzo
116
SQL :Structured
Query Language
Relazioni di base e derivate
Le relazioni definite nello schema di
database sono dette relazioni di base,
sono effettivamente memorizzate (e
ottimizzate)
Una relazione derivata è definita in
termini di altre relazioni attraverso
interrogazioni al motore di database,
espresse in uno specifico linguaggio
Nelle basi di dati relazionali, il linguaggio
è SQL
Basi di dati
Dario Colazzo
118
Sintassi query SQL
SELECT <lista campi>
FROM <lista recordset>
<tipo di join> JOIN <condizione di
join>
WHERE <condizioni di selezione tuple>
GROUP BY <lista di attributi di
raggruppamento>
HAVING <criterio di selezione>
Basi di dati BY <lista di
Dario
Colazzo
119
ORDER
attributi
su cui ordinare>
SELECT-FROM
L’unica parte obbligatoria è
SELECT <lista campi>
FROM <lista recordset>
In altre parole, è obbligatorio indicare
almeno le tabelle da cui si intende
estrarre dati (FROM) e quali campi di
queste selezionare (SELECT)
Basi di dati
Dario Colazzo
120
Operatori relazionali
Sono restrizione, proiezione, join,
(divisione)
Più alcuni operatori insiemistici: unione,
intersezione, differenza, prodotto
cartesiano
Queste sono le operazioni definite per
manipolare le relazioni
Sono tutte implementate attraverso una
appropriata SELECT di SQL
Basi di dati
Dario Colazzo
121
Valori Null e logica a tre
valori
Nell’implementare gli operatori
relazionali con SQL vedremo che
sarà necessario confrontare valori
memorizzate nelle tabelle.
È possibile che alcuni di questi siano
del valore speciale Null, che molti
motori mettono a disposizione
Basi di dati
Dario Colazzo
122
Informazioni sconosciute o
inesistenti
Il valore Null è stato introdotto per modellare la
possibilità di avere informazioni “mancanti” o
“assenti”.
Non risolve il problema: quando un valore di un
campo non è inserito (è di valore Null) non
sappiamo se il dato era inesistente o mancante.
Questo problema può essere risolto per alcuni
domini basati su tipi come stringhe o testo:
posso modellare l’inesistenza con valori di
lunghezza zero, e con Null il fatto che non si
conosce il valore.
Attenzione: non conviene introdurre valori
convenzionali.
Basi di dati
Dario Colazzo
123
Confronti con valori Null
Cosa accade se ad esempio voglio testare
l’uguaglianza di due dati (es: ora/data) di
cui uno è Null?
Per i valori booleani abbiamo le seguenti
tabelle:
In genere Null op Valore restituisce Null
Basi di dati
Dario Colazzo
124
Logica a tre valori
Possiamo avere condizioni dove alcune
sottoespressioni possono assumere Null,
come regolarci?
Logica a tre valori:
Basi di dati
Dario Colazzo
125
Restrizione
Restrizione: restringere un insieme di record ai
soli record che soddisfano una condizione
(WHERE)
SELECT *
FROM Employees
WHERE LastName = "Davolio"
La clausola WHERE può contenere espessioni
logiche complesse costruite con altri operatori di
confronto (<, >, ...) e connettivi (AND, OR,...)
Basi di dati
Dario Colazzo
126
Proiezione
La proiezione seleziona una porzione
verticale di un recordset, esempio
SELECT LastName, FirstName, Extens
ion FROM Employees
ORDER BY LastName, FirstName;
ORDER BY specifica il criterio di
ordinamento del recordset che la
query restituisce
Basi di dati
Dario Colazzo
127
Join
L’operazione di join è fondamentale: permette di
ricombinare più relazioni in una sola.
Senza tale operatore non sarebbe possibile
scomporre le relazioni per poi ricomporle
Il join ricombina le relazioni in base al confronto
di uno più campi comuni
In base al tipo di confronto e al modo in cui sono
trattati i risultati di confronto, si distinguono tre
tipi di join, implementati per mezzo di una
combinazione di SELECT e JOIN.
Basi di dati
Dario Colazzo
128
Equi-join
Si ha quando il join è effettuato in base ad un
confronto di uguaglianza
Se consideriamo la
seguente porzione di
schema, possiamo
ricombinare le relazioni
in accordo
all’associazione uno-amolti
Basi di dati
Dario Colazzo
129
INNER JOIN
Esempio
SELECT Orders.OrderID, Orders.CustomerID, [Order Details].ProductI
D FROM Orders
INNER JOIN [Order Details]
ON Orders.OrderID = [Order Details].OrderID
WHERE (Orders.OrderID)=10248;
Può essere vista come una
operazioni di denormalizzazione
Basi di dati
Dario Colazzo
130
Theta-Join
È una Join (INNER) basata su un
operatore di confronto diverso
dall’uguaglianza: <>, >, >=, <, <=.
Non sono applicate frequentemente,
ma possono essere utilizzate per
interrogazioni che individuano
record con un valore maggiore di
una media o di un totale, oppure
compresi in un intervallo.
Basi di dati
Dario Colazzo
131
Theta-Join, esempio
Consideriamo le tabelle
possono essere riunite per
visualizzare i prodotti che
hanno venduto di più
all’interno di una categoria
Basi di dati
Dario Colazzo
132
Theta-Join, query
SELECT DISTINCTROW
ProductCategoryAverages.CategoryName,
ProductTotals.ProductName
FROM ProductCategoryAverages
INNER JOIN ProductTotals
ON ProductCategoryAverages.CategoryID =
ProductTotals.CategoryID
AND ProductTotals.TotalSold >
ProductCategoryAverages.AverageSold;
Basi di dati
Dario Colazzo
133
..risultato theta-join
Basi di dati
Dario Colazzo
134
Riscrittura di query
La precedente query
SELECT DISTINCTROW
è equivalente a
ProductCategoryAverages.CategoryName,
ProductTotals.ProductName
FROM ProductCategoryAverages
INNER JOIN ProductTotals
ON ProductCategoryAverages.CategoryID =
ProductTotals.CategoryID
WHERE ProductTotals.TotalSold >
ProductCategoryAverages.AverageSold;
Basi di dati
Dario Colazzo
135
SQL :Structured
Query Language
Relazioni di base e derivate
Le relazioni definite nello schema di
database sono dette relazioni di base,
sono effettivamente memorizzate (e
ottimizzate)
Una relazione derivata è definita in
termini di altre relazioni attraverso
interrogazioni al motore di database,
espresse in uno specifico linguaggio
Nelle basi di dati relazionali, il linguaggio
è SQL
Basi di dati
Dario Colazzo
137
Sintassi query SQL
SELECT <lista campi>
FROM <lista recordset>
<tipo di join> JOIN <condizione di
join>
WHERE <condizioni di selezione tuple>
GROUP BY <lista di attributi di
raggruppamento>
HAVING <criterio di selezione>
Basi di dati BY <lista di
Dario
Colazzo
138
ORDER
attributi
su cui ordinare>
SELECT-FROM
L’unica parte obbligatoria è
SELECT <lista campi>
FROM <lista recordset>
In altre parole, è obbligatorio indicare
almeno le tabelle da cui si intende
estrarre dati (FROM) e quali campi di
queste selezionare (SELECT)
Basi di dati
Dario Colazzo
139
Operatori relazionali
Sono restrizione, proiezione, join,
(divisione)
Più alcuni operatori insiemistici: unione,
intersezione, differenza, prodotto
cartesiano
Queste sono le operazioni definite per
manipolare le relazioni
Sono tutte implementate attraverso una
appropriata SELECT di SQL
Basi di dati
Dario Colazzo
140
Valori Null e logica a tre
valori
Nell’implementare gli operatori
relazionali con SQL vedremo che
sarà necessario confrontare valori
memorizzate nelle tabelle.
È possibile che alcuni di questi siano
del valore speciale Null, che molti
motori mettono a disposizione
Basi di dati
Dario Colazzo
141
Informazioni sconosciute o
inesistenti
Il valore Null è stato introdotto per modellare la
possibilità di avere informazioni “mancanti” o
“assenti”.
Non risolve il problema: quando un valore di un
campo non è inserito (è di valore Null) non
sappiamo se il dato era inesistente o mancante.
Questo problema può essere risolto per alcuni
domini basati su tipi come stringhe o testo:
posso modellare l’inesistenza con valori di
lunghezza zero, e con Null il fatto che non si
conosce il valore.
Attenzione: non conviene introdurre valori
convenzionali.
Basi di dati
Dario Colazzo
142
Confronti con valori Null
Cosa accade se ad esempio voglio testare
l’uguaglianza di due dati (es: ora/data) di
cui uno è Null?
Per i valori booleani abbiamo le seguenti
tabelle:
In genere Null op Valore restituisce Null
Basi di dati
Dario Colazzo
143
Logica a tre valori
Possiamo avere condizioni dove alcune
sottoespressioni possono assumere Null,
come regolarci?
Logica a tre valori:
Basi di dati
Dario Colazzo
144
Restrizione
Restrizione: restringere un insieme di record ai
soli record che soddisfano una condizione
(WHERE)
SELECT *
FROM Employees
WHERE LastName = "Davolio"
La clausola WHERE può contenere espessioni
logiche complesse costruite con altri operatori di
confronto (<, >, ...) e connettivi (AND, OR,...)
Basi di dati
Dario Colazzo
145
Proiezione
La proiezione seleziona una porzione
verticale di un recordset, esempio
SELECT LastName, FirstName, Extens
ion FROM Employees
ORDER BY LastName, FirstName;
ORDER BY specifica il criterio di
ordinamento del recordset che la
query restituisce
Basi di dati
Dario Colazzo
146
Join
L’operazione di join è fondamentale: permette di
ricombinare più relazioni in una sola.
Senza tale operatore non sarebbe possibile
scomporre le relazioni per poi ricomporle
Il join ricombina le relazioni in base al confronto
di uno più campi comuni
In base al tipo di confronto e al modo in cui sono
trattati i risultati di confronto, si distinguono tre
tipi di join, implementati per mezzo di una
combinazione di SELECT e JOIN.
Basi di dati
Dario Colazzo
147
Equi-join
Si ha quando il join è effettuato in base ad un
confronto di uguaglianza
Se consideriamo la
seguente porzione di
schema, possiamo
ricombinare le relazioni
in accordo
all’associazione uno-amolti
Basi di dati
Dario Colazzo
148
INNER JOIN
Esempio
SELECT Orders.OrderID, Orders.CustomerID, [Order Details].ProductI
D FROM Orders
INNER JOIN [Order Details]
ON Orders.OrderID = [Order Details].OrderID
WHERE (Orders.OrderID)=10248;
Può essere vista come una
operazioni di denormalizzazione
Basi di dati
Dario Colazzo
149
Theta-Join
È una Join (INNER) basata su un
operatore di confronto diverso
dall’uguaglianza: <>, >, >=, <, <=.
Non sono applicate frequentemente,
ma possono essere utilizzate per
interrogazioni che individuano
record con un valore maggiore di
una media o di un totale, oppure
compresi in un intervallo.
Basi di dati
Dario Colazzo
150
Theta-Join, esempio
Consideriamo le tabelle
possono essere riunite per
visualizzare i prodotti che
hanno venduto di più
all’interno di una categoria
Basi di dati
Dario Colazzo
151
Theta-Join, query
SELECT DISTINCTROW
ProductCategoryAverages.CategoryName,
ProductTotals.ProductName
FROM ProductCategoryAverages
INNER JOIN ProductTotals
ON ProductCategoryAverages.CategoryID =
ProductTotals.CategoryID
AND ProductTotals.TotalSold >
ProductCategoryAverages.AverageSold;
Basi di dati
Dario Colazzo
152
..risultato theta-join
Basi di dati
Dario Colazzo
153
Riscrittura di query
La precedente query
SELECT DISTINCTROW
è equivalente a
ProductCategoryAverages.CategoryName,
ProductTotals.ProductName
FROM ProductCategoryAverages
INNER JOIN ProductTotals
ON ProductCategoryAverages.CategoryID =
ProductTotals.CategoryID
WHERE ProductTotals.TotalSold >
ProductCategoryAverages.AverageSold;
Basi di dati
Dario Colazzo
154
Join-esterna
Restituisce tutti i record che
soddisfano le condizioni di join (join
interna) + i record di uno o entrambi
i recordset
I valori non corrispondenti saranno
Null
Tre tipi: join esterna sinistra, join
esterna destra, join esterna piena
Basi di dati
Dario Colazzo
155
Esempi join esterne d/s
SELECT *
FROM X LEFT OUTER JOIN Y
ON <condition>
SELECT *
FROM Y RIGHT OUTER JOIN X
ON <condition>
Entrambe restituiscono i record di X e tutti i
record di Y per cui <condition> è valutata a
True.
Basi di dati
Dario Colazzo
156
Join esterna completa
SELECT *
FROM X FULL OUTER JOIN Y
ON <condition>
Restituisce i record provenienti da
entrambi i recordset, combinando quelli
per i quali la condizione è True.
Basi di dati
Dario Colazzo
157
Unione
L’unione relazionale è la
concatenazione di due recordset
Esempio:
SELECT CompanyName AS Name, Address, City, PostalCod
e
FROM Customers
UNION SELECT [FirstName] & " " & [LastName] AS Name,
Address, City, PostalCode
FROM Employees
ORDER BY Name;
Basi di dati
Dario Colazzo
158
risultato unione
Basi di dati
Dario Colazzo
159
Intersezione
Restituisce i record comuni a due
recordset; è implementata
attraverso join esterne
Supponiamo di avere due elenchi di
clienti e di volere i clienti che
occorrono in entrambi
Basi di dati
Dario Colazzo
160
Intersezione, esempio
Basi di dati
Dario Colazzo
161
Intersezione, query
SELECT DuplicateCustomers1.*
FROM DuplicateCustomers1
LEFT JOIN DuplicateCustomers2 ON
(DuplicateCustomers1.CustomerID =
DuplicateCustomers2.CustomerID)
AND
(DuplicateCustomers1.CompanyName =
DuplicateCustomers2.CompanyName)
WHERE
DuplicateCustomers2.CustomerID IS NOT NULL;
Basi di dati
Dario Colazzo
162
....risultato
Basi di dati
Dario Colazzo
163
Differenza
Restituisce i record che
appartengono ad un recordset ma
non all’altro
Può essere ottenuta con due
passaggi
Basi di dati
Dario Colazzo
164
Primo passo
Basi di dati
Dario Colazzo
165
Secondo passo
Basi di dati
Dario Colazzo
166
Prodotto cartesiano
Il prodotto cartesiano combina ogni
record di un recordset con i record
di un secondo recordset
SELECT CustomerName, CSRName
FROM Customer, CSRs;
Sono utilizzati allo scopo di analisi o come
risultati intermedi
Basi di dati
Dario Colazzo
167
Riepilogo, esempio di query
Basi di dati
Dario Colazzo
168
..risultato
Basi di dati
Dario Colazzo
169
Estensione
Permette di introdurre campi virtuali
che sono calcolati
Offre la possibilità di non introdurre
campi calcolati nelle tabelle, esempio
SELECT [UnitPrice]*[Qty] AS ExtendedPri
ce FROM [Order Details];
Basi di dati
Dario Colazzo
170
Rinomina
Già introdotta
Utile per definire auto-join
SELECT Manager.Name, Employee.Name
FROM Employees AS Employee
INNER JOIN Employees AS Manager
ON Employee.EmployeeID = Manager.Employe
eID;
Basi di dati
Dario Colazzo
171
