Connessione di Looker al tuo database

Dopo aver protetto e configurato il database, puoi connetterlo a Looker.

Creazione di una nuova connessione al database

Seleziona Connessioni nella sezione Database del riquadro Amministratore. Nella pagina Connections (Connessioni), fai clic sul pulsante Add Connection (Aggiungi connessione). Looker visualizza la pagina Connection Settings (Impostazioni di connessione). I campi disponibili nella pagina Impostazioni di connessione dipendono dal dialetto impostato.

Per ulteriori informazioni sull'applicazione di attributi utente alle impostazioni di connessione, consulta la sezione Connessioni della pagina della documentazione Attributi utente.

Per ulteriori informazioni sull'uso della colonna Override PDT per configurare credenziali di accesso separate per i processi PDT, vedi la sezione Configurazione di credenziali di accesso separate per i processi PDT.

Ad esempio, le opzioni seguenti sono disponibili per la configurazione quando colleghi Looker ad Amazon Redshift.

Nome

Il nome della connessione a cui vuoi fare riferimento. Non utilizzare il nome di alcuna cartella. Questo valore non deve corrispondere necessariamente ai contenuti del database, è solo un'etichetta assegnata da te. Lo utilizzerai nel parametro connection del tuo modello LookML.

Dialetto

Il dialetto SQL corrispondente alla tua connessione. È importante scegliere il valore corretto, in modo da visualizzare le opzioni di connessione appropriate e consentire a Looker di convertire correttamente il codice LookML in codice SQL.

Server SSH

L'opzione SSH Server (Server SSH) è disponibile se è stato eseguito il deployment dell'istanza nell'infrastruttura Kubernetes e solo se è stata concessa la possibilità di aggiungere informazioni di configurazione del server SSH alla tua istanza di Looker. Se questa opzione non è abilitata per la tua istanza di Looker e desideri abilitarla, contatta il tuo account manager Looker o apri una richiesta di supporto nel Centro assistenza di Looker.

Il server SSH sceglie automaticamente la porta localhost e al momento non è possibile specificare la porta localhost. Se devi creare una connessione SSH che richiede l'indicazione di una porta localhost, contatta il tuo account manager Looker o apri una richiesta di supporto nel Centro assistenza di Looker.

Per connetterti al tuo database utilizzando un tunnel SSH, attiva il pulsante di attivazione/disattivazione e seleziona una configurazione server SSH dall'elenco a discesa.

Host remoto:Porta

Il nome host del tuo database e la porta che deve essere utilizzata da Looker per la connessione all'host del tuo database.

Se hai lavorato con un analista Looker per configurare un tunnel SSH nel tuo database, nel campo Host inserisci "localhost", mentre nel campo Port inserisci il numero di porta che reindirizza al tuo database, che deve essere stato fornito dall'analista Looker.

Se applichi un attributo utente al campo Host, non puoi avere un livello di accesso utente impostato su Modificabile.

Se hai configurato un tunnel SSH per la connessione al tuo database, non puoi applicare un attributo utente al campo Remote Host:Port (Host remoto:Porta).

Database

Il nome del database sul tuo host. Ad esempio, potresti avere un nome host my-instance.us-east-1.redshift.amazonaws.com in cui è presente un database chiamato sales_info. In tal caso, dovrai specificare sales_info in questo campo. Se sono presenti più database sullo stesso host, potrebbe essere necessario creare più connessioni per utilizzarli (tranne che per MySQL, in cui il termine database assume un significato lievemente diverso da quello attribuito nella maggior parte dei dialetti SQL).

Utilizzare OAuth

Per le connessioni a Snowflake e Google BigQuery, puoi scegliere di utilizzare OAuth. Di conseguenza i tuoi utenti devono accedere, rispettivamente, a Snowflake o Google, per eseguire query da Looker.

Quando selezioni Utilizza OAuth, vengono visualizzati i campi ID client OAuth e Secret client OAuth:

Questi valori vengono generati dal database Snowflake o da Google. Per la procedura completa, consulta la pagina della documentazione che descrive la configurazione di Snowflake OAuth o la configurazione di Google BigQuery OAuth.

Nome utente

Il nome utente che deve essere utilizzato da Looker per connettersi al tuo database. L'utente deve essere configurato preventivamente, attenendosi alle istruzioni per la configurazione del database.

Password

