[DATABASE] Domandina urgente circa cardinalità di una relazione

[D4rkAng3l]

Ciao,
per il progetto dell'esame di base di dati mi trovo a dover realizzare il DB di un piccolo sistema di aste online (una versione della baia molto semplificata).

Considerando queste due entità:

UTENTE: che rappresenta gli utenti iscritti al sistema e vendono o comprano oggetti

INSERZIONE: rappresenta gli oggetti messi in vendita dagli utenti.

Poi ho una relazione chiamata VENDE che lega insieme UTENTE e INSERZIONE (in pratica associa alcuni utenti ai prodotti che vendono).

In UTENTE ci saranno sia utenti venditori che utenti acquirenti.

Volendo gestire i feedback che gli acquirenti danno ai venditori circa il loro comportamento durante la vendita di un particolare oggetto (in pratica l'utente acquirente può dire al termine della vendita se il venditore siè comportato in maniera corretta, scorretta o neutra).

La relazione FEEDBACK_VENDITORE coinvolgerà: UTENTE, UTENTE (in maniera ricorsiva) e INSERZIONE.

In pratica un utente acquirente dà un feedback ad un utente venditore in relazione ad una ed una sola determinata inserzione.

Per quanto riguarda la cardinalità secondo voi va bene così?

1) Sul braccio che và da UTENTE a FEEDBACK imposto (0, n) perchè un utente acquirente può lasciare minimo 0 feedback (non ha ancora comprato nulla) e massimo n feedback (ha comprato più oggetti).

2) Sul braccio da FEEDBACK ad UTENTE imposto sempre (0, n) in quanto un utente venditore può aver ricevuto minimo 0 feedback (ancora non ha venduto alcun prodotto oppure il prodotto non è ancora stato ricevuto dall'acquirente che non ha ancora rilasciato il feedback) e massimo n (perchè potrebbe aver venduto n oggetti)

3) sul braccio da FEEDBACK ad INSERZIONE imposto (1,1) in quanto un feedback è riferito ad una ed una sola inserzione messa in vendita.

Per rendere più chiaro allego immagine, nello schema allegato la situazione è un po'più complessa perchè gestisco sia i feedback che gli acquirenti danno ai venditori mediante una relazione, sia il viceversa...ma alla fine il discorso non cambia.



Per favore ditemi se va bene...ho pochissimo tempo

[gugoXX]

Originariamente inviato da D4rkAng3l

3) sul braccio da FEEDBACK ad INSERZIONE imposto (1,1) in quanto un feedback è riferito ad una ed una sola inserzione messa in vendita.

Per favore ditemi se va bene...ho pochissimo tempo

E' sbagliato.
Per motivi analoghi ai precedenti, potrebbe non esistere Feedback per un'inserzione... almeno fino a che non e' stata venduta.

[D4rkAng3l]

Originariamente inviato da gugoXX

E' sbagliato.
Per motivi analoghi ai precedenti, potrebbe non esistere Feedback per un'inserzione... almeno fino a che non e' stata venduta.

mm forse mi sono espresso male, i dati verranno messi nella "tabella feedback" solamente dopo che l'utente ha ricevuto il pacco dal venditore e gli ha dato una valutazione e l'utente non potrà fare altri acquisti sul sistema finchè non metterà darà il feedback al venditore.

Te come lo faresti?

Grazie
Andrea

[gugoXX]

No, quella e' giusta, avevo scritto prima che pubblicassi il disegno.

Pero' non so bene per le 3 in alto.
Quando avevo studiato il la semantica del modello ER, per quanto riguarda le relazioni, la chiave primaria (che sia fisica, che sia logica poco importa) si poteva dedurre direttamente dalle entita' che vi insistevano.
Tu dovrai per forza mettere almeno il tempo nella chiave primaria (fisica o logica, non importa ripeto).
Non ve l'hanno fatta mai modellare l'entita' tempo?

