Modellare i dati per il loro significato
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)
Guida allo studio del capitolo 2 del corso Data Architect. Leggi prima i sei moduli; questa pagina ti aiuta a verificare cosa ti è rimasto.
Su questa guida allo studio. È costruita solo con i contenuti di questo corso e con l’elenco degli obiettivi della guida all’esame pubblicata da Salesforce. Non si basa mai su domande reali d’esame, e non pretende di sapere cosa c’è nell’esame. Se hai sostenuto l’esame, per favore non mandarmi domande: l’accordo di certificazione vieta di condividerle, e memorizzare le risposte è comunque il modo sbagliato per diventare architetto.
Questo capitolo è la base della sezione dell’esame su Data Modeling and Database Design, che vale un quarto dell’esame. Copre il ragionamento; il prossimo capitolo, Architettura dei dati Salesforce, copre come lo costruisce la piattaforma. Quindi gran parte di ciò che viene verificato su oggetti, campi e relazioni richiede entrambi i capitoli.
Per l’esame
Sezione intitolata “Per l’esame ”I punti di questo capitolo che più probabilmente contano all’esame. Ognuno è legato al suo obiettivo d’esame e rimanda al punto in cui è spiegato. Spuntali man mano.
DM-1: confrontare le tecniche per progettare un modello dati Salesforce
- So spiegare la differenza tra un modello dati concettuale, logico e fisico, e a cosa serve ciascuno. (Trasforma il modello in Salesforce)
- So trovare le entità candidate in un requisito, e distinguere una persona che svolge un lavoro da un dato. (I sostantivi ti danno entità candidate)
- So leggere e disegnare la notazione a zampa di gallina (crow’s foot): uno, molti, e il secondo segno per facoltativo o obbligatorio. (Leggi le linee, Anche l’opzionalità conta)
- So indicare la cardinalità di una relazione: uno-a-uno, uno-a-molti, molti-a-molti. (Chiedi “uno o molti?”)
- So che una relazione molti-a-molti diventa un’entità a sé, e in Salesforce di solito un oggetto di giunzione con due padri. (Le relazioni possono diventare cose)
- So quando una relazione ha bisogno di uno storico (un record con date di inizio e di fine) invece di un campo che viene sovrascritto. (Il tempo cambia le relazioni)
- So scegliere un buon ID univoco, e so perché una chiave naturale o qualsiasi cosa contenga dati personali è una scelta rischiosa. (Poi dobbiamo parlare di ID univoci)
- Conosco la differenza tra una chiave naturale e una chiave surrogata, e so che un record può portare diversi identificatori esterni. (Chiavi naturali e chiavi surrogate)
- So che un campo a numerazione automatica (Auto Number) è un numero leggibile, non l’ID Salesforce del record. (Le relazioni dipendono dagli ID univoci)
- So applicare la prima, la seconda e la terza forma normale, e riconoscere un campo che contiene più valori o ripete un fatto su qualcos’altro. (Un modo semplice di pensare a 1NF, 2NF e 3NF)
- So spiegare quando denormalizzare di proposito (utenti, reportistica, scala), e quanto costa. (Progetta fino alla terza forma normale, poi fai un passo indietro)
- So scegliere tra un elenco di selezione e una relazione di ricerca verso un oggetto per un elenco di valori. (Relazione di ricerca o elenco di selezione?)
- So che un tipo di report personalizzato consente al massimo quattro relazioni tra oggetti, e perché conta nei modelli profondi. (Relazione di ricerca o elenco di selezione?)
- So quando va bene una master-dettaglio (il figlio non viene mai riassegnato a un altro padre) e quando una relazione di ricerca è più sicura, inclusa l’indicazione di Salesforce di non superare i 10.000 figli su un solo padre. (Le relazioni diventano decisioni di piattaforma)
- So perché evitare le relazioni polimorfiche quando posso. (Le relazioni diventano decisioni di piattaforma)
- So che un’entità di business non significa automaticamente un oggetto personalizzato: può essere un oggetto standard, un campo, una configurazione o dati che risiedono fuori da Salesforce. (Un’entità di business non significa automaticamente un oggetto personalizzato)
Oltre l’esame
Sezione intitolata “Oltre l’esame ”L’esame è il pavimento, non il soffitto. Queste sono le abitudini di questo capitolo di cui un architetto ha bisogno, che una domanda le chieda o no.
- Dimentica Salesforce per un minuto. Modella il business prima di tradurlo in Account e Contatto.
- Ascolta la parola che nasconde due cose. In Steve Trucking, “cliente” era un Partner retail e un Destinatario.
- Il modello fa parte della conversazione. Il tuo primo modello non deve essere giusto; deve mostrarti dove sbagli.
- Dai un nome alle linee. Due modelli con gli stessi riquadri possono significare cose diverse.
- Chiedi “adesso o nel tempo?” per ogni relazione.
- Unico, immutabile, privo di significato, mai un dato personale.
- Metti ogni fatto al suo posto, poi fai un passo indietro di proposito, e scrivi il perché.
- La denormalizzazione non elimina la complessità; la sposta. Sappi chi possiede la verità.
- Un’unica fonte di verità, molte forme: schermate, report, il data warehouse e l’IA.
- Non progettare partendo da Imposta. Disegna il modello prima di cliccare Nuovo oggetto personalizzato.
- Riconduci ogni decisione fisica a qualcosa di cui il business ha bisogno.
Parole da conoscere
Sezione intitolata “Parole da conoscere ”| Termine | In una riga |
|---|---|
| Entità | Una cosa che interessa al business e di cui conserva dati |
| Entità candidata | Un sostantivo che potrebbe diventare un’entità, dopo le domande giuste |
| Attributo | Un fatto che descrive un’entità |
| Relazione | Come sono collegate due entità, con un nome nel linguaggio del business |
| Cardinalità | Quanti dell’una sono collegati a quanti dell’altra |
| Opzionalità | Se la relazione è obbligatoria, o può essere zero |
| Zampa di gallina (crow’s foot) | Il segno per “molti” all’estremità di una linea |
| Oggetto di giunzione | Il modo di Salesforce per costruire una relazione molti-a-molti: un figlio di entrambi i padri |
| Modello concettuale | Cosa esiste nel business e come è collegato; niente Salesforce |
| Modello logico | I dati: attributi, ID univoci e relazioni, ancora non legati a una piattaforma |
| Modello fisico | Come lo costruirà la piattaforma: oggetti, campi e tipi di relazione |
| Chiave naturale | Un identificatore che esiste già nel business, come il VIN di un camion |
| Chiave surrogata | Un identificatore creato solo per identificare il record |
| Identificatore esterno | L’ID di un altro sistema per lo stesso record, conservato e mappato |
| Normalizzazione (1NF, 2NF, 3NF) | Mettere ogni fatto al suo posto: un valore per campo, fatti sull’intera chiave, nessun fatto su altri fatti |
| Denormalizzazione | Copiare o appiattire i dati di proposito, per una ragione che sai nominare |
| Anomalia di aggiornamento | Lo stesso fatto memorizzato in molti posti, così una modifica lascia sbagliate alcune copie |
Mettiti alla prova
Sezione intitolata “Mettiti alla prova ”Brevi scenari nello stile del corso. Decidi la tua risposta prima di aprirla.
1. Un'azienda ti dice che una squadra guida un camion. Sei settimane dopo, qualcuno chiede quale squadra aveva il camion 117 in un certo giorno. Cosa avrebbe dovuto avere il modello?
Un’Assegnazione della squadra: la relazione tra squadra e camion come record a sé, con una data di inizio, una data di fine e il percorso. Squadre e camion sono in relazione molti-a-molti nel tempo, e al business interessa lo storico. Un campo sul camion sarebbe stato sovrascritto. Rileggi Il tempo cambia le relazioni.
2. Un team propone di usare il numero di telefono di ogni Destinatario come ID univoco, “perché è unico”. Cosa rispondi?
Non supera le prove: i numeri di telefono cambiano e vengono condivisi, quindi non è immutabile né affidabilmente unico, ed è un dato personale che verrebbe copiato in ogni sistema collegato al record. Usa un ID generato privo di significato e tieni il numero di telefono come attributo. Rileggi Poi dobbiamo parlare di ID univoci.
3. Una Consegna ha i campi Articolo 1, Articolo 2 e Articolo 3. Arriva una consegna con quattro articoli. Qual è il vero problema, e la soluzione?
Il modello ha nascosto una struttura ripetuta dentro dei campi (un problema di prima forma normale). La soluzione non è un campo Articolo 4; è un’entità Articolo della consegna, figlia della Consegna, così ogni articolo è un record. Rileggi Prima forma normale: non nascondere le strutture ripetute.
4. Ogni consegna memorizza il nome del responsabile del centro di distribuzione. Il responsabile cambia. Cosa è andato storto?
Un fatto su qualcos’altro (il centro di distribuzione) è stato memorizzato sulla consegna: un problema di terza forma normale, e ora un’anomalia di aggiornamento su centinaia di record. Il responsabile sta con il centro di distribuzione; la consegna punta al centro di distribuzione. Rileggi Terza forma normale: non memorizzare fatti su altri fatti.
5. Il tipo di tappa (solo consegna, con installazione, con ritiro dell'usato) ha bisogno di una durata, delle competenze della squadra e di una checklist. Elenco di selezione o oggetto?
Un oggetto. Ha più di una colonna di informazioni, lo gestisce il business e cambia secondo i propri tempi. Lo stato di una consegna, un elenco breve e stabile di etichette, resta un elenco di selezione. Rileggi Relazione di ricerca o elenco di selezione?.
6. I partner vogliono una scheda di valutazione della puntualità per regione, e la regione sta sul centro di distribuzione. Copi la regione su ogni consegna. Cosa devi decidere?
Chi possiede la verità, come la copia resta sincronizzata, e se le consegne passate debbano conservare la regione che era vera quando sono avvenute o seguire il centro di distribuzione se si sposta. Denormalizzare ha spostato la complessità; non l’ha eliminata. Rileggi A volte vince la reportistica.
7. Un esercizio come Seduto potrebbe essere collegato a centinaia di migliaia di animali. Master-dettaglio o relazione di ricerca da Esercizio dell'animale a Esercizio?
Una relazione di ricerca. L’indicazione di Salesforce è di non superare i 10.000 figli su un solo padre, e un esercizio popolare li supererebbe. La master-dettaglio va bene da Esercizio dell’animale ad Animale, perché l’esercizio di un animale non viene mai riassegnato a un altro padre e un animale conosce solo pochi esercizi; è anche ciò che permette all’animale di calcolare con un roll-up il conteggio Esercizi conosciuti. Rileggi Seduto, resta, modello.
Per approfondire
Sezione intitolata “Per approfondire ”- Salesforce Certified Platform Data Architect Exam Guide (opens in a new tab), Guida di Salesforce (in inglese, consultato il 2026-09-25): l’elenco ufficiale degli obiettivi e dei loro pesi. Controlla sempre la versione attuale prima di prenotare l’esame.