Struttura database e relazioni tra tabelle - cosa mi sfugge ?

di il
23 risposte

Struttura database e relazioni tra tabelle - cosa mi sfugge ?

Salve a tutti,

spinto da non so quale spirito autolesionista (scherzo!), ho proposto ad un collega di ‘evolvere’ il suo foglio Excel per la gestione delle commesse in un qualcosa di più sensato, appunto attraverso un database in Access.

Ora, avendo chiaramente sovrastimato le mie capacità di apprendimento, mi trovo con qualcosa che mi sfugge, soprattutto nelle relazioni.

Provo a spiegarmi a parole, e provo anche poi ad aggiungere un immagine delle relazioni attuali, per capire se è qualcosa che sto sbagliando o qualcosa che - invece - mi sfugge.

Vorrei creare un database compoosto da 17 tabelle, di cui in pratica ci sarebbe una prima tabella ('Generale'), che dovrebbe avere una riga univoca per ogni commessa (divise per ‘Sito’), e subordinata a questa, ci dovrebbero essere 9 tabelle che al loro interno hanno vari campi da compilare ma per ogni ‘Sito’ posso avere più righe.

Nella fattispecie, per il sito ‘Milano’ (in ‘Generale’), posso avere più righe di ‘Catastali’, e così per le restanti tabelle. 

Io ho messo una relazione ‘one-to-many’ su queste tabelle. E' corretto? E' corretto utilizzare il campo ‘ID_Generale’ o ha più senso usare l'ID_Sito'? Per ogni ID_Sito potrei avere più ID_Catastali, e come creo una maschera per inserire questi e ulterori dati?

Perchè il mio punto è che io avrei bisogno di avere delle maschere di inserimento che mi permettano di inserire dati in combinazione di queste tabelle, cosa che appena utilizzo la generazione guidata, mi da errore. 

Temo mi sfugga qualcosa nelle relazioni che sto adottando.

Allego qui la struttura se può essere d'aiuto (i campi ID vari nella tabella ‘Generale’ sono frutto di vari esperimenti).

Grazie a tutti,

Stefano

