[DATABASE] Domandina urgente circa cardinalità di una relazione

[D4rkAng3l]

Originariamente inviato da gugoXX

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


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

Ok, ti ringrazio...e invece per quanto riguarda le relazioni di feedback? nel disegno dello schema relazionale le posso lasciare così come nell'ER visto che sono ternarie? (sistemando quella storia della cardinalità di cui si parlava prima).

[gugoXX]

Originariamente inviato da D4rkAng3l

Ok, ti ringrazio...e invece per quanto riguarda le relazioni di feedback? nel disegno dello schema relazionale le posso lasciare così come nell'ER visto che sono ternarie? (sistemando quella storia della cardinalità di cui si parlava prima).

Direi di si'.
Non penso che il professore analizzi a sufficienza il tuo modello tanto da chiederti perche' nel feedback hai messo in chiave sia oggetto che destinatario.

Penso che tu stia commettendo un altro errore, forse.
Quale e' la chiave primaria della tabella Vende?

[D4rkAng3l]

Originariamente inviato da gugoXX

Direi di si'.
Non penso che il professore analizzi a sufficienza il tuo modello tanto da chiederti perche' nel feedback hai messo in chiave sia oggetto che destinatario.

Penso che tu stia commettendo un altro errore, forse.
Quale e' la chiave primaria della tabella Vende?

Intendi dire se per feedback devo riportare pari pari quello che ho nell'ER.

Cmq la chiave di VENDE per me è USER_ID di UTENTE e ID_OGGETTO di INSERZIONE.

Mi dovrebbe identificare in maniera univoca e mi dovrebbe collegare senza problemi le due entità in quanto ogni volta che un utente vende un oggetto questo viene inserito in INSERZIONE la cui chiave sarà un id numerico di tipo auto increment. E un utente non potrà mai vendere 2 volte lo stesso oggetto.

[gugoXX]

Originariamente inviato da D4rkAng3l

Intendi dire se per feedback devo riportare pari pari quello che ho nell'ER.

Cmq la chiave di VENDE per me è USER_ID di UTENTE e ID_OGGETTO di INSERZIONE.

Mi dovrebbe identificare in maniera univoca e mi dovrebbe collegare senza problemi le due entità in quanto ogni volta che un utente vende un oggetto questo viene inserito in INSERZIONE la cui chiave sarà un id numerico di tipo auto increment. E un utente non potrà mai vendere 2 volte lo stesso oggetto.

Hai fatto un pezzo di ragionamento. Hai impedito che nella tabella ci sia piu' di una volta la coppia UtenteA,Oggetto2
Ma quello che vorrei passarti e' che la chiave primaria di Vende, secondo me dovrebbe essere solamente Oggetto.
Un oggetto e' messo in relazione con un utente una volta sola, pertanto ogni Oggetto non dovrebbe comparire MAI piu' di una volta in quella tabella.
Ed e' questo il motivo per cui in fase di modellazione si potrebbe tranquillamente fondere questa tabella all'interno della tabella oggetto.
Perche' dovrebbero avere fisicamente la stessa chiave primaria.
La relazione verso l'utente ovviamente ci sarebbe, ma non identificativa.
L'utente non dovrebbe essere messo in chiave, pur avendo una chiave straniera verso la tabella degli utenti.
Sono riuscito a spiegarmi? Non sei d'accordo?

La vera schematizzazione, che se guardi ho sbagliato anche io nel veloce disegno che ho fatto, e' che la linea tra utente e vende dovrebbe essere tratteggiata.

Comunque direi che va bene per la feedback ternaria.
A questo punto lascia anche la Vende binaria altrimenti il professore potrebbe mangiare la foglia.

[D4rkAng3l]

Ciao,
rieccomi quà a rompere le scatole.
Visto che la relazione VENDE è una relazione di tipo UNO A MOLTI, dici che è meglio eliminarla ed inserire la chiave di UTENTE (USER_ID) dentro l'entità INSERZIONE, così eliminerei una tabella e cmq avrei il vincolo di integrità referenziale che punta da INSERZIONE ad UTENTE.

Invece l'altra cosa importante è la relazione VENDITA, altra relazione uno a molti. Tale relazione in pratica serve a contenere le vendite effettuate e lega un utente del sistema con il prodotto da lui acquistato.
Dal momento che la cardinalità minima dell'entità INSERZIONE che entra in gioco in questa relazione è 0 (in quanto su quel braccio la cardinalità è (0, 1)...credo di averlo dimenticato nell'ER postato) allora potrei anche mantenere una tabella VENDITA nello schema relazionale. che ne dici?

[D4rkAng3l]

mmm ancora un altro dubbio (ho quasi finito ).

