alice84 ha scritto:
Un archivio. Perché non vanno bene le tabelle?
Per semplificare la comprensione, analiziamo la sola Tabella Libri, in cui ci si aspetta siano inseriti i Libri... ovvero che il libro sia l'elemento UNIVOCO in questa Tabella.... invece:
Libri (ID_Autore - Autore - Titolo - Editore ...)
Questa che hai esposto contiene 2 ERRORI grandissimi, che esplicitano il fatto tu non conosca la normalizzazione o strutturazione NORMALE di un Database Relazionale.
1° ERRORE, assenza della PK
Le tabelle, in un sistema Relazionale, devono avere una Chiave primaria(si chiama PK) legata all'oggetto della Tabella... Libri(PK=IdLibro, semplifichiamola come un Campo di tipo AutoIncrementante o Counter).
2° ERRORE
Hai una Chiave Esterna(chiamata FK) relativa all'autore ed anche il Nome dell'autore...?
Quindi serve:
- una Tabella Anagrafica con gli Autori che conterrà (IdAutore, Nome, Cognome, Nazionalità)
- una Tabella Case Editrici (IdCasaEditrice, Nome, ecc...)
- una Tabella Responsabili
- una Tabella Genere (IdGenere, Genere)
- una Tabella Categorie (IdCategoria, Categoria)
- una Tabella Libri (IdLibro, Titolo, ISBN10, ISBN13, IdAutore, IdCasaEditrice, IdGenere,IdCategoria, Ristampa, NomeCollana ecc... se ci sono altri campi selezionabili)
I codici ISBN di suo sarebbero già delle Possibili chiavi PK, ma probabilmente se avete libri ante l'entrata in uso... ovviamente sarebbe un problema e non sempre si trova il vecchio SBM di natività Inglese dal 67)...
- una Tabella che collega Libri ad Editori nel caso in cui un Libro possa averne + di uno, si definisce Molti a Molti
- una Tabella che collega Libri ed Autori, stessa cosa di cui sopra se un Libro ha più Autori... Molti a Molti
- una Tabella che collega Libri a Responsabili... nel caso in cui non vi sia solo 1 Responsabile
ecc...
Prova a riflettere meglio sulle esigenze, ma se non hai qualche elemento teorico con cui fare questo processo... farai molta fatica.