Database biblioteca

[davhub]

Ciao a tutti, un piccolo OT per menti maniacali del controllo come la mia (almeno in potenza visto che poi sono un casinista totale.. )

Sto mettendo mano ad un "piccolo" progetto con il DATABASE di openoffice: una bella base dati della mia biblioteca personale e di famiglia.

Piccolo si fa per dire.. dopo i primi scozzi per vedere come funziona l'inserimento dei dati, lo sviluppo dei record, ecc. mi sto arenando di fronte a problemi concettuali.

perché ci sono campi la cui definizione calza a pennello per un libro, meno per una rivista, affatto per un fumetto seriale (e tutti rientrano nella mia biblioteca, pari titolo) e se poi volessi aggiungere CD e DVD... ciao a tutti...

In rete ci sono un sacco di programmi o programmi web che offrono servizi (tra cui, ed i mac user saranno felici, un certo booxter che è fantastico)...
ma vorrei strutturare il database da solo.

idee sui campi da utilizzare e su come strutturare le cose?

Personalmente mi viene in mente che:

LIBRI:
ID-Autore 1-Autore 2-Titolo-Casa editrice (Nome e luogo)-Anno di edizione-ISBN code-Genere-genere specifico-Commento-Posizione in libreria

RIVISTE:
ID-Titolo-Casa editrice (Nome e luogo)-Anno di edizione-ISBN code-Genere-Posizione in libreria

FUMETTI:
ID-Titolo-Casa editrice (Nome e luogo)-Anno di edizione-ISBN code-Genere-Saga contenuta-Posizione in libreria

Possa essere indicato come una prima traccia.

Nei libri il genere secondario è dovuto al fatto che prima cerco i saggi, ad esempio e poi raffino la ricerca con i saggi di astronomia o epistemologia.

Così i fumetti... cerco la saga di fenice nera? bene so che la troverò su X-men star comics XYZ...

Che ne dite? potrebbe funzionare?

passo successivo, ovviamente, capire come relazionare i campi.

se è libro mi si devono aprire alcune scelte ed inserimenti, se invece è rivista, altri. e così con il sottogenere.

Idee su come si possa fare?

Grazie in anticipo

[htsoft]

Ciao,
ho sviluppato anni fa un programma di archiviazione per una casa editrice e ti posso garantire che non è facile accomunare generi così diversi.
Il primo consiglio è (te lo dico da DBA): abbandona il database di OO.
Si lo so è carino, ti permette di fare le maschere e tutto quanto. Ma è instabile, lento ed il database tende a corrompersi (soprattutto gli indici, sembra di avere tra le mani Access 97 bacato).

Per poterti dare qualche suggerimento ho bisogno di sapere alcune cose:
1) Quanto ne sai di programmazione?
2) Quali linguaggi di programmazione conosci?
3) Sai (realmente) cos'è un database relazionale?

La risposta a queste tre domande mi permetterà di darti una via da seguire (tieni presente che per lavoro sviluppo applicativi web bancari con interfaccia verso DB Oracle, MS SQL Server, SyBase, MySQL e DB2/400 tutto contemporaneamente).

[davhub]

Il mitico htsoft.. quello con il curriculum database più palluto del forum (a quanto sappia, eh, non me ne vogliano gli altri.. )

allora... purtroppo il ricorso a OO è perché, purtroppo, lo devo imparare meglio di quanto lo conosca.
(motivi che non riporto).

Avrà qualche baco, ma pace. mi era sembrato che un esercizio del genere poteva essere una buona cosa
per imparare un ò come funziona il tutto sia teoricamente, sia operativamente.

Programmazione... ne so un pochino scrissi i miei programmi in Pascal all'università, quanche render di POVRay con scenari ricorsivi, basic alle elementari.
ma non scrivo più da un decennio e sono un pò fritto cerebralmente. questa è una cosa a cui non posso dedicare molto e quindi non posso studiare e applicarmi come se studiassi.

Ho bisogno di curve di apprendimento veloci e soddisfazioni immediate o quasi.

Database relazionale, conosco un pò claudicantemente la teoria, e so che le relazioni tra elementi sono le chiavi di tutto. ma sono proprio un newbie.

comunque mi sa che un saltino in libreria lo farò...

Grazie del tuo interessamento!!!

Davhub

[htsoft]

Bene, visto il tuo grado penso che la cosa migliore sia procedere con il metodo per esempi.

