Metti i dati dove devono stare

🌐 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)

Immagine generata con l'IA

Tradotto con l'IA. Non ancora rivisto dalla comunità. Leggi in inglese

Modulo 4 di 6 del capitolo Modellare i dati per il loro significato, capitolo 2 del corso Data Architect. Ogni modulo si regge da solo. Precedente: Costruisci il modello logico · Successivo: Progetta fino alla terza forma normale, poi fai un passo indietro

La domanda a cui risponde questo modulo: In che modo la normalizzazione mi aiuta a capire dove devono stare davvero i dati?

Abbiamo un modello logico: entità, relazioni, attributi e chiavi. Ora voglio porre una delle domande più importanti della modellazione dei dati: questi dati devono stare davvero qui?

Sembra semplice. Non lo è. Ho visto molti sistemi in cui ogni campo aveva senso quando qualcuno lo aveva creato. Il problema non era che i campi fossero assurdi; era che i fatti erano memorizzati nel posto sbagliato. Una consegna contiene informazioni che in realtà descrivono un centro di distribuzione. Lo stesso indirizzo compare su centinaia di record. Un campo contiene tre valori separati da virgole. Cambiare un singolo fatto di business significa aggiornare 10.000 record. È il problema che la normalizzazione ci aiuta a risolvere, e prima di farci seppellire dalla terminologia dei database, ecco l’idea intera: metti un fatto dove deve stare. Tutto il resto di questo modulo ci aiuta a farlo in modo più sistematico.

Che cos’è la normalizzazione?

La normalizzazione è organizzare i dati in modo che ogni fatto sia memorizzato una sola volta, nel posto a cui appartiene. Quando una tabella fa troppi lavori, la dividiamo in tabelle che descrivono ciascuna una cosa sola, e le colleghiamo con delle chiavi.

Perché prendersi la briga? Perché un fatto memorizzato una volta è un fatto che cambiamo una volta. La normalizzazione previene la ridondanza, lo stesso fatto copiato su molti record, e con essa le incoerenze che si insinuano quando una copia viene aggiornata e le altre no. Ecco perché si adatta ai sistemi transazionali come Salesforce, dove i record vengono creati e aggiornati tutto il giorno.

Normalizziamo per passi chiamati forme normali, e ognuna pone una sola domanda:

• Prima forma normale (1NF): un valore per campo, e qualcosa che identifichi in modo univoco ogni riga.
• Seconda forma normale (2NF): ogni fatto descrive l’intero insieme di ciò che identifica la riga, non solo una parte.
• Terza forma normale (3NF): ogni fatto descrive questa cosa, non qualcos’altro a cui è collegata.

Esistono altre forme oltre la terza. Ne dirò due parole più avanti, e spiegherò perché di solito ci fermiamo alla terza. Prima, guardiamo i tre passi in azione.

Perché normalizziamo?

Quando lo insegno dal vivo, non comincio dalle consegne. Comincio dai cani. Tutti capiscono i cani, quindi nessuno si distrae con il business, e possiamo guardare i dati che cercano casa. Poi portiamo le stesse mosse in Steve Trucking.

Seduto, resta, modello

Si parte: il foglio di calcolo grezzo. Metto un paio di cani sullo schermo, e poi la sala aggiunge i suoi. In pochi minuti abbiamo un unico grande elenco: il cane, l’anno in cui è nato, chi ne è il proprietario, dove vive il proprietario, la razza, chi lo ha allevato e gli esercizi che conosce.

Cane	Nascita	Proprietario	CAP	Città	Razza	Allevatore	Esercizi
Bella	2017	Marcus	80202	Denver	Labrador	Maple Ridge	Seduto, Resta, Dai la zampa
Milo	2019	Marcus	80202	Denver	Barboncino	Golden Meadow	Seduto, Rotola
Max	2022	Ana	64105	Kansas City	Meticcio		Seduto, Fai il morto
Luna	2020	Kenji	98101	Seattle	Husky	Cascade	Seduto, Resta, Gira
Rocky	2024	Priya	30301	Atlanta	Beagle	Maple Ridge	Seduto
Coco	2014	Ana	64105	Kansas City	Chihuahua	Little Paws	Dai la zampa, Gira

