RISOLUZIONE APPELLI

DI
SISTEMI INFORMATIVI

a cura di

E. Di Sciascio ed E. Tinelli
CONSIDERAZIONI PRELIMINARI ................................................................................................. 3
APPELLO 28 LUGLIO 2006 ........................................................................................................... 4
Esercizio a ................................................................................................................................. 4
Esercizio b ................................................................................................................................. 6
Esercizio c ................................................................................................................................. 7
Esercizio d ................................................................................................................................. 8
APPELLO 17 FEBBRAIO 2006 ...................................................................................................... 9
Esercizio a ................................................................................................................................. 9
Esercizio b ............................................................................................................................... 11
Esercizio c ............................................................................................................................... 12
Esercizio d ............................................................................................................................... 13
APPELLO 12 FEBBRAIO 2008................................................................................................... 14
Esercizio a............................................................................................................................... 14
Esercizio b............................................................................................................................... 16
Esercizio c ............................................................................................................................... 17
Esercizio d............................................................................................................................... 18
Esempi di Normalizzazione........................................................................................................... 19
1) Appello 7 Aprile 2006 .......................................................................................................... 19
2) Appello 23 Giugno 2006...................................................................................................... 21
3) Appello 28 Settembre 2006................................................................................................. 22
ESEMPI di query SQL .................................................................................................................. 23
1) Appello 21 Novembre 2006................................................................................................. 23
2) Appello 28 Settembre 2006................................................................................................. 24
3) Appello 24 Settembre 2005 ed Esempi vari ........................................................................ 25
CONSIDERAZIONI PRELIMINARI

1. Si osservi che generalmente non esiste una soluzione unica per la risoluzione di un appello.
Pertanto le risoluzioni qui proposte rappresentano esclusivamente un esempio di buone
pratiche, mA non escludono altre risoluzioni formalmente e sostanzialmente corrette. In questo
eserciziario, pertanto, si illustra una delle possibili soluzioni.
2. L’esercizio b va svolto scrivendo le CREATE TABLE corrispondenti a ciascuna relazione del
modello E-R dell’esercizio a. Per semplicità, in questo eserciziario, riportiamo il risultato del
mapping in forma tabellare ed esplicitiamo in SQL solamente le relazioni più complesse.
3. Quando nell’esercizio a si individua un attributo calcolato (o attributo derivato) è possibile
(ma non necessario) scrivere nell’esercizio b, senza ricorrere all’uso dei trigger, la query SQL
che servirebbe per calcolare il suddetto attributo.
4. Per business rules si intendono quelle regole che è necessario verificare e che non possono
essere espresse nel modello E-R. Generalmente tali regole possono essere espresse in SQL
nell’esercizio b mediante check , assertion e trigger.
5. L’esercizio c può essere svolto secondo i seguenti 2 approcci:
- trovare prima la chiave della tabella(anche procedendo per tentativi) e quindi le eventuali
dipendenze piene dalla chiave, le dipendenze parziali e/o transitive dalla chiave;
- trovare tutte le dipendenze funzionali in base alla semantica dei dati ed alle ipotesi del
problema e poi individuare la chiave della tabella.
In questo eserciziario si utilizza il secondo approccio.
APPELLO 28 LUGLIO 2006

Esercizio a

Si progetti uno schema concettuale Entità-Relazioni per lo scenario più sotto descritto.

Una base di dati deve essere utilizzata per gestire gli ordini di un’azienda che produce PC ed
organizzarne la produzione.
Bisogna tener traccia dei dettaglianti che effettuano gli ordini dei PC e dei fornitori che
forniscono i componenti necessari all’azienda per assemblare i PC. Sia i dettaglianti che i fornitori
sono caratterizzati dai seguenti dati: partita iva, ragione sociale, indirizzo, telefono ed e-mail.
Sia i PC che i loro componenti sono caratterizzati da un codice univoco, un nome ed un prezzo.
Inoltre, per i componenti è necessario memorizzare il fornitore di riferimento, mentre per i PC il
numero di pezzi (minore o uguale a 30) ed i componenti che li costituiscono. Bisogna verificare
anche che il numero di pezzi sia inferiore a 20 se il prezzo del PC è inferiore a 1000 euro.
È necessario, infine, tenere traccia dei seguenti eventi:
- gli ordini dei PC da parte dei dettaglianti caratterizzati dalla data ed ora dell’ordine, dalla data di
consegna pattuita, dal tipo di pagamento (anticipato, alla consegna, a 30 gg) e dai PC ordinati con
le relative quantità;
- il processo di assemblaggio di un PC caratterizzato dalla data ed ora di inizio del processo,
dall’ora di fine e dal dipendente che si occupa dell’assemblaggio.
Ciascun dipendente è caratterizzato dai seguenti dati: codice fiscale, nome, cognome, data di
nascita e di assunzione.
Indicare le cardinalità delle relazioni e un identificatore per ciascuna entità.

