• Quantos pedidos foram realizados?

• Qual foi o faturamento?

• Qual categoria vendeu mais?

• Qual foi o ticket médio?

Mas existe um problema que aparece rapidamente quando começamos a trabalhar com bancos de dados reais: as informações geralmente estão distribuídas em várias tabelas.

Um pedido pode estar em uma tabela, enquanto as informações sobre o cliente estão em outra. Os detalhes dos produtos podem estar em uma terceira tabela.

Como combinamos tudo isso?

É para isso que servem os JOINs.

Por que os dados ficam em tabelas diferentes?

Antes de entender os JOINs, precisamos entender por que não colocamos tudo em uma única tabela.

Imagine uma loja virtual. Poderíamos ter uma tabela customers:

E uma tabela orders:

Observe que a tabela orders não precisa repetir o nome e a cidade do cliente em cada pedido.

Em vez disso, ela possui a coluna customer_id, que permite identificar quem fez cada pedido.

Essa coluna funciona como uma ligação entre as duas tabelas.

O que é um JOIN?

Um JOIN permite combinar registros de duas ou mais tabelas utilizando uma condição de relacionamento entre elas.

No nosso exemplo, podemos relacionar:

customers.id
      ↓
orders.customer_id

Ou seja, o id do cliente em customers corresponde ao customer_id armazenado em orders.

Podemos utilizar essa relação para descobrir, por exemplo, o nome do cliente associado a cada pedido.

SELECT
    orders.id,
    customers.name,
    orders.order_value
FROM orders
JOIN customers
    ON orders.customer_id = customers.id;

O resultado poderia ser:

Agora temos informações que originalmente estavam em duas tabelas diferentes.

Entendendo o ON

A parte mais importante de um JOIN é a condição definida depois de ON.

No exemplo:

ON orders.customer_id = customers.id

Estamos dizendo ao banco:

"Relacione um pedido ao cliente cujo id corresponde ao customer_id desse pedido."

Essa condição determina como as tabelas devem ser relacionadas.

Se escolhermos uma condição errada, o resultado também estará errado.

Por isso, entender as relações entre as tabelas é uma das partes mais importantes de trabalhar com SQL.

INNER JOIN

O tipo de JOIN mais comum é o INNER JOIN.

Ele retorna apenas os registros que possuem correspondência nas duas tabelas.

Por exemplo:

SELECT
    orders.id,
    customers.name,
    orders.order_value
FROM orders
INNER JOIN customers
    ON orders.customer_id = customers.id;

Se existir um pedido cujo customer_id não corresponda a nenhum cliente na tabela customers, esse pedido não aparecerá no resultado.

Podemos visualizar a ideia assim:

customers        orders
    ●──────────────●
       correspondência

O INNER JOIN mantém apenas aquilo que existe nos dois lados.

Na prática, quando escrevemos simplesmente:

JOIN customers

em muitos bancos de dados estamos utilizando INNER JOIN.

LEFT JOIN

Agora imagine outra situação.

Queremos listar todos os clientes, inclusive aqueles que nunca fizeram um pedido.

Nesse caso, um INNER JOIN não seria suficiente.

Podemos utilizar um LEFT JOIN:

SELECT
    customers.name,
    orders.id AS order_id,
    orders.order_value
FROM customers
LEFT JOIN orders
    ON customers.id = orders.customer_id;

O LEFT JOIN mantém todos os registros da tabela que está à esquerda do JOIN.

Nesse caso, customers é a tabela da esquerda.

Se um cliente não tiver nenhum pedido, as colunas provenientes de orders aparecerão como NULL.

Por exemplo:

Maria continua aparecendo porque o objetivo era manter todos os clientes.

Essa diferença entre INNER JOIN e LEFT JOIN é extremamente importante.

INNER JOIN vs. LEFT JOIN

Podemos resumir assim:

INNER JOIN

"Quero somente os registros que possuem correspondência nas duas tabelas."

LEFT JOIN

"Quero todos os registros da tabela da esquerda, mesmo que não exista correspondência na tabela da direita."

Uma boa pergunta para fazer antes de escolher o JOIN é:

"Quero manter registros que não possuem correspondência?"

Se a resposta for não, INNER JOIN pode ser adequado.

Se a resposta for sim, provavelmente você precisará de um LEFT JOIN.

JOIN com três tabelas

Na prática, análises frequentemente precisam combinar mais de duas tabelas.

Imagine que nosso banco tenha:

• customers: clientes;

• orders: pedidos;

• products: produtos.

