Appelli ed esercizi svolti - SisInf Lab

CONSIDERAZIONI PRELIMINARI ................................................................................................. 3APPELLO 28 LUGLIO 2006 ........................................................................................................... 4Esercizio a ................................................................................................................................. 4Esercizio b ................................................................................................................................. 6Esercizio c ................................................................................................................................. 7Esercizio d ................................................................................................................................. 8APPELLO 17 FEBBRAIO 2006 ...................................................................................................... 9Esercizio a ................................................................................................................................. 9Esercizio b ............................................................................................................................... 11Esercizio c ............................................................................................................................... 12Esercizio d ............................................................................................................................... 13APPELLO 12 FEBBRAIO 2008................................................................................................... 14Esercizio a............................................................................................................................... 14Esercizio b............................................................................................................................... 16Esercizio c ............................................................................................................................... 17Esercizio d............................................................................................................................... 18Esempi di Normalizzazione........................................................................................................... 191) Appello 7 Aprile 2006 .......................................................................................................... 192) Appello 23 Giugno 2006...................................................................................................... 213) Appello 28 Settembre 2006................................................................................................. 22ESEMPI di query SQL.................................................................................................................. 231) Appello 21 Novembre 2006................................................................................................. 232) Appello 28 Settembre 2006................................................................................................. 243) Appello 24 Settembre 2005 ed Esempi vari ........................................................................ 25

CONSIDERAZIONI PRELIMINARI1. 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 buonepratiche, mA non escludono altre risoluzioni formalmente e sostanzialmente corrette. In questoeserciziario, pertanto, si illustra una delle possibili soluzioni.2. L’esercizio b va svolto scrivendo le CREATE TABLE corrispondenti a ciascuna relazione delmodello E-R dell’esercizio a. Per semplicità, in questo eserciziario, riportiamo il risultato delmapping 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 SQLche servirebbe per calcolare il suddetto attributo.4. Per business rules si intendono quelle regole che è necessario verificare e che non possonoessere espresse nel modello E-R. Generalmente tali regole possono essere espresse in SQLnell’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 eventualidipendenze 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 delproblema e poi individuare la chiave della tabella.In questo eserciziario si utilizza il secondo approccio.

APPELLO 28 LUGLIO 2006Esercizio aSi 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 edorganizzarne la produzione.Bisogna tener traccia dei dettaglianti che effettuano gli ordini dei PC e dei fornitori cheforniscono i componenti necessari all’azienda per assemblare i PC. Sia i dettaglianti che i fornitorisono 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 ilnumero di pezzi (minore o uguale a 30) ed i componenti che li costituiscono. Bisogna verificareanche 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 diconsegna pattuita, dal tipo di pagamento (anticipato, alla consegna, a 30 gg) e dai PC ordinati conle 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 dinascita 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 è necessariomodellare 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 oppureall’entità dettagliante ma mai ad una generica azienda, pertanto la gerarchia doveva risolversiportando i figli nel padre. Il risultato è quindi quello di avere nel modello E-R due entità distintefornitore 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 dallachiave 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 riferimentoall’entità PC oppure all’entità componente ma mai ad un generico prodotto, una eventuale gerarchiadoveva risolversi portando i figli nel padre. Anche in questo caso il risultato è quello di avere nelmodello 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 1000euro;3. il tipo di pagamento può assumere i seguenti 3 valori: ‘anticipato‘, ‘alla consegna’, ‘a 30gg’.

Esercizio bSi 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