Osservazioni:
1)Le due entità fornitore e dettagliante sono caratterizzate dagli stessi dati ma non è necessario
modellare una gerarchia costituita nel seguente modo:
- entità padre: azienda
- entità figlie: fornitore e dettagliante.
Il motivo è il seguente: le altre entità del modello fanno riferimento all’entità fornitore oppure
all’entità dettagliante ma mai ad una generica azienda, pertanto la gerarchia doveva risolversi
portando i figli nel padre. Il risultato è quindi quello di avere nel modello E-R due entità distinte
fornitore e dettagliante ciascuna con i sui attributi e le sue relazioni.
2) Le due entità PC e componente sono caratterizzate da alcuni dati in comune, in particolare dalla
chiave codice, ma non è necessario modellare una gerarchia costituita nel seguente modo:
- entità padre: prodotto
- entità figlie: PC e componente.
Considerando che un pc ed un componente non sono “materialmente” la stessa cosa (difatti un pc è
costituito dall’insieme dei componenti) e che le altre entità del modello fanno sempre riferimento
all’entità PC oppure all’entità componente ma mai ad un generico prodotto, una eventuale gerarchia
doveva risolversi portando i figli nel padre. Anche in questo caso il risultato è quello di avere nel
modello E-R due entità distinte PC e componente ciascuna con i sui attributi e le sue relazioni.
Business rules:
1. il numero di pezzi deve essere minore o uguale a 30;
2. il numero di pezzi deve essere inferiore a 20 quando il prezzo del PC è inferiore a 1000
euro;
3. il tipo di pagamento può assumere i seguenti 3 valori: ‘anticipato‘, ‘alla consegna’, ‘a 30
gg’.
Esercizio b

Si definiscano le relazioni (tabelle) risultanti in SQL, avendo cura di esplicitare i vincoli di integrità.

DETTAGLIANTE ( PIVA, ragione_sociale, indirizzo, Tel, e-mail )

FORNITORE ( PIVA, ragione_sociale, indirizzo, Tel, e-mail )

PC ( codice, nome, prezzo, N_pezzi )

COMPONENTE ( codice, nome, prezzo, PIVA_fornitore )
PC_componente ( codicePC, codiceComp )
ORDINE ( data, ora, PIVA_dett, data_consegna, tipo_pagamento )
ORDINE_PC ( data, ora, PIVA_dett, codicePC, quantità )
DIPENDENTE ( CF, nome, cognome, data_nascita, data_assunzione )

ASSEMBLAGGIO ( data_in, ora_in, CF_dipendente, codicePC, ora_fine )

CREATE TABLE PC
( codice char (8) primary key,
nome varchar(30) NOT NULL,
prezzo numeric (7,2) NOT NULL,
N_pezzi int check ( N_pezzi < = 30 ),
check ( N_pezzi >=20 OR (N_pezzi <20 AND prezzo< 1000 ))
)

CREATE TABLE ORDINE

( data date,
ora time,
PIVA_dett char (11) references dettagliante(PIVA),
data_consegna date,
tipo_ pagamento varchar (13) check (tipo_pagamento IN ( ‘anticipato’, ‘alla consegna’, ‘a 30
gg’ ),
primary key (data, ora, PIVA_dett)
)

CREATE TABLE ORDINE_PC

( data date,
ora time,
PIVA_dett char(11),
codicePC char(8) references PC(codice),
quantità smallint NOT NULL,
primary key (data, ora, PIVA_dett, codice PC),
foreign key (data, ora, PIVA_dett) references ORDINE (data, ora, PIVA_dett)
)
Esercizio c

Si vuole realizzare un database relativo alla organizzazione dei provini delle Agenzie di casting
italiane. E’ stata a tal fine costruita, da un inesperto progettista, una unica tabella descritta dai
seguenti attributi:

(PIVA_agenzia, nome_agenzia, indirizzo, tel, CF_partecipante, nome, cognome, data_nascita,

e_mail, codice_materiale_partecipante, descr_materiale, num_foto, città_provino,
nome_hotel_provino, data_provino, ora_provino, tipo_provino, esito_provino)

Nell’ipotesi che ciascun provino è organizzato da un’agenzia e che una stessa persona possa
partecipare a più provini, se ne determini la chiave e si individuino, esplicitandole, le dipendenze
funzionali. Sulla base di queste si proceda alla normalizzazione in 3° forma normale, preservando le
dip. Funzionali.

Dominio\semantica dei dati: organizzazione dei provini delle Agenzie di casting italiane.
Ipotesi della traccia: ciascun provino è organizzato da un’agenzia ed una stessa persona può
partecipare a più provini

Il dominio dei dati e le ipotesi forniscono le seguenti considerazioni: il dominio dei dati indica che è
necessario individuare le agenzie ed i provini mentre secondo le ipotesi della traccia chi li organizza e
chi vi partecipa.

Primo passo: trovare tutte le dipendenze funzionali in accordo al dominio ed alle ipotesi. Passare alla
seconda forma normale individuando eventuali attributi composti. In questo esercizio l’attributo
indirizzo può essere considerato composto dai seguenti attributi: via, N_civico e CAP

1) PIVA_agenzia nome_agenzia, via, N_civico, CAP, tel

