Autoexiste

Aplica-se a: SQL Server Analysis Services Azure Analysis Services Fabric/Power BI Premium

O conceito de autoexistência limita o espaço do cubo às células que realmente existem no cubo, em contraposição àquelas que poderiam existir como resultado da criação de todas as combinações possíveis de membros da hierarquia de atributos a partir da mesma hierarquia. Isto deve-se ao facto de membros de uma hierarquia de atributos não poderem existir com membros de outra hierarquia de atributos na mesma dimensão. Quando duas ou mais hierarquias de atributos da mesma dimensão são usadas numa instrução SELECT, o Analysis Services avalia as expressões dos atributos para garantir que os membros desses atributos estão devidamente confinados para cumprir os critérios de todos os outros atributos.

Por exemplo, suponha que está a trabalhar com atributos da dimensão Geografia. Se tiveres uma expressão que devolve todos os membros do atributo Cidade e outra expressão que confina os membros do atributo País a todos os países/regiões da Europa, isso resultará em que os membros da Cidade fiquem confinados apenas às cidades que pertencem a países/regiões na Europa. Isto deve-se à característica autoexistente dos Serviços de Análise. Autoexiste aplica-se apenas a atributos da mesma dimensão porque tenta impedir que os registos de dimensão excluídos numa expressão de atributo sejam incluídos pelas outras expressões de atributo. Os autoexists também podem ser entendidos como a interseção resultante das diferentes expressões de atributos ao longo das linhas de dimensão.

Existência celular

As seguintes células existem sempre:

• O membro (Todo), de todas as hierarquias, quando combinado com membros de outras hierarquias na mesma dimensão.

• Membros calculados quando cruzados com os seus irmãos não calculados, ou com os pais ou descendentes dos seus irmãos não calculados.

Fornecimento de células inexistentes

Uma célula inexistente é uma célula fornecida pelo sistema como resposta a uma consulta ou cálculo que solicita uma célula que não existe no cubo. Por exemplo, se tiver um cubo que tem uma hierarquia de atributos Cidade e uma hierarquia de atributos País que pertencem à dimensão Geografia, e uma medida de Valor de Vendas na Internet, o espaço deste cubo inclui apenas os membros que existem entre si. Por exemplo, se a hierarquia de atributos da Cidade incluir as cidades de Nova Iorque, Londres, Paris, Tóquio e Melbourne; e a hierarquia de atributos por país inclui os países/regiões Estados Unidos, Reino Unido, França, Japão e Austrália; então o espaço do cubo não inclui o espaço (célula) na interseção de Paris e dos Estados Unidos.

Ao consultar células que não existem, as células inexistentes retornam nulos; ou seja, não podem conter cálculos e não se pode definir um cálculo que escreva neste espaço. Por exemplo, a seguinte afirmação inclui células que não existem.

SELECT [Customer].[Gender].[Gender].Members ON COLUMNS,  
{[Customer].[Customer].[Aaron A. Allen]  
   ,[Customer].[Customer].[Abigail Clark]} ON ROWS   
FROM [Adventure Works]  
WHERE Measures.[Internet Sales Amount]  

Quando executa a consulta anterior, a célula na interseção de Aaron A. Allen e Female mostra um null. De forma semelhante, a célula na interseção de Abigail Clark e Male apresenta um nulo. Estas células não existem e não podem conter um valor, mas células que não existem podem aparecer no resultado devolvido por uma consulta.

Quando se usa a função Crossjoin (MDX) para devolver o produto cruzado dos membros da hierarquia de atributos de hierarquias de atributos na mesma dimensão, o auto-existe limita essas tuplas que são devolvidas ao conjunto de tuplas que realmente existem, em vez de devolver um produto cartesiano completo. Por exemplo, execute e depois examine os resultados da execução da consulta seguinte.

SELECT CROSSJOIN  
   (  
      {[Customer].[Country].[United States]},  
         [Customer].[State-Province].Members  
  ) ON 0   
FROM [Adventure Works]  
WHERE Measures.[Internet Sales Amount]  

A consulta anterior apenas retorna células para membros de cada hierarquia de atributos na consulta que existem entre si. A consulta anterior também pode ser escrita usando a nova variante * da função * (Crossjoin) (MDX ).

SELECT   
   [Customer].[Country].[United States] *   
      [Customer].[State-Province].Members  