Per le due relazioni feedback che voglio mantenere come relazioni...che chiavi metto? Avevo pensato che potrei impostare come chiave anche il solo ID_OGGETTO...secondo te potrebbe andare? (senza mettere in chiave l'ID dell'utente venditore e dell'acquirente...che magari metto come campi normali perchè credo che l'IDE_OGGETTO sia più che sufficiente ad identificarmi in maniera univoca una riga).

Grazie
Andrea

[gugoXX]

Originariamente inviato da D4rkAng3l

Ciao,
rieccomi quà a rompere le scatole.
Visto che la relazione VENDE è una relazione di tipo UNO A MOLTI, dici che è meglio eliminarla ed inserire la chiave di UTENTE (USER_ID) dentro l'entità INSERZIONE, così eliminerei una tabella e cmq avrei il vincolo di integrità referenziale che punta da INSERZIONE ad UTENTE.

Perfetto. Campo di una foreign key, che ovviamente non sara' in chiave nella tabella INSERZIONE. (relazione non identificativa).

Invece l'altra cosa importante è la relazione VENDITA, altra relazione uno a molti. Tale relazione in pratica serve a contenere le vendite effettuate e lega un utente del sistema con il prodotto da lui acquistato.
Dal momento che la cardinalità minima dell'entità INSERZIONE che entra in gioco in questa relazione è 0 (in quanto su quel braccio la cardinalità è (0, 1)...credo di averlo dimenticato nell'ER postato) allora potrei anche mantenere una tabella VENDITA nello schema relazionale. che ne dici?

Va bene.

VENDITA, con chiave (Oggetto, Acquirente) (Forse sarebbe meglio chiamarla ACQUISTI)
Attributi: data,...

Non e' necessario mettere il Venditore, perche', come gia' detto, e' univocamente definito dall'oggetto.

[gugoXX]

Originariamente inviato da D4rkAng3l

mmm ancora un altro dubbio (ho quasi finito ).

Per le due relazioni feedback che voglio mantenere come relazioni...che chiavi metto? Avevo pensato che potrei impostare come chiave anche il solo ID_OGGETTO...secondo te potrebbe andare? (senza mettere in chiave l'ID dell'utente venditore e dell'acquirente...che magari metto come campi normali perchè credo che l'IDE_OGGETTO sia più che sufficiente ad identificarmi in maniera univoca una riga).

Grazie
Andrea

Esatto. Se conti di modellare uno e un solo FEEDBack per ciascuna inserzione, allora ID_OGGETTO e' sufficiente, con relazione di integrita' verso la tabella inserzione.

La relazione verso l'acquirente non e' identificativa, non e' necessario metterla in chiave.

Anche qui, essendo il venditore univocamente definito dall'oggetto, sarebbe superfluo metterlo in uno schema normalizzato. Se lo metti non e' un errore (denormalizzazione parziale) ma non lo metterei appunto in chiave.

[D4rkAng3l]

Ok ti rignrazio troppo...

Ora manca solo l'ultima relazione da tadurre: SUBCAT.

Si tratta di una relazione ricorsiva tra l'entità CATEGORIA e se stessa. Praticamente dice quando una categoria è sottocategoria di un'altra.

E' di tipo uno a molti in quanto una categoria può avere minimo 0 sottocategorie e massimo n e viceversa una sottocategoria può avere una ed una sola sola categoria padre.

Adesso mi sorge un dubbio, passando allo schema relazionale è meglio mantenere una relazione SUBCAT che conterrà coppie, (ID_PADRE, ID_FIGLIA) che dicono chi è il padre di chi.

Oppure potrei fare un accorpamento PADRE-FIGLIA ed inserire un campo PADRE dentro CATEGORIA che dice qual'è il padre di quella categoria e se la categoria in questione non ha padre (in quanto categoria principale) allora avrà un NULL (che a mio avviso non è troppo carino).

Io tenderei a mantenere una relazione SUBCAT che mi contiene le varie coppie per evitare il fatto dei valori NULL...te che mi dici?

Poi dopo di questa cosa ho finito di tradurre lo schema ER in relazionale
Grazie

Andrea

[gugoXX]

Normalmente per casi come quello si usa una tabella sola.

Tassonomia:
ID_tassonomia, chiave
Descrizione, stringa
ID_tassonomia_padre, FK alla tabella stessa, non obbligatorio

E' il pattern che serve per modellare quello che in teoria dei grafi e' una FORESTA, ovvero un insieme di ALBERI.
I nodi radice di ciascun albero sarebbero per te le "MacroCategorie", che non hanno padre.
Ciascuno dei figli invece e' collegato al proprio padre, mediante il campo ID_tassonomia_padre.

Applicativamente occorrera' poi sviluppare delle QUERY ricorsive per navigare la foresta, ma quasi tutti i motori di Database seri hanno il supporto per le query ricorsive.
PS: Una foresta si puo' ridurre ad un albero unico, con un unico nodo padre.
Ma tale padre non avrebbe comunque un padre, pertanto resta lo stesso il vincolo di non obbligatorieta' della foreign key autoreferenziale.

