MySQL para Análise de Dados: consultas, métricas e perguntas de negócio

Do SQLite ao MySQL no projeto de análise - Apresentação

Apresentando o curso e o instrutor

Olá! Seja bem-vinde a este curso de MySQL para análise de dados. Eu sou Victorino Villa e vou acompanhar você ao longo desta jornada. Antes de qualquer coisa, obrigado por estar aqui.

Sempre que alguém escolhe estudar dados, SQL e análise, dá um passo importante para trabalhar melhor com informação, qualificar a tomada de decisão, fazer com que essas decisões sejam tomadas com mais critério e enxergar o negócio com mais profundidade. É isso que nós vamos fazer neste curso.

Definindo o foco do curso e o papel da pessoa analista

Aqui, o foco não é transformar você em uma pessoa administradora de banco de dados, nem fazer decorar comandos isolados de MySQL. Nosso objetivo é usar o MySQL como ferramenta de trabalho para a pessoa analista de dados.

Ao longo dos vídeos, nós vamos trabalhar com a base da empresa Suprema Shop, uma empresa fictícia de varejo que vende produtos pelo site, pelo aplicativo e em lojas físicas. Neste curso, você assumirá o papel de pessoa analista de dados dessa empresa.

Detalhando objetivos e técnicas de análise com dados

Partiremos de uma pergunta de negócio e a transformaremos — assim como outras perguntas — em consultas SQL.

Nós vamos entender a estrutura da base, reconhecer tabelas importantes, filtrar dados relevantes, organizar os resultados, criar métricas, usar agregações, cruzar informações com joins (junções), organizar consultas com subqueries (subconsultas) e CTEs (Expressões de Tabela Comuns), criar views (visões) e preparar o resultado para a entrega. Tudo isso sempre conectado a situações do dia a dia de quem trabalha como pessoa analista de dados. Por exemplo: quais canais vendem mais? Quais estados concentram mais faturamento? Quais categorias de produtos se destacam? Como transformar uma pergunta ampla em um indicador? Como conferir se uma métrica faz sentido antes de entregar? Esse tipo de raciocínio é muito importante para quem quer atuar como pessoa analista de dados.

Conhecer a SQL (Linguagem de Consulta Estruturada) não é apenas sair escrevendo comandos; é saber pensar com dados, olhar para uma pergunta de negócio, encontrar as tabelas certas, escolher os filtros corretos, calcular a métrica adequada e interpretar o resultado com responsabilidade. Ao desenvolver essa habilidade, tornamo-nos uma pessoa profissional muito mais preparada. Deixamos de apenas esperar que alguém entregue uma resposta pronta e passamos a investigar, validar, comparar, questionar e comunicar melhor o que os dados mostram. Isso faz diferença em qualquer área que utiliza dados para a tomada de decisão.

Encorajando a prática e concluindo a introdução

Bem, eu estou muito feliz em começar esse curso com vocês. Espero que ao longo das aulas e dos vídeos você pratique bastante, erre sem medo, teste consultas, compare resultados e construa confiança para usar a SQL em análises reais.

Mais uma vez, muito obrigado por estar aqui. Vamos começar? Até o próximo vídeo.

Do SQLite ao MySQL no projeto de análise - Apresentação do curso e do projeto de análise

Apresentando o curso e a abordagem analítica

Apresentação do curso e do projeto de análise

Neste curso, assumiremos o papel de pessoa analista de dados da Suprema Shop, uma empresa fictícia de comércio varejista. Isso significa que a empresa vende diferentes produtos por distintos canais: site, aplicativo móvel e lojas físicas. Como ocorre em muitas empresas reais, a diretoria quer usar os dados para entender melhor o negócio. Quer saber, por exemplo, quais categorias vendem mais, quais estados concentram mais faturamento, quais canais geram mais pedidos, quais produtos aparecem entre os mais vendidos e como transformar essas informações em consultas que possam ser reutilizadas em relatórios, planilhas e em dashboards (painéis).

Ao longo do curso, nossa proposta não será aprender MySQL como se estivéssemos memorizando comandos isolados. A ideia é usar MySQL como uma ferramenta de trabalho. Sempre que surgir um comando, uma função ou uma estrutura de SQL no curso, ela estará conectada a uma pergunta de negócio.