ON 0   
FROM [Adventure Works]  
WHERE Measures.[Internet Sales Amount]  

A consulta anterior também podia ser escrita da seguinte forma:

SELECT [Customer].[State-Province].Members  
ON 0   
FROM [Adventure Works]  
WHERE (Measures.[Internet Sales Amount],  
   [Customer].[Country].[United States])  

Os valores das células devolvidos serão idênticos, embora os metadados no conjunto de resultados sejam diferentes. Por exemplo, com a consulta anterior, a hierarquia de País foi movida para o eixo do slicer (na cláusula WHERE) e, por isso, não aparece explicitamente no conjunto de resultados.

Cada uma destas três consultas anteriores demonstra o efeito do comportamento auto-existente no SQL Server Analysis Services.

Deep and Shallow Autoexists

Autoexists podem ser aplicados às expressões como Deep ou Shallow. Deep Autoexists significa que todas as expressões serão avaliadas para alcançar o espaço mais profundo possível, após a aplicação das expressões do slicer e das expressões de subseleção no eixo, entre outras. Shallow Autoexists significa que expressões externas são avaliadas antes da expressão atual e esses resultados são passados para a expressão atual. A definição padrão é deep autoexists.

O seguinte cenário e amostras ajudarão a ilustrar os diferentes tipos de Autoexistss. Nos exemplos seguintes, serão criados dois conjuntos: um como expressão calculada e outro como expressão constante.

//Obtain the Top 10 best reseller selling products by Name

with member [Measures].[PCT Discount] AS '[Measures].[Discount Amount]/[Measures].[Reseller Sales Amount]', FORMAT_STRING = 'Percent'

set Top10SellingProducts as 'topcount([Product].[Model Name].children, 10, [Measures].[Reseller Sales Amount])'

set Preferred10Products as '

{[Product].[Model Name].&[Mountain-200],

[Product].[Model Name].&[Road-250],

[Product].[Model Name].&[Mountain-100],

[Product].[Model Name].&[Road-650],

[Product].[Model Name].&[Touring-1000],

[Product].[Model Name].&[Road-550-W],

[Product].[Model Name].&[Road-350-W],

[Product].[Model Name].&[HL Mountain Frame],

[Product].[Model Name].&[Road-150],

[Product].[Model Name].&[Touring-3000]

}'

select {[Measures].[Reseller Sales Amount], [Measures].[Discount Amount], [Measures].[PCT Discount]} on 0,

Top10SellingProducts on 1

from [Adventure Works]

O conjunto de resultados obtido é:

O conjunto obtido de produtos parece ser o mesmo do Preferred10Products; Portanto, verificando o conjunto Preferred10Products:

with member [Measures].[PCT Discount] AS '[Measures].[Discount Amount]/[Measures].[Reseller Sales Amount]', FORMAT_STRING = 'Percent'

set Top10SellingProducts as 'topcount([Product].[Model Name].children, 10, [Measures].[Reseller Sales Amount])'

set Preferred10Products as '

{[Product].[Model Name].&[Mountain-200],

[Product].[Model Name].&[Road-250],

[Product].[Model Name].&[Mountain-100],

[Product].[Model Name].&[Road-650],

[Product].[Model Name].&[Touring-1000],

[Product].[Model Name].&[Road-550-W],

[Product].[Model Name].&[Road-350-W],

[Product].[Model Name].&[HL Mountain Frame],

[Product].[Model Name].&[Road-150],

[Product].[Model Name].&[Touring-3000]

}'

select {[Measures].[Reseller Sales Amount], [Measures].[Discount Amount], [Measures].[PCT Discount]} on 0,

Preferred10Products on 1

from [Adventure Works]

De acordo com os resultados seguintes, ambos os conjuntos (Top10VendingProducts, Preferred10Products) são iguais

O exemplo seguinte irá ilustrar o conceito de deep Autoexists. No exemplo, estamos a filtrar o Top10SellingProducts pelo atributo [Linha de Produtos] para aqueles no grupo [Montanha]. Note que ambos os atributos (fatiador e eixo) pertencem à mesma dimensão, [Produto].

with member [Measures].[PCT Discount] AS '[Measures].[Discount Amount]/[Measures].[Reseller Sales Amount]', FORMAT_STRING = 'Percent'

set Top10SellingProducts as 'topcount([Product].[Model Name].children, 10, [Measures].[Reseller Sales Amount])'