La password che deve essere utilizzata da Looker per connettersi al tuo database. La password deve essere configurata preventivamente, attenendosi alle istruzioni per la configurazione del database.

Schema

Lo schema predefinito utilizzato da Looker quando non è specificato alcuno schema. Viene applicato quando utilizzi SQL Runner, durante la generazione di progetti LookML e quando esegui query sulle tabelle.

Tabelle derivate permanenti

Seleziona questa casella per abilitare le tabelle derivate permanenti. Vengono visualizzati ulteriori campi PDT e la colonna PDT Overrides (Override PDT). Looker visualizza questa opzione solo se il dialetto del database supporta l'uso di PDT.

Tieni presente quanto segue sulle PDT:

  • Le PDT non sono supportate per le connessioni a Snowflake che utilizzano OAuth.
  • La disabilitazione delle PDT su una connessione non implica la disabilitazione dei gruppi di dati associati alle tue PDT. Anche se disabiliti le PDT, i gruppi di dati esistenti continuano a eseguire le proprie query sql_trigger sul database. Se vuoi interrompere l'esecuzione della query sql_trigger di un gruppo di dati sul tuo database, devi eliminare o commentare il parametro datagroup dal progetto LookML. In alternativa, puoi aggiornare l'impostazione PDT and Datagroup Scheduling Schedule per la connessione in modo che Looker controlli le PDT e i gruppi di dati molto raramente o mai.
  • Per le connessioni a Snowflake, Looker imposta il valore del parametro AUTOCOMMIT su TRUE (valore predefinito di Snowflake;#39;s). AUTOCOMMIT è necessaria per i comandi SQL eseguiti da Looker per gestire il proprio sistema di registrazione delle PDT.

Database temporaneo

Anche se è denominato Temp Database (Database temporaneo), devi inserire il nome del database o dello schema, in base al tuo dialetto SQL, che deve essere utilizzato da Looker per creare tabelle derivate permanenti. Il database o lo schema deve essere configurato preventivamente, con le autorizzazioni di scrittura adeguate. Nella pagina della documentazione Istruzioni di configurazione del database, seleziona il dialetto del tuo database per visualizzare le istruzioni corrispondenti.

Ogni connessione deve avere il proprio Temp Database o Schema; non possono essere condivise tra più connessioni.

Max connessioni generatore PDT

L'impostazione Max PDT Builder Connections (Numero massimo di connessioni a generatore PDT) consente di specificare il numero delle operazioni di creazione delle tabelle che possono essere avviate contemporaneamente dal rigeneratore Looker sulla connessione al tuo database. L'impostazione Max PDT Builder Connections (Numero massimo di connessioni a generatore PDT) viene applicata solo ai tipi di tabelle per cui il rigeneratore Looker avvia la ricostruzione, ovvero:

  • Tabelle persistenti per il trigger (tabelle derivate permanenti e tabelle aggregate che utilizzano la strategia di persistenza datagroup_trigger o sql_trigger_value).
  • Tabelle persistenti che utilizzano la strategia persist_for, ma solo quando la tabella persist_for fa parte di una cascata di tabelle derivate da cui dipende una tabella che utilizza la strategia di persistenza datagroup_trigger o sql_trigger_value. In questo caso, il rigeneratore Looker ricostruisce una tabella persist_for, poiché è necessaria per la ricostruzione di un'altra tabella nella cascata. In caso contrario, il rigeneratore non avvia alcuna operazione di creazione per le tabelle persist_for.

L'impostazione Max PDT Builder Connections (Numero massimo di connessioni a generatore PDT) è 1, ma è possibile impostarla su 10. Tuttavia, il valore non può essere superiore a quello impostato nel campo Max Connections (Numero massimo di connessioni) o nelle per-user-query-limit impostate nelle opzioni di avvio di Looker.

Imposta questo valore con attenzione. Un valore troppo elevato può sovraccaricare il database. Se il valore è troppo basso, le PDT a esecuzione prolungata o le tabelle aggregate possono ritardare la creazione di altre tabelle permanenti o rallentare le altre query sulla connessione. I database che supportano la multitenancy, come BigQuery, Snowflake e Redshift, possono gestire più efficacemente la generazione delle query parallele.

Se vuoi aumentare l'impostazione Max PDT Builder Connections (Numero massimo di connessioni a generatore PDT), come regola generale è consigliabile procedere per incrementi di 1. Se si verifica un comportamento imprevisto, ripristina il valore predefinito 1. In caso contrario, se le prestazioni delle query non ne risentono, puoi continuare a incrementare il valore di 1 e a verificare le prestazioni dopo ogni incremento, prima di aumentare ulteriormente l'impostazione.

Tieni presente quanto segue in merito all'impostazione Max PDT Builder Connections (Numero massimo di connessioni a generatore PDT).

  • L'impostazione Max PDT Builder Connections (Numero massimo di connessioni a generatore PDT) viene applicata solo alle connessioni necessarie per la ricostruzione delle tabelle, non alle connessioni necessarie per i controlli trigger. Un controllo trigger è una query che verifica se la strategia di persistenza della tabella è stata attivata. Poiché tali query vengono sempre eseguite in sequenza, l'impostazione Max PDT Builder Connections (Numero massimo di connessioni a generatore PDT) non viene applicata.
  • In un'istanza di Looker in cluster, il rigeneratore viene eseguito solo sul nodo principale. L'impostazione Max PDT Builder Connections (Numero massimo di connessioni a generatore PDT) viene applicata solo al nodo principale, pertanto imposta il limite per l'intero cluster.
  • L'impostazione Max PDT Builder Connections (Numero massimo di connessioni a generatore PDT) non si applica ai tipi di tabelle seguenti. Questi tipi di tabelle vengono creati in sequenza:
    • Le tabelle sono persistenti tramite il parametro persist_for (a meno che la tabella non sia dipende dalle tabelle che utilizzano le strategie datagroup_trigger o sql_trigger_value).
    • Tabelle in modalità Development (Sviluppo).
    • Tabelle ricostruite con l'opzione Rebuild Derived Tables & Run (Ricostruisci tabelle derivate e esegui).
    • Tabelle in cui una dipende dall'altra in una cascata di dipendenza. Non è possibile creare una tabella contemporaneamente alla tabella da cui dipende. Ad esempio, se table_B dipende da table_A, table_A deve terminare la ricostruzione prima che table_B possa iniziare a ricostruire.

Riprova sempre le build PDT non riuscite

L'impostazione Always Retry Failed PDT Builds (Ritenta sempre le ricostruzioni PDT non riuscite) configura il modo in cui il rigeneratore Looker tenta di ricostruire le tabelle persistenti per i trigger non riuscite nel ciclo precedente del rigeneratore. Il rigeneratore Looker è il processo che ricostruisce le tabelle che attivano il trigger (PDT e tabelle aggregate) in base all'intervallo configurato nell'impostazione di connessione PDT and Datagroup Scheduling Schedule. Quando l'impostazione Always Retry Failed PDT Builds (Ritenta sempre le ricostruzioni PDT non riuscite), il rigeneratore Looker tenta di ricostruire le PDT non riuscite nel ciclo precedente del rigeneratore, anche se la relativa condizione trigger non è soddisfatta. Quando questa impostazione è disabilitata, il rigeneratore Looker tenta di ricostruire le PDT non riuscite nel ciclo precedente solo se la relativa condizione trigger è soddisfatta. L'opzione Always Retry Failed PDT Builds (Ritenta sempre le ricostruzioni PDT non riuscite) è disabilitata per impostazione predefinita.

Per ulteriori informazioni sul rigeneratore Looker, consulta la pagina della documentazione sulle tabelle derivate in Looker.

Abilita controllo API PDT

L'impostazione Abilita controllo API PDT determina se le chiamate API start_pdt_build, check_pdt_build e stop_pdt_build possono essere utilizzate per questa connessione. Se l'impostazione è disabilitata, queste chiamate API non andranno a buon fine quando fanno riferimento a PDT su questa connessione. L'opzione Abilita controllo API PDT è disattivata per impostazione predefinita.

Parametri aggiuntivi

Se necessario, qui puoi aggiungere ulteriori parametri JDBC (Java Database Connectivity) per le tue query.

Per fare riferimento a un attributo utente in un parametro JDBC, utilizza la sintassi Modello di liquido: _user_attributes['name_of_attribute']. Ad esempio:

my_jdbc_param={{ _user_attributes['name_of_attribute'] }}

Ecco come potrebbe apparire nel campo Additional Params (Parametri aggiuntivi) in Looker:

I parametri JDBC aggiuntivi non sono stati testati da Looker e potrebbero causare comportamenti indesiderati.

PDT e pianificazione della manutenzione del gruppo di dati

Questa impostazione accetta un'espressione di cron che indica quando il rigeneratore Looker deve controllare i gruppi di dati e le tabelle persistenti (entrambe tabelle aggregate e tabelle derivate permanenti) basate su sql_trigger_value e vedere quali tabelle devono essere rigenerate o eliminate.

Il valore predefinito di */5 * * * * significa"controlla ogni 5 minuti", che è la frequenza massima dei controlli. Un'espressione cron che indica controlli più frequenti comporterà controlli ogni 5 minuti.

Durante la creazione delle PDT, Looker non esegue ulteriori verifiche dei trigger. Dopo aver creato tutte le PDT dell'ultimo controllo dei trigger, Looker riprende a controllare i trigger di gruppi di dati e PDT in base alla pianificazione della manutenzione di PDT e gruppi di dati.

Se il tuo database non è in funzione 24 ore su 24, 7 giorni su 7, puoi limitare i controlli ai tempi in cui è attivo. Di seguito sono riportate alcune espressioni cron aggiuntive:

cron espressione Definizione
*/5 8-17 * * MON-FRI Controlla i gruppi di dati e le PDT ogni 5 minuti, dal lunedì al venerdì durante l'orario lavorativo
*/5 8-17 * * * Controlla i gruppi di dati e le PDT ogni 5 minuti, tutti i giorni durante l'orario lavorativo
0 8-17 * * MON-FRI Controlla i gruppi di dati e le PDT ogni ora, dal lunedì al venerdì durante l'orario lavorativo
1 3 * * * Controlla i gruppi di dati e le PDT ogni giorno alle 03:01

Quando crei un'espressione cron, tieni presente quanto segue:

  • Looker utilizza parse-cron v0.1.3, che non supporta ? nelle espressioni di cron.
  • L'espressione cron utilizza il fuso orario dell'applicazione di Looker per determinare quando vengono effettuati i controlli.
  • Se le PDT non vengono create, reimposta il valore predefinito della stringa cron, ovvero */5 * * * *.

Di seguito sono riportate alcune risorse utili per la creazione delle stringhe cron:

SSL

Scegli se utilizzare o meno la crittografia SSL per proteggere i dati scambiati fra Looker e il tuo database. SSL è solo una delle opzioni disponibili per proteggere i tuoi dati. Le altre opzioni di sicurezza sono illustrate nella pagina della documentazione relativa all'abilitazione dell'accesso sicuro ai database.

Verifica certificato SSL

Scegli se vuoi richiedere la verifica del certificato SSL utilizzato dalla connessione. Se è necessaria la verifica, l'autorità di certificazione (CA) SSL che ha firmato il certificato SSL deve essere inclusa nell'elenco delle origini attendibili del client. Se la CA non è un'origine attendibile, la connessione al database non viene stabilita.

Se questa casella non è selezionata, la crittografia SSL viene comunque utilizzata per la connessione, ma non viene richiesta la verifica della connessione SSL, che può quindi essere stabilita anche se la CA non è inclusa nell'elenco delle origini attendibili del client.

Connessioni massime

Qui puoi impostare il numero massimo di connessioni con il tuo database instaurabili da Looker. Nella maggior parte dei casi, si tratta del numero di query simultanee eseguibili da Looker sul database in questione. Looker riserva inoltre fino a un massimo di tre connessioni per l'interruzione delle query. Se il pool di connessioni è molto piccolo, Looker riserva un numero inferiore di connessioni.

Imposta questo valore con attenzione. Se il valore è troppo elevato, potresti sovraccaricare il tuo database. Se il valore è troppo basso, le query devono condividere un numero limitato di connessioni. Di conseguenza, molte query possono apparire lente agli utenti perché devono attendere la fine di altre query precedenti.

Il valore predefinito (che varia a seconda del dialetto SQL) è solitamente un punto di partenza ragionevole. La maggior parte dei database prevede anche una propria impostazione per il numero massimo di connessioni accettate. Se la configurazione del tuo database limita le connessioni, assicurati che il valore di Max Connections (Numero massimo di connessioni) sia minore o uguale al limite del database.

Timeout del pool di connessioni

Se gli utenti richiedono un numero di connessioni superiore al valore dell'impostazione Max Connections (Numero massimo di connessioni), le richieste in eccesso possono essere eseguite solo quando terminano quelle precedenti. Questa impostazione specifica il tempo massimo di attesa delle richieste. Questo valore deve essere impostato con attenzione. Se è troppo basso, le query di alcuni utenti rischiano di essere annullate perché il tempo disponibile non è sufficiente per completare le query di altri utenti. Se è troppo elevato, le numerose query rischiano di accumularsi costringendo gli utenti ad attendere molto tempo. Il valore predefinito è solitamente un punto di partenza ragionevole.

Stima dei costi

La casella di controllo Stima dei costi si applica solo alle seguenti connessioni al database:

La casella di controllo Stima dei costi attiva le seguenti funzionalità sulla connessione:

Le connessioni BigQuery e MySQL supportano anche la funzionalità Stima dei costi; tuttavia, poiché la funzionalità è sempre attiva, non è presente la casella di controllo Stima dei costi per le connessioni BigQuery e MySQL.

Per ulteriori informazioni, consulta la pagina Esplorare i dati in Looker.

Cache SQL Runner

In SQL Runner, tutte le informazioni relative alle tabelle vengono precaricate appena selezioni una connessione e uno schema. Questo permette a SQL Runner di visualizzare rapidamente le colonne di una tabella appena fai clic sul suo nome. Tuttavia, per le connessioni e gli schemi associati a tabelle numerose o molto grandi non è consigliabile precaricare tutte le informazioni richieste da SQL Runner.

Se preferisci che SQL Runner carichi le informazioni sulle singole tabelle solo quando vengono selezionate, puoi deselezionare l'opzione SQL Runner Precache (Pre-cache SQL Runner) per disabilitare il precaricamento per la connessione.

Schema di informazioni di recupero per la scrittura SQL

Per alcune funzionalità di scrittura SQL, come l'awareness aggregata, Looker utilizza lo schema di informazioni del database per ottimizzare la scrittura SQL. Se lo schema di informazioni non viene memorizzato nella cache, di tanto in tanto Looker potrebbe avere l'esigenza di bloccare la scrittura del codice SQL nel database al fine di recuperare lo schema di informazioni. Per i dialetti che utilizzano HDFS (Hadoop Distributed File System), il tempo necessario per recuperare lo schema di informazioni può determinare un notevole calo di prestazioni delle query di Looker. Se sai che il tuo schema di informazioni è lento, puoi disattivare l'opzione Fetch Information Schema For SQL writing (Recupera schema informazioni per scrittura SQL) per la tua connessione. La disattivazione di questa funzionalità impedisce in parte l'ottimizzazione SQL di Looker per determinate funzionalità, quindi dovresti abilitare l'opzione Fetch Information Schema For SQL writing (Recupera schema informazioni per scrittura SQL) a meno che non sai che lo schema di informazioni della tua connessione è particolarmente lento.

Disattiva commento contestuale

L'opzione Disabilita commento contestuale si applica solo alle connessioni BigQuery. I commenti relativi al contesto sulle connessioni a Google BigQuery sono disattivati per impostazione predefinita perché la presenza di commenti contestuali invalida la capacità di Google BigQuery di memorizzare nella cache e può influire negativamente sulle prestazioni della cache. Puoi abilitare i commenti relativi al contesto per una connessione BigQuery deselezionando l'impostazione Disabilita commento contestuale nella pagina Impostazioni di connessione per la connessione. Per ulteriori informazioni, consulta la pagina della documentazione relativa a Google BigQuery.

Fuso orario database

Il fuso orario utilizzato dal database per memorizzare le informazioni basate sul tempo. Looker utilizza queste impostazioni al fine di convertire i valori di data/ora per gli utenti, semplificando la comprensione e l'utilizzo dei dati basati sul tempo. Per ulteriori informazioni, consulta la pagina Utilizzo delle impostazioni del fuso orario.

Fuso orario query

L'opzione Fuso orario query è visibile solo se hai disattivato i Fusi orari specifici degli utenti.

Quando Fusi orari specifici degli utenti sono disattivati, il fuso orario della query è il fuso orario che viene visualizzato dagli utenti quando eseguono query su dati basati sul tempo, mentre il fuso orario in cui Looker convertirà i dati basati sul tempo dal fuso orario del database.

Per ulteriori informazioni, consulta la pagina Utilizzo delle impostazioni del fuso orario.

Configurazione di credenziali di accesso separate per i processi PDT

Se il tuo database supporta le tabelle derivate permanenti e hai selezionato la casella Persistent Derived Tables (Tabelle derivate permanenti) nelle impostazioni di connessione, Looker mostra la colonna PDT Overrides (Override PDT). Nella colonna Override delle PDT, puoi inserire parametri JDBC separati (host, porta, database, nome utente, password, schema e parametri aggiuntivi) specifici dei processi PDT. Questo può essere utile per vari motivi:

  • Creando un utente di database separato per i processi PDT, puoi utilizzare le PDT nel tuo modello anche se assegni gli attributi utente alle tue credenziali di accesso al database.
  • I processi PDT possono autenticarsi mediante un utente separato del database, dotato di una priorità superiore. In questo modo, il database può privilegiare i job PDT rispetto alle query utente meno critiche.
  • L'accesso in scrittura può essere revocato per la connessione standard al database di Looker e concesso solo a un utente speciale, che verrà utilizzato dai processi PDT per l'autenticazione. Si tratta di una strategia di sicurezza più efficace per la maggior parte delle organizzazioni.
  • Per database come Snowflake, i processi PDT possono essere instradati verso componenti hardware più potenti, che non vengono condivisi con gli altri utenti di Looker. In questo modo, le PDT vengono create più rapidamente, senza dover sostenere i costi dell'esecuzione a tempo pieno di risorse hardware più costose.

Ad esempio, la configurazione che segue utilizza una connessione in cui i campi Username (Nome utente) e Password vengono impostati su attributi utente. In questo modo, ogni utente può accedere al database utilizzando le proprie credenziali individuali. La colonna Override PDT crea un utente separato (pdt_user) con una propria password. L'account pdt_user verrà utilizzato per tutti i processi PDT, con livelli di accesso adeguati alla creazione e all'aggiornamento delle PDT:

La colonna Override PDT consente di modificare l'utente del database e le altre proprietà di connessione, ma un override PDT deve leggere gli stessi dati della connessione predefinita e deve scrivere i dati nella stessa posizione. Looker non può leggere i dati da una posizione e scriverli in un'altra.

Test delle impostazioni di connessione

Dopo aver inserito le credenziali, fai clic su Test These Settings (Prova queste impostazioni) per verificare che le informazioni siano corrette e che il database sia in grado di connettersi.

Se la connessione non supera uno o più test:

  • Prova alcuni dei passaggi per la risoluzione dei problemi disponibili nella pagina della documentazione Testare la connettività del database.
  • Se utilizzi Mongo versione 3.6 o precedente su Atlas e ricevi un errore del link di comunicazione, consulta la pagina della documentazione di Connettore Mongo.
  • Per ricevere un messaggio di connessione riuscita per lo schema temp e le PDT, devi abilitare questa funzionalità durante la configurazione del database Looker. Per sapere come eseguire questa operazione, consulta la pagina della documentazione relativa alle istruzioni per la configurazione del database.

Le connessioni di database che utilizzano OAuth, come Snowflake e Google BigQuery, richiedono l'accesso da parte dell'utente. Se non hai eseguito l'accesso al tuo account utente OAuth quando provi una di queste connessioni, Looker mostrerà un avviso con un link Log In (Accedi). Fai clic sul link per inserire le tue credenziali OAuth o per consentire a Looker di accedere ai dati del tuo account OAuth.

Se hai ancora problemi, puoi chiedere aiuto all'Assistenza Looker.

Testa come utente

Se hai impostato uno o più valori dei parametri di connessione per un attributo utente, sopra il pulsante Testa queste impostazioni verrà visualizzata l'opzione Testa come utente. Seleziona un utente e fai clic su Test These Settings (Prova queste impostazioni) per verificare che il database sia in grado di connettersi ed eseguire le query in base a questo utente.

Aggiungere la connessione al database

Dopo aver configurato e testato le impostazioni di connessione al database, fai clic su Aggiungi connessione. La connessione al tuo database viene aggiunta all'elenco della pagina Connessioni.

Passaggi successivi

Dopo aver collegato il database a Looker, puoi configurare le opzioni di accesso per gli utenti.