Modalità DirectQuery nei modelli tabulari

Si applica a: SQL Server Analysis Services Azure Analysis Services Power BI Premium

Questo articolo descrive la modalità DirectQuery per Analysis Services modelli tabulari con livelli di compatibilità 1200 e superiori. La modalità DirectQuery può essere abilitata per i modelli che si stanno progettando in Visual Studio o per i modelli tabulari già distribuiti, è possibile passare alla modalità DirectQuery usando SQL Server Management Studio (SSMS). Prima di scegliere la modalità DirectQuery, è importante comprendere i vantaggi e le limitazioni.

Vantaggi

Per impostazione predefinita, i modelli tabulari utilizzano una cache in memoria per l'archiviazione dei dati e l'esecuzione di query. Quando i modelli tabulari e interrogano i dati che risiedono in memoria, anche le query complesse possono essere molto veloci. Esistono tuttavia alcune limitazioni all'uso dei dati memorizzati nella cache, ad esempio i set di dati di dimensioni molto grandi possono superare la memoria disponibile e l'elaborazione (aggiornamento) dei dati del modello in memoria può richiedere quantità eccessive di risorse disponibili, se necessario di frequente.

DirectQuery supera queste limitazioni sfruttando allo stesso tempo le funzionalità RDBMS che rendono più efficiente l'esecuzione di query. Con DirectQuery:

  • I dati sono aggiornati. Poiché i dati vengono sempre sottoposti a query nell'origine dati, le applicazioni di creazione report client stanno sempre ricevendo i dati più recenti.

  • Non esiste alcun sovraccarico di gestione aggiuntivo dovuto alla necessità di mantenere una copia separata dei dati (nella cache in memoria). Non è necessaria alcuna elaborazione (aggiornamento) dei dati del modello. Le modifiche ai dati di origine sottostanti possono essere immediatamente riflesse nelle query sul modello di dati.

  • I set di dati possono essere maggiori della capacità di memoria di una Analysis Services server.

  • DirectQuery può sfruttare l'accelerazione delle query sul lato provider, ad esempio quella fornita dagli indici di colonna ottimizzati per la memoria.

  • La sicurezza può essere applicata dal database di origine back-end usando le funzionalità di sicurezza a livello di riga del database . In alternativa, è possibile usare le regole di sicurezza a livello di riga definite nel modello tramite DAX.

  • Se il modello contiene formule complesse che potrebbero richiedere più query, Analysis Services consente di eseguire l'ottimizzazione per garantire che il piano relativo alla query eseguita sul database back-end sia il più efficiente possibile.

Limitazioni

I modelli tabulari in modalità DirectQuery presentano alcune limitazioni. Prima di cambiare modalità, è importante stabilire se i vantaggi dell'esecuzione di query sul server back-end superano la riduzione della funzionalità. Se si modifica la modalità di un modello esistente in Visual Studio, Progettazione modelli tabulari invierà una notifica alle funzionalità del modello incompatibili con la modalità DirectQuery. Tenere presenti le limitazioni seguenti:

Funzionalità Restrizione
Origini dati I modelli DirectQuery possono usare solo i dati di un singolo database relazionale dei tipi seguenti: database SQL di Azure, Azure Synapse Analytics, SQL Server, Oracle e Teradata.
Stored procedure per SQL Per i modelli DirectQuery, non è possibile specificare stored procedure in un SQL per definire le tabelle.
Tabelle calcolate Le tabelle calcolate non sono supportate nei modelli DirectQuery. Sono invece supportate le colonne calcolate. Se si tenta di convertire un modello tabulare che contiene una tabella calcolata, viene visualizzato un errore che informa che il modello non può contenere i dati incollati.
Limiti delle query Il limite di righe predefinito è un milione di righe. Questo limite può essere incrementato specificando MaxIntermediateRowSize. Per altre informazioni, vedere Proprietà DAX.
Formule DAX Quando si esegue una query su un modello tabulare in modalità DirectQuery, Analysis Services converte le formule DAX e le definizioni di misura in SQL istruzioni . Le formule DAX che contengono elementi non convertibili in sintassi SQL causeranno errori di convalida nel modello.

Questa restrizione è per lo più limitata a determinate funzioni di tabella DAX. Per le misure, le formule DAX vengono convertite in operazioni basate su set nell'archivio dati relazionale. Per questo motivo, sono supportate tutte le misure create in modo implicito.

