Da Google Sheet a uno schema relazionale: piano di modellazione passo dopo passo

Perché i fogli di calcolo diventano disordinati quando li trasformi in database

Un foglio di calcolo è ottimo per una lista piccola. Puoi cambiare colonne al volo, aggiungere note ovunque e correggere a vista. Quella libertà comincia a rompersi quando il file diventa una fonte di verità condivisa.

Con la crescita dei dati, gli stessi problemi riemergono. Vedi duplicati perché non esiste un unico posto per memorizzare un cliente o un prodotto. Ottieni valori in conflitto perché due righe non sono d'accordo sulla stessa cosa, come un numero di telefono. Filtri e report diventano frustranti perché alcune colonne nascondono liste ("Tags", "Products", "Attendees") o mescolano formati ("$1,200", "1200", "1.2k").

Passare da un Google Sheet a uno schema relazionale riguarda la sicurezza dei dati. Un database impone una struttura più chiara così puoi interrogare, convalidare e aggiornare i dati senza creare nuove contraddizioni.

Un modello mentale utile: una riga dovrebbe rappresentare una cosa reale. Se una riga rappresenta un deal, un cliente e una lista di prodotti, aggiornare una di queste in seguito sarà doloroso.

Un test rapido: una singola riga ha mai bisogno di due valori per lo stesso campo?

• Un ordine ha più prodotti
• Un progetto ha più membri del team
• Un cliente ha più indirizzi

Se la risposta è sì, non è un problema di “riga larga”. È un problema di “tabella separata”. Una volta modellato in modo pulito, puoi costruire moduli e convalide sopra invece di contare su modifiche manuali fragili.

Parti dal definire cosa rappresenta davvero il foglio

Un foglio può sembrare organizzato ma significare cose diverse per persone diverse. Prima di convertire un Google Sheet in uno schema relazionale, mettetevi d'accordo su cosa sta tracciando il foglio.

Inizia dagli esiti, non dalle colonne. Quali decisioni devono supportare i dati: un report settimanale delle entrate, una lista di ticket scaduti, un workflow che assegna follow-up o una ricerca rapida durante una chiamata con il cliente? Se non riesci a nominare una decisione, quel campo spesso non appartiene al database.

Poi estrai i sostantivi nascosti nelle intestazioni e nelle note. Questi di solito diventano le tue future tabelle: customers, orders, products, invoices, tickets, agents, locations. Se una colonna mescola due sostantivi (come “Customer + Company”), stai memorizzando più cose in un unico posto.

Accordatevi sulle definizioni fin da subito

Piccole differenze di significato diventano grandi pulizie dopo. Chiarite i fondamenti:

• Cosa conta come “order” (un preventivo, un acquisto pagato o entrambi)?
• Che cos'è un “customer” (persona, azienda o entrambi)?
• Un ordine può avere più prodotti?
• Una email può appartenere a più clienti?
• Cosa deve mostrare lo “status” (stato corrente o storico)?

Esempio: se il tuo foglio ha una riga per “Order” ma la cella “Products” contiene una lista separata da virgole, decidete se quella riga rappresenta un checkout, una spedizione o una fattura. Ogni scelta porta a uno schema diverso.

Congela una copia del foglio originale in sola lettura. La userai per verificare che le nuove tabelle rispondano ancora alle stesse domande.

Pulisci il foglio così la struttura è visibile

Prima di convertire un Google Sheet in uno schema relazionale, fai sembrare il foglio dati, non un report. I database hanno bisogno di righe e colonne coerenti. Layout decorativi nascondono schemi che devi modellare.

Rimuovi trucchi di layout come celle unite, più righe di intestazione e subtotali dentro l'intervallo dati. Mantieni una sola riga di intestazione e poi solo righe di record. Se ti servono totali, mettili in una scheda di riepilogo separata così non si mescolano ai record veri.

Poi rendi i formati coerenti in ogni colonna. Un database non può indovinare che “1/2/24”, “2024-02-01” e “Feb 1” siano la stessa data. Lo stesso vale per numeri di telefono, valute e nomi. Scegli un formato e usalo ovunque, anche se sembra rigido.

Una breve pulizia che di solito ripaga:

• Assicurati che ogni riga rappresenti una cosa sola (un ordine, un cliente, un ticket).
• Rimuovi righe e colonne vuote di separazione.
• Sostituisci “N/A”, “-” e stringhe vuote con una regola unica che seguirai.
• Segna quali colonne sono calcolate e quali sono digitate da una persona.

