Scarica Database Relazionale SQL - Esercizi svolti con testo e commento e più Prove d'esame in PDF di Database Relazionali solo su Docsity!
Esercizi progettazione DB – 2011/2012 – 5B
- ESERCIZIO 1: CLUB
- ESERCIZIO 2: MEDICI
- ESERCIZIO 3: SQUADRE
- ESERCIZIO 4: CORSI DI BALLO
- ESERCIZIO 5: AUTO
- ESERCIZIO 6: FILIALI
- ESERCIZIO 7: APPARTAMENTI
- ESERCIZIO 8: CIRCOLO DI TENNIS (COMPITO)................................................................................................
- ESERCIZIO 9: FILM (COMPITO)
- ESERCIZIO 10: MOSTRA CANINA
- ESERCIZIO 11: AUTO USATE
- ESERCIZIO 12: OSPEDALE (COMPITO)
- ESERCIZIO 13: NOLEGGIO DVD (COMPITO)
- ESERCIZIO 14: VENDITORI (NORMALIZZAZIONE)..........................................................................................
- ESERCIZIO 15: SCRUTINI
- ESERCIZIO 16: SUPERMERCATO
- ESERCIZIO 17: VETERINARIO
Esercizio 1: Club
Progettare l’archivio dei soci di un club.
Svolgimento
ANALISI DELLA REALTÀ DI INTERESSE
Il progetto è rivolto alla gestione informatizzata dei soci di un club. Si ritengono rilevanti i seguenti dati: Numero Tessera, Cognome, Nome, Luogo di Nascita, Data di Nascita, Indirizzo di residenza, Data di prima iscrizione, Data Ultimo Versamento, Quota versata per l’anno corrente.
IPOTESI AGGIUNTIVE. Si suppone che l’archivio sia di tipo storico perché in caso di rientro del socio i suoi dati sono già disponibili e non è necessario attribuirgli un nuovo numero di tessera.
SCHEMA CONCETTUALE
VINCOLI ESPLICITI
V1 (SOCIO): DataUltVersam >= DataIscrizione V2 (SOCIO): DataNascita > #01/01/1900#
SCHEMA LOGICO
tblSoci(NTessera, Cognome, Nome, LuogoNascita, DataNascita, Indirizzo, Comune, DataIscrizione, DataRinnovo, QuotaVersata)
SCHEMA FISICO
Percorso fisico: Utenti\5Bs\DB Nome del Database: db01_Soci.accdb
SOCIO
NTessera
Cognome
Nome
LuogoNascita
DataNascita
Indirizzo
DataIscrizione
DataUltVersam
QuotaVersata
NTessera
Cognome
Nome
LuogoNascita
DataNascita
Indirizzo
Comune
DataIscrizione
DataUltVersam
QuotaVersata
SOCIO
Esercizio 2: Medici
Progettare una base di dati per memorizzare i dati dei medici generici che fanno capo ad una ASL e dei relativi pazienti. Di ogni medico devono essere registrati un codice, cognome, nome, data e luogo di nascita; di ogni paziente devono essere registrati codice fiscale, cognome, nome, data e luogo di nascita, indirizzo.
Svolgimento
ANALISI DELLA REALTÀ DI INTERESSE
L’ambito del progetto è la gestione informatizzata di una Azienda Sanitaria Locale, limitatamente ai medici di base con l’elenco dei rispettivi pazienti.
SCHEMA CONCETTUALE
SCHEMA LOGICO
tblMedici(Codice, Cognome, Nome, LuogoNascita, DataNascita)
tblPazienti(CF, Cognome, Nome, LuogoNascita, DataNascita, Indirizzo, Comune, CodiceMedico, DataScelta)
SCHEMA FISICO
Percorso fisico: Utenti\5Bs\DB Nome del Database: db02_ASL.accdb
Tabelle
tblMedici Chiave Nome campo Tipo Dimensione Richiesto Valido se K Codice Testo 6 SI Cognome Testo 30 SI Nome Testo 30 SI LuogoNascita Testo 40 SI DataNascita Data/Ora SI > #01/01/1930#
CF Cognome Nome LuogoNascita DataNascita Indirizzo Comune
Codice Cognome Nome LuogoNascita DataNascita
Medico cura Paziente
1
N
DataScelta
tblPazienti Chiave Nome campo Tipo Dimensione Richiesto Valido se K CF Testo 16 SI Cognome Testo 30 SI Nome Testo 30 SI LuogoNascita Testo 40 SI DataNascita Data/Ora SI > #01/01/1900# Indirizzo Testo 40 SI Comune Testo 30 SI FK CodiceMedico Testo 6 SI DataScelta Data/Ora SI
Chiave esterna: CodiceMedico referenzia: tblMedici (Codice)
SCHEMA LOGICO
tblCitta(Citta)
tblSerie(Categoria)
tblSquadre(NomeSquadra, AnnoFondazione, Citta, Serie)
tblGiocatori(NTessera, Cognome, Nome, DataNascita, Squadra)
SCHEMA FISICO
Percorso fisico: Utenti\5Bs\DB Nome del Database: db03_ASLSquadre.accdb
Tabelle
tblCitta Chiave Nome campo Tipo Dimensione Richiesto Valido se K Citta Testo 20 Sì
tblSerie Chiave Nome campo Tipo Dimensione Richiesto Valido se K Categoria Testo 20 Sì
tblSquadre Chiave Nome campo Tipo Dimensione Richiesto Valido se K NomeSquadra Testo 20 Sì AnnoFondazione Intero Sì FK Citta Testo 20 Sì Serie Testo 20 Sì Chiave esterna: Citta referenzia: tblCitta(Citta)
tblGiocatori Chiave Nome campo Tipo Dimensione Richiesto Valido se K NTessera Testo 5 Sì Cognome Testo 30 Sì FK Nome Testo 30 Sì Squadra Testo 20 Sì Chiave esterna: Squadra referenzia: tblSquadre(NomeSquadra)
Esercizio 4: Corsi di ballo
Progettare un DB per gestire i dati dei corsi di ballo erogati da una scuola di danza. Per ogni
corso devono essere registrati il nome, l’orario, il nome dell’istruttore e gli iscritti.
Svolgimento
ANALISI DELLA REALTÀ DI INTERESSE
La realtà di interesse è costituita dalla scuola di danza, di cui si devono gestire i corsi. Le entità individuate sono Corso, Istruttore, Iscritto. Ogni corso è tenuto da un solo istruttore.
IPOTESI AGGIUNTIVE Si suppone che l’archivio sia di tipo attuale perché è molto probabile che la traccia intenda far riferimento alla gestione solo dei corsi attualmente erogati. Si suppone che un istruttore possa anche tenere più corsi, e che un cliente possa iscriversi a più corsi.
SCHEMA CONCETTUALE
SCHEMA LOGICO
tblIstruttori(Matricola, Cognome, Nome, Telefono, DataAssunzione)
tblCorsi(NomeCorso, Orario, DataAvvio, Istruttore, DataAttribuzione)
tblIscritti(NTessera, Cognome, Nome, Telefono)
tblIscrizioni(NTessera, NomeCorso, DataIscrizione)
frequenta
ISCRITTO
CORSO^ èTenutoDa
NomeCorso
Orario
DataAvvio
NTessera
Cognome
Nome
NTelefono
N
M
1
N
ISTRUTTORE
Categoria DataAttribuzione
Matricola
Cognome
Nome
NTelefono
DataAssunzione
Esercizio 5: Auto
Un automobilista vuole gestire le informazioni che riguardano gli interventi effettuati sulla sua auto
da meccanici, carrozzieri, elettrauti, ma anche rifornimenti di benzina, cambio dell’olio, ecc. Per
ogni intervento occorre memorizzare la data, la durata, la descrizione dell’intervento, il costo, la
persona che ha fornito il servizio, indicandone la qualifica, l’indirizzo e il recapito telefonico.
Svolgimento
ANALISI DELLA REALTÀ DI INTERESSE
La realtà di interesse è costituita dagli interventi effettuati sulle auto di una persona. Ogni intervento riguarda una sola auto. Un’auto può ricevere uno o più interventi.
IPOTESI AGGIUNTIVE
La persona può avere più auto. Ogni intervento ha un numero d’ordine. La durata di un intervento è formulata come numero di ore di lavoro. Ogni operatore può avere una sola qualifica.
SCHEMA CONCETTUALE
riceve
AUTO
NTarga
Modello
AnnoImmatricolazione
1
N INTERVENTO
Numero
Descrizione
OreLavoro
Costo
DataIntervento
èFornitoDa OPERATORE
PIVA
Ditta
Qualifica
Indirizzo
Comune
Telefono
N 1
SCHEMA LOGICO
tblAuto (NTarga, Modello, AnnoImmatricolazione)
tblOperatori (PIVA, Ditta, Qualifica, Indirizzo, Comune, Telefono)
tblInterventi (Numero, Descrizione, OreLavoro, Costo, Auto, Operatore)
SCHEMA FISICO
Percorso fisico: Utenti\5AS\DB Nome del Database: db05_Auto.accdb
Tabelle tblRazze
Chiave Nome campo Tipo Dimensione Richiesto Valido se K NTarga Testo 8 Sì Modello Testo 20 Sì AnnoImmatricolazione Numerico Integer Sì >= 1900
tblOperatori Chiave Nome campo Tipo Dimensione Richiesto Valido se K PIVA Testo 18 SI Ditta Testo 30 SI Qualifica Testo 20 SI Indirizzo Testo 30 SI Comune Testo 20 SI Telefono Testo 15 SI
tblInterventi Chiave Nome campo Tipo Dimensione Richiesto Valido se K Numero Numerico Integer SI Descrizione Testo 50 SI OreLavoro Numerico Byte SI Costo Valuta FK Auto Testo 8 FK Operatore Testo 18 Chiave esterna (Auto) referenzia: tblAuto(Targa) Chiave esterna (Operatore) referenzia: tblOperatori(PIVA)
Tabelle
tblFiliali
Chiave Nome campo Tipo Dimensione Richiesto Valido se
K Numero Numerico Intero lungo SI Comune Testo 25 SI Indirizzo Testo 40 SI SK MatrDir Testo 4 NO CognomeDir Testo 25 SI NomeDir Testo 25 SI CellDir Testo 13 NO SK Email Testo 40 NO
Esercizio 7: appartamenti
Progettare una base di dati per memorizzare i dati degli appartamenti di uno stabile e dei
rispettivi proprietari. Si ipotizzi che ogni appartamento abbia un solo proprietario e che ogni
proprietario detenga un solo appartamento.
Svolgimento
ANALISI DELLA REALTÀ DI INTERESSE
La realtà d’interesse è l’insieme degli appartamenti di uno stabile. Il DB da progettare non è storico, perché si registrano solo i dati attuali. Si individuano come entità PROPRIETARIO e APPARTAMENTO. Tra esse si individua un’associazione 1:1.
IPOTESI AGGIUNTIVE Una filiale deve avere obbligatoriamente un proprietario e un direttore deve occuparsi obbligatoriamente di una filiale. Si ritiene opportuno registrare, per ogni filiale, un numero (che la identifica univocamente), il comune e l’indirizzo, mentre, per ogni direttore, una matricola (che lo identifica univocamente), il cognome, il nome, un numero di cellulare e un indirizzo email.
SCHEMA CONCETTUALE
SCHEMA LOGICO
tblAppartamenti (Numero, MQ, Vani)
tblProprietari (CF, Cognome, Nome, {Telefono}, NumeroApp)
VINCOLI ESPLICITI V1 (tblAppartamenti): Numero > V2 (tblAppartamenti): MQ > 40
SCHEMA FISICO
Percorso fisico: Utenti\5AS\DB
Nome del Database: db07_ Appartamenti.accdb
possiede 1
1
Numero MQ Vani
APPARTAMENTO
CF Nome Cognome Telefono
PROPRIETARIO
Esercizio 8: Circolo di tennis (compito)
Un circolo di tennis vuole memorizzare le prenotazioni dei propri campi da parte dei propri soci. Ogni prenotazione viene effettuata da un solo socio, riguarda un solo campo, ha validità di un’ora intera di un dato giorno, e può andare dalle 9:00 alle 21:00.
Di ogni socio interessano i dati anagrafici e il recapito. Di ogni campo interessa sapere il tipo (ad es. coperto e in terra battuta, coperto e in cemento, scoperto, etc.). I tipi non sono predefiniti.
Progettare la base di dati fino allo schema fisico.
Svolgimento
ANALISI DELLA REALTÀ DI INTERESSE
Oggetto dell’automazione è la gestione della prenotazioni dei campi da tennis di un circolo. Il DB da progettare è storico, perché conserva le prenotazioni nel tempo (dalla traccia non si rileva la necessità di cancellarle). Si individuano come entità CAMPO, SOCIO e TIPO CAMPO. La prenotazionè può essere vista come associazione tra CAMPO e SOCIO.
IPOTESI AGGIUNTIVE Si ritiene che i dati di interesse di ogni socio siano un numero di tessera (che lo identifica univocamente), cognome, nome e recapito telefonico), mentre per il campo si ritiene di dover registrare lunghezza, larghezza e un identificativo, che potrebbe essere un numero.
SCHEMA CONCETTUALE
SCHEMA LOGICO
tblSoci (NTessera, Cognome, Nome, Telefono)
tblTipi (Tipo)
tblCampi (Numero, Lunghezza, Larghezza, Tipo)
tblPrenota (Socio, Campo, Data, Ora)
N.B.: La particolare chiave di tblPrenota è dovuta alla necessità di evitare che uno stesso
campo possa essere prenotato da più persone nello stesso momento (giorno e ora).
prenota N
SOCIO^ M^ CAMPO
Numero Lunghezza Larghezza
èDi^1 TIPO
Tipo
N
NTessera Cognome Nome Telefono
Data Ora
Inserire nella
dispensa
SCHEMA FISICO
Percorso fisico: Utenti\5AS\DB
Nome del Database: db07_ Appartamenti.accdb
Tabelle
tblSoci
Chiave Nome campo Tipo Dimensione Richiesto Valido se K NTessera Numerico Integer SI > Cognome Testo 20 SI Nome Testo 20 SI Telefono Testo 15
tblTipi
Chiave Nome campo Tipo Dimensione Richiesto Valido se K Tipo Testo SI
tblCampi
Chiave Nome campo Tipo Dimensione Richiesto Valido se K Numero Numerico Byte SI Lunghezza Numerico Integer SI Larghezza Numerico Integer SI Tipo Testo 20 SI
SCHEMA FISICO
Percorso fisico: Utenti\5AS\DB Nome del Database: db09_Film.accdb
Tabelle tblProduttori
Chiave Nome campo Tipo Dimensione Richiesto Valido se K RagioneSociale Testo 20 Sì AnnoFondazione Numerico Integer Sì Recapito Testo 40 Sì
tblFilm Chiave Nome campo Tipo Dimensione Richiesto Valido se K Titolo Testo 20 SI Anno Numerico Integer SI FK Produttore Testo 20 SI Chiave esterna (Produttore) referenzia: tblProduttori(RagioneSociale)
tblRuoli Chiave Nome campo Tipo Dimensione Richiesto Valido se K Ruolo Testo 20 SI
tblAttori Chiave Nome campo Tipo Dimensione Richiesto Valido se K CF Testo 16 SI Cognome Testo 20 SI Nome Testo 20 SI DataNascita Data/Ora LuogoNascita Testo 20
tblInterpretazioni Chiave Nome campo Tipo Dimensione Richiesto Valido se FK,K Attore SI FK,K Film SI Ruolo SI Chiave esterna (Attore) referenzia: tblAttori(CF) Chiave esterna (Film) referenzia: tblFilm(Titolo)
Esercizio 10: MOSTRA CANINA
Progettare una base di dati per la gestione di una mostra canina. Di ogni cane, identificato da un codice, interessano il nome, la data di nascita, l'altezza, il peso, la razza di appartenenza, e i dati del proprietario. Le razze si distinguono dal nome, e possiedono un'altezza e un peso standard. Ogni giudice, identificato da un codice, esprime un voto su ciascun cane.
Realizzare l’analisi della realtà d’interesse, con eventuali ipotesi aggiuntive, lo schema concettuale, lo schema logico, lo schema fisico e un’applicazione per la gestione dei dati. Sviluppare in Access sia la base di dati, sia l’applicazione.
Svolgimento
ANALISI DELLA REALTÀ DI INTERESSE
La realtà d’interesse è una mostra canina. Il Database da realizzare ha breve durata nel tempo, perché è destinato alla gestione di una mostra canina, quindi è senz'altro di tipo attuale. Sia i giudici che i cani in concorso sono in numero imprecisato. Ogni cane sarà valutato da tutti i giudici. Ogni giudice esprime un solo voto su ciascun cane. Si individuano come entità CANE, PROPRIETARIO, RAZZA, GIUDICE.
IPOTESI AGGIUNTIVE Si suppone che ogni proprietario possa presentare un solo cane alla mostra. Di ogni proprietario si ritiene di dover registrare il codice fiscale, che lo identifica univocamente, cognome, nome, indirizzo e città di residenza. Di ogni giudice, oltre al codice, si ritiene di dover registrare almeno cognome e nome.
SCHEMA CONCETTUALE
SCHEMA LOGICO
tblRazze (NomeR, AltezzaStd, PesoStd)
tblCani (Codice, NomeCane, Razza, Altezza, Peso, DataNascita, CFPr, CognomePr, NomePr, TelefonoPr)
tblGiudici (Codice, Cognome, Nome)
tblValutazioni (CodGiudice, CodCane, Voto)
Codice Nome DataNascita Altezza Peso
Codice Cognome Nome
presenta
valuta M
N
1
1
Voto
1
Nome AltezzaStd PesoStd
N
Giudice Cane^ appartiene^ Razza
CF Cognome Nome Telefono
Proprietario
