Modo DirectQuery (SSAS Tabular)

O Analysis Services permite recuperar dados e criar relatórios de um modelo tabular recuperando dados e agregações diretamente de um sistema de banco de dados relacional, usando o modo DirectQuery. Este tópico apresenta as diferenças entre modelos tabulares padrão que residem apenas em modelos de memória e de tabela que podem consultar uma fonte de dados relacional e explica como você pode criar e implantar um modelo para uso no modo DirectQuery.

Seções neste tópico:

• Benefícios do modo DirectQuery

• Criando modelos para uso com o modo DirectQuery

  • Fontes de dados para modelos DirectQuery

  • Restrições de validação e design para o modo DirectQuery

  • Compatibilidade de fórmulas para modelos DirectQuery

  • Segurança no modo DirectQuery

  • Segurança no modo DirectQuery

• Propriedades do DirectQuery

• Tópicos e tarefas relacionados

Benefícios do modo DirectQuery

Por padrão, modelos tabulares usam um cache na memória para armazenar e consultar dados. Como os modelos tabulares usam dados que residem na memória, até mesmo consultas complexas podem ser incrivelmente rápidas. No entanto, há algumas desvantagens em usar dados armazenados em cache:

• Os dados não são atualizados quando os dados de origem são alterados. Você deve processar o modelo para obter atualizações para os dados.

• Quando você desativa o computador que hospeda o modelo, o cache é salvo em disco e deve ser reaberto quando você carrega o modelo ou abre o arquivo PowerPivot. As operações de salvamento e carregamento podem ser demoradas.

Por outro lado, o modo DirectQuery usa dados armazenados em um banco de dados do SQL Server. Em geral, você importa todo ou um pequeno exemplo dos dados para o cache durante a criação do modelo e, ao implantar o modelo, especifica que a fonte de dados para consultas no modelo deve ser o SQL Server, não os dados armazenados em cache. Todas as consultas DAX nos dados são traduzidas pelo Analysis Services em instruções SQL equivalentes em relação à fonte de dados relacional especificada.

Há muitas vantagens em implantar um modelo usando o modo DirectQuery:

• É possível ter um modelo sobre conjuntos de dados que são muito grandes para caber na memória no servidor do Analysis Services.

• Os dados são garantidos como up-to-date e não há sobrecarga extra de gerenciamento de ter que manter uma cópia separada dos dados. As alterações nos dados de origem subjacentes podem ser refletidas imediatamente em consultas no modelo de dados.

• O DirectQuery pode aproveitar a aceleração de consultas realizadas do lado do provedor, como a proporcionada pelos índices de colunas otimizados para memória do xVelocity.

• Qualquer segurança imposta pelo banco de dados de back-end tem a garantia de ser imposta, usando a segurança em nível de linha. Por outro lado, se você estiver usando dados armazenados em cache, pode ser difícil garantir que o cache seja protegido exatamente como no servidor.

• Se o modelo contiver fórmulas complexas que possam exigir várias consultas, o Analysis Services poderá executar a otimização para garantir que o plano de consulta para a consulta executada no banco de dados back-end seja o mais eficiente possível.

Criando modelos para uso com o modo DirectQuery

Os modelos de tabela são criados usando o designer de modelos SQL Server Data Tools (SSDT). O designer de modelo cria todos os modelos na memória, o que significa que, quando você estiver modelando, se os dados forem muito grandes para caber na memória, você deverá importar apenas um subconjunto de dados para o cache usado pelo banco de dados do workspace.

Quando estiver pronto para mudar para o modo DirectQuery, você poderá alterar uma propriedade que habilita o modo DirectQuery. Para obter mais informações, consulte Habilitar o Modo de Design do DirectQuery (SSAS Tabular).

Quando você faz isso, o designer de modelo configura automaticamente o banco de dados do workspace para ser executado em um modo híbrido que permite que você continue a trabalhar com os dados armazenados em cache. O designer de modelo também notificará você sobre todos os recursos em seu modelo incompatíveis com o modo DirectQuery. A lista a seguir resume os principais requisitos a serem considerados:

