Etichettatura delle molteplicità nelle mappature delle tabelle di classi

2

Riprovare ma con un approccio leggermente diverso. Il mio thread precedente era qui Qualcuno può spiegare questo concetto one-to-one, one-to-many, many-to-one, many-to-many rispetto agli ORM? ma onestamente penso mi ha confuso più di quanto mi abbia aiutato, soprattutto quando sembrava che ci fossero opinioni contrastanti anche tra le risposte / i commentatori.

Non sono sicuro che la mia comprensione sia corretta e mi mancava solo il vocabolario per esprimerlo, o se ho un buco serio da qualche parte che deve essere risolto con un contro-esempio esplicito.

Quindi voglio provare di nuovo con un esempio più esplicito o due.

Esempio 1:

Diciamo che ho definito due classi in questo modo:

class A { 
    private String name;
    private List<B> listB;
}

class B {
    private String name;
}

Ora in questo esempio non ho detto nulla esplicitamente (in termini di annotazioni) sul fatto che le relazioni siano una ad una, una a molte in entrambe le direzioni, o molte a molte. Vado esclusivamente dalle cardinalità dei contenitori.

A mio parere, questa è una relazione uno a molti da A a B e l'ORM lo mapperebbe in questo modo:

Esempio2:

Diciamochehodefinitodueclassiinquestomodo:

classA{privateStringname;privateList<B>listB;}classB{privateStringname;privateAreferenceA;}

Suppongochequestofiniscaconlostessomappingditabelladell'Esempio1.

Esempio3:

Diciamochehodefinitodueclassiinquestomodo:

classA{privateStringname;privateList<B>listB;}classB{privateStringname;privateList<A>listA;}

Presumochequestasiaunarelazionemolti-a-moltieunORMlomapperebbeinquestomodo:

La mia domanda è se la mia comprensione sia corretta o meno e se questo tipo di approccio abbia o meno delle ambiguità (e quale esempio potrebbe sembrare).

    
posta The 29th Saltshaker 20.08.2016 - 20:10
fonte

2 risposte

1

Se un ORM dovesse generare una tabella dal codice che fornisci, sarebbero i diagrammi ER:

Per i codici 1 e 2:

Perilcodice3:

Ilcodicedovrebbeavereannotazionichediconoall'ORMchelerelazionisono1:Menon0:M.

LefreccerossesonostateaggiuntedamepermostrarecheillatoUNOdellarelazioneNONèobbligatorio,mentreneldiagrammacheforniscièobbligatorio,ilchenonèdeducibiledalcodicechefornisci.

Hibernate,unpopolare,ORMpotrebbeaverbisognodiaggiungereun'annotazionesimileaquestainclasseBperfarsaperechelarelazionedaBadAèobbligatoria(nonusoHibernate,quindichiunquesisentaliberodicorreggerlo):

@Column(name="a_id", unique = false, nullable = false)
private A referenceA;
    
risposta data 20.08.2016 - 23:42
fonte
1

Per gli esempi 1 e 2 sei quasi corretto. Alcuni commenti:

  • Nell'associazione di classe dell'esempio 1 puoi navigare solo da A a B, ma non indietro (in un diagramma di classe UML dovresti usare una freccia per la navigabilità)
  • L'associazione di classe dell'esempio 2 è bidirezionale: puoi sempre navigare da A a B e viceversa (in un diagramma di classe UML devi usare una linea che collega le classi e una freccia bidirezionale o nessuna freccia).
  • Nel modello relazionale, non hai questa sottile differenza perché le relazioni sono sempre bidirezionali in un RDBMS . Quindi in effetti non puoi rappresentare esattamente l'esempio 1. Sarai sempre nella situazione dell'esempio 2. L'unica differenza che potresti fare è che il tuo codice ORM non utilizzerà la navigazione bidirezionale.
  • La tabella per B non mappa completamente le tue classi: secondo il tuo modello di classe potresti avere una B autonoma non correlata ad una A. Non puoi memorizzare una realtà del genere nella tua tabella, a meno che
    • accetti che a_id possa essere nullo mantenendo il tuo modello di tabella.
    • o useresti 3 tabelle, potresti essere ancora più preciso e garantire un ordinamento sequenziale delle B come nella lista di un oggetto A: tabella A (id come chiave primaria, nome), tabella B (id come primaria chiave, nome) tabella AB (id_A e seqno chiave primaria, id_B chiave esterna + vincolo univoco). Questo modello sarebbe: Nota che questo presuppone che se tu avessi un oggetto B con l'etichetta "CIOCCOLATO" che apparirebbe in diversi As, ci sarebbero diverse istanze di "CIOCCOLATO" in B, ognuna con un ID diverso (perché stiamo rappresentando uno per molte relazioni, e non molte a molte relazioni).

Per l'esempio 3, il modello relazionale non rappresenta in modo accurato il modello di classe:

  • Ogni A ha una lista di Bs, e ogni B ha una lista di As, ma non vi è alcuna garanzia che questi siano coerenti (cioè reciproci). Ad esempio, potresti avere una A con una lista vuota, ma al contrario avere una B che usa questa A specifica nella sua lista. Ancora una volta la relazione può essere asimmetrica nel modello di classe, mentre è sempre simmetrica nel modello relazionale.
  • Ovviamente potresti decidere che un invariante del tuo modello di classe è che ogni volta che una B viene inserita nell'elenco in una A, questa A viene inserita reciprocamente nell'elenco B (e lo stesso per la rimozione). In questo caso il tuo modello sarebbe ok così com'è (eccetto se l'ordine in ogni elenco avrebbe importanza, dovresti quindi inserire alcuni numeri di sequenza).
  • Un'altra alternativa potrebbe essere quella di avere due tabelle A_B e B_A nel modello relazionale per rappresentare la situazione asimmetrica.

In tutto questo ho presupposto che il tuo esempio di classe fosse in java, in cui i riferimenti dell'oggetto sono memorizzati nell'elenco, in modo che possano essere condivisi tra più elenchi:

  • nell'Esempio 1 e 2 Supponevo che per costruzione non avresti condiviso gli oggetti. Se autorizzi la condivisione di B (ad esempio avendo un "CIOCCOLATO" e facendo riferimento ad esso in più elenchi), ti ritroverai in una relazione unidirezionale da molti a molti
  • sarebbe C ++, potresti rendere esplicito se condividi oggetti (usando la lista dei puntatori agli oggetti) o meno (usando la lista degli oggetti)
  • questo è il motivo per cui per la modellazione dei dati preferisco UML che è più espressivo della notazione Entità / Relazione: potresti rappresentare i vincoli di navigabilità e potresti distinguere l'aggregazione (ad esempio la condivisione di elementi / parti) dalla composizione (di proprietà elementi / parti non condivisi).
risposta data 20.08.2016 - 23:26
fonte

Leggi altre domande sui tag