[Database] Dubbi su chiave di una relazione helpme :-/

[D4rkAng3l]

L'esame si avvicina sempre di più...mancano 5 giorni

Ho qualche quesito vi prego di aiutarmi...

L'esercizio diceva questo:

1) Costruire uno schema E-R logico che rappresenti il database di una flotta di Portaerei. Il database
deve essere disegnato in modo da evidenziare quali aerei fanno parte di una certa portaerei e inoltre
deve tenere memoria del fatto che un' aereo atterra su una portaerei , che può essere anche diversa da
quella a cui appartiene. Ci interessa anche sapere quando avvengono gli atterraggi.

Si tenga conto delle seguenti specifiche :
a) gli oggetti da considerare sono le Portaerei, gli Aerei e i Piloti;
b) il pilota di un' aereo guida sempre lo stesso aereoplano ( da questo se ne deduce che i piloti
sono di stanziamento solo su una portaerei).
Evitare bene la ridondanza dei dati.

2) Costruire quindi lo schema fisico o normalizzato evidenziando bene chiavi di entità e chiavi di
relazioni ed eventuali attributi utili.

3) Dire quali e quante sono le tabelle necessarie per rappresentare il database.

Allora per ora escludiamo la normalizzazione che non ho ancora fatto. Il dubbio è un altro per ora.

Il mio schema E-R e lo schema tradotto è il seguente:



Con la relazione APPARTENENZA specifico che ad una portaerei appartengono di stanziamento minimo uno e massimo n aerei mentre un aereo è stanziato solo su di una singola portaerei.

Con la relazione VOLA dico che un pilota può volare su un solo aereo e che un aereo è pilotato da un solo pilota.

Con la relazione ATTERRAGGIO tengo traccia di quale aereo atterra su quale portaerei e tengo memoria della data e dell'ora in cui gli atterraggi avvengono.

Il secondo schema è lo schema relazionale vero e proprio che può anche essere visto così:

PORTAEREI(nome, anno_di_varo, numero_marinai)

AEREO(codice, modello, anno_di_produzione, nome_portaerei)

PILOTA(matricola, nome, ore_di_volo, aereo_pilotato)

ATTERRAGGIO(nome_portaerei, codice_aereo, data, ora)

Gli attributi in grassetto e sottolineati sono le chiavi, ora ovviamente ci sono i vincoli di integrità referenziale ma dai nomi che ho dato credo sia chiaro quali siano e cosa leghino tra loro.

Il problema è sulla relazione ATTERRAGGIO e sulle sue chiavi.

Vista tabellarmente dovrebbe essere una cosa del genere:

portaerei1 002 12/03/2007 15:30
portaerei2 002 12/03/2007 16:10
portaerei3 001 15/04/2007 12:05
portaerei3 001 15/04/2007 14:07
.......................................................
.......................................................

In pratica mi sà che i soli campi nome_portaerei e codice_aereo non bastano a formare la chiave in quanto non mi identificano univocamente una riga della tabella...ci devo mettere anche la data nella chiave? l'ora si o no?

Viste le specifiche lo schema E-R dite che è fatto decentemente?

Vi prego di farmi sapere qualcosa.

Grazie
Andrea

[ReaToMe]

Se devi tenere lo storico degli atterraggi, devi mettere la data in chiave.
Questo perchè un aereo può atterrare diverse volte sulla stessa portaerei.

Se non devi tenerne traccia, non hai bisogno di aggiungerla in chiave.

[~ZeRO sTrEsS~]

cosa significa E-R?
Io sto impazzendo da un mese sui DB di access

io per pilota e aereo farei una sola tabella... visto che il pilota vola sempre con lo stesso aereo.

Sinceramente non ho capito cosa vogliono dal database. Vogliono tenere traccia di dove vanno gli aerei o se possono atterrare su una portaerei perché giá piena??

Io la farei cosi

2 tabelle ----> (piloti, aerei che pilotano, Appartenenza portaerei) / Codici delle portaerei. Su piloti ed aerei metto la chiave primaria.

Altra tabella dove ci sta partenza del volo, destinazione, arrivo del volo.

poi se vogliono sapere la disponibilitá di atterraggio su una portaerei faccio

X tabelle per quante sono le portaerei
X Query per quante sono le portaerei.

poi con una macro le collego tutte in modo con un click da aggiornare tutte le tabelle portaerei portaerei, in poche parole cancella le tabelle portaerei e le ricrea scrivendo pilota aereo e portaerei di atterraggio. Ovviamente metti una chiave primaria automatica sulle tabelle portaerei, in modo che poi ricavare un count down al riempimento della portaerei.

[D4rkAng3l]

Originariamente inviato da ReaToMe

Se devi tenere lo storico degli atterraggi, devi mettere la data in chiave.
Questo perchè un aereo può atterrare diverse volte sulla stessa portaerei.

Se non devi tenerne traccia, non hai bisogno di aggiungerla in chiave.

Si il testo chiede di tenere traccia dei vari atterraggi: "e inoltre
deve tenere memoria del fatto che un' aereo atterra su una portaerei , che può essere anche diversa da
quella a cui appartiene".

Quindi metto in chiave data ed ora? perchè teoricamente un aereo può atterrare su una certa portaerei in una certa data, ripartire e andare in missione e poi riatterrare proprio sulla stessa portaerei da cui era partito...