Quando l'avevo studiata io era una tabella tratteggiata, che puntava a tutte le relazioni in cui il tempo serviva.
Tratteggiata perche' poteva essere creata veramente, oppure poteva essere alla fine usato semplicemente un campo di tipo DATA, il cui tipo e' presente in tutti i Database.
Nel tuo caso appunto commento, vendita e offerta, le cui PK dovrebbero contenere appunto il tempo in chiave.

Come dire, il "tempo" in quelle 3 tabelle e' ben diverso dal "tempo" della tabella inserzione, o della tabella Feedback, che li' sarebbero usati come attributo.(Istante di pubblicazione, Istante dell'inserzione, etc.)

[gugoXX]

A parte il tratteggio della tabella Tempo, intendo una cosa del genere



Se noti la data ogni tanto va a finire sopra, ovvero tra i campi identificativi in questo modello (chiave), ogni tanto va a finire sotto, solo come attributo.
Da te, indipendentemente dalla soluzione grafica, l'ho visto sempre solo "sotto", ovvero tra gli attributi non identificativi.
Coem dire di nuovo, la DATA/ORA di un commento e' ben diversa dalla DATA/ORA di nascita dell'utente.

[D4rkAng3l]

quindi secondo te è giusto così?

[gugoXX]

Boh? Dipende da cosa vi hanno spiegato.
Ve l'hanno spiegata la differenza tra "Relazione identificativa" e "Relazione non identificativa"?
Ovvero, campo di una tabella che punta ad un altra (foreign key) e che partecipa anche alla chiave primaria della tabella stessa (Relazione identificativa)
oppure campo di una tabella che punta ad un altra (foreign key) ma che NON partecipa anche alla chiave primaria della tabella stessa (Relazione non identificativa) perche' e' solo un attributo?
(Come per esempio la mia inserizione nella tabella Messaggio. L'insezione non e' identificativa, perche' per identificare univocamente un messaggio e' sufficiente la terna (UtenteA, UtenteB, istante ))

[D4rkAng3l]

Originariamente inviato da gugoXX

Boh? Dipende da cosa vi hanno spiegato.
Ve l'hanno spiegata la differenza tra "Relazione identificativa" e "Relazione non identificativa"?
Ovvero, campo di una tabella che punta ad un altra (foreign key) e che partecipa anche alla chiave primaria della tabella stessa (Relazione identificativa)
oppure campo di una tabella che punta ad un altra (foreign key) ma che NON partecipa anche alla chiave primaria della tabella stessa (Relazione non identificativa) perche' e' solo un attributo?
(Come per esempio la mia inserizione nella tabella Messaggio. L'insezione non e' identificativa, perche' per identificare univocamente un messaggio e' sufficiente la terna (UtenteA, UtenteB, istante ))

si le abbiamo viste ma sinceramente non mi và di stravolgere il lavoro che ho già fatto in quanto ho solo due giorni per tradurlo in schema relazionale, metterlo su MySql, inserire i dati, fare 20 query e produrre una relazione...quindi magari non è la soluzione migliore di tutte ma francamente adesso come adessomi basta che non sia clamorosamente sbagliata...già non ho la certezza di finire in tempo...se mi metto a fare modifiche strutturali sull'ER ho la certezza di non finire in tempo

[gugoXX]

Capisco.
A questo punto fai bene attenzione alle chiavi primarie delle tabelle e ai vincoli di unicita'.
Come dire, la tua tabella di relazione "Vende", puo' essere costruita come una tabella in cui la PK e' formata dalle PK delle entita' a cui punta (Utente, Inserzione)
mentre la tua tabella di relazione "Messaggio", NON puo' essere costruita come una tabella la cui PK e' l'insieme delle PK delle tabelle entita' a cui punta (Mittente, Destinatario, Inserzione) altrimenti vincoleresti un utente a mandare un solo messaggio per ogni inserzione.

[D4rkAng3l]

Originariamente inviato da gugoXX

Capisco.
A questo punto fai bene attenzione alle chiavi primarie delle tabelle e ai vincoli di unicita'.
Come dire, la tua tabella di relazione "Vende", puo' essere costruita come una tabella in cui la PK e' formata dalle PK delle entita' a cui punta (Utente, Inserzione)
mentre la tua tabella di relazione "Messaggio", NON puo' essere costruita come una tabella la cui PK e' l'insieme delle PK delle tabelle entita' a cui punta (Mittente, Destinatario, Inserzione) altrimenti vincoleresti un utente a mandare un solo messaggio per ogni inserzione.

no lo sò, la tabella messaggio in fase di ristrutturazione avrà come chiave un campo id_messaggio e la cosa sarà motivata nella documentazione.

[gugoXX]

Originariamente inviato da D4rkAng3l

no lo sò, la tabella messaggio in fase di ristrutturazione avrà come chiave un campo id_messaggio e la cosa sarà motivata nella documentazione.

Ecco, io e' questa cosa della ristrutturazione che non capisco.
Il modello ER dovrebbe essere autoesplicativo. Il progettista di DB disegna il modello ER, poi lo passa ad un operatore (che potrebbe anche essere una macchina), che senza tanta intelligenza lo trasforma in istruzioni SQL per creare il Database.
Vabbe', se cosi' vi hanno insegnato fai pure...

[D4rkAng3l]

Originariamente inviato da gugoXX

Ecco, io e' questa cosa della ristrutturazione che non capisco.
Il modello ER dovrebbe essere autoesplicativo. Il progettista di DB disegna il modello ER, poi lo passa ad un operatore (che potrebbe anche essere una macchina), che senza tanta intelligenza lo trasforma in istruzioni SQL per creare il Database.
Vabbe', se cosi' vi hanno insegnato fai pure...

Beh oddio, mo non vorrei sembrare superbo perchè sono un pivellino, però sull'Atzeni c'è tutto il capitolo 8 che è dedicato alla ristrutturazione di schemi ER e da quello che dice lo schema ER è solo una visione d'insieme di cosa contiene il DB e di come queste cose sono messe in relazione tra loro....poi prima di trasformare l'ER in tabelle bisogna anzitutto fare un'analisi del carico e del costo delle operazioni quindi ristrutturarlo in base alle operazioni che vengono eseguite con più frequenza per rendere il DB più performante e anche normalizzato...poi si passa al disegno dello schema relazionale...e quest'ultimo allora potrebbe essere passato ad un'operatore che potrebbe anche essere un software che lo trasforma in SQL...

[gugoXX]

Come vuoi.
Magari quello che hai fatto e' una prima fase, e magari vi hanno richiseto solo quella, ma prima o poi si deve passare allo schema ER rigoroso.

P.ES. Io prendo il mio ER, disegnato cosi' com'e' e lo passo all'automa che mi genera questo.
E va gia' bene cosi' senza altri passaggi. Se ho usato bene le PK, e le FK mancano solo i campi, ma la struttura e' funzionale.

CREATE TABLE Tempo (
Time DATE NOT NULL,
PRIMARY KEY (Time)
);


CREATE TABLE Inserzione (
PKInserzione INTEGER NOT NULL,
Scadenza DATE NULL,
PRIMARY KEY (PKInserzione),
FOREIGN KEY (Scadenza)
REFERENCES Tempo
);


CREATE TABLE Utente (
PKUtente INTEGER NOT NULL,
PRIMARY KEY (PKUtente)
);


CREATE TABLE Vendita (
PKUtente INTEGER NOT NULL,
PKInserzione INTEGER NOT NULL,
Time DATE NOT NULL,
PRIMARY KEY (PKUtente, PKInserzione, Time),
FOREIGN KEY (Time)
REFERENCES Tempo,
FOREIGN KEY (PKInserzione)
REFERENCES Inserzione,
FOREIGN KEY (PKUtente)
REFERENCES Utente
);


CREATE TABLE Vende (
PKUtente INTEGER NOT NULL,
PKInserzione INTEGER NOT NULL,
IstanteDiInserzione DATE NULL,
PRIMARY KEY (PKUtente, PKInserzione),
FOREIGN KEY (IstanteDiInserzione)
REFERENCES Tempo,
FOREIGN KEY (PKInserzione)
REFERENCES Inserzione,
FOREIGN KEY (PKUtente)
REFERENCES Utente
);


CREATE TABLE Offerta (
PKUtente INTEGER NOT NULL,
PKInserzione INTEGER NOT NULL,
Time DATE NOT NULL,
PRIMARY KEY (PKUtente, PKInserzione, Time),
FOREIGN KEY (Time)
REFERENCES Tempo,
FOREIGN KEY (PKInserzione)
REFERENCES Inserzione,
FOREIGN KEY (PKUtente)
REFERENCES Utente
);


CREATE TABLE Messaggio (
Mittente INTEGER NOT NULL,
Destinatario INTEGER NOT NULL,
Time DATE NOT NULL,
PKInserzione INTEGER NULL,
PRIMARY KEY (Mittente, Destinatario, Time),
FOREIGN KEY (PKInserzione)
REFERENCES Inserzione,
FOREIGN KEY (Time)
REFERENCES Tempo,
FOREIGN KEY (Destinatario)
REFERENCES Utente,
FOREIGN KEY (Mittente)
REFERENCES Utente
);


CREATE TABLE Commento (
PKUtente INTEGER NOT NULL,
PKInserzione INTEGER NOT NULL,
Time DATE NOT NULL,
PRIMARY KEY (PKUtente, PKInserzione, Time),
FOREIGN KEY (Time)
REFERENCES Tempo,
FOREIGN KEY (PKInserzione)
REFERENCES Inserzione,
FOREIGN KEY (PKUtente)
REFERENCES Utente
);

[gugoXX]

Una cosa pero' non ho capito.
Perche' dici che p.es la relazione "Feedback Acquirente" - "Inserzione" e' (1:1)
e non una (0:1)

Ovvero, se la risposta e' "Perche' penso di inserire il feedback in un secondo tempo, e quindi quando il feedback esistera' allora esistera' anche l'inserzione", allora perche' la relazione "Feedback Acquirente" - "Venditore" e' una (0:N) e non (1:N)
?

[D4rkAng3l]

Perchè nelle specifiche del sistema prevedo che il feedback è obbligatorio, l'acquirente una volta ricevuto il pacco e controllata la merce dovrà obbligatoriamente rilasciare il feedback al venditore.

[gugoXX]

Originariamente inviato da D4rkAng3l

Perchè nelle specifiche del sistema prevedo che il feedback è obbligatorio, l'acquirente una volta ricevuto il pacco e controllata la merce dovrà obbligatoriamente rilasciare il feedback al venditore.

OK, avevo capito, ma quello che non mi convince e' che tu possa scrivere (1:1) per quella relazione. Mi sembra piu' un vincolo applicativo, mi sembra una forzatura metterla sul modello del database.
Se lasci 1:1 significa che per qualsiasi inserzione DEVE esserci un feedback, sempre. Anche per quelle non ancora vendute.
Ma e' lana caprina, non penso che il professore si impunti.

[D4rkAng3l]

Originariamente inviato da gugoXX

OK, avevo capito, ma quello che non mi convince e' che tu possa scrivere (1:1) per quella relazione. Mi sembra piu' un vincolo applicativo, mi sembra una forzatura metterla sul modello del database.
Se lasci 1:1 significa che per qualsiasi inserzione DEVE esserci un feedback, sempre. Anche per quelle non ancora vendute.
Ma e' lana caprina, non penso che il professore si impunti.

e se mettessi (0, 1) a significare che al massimo posso avere un feedback per un oggetto venduto?

[gugoXX]

Secondo me e' piu' giusto.

[D4rkAng3l]

Lo sò che a te questa cosa non garba molto però come ti ho detto non ho proprio il tempo materiale per cambiare l'impostazione del tutto...voglio solo verbalizzare qualsiasi cosa mi metta...

Allora sono in fase di passaggio da schema ER a schema relazionale normalizzato...le relazioni ternarie presenti nelmio ER nel disegno dello schema relazionale le devo lasciare come nell'ER, giusto? (ovviamente inserendo le chiavi)

Per le relazioni dei feedback la chiave sarà banalmente l'USER_ID dell'acquirente, del venditore e l'ID_OGGETTO dell'oggetto in questione.

Per i messaggi invece che posso mandarne più di uno come fare? Per te qual'è migliore tra queste due soluzioni:

1) Imposto semplicemente un ID_MESSAGGIO per ogni messaggio (usando l'auto increment), quindi ci sarà un numeretto che mi identifica ogni messaggio

2) Se usassi solo USER_ID del mittente, USER_ID del destinatario, ID_OGGETTO non basterebbe perchè potrei mandare più messaggi relativi ad un'oggetto...potrei inserire nella chiave anche la data e l'orario ma così avrei una chiave formata da 4 campi e non mi pare un gran che carino....