Funziona. Ogni foglio di calcolo funziona il primo giorno. Ma guarda cosa c’è già che non va. Come trovo tutti i cani che sanno dare la zampa? Il CAP di Ana è su due righe, e anche quello di Marcus: cosa succede se qualcuno aggiorna l’uno e non l’altro? Maple Ridge compare due volte, e anche Kansas City. E Max viene dal canile, quindi non ha nessun allevatore.

Passo 1: prima forma normale. Due regole. Ogni campo contiene un solo valore, quindi l’elenco di esercizi separati da virgole deve sparire. E ogni riga ha bisogno di qualcosa che la identifichi in modo univoco. Non il nome del cane; ci sono un sacco di cani che si chiamano Max. Un ID: un ID generato automaticamente o un GUID. Gli esercizi escono in righe proprie, una riga per ogni cane e ogni esercizio. E una volta che un esercizio ha la sua riga, c’è spazio per ciò che in un elenco con le virgole non potremmo mai dire: quanto è difficile l’esercizio, quanto bene lo fa questo cane, e quando lo ha imparato.

Cane (identificato dall’ID cane)

ID cane	Nome	Nascita	Proprietario	CAP	Città	Razza	Allevatore
D-001	Bella	2017	Marcus	80202	Denver	Labrador	Maple Ridge
D-002	Milo	2019	Marcus	80202	Denver	Barboncino	Golden Meadow
D-003	Max	2022	Ana	64105	Kansas City	Meticcio
D-004	Luna	2020	Kenji	98101	Seattle	Husky	Cascade
D-005	Rocky	2024	Priya	30301	Atlanta	Beagle	Maple Ridge
D-006	Coco	2014	Ana	64105	Kansas City	Chihuahua	Little Paws

Esercizio del cane (identificato da ID cane + Esercizio)

ID cane	Esercizio	Difficoltà	Livello di abilità	Imparato
D-001	Seduto	Facile	Esperto	2017-11
D-001	Resta	Facile	Esperto	2018-01
D-001	Dai la zampa	Media	Buono	2018-06
D-002	Seduto	Facile	Esperto	2020-02
D-002	Rotola	Difficile	In apprendimento	2023-05
D-003	Seduto	Facile	Buono	2022-06
D-003	Fai il morto	Difficile	In apprendimento	2024-03
D-004	Seduto	Facile	Esperto	2020-11
D-004	Resta	Facile	Buono	2021-01
D-004	Gira	Media	Esperto	2021-06
D-005	Seduto	Facile	In apprendimento	2025-02
D-006	Dai la zampa	Media	Esperto	2015-06
D-006	Gira	Media	In apprendimento	2025-04

Ora “tutti i cani che sanno dare la zampa” è una domanda semplice. Ma nota da cosa è identificato l’Esercizio del cane: non da una cosa, ma da due cose insieme, il cane e l’esercizio. Tienilo a mente.

Passo 2: seconda forma normale. La seconda forma normale conta solo quando una riga è identificata da una combinazione, e l’Esercizio del cane lo è. Quindi chiedo a ogni colonna: descrive l’intera combinazione, o solo una parte? Il Livello di abilità descrive questo cane che fa questo esercizio: Bella è esperta in Seduto, Rocky lo sta ancora imparando. Imparato, lo stesso. Ma la Difficoltà? Seduto è facile qualunque cane lo faccia. Descrive l’esercizio, solo una parte della chiave, ed è per questo che “Facile” si ripete su ogni riga di Seduto. Quindi l’esercizio riceve una tabella sua, e ciò che resta è la coppia.

Esercizio

ID esercizio	Esercizio	Difficoltà
T-01	Seduto	Facile
T-02	Resta	Facile
T-03	Dai la zampa	Media
T-04	Rotola	Difficile
T-05	Fai il morto	Difficile
T-06	Gira	Media

Esercizio del cane (ID cane + ID esercizio)

ID cane	ID esercizio	Livello di abilità	Imparato
D-001	T-01	Esperto	2017-11
D-001	T-02	Esperto	2018-01
D-001	T-03	Buono	2018-06
D-002	T-01	Esperto	2020-02
D-002	T-04	In apprendimento	2023-05
D-003	T-01	Buono	2022-06
D-003	T-05	In apprendimento	2024-03
D-004	T-01	Esperto	2020-11
D-004	T-02	Buono	2021-01
D-004	T-06	Esperto	2021-06
D-005	T-01	In apprendimento	2025-02
D-006	T-03	Esperto	2015-06
D-006	T-06	In apprendimento	2025-04

