Trasforma il modello in Salesforce

🌐 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 6 di 6 del capitolo Modellare i dati per il loro significato, capitolo 2 del corso Data Architect. Ogni modulo si regge da solo. Precedente: Progetta fino alla terza forma normale, poi fai un passo indietro · Successivo: la guida allo studio del capitolo, poi il prossimo capitolo: Architettura dei dati Salesforce

La domanda a cui risponde questo modulo: Come diventa un modello dati logico un modello dati fisico Salesforce?

Finalmente parliamo di Salesforce. Se hai resistito alla tentazione di trasformare ogni riquadro in un oggetto, ora puoi farlo. Ma nota l’ordine con cui siamo arrivati qui: abbiamo capito il business, descritto i dati, messo ogni fatto al suo posto, e deciso dove piegheremo di proposito queste regole. Solo ora mi chiedo come Salesforce dovrebbe implementarlo. È la progressione che voglio che tu ricordi: concettuale → logico → fisico. Il modello concettuale descrive il business. Il modello logico descrive i dati. Il modello fisico descrive come lo costruiremo davvero.

Seduto, resta, modello

Il passo fisico è più facile da vedere su qualcosa di piccolo, quindi gli animali vanno per primi.

Chi sono le aziende e le persone? L’allevatore è un’azienda, quindi diventa un Account con un tipo di record Allevatore. Anche il proprietario è un Account, o un account personale, con un tipo di record Proprietario. Due tipi dello stesso oggetto standard, uno accanto all’altro in cima al diagramma, proprio dove sono stati fin dal modulo 1.

Cosa non ha una casa standard? Animale, Razza, Esercizio, Esercizio dell’animale e Valutazione dell’esercizio diventano oggetti personalizzati. E ricordi la specie che abbiamo copiato sull’animale nel modulo 5? Qui riceve il suo lavoro: diventa il tipo di record dell’Animale, Cane o Gatto. Un solo oggetto con due tipi di record, ognuno con il proprio layout di pagina e i propri valori degli elenchi di selezione, invece di un oggetto Cane e un oggetto Gatto.

Quali relazioni sono master-dettaglio? Uso la master-dettaglio solo dove il figlio non verrà mai riassegnato a un altro padre. Un Esercizio dell’animale appartiene al suo animale per tutta la vita, e ogni Valutazione dell’esercizio appartiene al suo Esercizio dell’animale, quindi entrambe sono master-dettaglio. Ripaga subito: la master-dettaglio è ciò che permette all’animale di tenere un campo di riepilogo roll-up dei suoi Esercizi dell’animale, così il conteggio Esercizi conosciuti del modulo 5 resta allineato da solo. Gli animali però cambiano casa, quindi il Proprietario è una relazione di ricerca.

Quali sono relazioni di ricerca? Salesforce sconsiglia più di 10.000 figli su un singolo padre. Un esercizio popolare come Seduto, una razza comune o un grande allevatore potrebbero superarli facilmente, quindi l’Esercizio dell’animale punta al suo Esercizio con una relazione di ricerca, e l’animale punta allo stesso modo alla sua Razza e al suo Allevatore. E evita le relazioni polimorfiche quando puoi, quelle in cui un campo può puntare a diversi tipi di oggetto. Sono comode il primo giorno e più difficili per tutto ciò che deve leggerle dopo: report, integrazioni e ora gli agenti.

Cosa resta fuori dalla piattaforma? Se l’animale porta un collare GPS che segnala dove si trova, quella posizione non ha bisogno di essere copiata affatto. Può essere un oggetto esterno, letto in tempo reale dal sistema di tracciamento del collare.

Click to enlarge

Ogni decisione su quel diagramma risale a qualcosa che abbiamo deciso prima, ed è proprio questo il punto. Ora lo stesso passo per Steve Trucking.

Parti dal modello logico

Il nostro modello logico di Steve Trucking ora contiene Partner retail, Centro di distribuzione, Manifesto di carico, Consegna, Articolo della consegna, Destinatario, Percorso, Tappa, Squadra, Camion e Assegnazione della squadra. Sono concetti di business, e ora posso iniziare a tradurli in Salesforce.

Un Partner retail potrebbe essere un Account. Una consegna potrebbe corrispondere a qualcosa che Salesforce ha già per il lavoro pianificato sul campo, oppure diventare un oggetto personalizzato. Per un manifesto di carico non c’è niente di standard che vada bene, quindi probabilmente diventa personalizzato. E il Destinatario è una domanda davvero difficile: un Account personale, un Contatto, o semplicemente informazioni sulla consegna? Risponderemo come si deve nel prossimo capitolo.

