Un contratto sulle metriche è ciò a cui somiglia un livello semantico quando qualcosa lo fa davvero rispettare. Come una definizione viene fissata, cosa succede a una domanda che nomina campi di due warehouse, e perché gli identificatori che raggiungono l’SQL vengono dal contratto stesso.
Aggiornato · 6 min di lettura
Una definizione che è stata pubblicata e una definizione che è stata fissata sembrano identiche in un browser di catalogo. Entrambe portano un nome, un’espressione e un proprietario. La differenza si vede nel momento in cui qualcuno fa una domanda.
Fissare è ciò che succede quando il livello legge una volta l’oggetto contratto della piattaforma e memorizza ciò che ha trovato: i membri, le loro espressioni e l’oggetto da cui provengono. Ogni domanda successiva viene risolta contro la copia memorizzata invece che contro ciò che ha digitato chi chiede.
La copia memorizzata contiene nomi ed espressioni, mai righe. Viene riappresa a ogni sincronizzazione: una misura aggiunta nel warehouse martedì arriva con la sincronizzazione di martedì, e nessuno deve ricordarsi di ribatterla.
Un contratto appreso è un documento breve e noioso, e la noia è la caratteristica.
Un contratto è una descrizione e una lista di autorizzazione allo stesso tempo. Il documento che dice a una persona cosa esiste è il documento che dice al costruttore di query cosa può girare. Non c’è mai una seconda copia da tenere allineata.
Tutte e quattro le piattaforme ti lasciano definire la stessa cosa, e tutte e quattro hanno la propria idea di come si chiama un membro. Il vocabolario vale la pena sistemarlo prima della tua prima query, perché i primi fallimenti sono quasi sempre fallimenti di nomi, non di modellazione.
L’indicizzazione è per entità e nome insieme invece che per solo nome, e questo è emerso girando contro un account reale invece che leggendo la documentazione. Cinque semantic view lì definivano ciascuna lo stesso nome di dimensione su due entità, una a granularità di documento e una a granularità di sezione. Un dizionario indicizzato sul solo nome ha fuso le gemelle in una singola voce che non apparteneva a nessuna delle due. Nulla ha dato errore, e ogni risposta costruita sopra sarebbe stata sbagliata in un modo che nessuno poteva vedere.
Una domanda che nomina campi di due warehouse diversi è una cosa ragionevole da volere e irragionevole da eseguire. Due contratti appartengono a due motori, e non c’è un terzo motore sotto entrambi.
Il livello fa due lavori con gli stessi oggetti e li tiene separati. Per l’inventario, lo stesso schema e la stessa tabella visti in più warehouse diventano un unico oggetto logico che ricorda ogni sorgente da cui è venuto, che è ciò che rende possibile un rapporto di confronto. Per l’esecuzione, un contratto appartiene al warehouse da cui è stato appreso, e la query viene instradata lì. Una domanda che mescola due contratti torna nominando cosa è stato mescolato, e non viene mai risolta in silenzio verso il contratto che capitava di essere elencato per primo.
Dentro un singolo warehouse la stessa forma compare un livello più giù. Un modello che non dichiara alcuna relazione tra due entità non può rispondere a una domanda che le attraversa, e il warehouse lo dice con le sue parole. È una risposta di modellazione che vale la pena leggere: ti sta dicendo che il join che tutti davano per esistente non è mai stato dichiarato.
Confrontare tra warehouse e calcolare dentro uno solo sono lavori diversi. Tenerli separati è ciò che permette alla stessa tabella di comparire una volta in un rapporto di governance ed essere comunque calcolata in esattamente un motore.
Quando una domanda diventa un’istruzione, le stringhe inserite in quell’istruzione sono le copie del contratto stesso. Ciò che il chiamante ha digitato serve a cercare un membro. Ciò che raggiunge l’SQL è ciò che la sincronizzazione ha memorizzato.
È una piccola distinzione e sistema tre cose in una volta.
La proprietà è architetturale, non istruttiva. A un modello si può dire di usare solo nomi approvati, e una conversazione abbastanza strana finirà per convincerlo del contrario. Un percorso di codice mai scritto non ha nulla di cui essere convinto.
Una domanda a cui il contratto non sa rispondere torna nominando il problema, e quella risposta è la metà più utile della funzione. Tre forme coprono quasi tutto ciò che incontrerai.
Quei messaggi arrivano dal warehouse parola per parola invece che levigati in un codice di stato. Un compilatore che descrive la propria risposta è quasi sempre più preciso di una parafrasi, e la parafrasi è ciò che manda qualcuno a fare debug di un host che è sempre stato a posto.
Quest’ultimo punto merita un secondo sguardo. Conservare la forma di un risultato e scartarne il contenuto è ciò che rende una traccia di audit sicura da tenere per anni, e anni è l’unica durata utile per una traccia di audit.
Un livello semantico dà a una metrica una sola casa. Ogni strumento che calcola la metrica legge quell’unica casa. Tutti ottengono lo stesso numero. Ecco cosa significa in pratica, e cosa cambia quando gestisci più di un warehouse.
L’accesso di cui ha bisogno un livello di governance è stretto, specifico e vale la pena nominarlo con precisione. Cosa viene letto da un catalogo, cosa significa sola lettura quando è strutturale e non promessa, perché il tuo ruolo nel warehouse resta il confine, e cosa ti dà ereditare un catalogo.
La regola approva per eseguire, in parole semplici. L’assistente legge, spiega e propone, e una persona possiede il percorso di scrittura. Cosa costa, cosa rende, e tre domande da fare a qualsiasi funzione di IA.