Por exemplo, se a área comercial perguntar qual foi o faturamento por categoria, precisamos localizar as tabelas corretas, somar os valores e agrupar os resultados. Se a área de marketing perguntar quais vendas vieram de campanhas, precisamos cruzar pedidos com campanhas. Se a diretoria perguntar quais clientes compraram recentemente, precisamos observar pedidos, datas e o comportamento de compra. Esse é o fluxo de trabalho típico: recebemos uma pergunta, entendemos os dados disponíveis, escrevemos uma consulta, verificamos o resultado e o transformamos em uma resposta útil.

Antes de continuar, vale ressaltar um ponto importante. Este curso parte do princípio de que já conhecemos SQL básico, que já tivemos contato com comandos como SELECT, WHERE e ORDER BY, no curso de SQLite, que é requisito deste curso. Aqui não começaremos do zero; nosso foco será usar o conhecimento que já temos de SQL, agora em uma base em MySQL, que é um ambiente mais parecido com o profissional, onde teremos várias tabelas, essas tabelas estarão relacionadas e haverá um volume maior de dados.

Na base da Suprema Shop, que é nosso estudo de caso, trabalharemos com tabelas como clientes, pedidos, linhas de pedido, produtos, categorias, campanhas, entregas e centros de distribuição. Cada uma dessas tabelas conta uma parte da história dos dados. A tabela de clientes mostra quem compra. A tabela de pedidos mostra quando a compra ocorreu, por qual canal de venda foi realizada, qual foi o status dessa compra e qual é o valor total registrado. A tabela de linhas de pedido mostra o detalhamento de cada produto vendido dentro de um pedido. A tabela de produtos indica o nome do produto, isto é, o que foi vendido. Também temos a tabela de categorias, que ajuda a organizar os produtos em grupos de negócio. E as tabelas de campanhas, entregas e centros de distribuição permitem, por exemplo, ampliar a análise para a área de marketing e para a logística.

Preparando o ambiente e reconhecendo a base

Antes de partirmos para a demonstração, há um ponto importante sobre o ambiente. Para acompanhar este curso, é necessário ter em sua máquina o MySQL e também o MySQL Workbench, que será a ferramenta visual que usaremos para nos conectarmos à base, abrir os scripts (roteiros de código) e executar as consultas. Se o ambiente ainda não foi preparado, vale retomar a atividade anterior a este vídeo. Nessa atividade, estão disponíveis as instruções de instalação e configuração do MySQL e do MySQL Workbench. Realizar essa etapa é importante, porque a partir de agora trabalharemos com uma base real. Quanto antes o ambiente estiver funcionando, mais fácil será acompanhar as demonstrações e testar as consultas junto conosco.

Agora, vamos examinar a base de dados dentro do MySQL Workbench. No seu caso, ainda não é possível visualizar a base com a qual vamos trabalhar, Suprema Shop Analíticos. Não se preocupe: nos próximos vídeos, faremos a criação e a carga dessa base. Neste momento, não é necessário ter essa base nem entender todas as tabelas em profundidade. Nosso objetivo é mostrar como reconhecer o ambiente com o qual vamos trabalhar.

Com a conexão aberta no Workbench, vamos clicar no botão na parte superior que representa abrir uma nova guia, onde vamos escrever os comandos SQL.

Navegando no workbench e executando comandos iniciais

Ao clicarmos aqui, criamos uma nova aba e, por exemplo, executamos o comando para selecionar o banco de dados com o qual vamos trabalhar. No editor, rodamos:

USE supremashop_analytics;

Ao clicar no botão superior com o ícone de raio, executamos o comando que está na tela.

Ao fazer isso, recebemos abaixo uma mensagem informando que nos conectamos ao banco de dados. Como trabalharemos com várias tabelas, pode ser interessante verificar quais tabelas existem nesse banco. Para isso, utilizamos o comando a seguir para listar todas as tabelas e visões disponíveis:

SHOW TABLES;

Ao executá-lo, visualizamos abaixo o nome de todas as tabelas com as quais vamos trabalhar, não apenas tabelas, mas também as views (visões), que são tabelas lógicas.

Isso já indica que estamos trabalhando com um banco de dados relacional, pois as informações não ficam concentradas em uma única tabela grande. Elas são distribuídas em várias tabelas menores. O ponto fundamental para a pessoa analista de dados é saber como combinar essas tabelas para obter o resultado desejado.

