DESMISTIFICANDO O SELECT no SQL SERVER: O FROM – Parte 1

 

E após mais um longo tempo sem postar nada,  vou dando continuidade a nossa série do processamento lógico de um SELECT.

Hoje vamos falar sobre o FROM. No último post eu tentei uma breve explicação sobre o que é o processamento lógico, e a comparação dele com o processamento físico. O objetivo desta série é saber como o SQL Server “entende” uma query e como ele vai manipular as informações para produzir o resultado codificado pelo seu comando de SELECT. De posse desta informação, você pode começar a manipular suas queries e entender porque determinada consulta não está trazendo um resultado que você espera, ou rapidamente poder montar uma solução para um determinado problema.

Assim, vamos falar do processamento lógico como se fosse realmente o que SQL Server faz, e por mais que seja absurdo, não pense em performance agora. Concentre-se em entender qual a semântica por trás de um simples SELECT.

Para recapitular, um simples SELECT: (Utilize os scripts deste post para criar as tabelas)

SELECT
    C.clienteID
    ,C.cidade
FROM
    dbo.Cliente C

Se eu estivesse aprendendo banco de dados agora, e te perguntasse o que esse código faz, provavelmente você diria: “Retorna o ID e cidade de todos os registros da tabela ‘Cliente’ ”. E está certo! Você sabe o que vai ser retornado. Agora se eu te perguntasse, como o SQL Server está fazendo para acessar estes dados você poderia me responder: “Ele está lendo a tabela inteira diretamente”, ou “Ele está usando o índice da tabela”. Não importa como o SQL Server está fazendo, mas você sabe que o que ele está tentando fazer é ler a tabela inteira, e retornar 2 colunas. Independente de como ele vai fazer isso, porque é isto que a query está pedindo.

Agora, imagine que você quisesse saber o seguinte:

Trazer todas as cidades da tabela cliente, junto com o total de pedidos feitos por clientes cujo ID é < 3.

Em uma primeira tentativa, a query abaixo poderia ser uma solução:

SELECT
    C.cidade
    ,COUNT(P.PedidoID) as TotalPedidos
FROM
    dbo.Cliente C
    LEFT JOIN
    dbo.Pedido P
        ON P.ClienteID = C.ClienteID
WHERE
    P.ClienteID < 3
GROUP BY
    C.cidade
cidade               TotalPedidos
-------------------- ------------
Brasilia             5

 

Percebam que a cidade “Goiânia” não aparece no resultado, e a nossa regra de negócio exige que ela apareça. Mas porque ? Onde está o problema ? A coisa fica mais interessante quando você apenas muda um filtro de lugar …

SELECT
    C.cidade
    ,COUNT(P.PedidoID) as TotalPedidos
FROM
    dbo.Cliente C
    LEFT JOIN
    dbo.Pedido P
        ON P.ClienteID = C.ClienteID    
        AND P.ClienteID < 3
GROUP BY
    C.cidade
cidade               TotalPedidos
-------------------- ------------
Brasilia             5
Goiania              0

Agora sim o resultado retornado foi o que queríamos. Porque apenas ao mudarmos o filtro de lugar o resultado produzido foi diferente ? Repostas a estas perguntas serão respondidas quando você entender o processamento lógico.

Neste ponto, você não deve se preocupar em COMO o SQL Server irá fazer determinar operação, mas sim O QUE ele entenderá que deve ser feito. Isso é o processamento lógico!!!!

Conforme vistos no primeiro post, vamos falar agora fase por fase, explicando suas entradas e saídas. Hoje o nosso foco é a primeira fase, a parte do FROM.

 

Tabelas Virtuais

No processamento lógico cada fase produz um resultado, e esse resultado é passado para a próxima fase. Para facilitar, imagine que cada fase produz uma tabela virtual. Eu não vou chamar de “temporária” para você não confundir com as tabelas temporárias que existem na linguagem. Essas “tabelas virtuais” são passadas de fase por fase, e a próxima fase só enxerga a tabela que foi passada a ela, inclusive somente as suas colunas (tem algumas exceções, mas esqueça por agora). Por questões de nomenclatura, eu vou atribuir nomes a essas tabelas para ir facilitando nossa compreensão, mas lembre-se que essas tabelas só são “enxergadas” pelo SQL Server.

A cláusula FROM

A cláusula FROM é a primeira a ser processada. Lá é onde ficam as nossas tabelas e as operações que fazemos com elas.Você pode fazer JOINS, APPLYs e PIVOTs com as tabelas. A fase de processamento do FROM é divido em sub-fases. Cada sub-fase também produz uma tabela virtual que é passada para a próxima sub-fase e por ai em diante. No final, a tabela virtual resultante é retornada do FROM e passada para a próxima fase,que é o WHERE (que veremos em outro post).

A sintaxe do FROM é a seguinte:

FROM
   input OPERAÇÃO input OPERAÇÃO input OPERAÇÃO input [etc…]

Percebam que eu usei o nome “input”. Vou chamar assim porquê esse input pode ser qualquer coisa que retorne uma estrutura de tabela:

  • Uma tabela
  • Uma view
  • Uma tabela derivada
  • Uma CTE
  • Uma Table-Valued Function

