[Basi di dati] Aiuto per modello ER
Salve, sto svolgendo un progetto di basi di dati per un esame universitario che prevede la realizzazione di una piattaforma online per la gestione di eventi sportivi organizzati dagli studenti ed ho forti dubbi sul modello ER che devo preparare. Vi espongo i passaggi che mi lasciano più nel dubbio.
1)
La piattaforma gestisce gli eventi sportivi appartenenti a tre categorie: partite di calcio, pallavolo e tennis.
Per ogni categoria, si vogliono memorizzare: il regolamento (campo di testo), il numero di giocatori, ed una foto esplicativa. In aggiunta, si vogliono gestire le informazioni degli utenti della piattaforma (username univoco, pwd, solite cose). Gli utenti possono appartenere a due tipologie: utenti premium (UP) o utente semplici (US). Un utente UP –e solo lui- può organizzare un evento sportivo (ES): ogni evento dispone di un identificativo univoco, una data di svolgimento, uno stato (APERTO/CHIUSO), ed appartiene ad una delle categorie tra quelle gestite dalla piattaforma[..]
Non so se decidermi se sia giusto considerare la Categoria come un'entità di cui Calcio, Pallavolo e Tennis sono entità "figlie" (però non avrebbero attributi aggiuntivi diversi) oppure se sia più corretto inserire semplicemente l'attributo TIPO all'entità categoria per distinguere se si tratti di calcio pallavolo o tennis e poi mettere una relazione fra CATEGORIA e EVENTO SPORTIVO di tipo "appartenenza". O se ci sono altre soluzioni che non mi sono venute in mente. Il focus dell'applicazione è
2) Inoltre, è prevista la possibilità per gli utenti –sia US sia UP- di iscriversi agli ES APERTI presenti sulla piattaforma, in qualità di giocatore o di arbitro. Ogni iscrizione fa riferimento ad un singolo ES, e dispone di una data e di un campo stato che può assumere due valori: CONFERMATO o RIFIUTATO, a seconda che l’UP organizzatore dell’ES abbia approvato o meno la richiesta di iscrizione. Ogni utente –sia US sia UP- dispone di tre campi aggiuntivi: numero di partite di calcio giocate (ossia cui si è iscritto, e per le quali si è ricevuto conferma positiva), numero di partite di pallavolo giocate, numero di partite di tennis giocate.
Anche qui, mi chiedo, l'iscrizione è meglio considerarla un'entità o una relazione (con attributi propri) fra utente ed evento sportivo? Deve però essere messa in relazione sia con l'utente in generale (per l'inserimento) e sia con l'UP per l'approvazione dell'iscrizione. Oppure questo secondo elemento non è necessario che traspaia dal modello ER? Potrei semplicemente evitare di rappresentare nel modello ER il fatto che l'iscrizione deve essere validata dall'utente premium?
Nella mia elaborazione l'ho considerata un'entità legata dalla relazione "inserimento" con l'utente e dalla relazione "validazione" (che possiede un suo attributo "stato") con l'utente premium.
Inoltre, anche qui mi chiedo se può essere corretto inserire lo stato dell'iscrizione (CONFERMATA/RIFIUTATA) come entità figlie di ISCRIZIONE, in modo da rendere evidente il fatto che un utente abbia giocato in una partita (dato che si devono estrapolare altre info a riguardo, come il numero di partite giocate).
Poi c'è l'importante questione di come inserire il numero di partite giocate di ogni utente (c'è anche la questione di valutare se tenere o meno le ridondanze). Per adesso, potrebbe bastare una serie di attributi nell'entità utente (che comunque ne ha già tantissimi)?
3) Lo stato di un ES diventa CHIUSO quando si raggiunge un numero di giocatori pari a quello previsto dalla categoria (la presenza dell’arbitro è opzionale); in tal caso, non è più possibile effettuare iscrizioni all’ES. Inoltre, è prevista la possibilità di memorizzare l’esito di un ES. L’esito dispone di una data di inserimento (che deve essere ovviamente posteriore alla data di svolgimento), ed è immesso dall’UP organizzatore dell’evento stesso. Nel caso di ES appartenenti alla categoria partita di calcio/partita di pallavolo, l’esito contiene: i nomi delle due squadre, le composizioni (ossia le liste degli utenti giocatori per ciascuna squadra), il numero di goal/punti della prima squadra, il numero di goal/punti della seconda squadra, il numero di goal/punti messi a segno da ciascun utente giocatore. Nel caso di ES appartenente alla categoria tennis, l’esito contiene: il numero di set vinti da ciascun utente giocatore e la durata della partita
Posto che mi è chiaro che l'evento sportivo (ES) deve essere un'entità, mi chiedo se ha senso farne una specializzazione con APERTO e CHIUSO oppure se è più giusto inserire semplicemente l'attributo Stato. Se però faccio una specializzazione posso rendere chiaro nel modello il fatto che l'utente può iscriversi solo ad un ES aperto, legando quindi l'iscrizione alla specializzazione "(ES) APERTO" invece di mettere solo il legame fra iscrizione ed evento sportivo.
Altra domanda fondamentale è sulle informazioni da memorizzare per l'esito ma per ora mi interessa sapere come andare avanti per le cose qui sopra esposte.
Grazie infinite a chiunque vorrà chiarirmi questi dubbi.
1)
La piattaforma gestisce gli eventi sportivi appartenenti a tre categorie: partite di calcio, pallavolo e tennis.
Per ogni categoria, si vogliono memorizzare: il regolamento (campo di testo), il numero di giocatori, ed una foto esplicativa. In aggiunta, si vogliono gestire le informazioni degli utenti della piattaforma (username univoco, pwd, solite cose). Gli utenti possono appartenere a due tipologie: utenti premium (UP) o utente semplici (US). Un utente UP –e solo lui- può organizzare un evento sportivo (ES): ogni evento dispone di un identificativo univoco, una data di svolgimento, uno stato (APERTO/CHIUSO), ed appartiene ad una delle categorie tra quelle gestite dalla piattaforma[..]
Non so se decidermi se sia giusto considerare la Categoria come un'entità di cui Calcio, Pallavolo e Tennis sono entità "figlie" (però non avrebbero attributi aggiuntivi diversi) oppure se sia più corretto inserire semplicemente l'attributo TIPO all'entità categoria per distinguere se si tratti di calcio pallavolo o tennis e poi mettere una relazione fra CATEGORIA e EVENTO SPORTIVO di tipo "appartenenza". O se ci sono altre soluzioni che non mi sono venute in mente. Il focus dell'applicazione è
2) Inoltre, è prevista la possibilità per gli utenti –sia US sia UP- di iscriversi agli ES APERTI presenti sulla piattaforma, in qualità di giocatore o di arbitro. Ogni iscrizione fa riferimento ad un singolo ES, e dispone di una data e di un campo stato che può assumere due valori: CONFERMATO o RIFIUTATO, a seconda che l’UP organizzatore dell’ES abbia approvato o meno la richiesta di iscrizione. Ogni utente –sia US sia UP- dispone di tre campi aggiuntivi: numero di partite di calcio giocate (ossia cui si è iscritto, e per le quali si è ricevuto conferma positiva), numero di partite di pallavolo giocate, numero di partite di tennis giocate.
Anche qui, mi chiedo, l'iscrizione è meglio considerarla un'entità o una relazione (con attributi propri) fra utente ed evento sportivo? Deve però essere messa in relazione sia con l'utente in generale (per l'inserimento) e sia con l'UP per l'approvazione dell'iscrizione. Oppure questo secondo elemento non è necessario che traspaia dal modello ER? Potrei semplicemente evitare di rappresentare nel modello ER il fatto che l'iscrizione deve essere validata dall'utente premium?
Nella mia elaborazione l'ho considerata un'entità legata dalla relazione "inserimento" con l'utente e dalla relazione "validazione" (che possiede un suo attributo "stato") con l'utente premium.
Inoltre, anche qui mi chiedo se può essere corretto inserire lo stato dell'iscrizione (CONFERMATA/RIFIUTATA) come entità figlie di ISCRIZIONE, in modo da rendere evidente il fatto che un utente abbia giocato in una partita (dato che si devono estrapolare altre info a riguardo, come il numero di partite giocate).
Poi c'è l'importante questione di come inserire il numero di partite giocate di ogni utente (c'è anche la questione di valutare se tenere o meno le ridondanze). Per adesso, potrebbe bastare una serie di attributi nell'entità utente (che comunque ne ha già tantissimi)?
3) Lo stato di un ES diventa CHIUSO quando si raggiunge un numero di giocatori pari a quello previsto dalla categoria (la presenza dell’arbitro è opzionale); in tal caso, non è più possibile effettuare iscrizioni all’ES. Inoltre, è prevista la possibilità di memorizzare l’esito di un ES. L’esito dispone di una data di inserimento (che deve essere ovviamente posteriore alla data di svolgimento), ed è immesso dall’UP organizzatore dell’evento stesso. Nel caso di ES appartenenti alla categoria partita di calcio/partita di pallavolo, l’esito contiene: i nomi delle due squadre, le composizioni (ossia le liste degli utenti giocatori per ciascuna squadra), il numero di goal/punti della prima squadra, il numero di goal/punti della seconda squadra, il numero di goal/punti messi a segno da ciascun utente giocatore. Nel caso di ES appartenente alla categoria tennis, l’esito contiene: il numero di set vinti da ciascun utente giocatore e la durata della partita
Posto che mi è chiaro che l'evento sportivo (ES) deve essere un'entità, mi chiedo se ha senso farne una specializzazione con APERTO e CHIUSO oppure se è più giusto inserire semplicemente l'attributo Stato. Se però faccio una specializzazione posso rendere chiaro nel modello il fatto che l'utente può iscriversi solo ad un ES aperto, legando quindi l'iscrizione alla specializzazione "(ES) APERTO" invece di mettere solo il legame fra iscrizione ed evento sportivo.
Altra domanda fondamentale è sulle informazioni da memorizzare per l'esito ma per ora mi interessa sapere come andare avanti per le cose qui sopra esposte.
Grazie infinite a chiunque vorrà chiarirmi questi dubbi.
Risposte
Anche io stò preparando Basi di Dati 
allora, per la prima domanda, visto che non c'è alcuna differenza tra i 3 tipi di eventi sportivi, è buona norma comprimere le classi non usate, eventualmente aggiungendo un campo Tipo.
quindi EVENTO SPORTIVO è un'entità con un campo Tipo che dice di che tipo è(pallavolo, calcio,...)
Per il secondo punto ho un dubbio anche io...ho sempre qualche dubbio quando si tratta di distinguere tra certe relazioni ed entità...in questo caso sembra una relazione.
l'UP secondo me non dovrebbe essere collegato, dopotutto se pensi al diagramma degli studenti-insegnanti-esami sostenuti non c'è nessun collegamento con il docente che ha corretto il compito, ma solo col docente titolare del corso.
Attenzione che ogni utente ha 3 campi, ciascuno con il numero di partite di quello sport giocate, non è una lista.
3)secondo me specializzando l'evento in Aperto/Chiuso sarebbe strano dover cambiare la tabella dell'evento una volta raggiunto il numero massimo di partecipanti, però il testo fa pensare che ci siano proprio due sottoentità di ES, uno aperto e uno chiuso, in cui l'attributo ES "padre" ha tutti i campi e le relazioni generali, quello aperto abbia la relazione con l'utente "iscriviti" e con UP "crea" e il Chiuso abbia gli attributi sui risultati...Propendo per la seconda (le due sottoentità) a meno che non abbiate fatto nel vostro corso i trigger in maniera approfondita per risolvere questi problemi.
Ciao =)
allora, per la prima domanda, visto che non c'è alcuna differenza tra i 3 tipi di eventi sportivi, è buona norma comprimere le classi non usate, eventualmente aggiungendo un campo Tipo.
quindi EVENTO SPORTIVO è un'entità con un campo Tipo che dice di che tipo è(pallavolo, calcio,...)
Per il secondo punto ho un dubbio anche io...ho sempre qualche dubbio quando si tratta di distinguere tra certe relazioni ed entità...in questo caso sembra una relazione.
l'UP secondo me non dovrebbe essere collegato, dopotutto se pensi al diagramma degli studenti-insegnanti-esami sostenuti non c'è nessun collegamento con il docente che ha corretto il compito, ma solo col docente titolare del corso.
Attenzione che ogni utente ha 3 campi, ciascuno con il numero di partite di quello sport giocate, non è una lista.
3)secondo me specializzando l'evento in Aperto/Chiuso sarebbe strano dover cambiare la tabella dell'evento una volta raggiunto il numero massimo di partecipanti, però il testo fa pensare che ci siano proprio due sottoentità di ES, uno aperto e uno chiuso, in cui l'attributo ES "padre" ha tutti i campi e le relazioni generali, quello aperto abbia la relazione con l'utente "iscriviti" e con UP "crea" e il Chiuso abbia gli attributi sui risultati...Propendo per la seconda (le due sottoentità) a meno che non abbiate fatto nel vostro corso i trigger in maniera approfondita per risolvere questi problemi.
Ciao =)
"insideworld":
Anche io stò preparando Basi di Dati
allora, per la prima domanda, visto che non c'è alcuna differenza tra i 3 tipi di eventi sportivi, è buona norma comprimere le classi non usate, eventualmente aggiungendo un campo Tipo.
quindi EVENTO SPORTIVO è un'entità con un campo Tipo che dice di che tipo è(pallavolo, calcio,...)
Per il secondo punto ho un dubbio anche io...ho sempre qualche dubbio quando si tratta di distinguere tra certe relazioni ed entità...in questo caso sembra una relazione.
l'UP secondo me non dovrebbe essere collegato, dopotutto se pensi al diagramma degli studenti-insegnanti-esami sostenuti non c'è nessun collegamento con il docente che ha corretto il compito, ma solo col docente titolare del corso.
Attenzione che ogni utente ha 3 campi, ciascuno con il numero di partite di quello sport giocate, non è una lista.
3)secondo me specializzando l'evento in Aperto/Chiuso sarebbe strano dover cambiare la tabella dell'evento una volta raggiunto il numero massimo di partecipanti, però il testo fa pensare che ci siano proprio due sottoentità di ES, uno aperto e uno chiuso, in cui l'attributo ES "padre" ha tutti i campi e le relazioni generali, quello aperto abbia la relazione con l'utente "iscriviti" e con UP "crea" e il Chiuso abbia gli attributi sui risultati...Propendo per la seconda (le due sottoentità) a meno che non abbiate fatto nel vostro corso i trigger in maniera approfondita per risolvere questi problemi.
Ciao =)
1)
Ciao insideworld, e grazie per aver letto tutto il papocchio
Dunque, per il punto 1), dovendo memorizzare per ogni categoria di sport il regolamento, una foto e il numero di giocatori allora almeno l'entità Categoria deve esistere secondo me, legata da una relazione di appartenenza con l'entità Evento Sportivo (ES).
2) Effettivamente l'azione dell'iscrizione sembra proprio una relazione fra l'utente e l'evento sportivo, quello che è un po' fuorviante è che per ogni iscrizione si vogliono memorizzare data, il campo stato (confermato o rifiutato) ed anche se l'utente si sta iscrivendo all'evento come arbitro o giocatore. Quindi secondo te potrei inserire la relazione ISCRIZIONE fra UTENTE e EVENTO SPORTIVO e come attributi della relazione mettere Data, Tipologia, Stato, evitando di rappresentare nel modello ER il fatto che l'iscrizione deve essere validata da un utente premium? Non mi convince molto il fatto di non rappresentare nel modello quest'ultimo concetto visto che mi sembra abbastanza significativo. Ad esempio in uno schema ER cho ho sul libro un arbitro è rappresentato come un'entità collegata all'entità partita da una relazione chiamata arbitraggio (questo fatto indica che per ogni partita c'è un arbitro). Però, ora che ci penso, non mi sembra che sia chiesto di tenere traccia di quale utente premium abbia approvato la richiesta d'iscrizione, quindi forse in questo caso hai ragione tu, è un'informazione che non è necessario traspaia dal modello ER. Mentre invece ad esempio il fatto che un UP abbia organizzato un ES deve trasparire perché serve sapere chi è l'utente che ha organizzato l'evento. Che ne pensi?
2 bis) Peraltro, ogni utente che ha partecipato ad un ES (quindi in pratica tutti gli utenti confermati) è previsto che possa inserire una valutazione degli altri utenti che hanno partecipato allo stesso evento, e la valutazione deve includere data, punteggio ed eventuale commento. Nello schema io ho messo una relazione Immissione fra Utente e l'entità Valutazione, però da questa relazione non si capisce che la valutazione può inserirla solo chi ha partecipato ad un evento. Secondo te deve essere esplicitato questo fatto nel diagramma?
Attenzione che ogni utente ha 3 campi, ciascuno con il numero di partite di quello sport giocate, non è una lista.
Non ho capito cosa intendi qui.
3) I trigger vanno sicuramente usati nell'applicazione, per alcuni vincoli è espressamente richiesto di usarli, ad esempio ogni volta che un ES raggiunge il numero di giocatori confermati pari a quelli previsti dalla sua categoria il suo stato deve diventare CHIUSO. Ancora, un utente che partecipa a più di 10 ES deve diventare automaticamente premium ed anche qui è richiesto di usare un trigger. Tuttavia, per adesso io sono ancora alla fase del modello ER (che andrà poi anche ristrutturato) e non sono sicura che abbia senso mostrare questa informazione nel modello o se non sia sufficiente indicare semplicemente la relazione "creazione" fra UP e ES (che comunque ha il suo apposito campo Stato ad indicare se sia aperto o chiuso). La domanda è: conviene usare una specializzazione se l'entità figlia ha relazioni che l'entità padre in teoria non dovrebbe avere? Però se inserisco il campo Stato (aperto/chiuso) e relaziono l'evento anche con l'esito, non ottengo forse lo stesso risultato? Oddio che casino
mi sto davvero incartando. Gli esempi che ci sono sui libri sono sempre molto più semplici di così 
E non sono ancora arrivata alla parte più complicata, cioè il punto seguente...
4) L'UP che organizzato l'evento può memorizzare l'esito dell'evento e questo esito deve contenere le seguenti informazioni:
L’esito dispone di una data di inserimento (che deve essere ovviamente posteriore alla data di svolgimento), ed è immesso dall’UP organizzatore dell’evento stesso. Nel caso di ES appartenenti alla categoria partita di calcio/partita di pallavolo, l’esito contiene: i nomi delle due squadre, le composizioni (ossia le liste degli utenti giocatori per ciascuna squadra), il numero di goal/punti della prima squadra, il numero di goal/punti della seconda squadra, il numero di goal/punti messi a segno da ciascun utente giocatore. Nel caso di ES appartenente alla categoria tennis, l’esito contiene: il numero di set vinti da ciascun utente giocatore e la durata della partita.
Qui mi diventa un po' un casino perché il concetto di squadra non è emerso da nessuna parte nelle specifiche, e per il tipo di piattaforma richiesto ha anche poco senso...ho chiesto al prof e mi ha detto che posso eventualmente "ignorare" il concetto di squadra e prevedere un semplice inserimento "manuale" di quelle informazioni. Ma penso che almeno si dovrebbero ricavare dal db le info sui giocatori che hanno partecipato all'evento. A questo sto ancora pensando.
Grazie mille! E in bocca al lupo per il tuo esame!
oggi sono un pò incasinato, domani cercherò di risponderti a tutto.
la prima parte l'avevo fraintesa, se devi fare un entità categoria, secondo me devi considerare il nome della categoria come chiave primaria, visto che calcio, pallavolo e tennis sono delle istanze dell'entità categoria.
"Non ho capito cosa intendi qui."[/quote]
ho letto nel tuo post precedente:
avevo letto "lista" al posto di serie
comunque devo ripassarmi alcune cose di teoria perchè io ricordo che nel diagramma ER non ci fossero cose tipo
p.s. se posti il testo completo provo a fare l'esercizio completo anche io, a volte delle cose che in un punto sembrano importanti lo sono nel punto successivo
Ciao
la prima parte l'avevo fraintesa, se devi fare un entità categoria, secondo me devi considerare il nome della categoria come chiave primaria, visto che calcio, pallavolo e tennis sono delle istanze dell'entità categoria.
[quote]"Attenzione che ogni utente ha 3 campi, ciascuno con il numero di partite di quello sport giocate, non è una lista."
"Non ho capito cosa intendi qui."[/quote]
ho letto nel tuo post precedente:
Poi c'è l'importante questione di come inserire il numero di partite giocate di ogni utente (c'è anche la questione di valutare se tenere o meno le ridondanze). Per adesso, potrebbe bastare una serie di attributi nell'entità utente (che comunque ne ha già tantissimi)?
avevo letto "lista" al posto di serie
comunque devo ripassarmi alcune cose di teoria perchè io ricordo che nel diagramma ER non ci fossero cose tipo
2 bis) Peraltro, ogni utente che ha partecipato ad un ES (quindi in pratica tutti gli utenti confermati) è previsto che possa inserire una valutazione degli altri utenti che hanno partecipato allo stesso evento, e la valutazione deve includere data, punteggio ed eventuale commento. Nello schema io ho messo una relazione Immissione fra Utente e l'entità Valutazione, però da questa relazione non si capisce che la valutazione può inserirla solo chi ha partecipato ad un evento. Secondo te deve essere esplicitato questo fatto nel diagramma?
p.s. se posti il testo completo provo a fare l'esercizio completo anche io, a volte delle cose che in un punto sembrano importanti lo sono nel punto successivo
Ciao
Accedi a tutti gli appunti
Tutor AI: studia meglio e in meno tempo