Costruisci il modello logico

🌐 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 3 di 6 del capitolo Modellare i dati per il loro significato, capitolo 2 del corso Data Architect. Ogni modulo si regge da solo. Precedente: Disegna le relazioni · Successivo: Metti i dati dove devono stare

La domanda a cui risponde questo modulo: Come trasformo un modello concettuale in un modello dati logico?

Il modello concettuale ci ha detto cosa esiste in Steve Trucking e come è collegato: i Partner retail e i loro centri di distribuzione, i manifesti di carico e le consegne, i Destinatari, i percorsi e le tappe, le squadre, i camion e le assegnazioni delle squadre. Basta per una conversazione molto produttiva con il business. Ma prima o poi mi servono più dettagli. Cosa dobbiamo sapere di una consegna? Cosa rende un centro di distribuzione diverso da un altro? Come identifichiamo un Destinatario? Cosa appartiene a un’assegnazione della squadra e non alla squadra o al camion? Queste domande ci portano da un modello concettuale verso un modello dati logico, e non stiamo ancora costruendo Salesforce.

Seduto, resta, modello

Prima, torniamo ai cani. Abbiamo i riquadri e le linee. Ora due domande nuove: cosa sappiamo di ogni cosa, e come distinguiamo l’una dall’altra?

Cosa la descrive? Un cane ha un nome e una data di nascita. Un proprietario ha un nome, un numero di telefono e un indirizzo. Un esercizio ha un nome e una difficoltà. Ogni fatto va sul riquadro che descrive.

Poi la giunzione. Quanto bene Bella fa Seduto, e quando lo ha imparato: descrive Bella? Non proprio; in alcuni esercizi è più brava che in altri. Descrive Seduto? No; ogni cane fa Seduto in modo diverso. Descrive Bella e Seduto insieme, quindi va sull’Esercizio del cane: il livello di abilità e la data in cui lo ha imparato. Ecco perché esiste la giunzione: alcuni fatti appartengono solo alla coppia.

Quale cane è quale? Prova prima con il nome. Ci sono un sacco di cani che si chiamano Max, quindi il nome non è unico. Il numero di telefono del proprietario? Marcus ha due cani con lo stesso telefono, le persone cambiano numero, ed è un dato personale di qualcuno, che verrebbe copiato in ogni sistema che punta a un cane. Il numero del microchip sembra migliore: è unico e non cambia. Ma un cucciolo appena arrivato potrebbe non avere ancora il microchip, e una chiave non può essere vuota. Quindi il microchip resta, come qualcosa con cui il cane è anche conosciuto, e il cane riceve il suo ID cane: un numero che fa un unico lavoro noioso, distinguere un cane da un altro.

Click to enlarge

Sono le stesse domande che ora porremo a Steve Trucking, e i motivi per cui il nome, il telefono e il microchip non bastano diventano una regola che seguo da anni.

Il concettuale mi dice cosa esiste; il logico mi dice cosa significa come dato

Prendi il Camion. Cosa devo sapere di un camion? Forse il numero di unità, il numero di telaio (VIN), la marca, il modello, l’anno del modello, la targa, il chilometraggio attuale e lo stato. Sono attributi del Camion.

Ora prendi la Consegna. Forse il numero d’ordine del Partner retail, la data di consegna, la fascia oraria promessa, l’orario effettivo di arrivo, lo stato, e se include un’installazione o un ritiro dell’usato. Di nuovo, attributi.

Il modello concettuale ci ha detto che la Consegna esiste. Il modello logico inizia a dirci cosa significa una consegna come dato. Un semplice riquadro come Camion o Consegna può rappresentare un intero insieme di campi.

Click to enlarge

Anche così, nella maggior parte dei nostri diagrammi i riquadri restano semplici, per tre ragioni. Il numero di campi cresce. I campi diventano presto obsoleti. E ogni campo ha dettagli difficili da mostrare in un modello a oggetti: il nome API, l’etichetta, il tipo di dati e la lunghezza. Quei dettagli verranno sicuramente registrati, solo non nel primo modello dati. Quando mostrare alcuni campi chiave aiuta davvero a raccontare la storia, disegno un modello dati dettagliato: una porzione mirata, con solo i campi che contano per il punto in questione.

Gli attributi dovrebbero descrivere l’entità

Ecco una domanda semplice che uso quando guardo un attributo: cosa descrive? La marca del camion descrive chiaramente il camion. Ma i nomi dei membri della squadra su una consegna? Descrivono la consegna? O descrivono una squadra, che aveva un’assegnazione, che copriva il percorso, che includeva questa tappa?