2) CF_partecipante nome, cognome, data_nascita, e-mail, codice_materiale_partecipante
3) codice_materiale_partecipante descr_materiale, num_foto
Ipotesi: consideriamo che un’agenzia in una città possa organizzare solo 1 provino al giorno.
4) PIVA_agenzia, città_provino, data_provino nome_hotel_provino, tipo_provino
Ipotesi: consideriamo ora_provino come l’ora in cui inizia la prova di ciascun partecipante.
5) PIVA_agenzia, città_provino, data_provino, CF_partecipante ora_provino, esito_provino

Secondo passo: individuare la chiave della tabella.

In base alle dipendenze trovate ipotizziamo come chiave della tabella PIVA_agenzia, città_provino,
data_provino, CF_partecipante
Se tutte le dipendenze precedenti possono essere classificate rispetto alla suddetta chiave in uno dei
seguenti modi:
• dipendenza piena (la dip. 5);
• dipendenza parziale (la dip. 1, 2, 4);
• dipendenza transitiva (la dip. 3);
allora l’esercizio è svolto correttamente.

Le tabelle risultanti sono:

AGENZIA (PIVA_agenzia, nome_agenzia, via, N_civico, CAP, tel)

PARTECIPANTE (CF_partecipante, nome, cognome, data_nascita, e-mail, codice_materiale_partecipante)

MATERIALE (codice_materiale_partecipante, descr_materiale, num_foto)

PROVINO (PIVA_agenzia, città_provino, data_provino, nome_hotel_provino, tipo_provino)

PARTECIPA_PROVINO (PIVA_agenzia, città_provino, data_provino, CF_partecipante, ora_provino,

esito_provino)

Esercizio d

Date le seguenti relazioni:

PROGETTO(Codice, nome, importo_mensile, data_inizio, data_consegna)
DIPENDENTE(CF, nome, cognome, data_nascita, data_assunzione)
LAVORA_SU(Codice, CF, num_ore, ruolo)
esprimere in SQL le seguenti interrogazioni:

1) Estrarre i responsabili dei progetti con un importo annuale superiore a 10000 euro ed un numero di
ore complessivo superiore a 1000.

SELECT distinct CF
FROM LAVORA_SU natural join PROGETTO
WHERE importo_mensile*12 > 10000
AND ruolo = ‘responsabile’
AND codice IN ( SELECT codice
FROM LAVORA_SU
GROUP BY codice
HAVING sum(num_ore) > 1000 )

2) Per ciascun dipendente, estrarre il numero di progetti su cui lavora attualmente con qualifica di
‘programmatore’.

SELECT CF, count(*)

FROM LAVORA_SU natural join PROGETTO
WHERE ruolo = ‘programmatore’
AND data_inizio <= ‘28/07/2006’
AND data_consegna >= ‘28/07/2006’
GROUP BY CF
APPELLO 17 FEBBRAIO 2006

Esercizio a

Si progetti uno schema concettuale Entità-Relazioni per lo scenario più sotto descritto.

Una base di dati deve essere utilizzata dal comune di Bari per gestire alcuni dati relativi ai suoi
cittadini.
Ciascun cittadino è caratterizzato da un codice fiscale, dal nome e dal cognome, dalla data e dal
comune di nascita, dal numero di telefono e dalla residenza. Inoltre, per ciascun cittadino,
interessa conoscere i seguenti dati che ne definiscono il percorso formativo: occupazione attuale,
titolo di studio con relativa votazione, elenco degli eventuali attestati posseduti con relativa data di
conseguimento.
Per gestire la sezione “Anagrafe” del comune, è necessario memorizzare i seguenti dati:
i genitori di ciascun cittadino, i matrimoni e la relativa data, considerando che ciascun cittadino
può sposarsi più volte ma non con la stessa persona.
Per gestire la sezione “Catasto” del comune, è necessario memorizzare le proprietà di ciascun
cittadino che sono caratterizzate da un identificativo catastale, una descrizione, un valore
economico ed una categoria catastale (unità abitativa, unità commerciale, terreno). Per l’unità
abitativa si deve tener traccia del numero di vani,mentre, per l’unità commerciale ed il terreno, la
superficie (espressa in mq).
Per gestire la sezione “Sanità” del comune, è necessario memorizzare le malattie particolarmente
infettive da cui è attualmente, oppure è stato affetto, ciascun cittadino indicando, per ognuna, la
data di inizio della cura e l’eventuale data di guarigione. Ciascuna malattia è identificata da un
nome univoco, una descrizione, una classe (con valore non superiore a 4) e dal principio attivo che
la cura. Si ipotizzi che nessun cittadino possa avere, per più di una volta, la stessa malattia.
Indicare le cardinalità delle relazioni e un identificatore per ciascuna entità.

