Progetta fino alla terza forma normale, poi fai un passo indietro
Disponibile anche in 28 lingue
English · Español · 日本語 · Português (Brasil) · Français · Deutsch · 한국어 · 简体中文 · Português (Portugal) · 繁體中文 · Bahasa Indonesia · Türkçe · Polski · Tiếng Việt · ไทย · Nederlands · العربية · עברית · Українська · हिन्दी · Русский · Svenska · Dansk · Norsk bokmål · Suomi · Español (México) · Français (Canada) · Deutsch (Schweiz)
Modulo 5 di 6 del capitolo Modellare i dati per il loro significato, capitolo 2 del corso Data Architect. Ogni modulo si regge da solo. Precedente: Metti i dati dove devono stare · Successivo: Trasforma il modello in Salesforce
La domanda a cui risponde questo modulo: Quando dovrei allontanarmi intenzionalmente da un modello normalizzato pulito?
Nel modulo precedente ti ho detto di progettare fino alla terza forma normale.
Ora ti dirò di infrangerla.
A volte.
È una distinzione importante. C’è una grande differenza tra costruire per sbaglio un modello dati disordinato e denormalizzare deliberatamente un modello pulito. Se non capisci dove devono stare i dati in primo luogo, copiarli da un’altra parte non è architettura. È solo duplicazione.
Ma una volta capito il modello logico pulito, posso decidere consapevolmente di dare ai dati una forma diversa per le persone e i sistemi che li consumano.
Progetta fino alla terza forma normale dove è fattibile. Poi fai un passo indietro quando è necessario.
Nota cosa non dice quella frase. Non dice che la terza forma normale sia più facile da capire. A volte è più difficile: un modello completamente normalizzato può spargere un’unica idea di business su cinque oggetti, e chi lo usa deve rimetterla insieme a mente. La normalizzazione mi dice dove sta ogni fatto. Non promette che sia la forma più facile da leggere, da usare o su cui fare report. Proprio per questo fare un passo indietro è un’abilità di progettazione e non un fallimento.
Comincia modellando la verità. Poi decidi come quella verità deve essere consegnata.
Seduto, resta, modello
Sezione intitolata “Seduto, resta, modello ”Torniamo ai cani, e questa volta facciamo alcune scelte deliberate.
Razza: un elenco di selezione o una tabella sua? Passala attraverso le domande che ti darò più avanti in questo modulo. C’è più di una colonna di informazioni? Sì: almeno la taglia. Quanti valori? I kennel club riconoscono qualche centinaio di razze (solo l’American Kennel Club ne elenca 205), ben oltre la mia regola pratica di una ventina. Quindi Razza si guadagna una tabella sua, e ogni cane punta alla sua razza. Questo risolve la domanda che ci portiamo dietro dal modulo 1: Razza è un riquadro a sé.
Livello di abilità: un elenco di selezione. In apprendimento, Buono, Esperto. Tre etichette, nient’altro da dire su di loro, e non cambieranno. È esattamente lo scopo di un elenco di selezione.
Quanti esercizi conosce ogni cane? La risposta è già nel modello: conta i record Esercizio del cane del cane. Ma l’addestratore vuole quel numero su ogni report, per ordinare e filtrare in base a esso, senza costruire un report su due tabelle. Quindi faccio un passo indietro, e tengo un conteggio Esercizi conosciuti direttamente sul cane. È una copia. La verità vive ancora nell’Esercizio del cane; il conteggio ne è una rappresentazione, e deve restare allineato. Salesforce ci dà un modo pulito per fare esattamente questo, e lo vedremo nel modulo 6.
Ora il colpo di scena: la scuola per cani comincia ad accettare i gatti. Cosa facciamo? Un’opzione: aggiungere una tabella Gatto accanto alla tabella Cane, e un Esercizio del gatto accanto all’Esercizio del cane. Tutto raddoppia: due di ogni schermata, due di ogni report, e il giorno in cui accettano i conigli, tre. L’altra opzione: fare un passo indietro e notare che un gatto ha un proprietario, forse un allevatore, una razza, una data di nascita e, con pazienza, un esercizio o due. Gli stessi fatti e le stesse relazioni di un cane. Quindi generalizziamo: un Animale, con una Specie, cane o gatto. Anche ogni razza appartiene a una specie, ed è lì che la specie vive davvero: un Labrador è un cane. L’animale ne porta una copia, di proposito, così ogni schermata e ogni report possono partire da “cane o gatto?” senza andare a cercare la razza. Un’altra copia deliberata, e nel modulo 6 riceve un lavoro tutto suo.
Questo è progettare per il cambiamento, ed è un trade-off. Generalizza troppo presto e tutto diventa una vaga “Cosa” con un campo tipo che nessuno capisce. Io generalizzo quando il business mi porta davvero il secondo tipo, e i due condividono quasi tutto, come cani e gatti qui. Se i gatti avessero bisogno di fatti molto diversi, ci penserei due volte.
Ora lo stesso tipo di scelte in Steve Trucking, dove la posta in gioco è più alta.
Il modello più pulito non è sempre il sistema migliore
Sezione intitolata “Il modello più pulito non è sempre il sistema migliore ”Immagina una squadra a una tappa. La consegna ha i suoi articoli. L’installazione ha una checklist. Ogni passaggio richiede foto. Il Destinatario firma.
Il modello normalizzato è bellissimo: Consegna → Articolo della consegna → Checklist di installazione → Foto, ognuno al suo posto.
Poi mi siedo con le persone che lo usano davvero. Una squadra chiude una decina di tappe al giorno, nei vialetti, spesso senza segnale. Se il mio bellissimo modello le manda in un labirinto di schermate ed elenchi correlati per completare una tappa, ho un problema di architettura.
Il modello dati non è l’unica cosa che stiamo progettando.
Stiamo progettando un sistema.
A volte vince l’esperienza utente
Sezione intitolata “A volte vince l’esperienza utente ”È uno dei motivi per cui a volte mi allontano da un modello perfettamente normalizzato: l’esperienza utente.
Forse un concetto potrebbe tecnicamente essere un’entità a sé, ma separarlo aggiunge una complessità che porta pochissimo valore. Forse un padre con diversi livelli di figli è accademicamente pulito ma un tormento da compilare e mantenere. Forse il concetto è piccolo, stabile e usato soprattutto come selezione.
È qui che smetto di chiedermi solo “Dove sta in teoria questo fatto?” e comincio a chiedermi “Come verrà usato davvero questo sistema?”
Non significa che ogni lamentela per un clic in più appiattisca il modello. Significa che l’usabilità è un input architetturale legittimo.
A volte vince la reportistica
Sezione intitolata “A volte vince la reportistica ”La reportistica è un altro motivo frequente.
Ogni Partner retail vuole una scheda di valutazione: consegne puntuali per regione, per mese. Nel modello pulito, una consegna conosce il suo centro di distribuzione, e il CD conosce la sua regione. Tecnicamente possiamo navigare quel percorso.
Ma lo strumento di reportistica può? Possono farlo le persone che costruiscono da sé i propri report? Riescono a rispondere alla domanda senza un’architettura di reportistica più complicata della domanda stessa?
È allora che potrei copiare o derivare la regione sulla consegna, più vicino a dove viene consumata.
Ora ho introdotto una duplicazione. Quindi mi serve un’altra domanda: chi possiede la verità?
Se il valore di origine cambia, cosa succede alla mia copia? Deve cambiare? O deve conservare ciò che era vero quando è avvenuta la consegna? Sono requisiti diversi.
La denormalizzazione non elimina la complessità.
La sposta.
Relazione di ricerca o elenco di selezione?
Sezione intitolata “Relazione di ricerca o elenco di selezione? ”Ecco un esempio più piccolo che gli amministratori Salesforce incontrano di continuo. L’utente deve scegliere tra un insieme di valori. Creo un’altra entità e la collego, o uso un elenco di selezione?
Prendi lo stato di una consegna: pianificata, caricata, in consegna, in arrivo, consegnata, installata, eccezione, resa. Un elenco breve e stabile di etichette. Un elenco di selezione è esattamente ciò che voglio.
Ora prendi il tipo di tappa: solo consegna, consegna con installazione, consegna con ritiro dell’usato. Questo porta informazioni proprie: quanto dura la tappa, quali competenze servono alla squadra, quale checklist di installazione si applica. Cambia in modo indipendente, e lo gestisce il business. È un’entità, non un’etichetta.
Se creo un oggetto per ogni concetto che in teoria si potrebbe normalizzare, posso costruire un sistema tecnicamente bellissimo che nessuno ha piacere di usare. Se trasformo ogni concetto in un elenco di selezione perché è facile, posso chiudermi in un angolo molto in fretta.
Quindi mi chiedo: ha informazioni proprie? Relazioni? Cambia in modo indipendente? Deve essere gestito come dato? Il business potrebbe un giorno averne bisogno per qualcosa di più di un’etichetta?
Ecco le domande che pongo davvero in una sessione di progettazione.
C’è più di una colonna di informazioni? Se il valore ha bisogno di una descrizione, una durata, un elenco di competenze, un responsabile, non è più un’etichetta.
Quanti valori? La mia regola pratica è una ventina. Oltre i 20 valori un elenco di selezione comincia a cedere, ed è ora di pensare a un oggetto. Gli stati americani, una cinquantina, sono l’eccezione con cui conviviamo, e i paesi sono peggio; sinceramente, a qualcuno piacciono gli elenchi di selezione dei paesi? Io li trovo irritanti.
I valori vengono creati nel tempo, e da chi? Aggiungere un valore a un elenco di selezione è una modifica di configurazione, il che significa un amministratore. Se il business aggiunge valori ogni settimana, e chi li aggiunge non è un amministratore, un elenco di selezione mette un ticket davanti a ogni nuovo valore.
Le persone devono filtrare e fare report su di esso? Gli elenchi di selezione sono ottimi per questo. Le relazioni di ricerca non sono altrettanto pulite. Ogni relazione di ricerca aggiunge un salto: un tipo di report segue solo una breve catena di oggetti correlati (un tipo di report personalizzato consente al massimo quattro relazioni tra oggetti), la schermata si trasforma in elenchi correlati dentro elenchi correlati, e il codice si complica.
Un elenco di valori spesso nasce come elenco di selezione e, col tempo, si guadagna un oggetto tutto suo. Lascia che se lo guadagni.
A volte la scala cambia la risposta
Sezione intitolata “A volte la scala cambia la risposta ”Un progetto che funziona benissimo con qualche migliaio di record può comportarsi in modo molto diverso con milioni.
Quindi non guardare solo il diagramma. Conosci i numeri.
Steve Trucking fa circa un milione di consegne all’anno, con una crescita del 30 per cento l’anno. Ogni consegna raccoglie circa otto aggiornamenti di stato. Sono otto milioni di record di stato quest’anno, e circa 13,5 milioni l’anno entro il terzo anno. Aggiungi quattro o cinque milioni di foto all’anno.
Stesso modello. Architettura molto diversa.
Andremo molto più a fondo in Architecting at Scale. Per ora ricorda: il volume può cambiare una decisione di modellazione dei dati. Una relazione logicamente corretta non è automaticamente il miglior progetto fisico a ogni scala.
Consumatori diversi vogliono forme diverse
Sezione intitolata “Consumatori diversi vogliono forme diverse ”Finora abbiamo pensato al sistema operativo. I coordinatori assegnano le consegne ai percorsi. Le squadre chiudono le tappe. Il sistema cambia mentre il business lavora.
Ma il business vuole anche analizzare anni di storico. Quali partner e regioni sono in ritardo? Come è cambiato il tempo di consegna? Quanto spesso un’installazione richiede una seconda visita?
Un sistema analitico può volere le stesse informazioni organizzate in modo diverso. Sentirai termini come data warehouse, fatto, dimensione e schema a stella. Non li sviscereremo qui; in Steve Trucking è il data warehouse Snowflake, e ci torneremo più avanti nel corso.
Per ora: consumatori diversi possono aver bisogno di forme diverse della stessa verità.
L’IA aggiunge un altro consumatore
Sezione intitolata “L’IA aggiunge un altro consumatore ”E ora c’è un altro consumatore: l’IA.
Un Destinatario scrive: “Dov’è la mia consegna?”. Un assistente IA potrebbe trovare questo:
Consegna 10427, Percorso 3312, Tappa 7, Camion 117, Fascia 13:00–15:00.
Un’applicazione tradizionale è perfettamente contenta di seguire quelle relazioni. Ma per rispondere al Destinatario, l’assistente ha bisogno di un contesto raccolto da più punti:
La tua lavastoviglie Redrock è la settima tappa del percorso di oggi dal centro di distribuzione di Phoenix. Il camion è a tre tappe da te, e sei ancora nella tua fascia 13–15.
Abbiamo preso informazioni da diverse entità correlate e costruito una rappresentazione più piatta e ricca di contesto per un consumatore specifico.
Non significa che distruggo il mio modello normalizzato. E di certo non significa “all’IA piacciono i dati piatti, quindi metti tutto in un unico oggetto gigante”. Non farlo.
La fonte di verità resta pulita. L’IA riceve una rappresentazione costruita per il lavoro che deve fare. È la stessa idea che abbiamo appena visto con le analisi:
Un’unica fonte di verità può sostenere più forme di consumo.
Andremo molto più a fondo nel grounding e nel recupero delle informazioni più avanti nel corso.
Non creare più verità
Sezione intitolata “Non creare più verità ”Qui c’è un pericolo.
Se copio la regione sulla consegna per la reportistica, mando una versione appiattita a Snowflake e costruisco una versione ricca di contesto per l’assistente IA, quale di queste è corretta?
Quella domanda ha bisogno di una risposta. Voglio sapere dove risiede il valore autorevole. Tutto il resto è una rappresentazione di quella verità per uno scopo.
Quel posto è il system of record (sistema di registrazione). Le copie denormalizzate possono essere utili: la schermata della tappa, la scheda di valutazione, Snowflake e il contesto dell’IA fanno ciascuno meglio il proprio lavoro con una forma costruita per loro, e consultarle va benissimo. Ma quando qualcosa cambia, la modifica parte dal system of record, di solito il modello relazionale, e si propaga verso ogni copia. Nessuno corregge la regione in Snowflake, o modifica a mano il contesto dell’IA. Correggila alla fonte, e lascia che la modifica si propaghi.
E conta soprattutto quando i dati cambiano. Se oggi un centro di distribuzione passa a un’altra regione, le consegne del mese scorso devono mostrare la nuova regione? Forse. Forse no. Per lo storico potrebbe servirmi la regione che era vera quando è avvenuta la consegna. Non è più un problema di sincronizzazione. È una decisione di business.
Ecco perché la denormalizzazione non dovrebbe mai avvenire per caso. Ogni fatto duplicato solleva domande su responsabilità, sincronizzazione, storico e fiducia. È il ragionamento sui trade-off del capitolo 1: sappi cosa stai comprando (una schermata più facile, un report più semplice, un contesto migliore per l’IA) e cosa stai pagando (dati duplicati, sincronizzazione, una titolarità della verità più complicata). E siccome siamo partiti da un modello logico pulito, possiamo indicare ogni copia e dire: “So che questo sta laggiù. Ne metto qui una rappresentazione per via di questo requisito.” È una decisione che possiamo rivedere, mettere in discussione e mettere per iscritto, così chi verrà dopo saprà perché.
Cosa decide qui un architetto
Sezione intitolata “Cosa decide qui un architetto ”Quando valuto una denormalizzazione, decido:
- Dove risiede la fonte autorevole di ogni fatto di business.
- Se il modello pulito crea problemi reali per gli utenti, la reportistica, la scala o le prestazioni.
- Se una rappresentazione più semplice vale la duplicazione, e come la copia resta affidabile.
- Se i valori storici debbano cambiare quando cambia la fonte attuale.
- Se le analisi o l’IA hanno bisogno di una forma dei dati diversa da quella del sistema operativo.
Il punto di partenza non cambia mai: sappi dove sta la verità. Poi, quando i requisiti lo giustificano, dagli la forma giusta per consegnarla.
Ora Salesforce torna in scena. Trasformeremo ciò che abbiamo progettato in un modello dati fisico.
Per approfondire
Sezione intitolata “Per approfondire ”- Build Powerful Reports with Custom Report Types (opens in a new tab), Salesforce Admins, 24 giugno 2019 (in inglese, consultato il 2026-10-12): un tipo di report personalizzato “can span up to 4 object relationships” (può estendersi fino a 4 relazioni tra oggetti).
- Unleash the hounds, terriers and lapdogs: American Kennel Club recognizes 3 more breeds (opens in a new tab), PBS NewsHour, 2 gennaio 2026 (in inglese, consultato il 2026-10-12): “The AKC recognizes 205 breeds, including these three newcomers” (l’AKC riconosce 205 razze, comprese queste tre nuove arrivate).
- Per divertimento: la FCI Breeds Nomenclature (opens in a new tab), Fédération Cynologique Internationale (consultato il 2026-10-12): l’elenco delle razze della federazione internazionale, in dieci gruppi. Scorrilo e capirai perché Razza si è guadagnata una tabella sua.