Investigando tabelas e realizando consultas iniciais

Por exemplo, vamos consultar algumas linhas da tabela de pedidos. Se executarmos a instrução abaixo, visualizamos as primeiras linhas dessa tabela:

SELECT * FROM pedidos;

Observamos que há diversas informações úteis para análise: o identificador do pedido, a pessoa cliente associada ao pedido, a data do pedido, o valor total, o status do pedido (a situação atual) e o canal de venda pelo qual o pedido foi realizado.

Somente olhando as primeiras linhas, já conseguimos inferir análises possíveis: quantos pedidos foram entregues, qual canal vende mais, se o faturamento vem mais do site, do app (aplicativo) ou da loja física, e como as vendas evoluem ao longo do tempo. Com a visualização dessa tabela, já conseguimos antecipar essas investigações.

Agora, ao consultar a tabela de produtos com o comando abaixo, encontramos outro conjunto de informações: essa tabela mostra o que a empresa vende.

SELECT * FROM produtos;

No entanto, apenas observando essa tabela, não conseguimos saber quanto cada produto vendeu. Para responder a isso, precisamos combinar, ou cruzar, os dados da tabela de produtos com a tabela de itens de pedido.

Podemos escrever a consulta a seguir para visualizar alguns itens de pedido. No MySQL Workbench, inclusive, podemos arrastar o nome da tabela a partir da lateral para o editor de consultas.

SELECT * FROM itens_pedidos;

Na tabela de itens de pedido, temos o identificador do produto, que permite unir essa informação com a tabela de produtos e, assim, obter o nome dos produtos. São essas relações que a pessoa analista de dados, diante de uma pergunta de negócio, precisa descobrir como resolver dentro do banco.

Evoluindo as análises e consolidando o raciocínio

Ao longo das próximas aulas, avançaremos progressivamente nesse processo: primeiro entenderemos a demanda de negócio e exploraremos o banco; depois construiremos métricas com agregações — como quantidade de pedidos, faturamento, ticket médio e volume de clientes. Em seguida, cruzaremos informações usando joins (junções) para responder perguntas que dependem de mais de uma tabela. Depois, organizaremos as análises com subqueries (subconsultas) e CTEs (expressões de tabela comuns), deixando as consultas mais claras e fáceis de manter. Ao final, criaremos consultas reutilizáveis com views (visões) e prepararemos resultados para uma entrega inicial à pessoa cliente.

O mais importante é aprendermos a pensar como uma pessoa analista de dados. Não basta escrever uma consulta que execute; a consulta deve responder a uma pergunta, fazer sentido para o negócio e ter seus resultados verificados antes da entrega.

Neste curso, sempre que escrevermos uma consulta SQL, vamos responder a três perguntas específicas:

• Qual problema de negócio estamos tentando resolver?
• Quais tabelas e campos podem nos ajudar?
• Como interpretar os resultados da consulta?

Ao construir esse raciocínio, o MySQL deixa de ser apenas uma ferramenta técnica e passa a ser um meio para investigar, validar e comunicar informações.

No próximo vídeo, falaremos sobre o que muda quando saímos do ambiente do SQLite e passamos a trabalhar com o MySQL no contexto de análise de dados. Veremos que muitos aspectos da linguagem SQL permanecem familiares, mas o ambiente, o volume de dados e a forma de organizar o trabalho se aproximam mais do que encontramos nas empresas.

Um abraço, até o próximo vídeo.

Do SQLite ao MySQL no projeto de análise - O que muda do SQLite para o MySQL no trabalho do analista

Contextualizando a transição do SQLite para o MySQL

O que muda ao sairmos do SQLite para o MySQL no trabalho da pessoa analista? No vídeo anterior, apresentamos o curso, conhecemos a ideia de Suprema Shop e vimos que nosso papel aqui é pensar como pessoa analista de dados. Agora, antes de mergulharmos nos análises, vale responder a uma pergunta importante: se já estudamos SQL em SQLite, o que vai mudar quando começarmos a trabalhar com MySQL?

Essa pergunta é relevante porque, em muitos momentos, a linguagem que vamos usar aqui será muito familiar. Vamos perceber que já conhecemos boa parte do que será utilizado. Continuaremos, em MySQL, escrevendo consultas com SELECT, filtrando registros com WHERE, ordenando resultados com ORDER BY e agrupando dados com GROUP BY. Portanto, a mudança aqui não é descartar o que já aprendemos, e sim entender que agora estamos usando SQL em um ambiente mais próximo daquele que encontramos nas empresas.