Osservazioni:
• Le ipotesi della traccia su matrimonio (ciascun cittadino può sposarsi più volte ma non con la
stessa persona) e malattia (nessun cittadino può avere, per più di una volta, la stessa malattia)
ci permettono di utilizzare delle relazioni N : N.
• L’entità PERCORSO FORMATIVO non è necessaria poichè è possibile assegnare tutti i suoi
attributi e relazioni direttamente all’entità CITTADINO.
• L’espressione eventuale guarigione della traccia indica che il campo data_guarigione può
essere NULL.
• La specifica che la superficie è espressa in mq è un’indicazione per il tipo di dato in SQL da
utilizzare per il campo mq nell’esercizio b.
Risoluzione della gerarchia: Aggiungere un attributo tipo (unità abitativa, terreno, unità
commerciale) all’entità PROPRIETÀ e portare gli attributi dei figli (N_vani, mq) nell’entità padre.
Per essere più precisi dovremmo aggiungere un ulteriore vincolo (check) chiedendo che:

- N_vani ha un valore quando tipo = ‘unità abitativa’

- Mq ha un valore quando tipo = ‘terreno’ oppure tipo = ‘unità commerciale’

Business rules:
1. la classe non può assumere un valore superiore a 4.
2. tipo può assumere solo i 3 valori: ‘unità abitativa’, ‘terreno’, ‘unità commerciale’.
Esercizio b

Si definiscano le relazioni (tabelle) risultanti in SQL, avendo cura di esplicitare i vincoli di integrità.
CITTADINO (CF, nome, cognome, data_nascita, comune_ nascita, residenza, tel, CF_padre,
CF_madre)
MATRIMONIO (CF_marito, CF_moglie, data)
PERCORSO_FORMATIVO ( CF, occupazione, titolo, voto)
ATTESTATO ( ID, NOME)

PERCORSO_ATTESTATO ( CF, ID, data)

PROPRIETÀ (ID_catasto, descrizione, valore, tipo, N_vani, mq, CF_proprietario)
MALATTIA ( nome, descrizione, classe)
CITTADINO_MALATTIA ( CF, malattia, data_inizio, data_guarigione)

CREATE TABLE CITTADINO

( CF char(16) primary key,
nome varchar(30),
cognome varchar(20),
data_nascita date,
comune_nascita varchar(50),
residenza varchar(100),
tel varchar(15),
CF_padre char(16) references CITTADINO(CF),
CF_madre char(16) references CITTADINO(CF) )

CREATE TABLE PERCORSO_FORMATIVO

( CF char(16) primary key,
occupazione varchar(50),
titolo varchar(50),
voto smallint,
foreign key(CF) references CITTADINO(CF)
)

CREATE TABLE PROPRIETÀ

( ID_catasto char(10) primary key,
descrizione varchar(100),
valore numeric(9,2),
tipo varchar (17) check (tipo IN (‘unità abitativa’, ‘terreno’, ‘unità commerciale’),
N_vani smallint,
mq float,
CF_proprietario char(16) references CITTADINO(CF),
check ( (N_vani IS NOT NULL AND tipo = ‘unità abitativa’) OR (mq IS NOT NULL AND tipo
IN (‘terreno’,‘unità commerciale’)) )
)
Esercizio c

Si vuole realizzare un database relativo alla alle programmazioni dei films delle reti televisive
italiane. E’ stata a tal fine costruita, da un inesperto progettista, una unica tabella descritta dai
seguenti attributi:

(cod_film, titolo, regista, anno_produzione, data_programmazione_film, ora_inizio, ora_fine,

nome_reteTV, tipo_rete, cod_pubblicità, nome_pubblicità, ora_trasmissione_pubblicità, durata)

Considerando che alla programmazione di un film possono essere assegnate le stesse pubblicità,
si determini la chiave della tabella e si individuino, esplicitandole, le dipendenze funzionali. Sulla
base di queste si proceda alla normalizzazione in 3° forma normale, preservando le dip. Funzionali.

Dominio\semantica dei dati: programmazioni dei films delle reti televisive italiane.
Ipotesi della traccia: alla programmazione di un film possono essere assegnate le stesse pubblicità
Il dominio dei dati e le ipotesi forniscono le seguenti considerazioni: il dominio dei dati indica che è
necessario individuare i films, le reti televisive e le relative programmazioni mentre secondo le ipotesi
della traccia le pubblicità e quando vengono trasmesse all¶interno di un film in programmazione.

Primo passo: trovare tutte le dipendenze funzionali in accordo al dominio ed alle ipotesi. Passare alla
seconda forma normale individuando eventuali attributi composti.

1) cod_film titolo, regista, anno_produzione

2) nome_reteTV tipo_rete
3) cod_pubblicità nome_pubblicità, durata
Ipotesi: consideriamo che un film non possa essere trasmesso su una stessa rete più volte al giorno.
4) cod_film, nome_reteTV, data_programmazione_film ora_inizio, ora_fine
Ipotesi: consideriamo l’ipotesi della traccia.
5) cod_film, nome_reteTV, data_programmazione_film, ora_trasmissione_pubblicità
cod_pubblicità

Secondo passo: individuare la chiave della tabella.

Si verifichi che, se la chiave della tabella è cod_film, nome_reteTV, data_programmazione_film,

ora_trasmissione_pubblicità, tutte le dipendenze funzionali precedenti possono essere classificate
rispetto alla suddetta chiave in uno dei seguenti modi: dipendenza piena, dipendenza parziale,
dipendenza transitiva.

Le tabelle risultanti sono:

FILM (cod_film, titolo, regista, anno_produzione)