Quella tabella Esercizio del cane è quella che abbiamo trovato nel modulo 2, e nella modellazione dei dati ha un nome: una giunzione, o come la chiamo io, un oggetto di giunzione logico. Un cane conosce molti esercizi; un esercizio è conosciuto da molti cani. La giunzione sta tra loro, e non è un tubo vuoto: contiene i fatti che appartengono alla relazione stessa, il livello di abilità e la data. La ritroveremo nel modulo 6, e nel capitolo 3 vedremo che Salesforce usa “oggetto di giunzione” in un senso più ristretto: un oggetto di giunzione di Salesforce (Salesforce Junction Object) è un oggetto personalizzato con due relazioni master-dettaglio (capitolo 3, modulo 7).

Passo 3: terza forma normale. Ora torniamo alla tabella Cane. Tutto ciò che contiene è identificato dall’ID cane, quindi la seconda forma normale non ha niente da dire. La terza forma normale pone una domanda diversa: questo fatto descrive il cane, o qualcos’altro a cui il cane è collegato? La razza è una cosa a sé: un Labrador è un Labrador qualunque cane sia, e i fatti che lo riguardano, come la taglia, appartengono alla razza, non a Bella. Il CAP e la città descrivono il proprietario, non il cane: è lì che vive Ana, qualunque dei suoi cani stiamo guardando. I dati dell’allevatore descrivono l’allevatore. Ognuno di questi è un fatto su un altro fatto, quindi ognuno si sposta in una tabella sua, e il cane vi punta con una chiave esterna:

• Cane: ID cane, Nome, Nascita, ID proprietario, ID razza, ID allevatore
• Proprietario: ID proprietario, Nome, CAP, Città
• Razza: ID razza, Razza, Taglia
• Allevatore: ID allevatore, Nome, Città
• Esercizio ed Esercizio del cane, dal passo 2

Ora Ana è memorizzata una volta sola, con entrambi i suoi cani che puntano a lei. Maple Ridge è memorizzato una volta sola, e la tabella Razza ci dà una casa per i fatti su ogni razza, come la taglia, che il foglio di calcolo non sapeva dove mettere. Una chiave esterna può essere vuota: Max non ha un ID allevatore, ed è una risposta onesta, non una lacuna. Poi lancio alla sala una domanda trabocchetto: quando il proprietario ha preso il cane, dove va quella data? Sul cane. In questo modello un cane ha un solo proprietario alla volta, quindi quella data descrive la relazione del cane con il suo proprietario.

Potresti fare un passo in più e separare la città dal CAP; i libri di testo lo fanno. In pratica un indirizzo resta unito, e comunque Kansas City si trova in due stati, un bel promemoria del fatto che il mondo reale non legge i nostri libri di testo.

Questa è la progressione: un foglio di calcolo, poi tre domande, e ogni fatto finisce in un solo posto. Fai un passo indietro e guarda cosa abbiamo costruito. Un elenco disordinato è diventato sei tabelle, ognuna delle quali descrive una cosa sola, collegate da chiavi:

Click to enlarge

Nessuno ha avuto bisogno di una sola parola di Salesforce per seguirlo. Sono solo i cani, le persone intorno a loro, e ciò che sanno fare.

Ora applichiamolo a Steve Trucking

I cani rendono le mosse facili da vedere. Un business vero le rende importanti, perché gli stessi errori su larga scala costano soldi veri. Quindi portiamo le stesse tre domande in Steve Trucking. Immagina che tenga le sue consegne così:

Consegna	Partner retail	Centro di distribuzione	Città del CD	Squadra	Camion
1001	Keystone	Keystone Phoenix DC	Phoenix	Squadra 12	117
1002	Keystone	Keystone Phoenix DC	Phoenix	Squadra 8	122
1003	Keystone	Keystone Phoenix DC	Phoenix	Squadra 12	117

A prima vista qui non c’è niente di complicato. Ma guarda il centro di distribuzione. Ripetiamo “Keystone Phoenix DC, Phoenix” su ogni consegna che parte da lì: Steve Trucking fa circa 3.300 consegne al giorno su nove CD, quindi qualche centinaio al giorno da ciascuno. Cosa succede se quel CD si trasferisce? Quanti record cambiamo, e cosa succede se ne sfugge uno? Ora i dati dicono che il CD si trova in due città contemporaneamente. È un’anomalia di aggiornamento. E se volessimo creare un nuovo CD prima della sua prima consegna? E se eliminassimo l’ultima consegna di un CD: abbiamo appena eliminato l’unico posto in cui avevamo memorizzato qualcosa su di esso?

