Struttura database e normalizzazione tabelle

di il
33 risposte

Struttura database e normalizzazione tabelle

Buongiorno,
sto creando un database access per organizzare i dati ecologici delle mie ricerche sui fiumi. Premetto che è la prima volta che creo un database access. Ho cercato di strutturarlo seguendo le formule normali (le prime tre) ma mi sa che qualche errore c'è per cui anche perchè alcune regole non mi sono chiarissime. Vorrei avere un riscontro sulla struttura del database e su come sono organizzate le singole tabelle. Visto che il database è grandino inizierò a mostrare solo parte delle relazioni in modo che se ci sono errori sistemo quelli prima di procedere oltre.
Premessa iniziale: io faccio dei campionamenti in campo in alcuni giorni in alcuni siti in cui raccolgo varie tipologie di dati. (riguardo alla tipologia di substrato, alla portata, alle alghe, agli insetti, alla geologia, alla qualità delle acque....). Ho pensato di strutturare il database così: ogni tabella farà riferimente ad un singolo oggetto (es: portata, oppure substrato, oppure chimica dell'acqua.....) e tutte saranno legate ad una tabella centrale che è quella dei campionamenti (Sampling). La tabella Sampling è legata ad una tabella siti (Site) dove sono contenute informazioni riguardo ai siti di campionamento (coordinate, quota, litologia...).
La tabella Site è pertanto l'unica già compilata. Tutte le altre tabelle verranno riempite man mano attraverso delle maschere di immisione dati.
In particolare per ora ho:
-la tabella centrale (Sampling) con:
ID_Sampling: (la chiave primaria a cui sarà legato tutto, numerazione automatica)
ID_Site: (per legare la tabella Site): numerico
la data: (data) e l'ora (testo)
-la tabella Site con:
ID Site: (numerazione automatica)
Site: il nome del sito (testo)
L'area del bacino che insiste su quel punto (numerico) e la distanza dalla sorgente (numerico)
La cordinata x (numerico), y (numerico) e z (numerico)
il tipo di litologia (testo)
il nome del fiume (testo)
il peso medio dei ciottoli grandi (numerico), dei cittoli medi (numerico), dei ciottoli piccoli (numerico)
-la tabella degli Habitat (Macro_Sample) con:
ID_Macro Sample: numerazione automatica
ID_Sampling: numerico
ID_Operator: numerico
Area_Sampled: (area di campionamento): numerico
e poi una serie di campi (Microhabitat_ARG..) che sono campi numerici che fanno riferimento alla percentuale di area campionata in cui vi è argilla, ghiaia..
ho poi introdotto un campo calcolato: Total_Habitat che è la somma degli habitat sopra citati
-la tabella Field_Operator oltre alla chiave in numerazione automatica contiene il nome (Field_Operator) di chi effettua il campionamento.
-la tabella Flow che oltre alla chiave in numerazione automatica contiene la portata (numerico)

I miei dubbi a questo punto sono:
sto procedendo correttamente? posso avere tabelle (es Tab_Site) che contiene sia campi numerici che di testo? il campo Total_Habitat che è calcolato va bene inserirlo nella stessa tabella o andrebbe meglio farlo in una separata? (che conterrà solo ID_Macro_Sample e Total_Habitat)? se sì, perchè?

Scusate la lunga descrizione, spero si capisca. Grazie a chi saprà darmi un riscontro
Allegati:
30854_ba10003a78725e984178973fa280f21f.jpg
30854_ba10003a78725e984178973fa280f21f.jpg

33 Risposte

  • Re: Struttura database e normalizzazione tabelle

    La descrizione che hai fornito a ME non aiuta. Provo a usare un linguaggio più terra terra (alla mia maniera). Io scriverò delle "cose", tu correggimi dove sbaglio:
    1. Io Osvaldo Laviosa vado sul fiume Po con una bacinella e la riempio di "acqua"?
    2. Dentro questo campione di "acqua" (o altro?) cosa spero di trovarci dentro?
    3. Il giorno dopo faccio lo stesso sul fiume Adige.
    4. La settimana successiva faccio lo stesso sul Tevere.
    5. Un anno dopo ritorno su Po, Adige, Tevere in 3 giorni diversi e faccio la stessa cosa.

    Mi fermo qui per ora. Ho ragionato correttamente? Puoi darmi dei dati che a te interessa tracciare?
  • Re: Struttura database e normalizzazione tabelle

    Forse se posti un file di esempio è più facile farti vedere una possibile ristrutturazione sfruttando quello che hai già creato.
    Già si può dire che:
    • nella tabella Tab_Site:
      • il campo Litology deve essere sostituito in IDLitology (Intero Lungo) e relazionato ad una nuova tabella tblLitologies (campi:
        • IDLitology (Numerazione automatica, Intero Lungo, Chiave primaria)
        • Litology (Testo breve, dimensione es:25, Richiesto, Consenti lunghezza zero = No, Indicizzato = Duplicati non ammessi)
      • il campo River deve essere sostituito in IDRiver (Intero Lungo, Richiesto, Duplicati ammessi) e relazionato ad una nuova tabella tblRivers (campi:
        • IDRiver (Numerazione automatica, Intero Lungo, Chiave primaria)
        • River (Testo breve, dimensione es:25, Richiesto, Consenti lunghezza zero = No, Indicizzato = Duplicati non ammessi)
    • la tabella Tab_Macro_Sample la strutturerei così:
      • ID_Macro Sample (Numerazione automatica, Intero Lungo, Chiave primaria)
      • ID_Sampling (Numerico, Intero lungo, Richiesto, Indicizzato = Duplicati non ammessi)
      • ID_Operator (Numerico, Intero lungo, Richiesto, Indicizzato = Duplicati non ammessi)
      • Se Sampled_Area corrisponde con quella del Sito la eliminerei altrimenti lo sostituirei con IDSampled_Area (Numerico, Intero lungo, Richiesto) e relazionato ad una nuova tabella tblSampled_Areas : (campi:
        • IDSampled_Area (Numerazione automatica, Intero Lungo, Chiave primaria)
        • Sampled_Area (Testo breve, dimensione es:25, Richiesto, Consenti lunghezza zero = No, Indicizzato = Duplicati non ammessi)
        • i campi Microhabitat_... li toglierei e creerei :
          • una nuova tabella tblMicrohabitat_Types : (campi:IDMicrohabitat_Type (Numerazione automatica, Intero Lungo, Chiave primaria) e Microhabitat_Type (Testo breve, dimensione es:15, Richiesto, Consenti lunghezza zero = No, Indicizzato = Duplicati non ammessi)
          • una nuova tabella tblSampled_Area_Microhabitats : (campi:
            • IDSampled_Area_Microhabitat (Numerazione automatica, Intero Lungo, Chiave primaria)
            • IDSampled_Area (Numerico, Intero lungo, Richiesto, Indicizzato = Duplicati non ammessi)
            • IDMicrohabitat_Type (Numerico, Intero lungo, Richiesto, Indicizzato = Duplicati non ammessi)
        • il campo Total_Habitat va eliminato in quanto calcolato ed eventualmente gestito in fase di visualizzazione Query o Maschera o Report
  • Re: Struttura database e normalizzazione tabelle

    OsvaldoLaviosa ha scritto:


    La descrizione che hai fornito a ME non aiuta. Provo a usare un linguaggio più terra terra (alla mia maniera). Io scriverò delle "cose", tu correggimi dove sbaglio:
    1. Io Osvaldo Laviosa vado sul fiume Po con una bacinella e la riempio di "acqua"?
    2. Dentro questo campione di "acqua" (o altro?) cosa spero di trovarci dentro?
    3. Il giorno dopo faccio lo stesso sul fiume Adige.
    4. La settimana successiva faccio lo stesso sul Tevere.
    5. Un anno dopo ritorno su Po, Adige, Tevere in 3 giorni diversi e faccio la stessa cosa.

    Mi fermo qui per ora. Ho ragionato correttamente? Puoi darmi dei dati che a te interessa tracciare?
    si è giusto. Faccio un esempio riferito al mio studio:
    io Bon il giorno 10 Maggio alle h 9.00 vado nel sito PO1 (che si trova sul fiume Po alle coordinate x 45000 e y 12000 e alla quota di 545 m, ha una litologia silicea, si trova a 120 km dalla sorgente e ha un area del bacino di 15000 km2, dimensione media sassi grandi di 10,5 Kg....) e lì campiono 1 mq di fiume di cui il 20% è composto da argilla, il 30 % da ghiaia e il 50% da sassi piccoli. Inoltre misuro la portata che è di 5 mc/s. Alle h 16 dello stesso giorno sempre io vado alla stazione D02 (Dora Baltea, coordinate...., distanza...litologia vulcanica, ....) e campiono 1 mq di fiume di cui il 50% è composto da sasssi medi, il 50 % da sassi grandi. La portata in questo caso è 2 mc/s. Il mese dopo 11 Gigno alle h 11:00 il mio collega Pinco Palla va a campionare al sito SE03 (fiume Sesia, coordinate...litologia scistosa,...) e campiona 1 mq di fiume così composto:....e la portata è di 3 mc/s mentre alle h 17:00 Pinco Palla ricampiona a PO1 1 mq di fiume così composto..... e la portata è di 6 mc/s...

    Intanto i dati che mi interessa tracciare sono: chi va a campionare, dove va, quando va, la composizione dell'habitat che campiona (come si divide in percentuale il mq di fiume tra argilla, ghiaia...) e il valore di portata.
    Poi ho moltri altri dati (quante alghe ci sono, di che taxa sono, quali insetti ci sono, di che taxa sono, di che dimensione, quanti sono, quale è il pH dell'acqua, l'ossigeno disciolto, la concentrazione di inquinanti....ma queste le vediamo man mano). Intanto Grazie
  • Re: Struttura database e normalizzazione tabelle

    Per me sassi, meduse, granchi, polveri...sono tutti la stessa cosa. Non so come chiamarli, dico per semplificazione Entità.
    Un Operatore fa molte Rilevazioni. Ogni Rilevazione ha dei DettagliRilevazioni dove scrive tutte le Entità raccolte e una per una le misura. Un MIO primo approccio (considerato che non conosco specifici termini tecnici) sarebbe:

    Operatori
    IDOperatore (PK)
    Cognome
    Nome

    Rilevazioni
    IDRilevazione (PK)
    TimeRilevazione (con il formato Data/Ora completo)
    IDComune (FK)
    NomeLuogo
    Coordinate (che potresti suddividere in più campi se lo ritieni opportuno)
    QuantitàCampioneGenerale (prendi con le pinze la denominazione di questo campo)
    IDOperatore (FK)

    DettagliRilevazioni
    IDDR (PK)
    IDEntità (FK)
    Dimensioni
    Peso
    Quantità
    IDRilevazione (FK)

    Entità
    IDEntità (PK)
    NomeEntità
    ...altri eventuali campi che specificano di cosa si tratta (Gruppo, Genere, Famiglia, Specie...non conosco tutte le classificazioni precise...)

    Comuni
    IDComune
    Comune
    CAP
    Provincia
    Regione
    Stato

    Relazioni:
    Operatori.IDOperatore uno-a-molti Rilevazioni.IDOperatore
    Rilevazioni.IDRilevazione uno-a-molti DettagliRilevazioni.IDRilevazione
    Comuni.IDComune uno-a-molti Rilevazioni.IDComune
    Entità.IDEntità uno-a-molti DettagliRilevazioni.IDEntità
  • Re: Struttura database e normalizzazione tabelle

    Grazie,
    mm rispetto al fatto di mettere tutti i dati di rilevamento in unica tabella (Entità) non sarei troppo sicuro perchè sono dati molto eterogenei e anche dal punto di vista logico mischiare sassi con meduse non è proprio il massimo, però questo si vedrà in un secondo momento.
    Invece il dubbio che ho è che le soluzioni che mi ha fornito OsvaldoLaviosa e Stifone sono diverse tra loro, c'è qualche criterio per capire quale va meglio o entrambe vanno bene? e perchè la mia struttura è sbagliata?
    Perchè per esempio le coordinate (e il NomeLuogo) secondo OsvaldoLaviosa andrebbero inserite nella tabella Rilevamenti? Una delle regole della normalizzazione è che ciascuna tabella deve contenere campi che fanno riferimento allo stesso oggetto reale no? Quindi tutte le info spaziali dovrebbero far riferimento ad una tabella Siti (con eventualmente anche il comune, la regione..), corretto?
    Invece rispetto ai suggerimenti di Stifone volevo chiedere: quanto è importante che Litology, River, Sampled Area.. siano stoccati in altre tabelle? Dipende dal numero di campi? Perchè per esempio i fiumi potrebbero effettivamente diventare tanti un domani ma l'area campionata è sempre 1 mq (la metodologia è standard) così come la litologia è abbastanza fissa (3 possibilità).
    Grazie
  • Re: Struttura database e normalizzazione tabelle

    Bon ha scritto:


    Perchè per esempio le coordinate (e il NomeLuogo) secondo OsvaldoLaviosa andrebbero inserite nella tabella Rilevamenti? Una delle regole della normalizzazione è che ciascuna tabella deve contenere campi che fanno riferimento allo stesso oggetto reale no? Quindi tutte le info spaziali dovrebbero far riferimento ad una tabella Siti (con eventualmente anche il comune, la regione..), corretto?
    Dubbio superlecito.
    Se ritieni che davvero tutte-tutte quelle informazioni di "localizzazione" hanno una ripetitività sistematica, fai come hai detto tu.
    Io mi sono lasciato guidare da un database simile dove il Ricercatore faceva prelevamenti su fiumi, coste ecc... Accadeva che lui rilevava per esempio (invento)
    Po\Foce nord
    Po\Foce centro
    Po\Foce sud
    Questi 3 valori li potremmo incanalare in unica tabella, ma poi anche all'interno di ognuna di quelle 3 voci ci potevano essere ulteriori sottodistinzioni...a tal punto che oggi si usano le Coordinate. Ma quanta "ripetitività sistematica" vi è in un Luogo con Coordinate a,b,c oppure x,y,z, oppure d,e,f,...? Anche per i 3 Po (almeno nel caso del database di cui parlavo) non vi era ripetitività sistematica.
    Valuta bene ciò che tu ritieni abbia davvero una ripetitività sistematica.
  • Re: Struttura database e normalizzazione tabelle

    Bon ha scritto:


    Intanto i dati che mi interessa tracciare sono: chi va a campionare, dove va, quando va, la composizione dell'habitat che campiona (come si divide in percentuale il mq di fiume tra argilla, ghiaia...) e il valore di portata.
    Fin qui credo di essermi avvicinato molto con la mia struttura tabelle proposta.

    Bon ha scritto:


    Poi ho moltri altri dati (quante alghe ci sono, di che taxa sono, quali insetti ci sono, di che taxa sono, di che dimensione, quanti sono, quale è il pH dell'acqua, l'ossigeno disciolto, la concentrazione di inquinanti....ma queste le vediamo man mano).

    Bon ha scritto:


    rispetto al fatto di mettere tutti i dati di rilevamento in unica tabella (Entità) non sarei troppo sicuro perchè sono dati molto eterogenei e anche dal punto di vista logico mischiare sassi con meduse non è proprio il massimo, però questo si vedrà in un secondo momento.
    Provo a fare un passo indietro io. Tu dici che ci sono "dati da rilevare" che sono molto "disomogenei". Come ti comporti al riguardo? Voglio dire, quando vai sul fiume Po il Giorno/Ora xx/yy/zzzz hh:mm con la bacinella, tu raccogli contemporaneamente dati disomogenei? Se sì, come vorresti tracciarli (spiegami a parole terra terra per chi come me non conosce i tuoi termini tecnici)? E poi puoi elencarmi tutte "quelle Entità" nelle tue "diverse" tabelle con tutti i loro campi?
    Bada bene che, se sto proponendo l'alternativa di separare le varie Entità, è perchè si ritiene che i dati "disomogenei" non verranno mai raccontati insieme, ma separatamente (con query e report).
  • Re: Struttura database e normalizzazione tabelle

    Intanto puoi leggere qualche cosa qui https://www.ionos.it/digitalguide/hosting/tecniche-hosting/minimizzare-le-ridondanze-del-database/
    Per quanto riguarda:
    • "l'area campionata se è sempre 1 mq" e allora non c'è motivo di inserirla
    • "la litologia è abbastanza fissa (3 possibilità)" se le possibilità di scelta sono sempre solo 3 non c'è effettivamente la necessità di creare una tabella ma se potrebbero aumentare allora sarà necessario creare la tabella per evitare di rimettere mano su diversi oggetti e magari anche nel codice del database.
  • Re: Struttura database e normalizzazione tabelle

    Provo a fare un passo indietro io. Tu dici che ci sono "dati da rilevare" che sono molto "disomogenei". Come ti comporti al riguardo? Voglio dire, quando vai sul fiume Po il Giorno/Ora xx/yy/zzzz hh:mm con la bacinella, tu raccogli contemporaneamente dati disomogenei? Se sì, come vorresti tracciarli (spiegami a parole terra terra per chi come me non conosce i tuoi termini tecnici)? E poi puoi elencarmi tutte "quelle Entità" nelle tue "diverse" tabelle con tutti i loro campi?
    Bada bene che, se sto proponendo l'alternativa di separare le varie Entità, è perchè si ritiene che i dati "disomogenei" non verranno mai raccontati insieme, ma separatamente (con query e report).
    [/quote]


    Ok, ora sto sistemando la prima parte della tabella.
    Rispetto al resto. Quando dico disomogenei intendo che per esempio raccolgo dati che si riferiscono a oggetti ambientali diversi (es: piante, animali, rocce..) per esempio avrò dati di chimica dell'acqua (quando vado al fiume prendo 1 litro di acqua lo porto al laboratorio e dopo un mese ricevo dati con le concentrazioni di sodio, calcio, ferro...) e allo stesso tempo campiono 1 mq di fiume in cui sono 1000 insetti di cui 50 sono plecotteri, (in cui c'è Pinco, Pluto..) 200 sono efemerotteri (in cui c'è...) e così via e allo stesso tempo raccolgo delle alghe che il giorno dopo analizzo per vedere quante diatomee ci sono, quanti cianobatteri..

    Tutti questi dati (che sono tanti) pensavo di stoccarli in tabelle separate per due motivi:
    -ogni tabella si riferisce ad un unico oggetto (tab chimica con le concentrazioni dei vari elementi, tab alghe con le quantità dei vari gruppi algali (diatomee, cianobatteri..), tab insetti (con il numero di individui di ciascun gruppo)) così ho tabelle relativamente piccole e se poi studio solo gli insetti prendo solo quella tabella.
    -Ma soprattutto tutti questi dati io li avrò in tempi diversi (alcuni il giorno in cui vado in campo, alcuni il giorno dopo(Alghe), altri dopo 1 mese(chimica), altri dopo 1 anno(insetti)) per cui io ho delle maschere in cui man mano inserisco i dati che ho.
    es la maschera alghe mi permette di inserire i dati delle alghe e la uso il giorno dopo del campo in modo che i dati delle alghe vengono già stoccati, la maschera chimica la uso dopo un mese per stoccare i dati della chimica....

    Poi quando avrò tutti i dati li guarderò attraverso delle query apposite che mi uniranno dati di due o più tabelle a seconda delle mie esigenze.
    l'idea comunque è quella di unire tutto per avere una tabellona in cui a ogni campionamento (riga) o dati del luogo, orario, chimica, alghe, insetti....)
  • Re: Struttura database e normalizzazione tabelle

    Ottimo, grazie per i suggerimenti.
    Ora la mia domanda è:
    sto creando delle tabelle con i campi calcolati in modo da diminuire l'effetto raggera. Quindi Tab_Algae_Coverage sarà collegata a C_Algae_Coverage (tabella dei dati di alghe calcolati) tramite un ID_Algae_Coverage
    Quindi per esempio ho la tabella Tab_Algae_Coverage in cui ho dati di massa e la superficie (e altri campi numerici), vorrei calcolare la massa delle alghe (Mass_Algae che è Weight_100-Weight_tara moltiplicata per il volume) e la densità (Algae_Coverage che è Mass_Algae/Surface) e salvare il risultato nella tabella C_Algae Coverage.
    (prima calcolavo tutto in Tab_Algae_Coverage)
    alghe.JPG
    alghe.JPG

    Come faccio a inserire nella maschera di inserimento dati delle alghe l'ID_Algae_Coverage?? in modo da poter compilare la tabella C_Algae_Coverage..? (prima mi bastava ID_Sampling che c'era già nella maschera) Grazie!
  • Re: Struttura database e normalizzazione tabelle

    Bon ha scritto:


    sto creando delle tabelle con i campi calcolati in modo da diminuire l'effetto raggera.
    Questa è sicuramente una strada sbagliata.
    1. I campi calcolati sono sconsigliati, si possono usare per piccole e rapide incombenze che non creano danni al resto dell'organigramma tabelle. Non è certamente il tuo caso. I calcoli vanno delegati alle QUERY.
    2. L'effetto "ragnatela" si risolve con una ben ragionata strutturazione tabelle. Io non ho ancora capito vari passaggi. Le denominazioni in inglese non mi aiutano. Non conosco molti termini tecnici del tuo campo professionale e, in mancanza di recordset di dati dai quali si possono sgrossare le inutili ridondanze, diventa impossibile venire a capo del tutto.

    Per me mettere mano a codici VBA adesso è prematuro.

    Per Stifone: sembra tu abbia capito qualcosa in più di me...se ci sei riuscito...io dico Amen e passo volentieri la palla.
  • Re: Struttura database e normalizzazione tabelle

    Forse se posti ciò che hai realizzato fino ad ora con un minimo di dati, sostituendo eventuali dati sensibili, sarebbe più facile capire quale è la sistuazione reale per poi aiutarti.
  • Re: Struttura database e normalizzazione tabelle

    Ok grazie,
    provo a postare quello che ho fatto fino ad esso. In realtà pensavo di mettere i campi calcolati in tabelle associate e poi nella query unire tutto ma se è meglio evitare allora posso fare il join e poi calcolare cioè che mi serve nella query (è che nella query volevo avere solo ciò che mi serviva non tutto tutto).

    -la struttura del database fino ad ora è la seguente: dove:
    -Tab_Sampling è la tabella centrale dei campionamenti
    Tab_sampling.JPG
    Tab_sampling.JPG

    -Tab Site è una tabella che contiene le info sui siti di campionamenti (aggiustata secondo i suggerimenti di Stifone ma lasciando i campi mass e litology in quanto hanno poche voci e non si amplieranno in futuro)
    Tab_Siti.PNG
    Tab_Siti.PNG

    -Tab_Macro_Sample è la tabella degli habitat in cui ho tolto il campo calcolato e ho messo un pulsante di controllo (la somma di ARG, MAC,GHI...deve essere 100. i quali campi li ho lasciati lì in quanto possono assumere poche voci (0,10,20,30,40,50))
  • Re: Struttura database e normalizzazione tabelle

    -Tab_Chemistry contiene campi numerici con concentrazioni di elementi
    tab_chimica.PNG
    tab_chimica.PNG

    -Tab_Algae_Coverage contiene dati numerici relative alle alghe
    tab_alghe.PNG
    tab_alghe.PNG

    C_Alghe_Coverage dovrebbe contenere campi calcolati relative alle alghe a partire dalla maschera di inserimento dati delle alghe
Devi accedere o registrarti per scrivere nel forum
33 risposte