Podemos combinar essas tabelas em uma única consulta.

Por exemplo:

SELECT
    customers.name,
    orders.id AS order_id,
    products.name AS product_name,
    orders.order_value
FROM orders
INNER JOIN customers
    ON orders.customer_id = customers.id
INNER JOIN products
    ON orders.product_id = products.id;

Agora podemos consultar informações do cliente, do pedido e do produto simultaneamente.

A ideia continua sendo a mesma: cada JOIN adiciona uma nova relação.

O perigo da duplicação

Aqui chegamos a um dos problemas mais importantes para quem está começando com SQL.

Um JOIN pode aumentar a quantidade de linhas do resultado.

Isso não significa necessariamente que existe um erro.

Imagine que Ana tenha feito três pedidos.

Na tabela customers, Ana aparece uma vez:

Na tabela orders, ela aparece três vezes:

Ao fazer o JOIN, Ana aparecerá três vezes:

Isso acontece porque existe uma relação de um para muitos:

um cliente → vários pedidos.

O JOIN está funcionando corretamente.

O problema aparece quando não entendemos essa relação e fazemos uma agregação depois.

Um exemplo de erro em uma análise

Imagine que queremos calcular o faturamento por cliente.

Podemos fazer:

SELECT
    customers.name,
    SUM(orders.order_value) AS total_sales
FROM customers
INNER JOIN orders
    ON customers.id = orders.customer_id
GROUP BY customers.name;

Essa consulta faz sentido porque cada pedido aparece uma vez no resultado do JOIN.

Mas, se adicionarmos outra tabela que tenha várias linhas para cada pedido, podemos acabar multiplicando os registros.

Por isso, antes de fazer um JOIN, é importante entender:

• Qual é a granularidade de cada tabela?

• Qual coluna conecta as tabelas?

• A relação é um para um?

• Um para muitos?

• Muitos para muitos?

• Quantas linhas espero ter depois do JOIN?

Essas perguntas são fundamentais para evitar análises incorretas.

O que é uma chave?

Para entender melhor os JOINs, vale conhecer dois conceitos:

Chave primária é uma coluna — ou conjunto de colunas — utilizada para identificar unicamente um registro em uma tabela.

No nosso exemplo:

customers.id

pode ser a chave primária da tabela customers.

Já uma chave estrangeira é uma coluna que faz referência a uma chave de outra tabela.

No nosso caso:

orders.customer_id

faz referência a:

customers.id

Essa estrutura permite estabelecer relações entre as tabelas.

Não é necessário dominar modelagem de bancos de dados para começar a usar SQL, mas entender esse conceito ajuda muito na hora de construir JOINs.

Usando aliases

Quando começamos a combinar várias tabelas, as consultas podem ficar grandes.

Uma prática bastante útil é utilizar aliases para dar nomes mais curtos às tabelas.

Por exemplo:

SELECT
    c.name,
    o.id AS order_id,
    o.order_value
FROM orders AS o
INNER JOIN customers AS c
    ON o.customer_id = c.id;

Agora:

• o representa orders;

• c representa customers.

Isso deixa a consulta mais compacta e, em consultas com várias tabelas, pode melhorar bastante a legibilidade.

JOIN e análise de dados

Os JOINs são especialmente importantes porque permitem transformar dados armazenados de maneira separada em informações úteis para análise.

Imagine uma pergunta como:

"Quais clientes geraram mais receita?"

Precisamos de pelo menos duas informações:

• o cliente;

• o valor dos seus pedidos.

Essas informações estão em tabelas diferentes.

Podemos combiná-las e depois utilizar GROUP BY:

SELECT
    c.name,
    SUM(o.order_value) AS total_sales
FROM customers AS c
INNER JOIN orders AS o
    ON c.id = o.customer_id
GROUP BY c.name
ORDER BY total_sales DESC;

Aqui estamos combinando vários conceitos que já aprendemos:

• JOIN conecta clientes e pedidos;

• SUM calcula a receita;

• GROUP BY cria uma linha por cliente;

• ORDER BY organiza os clientes pelo faturamento.

É assim que SQL começa a se tornar realmente poderoso para análise de dados: combinando diferentes operações para responder perguntas de negócio.

O que aprendemos até aqui?

Neste artigo, vimos:

• por que os dados são armazenados em diferentes tabelas;

• o que é um JOIN;

• como utilizar ON para definir o relacionamento;

• a diferença entre INNER JOIN e LEFT JOIN;

• como combinar três ou mais tabelas;