No SQLite, é muito comum trabalhar com um banco em um arquivo, o que torna o uso leve e direto, sendo excelente para aprender SQL. Também é uma ótima opção para praticar consultas e entender como funciona a lógica relacional de um banco SQL. Aqui, em MySQL, vamos trabalhar com um servidor de banco de dados. Isso significa que o banco não é apenas um arquivo aberto localmente. Há um serviço em execução, uma conexão com usuário e senha, um banco selecionado, permissões, esquemas, tipos de dados mais bem definidos e também um volume de informações potencialmente muito maior.

Para a pessoa analista de dados, isso altera principalmente a forma de organizar o trabalho no banco. Antes de consultar qualquer tabela, precisamos saber a qual banco estamos conectados. Devemos reconhecer quais tabelas fazem parte desse esquema e entender os tipos de campos, porque conhecer esses tipos é importante: eles afetam filtros, cálculos, datas e valores financeiros. Além disso, precisamos escrever consultas considerando que podem ser executadas em tabelas grandes, com centenas de milhares ou até milhões de linhas.

Isso não significa que este curso vai se transformar em um curso de administração de bancos de dados. Nosso foco continua sendo a análise. A diferença é que agora vamos analisar dados em um ambiente muito mais robusto.

Preparando o ambiente e validando o banco conectado

Vamos imaginar a seguinte situação em Suprema Shop: a diretoria quer monitorar as vendas por canal, comparando site, aplicativo e loja física. Essa é uma pergunta simples de negócio, mas já ilustra bem a transição do SQLite para o ambiente MySQL. Em um raciocínio SQL, essa consulta pode parecer familiar: vamos selecionar o canal, contar pedidos, somar o faturamento e agrupar os resultados. Porém, no ambiente MySQL, antes de fazer isso, precisamos confirmar se estamos no banco correto, entender a estrutura da tabela de pedidos e observar como os dados estão tipados dentro do banco. Esse é o tipo de cuidado que faz parte do trabalho da pessoa profissional analista de dados. Não se trata apenas de escrever uma consulta, e sim de saber onde ela está sendo executada, quais campos estamos usando e se o resultado faz sentido para a pergunta de negócio.

Vamos ver isso na prática no MySQL Workbench (ferramenta do MySQL). Por enquanto, precisamos apenas acompanhar. Posteriormente, vamos carregar no MySQL Workbench (ferramenta do MySQL) instalado na máquina local esta mesma base de dados com a qual estamos trabalhando.

Para entendermos melhor o que foi apresentado anteriormente, vamos criar uma nova área de trabalho e confirmar em qual banco estamos conectados. Ao olhar a interface, poderíamos supor que estamos na base Suprema Shop porque ela aparece em negrito. Porém, precisamos compreender os comandos SQL do MySQL, pois muitas vezes não estaremos trabalhando no MySQL Workbench (ferramenta do MySQL). Podemos, por exemplo, programar SQL dentro de um programa em Python (linguagem de programação), C# (linguagem de programação) ou Java (linguagem de programação). Precisamos saber qual é o comando que informa a qual banco estamos conectados. Esse comando, por exemplo, é SELECT DATABASE(); podemos ainda definir um alias (apelido) para verificar esse resultado com clareza. É uma consulta simples, mas muito útil, porque, em um ambiente real, podemos ter vários bancos disponíveis.

Verificando o banco atual e identificando tabelas

Para isso, primeiro executamos a verificação direta do banco atual:

SELECT DATABASE();

Em seguida, deixamos o resultado mais claro com um alias:

SELECT DATABASE() AS banco_atual;

No nosso caso, precisamos executar SELECT DATABASE() para ter certeza de que estamos dentro do banco Suprema Shop, que é o que vamos usar para trabalhar. Em seguida, se quisermos trabalhar com a tabela de pedidos, podemos executar SHOW TABLES LIKE 'pedido'. Ao rodar esse comando, esperaríamos encontrar a tabela de pedidos. No entanto, o nome correto é 'pedidos'. Se buscarmos por 'pedido', nada aparecerá; ao ajustar para SHOW TABLES LIKE 'pedidos', veremos que a tabela existe nesse banco.