Esercizio cSi vuole realizzare un database relativo alla organizzazione dei provini delle Agenzie di castingitaliane. E’ stata a tal fine costruita, da un inesperto progettista, una unica tabella descritta daiseguenti 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 possapartecipare a più provini, se ne determini la chiave e si individuino, esplicitandole, le dipendenzefunzionali. Sulla base di queste si proceda alla normalizzazione in 3° forma normale, preservando ledip. 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ù proviniIl 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 echi vi partecipa.Primo passo: trovare tutte le dipendenze funzionali in accordo al dominio ed alle ipotesi. Passare allaseconda forma normale individuando eventuali attributi composti. In questo esercizio l’attributoindirizzo può essere considerato composto dai seguenti attributi: via, N_civico e CAP1) PIVA_agenzia nome_agenzia, via, N_civico, CAP, tel2) CF_partecipante nome, cognome, data_nascita, e-mail, codice_materiale_partecipante3) codice_materiale_partecipante descr_materiale, num_fotoIpotesi: 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_provinoIpotesi: 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_provinoSecondo passo: individuare la chiave della tabella.In base alle dipendenze trovate ipotizziamo come chiave della tabella PIVA_agenzia, città_provino,data_provino, CF_partecipanteSe tutte le dipendenze precedenti possono essere classificate rispetto alla suddetta chiave in uno deiseguenti 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 dDate 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 diore complessivo superiore a 1000.SELECT distinct CFFROM LAVORA_SU natural join PROGETTOWHERE importo_mensile*12 > 10000AND ruolo = ‘responsabile’AND codice IN ( SELECT codiceFROM LAVORA_SUGROUP BY codiceHAVING 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 PROGETTOWHERE ruolo = ‘programmatore’AND data_inizio = ‘28/07/2006’GROUP BY CF

APPELLO 17 FEBBRAIO 2006Esercizio aSi 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 suoicittadini.Ciascun cittadino è caratterizzato da un codice fiscale, dal nome e dal cognome, dalla data e dalcomune 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 diconseguimento.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 cittadinopuò sposarsi più volte ma non con la stessa persona.Per gestire la sezione “Catasto” del comune, è necessario memorizzare le proprietà di ciascuncittadino che sono caratterizzate da un identificativo catastale, una descrizione, un valoreeconomico 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, lasuperficie (espressa in mq).Per gestire la sezione “Sanità” del comune, è necessario memorizzare le malattie particolarmenteinfettive da cui è attualmente, oppure è stato affetto, ciascun cittadino indicando, per ognuna, ladata di inizio della cura e l’eventuale data di guarigione. Ciascuna malattia è identificata da unnome univoco, una descrizione, una classe (con valore non superiore a 4) e dal principio attivo chela 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 lastessa 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 suoiattributi 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 dautilizzare 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 bSi 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 tipoIN (‘terreno’,‘unità commerciale’)) ))

Esercizio cSi vuole realizzare un database relativo alla alle programmazioni dei films delle reti televisiveitaliane. E’ stata a tal fine costruita, da un inesperto progettista, una unica tabella descritta daiseguenti 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. Sullabase 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 ipotesidella traccia le pubblicità e quando vengono trasmesse allinterno di un film in programmazione.Primo passo: trovare tutte le dipendenze funzionali in accordo al dominio ed alle ipotesi. Passare allaseconda forma normale individuando eventuali attributi composti.1) cod_film titolo, regista, anno_produzione2) nome_reteTV tipo_rete3) cod_pubblicità nome_pubblicità, durataIpotesi: 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_fineIpotesi: 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 classificaterispetto 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)

APPELLO 12 FEBBRAIO 2008Esercizio aSi 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 campionatodi calcio di serie A e di serie B.Bisogna, pertanto, tener traccia delle seguenti informazioni: gli stadi italiani, le squadre di calcio, icalciatori 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 fanclub 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: codicealfanumerico univoco, nome, capienza e città;• le squadre che partecipano al campionato che sono caratterizzate dai seguenti dati: identificativounivoco, nome ed eventuale numero di scudetti vinti.Per gestire il calendario è necessario tener traccia delle partite disputate, che possono essere di serie Aoppure di serie B, e che sono, inoltre, caratterizzate dai seguenti dati: data della partita, ora di inizioed 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 incasa, la squadra ospite, l’arbitro della partita, di cui si conoscono i soli dati anagrafici, i calciatoridella prima squadra ed i calciatori della seconda. Infine, per ciascun calciatore, sia esso della prima odella seconda squadra, è necessario tener traccia del ruolo e dell’eventuale numero di reti segnato inogni partita e di un campo che indichi se il calciatore giochi come capitano in ciascuna delle partitedisputate.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à CALCIATOREsenza chiave parzialeBusiness 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 bSi 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 eGIOCA_CASACREATE 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, squadra_1)foreign key(data, codStadio) references PARTITA(data, codStadio))

