Introduzione alle Basi di Dati

1. Introduzione alle
Basi Dati Relazionali
DATA SCIENCE AND COMPLEXITY
walter.quattrociocchi@uniroma1.it

2. Contenuti della lezione
● Perché studiamo le basi di dati relazionali
● Un primo sguardo a SQL
● La relazione (tabella) come elemento centrale del modello
● Database schema
● I tipi: vincolare i dati
● Progettare basi di dati: il diagramma entità/relazione
○ Entità e attributi
○ Relazioni
○ Molteplicità

3. Il ruolo delle basi di dati
Lo studio delle basi di dati viene tradizionalmente associato a temi noiosi
come la gestione di informazioni su impiegati, conti bancari e così via, ma
oggi i dati stanno assumendo un ruolo sempre più importante nelle
organizzazioni:
● Data Mining e Big Data analysis
● Ricerche su web
● Deep Learning e Intelligenza Artificiale
● Studio e gestione dei Social Network
● ERP e CRM

4. La necessità di un formalismo
Perché i dati possano essere gestiti è fondamentale che siano archiviati e
gestiti con metodi che rispondono ad una formalizzazione valida in base alle
operazioni che si vogliono svolgere.
Se volete trovare il mio indirizzo di mail è più utile fare una ricerca su Google
o accedere ad un file che contenga l'elenco di tutti i docenti di Ca' Foscari ? E
per mandare una mail a tutti i docenti ? E ai soli docenti che tengono corsi
triennali ?
In questo corso impareremo due formalismi chiave:
● Il modello Relazionale per la rappresentazione dei dati
● L'Algebra Relazionale (e SQL) per l'interrogazione dei dati

5. Una piccola anticipazione...
Modello relazionale e SQL sono progettati per essere facili da comprendere !
a b
5 20
10 30
20 40
R
SELECT b FROM R WHERE a<10 OR a>=10;
SELECT b FROM R;
SELECT a FROM R, S WHERE R.b = S.b;
SELECT a FROM R WHERE b IN (SELECT b FROM S);
Senza neppure aver completato il corso, siete già in grado di intuire cosa accada con
queste query SQL sulla tabella R ?

6. Cos'è un formalismo per una Base di Dati ?
Sono tre gli ingredienti necessari per definire un modello formale per
rappresentare e gestire una Base di Dati:
● Una rappresentazione matematica dei dati
○ Modello relazionale -> tabelle
○ XML -> alberi gerarchici
○ Servizi web -> Oggetto JSON
● Una serie di operatori che agiscono sui dati
○ Tramite la definizione di un'algebra
● Una serie di vincoli fra i dati stessi
○ Che garantiscono l'integrità dei dati

7. Il modello relazionale: tabelle
Il modello relazionale usa la tabella (relazione) per rappresentare i dati
Perchè ?
● Siamo abituati a ragionare per tabelle
● E' facile "vedere" i dati a colpo d'occhio
● I computer sono bravi a gestire dati ordinati
● E' facile definire operazioni su tabelle
● E' facile trasmettere dati regolari in rete
● E' facile eseguire ricerche
● Si possono creare indici

8. Anatomia di una tabella
Etichetta Produttore
Moretti Heineken
Dreher Heineken
Nastro Azzurro Asahi
Birre
Attributi (colonne, campi)
Tuple (righe, entries,
ennuple)
Nome tabella (relazione)

9. Un formalismo (compatto) per le tabelle
Non ha senso rappresentare sempre le tabelle graficamente, specialmente
se si ragiona su una base di dati.
Si usa un formalismo compatto, detto "Schema di relazione" o "Relation
Schema":
Nome Tabella ( Nome Attributo 1, Nome Attributo 2, …. )
esempio:
Birre ( Etichetta, Produttore )
Uno schema di database (Database Schema) è un insieme di "Relation
Schema"

10. Vincoli: i tipi
Uno schema di relazione specifica nome tabella e attributi, ma le righe
possono contenere qualsiasi cosa ?
● E' desiderabile modellare dati che possono avere qualsiasi valore ?
● Come facciamo a garantire che tutto funzioni ?
Per risolvere questi problemi vengono definiti degli insiemi di valori possibili
(tipi):
int, float, text, date, position... (e molti altri, dipendono dal DB software)
E' possibile specificare i tipi nello schema:
Birre ( Etichetta: text, Produttore: text )