Partiamo dalla struttura del DATABASE:
In un database relazionale il concetto che sta alla base di tutto è la normalizzazione. Con questo termine non si intende l'inizio di una terapia presso uno psicologo, ma più semplicemente la semplificazione di un database.

Per semplificazione si intende la necessità di ridurre le informazioni ripetute all'interno delle tabelle che costituiscono il tuo database.
Ad esempio il nome di una persona scritto nello stesso identico modo in 2 o più tabelle crea problemi in quanto nel momento in cui dovrai aggiornare il nome della persona dovrai sincerarti che tutte le tabelle che lo riportano siano modificate.
Pertanto se devi aggiornare cinque tabelle dovrai assicurarti che tutte e cinque le tabelle siano aggiornate ed in caso di errore vengano tutte riportate allo stato precedente la modifica. (Logica transazionale).
Il metodo più semplice per operare in questo caso è il seguente. Riportare l'informazione mutevole in una tabella ed associarla ad un'informazione immutabile e quindi riportare l'informazione immutabile in tutte le tabelle che fanno riferimento all'informazione mutevole in modo da modificare un unico record di un'unica tabella. Questa informazione si chiama normalizzazione. Per reperire velocemente tale informazione nelle tabelle che la usano si crea una relazione che risolve, detto in modo maccheronico, automaticamente il collegamento tra l'informazione mutevole e quella immutevole.
Detto in modo diretto al nome viene associato un codice ed il codice (non modificabile) viene riportato in tutte le tabelle che fanno riferimento al nome.

Venendo al tuo problema vediamo di definire il tuo database partendo dalle tabelle di dominio (ovvero quelle che subiscono meno modifiche o in alcuni casi non ne subiscono affatto).

Tabella 1:
Generi
CODICE (INTERO AUTOINCREMENTANTE)
DESCRIZIONE (STRINGA)
Tutti e due i campi sono obbligatori (non nulli) in più il codice (e solo lui) è chiave primaria.
Sulla descrizione vi è un indice secondario ordinato in modo ascendente.

Tabella 2:
Categorie autori (Utile se si parla di autore delle storie o disegnatore).
CODICE (INTERO AUTOINCREMENTANTE)
DESCRIZIONE (STRINGA)
Tutti e due i campi sono obbligatori (non nulli) in più il codice (e solo lui) è chiave primaria.
Sulla descrizione vi è un indice secondario ordinato in modo ascendente.

Tabella 2:
Case Editrici
CODICE (INTERO AUTOINCREMENTANTE)
RAGIONE SOCIALE (STRINGA)
ALTRE INFORMAZIONI OPPORTUNE (INDIRIZZO, SITO WEB, EMAIL, ECC. ECC)
Lo schema della chiave primaria e dell'indice secondario è come sopra.

Tabella 3:
Autore
CODICE (INTERO AUTOINCREMENTALE)
NOMINATIVO (STRINGA)
ALTRE INFORMAZIONI OPPORTUNE
Chiave primaria e indice secondario come sopra

[davhub]

O maremma.

Bene, visto il tuo grado penso che la cosa migliore sia procedere con il metodo per esempi.

Partiamo dalla struttura del DATABASE:
In un database relazionale il concetto che sta alla base di tutto è la normalizzazione. Con questo termine non si intende l'inizio di una terapia presso uno psicologo, ma più semplicemente la semplificazione di un database.

Per semplificazione si intende la necessità di ridurre le informazioni ripetute all'interno delle tabelle che costituiscono il tuo database.
Ad esempio il nome di una persona scritto nello stesso identico modo in 2 o più tabelle crea problemi in quanto nel momento in cui dovrai aggiornare il nome della persona dovrai sincerarti che tutte le tabelle che lo riportano siano modificate.
Pertanto se devi aggiornare cinque tabelle dovrai assicurarti che tutte e cinque le tabelle siano aggiornate ed in caso di errore vengano tutte riportate allo stato precedente la modifica. (Logica transazionale).

Perfetto. nulla da dire se non che lo sforzo di semplificazione e normalizzazione deve sempre esserci. il database è una struttura per platonizzatori e quindi riduttivisti ed è questa ottica che gli dà praticità a scapito della "potenza" globale.