// Preferred10Products set removed for clarity

select {[Measures].[Reseller Sales Amount], [Measures].[Discount Amount], [Measures].[PCT Discount]} on 0,

Top10SellingProducts on 1

from [Adventure Works]

where [Product].[Product Line].[Mountain]

Produz o seguinte conjunto de resultados:

No conjunto de resultados acima temos sete recém-chegados à lista dos Top10VendingProducts e Mountain-200, Mountain-100 e HL Mountain Frame subiram para o topo da lista. No conjunto de resultados anterior, esses três valores estavam intercalados.

Isto chama-se Deep Autoexists, porque o conjunto Top10SellingProducts é avaliado para cumprir as condições de segmentação da consulta. Deep Autoexists significa que todas as expressões serão avaliadas para atingir o espaço mais profundo possível após aplicar as expressões do slicer, as expressões de subseleção no eixo, e assim sucessivamente.

No entanto, pode ser necessário fazer a análise sobre o Top10VendingProducts como equivalente ao Preferred10Products, como no seguinte exemplo:

with member [Measures].[PCT Discount] AS '[Measures].[Discount Amount]/[Measures].[Reseller Sales Amount]', FORMAT_STRING = 'Percent'

set Top10SellingProducts as 'topcount([Product].[Model Name].children, 10, [Measures].[Reseller Sales Amount])'

set Preferred10Products as '

{[Product].[Model Name].&[Mountain-200],

[Product].[Model Name].&[Road-250],

[Product].[Model Name].&[Mountain-100],

[Product].[Model Name].&[Road-650],

[Product].[Model Name].&[Touring-1000],

[Product].[Model Name].&[Road-550-W],

[Product].[Model Name].&[Road-350-W],

[Product].[Model Name].&[HL Mountain Frame],

[Product].[Model Name].&[Road-150],

[Product].[Model Name].&[Touring-3000]

}'

select {[Measures].[Reseller Sales Amount], [Measures].[Discount Amount], [Measures].[PCT Discount]} on 0,

Preferred10Products on 1

from [Adventure Works]

where [Product].[Product Line].[Mountain]

Produz o seguinte conjunto de resultados:

Nos resultados acima, a segmentação resulta em um conjunto que contém apenas os produtos da Preferred10Products que pertencem ao grupo [Mountain] em [Produto].[Linha de Produtos], como era esperado, pois a Preferred10Products é uma expressão constante.

Este conjunto de resultados também é conhecido como Shallow Autoexists. Isto acontece porque a expressão é avaliada antes da cláusula de fatiamento. No exemplo anterior, a expressão era uma expressão constante para fins ilustrativos, de modo a introduzir o conceito.

O comportamento do Autoexists pode ser modificado ao nível da sessão usando a propriedade da cadeia de ligação Autoexists . O exemplo seguinte começa por abrir uma nova sessão e adicionar a propriedade Autoexists=3 à cadeia de ligação. Tens de abrir uma nova ligação para fazer o exemplo. Uma vez estabelecida a ligação com a configuração Autoexist, ela permanecerá ativa até essa ligação terminar.

with member [Measures].[PCT Discount] AS '[Measures].[Discount Amount]/[Measures].[Reseller Sales Amount]', FORMAT_STRING = 'Percent'

set Top10SellingProducts as 'topcount([Product].[Model Name].children, 10, [Measures].[Reseller Sales Amount])'

//Preferred10Products set removed for clarity

select {[Measures].[Reseller Sales Amount], [Measures].[Discount Amount], [Measures].[PCT Discount]} on 0,

Top10SellingProducts on 1

from [Adventure Works]

where [Product].[Product Line].[Mountain]

O conjunto de resultados seguinte mostra agora o comportamento superficial do Autoexists.

O comportamento do Autoexists pode ser modificado usando o parâmetro AUTOEXISTS=[1|2|3] na cadeia de ligação; ver Propriedades XMLA Suportadas (XMLA) e ConnectionString para a utilização de parâmetros.

Ver também

Conceitos-chave em MDX (Serviços de Análise)
Espaço Cúbico
Tuplas
Trabalhar com Membros, Tuplas e Conjuntos (MDX)
Totais Visuais e Totais Não Visuais
Referência de Linguagem MDX (MDX)
Referência de Expressões Multidimensionais (MDX)