Il database deve essere sempre mappato 1:1 nelle classi JAVA?

[American]

Salve, ho un enorme dubbio. Secondo quanto riferitomi da alcuni laureati in informatica (quindi persone che ne capiscono), le tabelle nel database dovrebbero corrispondere alle classi in java.
Tanto per fare un esempio, nel database ho la tabella articoli con le colonne id, nome_articolo, prezzo.
questo in java dovrebbe tradursi nella classe (o javabean che dir si voglia) articoli.java avente:

private int id;
private String nome_articolo;
private double prezzo;

//relativi metodi getter and setter 

eventuali chiavi esterne all'interno del database, nella classe java vengono tradotte in referenze ad istanze di altre classi.
Mettiamo ad esempio che nella tabella articoli aggiunga una colonna id_categoria.
Ovviamente si presuppone che nel DB abbia una tabella categorie formata dalle colonne ID e nome_categoria.

In java ovviamente andrei a creare un javabean Categoria e nel javabean Articoli.java andrei ad aggiungere quindi

Categoria catBean=new Categoria()
//metodi getter and setter 

fin qui tutto ok, è comodo e chiaro come sistema.
Faccio notare però che ciò funziona unicamente perchè si presuppone che ciascun articolo sia associato ad una sola categoria, tramite una relazione uno (articolo) a molti(categorie)
In altre parole, in articolo ho la referenza a categorie, ma lo stesso non accade per il contrario.

E qui nasce il mio dubbio, è concepibile aggiungere ulteriori parametri al javabean che non siano presenti nella struttura del DB, andando quindi a rompere la mappatura 1:1 ?
Tanto per fare un esempio, nel JB categorie vorrei aggiungere un ArrayList<Articolo> proprio per avere un riferimento, all'interno di categoria, ai molti articoli ad essa associati. Mettiamo che crei una query che, partendo da una categoria, mi prelevi tutti gli articoli corrispondenti, mi sarebbe più comodo e intuitivo utilizzare un unico javabean Categoria, con id, nome e l'arraylist degli articoli

[francesco.muia]

L'approccio che descrivi è secondo me assolutamente lecito, infatti se vai a vedere le specifiche JPA (Java Persistence Api) che sarebbe diciamo la "nuova" specifica di gestione delle persistenza dei dati in java avviene esattamente quanto descritto da te; cioè le relazione 1:N o N:N vengono "mappate" con le collection, di solito si usano i set per garantire l'unicità degli elementi all'interno, ma nessuno vieta di usare liste.

[American]

Si però io intendo proprio aggiungere una proprietà all'interno di una classe che non è presente nella tabella del DB.

Mettiamo che io abbia una situazione del genere (classico esempio del magazzino con prodotti e articoli per ordine)

datab.jpg

Se volessi rispettare la mappatura 1:1 del DB dovrei creare
classi Articolo, Spedizione, Ordine e ArticoloOrdinato

quest'ultima classe sarebbe così strutturata

private Ordine ordineBean=new Ordine();
private Articolo articoloBean=new Articolo(); 

Questo presuppone che dovrei utilizzare ArticoloOrdinato come classe principale, cioè "crocevia" di tutto. Per esempio, per ogni ordine prelevato devo creare un'istanza di ArticoloOrdinato e riempire i vari bean al suo interno. ArticoliOrdinati fungerebbe da fulcro per tutto.. Il che non mi piace!
Per quanto mi riguarda sarebbe invece più chiaro ragionare in termini di "Ordine" che contengono al loro interno più articoli (e quindi entrano in gioco le collection).
Ma per fare ciò dovrei aggiungere un parametro alla classe Ordini che nel DB ovviamente non esiste, e il parametro sarebbe:

ArrayList<ArticoloOrdinato>listaArticoli=new ArrayList(); 

Si potrebbe effettuare un'ulteriore rifinitura alla classe ArticoloOrdinato, ma per il momento mi fermo senò diventa troppo ingarbugliata la questione, anche perchè devo capire fino a che punto è contemplato questo non rispettare la mappatura del database

[francesco.muia]

Allora se la tua domanda è "Ogni tabella del database deve avere una rispettiva Classe Java ?"
La mia personale risposta è assolutamente no, in quanto un database è relazionale mentre Java è un linguaggio a oggetti e la cosa non è esattamente la stessa cosa.
Ti posso dire che JPA ti permette di gestire le cose in entrambe le maniere cioè avere una relazione dentro ordine che si riferisce ad articoli ordinati, o ancora meglio ti permette di "ignorare" la tabella di relazione e mettere all'interno di Ordine una lista di Articoli, poi si preoccuperà lui di aggiornare la tabella di relazione.

[American]

Allora se la tua domanda è "Ogni tabella del database deve avere una rispettiva Classe Java ?"