Il metodo più semplice per operare in questo caso è il seguente. Riportare l'informazione mutevole in una tabella ed associarla ad un'informazione immutabile e quindi riportare l'informazione immutabile in tutte le tabelle che fanno riferimento all'informazione mutevole in modo da modificare un unico record di un'unica tabella. Questa informazione si chiama normalizzazione. Per reperire velocemente tale informazione nelle tabelle che la usano si crea una relazione che risolve, detto in modo maccheronico, automaticamente il collegamento tra l'informazione mutevole e quella immutevole.
Detto in modo diretto al nome viene associato un codice ed il codice (non modificabile) viene riportato in tutte le tabelle che fanno riferimento al nome.

guarda.. se non fosse che poi lo devo interrogare e quindi trovare e far trovare ad altri (mia moglie, io stesso ecc.), direi che basta utilizzare un bel foglio di calcolo di CALC/EXCEL ed il gioco è fatto. Un bell'= e tutto si risolve.
peccato che poi.. poi manchino N funzioni.

Venendo al tuo problema vediamo di definire il tuo database partendo dalle tabelle di dominio (ovvero quelle che subiscono meno modifiche o in alcuni casi non ne subiscono affatto). ....

tolto dalla quota

OK incomincio a capire meglio... al posto di realizzare TUTTE le voci in una singola tabella (come farei in un foglio di calcolo), il database funziona ad un livello superiore.
ciascuna tabella contiene un argomento che, concettualmente, diventa esso stesso chiave primaria.
poi ci sarà una "mastertabella" se non erro si chiamano formulari, vero?
in cui saranno effettivamente posti a contatto visivo e quindi di utilizzo tutti i campi generati da ciascuna tabella e su cui potrò interrogare.

Nel modo in cui lo intendevo avevo solo una chiave primaria e quindi sarebbe stato in seguito impossibile, sospetto, trovare i libri di genere saggio essendo la chiave primaria chessò, l'ID del libro.

adesso, quindi una domanda operativa:
apro un nuovo database, e creo tante tabelle tanti sono gli argomenti che mi interessa compongano il formulario.
poi apro un formulario ed inserisco le tabelle.

La domanda è: le informazioni che riempiranno le schede dei formulari (i record nel linguaggio database / celle in quello del foglio di calcolo) dove saranno registrate?

grazie per i tuoi scorci di "scienza"...

Davhub

[htsoft]

Ora veniamo alla parte interessante ovvero i libri, riviste, DVD.

In questo caso l'utilità sta nel creare una tabella avente come campi quelli comuni a tutti i media. E poi creare delle "sottotabelle" che richiami in base al media selezionato.
Questo approccio ti permette quanto segue:
1) Se ti servono solo i campi comuni non sei costretto a riempire i campi extra
2) Non hai per ogni record una sfilza di campi inutilizzati
3) Se aggiungi un'informazione per un media specifico non la aggiungi per tutti i record ma solo per quelli del tipo specifico
4) Se l'informazione ti serve per tutti la aggiungi nella tabella Master
5) La flessibilità della struttura ti permette di aggiungere un nuovo media semplicemente aggiungendo una nuova tabella (ed i moduli di interfaccia ad esso legati).
6) Segui comunque la normalizzazione del database

Ecco pertanto una tabella per gli "ARTICOLI"
MEDIA
CODICE (INTERO AUTOINCREMENTALE)
TITOLO (STRINGA)
EDITORE (INTERO AUTOINCREMENTALE)
SUPPORTO (INTERO CHE TRASFORMI IN UN RADIOBUTTON)
POSIZIONE
ANNO PUBBLICAZIONE
EDIZIONE

Chiave primaria il codice
Indice secondario il titolo

Come puoi vedere ho omesso l'autore (non è una dimenticanza).
Questo perchè iniziamo a creare le tabelle di relazione.
Prima pero parliamo dell'editore e del supporto, ma anche del genere.