Tale relazione, ovvero foreign key non referenziale e pure non obbligatorie, si modella nel grafico ER con una linea tratteggiata, e con un pallino vuoto vicino al campo di partenza (che sarebbe ID_TASSONOMIA_PADRE di questo esempio)

Ma poi basta, senno' Cionci dice il voto lo danno a me.

[D4rkAng3l]

Originariamente inviato da gugoXX

Normalmente per casi come quello si usa una tabella sola.

Tassonomia:
ID_tassonomia, chiave
Descrizione, stringa
ID_tassonomia_padre, FK alla tabella stessa, non obbligatorio

E' il pattern che serve per modellare quello che in teoria dei grafi e' una FORESTA, ovvero un insieme di ALBERI.
I nodi radice di ciascun albero sarebbero per te le "MacroCategorie", che non hanno padre.
Ciascuno dei figli invece e' collegato al proprio padre, mediante il campo ID_tassonomia_padre.

Applicativamente occorrera' poi sviluppare delle QUERY ricorsive per navigare la foresta, ma quasi tutti i motori di Database seri hanno il supporto per le query ricorsive.
PS: Una foresta si puo' ridurre ad un albero unico, con un unico nodo padre.
Ma tale padre non avrebbe comunque un padre, pertanto resta lo stesso il vincolo di non obbligatorieta' della foreign key autoreferenziale.

Tale relazione, ovvero foreign key non referenziale e pure non obbligatorie, si modella nel grafico ER con una linea tratteggiata, e con un pallino vuoto vicino al campo di partenza (che sarebbe ID_TASSONOMIA_PADRE di questo esempio)

Ma poi basta, senno' Cionci dice il voto lo danno a me.

mmm la mia proff ODIA A MORTE le query ricorsive...ha minacciato bocciatura se ne vede anche una sola...che fare?

[gugoXX]

Originariamente inviato da D4rkAng3l

mmm la mia proff ODIA A MORTE le query ricorsive...ha minacciato bocciatura se ne vede anche una sola...che fare?

Fallo come l'hai fatto tu.
Non sembra ricorsiva, ma lo e' lo stesso. Ma magari non se ne accorge.

Sia nella singola tabella autoreferenziante che nel tuo disegno a 2 tabelle, per risolvere una domanda come:
"DATO un nodo della foresta, trovare quale e' il suo ANCESTOR"
che da te sarebbe
"Dato una qualsiasi categoria, trovare a quale MACRO Categoria appartiene"

Occorre comunque fare una query ricorsiva.
E non penso neppure che le abbiate fatte, perche' sono delle brutte bestie.

[D4rkAng3l]

Originariamente inviato da gugoXX

Fallo come l'hai fatto tu.
Non sembra ricorsiva, ma lo e' lo stesso. Ma magari non se ne accorge.

Sia nella singola tabella autoreferenziante che nel tuo disegno a 2 tabelle, per risolvere una domanda come:
"DATO un nodo della foresta, trovare quale e' il suo ANCESTOR"
che da te sarebbe
"Dato una qualsiasi categoria, trovare a quale MACRO Categoria appartiene"

Occorre comunque fare una query ricorsiva.
E non penso neppure che le abbiate fatte, perche' sono delle brutte bestie.

ma se invece lo facessi usando una tabella sola come hai detto te e poi per le query invece di fare query ricorsive usassi la strategia degli alias per "duplicare" la tabella con un altro nome?

[gugoXX]

Originariamente inviato da D4rkAng3l

ma se invece lo facessi usando una tabella sola come hai detto te e poi per le query invece di fare query ricorsive usassi la strategia degli alias per "duplicare" la tabella con un altro nome?

Ho intuito cosa stai dicendo.
Stai proponendo di fare delle query autoreferenzianti, nelle quali piazzi piu' volte la stessa tabella in join con se stessa.
Penso che non possa farlo "a priori" nel tuo modello, perche' dovresti sapere quante volte piazzare la tabella in JOIN con se stessa, che dipende dal livello di profondita' di ciascun nodo.
Poiche' dipende dal livello di profondita', essendo il livello variabile per ciascun nodo, secondo me non riesci a fare un'unica query generale che possa funzionare a priori indipendentemente dal nodo che cerchi.
Forse con delle OUTER JOIN, ma mi sa che non viene molto bella da farsi e da leggersi.

Tutto dipende da cosa devi farci con quella tabella.
A parte scriverci dentro, come la leggi? Cosa viene pubblicato di quella tabella?
Se il tuo "sito" mostra una navigazione ad un livello solo, ovvero fa vedere di volta in volta tutti gli oggetti venduti che appartengono alla categoria corrente, e ti propone la navigazione verso il padre (se esiste) e verso uno qualsiasi dei suoi figli diretti (se esistono), allora non ti servono le query ricorsive. Te la cavi con 2 query normali.
In tal caso una tabella come la soluzione da me proposta, oppure 2 tabelle come la tua, vanno entrambe bene.