Per quanto riguarda le forme normali quella tabella:
ATTERRAGGIO(nome_portaerei, codice_aereo, data, ora)

è sicuramente in prima forma normale perchè ogni campo è formato da dati atomici e non composti, è in 2nf perchè avendo tutti gli attributi che sono chiave non c'è la questione che gli attributi non chiave devono dipendere funzionalmente dalla chiave e credo per lo stesso discorso che possa anche essere considerata in terza forma normale...insomma non posso ottimizzarla più di tanto...

Secondo te dato il testo dell'esercizio il mio schema ER e la relativa traduzione in tabelle può essere considerata valida? insomma per te son da promuovere o da steccare?

[~ZeRO sTrEsS~]

Originariamente inviato da ReaToMe

Se devi tenere lo storico degli atterraggi, devi mettere la data in chiave.
Questo perchè un aereo può atterrare diverse volte sulla stessa portaerei.

Se non devi tenerne traccia, non hai bisogno di aggiungerla in chiave.

emm non va bene perché potresti avere due aerei che partono o decollano alla stessa ora da due portaerei diverse... in questo modo non puoi aggiungere un record.

[D4rkAng3l]

Originariamente inviato da ~ZeRO sTrEsS~

cosa significa E-R?
Io sto impazzendo da un mese sui DB di access

io per pilota e aereo farei una sola tabella... visto che il pilota vola sempre con lo stesso aereo.

Sinceramente non ho capito cosa vogliono dal database. Vogliono tenere traccia di dove vanno gli aerei o se possono atterrare su una portaerei perché giá piena??

Io la farei cosi

2 tabelle ----> (piloti, aerei che pilotano, Appartenenza portaerei) / Codici delle portaerei. Su piloti ed aerei metto la chiave primaria.

Altra tabella dove ci sta partenza del volo, destinazione, arrivo del volo.

poi se vogliono sapere la disponibilitá di atterraggio su una portaerei faccio

X tabelle per quante sono le portaerei
X Query per quante sono le portaerei.

poi con una macro le collego tutte in modo con un click da aggiornare tutte le tabelle portaerei portaerei, in poche parole cancella le tabelle portaerei e le ricrea scrivendo pilota aereo e portaerei di atterraggio. Ovviamente metti una chiave primaria automatica sulle tabelle portaerei, in modo che poi ricavare un count down al riempimento della portaerei.

Aspe no...allora schema E-R intendo schema entity-relationship ed è una metodologia di progettazione dei database che prevede le entità (ovvero gli oggetti che fanno parte) e le relazioni che collegano queste entità...poi lo schema andrebbe revisionato (ovvero ottimizzato per certe istruzioni che vengono eseguite con maggior frequenza) ma questa cosa non è richiesta nel compito d'esame...successivamente lo schema E-R viene tradotto in schema relazionale cioè in tabelle (cioè le entità e le relazioni dello schema E-R devono essere trasformarte in relazioni dello schema relazionale ovvero tabelle), per ultima cosa bisogna normalizzare queste tabelle cioè ricondurle eventualmente non lo fossero in una forma ulteriormente ottimizzata (in genere ci si ferma in terza forma normale) usando delle opportune metodologie.

Acces non c'entra nulla con quello di cui parlavo...apparte che usiamo MySql ma Acces ha anche una progettazione molto più banale in quanto serve per fare piccoli database quindi tante pippe mentali te le eviti e in genere se devi usare acces pensi direttamente in tabelle evitando di netto la fase di progettazione...anche questo è un piccolo database ma l'esame richiede la progettazione in quanto il fine del corso è insegnare appunto la metodologia precisa su come operare con i DB...poi per farci impazzire con un DB grosso c'è il progettone da portare...anche perchè in 2 ore di compito vogliono vedere se hai capito come si progetta e non farti fare un mega DB...

[D4rkAng3l]

Originariamente inviato da ~ZeRO sTrEsS~

emm non va bene perché potresti avere due aerei che partono o decollano alla stessa ora da due portaerei diverse... in questo modo non puoi aggiungere un record.

gli aerei da tener traccia sono solo quelli che atterrano e non quelli che decollino ed è fisicamente impossibile che uno stesso aereo atterri nello stesso minuto di se stesso...

[ReaToMe]

Originariamente inviato da ~ZeRO sTrEsS~

emm non va bene perché potresti avere due aerei che partono o decollano alla stessa ora da due portaerei diverse... in questo modo non puoi aggiungere un record.

Scusa ma no ti seguo.

[D4rkAng3l]

Originariamente inviato da ReaToMe

Scusa ma no ti seguo.

evidentemente ha capito che bisognava tener traccia dei decolli e degli atterraggi su di una portaerei invece bisogna tener traccia solo degli aerei che atterrano su di una certa portaerei e come dicevo prima inserendo la data e l'orario di atterraggio la riga è certamente identificata in maniera univoca.

Sai per caso illuminarmi anche su quella domanda circa la normalizzazione?

Grazie
Andrea

[ReaToMe]

Io ti promuoverei.
Ma quello che ti deve promuovere è un altro.

[D4rkAng3l]

ehehe è cmq più incoraggiante di: "non hai capito una ceppa"...cmq per te la normalizzazione di quella relazione è corretta?