Il genere l'ho omesso in quanto credo vada relegato in una tabella secondaria (a meno che tu non preveda la stessa struttura a generi per tutti i titoli), ad esempio per la musica puoi usare un unico genere mentre per i libri ne puoi usare due o tre.
Potendo però sfruttare le relazioni io eviterei di creare troppi livelli nei generi e cercherei di servirmi dei mezzi messi a disposizione dal linguaggi di query per poter effettuare le ricerche, questo perchè, normalizzando, la possibilità di incorrere in errori di scrittura si riduce di molto.
Per il supporto c'è una cosa fondamentale da dire, la rappresentazione interna di un dato non necessariamente corrisponde a quella esterna (o per l'utente). In genere il tuo obbiettivo dev'essere quello di ridurre l'uso di dati non atomici al minimo ed in particolare le stringhe ed i blob dovresti usarli solo quando l'informazione non può essere memorizzata in altro modo. Questo per due motivi. I motori SQL sono più veloci se lavorano su dati atomici e tali dati sono soggetti a minor incidenza di errore quando inseirti dall'utente.
Poi che tu all'utente mostri un radiobutton dove al DVD corrisponde il numero 1 questo è relegato al codice di gestione.
Il tipo atomico per eccellenza in un DB è l'intero, possibilmente della lunghezza della parola della macchina. Il booleano non esiste (neanche nello standard SQL '92) e pertanto non sei certo della sua rappresentazione (in genere un intero dove zero è false e tutto ciò che è diverso da zero è true e quindi non è un bit), e se un giorno decidi di cambiare RDBMS potresti trovare a mal partito.

Ora veniamo agli autori.
Spesso, ma non sempre, abbiamo che per ogni singolo "volume" vi è un solo autore. Ma sappiamo che ciò non sempre è detto, spesso di autori ve ne sono due, ma anche di più.
Ecco quindi che prevedere un numero determinato di campi da attribuire agli autori è errato.
Questo perchè non si rispetta la normalizzazione in quanto:
1) Se l'autore è uno solo si spreca lo spazio dei campi non adoperati.
2) Se il numero di autori è superiore al numero di campi a disposizione si perdono informazioni importanti
Occorre quindi una struttura dati che sia in grado di allungarsi ed accorciarsi in base alle propre esigenze.
Nel caso dei database si parla di tabelle associative.

La tabella associativa degli autori è pertanto questa:
AUTORIPERVOLUMI
CODICE VOLUME (INTERO AUTOINCREMENTALE)
CODICE AUTORE (INTERO AUTOINCREMENTALE)
CODICE CATEGORIA AUTORE (INTERO AUTOINCREMENTALE)

La chiave primaria è:
CODICE VOLUME + CODICE AUTORE
Non vi sono indici secondari.
Nel caso però tu voglia poter prevedere il caso in cui vuoi inserire due volte l'autore (quando è ad esempio autore dei testi e dei disegni e non vuoi creare la cateogira TESTI E DISEGNI) allora la chaive primaria diventa
CODICE VOLUME + CODICE AUTORE + CODICE CATEGORIA.

Con questo dovresti avere le idee chiare per iniziare le tabelle derivate.

Poi si passa a realizzare il codice. Ma prima la struttura del database ti dev'essere chiara e svolta, nonchè normalizzata, del tutto. Un errato disegno del database pregiudica tutto l'applicativo.

[davhub]

Posso dire che mi hai steso??
Grandioso! devo dire che la tua idea è molto semplice e le linee guida le condivido. atomizzare e lavorare con relazioni. adesso, però, mi trovo nei casini con il programma di realizzazione database...

se teoricamente la progettazione dovrebbe essere chiara e la metterei anche giù graficamente a mano per averla sempre come guida, dal punto di vista pratico mi trovo nei casini.
ma questo è solo perché non ho mai utilizzato un programma del genere. Sospetto poi che tu parli di database con i controC&%&i... e non penso che pur potente Base di openoffice funzi così come un ACCESS di microsoft, ad esempio...

Per non parlare che tra tabelle, formulari, quyesry, ecc... mi ci sto perdendo anche in relazione a quello che salvo su disco. quello che salvo su disco in formato BASDE o MDB... cos'è? TUTTOil database comrpensivo di tabelle quesry, formulari, ricerche,?

Scusa ancora e voto la discussione... non certo per i miei interventi...

Davhub

[davhub]

Ok dopo lo shock.. veniamo al sodo:

Base di openoffice funziona dalle 2.3 in poi (ora ho la 2.4), con un appicativo a sè stante e non solo come dorgente dati all'interno di CALC o WRITER.
ha molte procedure guidate per cui devo dire che è una buona piattaforma didattica.

Adesso: vedi la schermata in basso? ecco.
io creo quindi una tabella in cui metto:

MEDIA
CODICE (INTERO AUTOINCREMENTALE)
TITOLO (STRINGA)
EDITORE (INTERO AUTOINCREMENTALE)
SUPPORTO (INTERO CHE TRASFORMI IN UN RADIOBUTTON)
POSIZIONE
ANNO PUBBLICAZIONE
EDIZIONE

Ma qui una domanda.. perché editore è un intero autoincrementale?
non è un testo fisso o un vartext?

media e supporto... che differenza hai in mente?
o MEDIA è il titolo della tabella?

Poi un'altra tabella in cui gestisco i nomi autori...

AUTORIPERVOLUMI
CODICE VOLUME (INTERO AUTOINCREMENTALE)
CODICE AUTORE (INTERO AUTOINCREMENTALE)
CODICE CATEGORIA AUTORE (INTERO AUTOINCREMENTALE)

e qui la sola domanda è: il codice categoria autore? cosa sarebbe?
e come faccio a dire al sistema "chiedimi nomi autori fintanto non ti dico stop"?

i record veri e propri cioè le celle con i singoli dati li inserisco all'interno
delle tabelle che gentilmente hai messo giù prima..


Tabella 1:
Generi
CODICE (INTERO AUTOINCREMENTANTE)
DESCRIZIONE (STRINGA)
Tutti e due i campi sono obbligatori (non nulli) in più il codice (e solo lui) è chiave primaria.
Sulla descrizione vi è un indice secondario ordinato in modo ascendente.

Tabella 2:
Categorie autori (Utile se si parla di autore delle storie o disegnatore).
CODICE (INTERO AUTOINCREMENTANTE)
DESCRIZIONE (STRINGA)
Tutti e due i campi sono obbligatori (non nulli) in più il codice (e solo lui) è chiave primaria.
Sulla descrizione vi è un indice secondario ordinato in modo ascendente.

Tabella 2:
Case Editrici
CODICE (INTERO AUTOINCREMENTANTE)
RAGIONE SOCIALE (STRINGA)
ALTRE INFORMAZIONI OPPORTUNE (INDIRIZZO, SITO WEB, EMAIL, ECC. ECC)
Lo schema della chiave primaria e dell'indice secondario è come sopra.

Tabella 3:
Autore
CODICE (INTERO AUTOINCREMENTALE)
NOMINATIVO (STRINGA)
ALTRE INFORMAZIONI OPPORTUNE
Chiave primaria e indice secondario come sopra

Immagino che dell'immagine che è sotto utilizzerò, al momento, solo le tabelle.
poi penserò ai formulari (che mettono in relazione le tabelle) e solo dopo aver relazionato e tutto... inserirò dati e potrò interrogare ed avere reports...

mazza che bello e come mi intriga...

Davhub

[htsoft]

Posso dire che mi hai steso??
Grandioso! devo dire che la tua idea è molto semplice e le linee guida le condivido. atomizzare e lavorare con relazioni. adesso, però, mi trovo nei casini con il programma di realizzazione database...

se teoricamente la progettazione dovrebbe essere chiara e la metterei anche giù graficamente a mano per averla sempre come guida, dal punto di vista pratico mi trovo nei casini.
ma questo è solo perché non ho mai utilizzato un programma del genere. Sospetto poi che tu parli di database con i controC&%&i... e non penso che pur potente Base di openoffice funzi così come un ACCESS di microsoft, ad esempio...

Per non parlare che tra tabelle, formulari, quyesry, ecc... mi ci sto perdendo anche in relazione a quello che salvo su disco. quello che salvo su disco in formato BASDE o MDB... cos'è? TUTTOil database comrpensivo di tabelle quesry, formulari, ricerche,?

Scusa ancora e voto la discussione... non certo per i miei interventi...

Davhub

Allora la base del DB l'ho studiata tenendo conto proprio di OpenOffice ed Access 97.
Tutto quanto è realizzabile con questi due prodotti.
Un file MDB contiene tutto, ma proprio tutto, ciò che è inerente al DB quindi: tabelle, indici, relazioni, query, report, moduli.
Il vantaggio è che se copi il file copi tutto. Lo svantaggio se si corrompe il file perdi tutto.

[htsoft]

Ok dopo lo shock.. veniamo al sodo:

Base di openoffice funziona dalle 2.3 in poi (ora ho la 2.4), con un appicativo a sè stante e non solo come dorgente dati all'interno di CALC o WRITER.
ha molte procedure guidate per cui devo dire che è una buona piattaforma didattica.