La parola importante è ancora potrebbe. Non dare per scontata l’implementazione solo perché un concetto di business suona come un oggetto Salesforce. Ecco perché abbiamo costruito prima il modello logico: ci dà qualcosa con cui mettere alla prova il progetto Salesforce.

Un’entità di business non significa automaticamente un oggetto personalizzato

Ecco una trappola che voglio che gli amministratori evitino: “Abbiamo individuato undici entità, quindi ci servono undici oggetti personalizzati”. No. Un’entità logica ci dice che il concetto di business conta. Non detta come Salesforce debba memorizzarlo. Un concetto potrebbe diventare un oggetto standard, un oggetto personalizzato, una relazione tra oggetti, un campo o qualche campo, un valore gestito nella configurazione, o dati che risiedono del tutto fuori da Salesforce (le foto delle consegne di Steve Trucking sono una buona candidata). È nel modello fisico che si fanno queste scelte, ed è proprio per questo che non le abbiamo fatte alla prima chiamata.

Gli attributi diventano campi fisici

Lo stesso passaggio avviene con gli attributi. Il nostro Camion logico ha un numero di unità, un numero di telaio (VIN), marca, modello, anno del modello, targa e stato. Ora decidiamo come esistono fisicamente: quale oggetto li possiede, quali tipi di campo usano, quali sono obbligatori, quali devono essere unici, quali sono identificatori esterni, quali hanno bisogno di convalida, quali sono derivati anziché memorizzati, e quali sono sensibili. A livello logico ci siamo chiesti cosa significa Camion. A livello fisico ci chiediamo come Salesforce rappresenterà Camion. Domande diverse.

Click to enlarge

Le relazioni diventano decisioni di piattaforma

Tutto il tempo che abbiamo dedicato alle relazioni ripaga qui. Sappiamo già se ognuna è uno-a-uno, uno-a-molti o molti-a-molti, obbligatoria o facoltativa, e se il suo storico conta. Ora decidiamo come Salesforce la implementa: una relazione di ricerca, una master-dettaglio o un oggetto di giunzione di Salesforce, e magari una giunzione con attributi propri, perché, come abbiamo visto, la relazione stessa può avere un significato di business.

Ripensa all’Assegnazione della squadra. Avremmo potuto iniziare questo capitolo dicendo: “Creiamo un oggetto di giunzione di Salesforce tra squadra e camion”. Guarda cosa avremmo saltato: perché esiste la relazione, se ha bisogno di una data e di un percorso, se ha uno stato, e se un reclamo per danni settimane dopo ha bisogno del suo storico. Queste domande di business ci dicono cosa è un’Assegnazione della squadra. Solo dopo dovremmo decidere come Salesforce la costruisce, e se Salesforce ha già qualcosa che fa il lavoro.

Ora disegna il modello fisico

Il diagramma cambia di nuovo. Il modello concettuale mostrava concetti di business e linee semplici. Il modello logico ha aggiunto attributi, chiavi, cardinalità e le entità nascoste nelle relazioni. Ora il modello fisico inizia ad assomigliare a Salesforce: oggetti standard, oggetti personalizzati, campi, tipi di relazione, e ciò che risiede fuori dalla piattaforma.

Click to enlarge

Voglio che tu riesca a mettere quei tre diagrammi uno accanto all’altro e vedere la progressione: non tre diagrammi scollegati, ma lo stesso business a tre livelli.

Due parole su come li disegno, perché la disposizione fa parte del messaggio. Metto l’oggetto principale al centro, leggermente in basso. Se ha oggetti padre, li metto leggermente sopra, così il modello si legge dall’alto in basso, da sinistra a destra, come lo pensa il business. I dati di riferimento vanno di lato. Anche il colore significa qualcosa: faccio sempre Salesforce in blu, e scelgo un colore per i sistemi dell’azienda stessa, di solito verde, perché il verde è un colore simpatico e amichevole. Non uso il rosso, e i gialli sono un po’ aggressivi. Quando un modello è disposto così, per me canta. Molti dei diagrammi che troverai sono in realtà gestione dello spazio: come parcheggio tutte le mie auto nel mio garage intasato? Preferisco dipingere un quadro logico che la mente possa afferrare.

Il modello fisico deve rispettare la piattaforma