• o conceito de chave primária e chave estrangeira;

• por que um JOIN pode aumentar a quantidade de registros;

• como evitar problemas de duplicação;

• como utilizar aliases para deixar consultas mais legíveis.

Se você está começando, não se preocupe em memorizar todos os tipos de JOIN agora.

O mais importante é entender a ideia central:

Um JOIN permite combinar informações relacionadas que estão armazenadas em tabelas diferentes.

A partir daqui, já temos os principais fundamentos para começar a escrever consultas realmente úteis para análise de dados.

No próximo artigo, vamos avançar para recursos que permitem transformar e organizar os dados dentro das próprias consultas, como CASE WHEN, NULL e outras ferramentas bastante úteis no dia a dia de um analista.

Isso já permite responder perguntas simples sobre uma tabela. Mas, em análise de dados, frequentemente precisamos ir além de consultar registros individuais.

Imagine uma tabela com 1 milhão de pedidos. Em vez de analisar cada pedido separadamente, talvez você queira responder perguntas como:

• Quantos pedidos foram realizados?

• Qual foi o faturamento total?

• Qual foi o valor médio dos pedidos?

• Quanto cada categoria vendeu?

• Quantos pedidos cada cliente realizou?

Para esse tipo de análise, precisamos conhecer as funções de agregação e o GROUP BY.

O que são funções de agregação?

Funções de agregação são funções que recebem vários registros e produzem um resultado resumido.

As principais que você deve conhecer no início são:

Vamos utilizar novamente nossa tabela orders, que poderia ter uma estrutura semelhante a esta:

COUNT: contando registros

Comecemos pelo COUNT.

Se quisermos saber quantos pedidos existem na tabela:

SELECT COUNT(*)
FROM orders;

O banco retorna um único número representando a quantidade de registros.

Essa é uma das consultas mais simples e também uma das mais úteis.

Podemos, por exemplo, utilizar COUNT para descobrir quantos pedidos foram realizados:

SELECT COUNT(*) AS total_orders
FROM orders;

O AS cria um alias, ou seja, um nome mais amigável para a coluna do resultado.

Em vez de termos uma coluna chamada simplesmente COUNT(*), teremos total_orders.

SUM: calculando totais

Agora imagine que queremos saber quanto foi vendido no total.

Podemos utilizar SUM:

SELECT SUM(order_value) AS total_sales
FROM orders;

Nesse caso, o SQL soma todos os valores da coluna order_value.

Essa operação é extremamente comum em análise de dados. Dependendo do contexto, podemos utilizar SUM para calcular:

• faturamento;

• quantidade de produtos vendidos;

• custos;

• descontos;

• margem;

• outras métricas acumuláveis.

AVG: calculando médias

Para calcular uma média, usamos AVG.

Por exemplo:

SELECT AVG(order_value) AS average_order_value
FROM orders;

Podemos utilizar essa métrica para descobrir o ticket médio, por exemplo.

A ideia é simples:

Se SUM nos ajuda a descobrir o total, AVG nos ajuda a entender o valor médio.

MIN e MAX

As funções MIN e MAX retornam, respectivamente, o menor e o maior valor.

SELECT
    MIN(order_value) AS smallest_order,
    MAX(order_value) AS largest_order
FROM orders;

Com uma única consulta, podemos descobrir o menor e o maior pedido da tabela.

Essas funções também podem ser utilizadas com datas, números e outros tipos de dados compatíveis.

O problema de olhar apenas para o total

Até aqui, conseguimos responder perguntas gerais.

Por exemplo:

"Quanto a loja vendeu?"

Mas imagine que a pergunta seja:

"Quanto a loja vendeu em cada categoria?"

Agora precisamos de uma forma de dividir os dados em grupos.

É exatamente isso que o GROUP BY faz.

O que é GROUP BY?

O GROUP BY permite agrupar registros que possuem determinado valor em comum.

Por exemplo:

SELECT
    category,
    SUM(order_value) AS total_sales
FROM orders
GROUP BY category;

Agora, em vez de obter um único total, teremos um total para cada categoria.

O resultado poderia ser:

Podemos interpretar a consulta da seguinte forma:

"Separe os pedidos por categoria e calcule o total de vendas de cada grupo."

Essa é uma das ideias mais importantes de SQL para análise de dados.

GROUP BY com COUNT

Podemos combinar GROUP BY com diferentes funções de agregação.

Por exemplo, para descobrir quantos pedidos existem em cada categoria:

SELECT
    category,
    COUNT(*) AS total_orders
