Modalità DirectQuery nei modelli tabulari

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

Questo articolo descrive la modalità DirectQuery per i modelli tabulari di Analysis Services ai livelli di compatibilità 1200 e superiori. La modalità DirectQuery può essere abilitata per i modelli che si sta 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 sia i vantaggi che 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 eseguono query sui 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 set di dati molto grandi possono superare la memoria disponibile e l'elaborazione (aggiornamento) dei dati del modello in memoria possono richiedere quantità eccessive di risorse disponibili, se necessario.

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 report client ottengono sempre i dati più recenti.

• Non è previsto alcun sovraccarico aggiuntivo per la gestione della 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 risorsa server Analysis Services.

• 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 a tutte le 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: Azure SQL Database, Azure Synapse Analytics, SQL Server, Oracle e Teradata.
Stored procedure per SQL	Per i modelli DirectQuery, le stored procedure non possono essere specificate in un'istruzione 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 riga predefinito è un milione di righe. Questo limite può essere maggiore 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 istruzioni SQL. Le formule DAX che contengono elementi non convertibili in sintassi SQL causeranno errori di convalida nel modello. Questa restrizione è principalmente 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 potrebbero convalidare quando si passa il modello alla modalità DirectQuery, ma restituiscono risultati diversi quando vengono eseguiti sulla cache rispetto all'archivio dati relazionale. Ciò è dovuto al fatto che i calcoli sulla cache usano la semantica del motore di analisi in memoria, che contiene funzionalità progettate per 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, connettersi a un'origine dati e selezionare le tabelle e i campi da includere nel modello è identico a quello dei modelli in memoria.

Se DirectQuery è già stato attivato ma non è ancora stato connesso a un'origine dati, è possibile usare Recupera 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.

Se hai già usato Recupera dati per importare dati, ma non hai ancora attivato la modalità DirectQuery, quando lo fai, 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à Set as Sample in Partition Manager. 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 esempioin Progettazione modelli tabulari non è supportata. Ignorare TableName <> non contiene una partizione di esempio. Per usare i dati in SSDT, aggiungere avvisi di partizione di esempio.

Distribuzione di modelli DirectQuery

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

Vedi anche

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