Originariamente inviato da Pepito74
si scusa, non lo avevo scritto ma per ogni autore possono esserci più libri, così come per ogni libro possono esserci più autori...
se le cose stanno come dici allora ti servono le tre tabelle oppure, ma da valutare per bene, due tabelle autori/libri dove in libri metterai piu' campi autore (autore1, autore2, autore3) ma e' una cosa che non mi piace granche'.

Avevo fatto tempo fa un database per una biblioteca comprensivo della gestione libri in prestito, ma se ben ricordo di tabelle per gestire i titoli ne avevo una sola. ISBN, titolo autore/i, casa editrice, prezzo, stato e quant'altro identificativo. Ho sempre considerato queste cose come attributi del "libro".

Poi c'era una tabella utenti con i dati identificativi dell'utente e una tabella prestiti dove associavo l'utente al libro con le date di presa e di consegna ed altre cosette gestionali.

Quindi penso a quanto chiedi come ad una cosa esclusivamente didattica. Forse l'ho gia' detto, ma un database va strutturato come progetto per quello che dovra' servire, con le richieste del cliente, il budget a disposizione e non tanto per scrivere tabelle/campi. Una tabella "autori" e' valida se per ogni autore hai una sua bibliografia, lavori ecc... informazioni che non avrebbe senso duplicare per ogni libro. Ma se ti limiti a nome-cognome tanto vale che lo scrivi con il libro.

una query SELECT su tabelle multiple in relazione uno a molti tramite tabella di unione va scritta in questo modo:

select *
from tabella unione
left join autori using(id_autore)
left join libri using(id_libro)
where ... condizione ecc.ecc.