• Fontes de dados: Os modelos do DirectQuery só podem usar dados de uma única fonte de dados do SQL Server. Quando o modo DirectQuery tiver sido ativado para um modelo, você não poderá usar nenhum outro tipo de dados no designer de modelo, incluindo tabelas adicionadas por operações de copiar colagem. Todas as outras opções de importação estão desabilitadas. Todas as tabelas incluídas em uma consulta devem fazer parte da fonte de dados do SQL Server. Consulte fontes de dados para modelos DirectQuerypara obter mais informações.

• Suporte para colunas calculadas: Não há suporte para colunas calculadas para modelos DirectQuery. No entanto, você pode criar medidas e KPIs, que operam em conjuntos de dados. Consulte a seção sobre validação para obter mais informações.

• Uso limitado de funções DAX: Algumas funções DAX não podem ser usadas no modo DirectQuery, portanto, você deve substituí-las por outras funções ou criar os valores usando colunas derivadas na fonte de dados. O designer de modelo fornece validação durante o tempo de design para quaisquer erros que ocorrem quando você cria fórmulas que são incompatíveis com o modo DirectQuery. Confira as seções a seguir para obter mais informações: Validação.

• Compatibilidade de fórmulas: Em determinados casos conhecidos, a mesma fórmula pode retornar resultados diferentes em um modelo em cache ou híbrido em comparação com um modelo DirectQuery que usa apenas o armazenamento de dados relacional. Essas diferenças são uma consequência das diferenças semânticas entre o mecanismo de análise na memória xVelocity (VertiPaq) e o SQL Server. Para obter mais informações sobre essas diferenças, consulte esta seção: Compatibilidade de fórmulas.

• Segurança: Você pode usar métodos diferentes para proteger modelos dependendo de como eles são implantados. Os dados armazenados em cache para modelos de tabela são protegidos usando o modelo de segurança da instância do Analysis Services. Os modelos do DirectQuery podem ser protegidos usando funções, mas você também pode usar a segurança definida no armazenamento de dados relacional. O modelo pode ser configurado para que os usuários que abrem um relatório baseado em um modelo exclusivamente DirectQuery possam ver apenas os dados que são permitidos para eles sob suas permissões no SQL Server. Confira esta seção para obter mais informações: Segurança.