Primeiro, a tentativa com o nome incorreto:

SHOW TABLES LIKE 'pedido';

Agora, a correção para o nome real da tabela:

SHOW TABLES LIKE 'pedidos';

Inspecionando a estrutura da tabela pedidos

Agora, podemos querer ver a estrutura da tabela pedidos. Ao executar DESCRIBE pedidos, obteremos um resultado que mostra uma tabela com os campos existentes: ID do pedido, ID do cliente, data do pedido, valor total, status e canal de venda. Também conseguimos ver os tipos de dados. Assim, sabemos, por exemplo, que o ID do pedido é do tipo inteiro, a data do pedido é do tipo DATE e o valor total é um número com 14 dígitos e duas casas decimais.

Para inspecionar a estrutura, usamos:

DESCRIBE pedidos;

Os campos status e canal_venda são listas de valores válidos; por isso estão definidos com ENUM. Isso significa que não podemos armazenar na tabela pedidos um canal_venda diferente de 'sitio', 'aplicación' ou 'tienda física'. Com isso em mente, podemos observar e entender a estrutura da tabela pedidos.

Analisando pedidos e faturamento por canal de venda

Vamos responder à primeira pergunta de negócio: qual canal teve mais pedidos entregues e maior faturamento? Para isso, acessamos a tabela pedidos e selecionamos os canais de venda, pois queremos identificar qual é o canal. A própria pergunta indica o que precisamos selecionar. Escolhemos canal_venda no SELECT. Em seguida, contamos o número de pedidos com COUNT(*) AS total_pedidos, assumindo que cada linha da tabela representa um pedido. Depois, somamos o valor total com SUM(valor_total) para obter o faturamento e nomeamos esse resultado como faturamento (com f minúsculo). Assim, já temos os elementos necessários: o canal de venda, a quantidade de pedidos entregues e o faturamento.

Começamos selecionando apenas o canal:

SELECT
    canal_venda,

Em seguida, adicionamos a contagem de pedidos:

SELECT
    canal_venda,
    COUNT(*) AS total_pedidos,

Agora, incluímos a soma do faturamento:

SELECT
    canal_venda,
    COUNT(*) AS total_pedidos,
    SUM(valor_total) AS faturamento

Definimos a origem dos dados:

SELECT
    canal_venda,
    COUNT(*) AS total_pedidos,
    SUM(valor_total) AS faturamento
FROM pedidos

Filtramos apenas os pedidos entregues:

SELECT
    canal_venda,
    COUNT(*) AS total_pedidos,
    SUM(valor_total) AS faturamento
FROM pedidos
WHERE status = 'Entregue'

Agrupamos por canal de venda:

SELECT
    canal_venda,
    COUNT(*) AS total_pedidos,
    SUM(valor_total) AS faturamento
FROM pedidos
WHERE status = 'Entregue'
GROUP BY canal_venda

E ordenamos pelo maior faturamento primeiro:

SELECT
    canal_venda,
    COUNT(*) AS total_pedidos,
    SUM(valor_total) AS faturamento
FROM pedidos
WHERE status = 'Entregue'
GROUP BY canal_venda
ORDER BY SUM(valor_total) DESC;

Os dados serão lidos da tabela pedidos. Entretanto, não utilizamos todos os pedidos; filtramos apenas os pedidos entregues com WHERE status = 'Entregue'. Como estamos utilizando COUNT(*) e SUM(valor_total), precisamos agrupar os resultados com GROUP BY, e o agrupamento será por canal_venda, que identifica cada linha agregada. Para descobrir qual canal tem o maior faturamento, ordenamos a saída por faturamento utilizando ORDER BY SUM(valor_total) DESC, da maior para a menor. A partir da pergunta de negócio, elaboramos esse comando SQL. Ao executar, obtemos o resultado ordenado: o maior faturamento é por 'sitio', o segundo por 'aplicación' e o terceiro por 'tienda física'.

Acompanhando a evolução mensal das vendas

O que fizemos foi responder a uma pergunta de negócio. Passemos à segunda pergunta: como evoluíram as vendas mês a mês? Novamente, analisamos a estrutura da tabela pedidos. Para ver mês a mês, o primeiro passo é selecionar a data do pedido. No entanto, a data do pedido está no nível do dia, e precisamos agregá-la no nível do mês. Podemos fazer isso em SQL utilizando a função DATE_FORMAT, que formata a data do pedido em um formato específico. Definimos o formato como "%Y-%m" (ano-mês). Assim, exibimos a data do pedido no formato ano-mês e podemos agrupar por mês. Nomeamos essa expressão como mes.