NOTA: Se você não conhece essas coisas ainda, não se preocupe. Se concentre que um input é algo que representa uma estrutura de tabela.

A OPERACAO é o que será feito entre os dois inputs. Ela pode ser:

  • JOINS (CROSS,INNER, LEFT, RIGHT,FULL)
  • APPLY (CROSS, OUTER)
  • PIVOT (PIVOT, UNPIVOT)

        As sub-fases da cláusula FROM variam de acordo com cada uma dessas oparações. A sub-fases para um “INNER JOIN” são diferentes para um CROSS JOIN que são diferentes para um “CROSS APPLY” ou um “UNPIVOT”.
    Para simplificar, vamos inicialmente falar somente sobre as sub-fases para todos os tipos de JOINS, pois estes são mais fáceis de se compreender e são usados mais frequentemente.
    Em outro post entraremos em mais detalhes sobre as sub-fases dos outros operadores.

Operadores de Tabela

As operações realizada com as tabelas são feitas através de operadores de tabela. Por exemplo, um “INNER JOIN”. Os operadores de tabela seguem algumas regras já conhecida por nós lá na matemática…Por exemplo, você tem a operação de SOMA. O que é preciso para fazer uma soma acontecer? Você precisa de 2 números para fazer a SOMA. Neste caso, os 2 números chamamos de “operando” e a “soma” é o operador, o qual é representado pelo sinal “+”.

Aqui é a mesma coisa. Por exemplo, para fazer um CROSS JOIN, você precisa de dois inputs. O operador é representado pelo seu próprio nome. Os dois inputs são os nossos operandos. Em versões futuras do SQL Server, podem ser lançados operadores que requeiram somente um input, ou três, ou nenhum …

Ainda, na matemática, se você tem a expressão “1 + 1 + 2”, Você pode fazer “1 + 1”, e do resultado, somar com 2. Ou seja o operador só trabalha com 2 operandos por vez.
Igualmente com os operadores de tabela, se existir mais de 1 operando, é feito a operação entre os 2 primeiros operandos, e o resultado é usado como input para o próximo operador, juntamente com o o outro input, e por ai vai até acabar:

input_A OPERADOR input_B OPERADOR input_C OPERADOR input_D:

    input_A OPERADOR input_B  = input_AB

    input_AB OPERADOR input_C = input_ABC

    input_ABC OPERADOR input_D = input_ABCD

Como acabou as operações, o resultado seria o “input_ABCD”.

As tabelas virtuais retornadas por cada sub-fase serão passadas para a próxima fase, ou serão usadas como inputs para próximas operações, se houver, até acabar todas as cláusulas no FROM. No final, a tabela virtual resultante é passada para a fase de processamento do WHERE. Lembre-se que podemos misturar operadores de diferentes operações: 

A JOIN B APPLY C PIVOT D.

Simplesmente, o resultado do JOIN de A com B é usado para fazer o APPLY com C, e este último resultado é usado para fazer o PIVOT com D.

Mas, de novo, ressalto que iremos apenas falar de JOINs.

AS SUB-FASES

1ª SUB-FASE: Produto Cartesiano

Nesta fase, é feito um produto Cartesiano entre os inputs. Para quem não lembra o produto cartesiano vem lá da teoria de conjuntos. Ele é uma operação onde todos os elementos de um conjunto são combinados com todos os elementos de um outro conjunto. Isto gera um conjunto com TODAS AS COMBINAÇÕES POSSÍVEIS.

Trazendo para o nosso mundo, nesta sub-fase, será gerado uma tabela virtual contendo todas as combinações possíveis de linhas entre os dois inputs.
Se o input da esquerda contém 5 linhas, e o input da direita contém 2 linhas, a tabela virtual gerada aqui vai conter 5 x 2 = 10 linhas. Cada linha da esquerda será associada com cada linha da direita.

E é exatamente isso o que um CROSS JOIN faz. Ele serve para combinar TODAS AS LINHAS dos dois inputs. Quando a operação que está sendo executada é um CROSS JOIN, esta é a única sub-fase que executada para o operador que está sendo processado.

Aqui será retornado a tabela virtual “TVF1”.

JOINS RECAP:

Joins são operações que usamos para combinar linhas de dois inputs. O resultado de uma operação de JOIN é uma tabela que contém as colunas dos dois inputs. Dependendo do JOIN, você pode especificar uma condição, isto é, uma lógica, para determinar as combinações de linhas que vão ser geradas. Podemos combinar linhas usando APPLY. Existe também operadores que podemos combinar dois inputs. Eles diferem um pouco dos JOINS porque combinam colunas, isto é, juntam colunas de diferentes inputs. São: UNION, INTERSECT E EXCEPT. Mas isso é assunto pra outro post, outra série!

 

Bom, por hoje é só. No próximo post irei falar sobre as outras fases.  Até lá, vá revendo os tipos de JOINS. Para este momento entender e vê exemplos de JOINs irão facilitar ainda mais sua compreensão.

E como sempre, desculpem os erros de português. A cada post estou tentando melhorar e ser mais claro. Qualquer dúvida, sugestão, crítica, ou elogios, utilize os comentários! Seu feedback sempre é bem vindo!

[]’s
Rodrigo Ribeiro Gomes
MCTS | MCITP

Advertisements