Disegna le relazioni
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 6 del capitolo Modellare i dati per il loro significato, capitolo 2 del corso Data Architect. Ogni modulo si regge da solo. Precedente: Ascolta i sostantivi · Successivo: Costruisci il modello logico
La domanda a cui risponde questo modulo: Come trasformo le entità candidate in un modello dati concettuale?
Abbiamo i sostantivi sulla lavagna. Ora voglio sapere delle linee tra i riquadri, perché un insieme di entità non è ancora davvero un modello dati. È nelle relazioni che vive gran parte del significato. Un Partner retail gestisce dei centri di distribuzione. Un manifesto di carico elenca delle consegne. Una consegna va a un Destinatario. Una squadra guida un camion. Ognuna di queste affermazioni mi dice qualcosa sul business, e ognuna mi dà un’altra domanda da porre.
Parti dal linguaggio del business
Sezione intitolata “Parti dal linguaggio del business ”Non voglio ancora parlare di Salesforce. Non mi sto chiedendo se debba essere una relazione di ricerca o master-dettaglio, non penso agli oggetti di giunzione di Salesforce (Salesforce Junction Object) e non decido cosa succede quando un record padre viene eliminato. Sto cercando di capire la relazione di business.
Prendi “un Partner retail gestisce dei centri di distribuzione”. Sembra semplice. Ma un Partner retail può avere un CD o molti? In Steve Trucking, ogni Partner retail gestisce un centro di distribuzione regionale in ogni regione servita da Steve Trucking, quindi molti. Un CD può appartenere a più di un Partner retail? Un CD conta di per sé, con il suo personale e la sua storia, o è solo un indirizzo? Se un Partner retail se ne va, ci interessano ancora i suoi CD?
Non sono domande su Salesforce. Sono domande di business, e le risposte possono cambiare completamente il modello.
Leggi le linee
Sezione intitolata “Leggi le linee ”Prima di andare più a fondo, voglio darti il linguaggio che useremo in ogni diagramma da qui in avanti. È piccolo. Una linea tra due riquadri dice che le due cose sono collegate, e i segni alle sue estremità dicono quante.
Comincia da una linea semplice, senza nessun segno. È da lì che parto sulla lavagna: so che questi due sostantivi sono collegati, solo che non ho ancora chiesto come. Poi le estremità ricevono dei segni. Una sola barra trasversale sulla linea, la croce, significa uno. La zampa di gallina (crow’s foot), l’estremità che si apre in tre come la zampa di un uccello, significa molti. Più avanti in questo modulo vedrai comparire un secondo segno accanto al primo, una barra o un cerchio, e quello risponde a un’altra domanda: possono non essercene?
L’unica regola da ricordare: ogni segno si legge dal lato del riquadro che tocca. Il segno più vicino al riquadro indica il massimo possibile; il segno successivo, il minimo.
Seduto, resta, modello
Sezione intitolata “Seduto, resta, modello ”Prima di Steve Trucking, torniamo ai cani del modulo 1. Avevamo cinque riquadri: Proprietario, Allevatore, Cane, Razza ed Esercizio. Ora mi chiedo quali sono le linee tra loro.
Uno o molti? Un proprietario può avere più di un cane; Ana ne ha due. Un cane ha un solo proprietario, almeno nel nostro modello. È uno-a-molti: una barra dalla parte del Proprietario, una zampa di gallina dalla parte del Cane. L’allevatore ha la stessa forma: un allevatore alleva molti cani.
Può non essercene nessuno? Max viene dal canile, quindi non ha nessun allevatore. L’estremità dell’Allevatore riceve un cerchio: un cane ha zero o un allevatore. Ogni cane però ha un proprietario, quindi quell’estremità riceve una seconda barra: esattamente uno.
Molti a molti? Un cane conosce molti esercizi, e un esercizio, per esempio Seduto, è conosciuto da molti cani. È molti-a-molti, ed è proprio lì che vado a cercare un concetto nascosto. C’è qualcosa che riguarda questo cane che conosce questo esercizio? Quanto bene lo fa, e quando lo ha imparato. La relazione ha fatti suoi, quindi diventa una cosa a sé: l’Esercizio del cane, con il cane nel nome, perché è il cane a guidarlo. (In inglese è Dog Trick, con il nome del cane per primo.)
Cosa significa ogni linea? Un proprietario possiede un cane. Un allevatore lo alleva. Un cane conosce i suoi esercizi. Dai un nome alle linee, e chiunque potrà rileggerti il modello.
Adesso o nel tempo? A qualcuno interessa quanto è brava Bella oggi in Seduto, o come ci è arrivata? Se un addestratore la valuta ogni pochi mesi, ogni valutazione è un record a sé: una Valutazione dell’esercizio, con la data, il livello di abilità e chi ha fatto la valutazione, sotto l’Esercizio del cane a cui appartiene. Anche una relazione diventata una cosa può avere uno storico suo.
Per ora lascio Razza scollegata. È ancora la domanda del modulo 1, un riquadro a sé o una parola sul cane, e la risolve il modulo 4.
Ognuna di queste domande funziona allo stesso modo su un business vero. Ora poniamole a Steve Trucking.
Chiedi “uno o molti?”
Sezione intitolata “Chiedi “uno o molti?” ”Una delle prime cose che voglio capire di una relazione è la sua cardinalità. È il termine dei database; la domanda è molto più semplice: quanti di questi possono essere collegati a quanti di quelli? A livello concettuale ci sono tre schemi di base.
È un passaggio importante del processo: prendi due sostantivi diversi e capisci la loro relazione. Nella maggior parte dei casi è uno-a-molti, o molti-a-uno. Solo in rare circostanze incontrerai una relazione uno-a-uno.
Uno-a-molti è dappertutto. Un Partner retail ha molti centri di distribuzione. Un manifesto di carico elenca molte consegne. Un percorso ha una decina di tappe. Quando sento un linguaggio del genere, inizio a tracciare la linea.
E ora la linea riceve i suoi segni. Ogni estremità ti dice quanti ce ne sono del riquadro che tocca: la barra per uno, la zampa di gallina per molti. Leggila da ogni riquadro: un Partner retail ha molti Centri di distribuzione.
Le relazioni uno-a-uno esistono, ma sono rare, e quando ne trovo una pongo qualche domanda. Sono davvero due sostantivi diversi, o lo stesso? Se sono diversi, qual è la relazione uno-a-uno tra loro? E sarà sempre uno-a-uno, o solo uno-a-uno adesso? Sono domande chiave nel progettare il modello dati. Una squadra e un camion sembrano uno-a-uno in una mattina qualsiasi: due persone, un camion, un percorso. Nell’arco di un mese non lo sono, ed è lì che si nasconde la relazione più interessante di questo modello.
Le relazioni molti-a-molti sono particolarmente interessanti, perché spesso ci dicono che nel business c’è un altro concetto. Una squadra può guidare più di un camion nel tempo? Sì. Un camion può essere guidato da più di una squadra? Nell’arco della sua vita, certamente. Quindi squadre e camion hanno una relazione molti-a-molti. Ma ora voglio sapere di più. Al business interessa quando una squadra aveva un camion? Per quale percorso, in quale giorno? Chi ha fatto l’assegnazione? Se la relazione stessa porta informazioni che ci interessano, abbiamo scoperto un altro concetto di business: l’Assegnazione della squadra (Crew Assignment).
È un’abitudine di modellazione importante. A volte la cosa più interessante non è uno dei sostantivi che abbiamo sentito all’inizio. Si nasconde nella relazione tra due sostantivi.
Le relazioni possono diventare cose
Sezione intitolata “Le relazioni possono diventare cose ”È uno dei punti in cui voglio che gli amministratori inizino a pensare in modo diverso. In Salesforce siamo abituati a parlare di oggetti e campi, quindi è facile trattare i riquadri come la parte importante e le linee come tubature. Ma la relazione stessa può avere un significato di business.
Considera una consegna e i prodotti che contiene. Una consegna può portare diversi prodotti, per esempio una lavatrice e un’asciugatrice. Un prodotto, lo stesso modello di frigorifero, compare in migliaia di consegne. Abbastanza facile. Ma se devo sapere quanti pezzi di quel prodotto ci sono in questa consegna, se viene installato, o se quello vecchio viene ritirato? Non mi interessa più solo una relazione tra Consegna e Prodotto. Mi interessa un Articolo della consegna (Delivery Item), e quel concetto merita un’entità tutta sua.
Se vieni da Salesforce, forse stai già pensando: “È un oggetto di giunzione”. Non sbagli. Ma non voglio partire da lì. Un Articolo della consegna è un concetto di business prima di essere un oggetto di giunzione di Salesforce. Prima il business, poi l’implementazione.
Alcune mie abitudini per queste entità di relazione, ovunque finiscano per essere costruite.
Dagli un nome. Se il business ha già una parola, usa la sua. Se non ce l’ha, prendi i nomi dei due genitori e mettili insieme. Pensa a un ordine e a un prodotto. La cosa tra loro è l’Order Item: l’ordine, e l’articolo nell’ordine. È figlio di entrambi i genitori, e in Salesforce potrebbe diventare un oggetto di giunzione di Salesforce. Ma quale nome va per primo: Item Order o Order Item? Guarda che tipo di dati è ciascun genitore. Il prodotto è un dato di riferimento; l’ordine è transazionale, ed è l’ordine a guidarlo. Quindi è Order Item, o Order Product, così come Salesforce ha Opportunity Product. In Steve Trucking è il Delivery Item (l’Articolo della consegna). Il nome che guida va per primo, e il record si ordina accanto al suo titolare in ogni elenco che guarderai. (In italiano l’ordine delle parole è inverso, “articolo della consegna”, ma il principio non cambia: il nome resta legato a chi lo guida.)
Dagli una chiave tutta sua. Si è tentati di dire che un Articolo della consegna è identificato da Consegna più Prodotto e fermarsi lì. È una chiave composta, e le chiavi composte sono molto più difficili da gestire: ogni sistema che punta al record deve portarsi dietro entrambe le metà. Dai all’entità di relazione un suo identificatore, e tieni Consegna più Prodotto come regola di unicità, non come identità.
Nota cosa non c’è: un numero di serie. Una quantità e un numero di serie non stanno sullo stesso record. Una quantità conta più pezzi di una cosa; un numero di serie identifica una cosa precisa. Se il business ha bisogno dei numeri di serie, ogni unità diventa un record a sé, e cinque frigoriferi sono cinque record. Non vedo un caso per un Articolo della consegna con sotto un Dettaglio dell’articolo della consegna. È l’una o l’altra cosa: un aggregato con una quantità, o un record per unità. Qui è la quantità.
Tieni d’occhio gli attributi che vogliono uno storico. Alcune entità di relazione restano fisse una volta create: la lavatrice in questa consegna resta la lavatrice in questa consegna. Altre continuano a cambiare. Una squadra ha il camion 117 questa settimana, e la settimana prossima il camion passa a un’altra squadra. Quando la relazione cambia e al business interessa com’era prima, l’entità di relazione ha bisogno di date, e quella da tenere d’occhio è l’Assegnazione della squadra. Chiedi presto se al business interessa adesso o nel tempo; ci torniamo tra poco.
Le relazioni hanno un significato oltre la cardinalità
Sezione intitolata “Le relazioni hanno un significato oltre la cardinalità ”“Uno-a-molti” non basta per capire una relazione. Voglio anche sapere cosa significa la relazione.
Una consegna ha un luogo. Quale? Il centro di distribuzione da cui parte? La casa del Destinatario dove arriva? Non sono intercambiabili. Due modelli possono avere esattamente gli stessi riquadri e la stessa cardinalità, e le linee possono significare cose completamente diverse. Ecco perché un buon modello non è solo un insieme di riquadri collegati da linee. Le linee hanno bisogno di un nome. Se passo il mio diagramma a un altro architetto, non dovrebbe dover indovinare cosa significa una relazione, e se lo mostro al business, dovrebbe usare un linguaggio che riconosce.
Anche l’opzionalità conta
Sezione intitolata “Anche l’opzionalità conta ”Dentro “quanti?” si nasconde un’altra domanda: la relazione è obbligatoria? Una consegna può esistere prima di essere messa su un percorso? Deve: il manifesto di carico arriva un giorno o due prima della consegna, e i percorsi vengono definiti la sera prima. Una consegna può esistere senza un Partner retail? No; ogni consegna viene dal manifesto di un partner. Questa è l’opzionalità.
Di nuovo, non saltare subito alla casella Obbligatorio di Salesforce. C’è differenza tra dire “ogni consegna deve avere un Partner retail” e dire “Salesforce deve rendere obbligatorio il campo Partner retail quando il record viene creato”. Potrebbero finire per essere la stessa implementazione, ma non sono la stessa affermazione. La prima è una regola di business; la seconda è un modo per farla rispettare. Come architetti, vogliamo capire la prima prima di decidere la seconda.
Nel diagramma, l’opzionalità è il secondo segno su ogni estremità. Il segno più vicino al riquadro indica il massimo possibile: la barra per uno, la zampa di gallina per molti. Il segno successivo indica il minimo: un’altra barra significa almeno uno, un cerchio significa che può essere zero. Quindi ogni Consegna è su esattamente un Manifesto di carico, e un Manifesto di carico elenca una o molte Consegne. Una Consegna è a zero o una Tappa, nessuna finché non è stata assegnata a un percorso, e a una Tappa si lasciano zero o molte Consegne.
Il tempo cambia le relazioni
Sezione intitolata “Il tempo cambia le relazioni ”Ecco una domanda che faccio spesso: intendi adesso, o intendi nel tempo?
Una squadra guida un camion. Adesso? Per il percorso di oggi? Finché quelle due persone lavorano insieme? Ne escono modelli diversi. Se al business interessa solo quale camion ha una squadra oggi, il modello può restare semplice. Se servono tutti i camion che una squadra ha guidato, quando e su quale percorso, ci serve lo storico, e quell’Assegnazione della squadra che abbiamo scoperto diventa all’improvviso molto importante.
È una fonte comune di errori di modellazione. Modelliamo lo stato attuale perché è ciò che vediamo sullo schermo. Poi, settimane dopo, un Partner retail presenta un reclamo per danni e qualcuno chiede: “Quale squadra aveva il camion 117 il 17 marzo?”. E scopriamo di aver sovrascritto la risposta ogni volta che l’assegnazione cambiava.
Un modo per conservare quello storico è fare dell’assegnazione un record a sé. Quando una squadra viene assegnata, creiamo un’Assegnazione della squadra con una data di inizio. Quando l’assegnazione cambia, mettiamo una data di fine sul vecchio record e ne creiamo uno nuovo con la sua data di inizio. Ora “chi aveva quell’assegnazione sei mesi fa?” è una domanda semplice, invece di uno scavo nella cronologia dei campi o in un registro delle modifiche ai dati. E una volta che una squadra ha avuto molte assegnazioni, qualcuno chiederà qual è quella attuale, quindi aggiungerei anche un flag Attivo (Active).
Quindi quando qualcuno mi parla di una relazione, non chiedo solo come sono collegate le cose. Chiedo: quella relazione cambia, e ci interessa il suo storico?
Disegna prima di configurare
Sezione intitolata “Disegna prima di configurare ”Il nostro modello di Steve Trucking sta diventando utile. Sappiamo quali relazioni sono uno-a-molti, dove una molti-a-molti nasconde un altro concetto, quali relazioni sono facoltative e quali cambiano nel tempo. E non abbiamo ancora creato un oggetto Salesforce. È voluto.
Questo diagramma dovrebbe essere qualcosa che posso mettere davanti al business, e non dovrebbero aver bisogno di conoscere Salesforce per dirmi se è giusto. Se non possono convalidarlo perché è pieno di terminologia Salesforce, sono passato troppo in fretta al progetto fisico.
Cosa decide qui un architetto
Sezione intitolata “Cosa decide qui un architetto ”Quando lavoro sulle relazioni in un modello concettuale, decido:
- Come le principali entità di business si collegano tra loro.
- Se ogni relazione è uno-a-uno, uno-a-molti o molti-a-molti, adesso e nel tempo.
- Se ogni relazione è obbligatoria o facoltativa.
- Se una relazione molti-a-molti nasconde un concetto di business significativo.
- Se la relazione cambia nel tempo, e se ci serve il suo storico.
Relazione di ricerca o master-dettaglio, configurazione della giunzione, comportamento a cascata e condivisione sono decisioni fisiche; ci arriveremo. Per ora stiamo ancora rispondendo alla domanda più importante: come funziona davvero questo business? Una volta capite le entità e le relazioni tra loro, possiamo iniziare ad aggiungere i dettagli che le descrivono. È allora che il nostro modello concettuale inizia a diventare un modello dati logico.