Sono sintomi diversi dello stesso problema: abbiamo mescolato fatti su cose diverse. I fatti sul centro di distribuzione stanno con il centro di distribuzione. I fatti sulla consegna stanno con la consegna. I fatti sulla squadra stanno con la squadra. Questa è la normalizzazione in termini pratici.

Prima forma normale: non nascondere le strutture ripetute

Cominciamo dalla prima forma normale, o 1NF, dove a volte si rende la normalizzazione più difficile del necessario.

Supponiamo che una consegna abbia un campo chiamato Articoli: “Frigorifero, kit per il fabbricatore di ghiaccio, ritiro dell’usato”. Abbiamo messo tre informazioni in un solo campo. Sembra comodo, finché qualcuno non chiede: “Quanti ritiri dell’usato abbiamo fatto il mese scorso?”. Oppure immagina dei campi chiamati Articolo 1, Articolo 2 e Articolo 3. Funziona, fino alla consegna con quattro articoli. Il problema non è che abbiamo scelto il numero sbagliato di campi Articolo. Il problema è che non abbiamo riconosciuto la struttura ripetuta. Una consegna può avere diversi articoli. Sono dati che dovremmo modellare: l’Articolo della consegna che abbiamo trovato nel modulo 2.

Click to enlarge

La lezione pratica della 1NF: non nascondere strutture ripetute dentro i campi. Se il business ti dice che qualcosa può succedere molte volte, ascolta. Potrebbe esserci un’altra entità che cerca di uscire.

Lo vedrai di continuo nelle org reali. Qualcuno ha bisogno di una descrizione in più lingue, quindi crea un campo chiamato Description_English, poi Description_French, poi Description_German. Oppure un’approvazione richiede alcune persone, e ci ritroviamo con Approvatore 1, Approvatore 2, Approvatore 3. Quando lo trovo in una revisione, è una bacchettata sulle mani: sistema il tuo modello dati. Uno o due, forse, se il business ne ha davvero sempre e solo uno o due. Qualunque cosa oltre dovrebbe essere un oggetto figlio: una Traduzione con una lingua, un Passaggio di approvazione con un approvatore. La lingua successiva, o il quarto approvatore, diventa un nuovo record, non un nuovo campo e un deployment.

Seconda forma normale: descrivi l’intero

La seconda forma normale, o 2NF, conta quando un record è identificato da una combinazione di cose. Prendi l’Articolo della consegna. Ha il suo ID del record, ma ognuno è unico per Consegna + Prodotto. Supponiamo di memorizzare la consegna, il prodotto, la quantità e la descrizione del prodotto.

La quantità ha senso qui: descrive questo prodotto in questa consegna. Ma la descrizione del prodotto non descrive la combinazione; descrive il prodotto. Mettila su ogni Articolo della consegna e la ripeteremo ogni volta che quel modello di frigorifero parte su un altro camion. È l’indizio che il fatto deve stare da un’altra parte.

Quindi la domanda della 2NF è: questo attributo descrive l’intera cosa che sto identificando, o solo una parte? Se descrive solo il prodotto, va con il Prodotto. Se descrive il posto del prodotto in questa particolare consegna (la quantità, se va installato), appartiene all’Articolo della consegna. Molti amministratori non diranno mai consapevolmente: “Ora sto applicando la seconda forma normale”. Va bene così. Mi importa molto di più che tu impari a chiederti: cosa descrive davvero questo fatto?

Terza forma normale: non memorizzare fatti su altri fatti

Ora quella a cui tengo di più per la modellazione di tutti i giorni: la terza forma normale, o 3NF.

Ogni centro di distribuzione ha un responsabile dalla parte del Partner retail, qualcuno che usa il portale dei partner. Supponiamo di mettere il nome del responsabile del CD direttamente su ogni consegna. Cosa succede quando il CD cambia responsabile? Aggiorniamo ogni consegna di quel CD. È di nuovo quel cattivo odore: stiamo ripetendo un fatto che appartiene a un altro posto. La consegna parte da un CD; il CD ha un responsabile. Sono due relazioni, e il nome del responsabile sta con il CD.

La versione classica dei libri di testo è l’indirizzo: CAP, città e stato memorizzati insieme su ogni record, quando di solito la città e lo stato derivano dal CAP. Stessa forma, stessa domanda.

