Visualizza Versione Completa : Database biblioteca
Ciao a tutti, un piccolo OT per menti maniacali del controllo come la mia (almeno in potenza visto che poi sono un casinista totale.. :D)
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) :D 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
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).
Il mitico htsoft.. :D quello con il curriculum database più palluto del forum (a quanto sappia, eh, non me ne vogliano gli altri.. :D)
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!!! :D
Davhub
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
O maremma. :D
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
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.
Posso dire che mi hai steso?? :D
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... :D
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? :rolleyes:
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
Posso dire che mi hai steso?? :D
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... :D
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.
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? :rolleyes:
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.
Sto piangendo dalla contentezza :D
OK, dico solo che abbaimo un simile modo di approcciare le cose...
a livelli semplici e di controllo. sarà che la programmazione anche se saltuaria ha influenzato anche me.. :D
OK..
vado colpisco e torno..
Davhub
P.S. purtroppo noon c'è intero autoincrementale nel base di OO...
cambia qualcosa??
riedit...
mi sa che è nella digitazione automatica sotto :rolleyes:
P.S. purtroppo noon c'è intero autoincrementale nel base di OO...
cambia qualcosa??
riedit...
mi sa che è nella digitazione automatica sotto :rolleyes:
Purtroppo non ho OO in ufficio e quindi non posso controllare. Ma l'autoincremento è un'opzione sicuramente presente in quanto sia Base che Access non prevedono la creazione di triggers.
Vedi nel dettaglio del campo, forse è li.
P.S. dimenticavo nei nomi dei campi e quelli delle tabelle non usare lo spazio se proprio devi separare le parole metti l'underscore (il trattino di sottolineatura) altrimenti avrai problemi nella formulazione delle query.
Allora ho fatto tutte le tabelle e mi stavo chiedendo se non fosse il caso di inserire anche tabelle come quella dei generi musicali (che si attiva se e solo se il media è quello giusto) e poi me ne verranno altre in mente.
Non sono riuscito a trovare (ma non è detto che ci sia) l'indice secondario...
anche cercando nella guida di open office non l'ho trovato magari è sotto un altro nome...
Altra questione: dicevi del problema integrità dei dati. direi che oltre al classico backup... ci si dovrebbe riferire al backup incrementale mentre lavori.
tipo: adesso copio quello che ho fatto e lo nominimo XXXdataoggi.odb...
in allegato il file..
ti ringrazio in anticipo per quanto stati facendo... (poi vedi nei PM, OK? ;) )
Davhub
Ciao Davide,
in allegato il file Media leggermente corretto.
In particolar modo:
1) Ho rinominato il file Media in volumi per essere più coerente
2) Ho aggiunto il dettaglio per i DVD come esempio
3) Ho aggiunto il dettaglio brani per ogni DVD
4) Ho modificato ed esteso alcune tabella aggiungendo dei campi
5) Ho creato le relazioni (nei Tools / Relations le vedi e le puoi modificare)
Ho lasciato alcune incongruenze nei nomi dei campi proprio per permetterti di correggerle e vedere cosa succede.
Appena il meccanismo è chiaro passiamo alle View ed alle Query.
OK adesso sto finendo alcune cose, poi ci dò un occhio, la cosa che mi sta angustiando è
anche la terminologia...
Leggevo qua e là e tra report query, tabelle, campi, record, ecc. non ne sto uscendo vivo..
(perché sospetto che la terminologia si porti dietro nomi per pratica storica permetendo ad una stessa cosa di avere nomi differenti.) poi posto quello che ho capito, posso?
Davhub
OK adesso sto finendo alcune cose, poi ci dò un occhio, la cosa che mi sta angustiando è
anche la terminologia...
Leggevo qua e là e tra report query, tabelle, campi, record, ecc. non ne sto uscendo vivo..
(perché sospetto che la terminologia si porti dietro nomi per pratica storica permetendo ad una stessa cosa di avere nomi differenti.) poi posto quello che ho capito, posso?
Davhub
Si anche perchè l'uso di una corretta terminologia è necessario per interagire con altre persone. In genere si seguono semplici regole:
1) Lingua franca: Inglese
2) Riferimento allo standard SQL '92
3) Salvo che in casi specifici è sempre preferibile evitare le particolarità dei singoli RDBMS. Questo per la scalabilità.
Caio Roberto.. non sei collegato su MSN, vero?
ti ho appena inviato un messaggio.. non ti rompo, però sai che non trovo altro che quello che avevo fatto io?
non è che il sistema mi tiene a mente cose riconoscendo che il datanbse, al di là del cambio nome è lo stesso?
(sai un pò come fa LW ogni tanto.. :D)
davhub
Come si chiama la tabella contenente i volumi? Io l'ho rinominata Volumi prima era MEdia.
Ho controllato il file rar contiene il documento giusto.
Probabilmente è un problema di caching.
Ho letto il commento al blog. Grazie!
MSN lo posso tirare su stasera a casa...
Qui al lavoro ho il proxy occluso....
Non ti preoccupare.. allora. aperto il tutto (cache, in effetti) adesso sto vedendo cosa hai cambiato e cosa hai fatto. anche perchè muoio dalla voglia di vedere cosa hai combinato nelle relazioni :D
Comunque per poco sei comparso in linea, :D
Terminologia e funzioni nel database:
Le tabelle sono i contenitori delle informazioni.
Ogni tabella ha righe (record) e colonne (campi).
La cella (incrocio riga/colonna) non so se ha un suo nome specifico.
Il campo può avere validazioni e caratteristiche differenti (integer, ecc.)
che rendono intelligente il comportamento del software a seconda del tipo di dato inserito.
Diciamo che sono il cuore del sistema ma sono puri atomi.
il resto del database si preoccupa di formare macromolecole (le relazioni)
e di fornire gli strumenti per il "crawling" della molecola retificata===> vedere
query/ricerche e reports/rapporti.
Se ho ben capito, l'utente deve progettare una query in modo che il database reticolato (tabelle poste in relazione tra loro) posa rispondere e dare un risultato = report.
Corretto?
Spero di sì. adesso andiamo oltre. una volta che ho inserito la struttura delle informazioni (tabelle), le ho relazionate, ho progettato la query, ecc.
passo a vedere come il "programma" deve essere visto (la maschera altrimenti detta formulario, immagino, no?
Immaginando che quaanto detto sia giusto, ho 4 domande:
1) la chiave primaria identifica una singola riga (così dice la teoria) ma nelle tabelle la chiave primaria è una e quindi mi chiedo le altre righe della tabella come vengano identificate.
2) La metafora della molecola mi dice che tutto quanto fin qui descritto è la molecola e la strumentazione per navigare questa molecola. ma le tabelle, in fondo non sono le informazioni (fin qui dati io non ne ho inseriti).
allora mi chiedo i dati inseriti che poi saranno interrogati e navigati... a cosa corrispondono? dove li troverò concettualmente nel database?
sono gli atomi che le tabelle legano alla struttura?
3) Nel database che hai modificato, ho visto che alcuni integer non erano autoincrementanti e li ho rimessi tali (specie gli ID/chiavi primarie delle tabelle)
Ho rimodificato i nomi perchè il tempo ed i brani nei DVD, ha poco senso, semmai nei CD. Modificando sono usciti errori, e come immaginavo erano quelli delle relazioni che sono andate a posto da sole.
Ho aggiunto una tabella DVD e mi chiedo allora se mettere in campo riviste e fumetti...
4) le relazioni.. a prima vista si fanno bottomup o sbaglio?
adesso mi addentro..
Grazie tantissime!!
Davhub
Ciao Davide,
sostanzialmente la prima parte è corretta.
Il discorso importante è paragonare ad esempio una tabella ad un foglio excel, i record sono le righe, i fields le colonne, la tabella è il foglio.
Nei database si parla di cursore il riferimento alla riga corrente. Ovvero in un database (immaginalo come una lista ad accesso sequenziale) ho l'indicatore di record corrente che si chiama cursore.
Tutte le operazioni vengono eseguite su un solo record per volta (anche se da determinate istruzioni che vedremo poi potrebbe non sembrare così).
Questo record contiene le informazioni che andrai ad adoperare.
Ad esempio una tabella potrebbe essere:
Tabella Libri:
N° RECORD ID LIBRO VOLUME
000001 100 GUERRA E PACE
000002 110 I FRATELLI KARAMAZOV
000003 120 ARCHITETTURA AL CALCOLATORE
Ecc. ecc.
Se ti trovi sul record n° 1 il campo ID LIBRO conterrà il valore 100 ed il campo volume conterrà GUERRA E PACE
Spostandoti al record successivi i valori di questi campi conterranno 110 e I FRATELLI KARAMAZOV
E così via.
Ecco quindi che veniamo a comprendere una cosa:
Le tablle contengono i dati sotto forma di righe chiamate record ed ogni riga è divisa in campi.
Quindi la tabella è composta da una parte di definizione dei singolo campi che associati tra di loro formano un record, e dall'altro è un'entità che contiene i veri e propri dati a cui accedere.
Tecnicamente parlando nel database si può operare in due modi:
1) Alcuni RDBMS mettono le definizioni delle tabelle in altre tabelle invisibili ed i dati in files chiamati come le tabelle
2) Altri mettono in testa ad ogni tabella la definizione della tabella stessa.
Quindi proseguendo il discorso della molecola, se tu all'interno non metti atomi in modo coerente la molecola potrebbe non essere coesa o peggio ancora generare delle aberrazioni.
A questo punto si, fin'ora hai pogettato le fondamenta della casa in cui inserire i dati.
Come inserire i dati a questo punto?
1) Doppio click sulla tabella, ti si apre uno schema simile ad excel e ci digiti i dati in formato "raw" (diciamo"
2) Si creano delle form (schede) che ti aiutano nell'inserimento. Ma siamo ancora lontani da questo.
Il concetto della progettazione è importante soprattutto per quel procedimento che viene identificato dopo come Data Mining, ovvero estrazione dei dati. Se progetti correttamente il DB estrarne i dati è decisamente semplice e veloce, altrimenti...
Veniamo alla domanda della chiave primaria.
Quando identifichi un campo come chiave primaria, in realtà dici che è il contenuto del campo che identifica la chiave primaria e non il campo stesso.
Torniamo al concetto di record corrente
Nella tabella dei libri supponiamo che il campo ID LIBRO sia il campo chiave. In questo caso stai affermando che il contenuto del campo ID LIBRO per il record corrente dev'essere necessariamente definito e che dev'essere differente dal contenuto per il campo ID LIBRO di tutti gli altri record (righe) presenti nella tabella.
Per semplificarti il problema Base ti permette di definire un campo autoincrementale e quindi si occupa lui, per ogni nuovo record, di inserire un nuovo valore sicuramente differente dagli altri.
Qualcuno (io però non sono d'accordo con questa visione) afferma che il contenuto di un campo chiave, una volta definito per un singolo record, per quest'ultimo non può essere più modificato, pertanto supponendo di aver definito come campo chiave il Codice di un Articolo se vogliamo ridefinire il codice di un articolo dobbiamo necessariamente creare un duplicato del record ed eventualmente cancellare il record con il vecchio codice.
Come ti dicevo non sono d'accordo con questo approccio e lo standard mi supporta in questo. Fondamentalmente la scelta di rendere modificabile (e quindi gestire i vari casi) o meno il valore di un campo chiave è un requisito utente e pertanto va discusso con quest'ultimo l'approccio che si vuol seguire.
Ciao Roberto.. per quanto riguarda la tua questione posta nel PM.. ho mosso chi dovevo muovere e stasera sento l'ultima persona... vediamo ;)
Passiamo invece al discorso del topic.
Chiave primaria: la teoria (letta oggi) mi dice che è il modo per rendere UNIVOCO il campo. perfetto ecco perché, nel nostro caso, l'ID dei libri è chiave primaria. Ed ecco perché ci possaimo permettere di avere più chiavi primarie all'interno del nostro database.
ribadisco: gli ID devono essere univoci, ma ad un autore possono esserci più libri, ecc.)
Perfetto anche la questione di parallelismo excel/DB, visto che il primo lo conosco non benissimo, ma lo uso diffusamente.
il database, praticamente è come un foglio di excel con righe infinite e colonne pari a 3 (nome record, valore del record, descrizione).
poi ho capito che esistono due modalità di gestione e interazione con le tabelle: la modalità struttura: in cui si fissano le colonne di cui sopra e la modalità inserimento in cui si insriscono i dati. Praticamente è il programma che si preoccupa di inserire i dati dove servono (e questo modus operandi è come avere una tabella master/invisibile (come dicevi)/fantasma e una contenente i dati.
Quello che non riesco ancora a capire, però, riguarda l'estrazione dati
e le richieste.
Finora quindi ho progettato la struttura dati (nomi e tipologie), non solo ho anche stabilito che certe tipologie siano univoche (chiavi primarie) all'interno di ciascuna tabella, e sono (siamo) andati leggermente oltre:
alcune chiavi primarie sono state legate da una relazione UNO ad UNO (giusto)? in modo che diano lo stesso risultato coerente (sempre gli ID autori, ad esempio).
La domanda perciò è questa: è pertanto con le query che io dico al DB quali record utilizzare (se posso cercare per data oppure no, ad esempio).
E questo sarà il mio argomento di studio in questi giorni.
Hai consigli utili? sennò l'unedì, se posso, riposto il CD modificato..
grazie in anticipo, gentilissimo. :D
Davhub
Ciao a tutti, e ancora grazie ad HTSOFT. allora in allegato c'è il database modificato secondo alcune indicazioni ulteriori desunte dagli utlimi sviluppi.
spero che la mia comprensione di quanto fatto sia corretta.
Allora: qui di seguito lo schema rivisto e corretto di come potrebbe essere un database da biblioteca:
Struttura e classificazione di un database
Raccolta di media (Libri, riviste, fumetti, CD musicali, DVD video)
Per ciascuna di queste categorie serve:
1.un ID univoco
2.il riferimento alla casa editrice (comprensivo di dati della stessa, anno di pubblicazione, ecc.).
3.Autore/autori
4.Titolo
5.Posizione di archiviazione
Poi occorre una regola che modifica l'apparizione del DB in base alle esigenze:
Tipologia di medium/media (se è un CD, se un libro, una rivista, ecc.)
Infine, prima dei dati specifici la struttura potrebbe riportare il GENERE del contenuto ovviamente variabile in base al tipo di media scelto.
Ecco, invece i dati specifici per ciascun medium:
Libri:
1.Genere secondario (il primario “saggio” il secondario “cosmologia” piuttosto che “letteratura”.
2.Commento sui contenuti e sui concetti
Riviste:
1.Commento generale su articoli particolari
2.Indice in breve.
Fumetti:
1.Genere secondario (manga, comics, graphic novel)
2.Indice del volumetto/book
3.Saga contenuta
CD audio
1.Genere musicale specifico
2.Indice dei brani
DVD Video
1.Attori
2.Serie eventuale
3.Commenti
Questo a livello generale. nel nostro caso specifico abbiamo creato una serie di tabelle contenenti i campi più atomizzati possibili (normalizzazione del DB)
in modo che possano essere al richiamati i dati necessari. Le tabelle più piccole contengono solo la chiave primaria ed il genere (ad esempio).
Quelle un pò più complesse, invece, riguardano gli aspetti più di dettaglio.
Ho aggiunto anche le riviste e i campi per le suddette, i generi secondari, ecc..
a questo punto, a patto che sia corretta sia la stesura che l'interpretazione, come si prosegue?
Il campo relazioni, adesso che sussiste un pò più di complicanza, sospetto lo debba rivedere (insomma quello che non sto capendo è come rendere efficace la relazione tra i generi secondari e primari, e come effettuare la scelta dei media, che poi mostra o meno sia i generi che alti dati (immagino sia questione dei formulari/maschere di cui ci si occuperà, no?)
e poi, forse non avendo ben capito ocme si opera ho inserito troppe tabelle... :noidea:
Grazie in anticipo. :cool:
Davhub
Ciao Davide,
riprendo la discussione, spero sia ancora utile, rispondendo alle tue domande:
1) Si forse ci sono troppe tabelle, dobbiamo semplificare portando a fattor comune le informazioni
2) La scelta dei campi di riferimento è per le maschere. Il problema è che usando OpenOffice la gestione delle maschere è abbastanza complessa....
Vorrei proporti una cosa:
Ti realizzo al volo la struttura del DB (completa) in formaot OpenOffice, definitiva. In questo modo potrai studiare la sua struttura.
Dove non ti è chiaro affrontiamo il discorso punto per punto.
Ovvero: Scelte stilistiche, approcci e strutture.
La cosa, se ti serve ancora, posso finirla per questa sera.
A questo punto passiamo all'interfaccia.
In questo caso credo che a te interessi far vedere anche l'aspetto di sviluppo e non solo il disegno delle maschere.
Potremmo realizzare la cosa in un formato tipo PHP/HTML.
Inoltre se hai la gmail puoi raggiungermi anche adesso via gchat in questo modo possiamo tagliare un pò i tempi...
Io potrei passarti il DB anche adesso se vuoi.
dimenticavo ecco il link: rscarciello@gmail.com
Ciao HTsoft/Roberto!! Grazie per essere ripassato su questo thread.. certo che mi interessa ancora.. sai per cosa mi serve, e sto quasi finendo il programma.. :D
Da quando ci siamo sentiti diciamo che Openoffice base lo conosco meglio. adesso so come si fanno le maschere, e mi mancano solo alcuni dettagli di query e reports, le relazioni le capisco meglio, capisco anche meglio altre cosucce (viste inserimento e vista struttura, ecc.)
Scusa se ieri sono stato silente, ho visto che avevi risposto, ma sono giorni che inizio alle 8:00 e finisco di lavorare alle 20:00 se va bene.. per cui poca birra.. :D
Allora. Sull'operativo... oggi sono qui, tengo g mail aperta (se funziona così).. hai visto che ti ho inviato a parlare? :D
per quanto riguarda l'interfaccia: io ho capito che si fa con le maschere, che il livello predefinito con le maschere è la punta di un iceberg gigantesco (sono certificatore energetico della Regione Lombardia ed il software CENED, se non erro è fatto con ACCESS: so a cosa si può giungere avendo in mano un pò di voglia di fare).
Tuttavia a me serve avere un'idea di massima di come gestire le maschere con tabelle multiple (cioè come far vivere le relazioni e far apparire i campi che mi occorrono a seconda di certe scelte). poi per carità: ti dico anche che se vuoi prendere spunto da questo e sviluppare uno strumento web based.. ok. ma al momento in tutta franchezza non ho birra per questa attività ulteriore e non ti seguirei. devo concentrare sull'obiettivo che devo raggiungere, sarà prosaico ma proprio se non voglio al solito non concludere nulla delle mille cose che faccio...
Devo fare così.
Quindi.. se vuoi passa pure all'operativo:
ti chiedo però, non tagliamo guori il thread..semplicemente:
ogni tabella che apro, il sistema mi propone (ma posso evitarlo) la chiave primaria detta ID.
non capisco perchè ci deve essere per ogni tabella un ID NUMERICO e perchè questo, comunque, lo devo gestire io (cioè devo comunque pensarci io a scrivere 1,2 ecc.). Alla fine per ogni informazione che inserisco (pardon parlo meglio,per ogni record che devo compilare), devo anche pensare a come gestire l'ID relativo a quella tabella... visto che ne abbiamo una dozzina... mi chiedo che utilità abbia avere 12 ID 1, ad esempio...
ma forse qui è il classico equivoco tra chiave primaria e chiave di ricerca... (come spiegano in alcuni forum di databasisti.. :D).
OK, tu butta giù la struttura io poi chiedo, mi faresti un enorme piacere..
Davhub
Ciao Roberto, immagino tu sia impegnato in questo periodo... Nel frattempo io sto uscendo pazzo e tento di avere conforto.
per fare esempi che potessero essere gestiti ho cercato di fare un semplicissimo database di 2 tabelle 2:
una tabella autori (ID autore, Nome autore e cognome autore)
e una tabella Libri (ID libro, titolo, sottotitolo, nome autore, cognome autore, casaeditrice).
Bene.. adesso incomincia il delirio. creo relazioni, chiudo la finestra di creazione relazioni, la riapro: nessuna relazione creata. se tiro le voci a mano con il drag&drop... mi esce un incomprensibile messaggio di errore su vincolo di unique o qualcosa di simile.
rifaccio le tabelle da zero, (anche perché non mi accettava più di una chiave primaria per volta) e idem..
poi mi viene in mente che, forse, non è concettualmente giusto quello che ho in mente: le relazioni me le immagino tra i nomi autori ed i cognomi autori dlele due tabelle, ma come si crea una relazione 1 molti tra queste due tabelle? (1 nome per molti libri e idem per il cognome?)
Provo a creare quindi una relazione per cui ad ogni inserimento vorrei che parimenti mi si aggiornasse il record in relazione. ma nada.
allora mi viene in mente che nella creazione formulari posso inserire i menu a tendina... ed ecco che nel formulario per l'inserimento libri mi ritrovo i dati inseriti nella scheda autori. peccato che il nome ed il cognome vadano per i fatti loro e così al posoto di avere Dino Buzzatri e Giovanni pascoli mi posso comodamente ritrovare ad avere un Dino pascoli..
Insomma... un gran guazzabuglio e mi ci sto pure perdendo.
Tutto sommato quello che mi sconvolge è la questione dlele relazioni... qualche tempo fa mi faceva creare qualsiasi relazione... o quasi.. boohh? miagolo proprio nel buio..
Davhub
Ciao Davide,
nella seconda tabella c'è un errore: la struttura delle due tabelle dovrebbe essere:
AUTORE: IDAutore, Nome, Cognome
LIBRO: IDLibro, Titolo, Sottotitolo, IDAutore, CasaEditrice
E la relazione deve essere tra Autore.IDAutore -> Libro.IDAutore
Vedrai che dopo non la cancella più.
Per estrarre una lista che contiene sia il titolo del libro che il nome dell'autore dovrai impostare una query come segue (scritta in SQL):
SELECT IDLibro, Titolo, SottoTitolo, Nome, Cognome, CasaEditrice
FROM Libro,Autore
WHERE Libro.IDAutore = Autore.IDAutore
Perfetto! ecco cosa c'è che non va... sono un babacchione...
ma guarda che non me la crea comunque...
se la creo con il wizard, me la fa vedere ma poi non la salva (e non c'è nemmeno il numerico che mi indica se è una 1-1 o altro)
trasciando mi esce una cosa del genere:
il tipo colonna on trova corrispondenza in statement [alter table "libri"
ADD foreign KEY ID autore, references "Autori" ID autore
e altra cosa.. OK la query, per carità, parliamo di formulari/maschere.
con questa modifica, funzionasse, automaticamente quando compilo la scheda di un libro, se ho già inseirto gli autori, mi dovrebbe far vedere un pò di autori a disposizione.
oppure utilizzo il formulario secondario? ed in una sola maschera gestisco tutte e due le tabelle con i relativi record??
certo che non è facilissimo comprendere come funzionino realmente le cose in un database...
Grazie per la tua pazienza.
Davhub
Powered by vBulletin® Version 4.2.5 Copyright © 2024 vBulletin Solutions, Inc. All rights reserved.