Gerarchia nel modello ER e OO

-1

Quindi, potrebbe essere una domanda molto fondamentale, ma in questo momento sono piuttosto confuso ...

Riguarda Element e ElementCategory: un elemento appartiene a una categoria, una categorizzazione può avere molti elementi: una relazione semplice a molte.

A livello di database, ho due tabelle:

Element(element_id, category_id, element_name)

Category(category_id, category_name)

A livello di applicazione (Java), avrei:

class Element { int id; String name; Category category; }

class Category { int id; String name; Collection elements; }

La mia domanda: ho avuto il giusto approccio, sia a livello di database che a livello di applicazione? Che tipo di relazione è quella in OOD? has-a, is-a, ereditarietà, relazione di generalizzazione o qualsiasi cosa ...

Grazie in anticipo per eventuali commenti e risposte costruttivi.

    
posta nogc 16.08.2017 - 23:36
fonte

2 risposte

0

Sono d'accordo con @ Samuel che le tabelle del tuo database sembrano corrette.

  • La relazione del database guardando dall'estremità dell'elemento è di uno a uno: un elemento deve avere una sola categoria.
  • La relazione del database guardando dalla fine della categoria è zero a molti. Una categoria può avere zero o molti elementi.

L'unica restrizione sull'aggiunta di nuovi record è che la categoria deve essere aggiunta prima di qualsiasi elemento presente in quella categoria.

Sul lato OOD / Java, le cose diventano un po 'più interessanti.

  • La tua classe Element va bene. Riflette la tabella del database sottostante. C'è una relazione ha una nella categoria. Qualunque buona ORM di Java la mapperà bene.
  • In generale, la classe Category non dovrebbe avere una collezione di Elements, poiché la performance ne risentirebbe. Se si consente all'OMM di compilare questa raccolta, il recupero di un singolo elemento per ID caricherà la singola categoria per quell'elemento e l'ORM caricherà quindi tutti gli elementi presenti in quella categoria per popolare la raccolta. Questo non è quasi sempre quello che vuoi. Ci sono soluzioni che implicano il caricamento lento, ma possono essere complicate da usare quando il livello di accesso al database si trova su un server remoto (ad esempio come in quasi tutte le app Web).
  • Se hai bisogno di cercare gli elementi per categoria, di solito è limitato a una singola categoria alla volta (ad esempio mostrami tutti i Lamborgini che abbiamo in magazzino), e spesso hai bisogno di una query SQL specialistica (es. Mostrami tutto il 2016 toyota rosso in magazzino). Per eseguire queste query in modo efficiente, il livello del servizio del database avrà bisogno di funzioni specialistiche che restituiscano una raccolta di elementi.

Quindi il mio consiglio è di rimuovere la raccolta di elementi dalla categoria e aggiungere query di database per gestire qualsiasi caso d'uso che deve cercare elementi per categoria. Nota che un buon ORM (MyBatis è il mio preferito) gestirà comunque il mapping dai risultati della query alla raccolta di Elements.

    
risposta data 15.03.2018 - 22:49
fonte
-1

Hai una dipendenza circolare tra Category e Element nel tuo codice. Significato Category dipende da Element e Element dipende da Category . Ciò potrebbe causare problemi nel tentativo di popolare questa struttura dal database:

1. Populate element A
2. Populate element A's category
3. Populate element A's category's elements (which includes A)
4. Populate element A's category's elements' categories
5. Populate element A's category's elements' categories' elements
etc.

Crea anche un'ambiguità su come dovresti aggiornare la categoria di un elemento. Dovresti cambiare Element.category , o dovresti aggiungere / rimuovere l'elemento da Category.elements ? Per evitare questo tipo di problemi dovresti rendere la relazione unidirezionale.

Le tue tabelle hanno una relazione unidirezionale e hanno un bell'aspetto. Per correggere i tuoi modelli di codice devi solo rimuovere elements da Category .

class Element { int id; String name; Category category; }

class Category { int id; String name; }
    
risposta data 16.08.2017 - 23:51
fonte