RETE (nome_reteTV, tipo_rete)
PUBBLICITÀ (cod_pubblicità, nome_pubblicità, durata)
PROGRAMMAZIONE_FILM (cod_film, nome_reteTV, data_programmazione_film, ora_inizio,
ora_fine)
PROGRAMMAZIONE_PUBBLICITÀ (cod_film, nome_reteTV, data_programmazione_film,
ora_trasmissione_pubblicità, cod_pubblicità)

Esercizio d

Date le seguenti relazioni:

PERSONA(CF, nome, cognome, data_nascita)
CORSA(N_linea, ora_partenza, comune_partenza, ora_arrivo, comune_arrivo, num_km)
PRENOTAZIONE(codice, data_prenotazione, CF, N_linea, ora_partenza, costo)
esprimere in SQL le seguenti interrogazioni:

1) Estrarre il comune di partenza, il comune di arrivo e la durata di tutte le corse prenotate da ‘Mario
Rossi’.

SELECT comune_partenza, comune_arrivo, ora_arrivo – ora_partenza

FROM CORSA
WHERE (N_linea, ora_partenza) IN ( SELECT N_linea, ora_partenza
FROM PRENOTAZIONE natural join PERSONA
WHERE nome = ‘Mario’
AND cognome = ‘Rossi’
)

2) Estrarre i viaggiatori che hanno prenotato una stessa corsa almeno 2 volte ma mai una corsa in
partenza da ‘Bari’.

SELECT *
FROM Persona
WHERE CF IN ( SELECT distinct P1.CF
FROM PRENOTAZIONE P1, PRENOTAZIONE P2
WHERE P1.N_linea = P2.N_linea
AND P1.ora_partenza = P2.ora_partenza
AND P1.CF = P2.CF
AND P1.codice <> P2.codice
)
AND CF NOT IN ( SELECT distinct CF
FROM PRENOTAZIONE natural join CORSA
WHERE comune_partenza = ‘Bari’
)
APPELLO 12 FEBBRAIO 2008

Esercizio a
Si progetti uno schema concettuale Entità-Relazioni per lo scenario più sotto descritto.

Una base di dati deve essere utilizzata per gestire il calendario delle partite del prossimo campionato
di calcio di serie A e di serie B.
Bisogna, pertanto, tener traccia delle seguenti informazioni: gli stadi italiani, le squadre di calcio, i
calciatori tesserati e le partite disputate. In particolare, si consideri che:
• i calciatori che partecipano al campionato sono caratterizzati dai seguenti dati: numero di tessera,
nome e cognome, data e paese di nascita. A ciascun giocatore è associato eventualmente un fan
club di cui si vuole tener traccia mediante i seguenti dati: numero di iscritti, data di creazione,
quota di partecipazione e sito internet;
• gli stadi utilizzati durante il campionato che sono caratterizzati dai seguenti dati: codice
alfanumerico univoco, nome, capienza e città;
• le squadre che partecipano al campionato che sono caratterizzate dai seguenti dati: identificativo
univoco, nome ed eventuale numero di scudetti vinti.
Per gestire il calendario è necessario tener traccia delle partite disputate, che possono essere di serie A
oppure di serie B, e che sono, inoltre, caratterizzate dai seguenti dati: data della partita, ora di inizio
ed ora di fine, punteggio parziale alla fine del primo tempo e punteggio finale. Si osservi che è
necessario verificare che ciascun punteggio sia costituito da una sequenza di caratteri di questo tipo
‘0:0’. A ciascuna partita bisogna, inoltre, associare lo stadio di riferimento, la squadra che gioca in
casa, la squadra ospite, l’arbitro della partita, di cui si conoscono i soli dati anagrafici, i calciatori
della prima squadra ed i calciatori della seconda. Infine, per ciascun calciatore, sia esso della prima o
della seconda squadra, è necessario tener traccia del ruolo e dell’eventuale numero di reti segnato in
ogni partita e di un campo che indichi se il calciatore giochi come capitano in ciascuna delle partite
disputate.

Indicare le cardinalità delle relazioni e un identificatore per ciascuna entità.

N.B. era possibile anche considerare l’entità FUN CLUB come entità debole dall’entità CALCIATORE
senza chiave parziale

Business rules:
1) punt_parziale e punt_finale devono essere stringhe di testo di questo tipo ‘_:_’
2) serie può assumere i valori ‘A’ oppure ‘B’;
3) capitano può assumere solo due valori (vero/falso oppure sì/no)
4) il codice dello stadio è alfanumerico
Esercizio b
Si definiscano le relazioni (tabelle) risultanti in SQL, avendo cura di esplicitare i vincoli di integrità.

Si riportano per brevità la definizione SQL solamente delle seguenti tabelle: FUN CLUB, PARTITA e
GIOCA_CASA

CREATE TABLE FUN CLUB

