Il modello dati è lo scheletro
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 2 di 7 del capitolo Pensare da Data Architect, il primo capitolo del corso Data Architect. Ogni modulo si regge da solo. Precedente: Pensare come un architetto · Successivo: Il Test di Reversibilità
La domanda a cui risponde questo modulo: Perché il modello dati conta più di qualsiasi cosa costruita sopra, e come lo si giudica?
Quando insegno architettura dei dati, c’è una frase a cui torno continuamente: il modello dati è lo scheletro.
Il modello dati è lo scheletro del sistema. Tutto il resto è costruito intorno a lui, ed è ciò che tiene insieme il resto del corpo. Quando guardi una persona non vedi le ossa, ma sono loro a decidere quanto sta dritta, come si muove e cosa può portare.
Pensa a tutto ciò che costruiamo in un’implementazione Salesforce. Costruiamo l’automazione intorno al modello dati. Scriviamo Apex che lo usa, e Flow che lo leggono e lo aggiornano. Costruiamo integrazioni che vi inviano dati e ne estraggono. Creiamo report e analisi su di esso, e progettiamo la sicurezza intorno a esso. E, sempre di più, costruiamo agenti IA che devono capire quei dati e agire su di essi. Tutto dipende dalla struttura sottostante.
Ecco perché impostare bene il modello dati fin dall’inizio conta così tanto. Lo scheletro si può cambiare più tardi. Ma probabilmente farà male.
Parti dal business
Sezione intitolata “Parti dal business ”Un buon modello dati parte da una domanda semplice: cosa deve rappresentare davvero il business? Non “quali oggetti Salesforce abbiamo?”. E di certo non “cosa posso costruire in fretta?”.
Cerchiamo prima di capire il business. Quali sono le cose importanti in questo business? Come sono collegate? Chi le possiede? Come cambiano nel tempo? Cosa va ricordato, e cosa è condiviso tra i processi di business? Solo dopo aver capito queste cose dovremmo iniziare a tradurle in oggetti, campi e relazioni.
Sembra ovvio. In pratica è facilissimo farlo al contrario. Qualcuno riconosce qualcosa che somiglia a un’Opportunità, un Caso o un Asset e inizia subito a progettarci intorno. A volte è esattamente giusto. A volte stiamo cercando di far entrare un piolo quadrato in un foro rotondo, e una volta costruito abbastanza intorno a quella decisione, tirare fuori il piolo diventa molto costoso.
Ecco una domanda che sento di continuo. L’azienda di un cliente può avere molti luoghi di consegna. Ogni luogo dovrebbe essere un Account o un oggetto personalizzato? Prima di rispondere, nota cosa dovresti sapere prima: cosa significa un luogo per questo business, e cosa gli succede. Questo è modellare il business prima degli oggetti. (Ti darò la mia risposta nel capitolo 3.)
Sostenere. Crescere. Rendere.
Sezione intitolata “Sostenere. Crescere. Rendere. ”Quando guardo un modello dati, voglio che superi tre prove: sostenere il business, crescere con il business e rendere.
Sostenere. Il modello deve sostenere ciò che il business sta davvero cercando di fare. C’è una grande differenza tra un modello che tecnicamente può memorizzare i dati e uno che rappresenta bene il business. Se continuo ad aggiungere campi strani, flag speciali, automazioni complicate ed eccezioni perché il modello non calza del tutto, comincio a chiedermi se il problema sia davvero l’automazione. Forse è sbagliato il modello. Un buon modello dovrebbe rendere il business più facile da capire, non più difficile.
Crescere. Quando dico crescere non intendo solo più record. Il volume conta: diecimila record e cento milioni creano problemi molto diversi. Ma le aziende crescono anche in complessità. Aggiungono prodotti, entrano in nuovi mercati, acquisiscono aziende, cambiano processi, aggiungono canali e collegano nuovi sistemi. Scoprono che qualcosa che pensavano fosse una cosa sola è in realtà cinque cose diverse. Un modello che funziona benissimo oggi può diventare una trappola se non lascia spazio al domani. Per questo preferisco progetti che crescono per aggiunta piuttosto che progetti che continuano a cambiare ciò che esiste già. Aggiungere qualcosa di nuovo di solito è più facile che ridefinire qualcosa da cui dipendono decine di altre cose.
Rendere. I dati non restano lì fermi. Li scriviamo, li cerchiamo, li interroghiamo, li condividiamo, ne facciamo report e li integriamo, e sempre più spesso i sistemi di IA li recuperano come contesto prima di agire. Un modello può essere bellissimo in un diagramma ed essere comunque terribile da gestire. Quindi progettiamo sia per come i dati vengono memorizzati sia per come verranno usati.
E deve continuare a rendere. Deve rendere su larga scala: quando aumenta il numero di utenti, quando aumenta il volume dei dati, in condizioni reali e nei picchi, nel giorno più intenso dell’anno e non in quello medio. E deve continuare a rendere quando succede qualcosa di imprevisto.
Sostenere. Crescere. Rendere. Torneremo su queste tre prove per tutto il corso.
Troppo piatto, troppo complicato o semplicemente sbagliato
Sezione intitolata “Troppo piatto, troppo complicato o semplicemente sbagliato ”Ho visto modelli dati andare storti in tre modi.
Il primo è scegliere la cosa sbagliata fin dall’inizio. Usiamo un oggetto standard perché sembra abbastanza simile, poi passiamo anni ad aggiungere eccezioni perché non era mai stato quello giusto. È il piolo quadrato.
Il secondo è rendere il modello troppo piatto. Tutto finisce in un unico oggetto, e all’inizio sembra meravigliosamente semplice. Poi il business cresce, e scopriamo che alcune di quelle cose hanno un proprio ciclo di vita, possono avere più istanze, hanno bisogno di una propria sicurezza o hanno relazioni proprie. All’improvviso rappresentiamo una relazione uno-a-molti con Campo 1, Campo 2 e Campo 3, o con flag e automazioni sempre più complicati. Il modello non ci ha lasciato spazio per crescere.
Il terzo è l’errore opposto: normalizziamo troppo. Creiamo un diagramma elegante con un oggetto dopo l’altro, ogni concetto perfettamente separato. Tecnicamente bellissimo, in pratica un tormento. Gli utenti fanno fatica a capirlo, e i layout di pagina e le pagine Lightning, con un elenco correlato dopo l’altro, possono sembrare senza fondo. Le query diventano più complicate, l’automazione attraversa più relazioni, la reportistica si fa più difficile e la piattaforma lavora di più per rispondere a normali domande di business.
Allora cos’è corretto, piatto o normalizzato? Non c’è una formula. Hai in testa un’immagine del modello ottimale e capisci i trade-off man mano che te ne allontani. È l’arte dell’architettura, e ci torneremo nel modulo 4 e nel prossimo capitolo, dove impariamo a modellare. Per ora, riconosci che la struttura stessa è una decisione architetturale.
Attenzione a cambiare lo scheletro
Sezione intitolata “Attenzione a cambiare lo scheletro ”Una volta che un sistema è in funzione, divento molto prudente sui cambiamenti fondamentali al modello dati.
Supponiamo che un campo di testo esista da anni, e qualcuno dica: “Non lo usiamo più davvero così. Cambiamolo in un numero”. Sembra la modifica di un campo. Ma cosa dipende da quel campo? Flow, Apex, report, integrazioni, pipeline di dati, applicazioni esterne, agenti IA. E cosa succede ai dati storici? La piattaforma stessa non ti permette di cambiare il tipo di un campo finché codice o flow vi fanno ancora riferimento, e questo ti dice quanto lontano arriva la modifica.
A volte la risposta giusta non è modificare ciò che esiste già. A seconda di quanto è grave il cambiamento, preferisco creare qualcosa di nuovo, migrare in modo deliberato e deprecare la vecchia struttura:
Aggiungi invece di modificare. Depreca invece di sorprendere.
Salesforce ti dà persino un modo per dirlo nei metadati: il Field Usage di un campo può essere impostato su DeprecateCandidate, “pianificato per la deprecazione e non più in uso”. Questo segnala il campo a chiunque legga l’oggetto; non nasconde il campo, quindi ritirarlo resta una decisione che devi portare a termine.
Perché una volta che altre parti dell’architettura dipendono da qualcosa, cambiarne il significato può essere molto più pericoloso che cambiarne il nome. La versione peggiore è il campo il cui nome resta lo stesso mentre il contenuto cambia: tutto ciò che sta a valle si fida ancora del nome.
Anche una cosa semplice come spuntare la casella Obbligatorio su un campo può diventare una bomba a orologeria. Se hai già raccolto dati, alcuni record non avranno quel campo compilato. Poi, giorni, settimane o mesi dopo, qualcuno aggiorna uno di quei record e il salvataggio fallisce a causa del campo obbligatorio, e nessuno ha quel valore. Una modifica semplice come rendere obbligatorio un campo può avere conseguenze impreviste e ritardate. Torneremo su Obbligatorio, e su quando un valore è davvero noto, nel capitolo 3.
Oltre l’esame: anche l’IA costruisce sullo scheletro. Chiedi a uno strumento di IA di costruire un’applicazione e genererà oggetti, campi, Flow, Apex, componenti e test in pochi minuti. Se il modello dati originale era sbagliato, non abbiamo evitato le conseguenze di una cattiva decisione; le abbiamo accelerate, perché ogni livello generato è un’altra cosa che dipende da quella struttura. Ecco perché voglio un architetto umano che riveda un modello dati generato dall’IA, lo capisca e ne risponda. Il modulo 7 approfondisce il tema.
Prima viene lo scheletro
Sezione intitolata “Prima viene lo scheletro ”Nel corso parleremo di molta tecnologia: oggetti e relazioni, grandi volumi di dati, query, integrazione, migrazione, transazioni, sicurezza, Data 360 e IA. Sotto tutto questo c’è il modello dati.
Se il modello sostiene il business, può crescere con il business e rende per gli usi che faremo dei dati, abbiamo costruito fondamenta solide. Se sbagliamo le fondamenta, tutto ciò che viene dopo diventa più difficile.
Il modello dati è lo scheletro. Gli architetti dovrebbero fare molta attenzione quando progettano lo scheletro. Modificare strutture esistenti può avere conseguenze a cascata.
Cosa decide qui un architetto
Sezione intitolata “Cosa decide qui un architetto ”- Se il modello sostiene il business, può crescere con esso e rende per gli usi che si faranno dei dati.
- Se un concetto calza in un oggetto standard o è un piolo quadrato.
- Quanto rendere il modello piatto o normalizzato, e perché.
- Se una modifica allo scheletro debba essere un’aggiunta, una migrazione o una deprecazione, invece di una modifica sul posto.
Per approfondire
Sezione intitolata “Per approfondire ”- Considerations for Converting the Field Type of a Custom Field (opens in a new tab), Guida di Salesforce (in inglese, consultato il 2026-10-02; ricontrollato il 2026-10-12): quali cambi di tipo possono far perdere dati, e perché non puoi cambiare il tipo di un campo a cui fanno riferimento Apex, flow o processi.
- Data Classification Metadata Fields (opens in a new tab), Guida di Salesforce (in inglese, consultato il 2026-10-02; ricontrollato il 2026-10-12): i valori di Field Usage (Active, DeprecateCandidate, Hidden) e gli altri campi di classificazione.