Adesso: vedi la schermata in basso? ecco.
io creo quindi una tabella in cui metto:

MEDIA
CODICE (INTERO AUTOINCREMENTALE)
TITOLO (STRINGA)
EDITORE (INTERO AUTOINCREMENTALE)
SUPPORTO (INTERO CHE TRASFORMI IN UN RADIOBUTTON)
POSIZIONE
ANNO PUBBLICAZIONE
EDIZIONE

Ma qui una domanda.. perché editore è un intero autoincrementale?
non è un testo fisso o un vartext?

media e supporto... che differenza hai in mente?
o MEDIA è il titolo della tabella?

Poi un'altra tabella in cui gestisco i nomi autori...

AUTORIPERVOLUMI
CODICE VOLUME (INTERO AUTOINCREMENTALE)
CODICE AUTORE (INTERO AUTOINCREMENTALE)
CODICE CATEGORIA AUTORE (INTERO AUTOINCREMENTALE)

e qui la sola domanda è: il codice categoria autore? cosa sarebbe?
e come faccio a dire al sistema "chiedimi nomi autori fintanto non ti dico stop"?

i record veri e propri cioè le celle con i singoli dati li inserisco all'interno
delle tabelle che gentilmente hai messo giù prima..


Tabella 1:
Generi
CODICE (INTERO AUTOINCREMENTANTE)
DESCRIZIONE (STRINGA)
Tutti e due i campi sono obbligatori (non nulli) in più il codice (e solo lui) è chiave primaria.
Sulla descrizione vi è un indice secondario ordinato in modo ascendente.

Tabella 2:
Categorie autori (Utile se si parla di autore delle storie o disegnatore).
CODICE (INTERO AUTOINCREMENTANTE)
DESCRIZIONE (STRINGA)
Tutti e due i campi sono obbligatori (non nulli) in più il codice (e solo lui) è chiave primaria.
Sulla descrizione vi è un indice secondario ordinato in modo ascendente.

Tabella 2:
Case Editrici
CODICE (INTERO AUTOINCREMENTANTE)
RAGIONE SOCIALE (STRINGA)
ALTRE INFORMAZIONI OPPORTUNE (INDIRIZZO, SITO WEB, EMAIL, ECC. ECC)
Lo schema della chiave primaria e dell'indice secondario è come sopra.

Tabella 3:
Autore
CODICE (INTERO AUTOINCREMENTALE)
NOMINATIVO (STRINGA)
ALTRE INFORMAZIONI OPPORTUNE
Chiave primaria e indice secondario come sopra

Immagino che dell'immagine che è sotto utilizzerò, al momento, solo le tabelle.
poi penserò ai formulari (che mettono in relazione le tabelle) e solo dopo aver relazionato e tutto... inserirò dati e potrò interrogare ed avere reports...

mazza che bello e come mi intriga...

Davhub

Veniamo alla prima tabella: MEDIA (letto alla latina quindi MIDIA) è il nome della tabella.
L'editore è un numero in quanto in esso va inserito il codice assegnato al record dell'editore.
In questo modo se l'editore Adelphi ha codice 1 metterai nel campo editore della record "Lo Hobbit" con codice 1000 il codice 1 per l'editore.
In questo modo la descrizione dell'editore la cambi in un solo punto ed automaticamente cambia per tutte le tabelle relazionate (in reltà non cambia ma quando andrai ad interrogare la tabella ti sembrerà proprio così).
Errata corrige, in questo caso il campo EDITORE contiene un intero e non un intero autoincrementale.

Il codice tipologia autore ti occore nel caso in cui per un titolo con più autori questi ultimi ricoprano ruoli differenti (ad esempio nel libro di Simone Vassallo il capitolo su fryrender non l'ha scritto lui, ma un altro autore in questo caso puoi creare una categoria "autore aggiunto" per indicare che quest'ultimo non ha lavorato su tutta l'opera ma solo su una parte).
Per realizzare l'inserimento di autori multipli ti basta inserire una griglia nella form con il campo relativo al volume settato fisso con il codice del volume ed il resto variabile (ma questo lo vediamo dopo).

Si per ora limitati a creare le tabelle, magari poi postami il file di Base che gli do un'occhiata e lo correggo in caso di errori.

Poi passiamo al disegno delle relazioni.
Quindi passiamo alle query (o view).

E solo allora ci occuperemo delle schermate dell'inserimento dati.