È qui che un modello dati comincia a far emergere cose che sullo schermo sembrano perfettamente ragionevoli. Un coordinatore dice: “Voglio vedere i nomi della squadra sulla consegna”. È un requisito valido di esperienza utente. Non è necessariamente un requisito di memorizzare i nomi della squadra sulla consegna. Sono due cose diverse, e ci torneremo con la normalizzazione. Per ora prendi l’abitudine di chiederti quale cosa descrive davvero questo fatto. Quella domanda ti risparmierà molti problemi.

Poi dobbiamo parlare di ID univoci

Gli attributi descrivono le cose. Ma c’è un altro problema da risolvere: come faccio a sapere quale cosa è quale?

Due Destinatari si chiamano John Smith. Sono la stessa persona? Forse sì, forse no. Un nome non basta. Un indirizzo? Le persone traslocano. I numeri di telefono cambiano. Gli indirizzi email cambiano. Persino il nome di un Partner retail può cambiare.

Questo ci porta alle chiavi: ciò che ci permette di identificare in modo univoco qualcosa nel nostro modello. È un’area in cui negli anni mi sono fatto un’opinione piuttosto forte. Per un identificatore voglio quattro cose:

Unico. Immutabile. Privo di significato. Mai un dato personale (PII).

Unico. Un identificatore deve identificare esattamente una cosa. Se due consegne possono avere lo stesso valore, non è un identificatore affidabile della consegna. I nomi di solito non sono unici, gli indirizzi non lo sono necessariamente, e i numeri di telefono vengono condivisi. Anche valori che oggi sembrano unici potrebbero non esserlo quando avrai abbastanza dati. Quindi chiediti: due di questi possono mai avere lo stesso valore? Se la risposta è sì, fai molta attenzione a usarlo come ID univoco del record.

Immutabile. Questa sfugge spesso. Se identifichiamo un Partner retail con il suo nome e il partner cambia nome, abbiamo un nuovo partner? No. L’entità di business è rimasta la stessa; è cambiato uno dei suoi attributi. L’ID univoco di un record dovrebbe sopravvivere ai cambiamenti della cosa che identifica, il che esclude nomi, indirizzi email, numeri di telefono, indirizzi e nomi utente, per quanto comodi sembrino quando costruiamo un sistema per la prima volta.

Privo di significato. La prima volta che lo senti suona strano. Perché dovrei volere un identificatore privo di significato? Perché il significato cambia. Immagina che qualcuno costruisca un ID di consegna che codifica il CD, il Partner retail, la data di consegna e un numero progressivo: PHX-KEY-20261002-0042. Sembra ingegnoso. Poi il Destinatario sposta la consegna a venerdì. Cambiamo l’identificatore? Se non lo facciamo, ci sta mentendo. Se lo facciamo, abbiamo cambiato l’ID univoco della consegna perché è cambiato uno dei suoi attributi, e ogni sistema che aveva memorizzato il vecchio ID l’ha appena perso di vista. L’identificatore cercava di fare due lavori: identificare la consegna e descriverla. Preferisco lasciare che siano gli attributi a descriverla e che l’identificatore faccia un solo lavoro noioso: identificarla. Gli identificatori noiosi sono buoni identificatori.

Mai un dato personale. Questa è abbastanza importante da tenerla separata. Non usare informazioni di identificazione personale come identificatore solo perché sembrano uniche. In Steve Trucking si è tentati di riconoscere un Destinatario dal numero di telefono. Ma una chiave viene copiata ovunque i sistemi debbano collegare record: integrazioni, esportazioni, log, file di stato restituiti ai Partner retail, il data warehouse, i dati di test. Fai del numero di telefono la chiave, e hai sparso i dati personali di un Destinatario in tutta l’architettura.

Una chiave deve anche esserci per ogni record: mai nulla o vuota. Se alcune persone non vorranno, o non dovrebbero essere tenute a, darti un valore, quel valore non può essere la chiave. Ecco perché i sistemi emettono i propri identificatori interni, e i dati personali, se ti servono davvero, diventano un attributo protetto.

Quindi la mia regola è: unico, immutabile, privo di significato, mai un dato personale.

Chiavi naturali e chiavi surrogate

Chi lavora con i database ha dei nomi per alcune di queste cose. Una chiave naturale esiste già nei dati di business: il numero di telaio (VIN) di un camion è un buon esempio. Non l’ha inventato la nostra applicazione, e ha già un significato. Una chiave surrogata viene creata apposta per identificare il record; non descrive niente, identifica e basta.