(
URL char(30) primary key,
N_tessera char(8) references GIOCATORE (N_tessera),
data_creazione date,
N_iscritti int,
quota_iscrizione numeric(6,2)
)
CREATE TABLE PARTITA
(
data date,
codStadio char(8) references STADIO (codice),
ora_in time,
ora_fin time,
punt_parziale char(3) check( punt_parziale LIKE ‘_:_’),
punt_finale char(3) check( punt_finale LIKE ‘_:_’),
serie char(1) check( serie IN (‘A’,’B’)),
CFarbitro char(16) references ARBITRO (CF),
squadra_ospite int references SQUADRA (codice),
squadra_casa int references SQUADRA (codice),
primary key (data, codStadio)
)

CREATE TABLE GIOCA_CASA

(
N_tessera char(8) references CALCIATORE (N_tessera),
data date,
codStadio char(8),
ruolo varchar(30),
capitano bit,
N_reti,
primary key (N_tessera, data, codStadio)
foreign key(data, codStadio) references PARTITA(data, codStadio)
)
Esercizio c
Si vuole realizzare un database relativo alla gestione delle consegne di una società di trasporti. E’ stata a
tal fine costruita, da un inesperto progettista, un’unica tabella descritta dai seguenti attributi:

(Targa_mezzo, data_immatricolazione, modello, N_patente, nome, cognome, data_nascita,

livello_servizio, data_consegna, N_ord_consegna, N_colli_consegnati, PIVA_dettagliante,
ragione_sociale, via, civico, città, provincia)

Nell’ipotesi che un dettagliante possa ricevere una sola consegna al giorno e che l’attributo
N_ord_consegna indica il numero progressivo assegnato a ciascun dettagliante/consegna per
definire l’ordine delle consegne, se ne determini la chiave e si individuino, esplicitandole, le dipendenze
funzionali. Sulla base di queste si proceda alla normalizzazione in 3° forma normale, preservando le dip.
Funzionali.

IPOTESI 1 - dettagliante possa ricevere una sola consegna al giorno

IPOTESI 2 - N_ord_consegna indica il numero progressivo assegnato a ciascun

dettagliante/consegna per definire l’ordine delle consegne

(1) Targa_mezzo Æ data_immatricolazione, modello

(2) N_patente Æ nome, cognome, data_nascita, livello_servizio

Si osservi che il livello di servizio poteva anche essere associato ad ogni consegna piuttosto che al
conducente

(3) PIVA_dettagliante Æ ragione_sociale, via, civico, città

(4) Città Æ provincia (nell’ipotesi che fissata la città determino univocamente la provincia)

Per le ipotesi della traccia posso identificare univocamente una consegna con data_consegna e
piva_dettagliante (IPOTESI 1) oppure con data_consegna e N_ord_consegna (IPOTESI 2).

In particolare se fisso (soluzione A)

(Data_consegna, piva_dettagliante) determino univocamente il numero d’ordine della relativa consegna

(in termini di dipendenze funzionali avrò Data_consegna, piva_dettagliante Æ N_ord_consegna)

mentre se fisso (soluzione B)

(Data_consegna, N_ord_consegna) determino univocamente la piva_dettagliante associata alla relativa

consegna (in termini di dipendenze funzionali avrò Data_consegna, N_ord_consegna Æ
piva_dettagliante)

In accordo alla soluzione A ottengo la seguente dipendenza funzionale

(5) Data_consegna, piva_dettagliante Æ N_ord_consegna, N_colli_consegnati, targa_mezzo, N_patente

La chiave della tabella risulta essere in questo caso (soluzione A): Data_consegna, piva_dettagliante

Infine, si poteva anche ipotizzare che il numero d’ordine delle consegne fosse sempre lo stesso e non
venisse calcolato di giorno in giorno. In questo caso l’attributo N_ord_consegna andava associato
direttamente alla piva_dettagliante (PIVA_dettagliante Æ ragione_sociale, via, civico, città,
N_ord_consegna) e l’unica chiave possibile per la tabella diventava quella in accordo alla soluzione A

Esercizio d
Date le seguenti relazioni:

CLIENTE (CodCliente, nome, cognome, gg_nascita, mm_nascita, aa_nascita)

PRODOTTO (CodProdotto, nome)
ACQUISTO (CodAcquisto, gg_acquisto, mm_acquisto, aa_acquisto, ora_acquisto, CodCliente)
PRODOTTI_ACQUISTATI(CodAcquisto, CodProdotto, Num_pezzi)

esprimere in SQL le seguenti interrogazioni:

1) Estrarre in ordine alfabetico i dati dei clienti che hanno fatto un acquisto il giorno del loro
compleanno.

SELECT distinct Cliente.*

FROM Cliente natural join Acquisto
WHERE gg_nascita=gg_acquisto
AND mm_nascita=mm_acquisto
ORDER BY cognome, nome

Oppure

SELECT *
FROM Cliente C
WHERE codCliente IN ( SELECT distinct codCliente
FROM Acquisto
WHERE mm_acquisto = C.gg_nascita
AND mm_acquisto = C.mm_nascita)
ORDER BY cognome, nome

Oppure

SELECT *
FROM Cliente C
WHERE (gg_nascita, mm_nascita) IN ( SELECT gg_acquisto, mm_acquisto
FROM Acquisto
WHERE codCliente = C.codCliente
)
ORDER BY cognome, nome
2) Selezionare i prodotti per i quali nel 2007 è stato venduto un numero di pezzi complessivo superiore a
4000.

