Design della classe per entità JPA con più tabelle che fanno riferimento allo stesso oggetto business

Question

Design della classe per entità JPA con più tabelle che fanno riferimento allo stesso oggetto business

#1 da (1 voti)

1

Ho un'applicazione che funziona con prodotti provenienti da varie fonti di dati esterne (in DataSourceProduct) e mantiene anche la propria versione del prodotto (in MasterProduct). Ecco lo schema DB:

Nota:DataSourceProducthadiecialtrecolonnenonmostrateneldiagramma.IlMasterProducthadiecialtrecolonnenonmostrateneldiagramma.Adesempio,questecolonnehannolostessonomeinognitabella.chehannolostessonomemaperbrevitànonsonomostratineldiagramma.LecolonnecomuninonsitrovanonellatabellaProduct,masonopresentiinDataSourceProduct

Ognioriginedatiesternapuòfornirelapropriarappresentazionediundeterminatoprodotto.IlproductId(cioèProduct.id)èunIDgeneratoautomaticamente(incrementale)neldatabase.Èunachiavesurrogata.Unprodottodovrebbefareriferimentoa1&solo1prodottodelmondoreale.OgnioriginedatipuòavereipropridatisuquelprodottoeilDBdevecatturarlo.Supponiamodiavereunaportadiferro.SeèilprimoprodottoinseritonelDB,verràassegnatounIDprodotto1.Ora,l'originedatiApuòfornireunadescrizionedi"porta fine". La fonte di dati B può dare alla stessa porta di ferro una descrizione di "vecchia porta di ferro". Quindi, DataSourceProduct avrà 2 righe (1 riga per ogni origine dati). Entrambe le righe avranno productId = 1 in modo che possiamo sapere che entrambe le fonti di dati si riferiscono effettivamente allo stesso prodotto.

Sfortunatamente, non ci sono dati (come SKU) che possono determinare che un prodotto dall'origine dati A e dall'origine dati B si riferiscano allo stesso prodotto. Gli utenti mapperanno manualmente i prodotti come se fossero gli stessi. ProductId della tabella Product serve allo scopo di archiviare la mappatura utente (ad esempio, i prodotti di varie origini dati si riferiscono allo stesso prodotto).

L'applicazione deve anche avere una propria versione dei dati di prodotto che è memorizzata nella tabella MasterProduct. Differisce da DataSourceProduct perché

Deve conservare la cronologia delle modifiche dei dati a un prodotto
Deve conservare i dati del fornitore

Il prodotto dell'applicazione (ad esempio MasterProduct) verrà utilizzato estesamente in tutta l'applicazione mentre il prodotto dell'origine dati esterna (ovvero DataSourceProduct) viene utilizzato solo in una piccola parte dell'applicazione.

Come dovrei progettare le entità JPA corrispondenti? Le tre tabelle che rappresentano i prodotti possono (?) Avere un senso da una prospettiva DB. In OOP, tuttavia, sembra che esista una relazione di ereditarietà.

object-oriented java object-oriented-design database-design jpa

posta James 26.04.2017 - 20:43

fonte

1 risposta

Leggi altre domande sui tag object-oriented java object-oriented-design database-design jpa

Qual è il modo più efficace per rappresentare una matrice di adiacenza ridimensionabile Livello dati Astrazione dal livello aziendale per la ricerca

score 1 · Answer 1

Penso che la tua confusione derivi dalla generale mancanza di utilità della tabella Product, poiché contiene un ID e nient'altro.

Tuttavia non è un grosso problema. Quando definisco le entità JPA, inizierei con la tabella Prodotti e definirò ciascuno degli oggetti figlio come classi separate. Quindi includi quelli nella classe Product:

@Entity
@Table(name = "PRODUCT")
public class Product {

   @Id
   @Column(name = "id")
   private long id;

   @OneToMany(mappedBy="product")
   List<DataSourceProduct> dataSourceProducts;

   @OneToMany(mappedBy="product")
   List<MasterProduct> masterProducts;
}

Ciascuno di questi prodotti secondari verrebbe definito con la relazione inversa @ManyToOne con la tabella Product.

Come citi nei commenti, potresti rinominarli e magari spostarti su alcune proprietà, ma penso che questa struttura dovrebbe essere un buon punto di partenza.