Infine, segnala ogni cella che contiene valori multipli, come “red, blue, green” in una colonna. Non correggere ancora lo schema. Segnala solo quelle colonne così ti ricorderai che diventeranno righe separate dopo.

Identifica gruppi ripetuti e campi che nascondono liste

Il segnale di avviso più grande nella modellazione dei dati da foglio è la ripetizione. I fogli spesso comprimono “più di una cosa” in una singola riga ripetendo colonne o impacchettando più valori in una cella. Questo funziona per il tracking veloce, poi si rompe quando servono filtri, report o aggiornamenti coerenti.

Schemi che solitamente significano “questo dovrebbe essere un'altra tabella”

Scansiona queste forme:

• Colonne numerate come Item 1, Item 2, Item 3 o Phone 1, Phone 2.
• Blocchi ripetuti come campi indirizzo duplicati per “Home” e “Work”.
• Celle con virgole, interruzioni di riga o “e” che combinano valori (per esempio, “Mouse, Keyboard, Monitor”).
• Una colonna che mescola due concetti, come “Approved 2025-01-10” o “Alex (Manager)”.
• Una riga che rappresenta due livelli insieme, come una riga Order che prova anche a memorizzare tutti gli Order Items.

Esempio: se il tuo tracker vendite usa Order ID, Customer, Product 1, Qty 1, Product 2, Qty 2, arriverai a un muro. Alcuni ordini hanno 1 articolo, altri 8. Il foglio o cresce all'infinito in larghezza o inizia a perdere dati. In un modello relazionale, “Orders” diventa una tabella e “Order Items” diventa un'altra tabella con una riga per ogni prodotto nell'ordine.

Per le “liste in una cella”, tratta ogni valore come un proprio record. Una cella che dice “Email, SMS” di solito significa che hai bisogno di una tabella separata (o di una tabella di join) per tracciare i canali in modo pulito.

Le colonne miste sono più silenziose ma altrettanto rischiose. Dividile presto così ogni campo memorizzi un fatto chiaro.

Crea tabelle dalle entità che hai trovato

Una volta che riesci a nominare le cose del mondo reale nel foglio, trasformane ciascuna in una tabella. Il tuo foglio smette di essere una grande griglia e diventa un insieme di liste più piccole e mirate.

Se una riga mescola dettagli su due cose diverse, probabilmente servono due tabelle. Una riga di tracking vendite potrebbe includere info cliente (nome, telefono), info ordine (data, stato) e info prodotto (SKU, prezzo). I clienti non cambiano ogni volta che cambia un ordine, e i prodotti non dipendono da un singolo ordine. Separandoli eviti modifiche duplicate e valori non corrispondenti.

Prima di finalizzare, scrivi una frase di scopo per ogni tabella. Se non riesci a descrivere cosa rappresenta una tabella senza dire “e anche”, di solito è troppo ampia.

Alcune regole pratiche:

• Mantieni insieme gli attributi che descrivono la stessa cosa e condividono lo stesso ciclo di vita (nome cliente e email cliente).
• Sposta qualsiasi cosa che può apparire più volte in una sua tabella (più order items, più indirizzi).
• Se una cella contiene una lista (valori separati da virgole, colonne ripetute), quella è una tabella separata.
• Se due set di campi cambiano per motivi diversi, separali (stato ordine vs info di contatto cliente).

Poi dai nomi chiari e coerenti alle colonne. Preferisci sostantivi semplici ed evita etichette vaghe come “Info” o “Details”.

Scegli chiavi che rimangono stabili nel tempo

Scegli una chiave primaria per ogni tabella fin da subito. Una buona chiave è noiosa: non cambia mai, è sempre presente e identifica una sola riga.

Le chiavi naturali (valori del mondo reale) possono funzionare, ma solo se sono davvero stabili. Uno SKU spesso è una buona chiave naturale perché è pensata per essere permanente. Gli indirizzi email sembrano stabili, ma le persone li cambiano, condividono caselle e creano duplicati come “john@” e “john.work@”. Nomi, telefoni e indirizzi cambiano e non sono garantiti unici.

Un default sicuro è un ID generato automaticamente (come customer_id, order_id). Mantieni l'identificatore naturale come campo normale e aggiungi una regola di unicità quando è adatta alle tue regole di business. Se un'email cambia, il customer_id resta lo stesso e gli ordini correlati puntano ancora al cliente giusto.

Regole semplici per le chiavi:

