[sql] modello er e struttura database

[dogo21sob]

Ciao a tutti, devo realizzare un'applicazione per la gestione di una videoteca ed ho un dubbio riguardo la struttura del database.. in pratica ho disegnato il modello er ma traducendolo non mi trovo con quello che mi aspettavo.. mi spiego meglio..
nel modello er (tralasciando il resto dei dettagli, non rilevanti in questo caso) ho un'entità "FILM" e un entità "UTENTE" che identificano rispettivamente una copia di un film ed un utente registrato presso la videoteca. Tra queste 2 entità ci sono 2 associazioni, una "vendita" e un'altra "affitto".
L'associazione "affitto" tra "FILM" e "UTENTE" è del tipo "molti a molti" cioè ogni film può essere affittato a più utenti e ogni utente può affittare più film.
L'associazione "vendita" tra "FILM" e "UTENTE" è del tipo "molti a uno" cioè ogni film (ogni copia) può essere venduta a un solo utente ma ogni utente può acquistare più film.
Traducendo questo diagramma (per maggiore comprensione allego una bozza disegnata) in tabelle ottengo che, rispetto alle associazioni, l'associazione "affitto" essendo di tipo "molti a molti" viene tradotta creando una nuova tabella contenente le chiavi di "FILM" e "UTENTE" oltre agli attributi dell'associazione. E fin qui tutto bene.
L'associazione "vendita" però essendo di tipo "molti a uno" viene tradotta inserendo dal lato "molti" la chiave del lato "uno", quindi in pratica inserendo la chiave di "UTENTE" in "FILM".
E qui nascono i miei dubbi perchè mi aspettavo di avere una tabella "VENDITE" con il codice del film, il codice dell'utente, e la data di acquisto.
Seguendo le regole per la traduzione del modello er in scherma relazionale, per ottenere quello che voglio dovrei modificare nel modello er l'associazione "vendita" facendola diventare di tipo "molti a molti". Ma come giustificherei poi questa scelta? Che è concettualmente sbagliata visto che se una copia di un film è stata venduta ad un utente, non può essere venduta a un altro...

qualcuno ha mezza idea su come posso uscire da questa situazione?

p.s. non posso barare perchè assieme con l'applicazione e il database devo consegnare anche il modello er e giustificare le scelte fatte

[luca200]

Semplice, la vendita non è una relazione, ma un'entità.
Il fatto che tu le attribuisca un attributo (la data) lo dimostra

[luca200]

Starei attento su un altro punto: i film e le loro copie non sono la stessa cosa.
Un'analisi dettagliata dovrebbe prevedere l'entità "film", con i dati che la riguardano (produzione, regia, interpreti, distribuzione, anno ecc. ecc.) e l'entità "copie", relazionata n:1 con la precedente

[dogo21sob]

Originariamente inviato da luca200
Starei attento su un altro punto: i film e le loro copie non sono la stessa cosa.
Un'analisi dettagliata dovrebbe prevedere l'entità "film", con i dati che la riguardano (produzione, regia, interpreti, distribuzione, anno ecc. ecc.) e l'entità "copie", relazionata n:1 con la precedente

si questa cosa già l'ho pensata, ora qui ho scritto solo film -> utente per semplificare...

nel modello er è prevista la possibilità di inserire degli attributi alle associazioni, quindi il fatto che abbia un attributo non significa che per forza deve essere un'entità...
e comunque, secondo te, vendita e affitto dovrebbero essere entrambe entità? (in questo caso comunque entità deboli, in quanto le loro chiavi dipenderebbero dalle chiavi di "FILM" e "UTENTE", inoltre proprio concettualmente se non esiste il film o non esiste il cliente non può esistere nè l'affitto nè la vendita, quindi entità deboli)
casomai provo a ridisegnare il modello er mettendo vendita e affitto come entità deboli invece che associazioni e vediamo se poi mi trovo...

[luca200]

Guarda, il mio studio del modello er comincia ad essere un po' troppo datato, e questo, unito alla ruggine nella memoria, non è che sia di grande aiuto... il concetto di entità debole non me lo ricordo proprio