[Basi di dati] Dilemmi sul modello ER

[EveyH]

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 )

[apatriarca]

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.

[EveyH]

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...

[apatriarca]

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.

[EveyH]

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

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!

[apatriarca]

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.

[EveyH]

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!

[apatriarca]

Ho sempre disegnato tali diagrammi a mano, non saprei quindi consigliarti.

[insideworld]

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?

[apatriarca]

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.