Esercizio cSi vuole realizzare un database relativo alla gestione delle consegne di una società di trasporti. E’ stata atal 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’attributoN_ord_consegna indica il numero progressivo assegnato a ciascun dettagliante/consegna perdefinire l’ordine delle consegne, se ne determini la chiave e si individuino, esplicitandole, le dipendenzefunzionali. 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 giornoIPOTESI 2 - N_ord_consegna indica il numero progressivo assegnato a ciascundettagliante/consegna per definire l’ordine delle consegne(1) Targa_mezzo data_immatricolazione, modello(2) N_patente nome, cognome, data_nascita, livello_servizioSi osservi che il livello di servizio poteva anche essere associato ad ogni consegna piuttosto che alconducente(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 epiva_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 relativaconsegna (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_dettaglianteInfine, si poteva anche ipotizzare che il numero d’ordine delle consegne fosse sempre lo stesso e nonvenisse calcolato di giorno in giorno. In questo caso l’attributo N_ord_consegna andava associatodirettamente 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 AEsercizio dDate 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 lorocompleanno.SELECT distinct Cliente.*FROM Cliente natural join AcquistoWHERE gg_nascita=gg_acquistoAND mm_nascita=mm_acquistoORDER BY cognome, nomeOppureSELECT *FROM Cliente CWHERE codCliente IN ( SELECT distinct codClienteFROM AcquistoWHERE mm_acquisto = C.gg_nascitaAND mm_acquisto = C.mm_nascita)ORDER BY cognome, nomeOppureSELECT *FROM Cliente CWHERE (gg_nascita, mm_nascita) IN ( SELECT gg_acquisto, mm_acquistoFROM AcquistoWHERE codCliente = C.codCliente)ORDER BY cognome, nome

2) Selezionare i prodotti per i quali nel 2007 è stato venduto un numero di pezzi complessivo superiore a4000.SELECT *FROM ProdottoWHERE codProdotto IN ( SELECT codProdottoFROM Acquisto natural join Prodotti_acquistatiWHERE aa_acquisto = 2007GROUP BY codProdottoHAVING sum(Num_pezzi) > 4000)Esempi di Normalizzazione1) Appello 7 Aprile 2006Si 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 assistenza1. cod_operatore → nome, cognome, tipo_operatore2. CF_cliente → nome, cognome, data_nascita3. cod_assistenza → descrizione_cod_assistenzaOsservazione: 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 dellastessa4. cod_operatore, data_chiamata, ora_inizio → ora_fine, CF_clienteOsservazione: secondo quanto indicato dalla traccia una stessa chiamata può risolvere più problemi diassistenza ossia fissata la chiamata è possibile avere N codici di assistenza diversi ed analogamentefissato un codice di assistenza questo può riferirsi ad N chiamate diverse pertanto si ottiene la seguenteultima dipendenza5. 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 costoassociato ad un problema di assistenza risolto durante una particolare chiamataChiave 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 2006Si 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ù commissari1. CF_partecipante → nome_p, cognome_p, data_nascita, laurea, num_titoli, codice_elaborato2. CF_commissario → nome_c, cognome_c, titolo_c3. codice_elaborato → ora_consegna, num_pagine, puntegg_elaboratoOsservazione: consideriamo l’ipotesi della traccia ed il fatto che è plausibile supporre che uncommissario valuti un elaborato una sola volta e che tale valutazione avverrà in una certa data ed ora4. CF_partecipante, CF_commissario → punteggio_commissario, data_valutazione, ora_valutazioneChiave 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 2006Si vuole realizzare un database relativo alla gestione dei contratti di affitto dei posti auto di unautosilo. E’ stata a tal fine costruita, da un inesperto progettista, un’unica tabella descritta dai seguentiattributi:(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, cellulare2. N_targa → modello, colore, anno_immatricolazione3. num_box → num_piano4. N_targa, data_inizio_contratto → data_fine_contratto, prezzo_affitto, N_patente, num_box,stato_autoOsservazione: Si è considerato il caso più generale in cui il proprietario varia nel tempo altrimenti sipoteva anche far dipendere N_patente da N_targaChiave 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 SQL1) Appello 21 Novembre 2006d) 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 è quelloimmediatamente precedente.I soluzione che considera un ordine temporale basato solo sulla dataSELECT *FROM controllo_aziendaWHERE data_controllo = '21-11-2006'OR data_controllo = (SELECT max(data_controllo)FROM controllo_aziendaWHERE data_controllo < '21-11-2006')II soluzione che considera un ordine temporale basato sulla data e sull’oraselect *from controllo_aziendawhere data_controllo = '21-11-2006'AND ora=(select max(ora)from controllo_aziendawhere data_controllo = '21-11-2006')UNIONselect *from controllo_aziendawhere (data_controllo, ora) = (select max(data_controllo),max(ora)from controllo_aziendawhere (data_controllo = '21-11-2006'AND ora1 < (select orafrom controllo_aziendawhere (data_controllo, ora) = (select max(data_controllo), max(ora)from controllo_aziendawhere data_controllo = '21-11-2006')))OR(data_controllo = (select max(data_controllo)from controllo_aziendawhere data_controllo < '21-11-2006')))