Salesforce non è un database relazionale generico. Ha le sue idee su relazioni, titolarità, sicurezza e reportistica. Ha limiti, un comportamento delle query e un’automazione, e un’architettura che influisce su come si comporta un modello su larga scala. Quindi un modello logico che sembra perfetto su una lavagna potrebbe dover cambiare quando diventa fisico. Non è Salesforce che si mette di traverso. Significa che la piattaforma ha una forma, e i buoni architetti capiscono quella forma. Il prossimo capitolo parla proprio di questo.

A volte, inoltre, il modello fisico si discosterà di proposito dal modello logico pulito per via delle decisioni di denormalizzazione prese nel modulo 5. Va bene, purché sappiamo spiegare perché.

Non progettare partendo da Imposta

C’è un’abitudine che voglio che tu perda, se ce l’hai: iniziare la tua architettura dei dati da Imposta → Gestione oggetti → Nuovo oggetto personalizzato e capire il modello strada facendo. Salesforce rende incredibilmente facile creare cose; è uno dei suoi punti di forza, e uno dei motivi per cui i modelli dati deboli nascono così in fretta. Pochi clic e hai un oggetto, qualche altro e hai campi e una relazione. Poi arrivano i dati, si costruiscono i flow, si creano i report, le integrazioni ne dipendono, e l’oggetto che hai creato in cinque minuti diventa molto costoso da cambiare. È il Test di Reversibilità del capitolo 1. Quindi, prima di cliccare Nuovo oggetto personalizzato, disegna il modello.

Fisico non significa permanente

C’è un’altra ragione per cui tengo separati i tre modelli: la tecnologia cambia. Oggi una parte dei dati di Steve Trucking risiede sul core di Salesforce. Domani una parte potrebbe risiedere in Data 360, in un data warehouse o in un sistema che non abbiamo ancora scelto, e l’assistente IA ha bisogno di una sua rappresentazione. L’architettura fisica può cambiare, mentre i concetti di business restano notevolmente stabili: Partner retail, consegne e Destinatari esistono ancora. È questo che rende prezioso il modello logico. È una descrizione duratura del business, non legata all’implementazione di oggi.

Cosa decide qui un architetto

Quando trasformo un modello logico in un modello fisico Salesforce, decido:

• Quali entità di business corrispondono a funzionalità standard di Salesforce, e quali hanno bisogno di oggetti personalizzati o di un’altra rappresentazione.
• Come gli attributi logici diventano campi fisici, e come le relazioni vengono implementate sulla piattaforma.
• Dove trova posto la denormalizzazione deliberata nel progetto fisico.
• Quali dati stanno su Salesforce, e quali da un’altra parte.
• Quali caratteristiche della piattaforma richiedono che il modello fisico si discosti da quello logico.

Soprattutto, voglio poter ricondurre ogni decisione all’indietro. Se indichi qualcosa nel mio modello fisico e chiedi “Perché è lì?”, dovrei poterti riportare attraverso il modello logico e il modello concettuale fino a qualcosa di cui il business ha davvero bisogno: business → concettuale → logico → fisico.

Oltre l’esame: cosa cambia l’IA. Oggi l’IA può portare un documento dei requisiti fino agli oggetti e ai campi Salesforce in un solo salto. Questo rende la sequenza più importante, non meno: se salta dai requisiti alla configurazione, chiedile di mostrare cosa è successo nel mezzo: cosa ha deciso che fosse un’entità, quali chiavi ha scelto, quali relazioni ha dato per scontate e dove ha denormalizzato. Sono decisioni di architettura, e l’architetto ha ancora bisogno di vederle.

Abbiamo iniziato questo capitolo a una prima chiamata, ascoltando i sostantivi, e lo chiudiamo con un modello fisico che possiamo ricondurre al business. Ora che abbiamo scelto di costruire su Salesforce, la domanda successiva va più a fondo: su che tipo di piattaforma dati stiamo costruendo davvero?

Per approfondire

• Designing Record Access for Enterprise Scale: Parent-Child Data Skew (opens in a new tab), Salesforce Developers, Winter ‘27 (in inglese, consultato il 2026-10-02): “configure parent-child relationships with no more than 10,000 children to one parent record” (configura le relazioni padre-figlio con non più di 10.000 figli per record padre). Un’indicazione sullo squilibrio dei dati (data skew), non un limite rigido; il capitolo 7 va più a fondo.
• Roll-Up Summary Field (opens in a new tab), Guida di Salesforce (in inglese, consultato il 2026-10-12): un campo di riepilogo roll-up conta o somma i record di dettaglio attraverso una relazione master-dettaglio.