FROM orders
GROUP BY category;

O resultado poderia ser:

Agora temos uma métrica de quantidade para cada grupo.

GROUP BY com AVG

Também podemos calcular a média por grupo.

SELECT
    category,
    AVG(order_value) AS average_order_value
FROM orders
GROUP BY category;

Assim, conseguimos descobrir o valor médio dos pedidos de cada categoria.

Essa mesma lógica pode ser aplicada a praticamente qualquer dimensão que faça sentido para a análise.

Por exemplo:

• vendas por mês;

• pedidos por cidade;

• receita por produto;

• clientes por segmento;

• salário médio por departamento.

Agrupando por mais de uma coluna

Também podemos utilizar mais de uma coluna no GROUP BY.

Imagine que queremos descobrir quanto cada cliente gastou em cada categoria:

SELECT
    customer_id,
    category,
    SUM(order_value) AS total_sales
FROM orders
GROUP BY customer_id, category;

Nesse caso, o grupo é definido pela combinação de customer_id e category.

Ou seja, teremos uma linha para cada combinação de cliente e categoria.

Essa possibilidade é muito importante em análises mais detalhadas.

WHERE e GROUP BY

É comum utilizar WHERE junto com GROUP BY.

Por exemplo, podemos querer calcular as vendas por categoria considerando apenas pedidos acima de R$ 500:

SELECT
    category,
    SUM(order_value) AS total_sales
FROM orders
WHERE order_value > 500
GROUP BY category;

Aqui acontece uma sequência lógica:

1. O WHERE filtra os pedidos.

2. O GROUP BY agrupa os pedidos restantes.

3. O SUM calcula o total de cada grupo.

Essa ordem de raciocínio é importante.

Primeiro decidimos quais registros participam da análise. Depois decidimos como agrupá-los.

WHERE não é HAVING

Existe uma diferença importante entre WHERE e HAVING.

O WHERE filtra registros antes da agregação.

O HAVING filtra grupos depois da agregação.

Por exemplo, imagine que queremos encontrar apenas as categorias que faturaram mais de R$ 1.000:

SELECT
    category,
    SUM(order_value) AS total_sales
FROM orders
GROUP BY category
HAVING SUM(order_value) > 1000;

Nesse caso, não queremos filtrar pedidos individuais.

Queremos primeiro calcular o total de cada categoria e, depois, manter apenas as categorias cujo total ultrapassa R$ 1.000.

Uma forma simples de lembrar é:

WHERE filtra linhas. HAVING filtra grupos.

Essa diferença aparece com muita frequência em consultas de análise de dados.

Uma consulta mais completa

Agora podemos combinar vários dos conceitos que aprendemos.

Imagine que queremos descobrir as cinco categorias com maior faturamento em 2026.

Uma consulta poderia ser:

SELECT
    category,
    COUNT(*) AS total_orders,
    SUM(order_value) AS total_sales,
    AVG(order_value) AS average_order_value
FROM orders
WHERE order_date >= '2026-01-01'
  AND order_date < '2027-01-01'
GROUP BY category
ORDER BY total_sales DESC
LIMIT 5;

Essa consulta parece mais complexa, mas podemos desmontá-la em etapas:

• WHERE seleciona apenas os pedidos de 2026;

• GROUP BY separa os pedidos por categoria;

• COUNT calcula a quantidade de pedidos;

• SUM calcula o faturamento;

• AVG calcula o ticket médio;

• ORDER BY coloca as categorias mais lucrativas primeiro;

• LIMIT mantém apenas as cinco primeiras.

Perceba como os comandos que aprendemos nos artigos anteriores começam a se combinar para responder perguntas mais interessantes.

Pensando como um analista

A essa altura, é importante começar a mudar a maneira de pensar sobre SQL.

Uma consulta não deve ser apenas uma sequência de comandos que você tenta montar até funcionar.

Antes de escrever o código, tente transformar a pergunta em etapas.

Por exemplo:

"Quais cidades geraram mais vendas?"

Podemos pensar:

O que quero medir? Valor das vendas → SUM

Como quero dividir os dados? Por cidade → GROUP BY city

Como quero ordenar? Da maior para a menor venda → ORDER BY

A consulta então surge naturalmente:

SELECT
    city,
    SUM(order_value) AS total_sales
FROM orders
GROUP BY city
ORDER BY total_sales DESC;

Esse raciocínio é muito mais importante do que decorar a sintaxe.

Cuidado com o nível de detalhe