2) Estrarre i controllori che hanno partecipato a controlli per cui si è avuto un valor medio in grassopari a 4.5 ed un valor medio in proteine superiore a 4.SELECT *FROM controlloreWhere CF IN (SELECT distinct CF_controlloreFROM risultati_analisi_bovinoGROUP BY data_controllo, CF_controlloreHAVING avg(grasso) = 4.5 AND avg (proteine) > 4)2) Appello 28 Settembre 2006d) 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 giocatoreWHERE N_tessera IN ( SELECT N_tesseraFROM partita NATURAL JOIN giocataWHERE campionato = '2004-2005'GROUP BY N_tesseraHAVING sum(num_reti) >= ALL (SELECT sum(num_reti)FROM partita NATURAL JOIN giocataWHERE campionato = '2004-2005'GROUP BY N_tessera))

3) Appello 24 Settembre 2005 ed Esempi variDate 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_incidenteWHERE CF=CF_guidatore AND auto.Targa=auto_incidente.targaGROUP BY Codice,anno;2) Selezionare il numero di auto coinvolte ed il numero di feriti del primo e dell’ultimo incidente (subase temporale) memorizzati nella base di dati .SELECT num_auto_coinvolte, num_feriti, data_ora_riferimentoFROM incidenteWHERE data_ora_riferimento = (select max(data_ora_riferimento) from incidente)OR data_ora_riferimento = (select min(data_ora_riferimento) from incidente)OppureSELECT num_auto_coinvolte, num_feritiFROM incidenteWHERE data_ora_riferimento >= ALL (select data_ora_riferimento from incidente)OR data_ora_riferimento = ALL (SELECT count(*)FROM guidatore,auto,auto_incidenteWHERE CF=CF_guidatore AND auto.Targa=auto_incidente.targaGROUP BY CF);

4) Mostrare i guidatori che non sono mai stati coinvolti in incidenti.SELECT *FROM guidatoreWHERE CF NOT IN (SELECT distinct CF_guidatoreFROM 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, etaFROM guidatore,autoWHERE CF=CF_guidatore AND targa IN (SELECT targaFROM auto_incidenteGROUP BY targaHAVING count(*)