Primeiro, relembramos a estrutura da tabela:

DESCRIBE pedidos;

Agora, iniciamos extraindo a data no formato desejado:

SELECT
    DATE_FORMAT(data_pedido,

Completamos o formato ano-mês:

SELECT
    DATE_FORMAT(data_pedido, '%Y-%m')

Damos um alias para essa coluna derivada:

SELECT
    DATE_FORMAT(data_pedido, '%Y-%m') AS mes,

Aproveitamos os elementos da consulta anterior: contamos o número de pedidos, somamos o faturamento, usamos a mesma tabela e mantemos o filtro apenas para pedidos entregues:

SELECT
    DATE_FORMAT(data_pedido, '%Y-%m') AS mes,
    COUNT(*) AS total_pedidos,
    SUM(valor_total) AS faturamento
FROM pedidos
WHERE status = 'Entregue'

Agregamos por mês usando a mesma expressão:

SELECT
    DATE_FORMAT(data_pedido, '%Y-%m') AS mes,
    COUNT(*) AS total_pedidos,
    SUM(valor_total) AS faturamento
FROM pedidos
WHERE status = 'Entregue'
GROUP BY DATE_FORMAT(data_pedido, '%Y-%m')

E ordenamos cronologicamente:

SELECT
    DATE_FORMAT(data_pedido, '%Y-%m') AS mes,
    COUNT(*) AS total_pedidos,
    SUM(valor_total) AS faturamento
FROM pedidos
WHERE status = 'Entregue'
GROUP BY DATE_FORMAT(data_pedido, '%Y-%m')
ORDER BY DATE_FORMAT(data_pedido, '%Y-%m');

Ao executar essa segunda consulta, obtemos a evolução das vendas mês a mês, com o total de pedidos e o faturamento por mês.

Consolidando aprendizados e definindo próximos passos

O raciocínio analítico aqui é transformar uma pergunta de negócio em um comando SQL. Ao longo do curso, veremos diversos exemplos e, pouco a pouco, aprenderemos algumas diferenças encontradas no MySQL, principalmente na parte de funções. O MySQL possui funções que podem ser distintas das do SQLite. Ao sairmos do SQLite e entrarmos no MySQL, precisamos lembrar: não estamos começando do zero. O conhecimento de SQL adquirido continua válido; o que muda é o ambiente: servidor, conexão, base selecionada, schema (esquema), tipo de dado, funções e tabelas com maior volume.

Para a pessoa analista de dados, isso significa trabalhar com mais contexto. Antes de escrever uma consulta, vale confirmar onde estamos conectados. Antes de calcular uma métrica, vale entender quais campos estão disponíveis. Antes de entregar uma resposta, vale verificar se o resultado condiz com a pergunta de negócio realizada. Essa postura é mais importante do que memorizar as diferenças entre ferramentas. Ao longo do curso, construiremos essa confiança gradualmente. O MySQL não precisa ser tratado como algo distante ou intimidante; é simplesmente outra ferramenta para fazermos perguntas melhores sobre os dados das empresas.

No próximo vídeo, prepararemos esse ambiente de trabalho de forma direta: conectaremos ao MySQL, veremos como restaurar a base apresentada, acessaremos a base do projeto e deixaremos tudo pronto para iniciar as análises da Suprema Shop com mais segurança.

Obrigado, um abraço e até o próximo vídeo.

Sobre o curso MySQL para Análise de Dados: consultas, métricas e perguntas de negócio

O curso MySQL para Análise de Dados: consultas, métricas e perguntas de negócio possui 323 minutos de vídeos, em um total de 68 atividades. Gostou? Conheça nossos outros cursos de Bancos de Dados & SQL em Dados, ou leia nossos artigos de Dados.

Matricule-se e comece a estudar com a gente hoje! Conheça outros tópicos abordados durante o curso:

• Do SQLite ao MySQL no projeto de análise
• Primeira exploração da base de dados
• Construindo métricas com SQL
• Cruzando informações com JOINs
• Organizando análises com subqueries e CTEs
• Consultas reutilizáveis e entrega da análise