SELECT *
FROM Prodotto
WHERE codProdotto IN ( SELECT codProdotto
FROM Acquisto natural join Prodotti_acquistati
WHERE aa_acquisto = 2007
GROUP BY codProdotto
HAVING sum(Num_pezzi) > 4000)

Esempi di Normalizzazione

1) Appello 7 Aprile 2006

Si vuole realizzare un database relativo alla gestione delle chiamate di assistenza di un call center.
E’ stata a tal fine costruita, da un inesperto progettista, un’unica tabella descritta dai seguenti attributi:

(cod_operatore, nome, cognome, tipo_operatore, data_chiamata, ora_inizio, ora_fine, CF_cliente,

nome, cognome, data_nascita, tipo_pagamento_assistenza, cod_assistenza,
descrizione_cod_assistenza, costo_assistenza_chiamata)

Ipotesi della traccia: ciascuna chiamata può soddisfare più problemi di assistenza

1. cod_operatore → nome, cognome, tipo_operatore

2. CF_cliente → nome, cognome, data_nascita

3. cod_assistenza → descrizione_cod_assistenza

Osservazione: Un operatore in un certo istante prenderà una sola chiamata e quindi fissati operatore,
data ed ora risultano univocamente definiti anche il cliente che effettua la chiamata e l’ora di fine della
stessa

4. cod_operatore, data_chiamata, ora_inizio → ora_fine, CF_cliente

Osservazione: secondo quanto indicato dalla traccia una stessa chiamata può risolvere più problemi di
assistenza ossia fissata la chiamata è possibile avere N codici di assistenza diversi ed analogamente
fissato un codice di assistenza questo può riferirsi ad N chiamate diverse pertanto si ottiene la seguente
ultima dipendenza

5. cod_operatore, data_chiamata, ora_inizio, cod_assistenza → tipo_pagamento,

costo_assistenza_chiamata
Osservazione: Si è considerato il caso più generale in cui il costo_assistenza_chiamata sia il costo
associato ad un problema di assistenza risolto durante una particolare chiamata

Chiave della tabella: cod_operatore, data_chiamata, ora_inizio, cod_assistenza

• dipendenza piena (la dip. 5);

• dipendenza parziale (la dip. 1, 3, 4 );
• dipendenza transitiva (la dip. 2).
2) Appello 23 Giugno 2006

Si vuole realizzare un database relativo alla gestione delle valutazioni delle prove di un concorso. E’
stata a tal fine costruita, da un inesperto progettista, un’unica tabella descritta dai seguenti attributi:
(CF_partecipante, nome_p, cognome_p, data_nascita, laurea, num_titoli, CF_commissario, nome_c,
cognome_c, titolo_c, codice_elaborato, ora_consegna, num_pagine, puntegg_elaborato,
data_valutazione, ora_valutazione, punteggio_commissario)
Ipotesi della traccia: ciascun elaborato è valutato da più commissari

1. CF_partecipante → nome_p, cognome_p, data_nascita, laurea, num_titoli, codice_elaborato

2. CF_commissario → nome_c, cognome_c, titolo_c

3. codice_elaborato → ora_consegna, num_pagine, puntegg_elaborato

Osservazione: consideriamo l’ipotesi della traccia ed il fatto che è plausibile supporre che un
commissario valuti un elaborato una sola volta e che tale valutazione avverrà in una certa data ed ora

4. CF_partecipante, CF_commissario → punteggio_commissario, data_valutazione, ora_valutazione

Chiave della tabella: CF_partecipante, CF_commissario

• dipendenza piena (la dip. 4);

• dipendenza parziale (la dip. 1, 2 );
• dipendenza transitiva (la dip. 3).
3) Appello 28 Settembre 2006

Si vuole realizzare un database relativo alla gestione dei contratti di affitto dei posti auto di un
autosilo. E’ stata a tal fine costruita, da un inesperto progettista, un’unica tabella descritta dai seguenti
attributi:

(N_patente, data_rilascio, nome, cognome, cellulare, N_targa, modello, colore,

anno_immatricolazione, stato_auto, num_piano, num_box, data_inizio_contratto, data_fine_contratto,
prezzo_affitto)

1. N_patente → data_rilascio, nome, cognome, cellulare

2. N_targa → modello, colore, anno_immatricolazione

3. num_box → num_piano

4. N_targa, data_inizio_contratto → data_fine_contratto, prezzo_affitto, N_patente, num_box,

stato_auto

Osservazione: Si è considerato il caso più generale in cui il proprietario varia nel tempo altrimenti si
poteva anche far dipendere N_patente da N_targa

Chiave della tabella: N_targa, data_inizio_contratto

• dipendenza piena (la dip. 4);

• dipendenza parziale (la dip. 2);
• dipendenza transitiva (la dip. 1,3).
ESEMPI di query SQL

1) Appello 21 Novembre 2006

d) Date le seguenti relazioni:

CONTROLLORE (CF, nome, cognome, data_nascita, codice)

