[Basi di dati] Dilemmi sul modello ER
Ciao, come modellereste in un modello ER la seguente situazione (trattasi di piattaforma online per iscriversi ad eventi sportivi, gli utenti sono divisi in due categorie semplici e premium):
- un utente può iscriversi ad un certo evento sportivo con un certo ruolo (arbitro/giocatore)
- l'iscrizione deve avere una data e uno stato (approvata/rifiutata) e l'approvazione o meno deve essere fatta dall'utente premium che ha organizzato quell'evento.
Io ho pensato di far così:
- ho messo una relazione "Richiesta" fra UTENTE e ISCRIZIONE
- una relazione "Partecipazione" fra ISCRIZIONE e EVENTO
- una relazione "Validazione" fra UTENTE PREMIUM (che è una specializzazione di UTENTE) e ISCRIZIONE, la quale ha un unico attributo che è lo stato.
Che cosa ne pensate? In questo modo però non ho modellato il fatto che la validazione deve farla proprio l'UP che ha organizzato quell'evento (l'UP è legato anche da una relazione "Creazione" con EVENTO), ma potrei inserire questa informazione nelle business rules, che dite?
Grazie di cuore a chiunque mi aiuterà a dipanare la matassa (di cui questo è solo un piccolo frammento
)
- un utente può iscriversi ad un certo evento sportivo con un certo ruolo (arbitro/giocatore)
- l'iscrizione deve avere una data e uno stato (approvata/rifiutata) e l'approvazione o meno deve essere fatta dall'utente premium che ha organizzato quell'evento.
Io ho pensato di far così:
- ho messo una relazione "Richiesta" fra UTENTE e ISCRIZIONE
- una relazione "Partecipazione" fra ISCRIZIONE e EVENTO
- una relazione "Validazione" fra UTENTE PREMIUM (che è una specializzazione di UTENTE) e ISCRIZIONE, la quale ha un unico attributo che è lo stato.
Che cosa ne pensate? In questo modo però non ho modellato il fatto che la validazione deve farla proprio l'UP che ha organizzato quell'evento (l'UP è legato anche da una relazione "Creazione" con EVENTO), ma potrei inserire questa informazione nelle business rules, che dite?
Grazie di cuore a chiunque mi aiuterà a dipanare la matassa (di cui questo è solo un piccolo frammento
)
Risposte
A me sembra vada bene, ma si tratta di una di quelle cose in cui non c'è una risposta corretta o sbagliata. Personalmente avrei in effetti usato diverse entità, ma non amo molto lavorare con questo tipo di astrazione* e tendo a pensare più facilmente in termini di strutture dati più concrete.
* Ho sempre trovato il modello ER inutile in quanto mi sembra molto lontano sia dalla formulazione del problema che dalla sua effettiva implementazione. Trovo sinceramente che la breve descrizione che hai fatto all'inizio sia in effetti più utile e precisa di quanto non lo sia il diagramma ER corrispondente.
* Ho sempre trovato il modello ER inutile in quanto mi sembra molto lontano sia dalla formulazione del problema che dalla sua effettiva implementazione. Trovo sinceramente che la breve descrizione che hai fatto all'inizio sia in effetti più utile e precisa di quanto non lo sia il diagramma ER corrispondente.
Intanto grazie per la tua risposta 
Anche a me a volte il modello ER sembra un esercizio "inutile", ma purtroppo mi tocca farlo in questo progetto, è per un esame. Tanto peraltro sarà sicuramente rielaborato parecchio nella successiva progettazione logica.
Cosa intendi con "Personalmente avrei in effetti usato diverse entità"?
Ci sarebbe un'altra questione che mi "tormenta".
Da specifiche, un utente che abbia partecipato ad un evento può inserire una valutazione su un altro utente (giocatore) che abbia partecipato ad un evento. Ora, siccome la partecipazione di un utente ad un evento si evince solo dalla sua iscrizione (confermata), l'unica soluzione che mi è venuta in mente per modellare questo contesto è inserire una relazione ricorsiva "Valutazione" (con attributi Data, Punteggio, Commento) tra l'entità ISCRIZIONE e se stessa, dove un ramo è "Valutante" e l'altro ramo è "Valutato" (ma non riesco a stabilirne la cardinalità, so che un utente giocatore può inserire una sola valutazione su uno specifico utente giocatore).
Tuttavia, anche qui, ho diverse perplessità: "navigando" nel modello posso sapere chi ha inserito una valutazione perché comunque l'entità ISCRIZIONE è legata all'entità UTENTE anche se non c'è un legame diretto fra UTENTE e "Valutazione"?
Che casino...
Anche a me a volte il modello ER sembra un esercizio "inutile", ma purtroppo mi tocca farlo in questo progetto, è per un esame. Tanto peraltro sarà sicuramente rielaborato parecchio nella successiva progettazione logica.
Cosa intendi con "Personalmente avrei in effetti usato diverse entità"?
Ci sarebbe un'altra questione che mi "tormenta".
Da specifiche, un utente che abbia partecipato ad un evento può inserire una valutazione su un altro utente (giocatore) che abbia partecipato ad un evento. Ora, siccome la partecipazione di un utente ad un evento si evince solo dalla sua iscrizione (confermata), l'unica soluzione che mi è venuta in mente per modellare questo contesto è inserire una relazione ricorsiva "Valutazione" (con attributi Data, Punteggio, Commento) tra l'entità ISCRIZIONE e se stessa, dove un ramo è "Valutante" e l'altro ramo è "Valutato" (ma non riesco a stabilirne la cardinalità, so che un utente giocatore può inserire una sola valutazione su uno specifico utente giocatore).
Tuttavia, anche qui, ho diverse perplessità: "navigando" nel modello posso sapere chi ha inserito una valutazione perché comunque l'entità ISCRIZIONE è legata all'entità UTENTE anche se non c'è un legame diretto fra UTENTE e "Valutazione"?
Che casino...
Questo è come avrei fatto le cose (ma non vuol dire che sia necessariamente meglio/peggio della tua soluzione). Come ho già detto il mio approccio è forse al contrario di quello che dovrebbe essere (dalle tabelle al modello ER piuttosto che il contrario) per cui è probabilmente molto diverso da come vorrebbe il tuo professore.
Invece di creare una relazione richiesta, avrei creato una entità RICHIESTA. RICHIESTA avrebbe quindi avuto una relazione con UTENTE (richiedente) e una con PARTECIPAZIONE (coppia ruolo/evento). La relazione con PARTECIPAZIONE avrebbe avuto un attributo che indica lo stato della richiesta. Ovviamente PARTECIPAZIONE avrebbe avuto relazioni con RUOLO ed EVENTO. L'EVENTO avrebbe infine una relazione con UTENTE PREMIUM che ne indica l'organizzatore. Il fatto che l'organizzatore è quello che ha la responsabilità di accettare le richieste non lo inserirei nel diagramma (sarebbe implicito nella regola per cui a farlo è l'organizzatore dell'evento). Tuttavia questa soluzione è forse meno adatta della tua a modellare la nuova relazione che hai richiesto. Anche se nella pratica la valutazione sarebbe probabilmente una tabella che lega i due utenti e l'evento, per cui forse sarebbe meglio modellarla come una entità invece che una relazione.
Nel tuo caso è ovviamente possibile stabilire l'utente dall'INSCRIZIONE e non c'è alcuna ragione per aggiungere ulteriori relazioni o attributi o altro.
Invece di creare una relazione richiesta, avrei creato una entità RICHIESTA. RICHIESTA avrebbe quindi avuto una relazione con UTENTE (richiedente) e una con PARTECIPAZIONE (coppia ruolo/evento). La relazione con PARTECIPAZIONE avrebbe avuto un attributo che indica lo stato della richiesta. Ovviamente PARTECIPAZIONE avrebbe avuto relazioni con RUOLO ed EVENTO. L'EVENTO avrebbe infine una relazione con UTENTE PREMIUM che ne indica l'organizzatore. Il fatto che l'organizzatore è quello che ha la responsabilità di accettare le richieste non lo inserirei nel diagramma (sarebbe implicito nella regola per cui a farlo è l'organizzatore dell'evento). Tuttavia questa soluzione è forse meno adatta della tua a modellare la nuova relazione che hai richiesto. Anche se nella pratica la valutazione sarebbe probabilmente una tabella che lega i due utenti e l'evento, per cui forse sarebbe meglio modellarla come una entità invece che una relazione.
Nel tuo caso è ovviamente possibile stabilire l'utente dall'INSCRIZIONE e non c'è alcuna ragione per aggiungere ulteriori relazioni o attributi o altro.
Ciao, scusa per il ritardo nella risposta, purtroppo riesco a lavorare a questo progetto a fasi alterne.
Quindi secondo te se faccio un'entità VALUTAZIONE e la metto in due relazioni "Valutante" e "Valutato" con UTENTE, non è necessario/utile inserire un'ulteriore relazione fra VALUTAZIONE ed EVENTO? Effettivamente nelle specifiche non è scritto di tenere traccia di a quale evento faccia riferimento la valutazione, c'è scritto solo che "un utente che ha partecipato ad un EVENTO può eventualmente valutare la prestazione degli altri utenti giocatori". Però è un particolare importante che non riesco a mettere nemmeno nelle business rules visto che non rappresenta esattamente una di quelle regole, quindi non so. Questa è una delle cose che sto trovando più difficili nella compilazione di un modello ER, ovvero capire quali informazioni devono trasparirne chiaramente. Immaginando però l'applicazione in funzione, mi rendo conto che probabilmente sarebbe una cosa del tipo:
- utente x si logga nel sistema
- x ha partecipato ad un evento, quindi viene visualizzata la finestra con la possibilità di inserire una valutazione
- nella finestra verranno mostrati solo gli altri utenti giocatori per quell'evento
Quindi mi sembra più una faccenda da implementare via codice.
Per l'altra faccenda, non ho capito perché pensi sia utile inserire un'ulteriore entità RICHIESTA e PARTECIPAZIONE e questo passaggio
pure non mi è chiaro. PARTECIPAZIONE dovrebbe quindi essere un'ulteriore tabella ma con quali attributi?
Grazie ancora!
Quindi secondo te se faccio un'entità VALUTAZIONE e la metto in due relazioni "Valutante" e "Valutato" con UTENTE, non è necessario/utile inserire un'ulteriore relazione fra VALUTAZIONE ed EVENTO? Effettivamente nelle specifiche non è scritto di tenere traccia di a quale evento faccia riferimento la valutazione, c'è scritto solo che "un utente che ha partecipato ad un EVENTO può eventualmente valutare la prestazione degli altri utenti giocatori". Però è un particolare importante che non riesco a mettere nemmeno nelle business rules visto che non rappresenta esattamente una di quelle regole, quindi non so. Questa è una delle cose che sto trovando più difficili nella compilazione di un modello ER, ovvero capire quali informazioni devono trasparirne chiaramente. Immaginando però l'applicazione in funzione, mi rendo conto che probabilmente sarebbe una cosa del tipo:
- utente x si logga nel sistema
- x ha partecipato ad un evento, quindi viene visualizzata la finestra con la possibilità di inserire una valutazione
- nella finestra verranno mostrati solo gli altri utenti giocatori per quell'evento
Quindi mi sembra più una faccenda da implementare via codice.
Per l'altra faccenda, non ho capito perché pensi sia utile inserire un'ulteriore entità RICHIESTA e PARTECIPAZIONE e questo passaggio
RICHIESTA avrebbe quindi avuto una relazione con UTENTE (richiedente) e una con PARTECIPAZIONE (coppia ruolo/evento).
pure non mi è chiaro. PARTECIPAZIONE dovrebbe quindi essere un'ulteriore tabella ma con quali attributi?
Grazie ancora!
Avrei separato la tua entità PARTECIPAZIONE in due, una dedicata alla richiesta di un utente di partecipare e l'altra relativa a cosa sta effettivamente richiedendo (di essere un arbitro o giocatore ad un particolare evento). Ma esistono numerosi modo diversi per fare questa cosa e la mia opinione non è necessariamente migliore della tua (sono dopotutto cose che ho fatto tempo fa e ritenuto inutili/dannose). I modelli ER non rispecchiano il mio modo di approcciarmi ad un problema e descrivere un insieme di informazioni. Esistono a mio parere problemi che si possono facilmente tradurre in un modello ER e altri in cui ho l'impressione di star cercando di forzare una serratura con la chiave sbagliata. Penso quindi che faresti meglio a seguire consigli da persone per cui tutto questo abbia un senso.
Penso che il tuo problema con i modelli ER sia semplicemente legato all'idea che debba esistere un modo giusto di realizzarlo. Che ci sia necessariamente l'ha risposta giusta e che le altre sono sbagliate. Non è quasi mai così in programmazione. E in questo caso in modo particolare, perché lo scopo di questo modello è solo quello di comprendere meglio la struttura e le relazioni interne nei dati. Al di fuori dell'università è insomma qualcosa che facciamo per noi o per semplificare la comunicazione con altri ed è ridicolo mettere regole troppo strette su una cosa del genere. Le definizioni sono poco precise proprio per questo. Cosa mettere nel modello è in generale una tua scelta, ma puoi evitare cose che puoi ottenere a partire dalle entità e dalle relazioni esistenti.
Penso che il tuo problema con i modelli ER sia semplicemente legato all'idea che debba esistere un modo giusto di realizzarlo. Che ci sia necessariamente l'ha risposta giusta e che le altre sono sbagliate. Non è quasi mai così in programmazione. E in questo caso in modo particolare, perché lo scopo di questo modello è solo quello di comprendere meglio la struttura e le relazioni interne nei dati. Al di fuori dell'università è insomma qualcosa che facciamo per noi o per semplificare la comunicazione con altri ed è ridicolo mettere regole troppo strette su una cosa del genere. Le definizioni sono poco precise proprio per questo. Cosa mettere nel modello è in generale una tua scelta, ma puoi evitare cose che puoi ottenere a partire dalle entità e dalle relazioni esistenti.
Temo che a riguardo io mi sia fatta influenzare un po' troppo da quello che ho letto sul libro, dove mi sembra che si dedichi un'attenzione non trascurabile a questo modello. Ho visto tanti esempi ma nessuno che si avvicinasse alla complessità di questo progetto che sto facendo io, anche se probabilmente mi sto facendo troppi problemi e ci sto dedicando più tempo di quanto non sarebbe in realtà necessario.
Approfitto dunque per farti un'ultima domanda: attualmente sto usando JDER come editor di diagrammi ER, è semplice e funzionale ma ha un paio di piccolezze che mi danno molto fastidio. Conosci qualche altro editor?
Grazie mille!
Approfitto dunque per farti un'ultima domanda: attualmente sto usando JDER come editor di diagrammi ER, è semplice e funzionale ma ha un paio di piccolezze che mi danno molto fastidio. Conosci qualche altro editor?
Grazie mille!
Ho sempre disegnato tali diagrammi a mano, non saprei quindi consigliarti.
io ho seguito un corso di basi di dati di soli 6 crediti, quindi non ho fatto molto, ma ho capito che i vincoli che non possono essere forzati a livello di schema vanno forzati con i trigger, quindi dovessi trovarmi in un futuro lavoro a progettare una base dati farei così.
Sbaglio?
Sbaglio?
E' importante capire che esistono delle differenze tra quella che è la teoria e quella che è la pratica. In linea di principio è vero, ma ci sono situazioni in cui forzare un particolare vincolo a livello di database potrebbe essere difficile o lento. Un database non è una entità che vive a se stante, ma qualcosa che va progettata tenendo sempre presente l'uso che se ne fa.
Ragazzi, ho di nuovo bisogno del vostro aiuto.
L'altra matassa che non riesco a dipanare è la seguente. Ho necessità di memorizzare l'esito dell'evento sportivo con i seguenti dati, fra gli altri:
- squadra1
- squadra2
- punti squadra1
- punti squadra2
- giocatori squadra1
- giocatori squadra2
- punti segnati da ogni giocatore
Ora, il punto è questo. Non esiste l'entità "squadra" quindi non ho una tabella con le squadre e le loro formazioni. Il concetto di squadra è puramente diciamo rappresentativo (anche se poi bisogna fare delle statistiche a riguardo, tipo la squadra che ha vinto più partite etc.), in quanto la formazione delle squadre viene decisa nel momento di svolgere le partite, come non esiste, di fatto, una tabella giocatori. Esistono utenti che si iscrivono ad un evento sportivo (che può essere di vario tipo) in qualità di giocatori (o arbitri). Quindi io ho la tabella degli utenti collegata alla tabella delle iscrizioni e quest'ultima è collegata alla tabella dell'evento sportivo, come ho detto più su.
Devo sicuramente avere una tabella EsitoEvento dove inserire le informazioni di cui sopra. Idealmente immaginando l'applicazione in funzione potrebbe funzionare così: l'utente premium che inserisce l'esito di un evento sportivo sceglie il nome delle due squadre e, scorrendo la lista degli utenti iscritti a quell'evento, li mette in una o nell'altra squadra, inserisce il punteggio delle due squadre, e poi dovrebbe inserire anche i punti segnati da ogni giocatore.
Non so come riportare tutto questo a livello di schema.
Grazie mille.
L'altra matassa che non riesco a dipanare è la seguente. Ho necessità di memorizzare l'esito dell'evento sportivo con i seguenti dati, fra gli altri:
- squadra1
- squadra2
- punti squadra1
- punti squadra2
- giocatori squadra1
- giocatori squadra2
- punti segnati da ogni giocatore
Ora, il punto è questo. Non esiste l'entità "squadra" quindi non ho una tabella con le squadre e le loro formazioni. Il concetto di squadra è puramente diciamo rappresentativo (anche se poi bisogna fare delle statistiche a riguardo, tipo la squadra che ha vinto più partite etc.), in quanto la formazione delle squadre viene decisa nel momento di svolgere le partite, come non esiste, di fatto, una tabella giocatori. Esistono utenti che si iscrivono ad un evento sportivo (che può essere di vario tipo) in qualità di giocatori (o arbitri). Quindi io ho la tabella degli utenti collegata alla tabella delle iscrizioni e quest'ultima è collegata alla tabella dell'evento sportivo, come ho detto più su.
Devo sicuramente avere una tabella EsitoEvento dove inserire le informazioni di cui sopra. Idealmente immaginando l'applicazione in funzione potrebbe funzionare così: l'utente premium che inserisce l'esito di un evento sportivo sceglie il nome delle due squadre e, scorrendo la lista degli utenti iscritti a quell'evento, li mette in una o nell'altra squadra, inserisce il punteggio delle due squadre, e poi dovrebbe inserire anche i punti segnati da ogni giocatore.
Non so come riportare tutto questo a livello di schema.
Grazie mille.
Sinceramente non ricordo bene come avevi definito il tuo schema e ora sono di fretta. Io creerei una entità partecipazione che associa un giocatore all'evento e due specializzazioni, una per gli arbitri e un'altra per i giocatori. I giocatori avranno a questo punto degli ulteriori relazioni con l'ha squadra a cui appartengono e i punti che hanno fatto. Penso che l'entità squadra sia da inserire e sarà definita da un nome e associata al particolare evento.
Questo è lo schema che ho fatto:
http://oi67.tinypic.com/34fbpjr.jpg
(non lo metto come immagine perché lo tronca)
Grazie...
http://oi67.tinypic.com/34fbpjr.jpg
(non lo metto come immagine perché lo tronca)
Grazie...
Nel frattempo ho modificato lo schema. Non mi convince al 100%, e va comunque ristrutturato, però mi sembra che riporti tutte le informazioni importanti. Che cosa ne pensate? Grazie.
http://oi63.tinypic.com/352jarn.jpg
http://oi63.tinypic.com/352jarn.jpg
Accedi a tutti gli appunti
Tutor AI: studia meglio e in meno tempo