Click to enlarge

La domanda pratica della 3NF è: questo fatto descrive questa cosa, o qualcos’altro a cui questa cosa è collegata? Voglio che te la ponga di continuo.

Ora fai un passo indietro, come abbiamo fatto con i cani. La tabella delle consegne da cui siamo partiti è diventata cinque cose, ognuna con i propri fatti: l’Articolo della consegna è uscito con la prima forma normale, il Prodotto con la seconda, e la città e il responsabile del Centro di distribuzione si sono spostati sul Centro di distribuzione con la terza.

Click to enlarge

Stesse tre domande, stesso risultato: ogni fatto in un solo posto.

Un modo semplice di pensare a 1NF, 2NF e 3NF

Si può dedicare un intero corso sui database alla normalizzazione. Noi non lo faremo. Per questo corso voglio che tu ne abbia la comprensione operativa di un architetto:

• 1NF: sto nascondendo più valori o strutture ripetute dentro un campo o un record?
• 2NF: questo fatto descrive l’intera cosa che sto identificando?
• 3NF: questo fatto descrive davvero questa entità, o qualcosa a cui è collegata?

Non sono definizioni da libro di testo sui database. Sono domande che posso usare davvero mentre progetto.

Sì, la normalizzazione va oltre: la forma normale di Boyce-Codd (BCNF) rende più rigide le regole intorno alla 3NF per i modelli con chiavi più complicate, e ci sono la quarta, la quinta e perfino la sesta forma normale. Riguardano tipi più rari di ripetizione, quelli che nascono da strutture di chiavi insolite più che dai normali record di business. Tanta teoria, e secondo la mia esperienza non vale il mal di testa per il tipo di sistemi che costruiamo su Salesforce. Nei sistemi di business la pressione di solito va nella direzione opposta: è molto più probabile che ci allontaniamo dalla terza forma normale, per gli utenti, la reportistica e le prestazioni, che andare oltre. È il prossimo modulo. Sappi che le forme successive esistono, ma per la maggior parte di ciò che facciamo, dalla 1NF alla 3NF abbiamo gli strumenti di ragionamento che ci servono.

Progetta per la terza forma normale

Ecco la mia posizione. Quando cerco di capire un business e di progettarne il modello logico, voglio partire pulito: i fatti sulla consegna con la consegna, i fatti sul centro di distribuzione con il CD, i fatti sul camion con il camion, i concetti ripetuti modellati come concetti. Non voglio un fatto di business copiato in tutto il modello solo perché potrebbe rendere più facile una schermata o un report. Non ancora.

Ma la normalizzazione non è una religione. L’obiettivo non è il modello più puro possibile dal punto di vista accademico. Ho visto architetti concentrarsi così tanto sulla purezza che il modello diventava faticoso per tutti quelli che dovevano usarlo. Non stiamo cercando di vincere una gara di normalizzazione; stiamo costruendo un sistema, e quel sistema ha utenti, report, integrazioni, esigenze di prestazioni, scala e, sempre di più, un’IA che legge i dati. Tutti questi potrebbero volere i dati in forme diverse.

Quindi il mio punto di partenza è progettare fino alla terza forma normale dove è fattibile, poi fare un passo indietro quando serve: capire prima dove deve stare ogni fatto. Poi, se ce ne allontaniamo, voglio sapere perché. Se la risposta è “perché non sapevo dove altro mettere il campo”, non basta. Se la risposta è “abbiamo copiato deliberatamente questo valore perché rende semplice la scheda di valutazione dei partner, e abbiamo un modo affidabile per tenerlo sincronizzato”, allora stiamo facendo una conversazione di architettura.

Cosa decide qui un architetto

Quando normalizzo un modello logico, cerco:

• Valori o strutture ripetute che andrebbero modellati separatamente.
• Attributi che descrivono un’entità diversa da quella su cui sono memorizzati.
• Fatti duplicati senza necessità su molti record, e le dipendenze che li rendono incoerenti.
• Concetti di business nascosti dentro i campi.
• Un modello pulito che rappresenti la verità prima di qualsiasi compromesso di implementazione.

Non perché ogni sistema fisico debba restare perfettamente normalizzato. Anzi, il contrario. Nel prossimo modulo ci allontaneremo di proposito dal modello pulito, per gli utenti, la reportistica, la scala, l’analisi e l’IA, e lo faremo sapendo esattamente cosa stiamo scambiando.