• Usa un ID auto quando l'identificatore reale potrebbe cambiare, mancare o essere riutilizzato.
• Usa una chiave naturale solo quando la controlli e sia progettata per essere permanente (per esempio, SKU).
• Segna i campi come unici solo quando i duplicati sarebbero sbagliati.
• Consenti NULL solo quando “sconosciuto” è uno stato valido; altrimenti richiedi un valore.
• Scrivi cosa significa “unico” (unico per tabella, per azienda o per periodo di tempo).

Esempio: in una tabella Contacts, usa contact_id come chiave primaria. Tieni email unica solo se la tua regola è un contatto = una email. Permetti che phone sia vuoto perché non tutti lo condividono.

Mappa le relazioni senza indovinare

La maggior parte degli errori gravi nasce dall'indovinare come le cose si relazionano. Usa una regola semplice: se una riga “possiede” molti di qualcosa, è uno-a-molti. Metti la foreign key sul lato “molti”.

Esempio: un Customer può avere molti Orders. La tabella Orders dovrebbe memorizzare customer_id. Se tieni una lista di numeri d'ordine separata da virgole dentro Customers, presto compariranno duplicati e dati mancanti.

Molti-a-molti è la trappola comune del foglio. Se un Order può includere molti Products e un Product può apparire in molti Orders, ti serve una tabella di join (spesso chiamata line items). Tipicamente include order_id, product_id, più campi come quantity e il prezzo al momento dell'acquisto.

Uno-a-uno è raro. Ha senso quando i dati aggiuntivi sono opzionali o separati per privacy o performance (per esempio, User e UserProfile). È un campanello d'allarme quando separi una tabella solo perché il foglio aveva due schede.

Lo storico ha una sua struttura. Se i valori possono cambiare nel tempo (status, prezzo, indirizzo), evita di sovrascrivere una singola colonna. Memorizza i cambiamenti come righe in una tabella di history così puoi rispondere a “qual era la verità in quella data?”.

Normalizza quanto basta per prevenire contraddizioni

Una regola semplice: memorizza un fatto in un solo posto. Se il numero di telefono di un cliente appare in cinque righe, qualcuno ne aggiornerà quattro e ne mancherà una.

La normalizzazione in termini pratici:

1NF, 2NF, 3NF in parole semplici

La prima forma normale (1NF) significa che ogni cella contiene un solo valore. Se una colonna contiene “red, blue, green” o “SKU1|SKU2|SKU3”, è una lista nascosta. Spezzala in righe in una tabella correlata.

La seconda forma normale (2NF) appare soprattutto negli line items. Se hai OrderItems e la chiave è (OrderID, ProductID), campi come CustomerName non appartengono lì. Dipendono dall'ordine, non dal prodotto.

La terza forma normale (3NF) significa che i campi non chiave non dovrebbero dipendere da altri campi non chiave. Esempio: se memorizzi ZipCode e City, e City è determinata dal ZipCode, rischi incongruenze.

Un rapido controllo:

• Lo stesso valore potrebbe essere modificato in più posti?
• Una modifica costringerebbe ad aggiornare molte righe?
• Stai memorizzando etichette che possono essere derivate da un ID?
• I totali sono memorizzati accanto alle righe che li generano?

Quando denormalizzare va bene

Denormalizza principalmente per reporting orientato alla lettura, e fallo in modo sicuro: tratta la tabella di report come una copia che puoi ricostruire. Mantieni le tabelle normalizzate come fonte di verità.

Per valori derivati come totali, saldi e stati, non duplicarli a meno che tu non abbia una regola chiara per ricalcolarli. Un approccio pratico: memorizza le transazioni raw, calcola i totali nelle query e memorizza in cache i totali solo quando le prestazioni lo richiedono.

Trappole comuni di modellazione che richiedono pulizie future

La maggior parte dei problemi “funzionava nel foglio” nasce dal significato, non dagli strumenti. L'obiettivo è far sì che ogni riga dica una cosa chiara, nello stesso modo, ogni volta.

Trappole comuni:

• Usare nomi come ID. “John Smith” non è un identificatore univoco e i nomi cambiano. Usa un ID generato (o un'email/telefono verificati) e tratta i nomi come etichette.
• Impacchettare liste in una cella. Sembra semplice, ma rompe ricerca, convalida e report. Le liste appartengono a una tabella correlata.
• Mescolare stato corrente con storico. Una singola colonna Status non può dirti sia l'ultimo stato sia come è cambiato. Se il timing conta, memorizza i cambiamenti come eventi con timestamp.
• Sovraccaricare una tabella per significare più cose. Un foglio Contacts che include clienti, fornitori e dipendenti finisce con campi che valgono solo per alcune righe. Separa per ruolo, o tieni una tabella Person condivisa e aggiungi tabelle specifiche per ruolo.
• Ignorare campi obbligatori vs opzionali. Se campi chiave possono essere vuoti, otterrai righe che non si uniscono bene. Decidi cosa è obbligatorio e applicalo presto.

Se la tua tabella Orders ha colonne come Item 1, Item 2, Item 3, stai vedendo un gruppo ripetuto. Pianifica una tabella Orders più una tabella OrderItems.

Checklist rapida prima di confermare lo schema

Prima di bloccare lo schema, fai un'ultima verifica per chiarezza. Gran parte del dolore del database dopo deriva da piccoli compromessi che sembravano innocui all'inizio.

Chiediti se ogni tabella risponde a una domanda semplice. “Customers” dovrebbe significare clienti, non clienti più il loro ultimo ordine più note delle chiamate. Se non riesci a descrivere una tabella in una frase breve, sta mescolando cose.

Controlli finali:

• Riesci a indicare la colonna (o l'insieme di colonne) che identifica univocamente ogni riga, anche se i nomi cambiano?
• Ci sono celle con più di un valore (tag separati da virgole, più email, colonne Item1/Item2)? Se sì, separa in una tabella figlia.
• Per ogni relazione, è memorizzata come una foreign key intenzionale? Per molti-a-molti, hai una tabella di join?
• I campi importanti hanno regole (obbligatori quando i dati mancanti rompono il processo, unici quando i duplicati sarebbero dannosi)?
• Puoi aggiornare un fatto (indirizzo cliente, prezzo prodotto, ruolo dipendente) in un solo posto?

Test di realtà: immagina che qualcuno inserisca lo stesso cliente due volte con una grafia leggermente diversa. Se il tuo schema lo rende facile, aggiungi una chiave migliore o una regola di unicità.

Esempio: trasformare un foglio tracker vendite in tabelle pulite

Immagina un tracker vendite dove ogni riga è un deal. Ha colonne come Customer Name, Customer Email, Deal Amount, Stage, Close Date, Products (lista separata da virgole) e Notes (a volte più note in una cella).

Quella singola riga nasconde due gruppi ripetuti: products (un deal può includere molti prodotti) e notes (un deal può avere molte note). Qui le conversioni spesso falliscono, perché le liste nelle celle sono difficili da interrogare e facili da contraddire.

Un modello “dopo” pulito che rispecchia come funziona davvero il lavoro:

• Customers (CustomerId, Name, Email)
• Deals (DealId, CustomerId, Amount, Stage, CloseDate)
• Products (ProductId, Name, SKU)
• DealProducts (DealId, ProductId, Quantity, UnitPrice)
• DealNotes (NoteId, DealId, NoteText, CreatedAt)

CustomerId, DealId e ProductId sono identificatori stabili. DealProducts risolve la relazione molti-a-molti: un deal può includere molti prodotti e un prodotto può apparire in molti deal. DealNotes tiene separate le note, così non ti ritrovi con “Note 1, Note 2, Note 3” in colonne.

Prima di modellare, un report come “fatturato per prodotto” significa dividere stringhe e sperare che le persone abbiano scritto i nomi in modo coerente. Dopo la modellazione diventa una query semplice su DealProducts unita a Deals e Products.

Passi successivi: passa dallo schema a un'app funzionante

Una volta che lo schema ti convince su carta, trasferiscilo in un database reale e testalo con dati reali. Non importare tutto in una volta. Carica prima un piccolo lotto, sistema quello che si rompe, poi ripeti.

Un ordine pratico che riduce il rischio:

• Crea tabelle e relazioni.
• Importa 50–200 righe, verifica i totali e controlla alcuni record.
• Risolvi problemi di mapping (colonne sbagliate, ID mancanti, duplicati), poi reimporta.
• Quando è stabile, carica il resto.

Aggiungi regole di convalida presto così le abitudini disordinate del foglio non ritornino. Rendi i campi obbligatori veramente obbligatori, limita i valori permessi (come gli status), valida i formati (date ed email) e usa foreign key così non puoi creare un ordine per un cliente che non esiste.

Poi smetti di usare il foglio per le modifiche. Proteggere i dati diventa molto più facile quando le persone hanno moduli semplici e workflow chiari.

Se vuoi trasformare lo schema in uno strumento interno senza scrivere codice, AppMaster (appmaster.io) può aiutare: modelli tabelle e relazioni visivamente e poi genera backend pronto per la produzione, web app e app native mobili dallo stesso modello.