RISOLUZIONE APPELLI DI SISTEMI INFORMATIVI

Transcript

1 RISOLUZIONE APPELLI DI SISTEMI INFORMATIVI a cura di E. Di Sciascio ed E. Tinelli

2 CONSIDERAZIONI PRELIMINARI... 3 APPELLO 28 LUGLIO Esercizio a... 4 Esercizio b... 6 Esercizio c... 7 Esercizio d... 8 APPELLO 17 FEBBRAIO Esercizio a... 9 Esercizio b Esercizio c Esercizio d APPELLO 12 FEBBRAIO Esercizio a Esercizio b Esercizio c Esercizio d Esempi di Normalizzazione ) Appello 7 Aprile ) Appello 23 Giugno ) Appello 28 Settembre ESEMPI di query SQL ) Appello 21 Novembre ) Appello 28 Settembre ) Appello 24 Settembre 2005 ed Esempi vari... 25

3 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.

4 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 . 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.

5 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.

6 Esercizio b Si definiscano le relazioni (tabelle) risultanti in SQL, avendo cura di esplicitare i vincoli di integrità. DETTAGLIANTE ( PIVA, ragione_sociale, indirizzo, Tel, ) FORNITORE ( PIVA, ragione_sociale, indirizzo, Tel, ) 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) )

7 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, , 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);

8 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, , 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 euro ed un numero di ore complessivo superiore a SELECT distinct CF FROM LAVORA_SU natural join PROGETTO WHERE importo_mensile*12 > 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

9 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.

10 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 tipo può assumere solo i 3 valori: unità abitativa, terreno, unità commerciale.

11 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 )) ) )

12 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)

13 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 )

14 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à.

15 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

16 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) )

17 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

18 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

19 2) Selezionare i prodotti per i quali nel 2007 è stato venduto un numero di pezzi complessivo superiore a 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

20 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).

21 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).

22 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).

23 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 = ' ' OR data_controllo = (SELECT max(data_controllo) FROM controllo_azienda WHERE data_controllo < ' ') II soluzione che considera un ordine temporale basato sulla data e sull ora select * from controllo_azienda where data_controllo = ' ' AND ora=(select max(ora) from controllo_azienda where data_controllo = ' ') UNION select * from controllo_azienda where (data_controllo, ora) = (select max(data_controllo),max(ora) from controllo_azienda where (data_controllo = ' ' AND ora1 < (select ora from controllo_azienda where (data_controllo, ora) = (select max(data_controllo), max(ora) from controllo_azienda where data_controllo = ' '))) OR (data_controllo = (select max(data_controllo) from controllo_azienda where data_controllo < ' ')) )

24 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 = ' ' GROUP BY N_tessera HAVING sum(num_reti) >= ALL (SELECT sum(num_reti) FROM partita NATURAL JOIN giocata WHERE campionato = ' ' GROUP BY N_tessera))

25 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);

26 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);