Si questo era il mio dubbio, cioè, qual era la convenzione normalmente utilizzata dato che la mappatura 1:1 non mi risulta comoda poi all'interno delle classi.
Quindi posso giostrarmi come mi pare, per me molto meglio la soluzione di mettere l'arraylist in Ordine.

Poi un'altra cosa che mi viene in mente è nel modello 1:1, ad esempio, la relazione che sussiste tra Spedizione e Ordine.
Io ho pensato che Ordine potrebbe estendere la classe Spedizione.
Stessa cosa per Articolo Ordinato. Questo infatti ha come parametro aggiuntivo unicamente la quantità, le informazioni "principali" dell'articolo sono stipate nel relativo bean.
A sto punto potrei fare direttamente:

class ArticoloOrdinato extends Articolo{
private int quantita;

} 

anziché

class ArticoloOrdinato{
private Articolo articoloBean=new Articolo();
private int quantita;

} 

[francesco.muia]

Ni....
Deve tener conto anche poi che cosa ci dovrai fare con queste classi.
Se il modello (con modello mi riferisco alla mappatura) ti serve solo in lettura allora potrebbe avere un senso farlo, ma se poi dovrai gestire anche la scrittura sul db, mantenendo le cose separate potresti modularizzare meglio la scrittura sul db.

[American]

Si mi serve anche in scrittura. Per esempio nel momento in cui viene effettuato l'ordine, creo l'istanza di Ordine (contenente ArrayList di Articoli) e passo tutto al relativo metodo della classe OrdineDaoImplementation che si occupa di creare la stringa di query in base ai dati forniti dall'istanza Ordine, e di effettuare l'execute della stessa.
Considera che ancora non uso JPA e non ho capito in che modo facilita la vita, quindi per il momento scrivo tutte le query manualmente.

Ora la maggior differenza tra l'usare o meno l'extends la riscontro proprio nel momento in cui vado a prelevare i dati da scrivere nel DB all'interno della OrdineDaoImplementation.

Se non estendo la classe allora mi ritroverei a fare una cosa del genere

public class effettuaOrdine(Ordine o)
{
...
//per prelevare l'id di un articolo dall'ArrayList dovrei fare: 
o.getListaArticoli.get(index).getArticoloBean().getId();
o.getListaArticoli.get(index).getArticoloBean().getNome();
o.getListaArticoli.get(index).getArticoloBean().getPrezzo();


...
} 

considerando che:
Ordine contiene l'ArrayList di ArticoloOrdinato (listaArticoli)
ArticoloOrdinato contiene a sua volta il riferimento ad un'istanza del bean Articolo (articoloBean)

applicando l'ereditarietà tramite l'extends, invece avrei valori meno "annidati" (risparmiando un passaggio)

public class effettuaOrdine(Ordine o)
{
...
//per prelevare l'id di un articolo dall'ArrayList dovrei fare: 
o.getListaArticoli.get(index).getId(); //come puoi vedere è scomparso getArticoloBean()
o.getListaArticoli.get(index).getNome();
o.getListaArticoli.get(index).getPrezzo();
...
} 

[francesco.muia]

Ed è li che ti volevo....
Suppongo che in DaoImplementation tu scriva tutte le query di insert/update di tutte le tabelle....
Questo a mio avviso è un errore progettuale in quanto ci dovrebbe essere + Dao che implementano "quasi" singolarmente l'insert ed update dei dati sulle tabelle. Il quasi è dato appunto dalle tabelle di relazione che se si vogliono omettere ovviamente qualche dao dovrà scrivere anche su queste tabelle.

[American]

No ho modificato il messaggio cambiando il nome della Dao
In pratica nel progetto vero e proprio ho interfaccie e relative implementazioni quasi per ogni tabella
Ad esempio, ho la iArticoloDao e l' ArticoloDaoImpl.
Ho l'iOrdineDao e l'OrdineDaoImpl
Ho l'iSpedizioneDao e i la SpedizioneDaoImpl
e così via.

Ciascuna di questa classi effettua operazioni di lettura e scrittura nelle relative tabelle

Il quasi è dato appunto dalle tabelle di relazione che se si vogliono omettere ovviamente qualche dao dovrà scrivere anche su queste tabelle.

Esatto, questo dipende appunto da come decido di strutturare le classi. Se nella classe Ordine metto l'ArrayList <ArticoloOrdinato> (andando quindi contro la mappatura 1:1 del DB), allora all'interno dell'iOrdineDao ci sarà un metodo addOrdine(Ordine o) che quando andrò ad implementare effettuerà tutte le operazioni necessarie, inclusa quella di memorizzare i dati nelle tabelle di relazione

Altrimenti dovrei creare un'interfaccia solo per le operazioni sulla tabella di relazione, ma dal momento che ho deciso che "ometterla" nel progetto java, conviene ometterla in tutti i sensi