Salta ai contenuti

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)

Capitolo 2 di Data Architect, Parte 1: Diventare un architetto dei dati. Precedente: Pensare da Salesforce Data Architect.

Una delle cose che faccio alla prima chiamata con un cliente è ascoltare i sostantivi. Partner retail. Destinatario. Centro di distribuzione. Consegna. Camion. Da qualche parte in quella conversazione ci sono gli inizi del mio modello dati, e voglio cominciare a vederlo prima che qualcuno apra Imposta. In questo capitolo lo faremo due volte. Prima su qualcosa che tutti capiscono, una scuola per cani: proprietari, allevatori, cani e gli esercizi che conoscono. Poi su Steve Trucking, l’azienda di consegne dell’ultimo miglio che usiamo in tutto il corso.

Una persona ascolta il titolare di un'attività di consegne e abbozza la prima forma di un modello dati in una casa nel deserto

Immagine generata con l’IA.

Nel capitolo 1 ho detto che il modello dati è lo scheletro. Questo capitolo spiega come si progetta lo scheletro, nell’ordine in cui lo faccio io: capire il business, descrivere i dati e solo allora decidere come Salesforce li implementerà. Concettuale, poi logico, poi fisico. Se indichi qualsiasi cosa nel mio modello fisico e chiedi “perché è lì?”, voglio poterti riportare indietro attraverso il modello logico e quello concettuale fino a qualcosa di cui il business ha davvero bisogno.

Ogni modulo comincia dai cani, in una breve sezione intitolata Seduto, resta, modello, e poi porta la stessa mossa in Steve Trucking. Osserva il modello dei cani man mano: è un unico diagramma che cresce di modulo in modulo, dai semplici riquadri alle relazioni, a un modello dati dettagliato, fino agli oggetti Salesforce, e ogni riquadro resta nello stesso posto, così puoi vedere esattamente cosa aggiunge ogni passo.

  1. Ascolta i sostantivi. Trova gli inizi di un modello dati in una conversazione di business, e dimentica Salesforce per un minuto. Cinque sostantivi sui cani diventano cinque riquadri candidati.
  2. Disegna le relazioni. Uno o molti, obbligatorio o facoltativo, ora o nel tempo, e il concetto di business nascosto in una relazione molti-a-molti: l’Esercizio del cane e l’Assegnazione della squadra.
  3. Costruisci il modello logico. Attributi che descrivono la cosa giusta, e chiavi uniche, immutabili, prive di significato, mai dati personali (PII). Perché il nome di un cane, il telefono del suo proprietario e perfino il suo microchip non bastano come chiave.
  4. Metti i dati dove devono stare. Che cos’è la normalizzazione, poi un foglio di calcolo con sei cani portato passo dopo passo fino alla terza forma normale, e le stesse tre domande in Steve Trucking.
  5. Progetta fino alla terza forma normale, poi fai un passo indietro. Quando mi allontano di proposito dal modello pulito: utenti, reportistica, elenco di selezione o relazione di ricerca, scala, analisi e IA. E il giorno in cui la scuola per cani comincia ad accettare i gatti.
  6. Trasforma il modello in Salesforce. Dal modello logico agli oggetti standard e personalizzati, ai campi e alle relazioni, master-dettaglio o relazione di ricerca, e perché non si progetta partendo da Imposta.

Quando hai finito, mettiti alla prova con la guida allo studio del capitolo: una checklist per l’esame, le abitudini che vanno oltre, le parole da conoscere e qualche domanda.

  • Trovare entità e relazioni candidate in una conversazione o in un documento dei requisiti, e convalidarle con il business.
  • Descrivere ogni relazione: la sua cardinalità, il suo significato, se è obbligatoria e se la sua storia conta.
  • Costruire un modello logico con gli attributi sulle entità giuste e chiavi che reggono.
  • Applicare 1NF, 2NF e 3NF come domande pratiche, e denormalizzare in modo deliberato, sapendo quanto costa.
  • Tradurre un modello logico in Salesforce e ricondurre ogni scelta fisica al business.

Successivo: Architettura dei dati Salesforce