Per te qual'è la strategia più decente?

Grazie
Andrea

[gugoXX]

Intendiamoci, non e' che non mi piaccia il modello.
Secondo me hai trovato entita' e relazioni corrette.

Originariamente inviato da D4rkAng3l

1) Imposto semplicemente un ID_MESSAGGIO per ogni messaggio (usando l'auto increment), quindi ci sarà un numeretto che mi identifica ogni messaggio
2) Se usassi solo USER_ID del mittente, USER_ID del destinatario, ID_OGGETTO non basterebbe perchè potrei mandare più messaggi relativi ad un'oggetto...potrei inserire nella chiave anche la data e l'orario ma così avrei una chiave formata da 4 campi e non mi pare un gran che carino....

Propenderi per la prima, ma non perche' 4 campi in chiave nella seconda siano troppi, ma piuttosto perche' quei 4 non sono identificative.
2 sarebbero sufficienti:
Potrei modellare il fatto che ogni oggetto non possa ricevere piu' di un messaggio nello stesso istante. (Oggetto, Data)
Oppure sempre con 2:
Ogni utente puo' spedire un solo messaggio alla volta (Mittente, Data)
Oppure con 3:
Ogni utente puo' spedire un solo messaggio alla volta, riferito ad un singolo oggetto. Puo' pero' mandare piu' messaggi contemporaneamente, purche' riferiti ad oggetti diversi. (Mittente, Data, Oggetto)
Oppure sempre con 3:
Ogni utente puo' spedire un solo messaggio alla volta, per un altro utente. Puo' pero' mandare piu' messaggi contemporaneamente, purche' ad utenti diversi. (Mittente, Data, Destinatario)

Sono tutte modellazioni fisiche valide, ma con 4 anche a me sembra eccessivo se non errato.
L'errore starebbe nel considerare la variabilita' tra oggetto e destinatario, cosa che nel tuo modello non c'e'.
Per ciascun oggetto c'e' un solo destinatario. Metterli insieme in chiave in una qualsiasi tabella che non sia quella della loro relazione diretta (vende) non ha senso.
Non appena mi dici l'oggetto, so direttamente chi lo vende, non c'e' ambiguita'. Non c'e' necessita' di metterli entrambi insieme in una qualche chiave.

Quindi, se adotti la prima soluzione avrai meno cose da spiegare o giustificare...
Speriamo al professore non venga in mente di chiederti quindi piu' spiegazioni sulla chiave del feedback, per esempio.
Penso che tu stia facendo l'errore che se hai una relazione, allora il campo deve per forza essere in chiave nella tabella figlia.
Non e' cosi'. Esistono appunto le relazioni non identificative (le linee tratteggiate).

Tanto per essere onesti: Quando avevo passato l'esame di basi di dati, io personalmente non l'avevo capito.