Sto disegnando un diagramma di classe e voglio sapere qual è la notazione corretta per molte e molte relazioni tra fornitore e prodotto?
Devo mostrare la tabella fornitore_prodotto o lasciarlo fuori e avere la relazione molti a molti tra fornitore e prodotto?
Ho visto varie rappresentazioni online.
"Sto disegnando un diagramma classe ... Devo mostrare la tabella creata fornitore_prodotto?"
La relazione molti-a-molti fa parte del tuo design di classe. La tabella di join non è; è creato per inciso dal framework di mappatura OR. Includi la relazione. Non includere la tabella o qualsiasi altro artefatto generato.
Dipende dal business. Sulla nostra attività è possibile ottenere lo stesso pezzo di ricambio da più fornitori e ognuno ha il proprio codice articolo interno. Quindi abbiamo il nostro master per articolo prodotto che contiene il nostro codice con i dati relativi.
Poi c'è la tabella principale del fornitore con i fornitori.
Finalmente esiste una tabella di riferimenti incrociati in cui si associa un articolo a un fornitore e si fornisce la descrizione e il codice articolo del fornitore.
Quindi suppongo che nel nostro caso sia una relazione molte a molte ....
La tua domanda è buona perché stai pensando se hai bisogno di questo tavolo o meno. Ciò dimostra che ti interessa la qualità del tuo design.
La parte notazione ha ricevuto risposta completa da altri, quindi mi concentrerò maggiormente sull'altra parte.
Should I show the table created supplier_product or leave it out and have the relationship many to many between supplier and product?
Devi trovare la risposta non solo dal punto di vista tecnico ma anche dal punto di vista del business. Ad esempio, devi fare una domanda come questa:
Devo sapere quando un fornitore ha iniziato a fornire un prodotto alla società?
Il prezzo di un elemento fornito è indicativo al tempo o alla quantità fornita?
Esiste una quantità minima che un fornitore deve fornire per ordine di cui abbiamo bisogno di sapere?
Ci sarebbero associazioni tra supplier_product in altre classi nel modello?
Se la tua azienda non ha proprietà interessanti da inserire nella tabella delle intersezioni e non ci sono associazioni richieste (come nelle domande precedenti) e Se stai facendo il diagramma delle classi come parte del design di alto livello da una prospettiva OO, potrebbe fare come @Kenvin Cline suggerisce e non includere la classe nella versione attuale del modello.
Se si desidera essere precisi e chiari e / o Se si intende implementare il progetto in questa fase in un database relazionale, sia tu stesso che l'applicazione che userai per creare (forward engineer) la DLL dovrà occuparsi con la classe mancante che rappresenta la relazione molti-a-molti. Alcuni strumenti potrebbero creare automaticamente una chiave primaria e FK e vincoli RI (a scelta dello strumento) e nominare tutto ciò in un modo che potresti accettare o meno. Inoltre, il tuo mappatore ORM dovrà creare il codice per gestire questa tabella nascosta .
L'effetto del RI è fondamentale e dovrebbe essere sempre controllato e controllato. È necessario determinare con precisione cosa succede alle informazioni sugli articoli forniti quando un fornitore viene cancellato da un database.
Se stavi progettando un database fisico, ti suggerirei sicuramente di arricchire il tuo progetto e non lasciare che gli strumenti lo facciano per te, a meno che tu non abbia completamente familiarità con come e quali strumenti verranno creati per te.
Leggi altre domande sui tag uml class-diagram