WinstonSmith ha scritto:
In caso di relazione N:M bisogna creare una terza tabella con PK della prima entity e PK della seconda
Sì, esatto.
WinstonSmith ha scritto:
ma in java dovrò creare la classe di questa tabella con attributi le due pk?
No, la tabella di "relazione" con le due PK
non la si rappresenta a livello di oggetti.
WinstonSmith ha scritto:
In caso di relazione 1:N bisogna inserire la PK della entity 1 nella tabella della entity 2 e fungerà da chiave esterna, quindi nella classe della entity2 dovrò dichiarare la Pk dell'altra entity, giusto?
In una relazione uno-a-molti, la
foreign key ovvero la chiave che punta verso un'altra tabella sta
sempre dalla parte del "molti". Un caso "classico" (ma se ne possono fare molti altri): "clienti" e "ordini". Nella tabella ORDINI ci va il Id del Cliente che è la
foreign key verso il record in CLIENTI. Appunto perché 1 cliente può avere N ordini, come nell'esempio sotto dove il singolo cliente Luca Bianchi ha 3 ordini.
CLIENTI ORDINI
+------------+--------------+ +-----------+------------+---- - -
| ID_CLIENTE | NOMINATIVO | | ID_ORDINE | ID_CLIENTE | .......
| (PK) | | | (PK) | (FK) |
+------------+--------------+ +-----------+------------+---- - -
| 103 | Mario Rossi | | 1010 | 103 | .......
| 105 | Luca Bianchi | | 1011 | 105 | .......
+--\---------+--------------+ | 1012 | 105 | .......
\ | 1013 | 105 | .......
\ +-----------+--/---------+---- - -
\________________________________________/
WinstonSmith ha scritto:
devo creare una tabella Carrello per ogni utente registrato oppure una sola tabella
Una sola tabella ... è di nuovo anche qui una relazione uno-a-molti: 1 utente ha N prodotti in carrello.
WinstonSmith ha scritto:
E soprattutto, la query come va scritta visto che la pk dell'acquirente sarà un id classico, come associo l'id cliente al prodotto?
Esattamente come si farebbe per i clienti-ordini visti sopra: avendo il ID_CLIENTE, si fa una query su ORDINI per estrarre tutti gli ordini che hanno quel ID_CLIENTE.