[D4rkAng3l]

mmm mi sà che ho capito cosa intendi...praticamente te stai dicendo che facendo query di questo tipo usando gli alias potrei fare una query del tipo: "Dimmi tutte le categorie figlie della categoria "FOTOGRAFIA"".

Però usando questa strategia potrei dire quali sono le figlie dirette e non le figlie delle figlie, etcetc....intendi questo?

mmm e se mi tengo la relazione SUBCAT dici che è una porcata?

Grazie
Andrea

[gugoXX]

Originariamente inviato da D4rkAng3l

mmm mi sà che ho capito cosa intendi...praticamente te stai dicendo che facendo query di questo tipo usando gli alias potrei fare una query del tipo: "Dimmi tutte le categorie figlie della categoria "FOTOGRAFIA"".

Il problema e' esattamente questo, ma sto dicendo che usando gli "alias" e non le query ricorsive, a quella domanda non riesci a rispondere facilmente, se non addiruttura impossibile.
ES: Se sul tuo sito volessi mostrare tutte gli oggetti venduti da una categoria e conteporaneamente anche da tutte le sue categorie figlie, nipoti, etc... allora dico che senza le query ricorsive non ne esci. Prova a chiedere alla tua Professoressa, alle quali non piacciono, come risolverebbe questo problema, che modello e che query farebbe.
Se la risposta fosse "Lancio una query che mi da tutti i figli, e per ciascuno di questi rilancio poi la stessa query", allora e' un altro modo per fare "male" una query ricorsiva

Però usando questa strategia potrei dire quali sono le figlie dirette e non le figlie delle figlie, etcetc....intendi questo?

Esatto.

mmm e se mi tengo la relazione SUBCAT dici che è una porcata?

No, non e' necessaria ma non e' una porcata.

[D4rkAng3l]

vabbuò...vado a pappare e spero che il pranzo mi porti anche saggezza Ti rin grazio tantissimo ;-)

[D4rkAng3l]

Quindi ricapitolando te accorperesti la relazione SUBCAT dentro CATEGORIA e metteresti il campo Padre dentro CATEGORIA così da sapere per ogni record (quindi per ogni categoria) chi è la categoria padre di quel record per qvere una cosa del genere


ID_CATEGORIA, NOME_CAT, DESCRIZIONE PADRE

001, HOBBY, blablabla, NULL
006, FOTOGRAFIA, blablabla, 001

Intendevi questo?

Grazie
Andrea

[gugoXX]

Originariamente inviato da D4rkAng3l

Quindi ricapitolando te accorperesti la relazione SUBCAT dentro CATEGORIA e metteresti il campo Padre dentro CATEGORIA così da sapere per ogni record (quindi per ogni categoria) chi è la categoria padre di quel record per qvere una cosa del genere


ID_CATEGORIA, NOME_CAT, DESCRIZIONE PADRE

001, HOBBY, blablabla, NULL
006, FOTOGRAFIA, blablabla, 001

Intendevi questo?

Grazie
Andrea

Beh, senza la descrizione padre in tabella pero', che non e' normalizzata.

001, Hobby, null
002, Fotografia, 001
003, Bricolage, 001
004, Informatica, null
005, Hardware,004
006, Software,004
007, Canon, 002
008, Konika, 002
etc.

Puoi sapere subito tutto dei figli diretti di 002
SELECT * FROM tabella WHERE padre=002


E puoi sapere tutto del padre
SELECT * FROM tabella
WHERE ID = (SELECT padre FROM tabella WHERE ID=002)

oppure se non vi hanno spiegato le inner query lo fai con la INNER JOIN

SELECT tab1.*
FROM tabella AS tab1 JOIN tabella AS tab2
ON (tab1.ID=tab2.padre)
WHERE tab2.ID=002

[D4rkAng3l]

mmm no Descrizione è solo un campo di Categoria e non è legato al Padre (forse mi son mangiato una virgola).

Nel senso se il titolo della categoria è: "Fotografia" la sua descrizione sarà un campo testuale che ne sò qualcosa del tipo: "Inserzioni relative alla fotografia: macchine fotografiche, flash e attrezzatura fotografica di vario genere".

Ho appena finito di tradurre lo schema relazionale.
Dici che è decente qualcosa del genere? (Le chiavi sono con la pallina rossa, i campi con le palline nere). Dove le relazioni sono state eliminate aggiungendo un campo ad un'entità che punta ad un'altra entità ho messo la freccia. Dove non le ho eliminate ho lasciato la relazione con relative cardinalità che di fatto nello schema relazionale è una tabella.



Grazie
Andrea