CONTROLLO_AZIENDA (data_controllo, CF_controllore, ora, azienda_riferimento)
RISULTATI_ANALISI_BOVINO ((Data_controllo, CF_controllore, ID_bovino, proteine, lattosio, grasso)

esprimere in SQL le seguenti interrogazioni:

1) Estrarre i dati relativi a 2 controlli: il primo è quello in data odierna ed il secondo è quello
immediatamente precedente.

I soluzione che considera un ordine temporale basato solo sulla data

SELECT *
FROM controllo_azienda
WHERE data_controllo = '21-11-2006'
OR data_controllo = (SELECT max(data_controllo)
FROM controllo_azienda
WHERE data_controllo < '21-11-2006')

II soluzione che considera un ordine temporale basato sulla data e sull’ora

select *
from controllo_azienda
where data_controllo = '21-11-2006'
AND ora=(select max(ora)
from controllo_azienda
where data_controllo = '21-11-2006')
UNION
select *
from controllo_azienda
where (data_controllo, ora) = (select max(data_controllo),max(ora)
from controllo_azienda
where (data_controllo = '21-11-2006'
AND ora1 < (select ora
from controllo_azienda
where (data_controllo, ora) = (select max(data_controllo), max(ora)
from controllo_azienda
where data_controllo = '21-11-2006')))
OR
(data_controllo = (select max(data_controllo)
from controllo_azienda
where data_controllo < '21-11-2006'))
)
 2) Estrarre i controllori che hanno partecipato a controlli per cui si è avuto un valor medio in grasso
pari a 4.5 ed un valor medio in proteine superiore a 4.

SELECT *
FROM controllore
Where CF IN (SELECT distinct CF_controllore
FROM risultati_analisi_bovino
GROUP BY data_controllo, CF_controllore
HAVING avg(grasso) = 4.5 AND avg (proteine) > 4)

2) Appello 28 Settembre 2006

d) Date le seguenti relazioni:

GIOCATORE (N_tessera, nome, cognome, data_nascita, squadra_attuale)

PARTITA (Codice, squadra1, squadra2, campionato, punteggio1, punteggio2)
GIOCATA (Codice, N_tessera, num_reti)

esprimere in SQL la seguente interrogazione:

1) Estrarre i dati del capocannoniere del campionato 2004/2005.

SELECT *
FROM giocatore
WHERE N_tessera IN ( SELECT N_tessera
FROM partita NATURAL JOIN giocata
WHERE campionato = '2004-2005'
GROUP BY N_tessera
HAVING sum(num_reti) >= ALL (SELECT sum(num_reti)
FROM partita NATURAL JOIN giocata
WHERE campionato = '2004-2005'
GROUP BY N_tessera))
3) Appello 24 Settembre 2005 ed Esempi vari
Date le seguenti relazioni:

GUIDATORE ( CF, nome, cognome, età, N_patente)

AUTO ( Targa, data_immatricolazione, modello, CF_guidatore)
INCIDENTE ( Codice, anno, data_ora_riferimento, indirizzo, num_auto_coinvolte, num_feriti)
AUTO_INCIDENTE ( Codice, anno, targa)
esprimere in SQL le seguenti interrogazioni:

1) Selezionare, per ciascun incidente, l’età media dei guidatori coinvolti.

SELECT Codice,anno,avg(eta)
FROM guidatore,auto,auto_incidente
WHERE CF=CF_guidatore AND auto.Targa=auto_incidente.targa
GROUP BY Codice,anno;

2) Selezionare il numero di auto coinvolte ed il numero di feriti del primo e dell’ultimo incidente (su
base temporale) memorizzati nella base di dati .

SELECT num_auto_coinvolte, num_feriti, data_ora_riferimento

FROM incidente
WHERE data_ora_riferimento = (select max(data_ora_riferimento) from incidente)
OR data_ora_riferimento = (select min(data_ora_riferimento) from incidente)

Oppure

SELECT num_auto_coinvolte, num_feriti

FROM incidente
WHERE data_ora_riferimento >= ALL (select data_ora_riferimento from incidente)
OR data_ora_riferimento <= ALL (select data_ora_riferimento from incidente)

3) Estrarre i guidatori che hanno fatto il maggior numero di incidenti

SELECT distinct CF, nome, cognome

FROM guidatore,auto,auto_incidente
WHERE CF=CF_guidatore AND auto.Targa=auto_incidente.targa
GROUP BY CF
HAVING count(*) >= ALL (SELECT count(*)
FROM guidatore,auto,auto_incidente
WHERE CF=CF_guidatore AND auto.Targa=auto_incidente.targa
GROUP BY CF);
 4) Mostrare i guidatori che non sono mai stati coinvolti in incidenti.

SELECT *
FROM guidatore
WHERE CF NOT IN (SELECT distinct CF_guidatore
FROM auto natural join auto_incidente)

5) Selezionare le auto e l’età del relativo guidatore che non hanno fatto più di due incidenti.

SELECT Targa, modello, eta

FROM guidatore,auto
WHERE CF=CF_guidatore AND targa IN (SELECT targa
FROM auto_incidente
GROUP BY targa
HAVING count(*) <=2);