Um erro bastante comum ao começar a utilizar GROUP BY é escolher uma granularidade que não corresponde à pergunta.

Imagine que queremos descobrir o faturamento por cidade. Se adicionarmos também customer_id ao agrupamento:

GROUP BY city, customer_id

já não teremos mais o faturamento por cidade. Teremos o faturamento por cliente dentro de cada cidade.

O resultado pode continuar sendo tecnicamente correto, mas responderá a uma pergunta diferente.

Por isso, antes de utilizar GROUP BY, pergunte:

"Qual deve ser uma linha do meu resultado final?"

Se a resposta for "uma linha por cidade", provavelmente city será a dimensão que você deve utilizar no agrupamento.

Essa forma de pensar será cada vez mais importante à medida que as consultas ficarem mais complexas.

O que aprendemos até aqui?

Neste artigo, vimos como transformar registros individuais em métricas e resumos utilizando:

• COUNT para contar registros;

• SUM para calcular totais;

• AVG para calcular médias;

• MIN e MAX para encontrar extremos;

• GROUP BY para dividir os dados em grupos;

• HAVING para filtrar grupos após a agregação.

Esses recursos estão entre os mais utilizados em SQL para análise de dados.

Com eles, já conseguimos responder perguntas bastante comuns de negócio, como:

Quanto vendemos?

Quantos pedidos recebemos?

Qual é o ticket médio?

Qual categoria vende mais?

Quais cidades geram mais receita?

Mas ainda existe um problema importante.

Os dados de uma empresa normalmente não estão todos em uma única tabela. Clientes estão em uma tabela, pedidos em outra, produtos em outra e assim por diante.

Como podemos combinar essas informações?

Para isso, precisamos aprender um dos conceitos mais importantes de SQL: os JOINs.

No próximo artigo, vamos entender como combinar dados de diferentes tabelas e, principalmente, como evitar erros comuns que podem fazer uma análise apresentar números incorretos.

Agora vamos começar a colocar a mão na massa.

Neste artigo, vamos conhecer alguns dos comandos mais básicos e importantes do SQL: SELECT, FROM, WHERE e ORDER BY. Com eles, já conseguimos fazer algo fundamental em qualquer análise: escolher quais dados queremos consultar, filtrar os registros que nos interessam e organizar o resultado.

Para os exemplos, vamos continuar imaginando o banco de dados de uma loja virtual.

Consultando uma tabela com SELECT

O comando SELECT é provavelmente o primeiro comando SQL que você vai aprender. Ele serve para indicar quais informações queremos obter de uma tabela.

Imagine uma tabela chamada customers, que contém informações sobre os clientes:

Se quisermos consultar os nomes dos clientes, podemos escrever:

SELECT name
FROM customers;

A palavra FROM indica de qual tabela queremos buscar os dados.

Podemos interpretar a consulta assim:

"Selecione o nome a partir da tabela de clientes."

O resultado seria:

Também podemos selecionar mais de uma coluna:

SELECT name, city
FROM customers;

Nesse caso, o resultado terá apenas o nome e a cidade de cada cliente.

Selecionando todas as colunas

Às vezes queremos consultar todas as informações disponíveis na tabela. Para isso, podemos utilizar o asterisco (*):

SELECT *
FROM customers;

O * significa que queremos todas as colunas.

Embora seja útil para explorar uma tabela rapidamente, é uma boa prática evitar SELECT * em consultas que serão utilizadas de forma definitiva. Quando sabemos quais colunas precisamos, é preferível especificá-las:

SELECT name, city, age
FROM customers;

Isso deixa a consulta mais clara e evita trazer dados desnecessários.

Filtrando dados com WHERE

Selecionar dados é apenas o começo. Em uma análise, normalmente não queremos todos os registros de uma tabela.

Imagine que queremos descobrir apenas os clientes que moram em São Paulo.

É para isso que usamos o WHERE.

SELECT name, city
FROM customers
WHERE city = 'São Paulo';

Agora o banco de dados retorna somente os registros que atendem à condição.

O WHERE pode ser entendido como:

"Retorne apenas os registros que satisfazem esta condição."

Esse é um dos comandos mais importantes do SQL, porque permite trabalhar com subconjuntos dos dados.

Comparando valores

Podemos utilizar diferentes operadores para criar filtros.

Por exemplo, para encontrar clientes com mais de 30 anos:

SELECT name, age
FROM customers
WHERE age > 30;

Podemos também procurar clientes com idade igual a 30:

SELECT name, age
FROM customers
WHERE age = 30;