Quando si verifica un errore di convalida, è necessario, riscrivere una formula, inserire una funzione diversa o applicare una soluzione alternativa usando colonne derivate nell'origine dati. Se un modello tabulare include formule contenenti funzioni incompatibili, verrà segnalato quando si passa alla modalità DirectQuery nella finestra di progettazione.

Nota: alcune formule nel modello possono essere convalidate quando si passa alla modalità DirectQuery, ma restituiscono risultati diversi quando vengono eseguite nella cache rispetto all'archivio dati relazionale. Questo perché i calcoli sulla cache usano la semantica del motore di analisi in memoria, che contiene funzionalità destinate a emulare il comportamento di Excel, mentre le query sui dati archiviati nell'origine dati relazionale usano la semantica di SQL.

Coerenza delle formula In alcuni casi, la stessa formula può restituire risultati diversi in un modello memorizzato nella cache rispetto a un modello DirectQuery che usa unicamente l'archivio dati relazionale. Queste differenze sono una conseguenza delle differenze semantiche tra il motore di analisi in memoria e l'origine dati.

Limitazioni MDX Nessun nome di oggetto relativo. Tutti i nomi di oggetto devono essere completi.

Nessuna istruzione MDX con ambito sessione (set denominati, membri calcolati, celle calcolate, totali visualizzati, membri predefiniti e così via), ma è possibile usare costrutti con ambito query, come la clausola 'WITH'.

Nessuna tupla con membri da livelli diversi in clausole sub-SELECT MDX.

Nessuna gerarchia definita dall'utente.

Nessuna query SQL nativa. Normalmente, Analysis Services supporta un subset T-SQL, ma non per modelli DirectQuery.

Connessione a un'origine dati

Quando si progetta un modello DirectQuery in Visual Studio, la connessione a un'origine dati e la selezione delle tabelle e dei campi da includere nel modello sono molto uguali a quanto con i modelli in memoria.

Se DirectQuery è già stato attivato ma non si è ancora connessi a un'origine dati, è possibile usare l'opzione Ottieni dati (o Importazione guidata dati per le origini dati del provider legacy) per connettersi a un'origine dati, selezionare tabelle e campi e così via. La differenza è che al termine dell'operazione nessun dato viene effettivamente importato nella cache in memoria.

Importazione DirectQuery completata

Se è già stato usato Il comando Ottieni dati per importare i dati, ma non è ancora stata attivata la modalità DirectQuery, quando si esegue questa operazione, la cache in memoria verrà cancellata.

Aggiunta di dati di esempio a un progetto di modello DirectQuery

Per impostazione predefinita, quando si usa Progettazione modelli tabulari in Visual Studio (SSDT) per progettare un progetto di modello tabulare DirectQuery, il database dell'area di lavoro del modello non contiene dati. Esiste una partizione predefinita per ogni tabella e questa partizione indirizza tutte le query all'origine dati. Poiché DirectQuery è stato introdotto per la prima volta, Progettazione modelli tabulari include una funzionalità Imposta come esempio in Gestione partizioni. Questa funzionalità consente di aggiungere una partizione di copia alle tabelle che possono essere usate per importare una piccola quantità di dati di esempio nel database dell'area di lavoro. Questa funzionalità consente di convalidare le decisioni di modellazione senza influire sull'origine dati.

Importante

Attualmente, la funzionalità Imposta come esempio in Progettazione modelli tabulari non è supportata. Ignora tabella non contiene una partizione di esempio. Per usare i dati in <TableName> SSDT, aggiungere avvisi di partizione di esempio.

Distribuzione di modelli DirectQuery

I modelli DirectQuery vengono distribuiti come i modelli di importazione. Tuttavia, a differenza dei modelli di importazione, se un modello DirectQuery contiene elementi calcolati, ad esempio colonne calcolate o gruppi di calcolo, dopo la distribuzione è necessario eseguire un ricalcolo del processo in tutte le tabelle. Per altre informazioni, vedere Elaborare database, tabelle o partizioni.

Vedi anche

Abilitare la modalità DirectQuery in Visual Studio
Abilitare la modalità DirectQuery in SSMS
Definire partizioni nei modelli DirectQuery Testare un modello in modalità DirectQuery
Origini dati supportate in Azure Analysis Services
Origini dati supportate nei SQL Server Analysis Services tabulari 1400 e versioni successive.