• Restrições de cliente: Quando um modelo está no modo DirectQuery, ele só pode ser consultado usando DAX. Você não pode usar o MDX para criar consultas. Isso significa que você não pode usar o Cliente Dinâmico do Excel, pois o Excel usa o MDX.

  No entanto, você pode criar consultas em um modelo DirectQuery no SQL Server Management Studio se usar uma consulta de tabela DAX como parte de uma instrução Execute XMLA, para obter mais informações, consulte [Referência de sintaxe de consulta DAX](/dax/dax-syntax-reference

Quando você tiver resolvido todos os problemas de design e testado seu modelo, estará pronto para implantação. Neste ponto, você pode definir o método preferencial para responder consultas ao modelo. Deseja que os usuários tenham acesso ao cache ou sempre usem apenas a fonte de dados relacional?

Se você implantar o modelo em um modo híbrido, o cache ainda estará disponível e poderá ser usado para consultas. Um modo híbrido fornece várias opções:

• Quando o cache e a fonte de dados relacional estão disponíveis, você pode definir o método de conexão preferencial, mas, em última análise, o cliente controla qual origem é usada, usando a propriedade de cadeia de conexão DirectQueryMode.

• Você também pode configurar partições no cache de forma que a partição primária usada para o modo DirectQuery nunca seja processada e sempre deve referenciar a fonte relacional. Há muitas maneiras de usar partições para otimizar o design do modelo e a experiência de relatório. Para obter mais informações, consulte Partições e Modo DirectQuery (SSAS Tabular).

• Depois que o modelo for implantado, você poderá alterar o método de conexão preferencial. Por exemplo, você pode usar um modo híbrido para teste e alternar o modelo somente para o modo DirectQuery depois de testar minuciosamente os relatórios ou consultas que usam o modelo. Para obter mais informações, consulte Definir ou alterar o método de conexão preferencial para DirectQuery.

Fontes de dados para modelos DirectQuery

Assim que você alterar o ambiente de design para habilitar o modo DirectQuery, as fontes de dados do banco de dados do workspace serão validadas para garantir que elas venham de uma única fonte de dados do SQL Server. Dados de outras fontes, incluindo dados colados em cópia, não são permitidos em modelos DirectQuery.

Se você pretende usar o modelo no modo DirectQuery, deve garantir que todos os dados necessários para relatórios sejam armazenados no banco de dados do SQL Server especificado. Se os dados necessários para modelagem não estiverem disponíveis nessa fonte, considere o uso do Integration Services ou de outras ferramentas de data warehousing para importar os dados para um banco de dados do SQL Server que serve como a fonte de dados do DirectQuery.

Restrições de validação e design para o modo DirectQuery

Ao criar um modelo para uso no modo DirectQuery, inicialmente você deve carregar parte dos dados no cache. Se os dados que você eventualmente usarão forem muito grandes para caber na memória, você poderá usar a opção Visualizar &Filtrar no assistente de Importação de Tabela para selecionar um subconjunto de dados ou gravar um script SQL para obter os dados desejados.

Para exibir e resolver erros de validação, abra a Lista de Erros nas Ferramentas de Dados do SQL Server. Erros críticos que impedem o uso do modo DirectQuery são exibidos na guia Erros. Você deve corrigir esses erros antes de alterar para o modo DirectQuery. Os erros de validação que são mais difíceis de resolver normalmente estão relacionados a fórmulas que não têm suporte no modo DirectQuery. Consulte a seção, Compatibilidade de Fórmulas, para obter uma visão geral dos erros relacionados a fórmulas e colunas calculadas.

A lista a seguir descreve outras considerações a serem consideradas ao criar um modelo para acesso ao DirectQuery:

• Quando no modo somente DirectQuery , os resultados em um relatório podem variar dependendo do contexto de segurança do usuário que está exibindo os resultados. Você deve testar modelos com credenciais diferentes para garantir que os usuários obtenham os resultados esperados.

• Se você configurar um modelo para operar no modo híbrido, o que permite o uso do cache ou dos dados do SQL Server, você deverá estar ciente da possibilidade de que os clientes que se conectam a cada fonte possam ver resultados diferentes, dependendo do modo especificado na cadeia de conexão. Se você precisar garantir que os usuários do relatório vejam apenas os dados do SQL Server, desmarque o cache ou altere o modelo para DirectQueryOnly.

Compatibilidade de fórmulas para modelos DirectQuery

Alguns modelos podem conter fórmulas que não têm suporte no modo DirectQuery e o modelo deve ser reprojetado para evitar erros de validação. As restrições às fórmulas com suporte no modo DirectQuery incluem o seguinte:

• Não há suporte para colunas calculadas em nenhum modelo de tabela que tenha o modo DirectQuery habilitado, nem mesmo modelos híbridos. Se você precisar de colunas calculadas para um modelo, considere convertê-las em colunas derivadas usando Transact-SQL em sua definição de importação.

• Os modelos DirectQuery suportam fórmulas DAX para medidas, que são convertidas em operações baseadas em conjuntos no armazenamento de dados relacional. Todas as medidas criadas usando medidas implícitas têm suporte.

• Nem todas as funções têm suporte. Como o Analysis Services converte todas as fórmulas DAX e definições de medida em instruções SQL ao consultar um modelo DirectQuery, qualquer fórmula que contenha elementos que não possam ser convertidos em Transact-SQL disparará erros de validação no modelo. Por exemplo, não há suporte para funções de inteligência de tempo. Até mesmo as funções com suporte podem se comportar de forma diferente, como funções estatísticas. Para obter uma lista completa de problemas de compatibilidade, consulte Compatibilidade de fórmulas no modo DirectQuery.

• Algumas fórmulas no modelo podem ser validadas quando você alterna o modelo para o modo DirectQuery, mas retornam resultados diferentes quando executadas no cache versus no armazenamento de dados relacional. Isso ocorre porque os cálculos em relação ao cache usam a semântica do mecanismo de análise na memória xVelocity (VertiPaq), que contém muitos recursos destinados a emular o comportamento do Excel, enquanto as consultas em relação aos dados armazenados no armazenamento de dados relacionais usam necessariamente a semântica do SQL Server. Para obter uma lista de funções DAX que podem retornar resultados diferentes quando o modelo é implantado em tempo real, consulte Compatibilidade de fórmulas no modo DirectQuery.

Conectando-se a modelos DirectQuery

Os clientes que usam o MDX como a linguagem de consulta não podem se conectar a modelos que usam o modo DirectQuery. Por exemplo, se você tentar criar uma consulta MDX em um modelo DirectQuery, receberá um erro indicando que o cubo não pode ser encontrado ou não foi processado. Você pode criar consultas em modelos DirectQuery usando o Power View, fórmulas DAX ou consultas XMLA. Para obter mais informações sobre como você pode executar consultas ad hoc em modelos tabulares, consulte Tabular Model Data Access.

Se você estiver usando um modelo híbrido, poderá especificar se os usuários se conectam ao cache ou usam dados do DirectQuery especificando a propriedade de cadeia de conexão, DirectQueryMode.

Segurança no modo DirectQuery

Durante a criação do modelo, você especifica as permissões usadas para recuperar os dados de origem. Geralmente, essas serão suas próprias credenciais ou uma conta usada para desenvolvimento. No entanto, quando você alterna o modelo para usar o modo DirectQuery, o contexto de segurança é mais complexo:

• Considere se os usuários têm o nível necessário de acesso aos dados no armazenamento de dados relacional.

• Os usuários que exibem o mesmo modelo ou relatório podem ver dados diferentes, dependendo do contexto de segurança do usuário.

• Se o cache do modelo tiver sido preservado, o cache será protegido usando o modelo de segurança (funções) do Analysis Services. O cache pode conter dados que o designer de modelo tem o privilégio de ver, mas o usuário não. Os designers de modelo e de relatório devem limpar o cache ou proteger esses dados controlando o acesso por meio de funções.

• Um modelo que responde a consultas do cache não pode representar o usuário atual ao se conectar à fonte de dados. Se você quiser representar o usuário atual ao se conectar à fonte de dados, deverá usar o modo DirectQuery.

• Se o modelo de relatório exigir segurança, você terá duas opções: você pode usar funções do Analysis Services ou definir permissões de nível de linha na fonte de dados. A segurança na fonte de dados relacional é usada para controlar o acesso a tabelas e não há suporte para segurança em nível de coluna. Portanto, se os usuários em uma região não tiverem permissão para exibir números de vendas de regiões diferentes, um relatório que inclui uma medida com base na tabela Vendas retornará espaços em branco ou um erro.

A propriedade de configurações de personificação especifica as credenciais usadas quando você está se conectando a um modelo usando DirectQuery, seja para um modelo somente DirectQuery ou para um modelo híbrido que responde a consultas por meio do DirectQuery. A propriedade tem os seguintes valores:

Padrão
Usa as credenciais especificadas no assistente de importação para se conectar à fonte de dados. Pode ser um usuário específico do Windows ou a conta de serviço.

ImpersonateCurrentUser
Usa as credenciais do usuário atual para se conectar à fonte de dados.

Para obter informações sobre como definir essas propriedades, consulte Cenários de Implantação do DirectQuery (SSAS Tabular).

Propriedades do DirectQuery

A tabela a seguir lista as propriedades que você pode definir no SQL Server Data Tools e no SQL Server Management Studio, para habilitar o DirectQuery e controlar a fonte de dados usada para consultas no modelo.

Além disso, se o modelo incluir partições, você deverá escolher uma partição para usar como fonte para consultas no modo DirectQuery. Para obter mais informações, consulte Partições e Modo DirectQuery (SSAS Tabular).

Tópicos e tarefas relacionados

Consulte Também

Partições (SSAS Tabular)
Projetos de Modelos Tabulares (SSAS Tabular)
Analisar no Excel (SSAS Tabular)