Alguns dos operadores mais comuns são:

Eles podem ser utilizados tanto com números quanto com outros tipos de dados, dependendo da situação.

Combinando condições

Também podemos criar filtros mais específicos combinando condições.

O operador AND exige que todas as condições sejam verdadeiras.

Por exemplo, para encontrar clientes de São Paulo com mais de 30 anos:

SELECT name, city, age
FROM customers
WHERE city = 'São Paulo'
  AND age > 30;

Já o operador OR permite que pelo menos uma das condições seja verdadeira.

SELECT name, city
FROM customers
WHERE city = 'São Paulo'
   OR city = 'Rio de Janeiro';

Nesse caso, serão retornados clientes de qualquer uma das duas cidades.

É importante prestar atenção à lógica das condições. À medida que as consultas ficam mais complexas, o uso de parênteses pode ajudar a deixar essa lógica explícita.

Filtrando por uma lista de valores com IN

Quando queremos verificar se uma coluna corresponde a vários valores possíveis, o operador IN pode deixar a consulta mais simples.

Por exemplo:

SELECT name, city
FROM customers
WHERE city IN ('São Paulo', 'Rio de Janeiro', 'Curitiba');

Em vez de escrever várias condições com OR, podemos informar diretamente a lista de valores desejados.

Filtrando intervalos com BETWEEN

O BETWEEN é útil quando queremos trabalhar com intervalos.

Por exemplo, para encontrar clientes com idade entre 25 e 35 anos:

SELECT name, age
FROM customers
WHERE age BETWEEN 25 AND 35;

Ele também pode ser utilizado com datas, algo bastante comum em análise de dados.

Por exemplo:

SELECT *
FROM orders
WHERE order_date BETWEEN '2026-01-01' AND '2026-01-31';

Ao trabalhar com datas, entretanto, é importante entender como o banco de dados armazena valores de data e hora. Em situações mais complexas, outras formas de filtragem podem ser mais adequadas.

Procurando textos com LIKE

O operador LIKE permite procurar padrões dentro de textos.

Por exemplo, imagine que queremos encontrar clientes cujo nome começa com "Mar":

SELECT name
FROM customers
WHERE name LIKE 'Mar%';

O símbolo % representa uma sequência de caracteres.

Assim, a condição poderia encontrar nomes como:

• Maria

• Marcos

• Mariana

O LIKE é especialmente útil quando não conhecemos exatamente o valor que estamos procurando.

Organizando os resultados com ORDER BY

Depois de selecionar e filtrar os dados, talvez seja interessante organizá-los.

Para isso, usamos o ORDER BY.

Por exemplo, podemos listar os clientes do mais velho para o mais novo:

SELECT name, age
FROM customers
ORDER BY age DESC;

DESC significa que queremos a ordenação decrescente.

Para fazer o contrário, podemos usar ASC:

SELECT name, age
FROM customers
ORDER BY age ASC;

ASC significa ordem crescente.

Na prática, ASC costuma ser o comportamento padrão, então também poderíamos escrever:

SELECT name, age
FROM customers
ORDER BY age;

Ordenando por mais de uma coluna

Também podemos utilizar mais de uma coluna no ORDER BY.

Imagine que queremos ordenar os clientes primeiro por cidade e, dentro de cada cidade, pelo nome:

SELECT name, city
FROM customers
ORDER BY city ASC, name ASC;

O banco primeiro organiza os registros pela cidade. Quando dois ou mais registros possuem a mesma cidade, o nome é utilizado como critério seguinte.

Essa possibilidade é bastante útil quando estamos explorando dados e queremos tornar o resultado mais fácil de interpretar.

Limitando a quantidade de resultados

Quando estamos trabalhando com tabelas muito grandes, pode ser útil retornar apenas uma determinada quantidade de registros.

Em muitos bancos de dados, podemos utilizar LIMIT:

SELECT name, age
FROM customers
ORDER BY age DESC
LIMIT 10;

Nesse exemplo, estamos pedindo os 10 clientes mais velhos.

Uma combinação como essa é bastante comum:

SELECT → escolhe as colunas
FROM → indica a tabela
WHERE → filtra os registros
ORDER BY → organiza o resultado
LIMIT → limita a quantidade de linhas

Juntando tudo

Agora podemos combinar os conceitos que vimos.

Imagine que queremos encontrar os cinco pedidos de maior valor realizados em janeiro de 2026.

Uma consulta poderia ser:

SELECT customer_id, order_date, order_value
FROM orders
WHERE order_date BETWEEN '2026-01-01' AND '2026-01-31'
ORDER BY order_value DESC
LIMIT 5;

Podemos ler essa consulta de cima para baixo:

• SELECT: queremos cliente, data e valor do pedido;

• FROM: os dados estão na tabela orders;

• WHERE: queremos apenas pedidos de janeiro;

• ORDER BY: queremos ordenar pelo valor, do maior para o menor;

• LIMIT: queremos apenas os cinco primeiros resultados.

Essa forma de pensar é muito importante. Em vez de tentar decorar cada consulta, procure entender qual pergunta estamos fazendo ao banco e como cada cláusula ajuda a responder essa pergunta.

E o DISTINCT?

Existe ainda um comando bastante útil nessa etapa: DISTINCT. Ele serve para eliminar valores duplicados do resultado.

Por exemplo, se quisermos descobrir quais cidades aparecem na tabela de clientes:

SELECT DISTINCT city
FROM customers;

Em vez de retornar a cidade de cada cliente, teremos uma lista de cidades sem repetições.

Isso pode ser bastante útil durante a exploração inicial dos dados.

O que aprendemos até aqui?

Neste artigo, conhecemos alguns dos principais blocos de construção de uma consulta SQL:

• SELECT para escolher as colunas;

• FROM para indicar a tabela;

• WHERE para filtrar registros;

• AND e OR para combinar condições;

• IN para trabalhar com listas de valores;

• BETWEEN para intervalos;

• LIKE para procurar padrões em textos;

• ORDER BY para ordenar resultados;

• LIMIT para limitar a quantidade de registros;

• DISTINCT para remover duplicidades do resultado.

Com esses comandos, já conseguimos realizar uma quantidade razoável de consultas simples.

Mas ainda estamos olhando para os dados principalmente linha por linha. Em análise de dados, muitas vezes queremos algo diferente: transformar milhares ou milhões de registros em métricas e resumos.

Por exemplo:

Quantos pedidos foram realizados?

Qual foi o faturamento total?

Qual produto vendeu mais?

Quanto cada categoria faturou?

Para responder perguntas desse tipo, precisamos aprender a agrupar e agregar dados.

É isso que veremos no próximo artigo, quando entraremos em COUNT, SUM, AVG e GROUP BY.

Mas afinal, o que é SQL e por que ele é tão importante para quem trabalha com dados?

Neste artigo, vamos entender os conceitos básicos sem entrar em detalhes técnicos. A ideia é oferecer um ponto de partida para quem nunca trabalhou com SQL e mostrar quais conhecimentos você deve desenvolver a partir daqui.

O que é SQL?

SQL, sigla para Structured Query Language (Linguagem de Consulta Estruturada), é uma linguagem utilizada para trabalhar com bancos de dados relacionais.

De forma simples, podemos pensar no SQL como uma maneira de fazer perguntas aos dados.

Imagine, por exemplo, que uma empresa tenha milhares de registros de vendas. Um analista pode querer responder perguntas como:

• Quanto a empresa vendeu no último mês?

• Quais foram os produtos mais vendidos?

• Quais clientes fizeram mais compras?

• Qual categoria gerou mais receita?

• Como as vendas evoluíram ao longo do tempo?

Em vez de procurar essas informações manualmente, podemos utilizar SQL para fazer essas consultas diretamente ao banco de dados.

Onde os dados ficam?

Antes de entender SQL, é importante conhecer alguns conceitos básicos de bancos de dados.

Um banco de dados pode armazenar diversas tabelas, e cada tabela normalmente representa um tipo de informação.

Imagine um banco de dados de uma loja virtual. Ele poderia ter tabelas como:

• customers: informações sobre clientes;

• orders: pedidos realizados;

• products: produtos disponíveis;

• categories: categorias dos produtos.

Uma tabela, por sua vez, é formada por colunas e linhas.

Por exemplo:

Cada coluna representa uma característica dos dados. Nesse caso, temos id, cliente, cidade e idade.

Cada linha representa um registro.

É sobre essas tabelas que vamos fazer nossas consultas utilizando SQL.

O que um analista pode fazer com SQL?

Uma das grandes vantagens do SQL é que ele permite transformar grandes quantidades de registros em informações úteis para análise.

Por exemplo, suponha que a tabela orders tenha milhões de pedidos.

Podemos utilizar SQL para descobrir apenas os pedidos realizados em determinado período:

SELECT *
FROM orders
WHERE order_date >= '2026-01-01';