23 Risposte

  • Re: Struttura database e relazioni tra tabelle - cosa mi sfugge ?

    Forse avresti dovuto postare nella sezione “Progettazione database”…ma va bene uguale.

    C'è un enorme errore di NORMALIZZAZIONE per cui le tabelle devono avere nomi coerenti con i dati che contengono. Mi spiego meglio, una tabella non può chiamarsi Generale (nel senso logico intendo). A seguire molte delle tabelle che vedo sono inutili doppioni, possono diventare tabella unica e poi contenere un campo che specifica. Impossibile adesso darti una dritta. Occorre rivedere tutto il progetto da ZERO, previa analisi passo passo di quello che si vuole ottenere. Prima parola d'ordine: DIMENTICA EXCEL.

  • Re: Struttura database e relazioni tra tabelle - cosa mi sfugge ?

    Ciao Osvaldo, grazie mille della risposta.

    E' esattamente quello che sto provando a fare.

    Sto provando a rioganizzare le tabelle, per esempio i campi ‘univoci’ per ogni ID ha senso tenerli nella stessa tabella, o separarli?
    Intendo ad esempio un ‘Anagrafica’.

    Grazie mille!

  • Re: Struttura database e relazioni tra tabelle - cosa mi sfugge ?

    Non è una questione di qualcosa che possa sfuggire… non hai per nulla i concetti della normalizzazione. C'è una miriade di campi ID che non si capisce a cosa servono. Apparte questo ci sono correlazioni che non si comprende a cosa debbano condurre. Ti consiglio di partire da qualcosa di più semplice e cominciare a costruire per gradi. Scusa se sono un po' duro.

  • Re: Struttura database e relazioni tra tabelle - cosa mi sfugge ?

    14/03/2024 - stealbi ha scritto:


    Vorrei creare un database composto da 17 tabelle

    In nessun database puoi sapere (detto con questa frase) a priori quante tabelle ti servono.

    14/03/2024 - stealbi ha scritto:


    di cui in pratica ci sarebbe una prima tabella ('Generale'), che dovrebbe avere una riga univoca per ogni commessa

    Perchè questa tabella non si chiama Commesse (sarebbe più logico)?

    14/03/2024 - stealbi ha scritto:


    (divise per ‘Sito’)

    Che significa?

    14/03/2024 - stealbi ha scritto:


    e subordinata a questa, ci dovrebbero essere 9 tabelle che al loro interno hanno vari campi da compilare ma per ogni ‘Sito’ posso avere più righe.

    Anche questa frase è incomprensibile. Da una tabella (suppongo) “figlia”…che senso ha diramare in 9 tabelle?

    Questo solo per le parti testuali che hai scritto. 
    L'immagine della Finestra Relazioni non è del tutto leggibile, non si capisce nulla (almeno io non ci riesco). Consiglio di fare più piccoli passi:
    1. Di cosa parla il database? Di Commesse?
    2. Se il punto 1. è Sì, esponi tutti i campi della tabella Commesse (elencali in verticale in maniera testuale).
    3. Poi (piano piano…perchè non è detto che sia la strada giusta) ci spieghi la questione dei Siti…e racconti un esempio concreto per Milano…usando un linguaggio per “non addetti ai tuoi lavori”, perchè come hai esposto prima (a me…durissimo di comprendonio) non è chiaro.

    Fermiamoci qua per ora.

  • Re: Struttura database e relazioni tra tabelle - cosa mi sfugge ?

    Per aiutari dovresti spiegare passo passo come si svolge l'attività che vorresti riprodurre nel database e postare il file di esempio con un minimo di dati.

  • Re: Struttura database e relazioni tra tabelle - cosa mi sfugge ?

    14/03/2024 - Stifone ha scritto:


    Per aiutarti dovresti spiegare passo passo come si svolge l'attività che vorresti riprodurre nel database

    Questo sì.

    14/03/2024 - Stifone ha scritto:


    postare il file di esempio con un minimo di dati.

    A guardare la Finestra Relazioni e la descrizione testuale a me appare come un gran nonsense. Inoltre non è nello spirito del forum lavorare direttamente col database…tranne in casi limite. Bisogna sforzarsi di spiegare correttamente ed esaustivamente il problema, cosa che stealbi può fare.

  • Re: Struttura database e relazioni tra tabelle - cosa mi sfugge ?

    Purtroppo hanno ragione, il tuo schema e' confuso. 17 tabelle sono TANTE. Molte non hanno senso, altre sono duplicazione 

    1. tutto il blocco asset e tabelle relative sono inutili
    2. tabelle con campi che finiscono con 1,2,… sono sbagliate
    3. tabelle con solo 2 colonne sono sbagliate
    4. tabelle con 2 o piu' campi data sono sbagliate 
    5. tabelle che contengono SOLO un'ettichetta/stringa NON SERVONO

    .

    In un database i tipi “primitivi” sono: intero, numero con la virgola, stringa, data&ora. 
    NON E' difficile aggiungere un “enumerativo”, cioe' una lista PREDEFINITA (e costante) di valori di tipo primitivo.
    Ovviamente, i vari DBMS mettono a disposizione anche tipi di dati piu' complessi, MA, come tutte le cose, vanno usati con intelligenza e sapendo quello che si sta' facendo.

    Questo per dire che tabelle come “Tipo CiccioPasticcio” potrebbero NON SERVIRE, magari ti basta un file di testo da leggere in fase di inizializzazione del programma.

    non e' che non si possano avere tabelle con le sopracitate caratteristiche, in ASSOLUTO, il problema e' che non hanno senso in QUESTO caso. 

    Bisogna studiare:

    1. teoria relazionale dei dati e relativi concetti
    2. i concetti di normalizzazione dei dati. Esistono TANTE forme normali MA bisogna conoscere ALMENO le prime 4 
    3. ma sopratutto, chiarirsi mooooooooooooolto meglio quali sono gli ‘oggetti’  che vanno manipolati 

    Tu ti sei fatto un'idea MA e' confusa. Come risultato hai un modello ‘impasticciato’ . 

    SE hai esperienza di programmazione, il modello dei dati in un database e' mooooolto simile al modello dei dati nella programmazione ad oggetti. 

    Infatti esistono un'infinita' di librerie che mappano in automatico tabelle e classi, record ed oggetti.

    Altra cosa fondamentale e' dare dei nomi significativi alle tabelle ed alle colonne. Nomi non chiari, dubbiosi, che finiscono per 1,2,… (anche se in numero romano) sono sintomo che non si e' scelto l'oggetto giusto

    Inoltre, NON ESISTE la struttura perfetta di un database. Il suo compito e' rispondere in modo efficiente a delle interrogazioni. Quindi per prima cosa ti devi fare una lista di domande del tipo:

    1. voglio avere la lista di TUTTI gli A disponibili
    2. voglio avere la lista di tutti gli A che soddisfano la condizione C
    3. voglio avete la lista di tutti i B che sono in relazione con A  su questa proprieta'

    A questo punto inizi ad avere un qualcosa che puo' assomigliare ad un database.

    SOLO DOPO si inizia a correggere il tiro adattando il modello dei dati ai limiti tecnici e di modello di rappresentazione

    Altra cosa FONDAMENTALE: il modello dei dati lo si progetta con carta e matita, LETTERALMENTE. 

    Usa fogli A4 e se non ti basta, A3, gomma da cancellare e matita 2B.

    SOLO quando ti e' chiaro IN TESTA E sul foglio di carta  , puoi metterti di rappresentare con un computer

    .

    Insomma, i pasticci sono tanti, milioni di milioni, come la stella di Negroni! ;-)

  • Re: Struttura database e relazioni tra tabelle - cosa mi sfugge ?

    Suppongo che sito sia il comune(?)

    generali è uno a molti (tabelle)… uno a molti si dovrebbe intendere un record tabella madre ha tanti record tabella figlia non una tabella ha tante tabelle.

    stiamo parlando di dati catastali? una mappatura di uno o piu' comuni?

    Non riesco a distinguere la parte statica (dati) da quella dinamica (ciò che deve fare il programma).

    spiego meglio: se il programma deve gestire l'emissione fattura (parte dinamica) hai bisogno di dati statici (movimenti la tabella solo poche volte)

    in questo caso i dati sono: 

    • il cliente (o fornitore) lo carichi una volta e lo usi ogni volta che emetti (ricevi) un documento.
    • gli articoli (li carichi una volta e li usi quando servono)
    • eventuali trasportatori
    • eventuali magazzini
    • i reparti dei prodotti
    • ecc..

    la parte dinamica:

    • fatture
    • righe fatture

    queste tabelle le movimenterai sempre (appunto dinamiche).

    il core del database (può averne più di uno, pensa alla gestione pagamenti derivata da ricezione emissione fatture) è la fatturazione, quindi fatture attinge a clienti(fornitori) e vettori

    fatture avrà i dati di testa (cliente, nr, data) e piede (totale documento, vettore) di una fattura.

    le righe saranno collegate a fattura e attingono come dati a articoli. in piu' avrai i dati variabili della riga (quantità, prezzo se diverso da quello proposto, iva applicata se diversa da quella proposta ecc…).

    intanto ti suggerisco di lavorare sulla parte dati (tutto ciò che caricheresti una sola volta in tabella) poi cerchi di individuare la parte dinamica (cosa deve fare il programma?).

    spiega bene cosa deve fare e quali dati ti servono per lo scopo, poi chi ha più dimestichezza in access ti può indirizzare alla normalizzazione e gestione.

  • Re: Struttura database e relazioni tra tabelle - cosa mi sfugge ?

    Grazie a tutti, anche per il cazziatone! :-D :-P

    Sembrerà strano, ma sono partito proprio da carte e penna (e il suo foglio Excel, e le sue indicazioni - a questo punto direi molto poco utili).

    Ho rivisto un po' la struttura.

    Cercherò di essere più esaustivo nella spiegazione.

    Per la gioia di tutti, ho rinominato le tabelle con nomi più sensati (o almeno spero).

    Quelle che deve essere gestito sono le pratiche amministrative con relativi dati e date per delle bonifiche ambientali.

    Nella tabella 1_Riepilogo, ho indicato tutti i campi univoci per ogni sito di bonfica (quindi con lo stesso ID_Generale), dove avrò per ogni ID_Generale appunto una solo - ad esempio - un Normativa_Notifica etc etc.

    Ora due aspetti, nella tabella con prefisso 0_Tipo_Siti ho inserito io i dati di anagrafica di ogni sito, in realtà anche qui avrei un valore univoco, quindi non so se abbia del tutto senso separarli, forse no. Al contrario invece Nelle tabelle 0_Tipo_Criticità e 0_Tipo_Matrice, che non verranno mai toccate, questa tabelle mi permettono la creazione di un ‘menù a tendina’ per aiutare l'utilizzare a popolare il database (lo stesso discorso vale per 0_Tipo_Asset, con riferimento alla tabella 2_Stato_Asset).

    A questo punto la cosa mi pare sensata, e riesco a creare delle maschere di inserimento per i vari campi.

    Ora viene il mio dubbio amletico, per quanto rigurda invece gli Asset, io avrò a parità di sito la possiblità che ci siano più asset. 

    Non mi è chiarissima come posso creare una relazione - e soprattutto una maschera di inserimento dati - tra un ID_Generale (univoco) e tanti asset riferiti al medesimo ID_Generale. 

    Diciamo che, l'idea è quella di creare delle maschere di inserimento per popolare le tabelle (di fatto 0_Tipo_Siti per l'anagrafica, 1_Riepilogo con il resto dei dati e 2_Stato_Asset per gli asset, appunto), compilando alcuni campi alla volta. Faccio un esempio, tipo per aggiungere un nuovo sito, avrò una maschera per tutti i campi di 0_Tipo_Siti, poi avrò una maschera per i campi a parità di ID_Generale (o Nome_Sito) i campi Data_Notifica, Normativa_Notifica, Data_PdC, Data_AdR e Data_POB_MISO. Vorrei poi una maschera in cui ‘selezionando’ il sito appropriato io possa aggiungere vari asset. 

    Infine, quello che potrebbero essere le interrogazioni, sarà la generazione di report, incrociando questi dati.

    Spero di essere stato più esaustivo.

    Ringrazio di nuovo tutti per i consigli (e i cazziatoni), apprezzate che sto provando a fare il salto (nel buio) da un file .xlsx ad un db.

    Grazie ancora ,

    S

  • Re: Struttura database e relazioni tra tabelle - cosa mi sfugge ?

    Senza sapere NE LEGGERE, NE SCRIVERE, ti si puo' gia dire: NON VA ANCORA.

    La tabella 1_Riepilogo_1 E' UN POLPETTONE!!!

    Contiene TROPPI CONCETTI, che corrispondono ai nomi delle colonne.

    OGNI TABELLA deve contenere UN'UNICO CONCETTO.

    Inoltre, ci sono delle REGOLE per assegnare i nomi delle tabelle e delle colonne, che aiutano a capire SE la tabella ha senso oppure no.

    Ultimo, ma non meno importante: DECIDITI, tutto in INGLESE OPPURE tutto ITALIANO.
    Evita come la PESTE QUALUNQUE CARATTERE NON ASCII standard, nei nomi degli oggetti. Usa SOLO

    A-Z a-z 0-9 _

    Se proprio proprio non se ne puo' fare a meno: @, $

    E NIENTE ALTRO.

    Inoltre, ci sono DUE modi per scrivere gli identificatori composti da piu' parole:

    • ‘camelCase’: ilNomeDellOggetto, OPPURE IlNomeDellOggetto
    • ‘snake_case’: il_nome_dell_oggetto
    • ‘SNAKE_CASE’: IL_NOME_DELL_OGGETTO

    Il tuo e' un ibrido, che potrebbe anche andare bene, ma tutto sommato meglio attenersi alle regole di “buon vicinato”


    Ma ti sei studiato le forme normali?
    Hai capito come si progetta un database?

    Fino a che vai a tentoni, SPERANDO di azzeccare la soluzione corretta, … , campa cavallo che l'erba cresce …

  • Re: Struttura database e relazioni tra tabelle - cosa mi sfugge ?

    Vorrei dirti che puoi rispondermi tranquillamente, se fossi già skillato sulle cose, non sarei qui. 

    Chiaro che sto semplicemente chiedendo una mano, probabilmente anche se concetti per voi molto base, ma non c'è bisogno di scaldarsi. Pensavo che chiedere - gentilmente ed educatamente - una mano, ammettendo fin da subito i miei limiti, fosse una cosa positiva. Pare di no.

    Se le mie domande sono un problema, chiudiamo pure qua, in qualche modo farò.

    Grazie ancora a tutti quelli che hanno risposto!

    Buona serata

    S

  • Re: Struttura database e relazioni tra tabelle - cosa mi sfugge ?

    15/03/2024 - stealbi ha scritto:


    Vorrei dirti che puoi rispondermi tranquillamente, se fossi già skillato sulle cose, non sarei qui.

    Non prenderla a male se qualcuno di contesta il modo di operare. Cerca invece di fare tesoro dei consigli che ti vengono dati. Anche io ho approcciato Access come Te un passo alla volta: cio' che vuoi ottenere e' sicuramente molto impegnativo e se vuoi partire con il piede giusto il consiglio che posso darti e' di fare un passo indietro, azzerare il concetto del DB che vuoi ottenere e studiare prima che come funziona un database relazionale, come si struttura, cosa e' un grafico E-R (base per strutturare bene il DB) e di conseguenza quanto gia' suggerito dai colleghi sopra.

    Alternativa e' creare il “polpettone” (cit.) che hai descritto sopra e trovarti con una marea di problemi dopo, non ultimo quello di dover rifare tutto da zero.

    Non pensare ad Access come un Excel avanzato: e' un errore che i principianti, devi ragionare per insiemi omogenei (quindi occorre anche una base di insiemistica)….

  • Re: Struttura database e relazioni tra tabelle - cosa mi sfugge ?

    15/03/2024 - Mailman ha scritto:


    15/03/2024 - stealbi ha scritto:


    Vorrei dirti che puoi rispondermi tranquillamente, se fossi già skillato sulle cose, non sarei qui.

    Non prenderla a male se qualcuno di contesta il modo di operare. Cerca invece di fare tesoro dei consigli che ti vengono dati. Anche io ho approcciato Access come Te un passo alla volta: cio' che vuoi ottenere e' sicuramente molto impegnativo e se vuoi partire con il piede giusto il consiglio che posso darti e' di fare un passo indietro, azzerare il concetto del DB che vuoi ottenere e studiare prima che come funziona un database relazionale, come si struttura, cosa e' un grafico E-R (base per strutturare bene il DB) e di conseguenza quanto gia' suggerito dai colleghi sopra.

    Alternativa e' creare il “polpettone” (cit.) che hai descritto sopra e trovarti con una marea di problemi dopo, non ultimo quello di dover rifare tutto da zero.

    Non pensare ad Access come un Excel avanzato: e' un errore che i principianti, devi ragionare per insiemi omogenei (quindi occorre anche una base di insiemistica)….

    Mi sembra di aver chiarito subito che sono ASSOLUTAMENTE un neofita in questo campo, sono il primo ad ammettere limiti ed errori. Ci sto provando, sto cercando di capire le cose, di provarci (tant'è che ho completamente rivoluzionato il db, senza otterne nulla tra l'altro).

    Se la soluzione è vai su google e fai da te, va bene prendo atto, e TORNO su google per cercarmi le risposte. 

    Ho comunque ringraziato tutti per chi ci ha provato a darmi una mano, ho apprezzato molto.

  • Re: Struttura database e relazioni tra tabelle - cosa mi sfugge ?

    15/03/2024 - stealbi ha scritto:


    Mi sembra di aver chiarito subito che sono ASSOLUTAMENTE un neofita in questo campo, sono il primo ad ammettere limiti ed errori. Ci sto provando, sto cercando di capire le cose, di provarci (tant'è che ho completamente rivoluzionato il db, senza otterne nulla tra l'altro).

    Se la soluzione è vai su google e fai da te, va bene prendo atto, e TORNO su google per cercarmi le risposte. 

    Ho comunque ringraziato tutti per chi ci ha provato a darmi una mano, ho apprezzato molto.

    La soluzione che ti viene fornita non è “vai su Google”, anzi… però non è che basta dire “SONO NEOFITA” e pensare che ti venga erogato un corso accelerato ONLINE…!!!

    Quindi se non studi per appropriarti di nomenclatura e concetti di base, partendo dai suggerimenti dati, non sarà possibile aiutarti perchè le informazioni i suggerimenti che ti vengono forniti non saranno alla tua portata.

    Consentici di poterti aiutare partendo dal fatto che almeno tu comprenda tecnicamente i termini e gli argomenti di cui è necessrio parlare senza doverti fornire “PAPPA PRONTA” e nemmeno un Corso per farti capire… altrimenti ovviamente non è fattibile.

Devi accedere o registrarti per scrivere nel forum
23 risposte