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

Dimensione: px

Iniziare la visualizzazioe della pagina:

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

Leo Pappalardo
8 anni fa
Visualizzazioni

1 RISOLUZIONE APPELLO SISTEMI INFORMATIVI DEL 12/02/2007 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à.

Bisogna, pertanto, tener traccia delle seguenti informazioni: gli stadi italiani, le squadre di calcio, i calciatori tesserati e le partite disputate.

2 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 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 char30 primary key, N_tessera char8 references GIOCATORE N_tessera, data_creazione date, N_iscritti int, quota_iscrizione numeric6,2

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

3 CREATE TABLE PARTITA data date, codstadio char8 references STADIO codice, ora_in time, ora_fin time, punt_parziale char3 check punt_parziale LIKE _:_, punt_finale char3 check punt_finale LIKE _:_, serie char1 check serie IN A, B, CFarbitro char16 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 char8 references CALCIATORE N_tessera, data date, codstadio char8, ruolo varchar30, capitano bit, N_reti, primary key N_tessera, squadra_1 foreign keydata, codstadio references PARTITAdata, codstadio 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à

TABLE GIOCA_CASA N_tessera char8 references CALCIATORE N_tessera, data date, codstadio char8, ruolo varchar30, capitano bit, N_reti, primary key N_tessera, squadra_1 foreign keydata, codstadio

4 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 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_ACQUISTATICodAcquisto, 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 Oppure FROM Cliente C WHERE codcliente IN SELECT distinct codcliente FROM Acquisto WHERE mm_acquisto = C.gg_nascita AND mm_acquisto = C.mm_nascita

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,

5 Oppure FROM Cliente C WHERE gg_nascita, mm_nascita IN SELECT gg_acquisto, mm_acquisto FROM Acquisto WHERE codcliente = C.codCliente 2 Selezionare i prodotti per i quali nel 2007 è stato venduto un numero di pezzi complessivo superiore a FROM Prodotto WHERE codprodotto IN SELECT codprodotto FROM Acquisto natural join Prodotti_acquistati WHERE aa_acquisto = 2007 GROUP BY codprodotto HAVING sumnum_pezzi > 4000

codCliente 2 Selezionare i prodotti per i quali nel 2007 è stato venduto un numero di pezzi complessivo

Documenti analoghi

RISOLUZIONE APPELLI DI SISTEMI INFORMATIVI

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