Ou podemos calcular o valor total das vendas:

SELECT SUM(order_value)
FROM orders;

Também podemos agrupar os dados para descobrir quanto foi vendido por categoria:

SELECT category, SUM(order_value)
FROM orders
GROUP BY category;

Não é necessário entender todos esses comandos agora. O importante é perceber a lógica: SQL permite selecionar, filtrar, organizar, combinar e resumir dados para responder perguntas.

É justamente por isso que SQL é tão útil para análise de dados.

SQL é programação?

Essa é uma dúvida bastante comum de quem está começando.

SQL é, sim, uma linguagem, mas sua utilização é diferente daquela de linguagens de programação de propósito geral, como Python ou Java.

Quando estamos fazendo uma consulta SQL, normalmente estamos dizendo ao banco o que queremos encontrar, e não descrevendo passo a passo como o computador deve executar toda a tarefa.

Por exemplo:

SELECT name
FROM customers
WHERE city = 'São Paulo';

Essa consulta pode ser lida de maneira bastante próxima da linguagem natural:

"Selecione o nome dos clientes que moram em São Paulo."

Essa característica torna SQL relativamente acessível para iniciantes, especialmente quando o objetivo é trabalhar com análise de dados.

SQL e análise de dados

Para um analista, SQL não é importante apenas porque permite consultar bancos de dados. O mais importante é que ele ajuda a transformar dados brutos em informações que podem responder perguntas de negócio.

Imagine que uma empresa queira saber:

"As vendas aumentaram neste ano?"

Essa pergunta pode parecer simples, mas para respondê-la talvez seja necessário:

1. encontrar os pedidos do período analisado;

2. calcular o valor das vendas;

3. agrupar os resultados por mês;

4. comparar os meses;

5. calcular a variação percentual.

SQL pode ser utilizado em várias dessas etapas.

Por isso, aprender SQL para análise de dados não significa apenas decorar comandos. É necessário desenvolver a capacidade de pensar sobre os dados e transformar uma pergunta em uma consulta.

O que você precisa aprender primeiro?

SQL possui muitos recursos, mas você não precisa aprender tudo de uma vez.

Para quem está começando com foco em análise de dados, uma sequência bastante útil é:

1. SELECT e FROM Aprender a selecionar informações de uma tabela.

2. WHERE Aprender a filtrar os dados.

3. ORDER BY e LIMIT Aprender a ordenar e limitar os resultados.

4. Funções de agregação e GROUP BY Aprender a calcular métricas como soma, média e quantidade.

5. JOINs Aprender a combinar informações de diferentes tabelas.

6. CASE WHEN e tratamento de NULL Aprender a criar classificações e lidar com dados ausentes.

7. CTEs e subqueries Aprender a estruturar consultas mais complexas.

8. Window Functions Aprender técnicas mais avançadas para comparar registros, criar rankings e realizar análises ao longo do tempo.

Essa sequência não é uma regra absoluta, mas oferece um bom caminho para quem está começando.

SQL é suficiente para trabalhar com dados?

Não necessariamente.

SQL é uma ferramenta muito importante, mas análise de dados normalmente envolve outras competências também.

Dependendo da função, um profissional pode trabalhar com ferramentas de visualização, como Power BI ou Tableau, planilhas, Python, estatística e outras tecnologias.

Além disso, conhecer SQL não substitui a capacidade de entender o contexto do negócio e fazer boas perguntas.

Uma consulta SQL pode estar perfeitamente correta e ainda assim responder à pergunta errada.

Por isso, uma boa análise combina conhecimento técnico, raciocínio analítico e entendimento do problema que precisa ser resolvido.

Por onde começar?

Se você nunca utilizou SQL, não tente memorizar dezenas de comandos de uma vez.

Comece entendendo a estrutura de um banco de dados e aprenda a fazer consultas simples. Depois, avance gradualmente para filtros, agregações, combinações entre tabelas e, por fim, recursos mais avançados.

Ao longo deste guia, vamos seguir justamente esse caminho.

Nos próximos artigos, começaremos pelo básico: como selecionar, filtrar e ordenar dados com SQL. Depois, avançaremos para agregações, JOINs e recursos intermediários.

O objetivo não é transformar você em especialista em SQL, mas oferecer uma base suficiente para que consiga entender consultas, explorar dados e começar a resolver problemas reais de análise.

E talvez essa seja a melhor maneira de pensar em SQL:

SQL é uma ferramenta para fazer perguntas aos dados e transformar as respostas em informação útil.