11. Vincoli: chiavi primarie
Quando nel mondo reale voglio indicare qualcosa senza ambiguità cosa faccio
?
● Per identificare uno studente, un cittadino ?
● Una parte di ricambio, un prodotto ?
Definisco un attributo che è univoco in tutto l'insieme degli elementi e
garantisco che tale proprietà sia mantenuta (ad esempio con un'anagrafe).
La chiave primaria è un attributo (o insieme di attributi) che vincolo ad essere
univoco:
Birre ( Etichetta: text, Produttore: text )

12. Un esempio completo di database schema
Birre ( Etichetta: text, Produttore: text )
Bar ( Insegna: text, Indirizzo: text, Alcolici: boolean )
Clienti ( Nome: text, Telefono: phone )
Beve ( NomeCliente: text, EtichettaBirra: text )
Frequenta ( NomeCliente: text, InsegnaBar: text )
Vende ( InsegnaBar: text, EtichettaBirra: text, Prezzo: float )
Chiavi esterne !

13. Alcune tabelle (parziali) al lavoro
Etichetta Produttore
Moretti Heineken
Dreher Heineken
Nastro Azzurro Asahi
Birre
Insegna Indirizzo Alcolici
Moe via Verdi, 1 False
Roxy via Roma, 3 True
Rick's corso Italia, 5 True
Bar
InsegnaBar EtichettaBirra Prezzo
Moe Moretti 2
Moe Dreher 2.5
Roxy Moretti 2.5
Vend
e

14. Chiavi esterne
Chiave esterna (foreign key): campo/i una tabella R che è chiave primaria di
un’altra tabella S (permette di stabilire relazioni fra tabelle).
● Per ogni tupla r di R esiste una tupla s di S tale che il valore della foreign
key di r coincide con la chiave primaria di s (integrità referenziale)
Quali sono le chiavi esterne nella tabella Vende ?
InsegnaBar EtichettaBirra Prezzo
Moe Moretti 2
Moe Dreher 2.5
Roxy Moretti 2.5
Vend
e

15. Schema e istanze di una base di dati
● Lo schema, sostanzialmente invariante nel tempo, ne descrive la
struttura (aspetto intensionale);
● L’istanza, costituita dai valori attuali, che possono cambiare molto e
molto rapidamente (aspetto estensionale); nell’esempio, il “corpo” di
ciascuna tabella.
● Ogni tabella contiene un certo numero di record ennuple, che definisce
la sua cardinalità

16. Tabelle e relazioni
Una tabella rappresenta una relazione se
● i valori di ciascuna colonna sono fra loro omogenei (dello stesso
dominio)
● le righe sono diverse fra loro
● le intestazioni delle colonne sono diverse tra loro
Inoltre, in una tabella che rappresenta una relazione
● l’ordinamento tra le righe è irrilevante
● l’ordinamento tra le colonne è irrilevante

17. Il ruolo del diagramma E/R (entità/relazione)
Ma come fare per scegliere quali tabelle creare e come relazionarle ?
Il diagramma E/R è un valido strumento che permette di:
● Progettare visualmente la base dati
● Utilizzare una sintassi grafica standard
● Convertire facilmente il progetto in tabelle
● Verificare la funzionalità del progetto
● Ragionare sui dati con gli "stakeholder"
● Dialogare con gli informatici
● Utilizzare software generici

18. Elementi di un diagramma E/R
Un diagramma E/R si compone di due soli elementi:
● Entity Set: corrispondono a fatti concreti, ovvero a entità, fisiche o
astratte che esistono di per sè (uno studente, una materia, un bar, una
birra, un esame, un dipartimento)
● Relationship: corrispondono a rapporti che intercorrono fra entity set,
ma che non hanno motivo di esistere in assenza degli entity set che
collegano (aver sostenuto un esame, vendere una birra, avere una
materia in piano di studi)
Le relationship si indicano spesso con il termine "relazione", ma non vanno
confuse col concetto di tabella ! In inglese i termini sono appunto diversi fra
loro (relation vs relationship) !

19. Entity Set
● Ogni entity set viene rappresentato con un rettangolo contenente il suo
nome
● Ogni informazione relativa all'entity set (attributo) viene rappresentata
con un ovale collegato ad esso con una linea retta
Esempi:
Gli attributi che costituiscono chiave primaria vanno sottolineati
Birre
Etichetta Produttore
Studenti
Matricola Nome
Indirizzo

20. Relationship
● Una relationship connette diversi entity set che sono in qualche
rapporto e viene rappresentata con un rombo
Esempio:
Birre
Etichetta Produttore
Clienti
Nome Telefono
Beve

21. Attributi su relationship
Una relationship può prevedere degli attributi che la qualificano, se presenti
vengono rappresentati come ovali
Esempio:
Birre
Etichetta Produttore
Bar
Insegna Indirizzo
Vend
e
Alcolici
Prezzo

22. Diagramma E/R e dati
E' importante capire che un diagramma E/R rappresenta lo schema di come
sono organizzati i dati e come si relazionano fra loro, non costituisce i dati
stessi !
I dati sono mantenuti nella base dati e cambiano nel tempo, ma rispettano
sempre lo schema imposto dal diagramma E/R
Insegna Indirizzo Alcolici
Moe via Verdi, 1 False
Roxy via Roma, 3 True
Rick's corso Italia, 5 True
Bar
Bar
Insegna Indirizzo
Alcolici
Modello E/R
Dati

23. Relationship ternarie (quaternarie, etc…)
Una relationship non collega necessariamente solo due entity set, ma può
essere utilizzata per collegarne di più per mettere in rapporto tre o quattro
entity set fra i quali insista un fatto che ha senso solo coinvolgendoli tutti.
Esempio:
● Immaginiamo che vogliamo modellare il fatto che un cliente preferisca
bere una birra in uno specifico bar (magari perché il prezzo è migliore o
perché viene spillata meglio), come possiamo modellarlo ?

24. Relationship ternarie (quaternarie, etc…)
Birre
Etichetta Produttore
Bar
Insegna Indirizzo
Preferisc
e bere da
Alcolici
Clienti
Nome Telefono

25. Molteplicità delle relationship
Abbiamo visto che le relationship possono connettere un numero variabile di
entity set, mettendo in relazione elementi collegati da un fatto, ma esistono
dei vincoli ?
● E' sempre possibile collegare un elemento di un entity set con elementi
diversi di un altro (un marito può avere più mogli oppure una moglie più
mariti) ?
● Ci sono relazioni di natura non esclusiva (un cliente può bere più birre,
ma la stessa birra può essere bevuta da più clienti) ?
● Ci sono relazioni asimmetriche (un padre può avere più figli, ma un figlio
può avere più padri ?)
Alla necessità di imporre vincoli su queste questioni rispondono le
molteplicità delle relationship

26. Relationship many-to-many
Nelle relationship di tipo many-to-many non esistono vincoli e qualsiasi
elemento di un entity set può essere messo in relazione con uno o più
elementi dell'altro e viceversa
● La relationship Vende fra Bar e Birre
● La relationship Beve fra Clienti e Birre
● La relationship Frequenta fra Studenti e Corsi
● La relationship Conosce fra Studenti e Studenti

27. Aspetto grafico delle relationship many-to-many
Le relationship many-to-many vengono rappresentate con semplici segmenti
senza segni grafici particolari
Corso
Codice Titolo
Studente
Matricola Nome
Frequent
a
Corso di
laurea

28. Relationship many-to-one (o one-to-many)
Nelle relationship di tipo many-to-one un elemento di un entity set può
essere collegato ad (al più) un solo elemento del secondo, ma non viceversa
● La relationship Produce fra Produttori e Birre
● La relationship Favorita fra Clienti e Birre
● La relationship Padre fra Cittadini e Cittadini
● La relationship Appartiene fra Docenti e Dipartimenti

29. Aspetto grafico delle relationship many-to-one
Le relationship many-to-one vengono rappresentate con una freccia nel lato
"one", piena nel caso di al più uno, vuota nel caso di esattamente uno.
Dipartimen
ti
Nome Indirizzo
Docenti
Codice
Fiscale
Nome
Appartien
e
Birre
Etichetta Produttore
Clienti
Nome Telefono
Favorita

30. Relationship one-to-one
Nelle relationship di tipo one-to-one un elemento di un entity set può essere
collegato ad (al più) un solo elemento del secondo, e viceversa
● La relationship BestSeller fra Produttori e Birre
● La relationship Capitano fra Giocatori e Squadre
● La relationship Coniuge fra Cittadini e Cittadini
● La relationship Rettore fra Docenti e Atenei

31. Aspetto grafico delle relationship many-to-one
Le relationship one-to-one vengono rappresentate con le stesse regole delle
many-to-one, ma con due lati "one".
Atenei
Nome Indirizzo
Docenti
Codice
Fiscale
Nome
Rettore
Birre
Etichetta Produttore
Produttor
i
Partita Iva
Ragione
sociale
BestSelle
r

32. Relationship fra elementi del medesimo entity set
E' perfettamente lecito avere relationship interne ad un entity set, nel qual
caso è necessario etichettare dei "ruoli".
Esempi:
Studenti
Matricola Nome
Cittadini
Codice
Fiscale
Nome
Conosc
e
S1 S2
Coniug
e
Marit
o
Mogli
e