Nella maggior parte delle architetture preferisco una chiave surrogata come ID interno del record e tengo gli identificatori naturali importanti come attributi. Non significa che gli identificatori naturali siano cattivi; spesso sono estremamente importanti. Solo, non li rendo automaticamente l’ID univoco del record. Chiediti cosa succede se il valore viene corretto, riformattato, sostituito, riutilizzato, manca, o arriva da più di un sistema di origine. È lì che una decisione dall’aria semplice diventa una decisione di architettura.

Una cosa può avere diversi identificatori utili

L’ID interno del record non è necessariamente l’identificatore che usano tutti gli altri sistemi. Steve Trucking potrebbe identificare internamente una consegna con un ID generato. Ogni Partner retail conosce la stessa consegna con il proprio numero d’ordine: Keystone nel suo manifesto di carico CSV, Redrock nella sua API, Brightwave nei suoi messaggi EDI. E gli otto anni di storico in RouteDesk, il vecchio strumento di dispatch, usano gli ID di consegna di RouteDesk.

Quegli identificatori contano. Dobbiamo conservarli e mapparli correttamente, perché un aggiornamento di stato deve tornare a ciascun partner con il suo numero. Ma non devono diventare tutti l’ID univoco della consegna. “Qual è il suo ID?” può avere più di una risposta, e l’architetto deve sapere quale ID è autorevole in quale contesto. Ci torneremo con i dati master e l’integrazione.

Le relazioni dipendono dagli ID univoci

Ora torna alle linee che abbiamo disegnato. Un manifesto di carico elenca delle consegne. Un Destinatario riceve delle consegne. Una squadra ha delle assegnazioni. Quelle relazioni funzionano solo perché possiamo identificare in modo affidabile le cose a entrambe le estremità.

Ecco dove fa male in Steve Trucking. Un Partner retail modifica il suo manifesto di carico il giorno stesso: un ordine annullato, un articolo sostituito, un nuovo indirizzo. Se non riusciamo ad abbinare la riga modificata alla consegna che abbiamo già, tramite il numero d’ordine del partner, creiamo una seconda consegna per lo stesso frigorifero, e una squadra potrebbe presentarsi due volte. Riquadri, attributi, chiavi e relazioni non sono idee separate. Sono tutte parti dello stesso modello.

Click to enlarge

A questo punto potresti pensare: “Salesforce dà un ID a ogni record”. Giusto, e ci arriveremo. Se i dati risiedono in Salesforce, ogni record riceve un ID generato da Salesforce. È criptico e difficile da leggere, quindi di solito esponiamo anche un campo ID che le persone possono usare, come un numero di consegna D-000184227, un campo a numerazione automatica (Auto Number). Spesso si pensa che quel numero sia l’ID del record, ma non lo è: sotto c’è sempre l’ID Salesforce. Anche un sistema esterno o un database, Oracle o SQL Server, ha i propri ID univoci. Ma l’architettura potrebbe alla fine includere Salesforce, l’ERP finanziario, Snowflake, Data 360, i sistemi dei partner e sistemi che ancora non esistono. Il modello logico descrive i dati di business senza far dipendere ogni decisione da una sola tecnologia. Come Salesforce lo implementa fisicamente è un passo successivo.

Cosa decide qui un architetto

Mentre trasformo un modello concettuale in un modello logico, decido:

• Quali attributi descrivono davvero ogni entità.
• Come viene identificata in modo univoco ogni entità, e se quell’identificatore è abbastanza stabile da essere il suo ID univoco.
• Quali identificatori di business (numeri d’ordine dei partner, ID dei sistemi legacy) vanno conservati e mappati.
• Se informazioni sensibili vengono usate come chiave.
• Se le relazioni collegano le entità tramite ID univoci affidabili.

Ora abbiamo entità, relazioni, attributi e ID univoci: gli inizi di un vero modello dati logico. Ma c’è ancora un problema. È facilissimo mettere dati perfettamente validi nel posto sbagliato. È qui che entra in gioco la normalizzazione.

Per approfondire

• Custom Field Types (opens in a new tab), Guida di Salesforce (in inglese, consultato il 2026-10-09): la numerazione automatica assegna a ogni record un numero univoco con un formato di visualizzazione, per esempio un prefisso e zeri iniziali; non è l’ID Salesforce del record. Vedi anche Auto-Number Fields Are Not Always Sequential (opens in a new tab) (in inglese, consultato il 2026-10-09).