consistentes e legíveis.

O primeiro cuidado do analista deve ser preservar a base original. Antes de fazer qualquer alteração, é recomendável criar uma cópia do arquivo. Essa prática evita perdas e permite voltar ao ponto inicial caso alguma correção seja feita de maneira inadequada. Em ambientes profissionais, também é importante registrar quais mudanças foram realizadas: quais colunas foram renomeadas, quais dados foram excluídos, quais valores foram corrigidos e quais critérios foram usados.

Depois disso, o analista deve fazer uma leitura geral da base. Essa leitura inicial funciona como uma inspeção. Ele observa quantas linhas e colunas existem, quais são os nomes dos campos, que tipos de dados aparecem, se há datas, números, textos, códigos, categorias e identificadores. Também verifica se existem colunas vazias, linhas duplicadas, informações estranhas ou registros claramente incorretos.

Um exemplo simples ajuda a entender. Imagine uma planilha de vendas com as colunas: data da venda, nome do cliente, cidade, produto, categoria, quantidade, valor unitário e forma de pagamento. Antes de somar as vendas, o analista deve verificar se a data está em formato correto, se a quantidade é numérica, se o valor unitário está registrado como moeda, se a cidade está padronizada e se a categoria do produto faz sentido. Se essa conferência não for feita, os cálculos podem sair distorcidos.

Um dos problemas mais comuns em bases de dados são os valores ausentes. Eles aparecem quando uma célula está vazia ou quando uma informação não foi preenchida. Nem sempre um campo vazio significa erro, mas sempre exige atenção. Em uma tabela de clientes, a ausência do telefone pode dificultar contato. Em uma base de vendas, a ausência do valor do pedido pode impedir o cálculo do faturamento. Em uma planilha de alunos, a falta da nota pode alterar a média geral da turma.

O tratamento de valores ausentes depende do contexto. Em alguns casos, o analista pode preencher a informação buscando outra fonte confiável. Em outros, pode deixar o campo vazio e apenas sinalizar a ausência. Também pode excluir linhas quando a falta de informação inviabiliza totalmente a análise, mas essa decisão deve ser tomada com cuidado. Excluir dados sem critério pode gerar distorções. Se muitos registros forem removidos, a base talvez deixe de representar a realidade analisada.

Outro problema frequente são os registros duplicados. Uma duplicidade acontece quando a mesma informação aparece repetida

de acontece quando a mesma informação aparece repetida de forma indevida. Em uma lista de alunos, o mesmo estudante pode ter sido cadastrado duas vezes. Em uma base de pedidos, a mesma venda pode aparecer duplicada por erro de importação. Em uma planilha de clientes, uma pessoa pode aparecer com pequenas variações no nome. A AWS inclui a identificação e remoção de informações duplicadas entre as principais etapas da limpeza de dados.

Nem toda repetição, porém, é erro. Se um cliente fez três compras diferentes, ele deve aparecer três vezes em uma base de vendas. Se um aluno cursou três módulos, pode haver três registros relacionados ao mesmo estudante. Por isso, o analista não deve simplesmente remover tudo que se repete. Ele precisa entender o que cada linha representa. A pergunta correta é: esta repetição é esperada ou é uma cópia indevida?

A padronização também é uma parte central da preparação dos dados. Ela consiste em deixar informações semelhantes escritas da mesma forma. Cidades, estados, produtos, categorias, formas de pagamento e status precisam seguir um padrão. Por exemplo, se uma base registra “Minas Gerais”, “MG” e “M.G.”, o ideal é escolher um formato e aplicá-lo a todos os registros, conforme a necessidade da análise.

A padronização de datas merece atenção especial. Datas podem aparecer como “10/05/2026”, “2026-05-10”, “10 maio 2026” ou até como texto. Se o sistema ou à planilha não reconhecer esses valores como datas, o analista não conseguirá ordenar corretamente, filtrar períodos ou criar gráficos de evolução. Em análises por mês, trimestre ou ano, o formato da data precisa estar bem definido.

Os números também precisam ser conferidos. Em bases brasileiras, é comum encontrar valores com vírgula decimal, como “59,90”. Em alguns sistemas, o padrão pode usar ponto decimal, como “59.90”. Se esses formatos forem misturados, a ferramenta pode interpretar alguns valores como texto, e não como número. Isso prejudica somas, médias e percentuais. O mesmo cuidado vale para porcentagens, quantidades, notas e valores monetários.

Outro ponto importante é a consistência entre colunas. Uma base pode ter uma coluna de “quantidade” e outra de “valor total”. Se a quantidade é 2 e o valor unitário é R$ 50,00, o valor total esperado seria R$ 100,00. Quando os números não fecham, pode existir erro de cálculo, desconto não registrado ou problema no preenchimento. O analista precisa investigar antes de concluir.

Além de limpar, muitas vezes é necessário

transformar os dados. Transformar significa criar novas colunas ou reorganizar informações para facilitar a análise. A partir de uma coluna de data, por exemplo, é possível criar uma coluna de mês, ano ou dia da semana. A partir de quantidade e valor unitário, é possível criar o faturamento. A partir de uma data prevista e uma data real de entrega, é possível criar uma coluna indicando se houve atraso.

Essas transformações ajudam a responder perguntas de negócio. Se uma empresa quer saber qual mês vendeu mais, a coluna de mês será útil. Se deseja comparar desempenho por vendedor, precisa que o nome do vendedor esteja padronizado. Se quer acompanhar atrasos, precisa calcular a diferença entre prazos. A preparação, portanto, não é apenas uma correção técnica; ela organiza os dados para que eles conversem com a pergunta da análise.

Ferramentas como Excel, Google Planilhas, Power Query e Power BI podem ajudar bastante nessa etapa. O Power Query, por exemplo, possui recursos para alterar tipos de dados, renomear objetos, dinamizar dados e criar perfis de colunas, permitindo verificar quais campos possuem informações úteis para análises mais profundas. Para iniciantes, o mais importante não é decorar todos os botões da ferramenta, mas entender a lógica por trás das ações.

Um bom analista iniciante deve criar uma rotina de verificação. Primeiro, observa a estrutura da base. Depois, identifica valores ausentes. Em seguida, verifica duplicidades, formatos, categorias e inconsistências. Só então começa a calcular indicadores. Essa sequência reduz erros e torna a análise mais segura. Pular essa etapa é como construir uma casa sem verificar o terreno.

Também é importante saber que a limpeza de dados exige decisões. Nem sempre haverá uma resposta única. Ao encontrar um campo vazio, o analista precisa decidir se preenche, mantém, exclui ou sinaliza. Ao encontrar uma categoria estranha, precisa verificar se é erro ou se representa uma informação válida. Ao encontrar um valor muito alto ou muito baixo, precisa investigar se é um dado real ou uma digitação equivocada.

Esses valores muito diferentes do restante são chamados, muitas vezes, de outliers ou pontos fora do padrão. Eles podem ser erros, mas também podem representar acontecimentos reais. Em uma loja, uma venda muito alta pode ser um erro de digitação, mas também pode ser uma compra corporativa. Em uma escola, uma nota muito baixa pode indicar erro de lançamento, mas também pode refletir uma dificuldade real

do restante são chamados, muitas vezes, de outliers ou pontos fora do padrão. Eles podem ser erros, mas também podem representar acontecimentos reais. Em uma loja, uma venda muito alta pode ser um erro de digitação, mas também pode ser uma compra corporativa. Em uma escola, uma nota muito baixa pode indicar erro de lançamento, mas também pode refletir uma dificuldade real do aluno. O analista não deve apagar esses dados automaticamente. Deve investigar.

A documentação é outro hábito essencial. Sempre que a base for alterada, o ideal é manter um registro simples: o que foi corrigido, por qual motivo e com qual critério. Isso facilita a revisão do trabalho e aumenta a confiança de quem vai receber o relatório. Se alguém perguntar por que determinada linha foi removida ou por que uma categoria foi unificada, o analista terá uma resposta clara.

A preparação dos dados também envolve cuidado ético. Muitas bases contêm informações pessoais, como nome, telefone, endereço, e-mail, CPF, matrícula, histórico de compras ou desempenho escolar. O analista deve usar apenas os dados necessários para a finalidade da análise e evitar exposição individual quando não for indispensável. Em muitos relatórios, é melhor apresentar informações agrupadas, como totais por cidade, médias por turma ou percentuais por categoria.

Um erro comum entre iniciantes é alterar a base sem compreender o impacto da mudança. Por exemplo, substituir todos os campos vazios por zero pode parecer uma solução rápida, mas pode distorcer os resultados. Uma nota vazia não significa necessariamente nota zero. Um valor de venda vazio não significa venda gratuita. Um campo sem data não significa que o evento não aconteceu. Cada ausência precisa ser interpretada de acordo com o contexto.

Outro erro comum é confiar demais na aparência da planilha. Uma tabela pode parecer organizada visualmente, com colunas alinhadas e cores bem escolhidas, mas ainda assim conter problemas. O que define a qualidade da base não é sua aparência, mas sua consistência, completude e utilidade para responder à pergunta proposta. O analista deve olhar além da estética.

Também é comum que iniciantes tentem corrigir tudo manualmente sem criar padrões. Em bases pequenas, isso pode funcionar por algum tempo. Mas, conforme o volume cresce, a falta de método se torna um problema. Por isso, é importante criar regras simples: escolher um padrão de escrita para categorias, definir o formato de datas, separar colunas que misturam

informações e usar validações sempre que possível.

Um exemplo prático é uma coluna chamada “cliente/cidade”, preenchida com valores como “Maria - Juiz de Fora” ou “João - Belo Horizonte”. Essa coluna mistura duas informações diferentes: nome do cliente e cidade. Para analisar vendas por cidade, o ideal é separar esses dados em colunas distintas. Quanto mais clara for a estrutura da base, mais fácil será analisar.

Outro exemplo é uma coluna de “status” com valores como “entregue”, “Entrega feita”, “ok”, “finalizado” e “concluído”. Talvez todos signifiquem a mesma coisa, mas aparecem de formas diferentes. Se o analista não padronizar, os filtros e contagens ficarão confusos. Uma boa preparação transforma esses registros em categorias consistentes, como “Entregue”, “Pendente”, “Cancelado” e “Atrasado”.

Ao final da limpeza, a base deve estar mais simples, coerente e pronta para análise. Isso não significa que ela será perfeita. Dados reais sempre podem ter limitações. O importante é que o analista saiba quais problemas foram encontrados, quais foram corrigidos e quais ainda podem influenciar os resultados. Uma análise honesta reconhece suas limitações.

A limpeza e a preparação dos dados são, portanto, uma etapa de responsabilidade. Elas protegem a qualidade da análise e evitam conclusões precipitadas. Quando o analista dedica tempo a essa fase, ele reduz erros, melhora os indicadores e aumenta a confiança nas decisões que serão tomadas a partir dos dados.

Para quem está começando, a principal lição desta aula é simples: antes de analisar, organize. Antes de criar gráficos, confira. Antes de concluir, questione a base. Um bom relatório nasce de dados bem-preparados. E dados bem-preparados dependem de atenção, método e cuidado.

Atividade de fixação

Imagine que você recebeu uma planilha de vendas com as seguintes colunas: data da venda, nome do cliente, cidade, produto, categoria, quantidade, valor unitário, valor total e forma de pagamento. Ao observar a base, você percebe que algumas datas estão em formatos diferentes, há cidades escritas com abreviações, alguns produtos aparecem com nomes variados, existem campos vazios em valor total e alguns pedidos parecem duplicados.

Sua tarefa é criar um plano de limpeza em cinco etapas. Primeiro, indique como você preservaria a base original. Depois, explique como verificaria os campos vazios. Em seguida, mostre como padronizaria cidades, produtos e categorias. Depois, descreva como identificaria duplicidades.

Por fim, escreva quais cuidados tomaria antes de excluir ou alterar qualquer informação.

O objetivo da atividade não é apenas “corrigir a planilha”, mas desenvolver o olhar do analista. Cada mudança precisa ter motivo, critério e registro.

Referências bibliográficas

AMAZON WEB SERVICES. O que é a preparação de dados? AWS.

AMAZON WEB SERVICES. O que é limpeza de dados? AWS.

IBM. O que é limpeza de dados? IBM Think.

MICROSOFT. Limpar, transformar e carregar dados no Power BI. Microsoft Learn.

PANDAS. Working with missing data. Pandas Documentation.

Aula 5 — Análise exploratória de dados

A análise exploratória de dados é uma das etapas mais importantes na formação de um analista. Depois de entender o problema, conhecer a base e realizar a limpeza inicial, chega o momento de explorar os dados com mais atenção. Explorar, nesse contexto, significa observar, comparar, calcular, filtrar, agrupar e procurar padrões que ajudem a compreender melhor a realidade representada na base. A IBM define a análise exploratória de dados como uma prática usada para investigar conjuntos de dados, resumir suas principais características e descobrir padrões, anomalias, hipóteses e suposições que precisam ser verificadas.

Em outras palavras, a análise exploratória é o momento em que o analista começa a “conversar” com os dados. Ele olha para a base e faz perguntas simples, mas muito importantes: quais valores aparecem com mais frequência? Qual é o maior e o menor resultado? Existe algum número muito diferente dos demais? Há meses com comportamento fora do padrão? Alguma categoria se destaca? Existem registros estranhos? A base parece coerente com o problema que queremos investigar?

Essa etapa não deve ser vista como algo mecânico. Embora envolva cálculos, tabelas e gráficos, a análise exploratória depende muito do olhar crítico do analista. Dois profissionais podem olhar para a mesma planilha e perceber coisas diferentes, dependendo das perguntas que fazem. Por isso, o iniciante precisa desenvolver o hábito de observar os dados com curiosidade e responsabilidade. O objetivo não é confirmar uma opinião anterior, mas permitir que os dados ajudem a revelar caminhos de investigação.

Imagine uma planilha de vendas de uma pequena loja. Depois da limpeza inicial, o analista pode começar calculando o faturamento total, a quantidade de pedidos, o ticket médio, os produtos mais vendidos e os meses com maior movimento. Esses primeiros cálculos ajudam a formar uma visão geral.

uma planilha de vendas de uma pequena loja. Depois da limpeza inicial, o analista pode começar calculando o faturamento total, a quantidade de pedidos, o ticket médio, os produtos mais vendidos e os meses com maior movimento. Esses primeiros cálculos ajudam a formar uma visão geral. Mas a análise não para aí. O analista pode comparar vendas por categoria, observar diferenças entre vendedores, verificar formas de pagamento mais usadas e analisar se determinados produtos vendem melhor em certos períodos.

A análise exploratória costuma começar com medidas simples. Entre elas estão soma, média, mediana, mínimo, máximo, frequência e percentual. A soma mostra o total de um valor, como faturamento ou quantidade vendida. A média apresenta um valor aproximado de referência, como o gasto médio por pedido. A mediana indica o valor central de um conjunto, sendo útil quando existem números muito altos ou muito baixos que podem distorcer a média. O mínimo e o máximo ajudam a identificar limites. A frequência mostra quantas vezes uma categoria aparece. O percentual permite comparar partes em relação ao todo.

Um exemplo ajuda a entender. Suponha que uma empresa tenha cinco pedidos nos seguintes valores: R$ 50,00, R$ 60,00, R$ 70,00, R$ 80,00 e R$ 1.000,00. A média será puxada para cima pelo pedido de R$ 1.000,00. Nesse caso, a mediana, que é R$ 70,00, talvez represente melhor o comportamento típico das compras. Esse exemplo mostra que o analista não deve usar um número automaticamente. Ele precisa pensar sobre o que aquele cálculo realmente representa.

A frequência é especialmente útil quando trabalhamos com dados categóricos. Em uma base de atendimento, por exemplo, o analista pode contar quantos chamados foram classificados como “dúvida”, “reclamação”, “solicitação”, “cancelamento” ou “elogio”. Em uma escola, pode contar alunos por turma, status de matrícula ou motivo de desistência. Em uma loja, pode contar vendas por categoria, cidade ou forma de pagamento. A documentação do Pandas, biblioteca usada em Python para análise de dados, apresenta recursos como contagem de valores e agrupamentos, que são muito usados para resumir frequências e calcular resultados por grupos em bases tabulares.

Agrupar dados é uma das ações mais comuns na análise exploratória. Em vez de olhar linha por linha, o analista reúne registros por alguma característica. Pode agrupar vendas por mês, alunos por curso, atendimentos por canal, pedidos por estado ou produtos por categoria. Esse

agrupamento facilita a comparação e permite perceber comportamentos que não aparecem quando os dados estão espalhados.

Por exemplo, uma empresa pode olhar apenas o faturamento total e concluir que o mês foi bom. Mas, ao agrupar por categoria, talvez descubra que apenas uma linha de produtos sustentou o resultado, enquanto outras tiveram queda. Uma escola pode observar uma média geral satisfatória, mas, ao agrupar por turma, perceber que uma turma específica apresenta dificuldade. Um setor de atendimento pode ter tempo médio aceitável, mas, ao separar por canal, perceber que o WhatsApp está muito mais lento do que o e-mail.

A análise exploratória também ajuda a encontrar valores fora do padrão. Esses valores, muitas vezes chamados de outliers, são registros muito diferentes dos demais. Eles podem ser erros ou situações reais. Uma venda de R$ 100.000,00 em uma loja que normalmente vende pedidos de R$ 100,00 pode ser erro de digitação, mas também pode ser uma venda corporativa. Uma nota zero em uma avaliação pode indicar ausência, erro no lançamento ou dificuldade real do aluno. Um tempo de atendimento muito alto pode apontar um problema específico ou um registro esquecido aberto no sistema.

O analista iniciante deve tomar cuidado para não apagar valores fora do padrão sem investigar. O correto é primeiro verificar o contexto. Aquele valor faz sentido? Há outros registros parecidos? Existe alguma observação na base? O número pode ser confirmado em outra fonte? Se for erro, deve ser corrigido ou sinalizado. Se for real, deve ser considerado na análise, talvez com explicação. A Databricks destaca que a análise exploratória usa métodos estatísticos e visualizações para entender o conjunto de dados, identificar problemas e avaliar sua prontidão para análises posteriores.

Outro ponto essencial é a comparação ao longo do tempo. Muitas bases possuem datas, e datas permitem observar evolução. O analista pode comparar dias, semanas, meses, trimestres ou anos. Em vendas, isso ajuda a identificar sazonalidade, promoções bem-sucedidas ou quedas inesperadas. Na educação, permite acompanhar frequência, desempenho ou evasão ao longo do curso. No atendimento, mostra períodos de maior demanda. Em logística, revela atrasos concentrados em determinadas épocas.

Mas comparar períodos exige cuidado. Janeiro pode ter comportamento diferente de dezembro. Uma semana com feriado pode ter menos vendas ou menos atendimentos. Uma campanha promocional pode aumentar pedidos

temporariamente. Uma turma pode ter queda de desempenho em uma avaliação mais difícil. Por isso, o analista precisa sempre perguntar: estou comparando períodos equivalentes? Existe algum evento externo que possa explicar a diferença? A mudança é realmente significativa ou apenas uma oscilação normal?

A visualização de dados entra como uma grande aliada nessa etapa. Gráficos simples ajudam a enxergar padrões que uma tabela extensa pode esconder. Um gráfico de linha pode mostrar crescimento ou queda ao longo dos meses. Um gráfico de barras pode comparar categorias. Um gráfico de colunas pode destacar diferenças entre produtos. Uma tabela resumida pode organizar os principais indicadores. O Microsoft Learn apresenta a análise de dados e o Power BI como recursos voltados à transformação de dados em relatórios e painéis que apoiam decisões orientadas por dados.

No entanto, o gráfico não deve ser criado apenas para enfeitar o relatório. Ele precisa responder a uma pergunta. Se a pergunta envolve evolução no tempo, um gráfico de linha pode ser adequado. Se envolve comparação entre categorias, barras ou colunas costumam funcionar melhor. Se o objetivo é mostrar um número principal, como faturamento total ou taxa de atraso, um cartão de indicador pode ser mais claro. O analista deve escolher a visualização de acordo com a mensagem que deseja transmitir.

Um erro comum é usar muitos gráficos ao mesmo tempo. O iniciante, empolgado com a ferramenta, pode criar gráficos de todos os tipos, mesmo quando eles não ajudam na interpretação. Isso deixa o relatório confuso. Uma boa análise exploratória deve começar com simplicidade: poucos gráficos, bem escolhidos, com títulos claros e informações relevantes. O foco não está na quantidade de visualizações, mas na qualidade da leitura.

Também é importante lembrar que a análise exploratória não entrega, necessariamente, uma conclusão definitiva. Muitas vezes, ela levanta hipóteses. Se os dados mostram que as reclamações aumentaram em determinado mês, isso indica que algo pode ter acontecido, mas ainda será necessário investigar a causa. Se uma categoria teve queda nas vendas, o analista pode suspeitar de falta de estoque, preço alto ou menor divulgação, mas precisa buscar evidências adicionais. A análise exploratória abre caminhos; ela não deve ser usada para conclusões apressadas.

Pense em uma escola que deseja entender por que alguns alunos não concluem um curso. A análise exploratória pode mostrar que a desistência é

maior após determinado módulo. Isso é um achado importante. Mas ele não prova, sozinho, que o conteúdo daquele módulo é o único motivo da evasão. Talvez o módulo seja mais difícil, talvez coincida com avaliações, talvez os alunos tenham menos acompanhamento nesse período ou talvez haja problemas de comunicação. O papel do analista é apresentar o padrão observado e sugerir novas investigações.

Outro cuidado é não analisar apenas médias. A média resume, mas também pode esconder diferenças. Uma turma pode ter média 7,0, mas isso não mostra se todos os alunos estão próximos dessa nota ou se metade está muito bem e metade está com muita dificuldade. Uma empresa pode ter ticket médio de R$ 120,00, mas talvez a maior parte dos clientes compre valores baixos e poucos clientes façam compras muito altas. Por isso, sempre que possível, o analista deve observar também distribuição, mediana, faixas de valores e concentração dos dados.

A distribuição mostra como os valores estão espalhados. Em uma análise de notas, por exemplo, é possível verificar se a maioria está entre 6 e 8, se há muitos alunos abaixo da média ou se existem notas muito altas e muito baixas. Em vendas, é possível observar se os pedidos se concentram em valores pequenos ou se há grande variação. Em atendimento, a distribuição do tempo de resposta pode revelar se a maior parte dos casos é resolvida rapidamente, mas alguns ficam parados por muito tempo.

A análise por percentual também é muito útil. Números absolutos podem enganar quando os grupos têm tamanhos diferentes. Imagine duas turmas: a Turma A teve 10 desistências e a Turma B teve 5 desistências. À primeira vista, a Turma A parece pior. Mas, se a Turma A tinha 200 alunos e a Turma B tinha 20, a interpretação muda completamente. A Turma A teve 5% de desistência, enquanto a Turma B teve 25%. O percentual permite comparar de forma mais justa.

Da mesma forma, uma loja pode vender mais em uma cidade simplesmente porque tem mais clientes ali. Para entender o desempenho real, pode ser necessário calcular vendas por cliente, ticket médio por região ou percentual de crescimento. O analista precisa escolher medidas que tornem a comparação equilibrada.

Na prática, a análise exploratória pode seguir uma sequência simples. Primeiro, o analista observa a estrutura da base: número de linhas, colunas e tipos de dados. Depois, verifica se há valores ausentes, duplicidades e dados fora do padrão. Em seguida, calcula medidas gerais, como totais, médias e

frequências. Depois, agrupa os dados por categorias importantes. Por fim, cria gráficos simples para visualizar padrões e registra hipóteses que precisam ser investigadas.

Essa sequência pode ser aplicada em diferentes áreas. Em vendas, o analista pode explorar faturamento por mês, produto, categoria e vendedor. Em educação, pode analisar notas, frequência, conclusão e evasão por turma. Em recursos humanos, pode observar admissões, desligamentos, absenteísmo e treinamentos. Em atendimento, pode verificar volume de chamados, tempo de resposta, motivos de contato e satisfação. Em estoque, pode acompanhar produtos parados, itens mais vendidos e rupturas.

Para o iniciante, é importante aprender a fazer perguntas durante toda a análise. O que mais aparece na base? O que menos aparece? O que mudou ao longo do tempo? Quais grupos se comportam de forma diferente? Há valores estranhos? O resultado confirma ou contradiz a expectativa inicial? Que informação ainda falta para explicar melhor o fenômeno? Essas perguntas desenvolvem o pensamento analítico.

A análise exploratória também exige humildade. Nem sempre os dados vão mostrar aquilo que se esperava. Às vezes, a hipótese inicial está errada. Uma empresa pode acreditar que as vendas caíram por causa do preço, mas os dados podem mostrar que o problema principal foi falta de estoque. Uma escola pode acreditar que a evasão acontece por dificuldade no conteúdo, mas os dados podem indicar abandono logo no início, antes das avaliações. Um atendimento pode culpar o volume de chamados, mas a análise pode revelar gargalo em um canal específico.

Quando isso acontece, o analista precisa respeitar os dados. Seu papel não é defender uma opinião, mas ajudar a compreender a situação com base em evidências. Ao mesmo tempo, deve lembrar que dados não explicam tudo sozinhos. Eles precisam ser interpretados junto com o conhecimento das pessoas que vivem aquela realidade. Por isso, uma boa análise exploratória muitas vezes gera conversas com gestores, professores, vendedores, atendentes ou equipes técnicas.

A comunicação dos achados deve ser clara. Em vez de dizer apenas “houve variação na métrica de conversão”, o analista pode explicar: “a proporção de visitantes que realizaram compra caiu em maio, principalmente no canal de redes sociais”. Em vez de afirmar “há outliers na distribuição”, pode dizer: “existem alguns pedidos com valor muito acima do padrão, e eles precisam ser verificados antes de calcularmos conclusões finais”.

comunicação dos achados deve ser clara. Em vez de dizer apenas “houve variação na métrica de conversão”, o analista pode explicar: “a proporção de visitantes que realizaram compra caiu em maio, principalmente no canal de redes sociais”. Em vez de afirmar “há outliers na distribuição”, pode dizer: “existem alguns pedidos com valor muito acima do padrão, e eles precisam ser verificados antes de calcularmos conclusões finais”. Uma linguagem simples não empobrece a análise; pelo contrário, torna o resultado mais útil.

Ao final desta aula, o aluno deve compreender que a análise exploratória é uma etapa de descoberta. Ela ajuda a conhecer a base, identificar padrões, perceber problemas, levantar hipóteses e preparar o caminho para análises mais profundas. Não se trata apenas de fazer contas, mas de desenvolver um olhar investigativo. O analista observa, compara, questiona e interpreta.

A principal lição é que os dados precisam ser explorados antes de serem usados para decisões. Uma base pode esconder tendências, erros, oportunidades e riscos. Quando o analista aprende a investigar com método e cuidado, ele transforma uma planilha comum em uma fonte de aprendizado. É assim que a análise exploratória cumpre seu papel: aproximar os dados da realidade e preparar decisões mais conscientes.

Atividade de fixação

Imagine que você recebeu uma planilha de vendas com as seguintes colunas: data da venda, produto, categoria, quantidade vendida, valor unitário, valor total, vendedor, cidade e forma de pagamento.

Sua tarefa é fazer um plano de análise exploratória. Primeiro, indique cinco perguntas que poderiam ser feitas a essa base. Depois, escolha quais medidas seriam úteis para respondê-las, como soma, média, mediana, frequência ou percentual. Em seguida, indique três agrupamentos possíveis, como vendas por mês, por categoria ou por cidade. Por fim, escolha dois gráficos adequados e explique por que eles ajudariam na interpretação.

O objetivo da atividade não é chegar a uma resposta única, mas praticar o raciocínio do analista. Antes de concluir, é preciso observar, comparar e questionar.

Referências bibliográficas

IBM. O que é análise exploratória de dados? IBM Think.

DATABRICKS. Análise exploratória de dados: ferramentas e técnicas.

MICROSOFT. Introdução à análise de dados da Microsoft. Microsoft Learn.

PANDAS. Documentação oficial: DataFrame value_counts.

PANDAS. Documentação oficial: DataFrame groupby.

Aula 6 — Introdução a SQL e bases relacionais

Depois de aprender a limpar, organizar e explorar dados, chega um momento importante na formação do analista: entender onde muitos dados ficam armazenados nas empresas. No começo, é comum trabalhar com planilhas, porque elas são simples, visuais e acessíveis. Porém, em organizações maiores, os dados geralmente não ficam todos em uma única tabela. Eles costumam estar distribuídos em bancos de dados, separados por assunto, como clientes, pedidos, produtos, pagamentos, matrículas, atendimentos, avaliações ou entregas.

É aí que entra o banco de dados relacional. De forma simples, um banco de dados relacional organiza informações em tabelas formadas por linhas e colunas. Cada tabela guarda um tipo de informação, e essas tabelas podem se relacionar entre si por meio de campos de ligação, como código do cliente, número do pedido, matrícula do aluno ou código do produto. A IBM explica que bancos de dados relacionais organizam dados em linhas e colunas que, juntas, formam tabelas.

Para entender melhor, imagine uma pequena loja virtual. Em vez de manter tudo em uma única planilha enorme, o sistema pode ter uma tabela de clientes, uma tabela de produtos, uma tabela de pedidos e uma tabela de pagamentos. A tabela de clientes guarda nome, cidade e contato. A tabela de produtos guarda nome, categoria e preço. A tabela de pedidos registra quando uma compra foi feita e qual cliente realizou aquela compra. A tabela de pagamentos informa se o pedido foi pago no cartão, PIX ou boleto. Separar os dados dessa forma evita repetição excessiva e facilita a organização.

Essa separação também ajuda a manter os dados mais consistentes. Se o endereço de um cliente muda, por exemplo, a empresa não precisa alterar essa informação em todas as compras que ele já fez. Basta atualizar o cadastro do cliente. Os pedidos continuam ligados a ele por meio de um identificador, como o código do cliente. Esse identificador funciona como uma ponte entre as tabelas.

Na análise de dados, compreender essa estrutura é muito importante. O analista precisa saber que uma pergunta simples pode exigir informações de várias tabelas. Se a pergunta for “quais produtos foram mais comprados por clientes de Minas Gerais?”, talvez seja necessário cruzar a tabela de clientes, a tabela de pedidos e a tabela de produtos. Se a pergunta for “qual forma de pagamento gera maior faturamento?”, será preciso relacionar pedidos e pagamentos. Se a pergunta for “quais alunos têm maior risco de evasão?”, talvez seja

necessário cruzar a tabela de clientes, a tabela de pedidos e a tabela de produtos. Se a pergunta for “qual forma de pagamento gera maior faturamento?”, será preciso relacionar pedidos e pagamentos. Se a pergunta for “quais alunos têm maior risco de evasão?”, talvez seja necessário cruzar dados de matrícula, frequência, notas e acesso às aulas.

Para conversar com esses bancos de dados, usa-se uma linguagem chamada SQL, sigla para Structured Query Language, ou Linguagem de Consulta Estruturada. O SQL permite consultar, filtrar, organizar, agrupar e combinar dados armazenados em bancos relacionais. A IBM descreve o SQL como uma linguagem usada para armazenar, consultar e manipular informações em bancos de dados relacionais.

É importante deixar claro que, neste curso introdutório, o objetivo não é formar um programador avançado em SQL. A proposta é que o aluno iniciante compreenda a lógica básica das consultas. Um analista de dados não precisa decorar todos os comandos de uma vez, mas deve entender como os dados são buscados, filtrados e combinados. Essa compreensão já melhora muito sua capacidade de dialogar com equipes técnicas, interpretar bases e solicitar informações corretamente.

O comando mais conhecido do SQL é o SELECT. Ele é usado para consultar dados. A documentação da Microsoft explica que a instrução SELECT recupera linhas do banco de dados e permite escolher uma ou várias colunas de uma ou mais tabelas. Em termos simples, é como dizer ao banco: “mostre para mim estas informações”.

Por exemplo, se existe uma tabela chamada clientes, uma consulta poderia pedir apenas o nome e a cidade de cada cliente. Se existe uma tabela chamada vendas, a consulta poderia pedir a data da venda, o produto vendido e o valor total. A ideia é selecionar apenas o que interessa para a análise, em vez de trazer todos os dados de uma vez.

O SELECT pode ser comparado ao ato de escolher colunas em uma planilha. Em uma planilha grande, talvez o analista não precise visualizar todas as colunas. Ele pode precisar apenas de data, produto, quantidade e valor. No banco de dados, o raciocínio é parecido: a consulta deve trazer as colunas necessárias para responder à pergunta.

Outro comando essencial é o WHERE, usado para filtrar registros. Se o SELECT escolhe o que será exibido, o WHERE define quais linhas entram no resultado. Por exemplo, em vez de consultar todas as vendas, o analista pode consultar apenas as vendas de janeiro, apenas os clientes de uma cidade ou apenas

os. Se o SELECT escolhe o que será exibido, o WHERE define quais linhas entram no resultado. Por exemplo, em vez de consultar todas as vendas, o analista pode consultar apenas as vendas de janeiro, apenas os clientes de uma cidade ou apenas os pedidos com status “entregue”. Esse filtro torna a análise mais objetiva.

Imagine que uma empresa tem dez anos de vendas registradas. Se o analista quer estudar apenas o último mês, não faz sentido trazer toda a base. Ele pode usar uma condição para limitar os resultados ao período desejado. Da mesma forma, se deseja investigar atrasos, pode filtrar apenas pedidos cuja data de entrega real ultrapassou a data prevista. O filtro ajuda a transformar uma base grande em um recorte mais útil.

Além de selecionar e filtrar, o SQL permite agrupar dados. Para isso, usa-se o GROUP BY. A Microsoft explica que a cláusula GROUP BY divide o resultado de uma consulta em grupos de linhas, geralmente para executar agregações em cada grupo. Em linguagem simples, isso significa reunir registros semelhantes para calcular totais, médias, contagens ou outros indicadores.

Pense em uma tabela de vendas com milhares de linhas. Cada linha representa uma venda. Se o analista quiser saber o faturamento total por mês, ele não precisa olhar venda por venda. Ele pode agrupar os registros pelo mês e somar os valores. Se quiser saber a quantidade de pedidos por cidade, pode agrupar por cidade. Se quiser descobrir o total de alunos por curso, pode agrupar por curso.

O GROUP BY é muito útil porque transforma dados detalhados em resumos. E, na análise de dados, resumir bem é uma habilidade essencial. O gestor geralmente não quer receber uma tabela com milhares de linhas; ele quer saber quais produtos vendem mais, quais regiões têm maior demanda, quais turmas têm maior evasão ou quais canais de atendimento concentram mais solicitações.

Normalmente, o GROUP BY aparece junto com funções de agregação, como COUNT, SUM, AVG, MIN e MAX. A função COUNT conta registros. A função SUM soma valores. A função AVG calcula média. MIN mostra o menor valor e MAX mostra o maior. Com esses recursos, o analista consegue criar muitos indicadores básicos.

Por exemplo, para acompanhar vendas, pode contar o número de pedidos, somar o faturamento, calcular o ticket médio, identificar o menor e o maior valor de compra. Para uma escola, pode contar alunos matriculados, calcular média de notas, verificar quantidade de concluintes e identificar turmas com maior índice de

ausência. Para um atendimento, pode contar chamados por motivo e calcular tempo médio de resposta.

Outro conceito fundamental é o JOIN, usado para unir informações de tabelas diferentes. A Microsoft explica que junções permitem recuperar dados de duas ou mais tabelas com base em relações lógicas entre elas. Esse é um dos pontos mais importantes para o analista, porque muitas perguntas reais exigem cruzamento de dados.

Imagine uma tabela chamada clientes e outra chamada pedidos. A tabela de pedidos talvez não tenha o nome completo do cliente, apenas o código dele. Para saber quais clientes fizeram pedidos, é preciso unir as duas tabelas pelo código do cliente. Da mesma forma, uma tabela de pedidos pode trazer apenas o código do produto. Para descobrir o nome e a categoria do produto, será necessário unir pedidos e produtos pelo código do produto.

Esse cruzamento deve ser feito com muito cuidado. Um erro comum é unir tabelas por campos inadequados. Por exemplo, usar o nome do cliente como ligação pode gerar problemas, porque duas pessoas podem ter nomes iguais, ou o mesmo nome pode estar escrito de formas diferentes. O ideal é usar identificadores únicos, como ID do cliente, código do pedido, matrícula ou código do produto. Esses campos reduzem o risco de confusão.

Outro erro comum é não perceber que o cruzamento pode multiplicar linhas. Se uma tabela tem um cliente e outra tem vários pedidos desse mesmo cliente, a união mostrará uma linha para cada pedido. Isso é correto quando a análise está no nível dos pedidos, mas pode gerar contagem duplicada se o analista estiver tentando contar clientes. Por isso, antes de usar um JOIN, é necessário entender o que cada linha representa em cada tabela.

Para o iniciante, uma boa forma de pensar é perguntar: “qual é a unidade de cada tabela?”. Na tabela de clientes, cada linha representa um cliente. Na tabela de pedidos, cada linha representa um pedido. Na tabela de itens do pedido, cada linha pode representar um produto dentro de um pedido. Na tabela de pagamentos, cada linha pode representar uma transação. Entender essa unidade evita muitos erros.

Vamos pensar em um exemplo prático. Uma empresa quer saber quais categorias de produto geram maior faturamento. Os dados estão em três tabelas: pedidos, itens_pedido e produtos. A tabela de pedidos mostra quando a compra ocorreu. A tabela de itens_pedido informa quais produtos foram comprados e em que quantidade. A tabela de produtos mostra o nome e a categoria de cada

pensar em um exemplo prático. Uma empresa quer saber quais categorias de produto geram maior faturamento. Os dados estão em três tabelas: pedidos, itens_pedido e produtos. A tabela de pedidos mostra quando a compra ocorreu. A tabela de itens_pedido informa quais produtos foram comprados e em que quantidade. A tabela de produtos mostra o nome e a categoria de cada produto. Para responder à pergunta, o analista precisa unir essas tabelas, calcular o valor de venda e agrupar por categoria.

Esse raciocínio mostra que SQL não é apenas uma linguagem técnica. Ele representa uma forma de pensar os dados. O analista aprende a perguntar onde está cada informação, como as tabelas se conectam e qual caminho precisa percorrer para chegar ao indicador desejado.

Também é importante diferenciar o banco de dados da planilha. A planilha é muito útil para estudos iniciais, controles simples e análises menores. Porém, quando o volume de dados cresce ou quando várias pessoas e sistemas precisam acessar as informações ao mesmo tempo, o banco de dados oferece mais organização, segurança e consistência. Bancos relacionais são bastante usados justamente porque permitem armazenar dados estruturados e relacionados de forma organizada.

Isso não significa que a planilha deixa de ser importante. Na rotina do analista, é comum extrair dados do banco e depois trabalhar com eles em planilhas, ferramentas de BI ou linguagens como Python. A diferença é que, ao conhecer SQL, o analista passa a depender menos de relatórios prontos. Ele ganha autonomia para buscar recortes mais específicos e montar suas próprias análises.

Um ponto que merece atenção é a qualidade da consulta. Uma consulta mal escrita pode trazer dados demais, dados de menos ou dados errados. Se o filtro de data estiver incorreto, o período analisado pode mudar. Se a junção entre tabelas for feita com o campo errado, o resultado pode duplicar registros. Se o agrupamento estiver mal planejado, o indicador pode não representar a realidade. Por isso, toda consulta precisa ser testada e conferida.

O analista deve criar o hábito de validar resultados. Se a consulta diz que houve 10 mil pedidos em um mês, esse número faz sentido? Ele bate com relatórios conhecidos? Se o faturamento ficou muito acima do esperado, existe alguma duplicidade? Se uma categoria aparece zerada, será que o filtro excluiu dados indevidamente? A análise responsável não confia cegamente no primeiro resultado; ela verifica.

Também é importante documentar

consultas importantes. Em uma empresa, o mesmo indicador pode ser usado todo mês. Se a consulta que gera esse número não estiver registrada, cada pessoa pode calcular de um jeito. Isso cria divergências. Um analista pode considerar pedidos cancelados, outro pode excluir. Um pode usar data de compra, outro pode usar data de pagamento. A documentação ajuda a manter padrão e transparência.

O SQL também ajuda o analista a entender melhor os dashboards. Muitas ferramentas visuais escondem a complexidade das consultas por trás de botões e menus. Isso é útil, mas pode levar a erros quando o usuário não entende o modelo de dados. Ao aprender noções de SQL, o aluno passa a enxergar o que acontece por trás dos relatórios: tabelas, filtros, relações, agrupamentos e cálculos.

Na prática profissional, o analista nem sempre terá permissão para alterar dados no banco. Muitas vezes, ele terá acesso apenas para consulta. Isso é comum e desejável, especialmente para preservar a segurança das informações. Consultar dados é diferente de modificar dados. Neste curso, o foco está na consulta e interpretação, não em alterações estruturais no banco.

Outro cuidado importante envolve dados pessoais. Bancos de dados podem conter nomes, documentos, e-mails, telefones, endereços, histórico de compras, notas, frequência, informações financeiras ou registros de atendimento. O analista deve consultar apenas os dados necessários para a finalidade da análise e evitar exposição individual quando não for indispensável. Muitas análises podem ser feitas com dados agregados, como totais por cidade, médias por turma ou quantidade por categoria.

Para aprender SQL, o aluno iniciante pode começar com perguntas simples. Primeiro, consultar algumas colunas de uma tabela. Depois, aplicar filtros. Em seguida, contar registros. Depois, agrupar por uma categoria. Por fim, unir duas tabelas. Esse caminho gradual é mais seguro do que tentar aprender comandos complexos de uma só vez. O mais importante é compreender a lógica.

Uma boa sequência de aprendizagem seria: entender tabelas, linhas e colunas; reconhecer chaves e identificadores; praticar SELECT; aplicar WHERE; usar funções de agregação; criar agrupamentos com GROUP BY; e, depois, estudar JOIN. Com essa base, o aluno já consegue interpretar muitas consultas usadas em análises do dia a dia.

Ao final desta aula, o aluno deve compreender que SQL é uma ferramenta poderosa para buscar respostas em bancos de dados relacionais. Ele permite selecionar,

final desta aula, o aluno deve compreender que SQL é uma ferramenta poderosa para buscar respostas em bancos de dados relacionais. Ele permite selecionar, filtrar, agrupar e cruzar informações. Mas seu uso exige cuidado, porque uma consulta mal construída pode gerar conclusões equivocadas. Por isso, o bom analista combina conhecimento técnico, atenção ao contexto e validação dos resultados.

A principal ideia desta aula é que os dados de uma organização formam uma rede. Clientes se relacionam com pedidos, pedidos se relacionam com produtos, produtos se relacionam com categorias, pagamentos se relacionam com compras, alunos se relacionam com matrículas, matrículas se relacionam com cursos. O SQL ajuda o analista a percorrer essa rede com método, buscando as informações certas para responder perguntas reais.

Atividade de fixação

Imagine um banco de dados simples de uma escola com três tabelas. A tabela alunos possui código do aluno, nome e cidade. A tabela matrículas possui código da matrícula, código do aluno, código do curso, data de matrícula e status. A tabela cursos possui código do curso, nome do curso e carga horária.

Agora, responda em forma de texto: quais tabelas seriam necessárias para descobrir quantos alunos estão matriculados em cada curso? Qual campo poderia ligar alunos e matrículas? Qual campo poderia ligar matrículas e cursos? Que cuidado você tomaria para não contar o mesmo aluno duas vezes? Como você filtraria apenas matrículas com status ativo?

Depois, imagine que a coordenação deseja saber quais cursos têm maior número de alunos ativos. Explique quais dados seriam selecionados, quais seriam filtrados e como o agrupamento ajudaria a transformar várias linhas de matrícula em um resumo por curso.

Referências bibliográficas

IBM. O que é um banco de dados relacional? IBM Think.

IBM. O que é linguagem de consulta estruturada, SQL? IBM Think.

IBM. O que é um banco de dados? IBM Think.

MICROSOFT. SELECT — Transact-SQL. Microsoft Learn.

MICROSOFT. Cláusula SELECT — GROUP BY. Microsoft Learn.

MICROSOFT. Junções no SQL Server. Microsoft Learn.

POSTGRESQL. Documentação oficial: SELECT.

Estudo de caso — Módulo 2

A planilha parecia organizada, mas escondia decisões perigosas

A Clínica Sorriso Vivo era uma clínica odontológica de médio porte, localizada em uma cidade bastante movimentada. Todos os dias, a recepção registrava agendamentos, confirmações, faltas, retornos, procedimentos realizados e pagamentos. Durante muito tempo,

esses dados ficaram espalhados em planilhas diferentes: uma para pacientes, outra para consultas, outra para pagamentos e uma quarta para procedimentos.

No fim de um semestre, a direção percebeu um problema: a agenda parecia cheia, mas o faturamento não crescia como esperado. Além disso, os dentistas reclamavam de horários vagos por faltas de pacientes, enquanto a recepção dizia que fazia confirmações todos os dias. A pergunta inicial da diretora foi simples: “Por que estamos trabalhando tanto e faturando menos do que deveríamos?”.

Para ajudar nessa investigação, entrou em cena Rafael, um analista de dados iniciante. Ele já sabia que não poderia começar criando gráficos imediatamente. Antes disso, precisava limpar os dados, explorar a base e entender como as tabelas se relacionavam. Essa postura era importante porque a limpeza de dados envolve identificar e corrigir erros e inconsistências em dados brutos para melhorar sua qualidade antes da análise.

Rafael recebeu quatro arquivos. O primeiro tinha o cadastro dos pacientes. O segundo trazia os agendamentos. O terceiro registrava pagamentos. O quarto listava os procedimentos realizados. À primeira vista, parecia tudo bem: havia colunas, datas, nomes e valores. Mas, ao observar com cuidado, ele encontrou problemas comuns em bases reais.

Na planilha de pacientes, o mesmo nome aparecia de maneiras diferentes: “Ana Paula Souza”, “Ana P. Souza” e “Ana Paula de Souza”. Em alguns casos, havia pacientes com o mesmo telefone, mas nomes escritos de forma diferente. Na tabela de agendamentos, a coluna de status trazia registros como “faltou”, “FALTA”, “não veio”, “ausente” e “no-show”. Na tabela de pagamentos, alguns valores estavam com vírgula decimal, outros com ponto, e alguns campos estavam vazios.

O primeiro erro que Rafael quase cometeu foi tratar cada linha como se fosse confiável. Se ele simplesmente contasse os pacientes, poderia considerar a mesma pessoa mais de uma vez. Se calculasse a taxa de faltas sem padronizar o status, dividiria a mesma situação em categorias diferentes. Se somasse valores sem corrigir o formato numérico, parte dos pagamentos poderia ser ignorada pela ferramenta.

Ele então criou uma cópia dos arquivos originais e começou a preparação. Padronizou os status de atendimento em quatro grupos: “compareceu”, “faltou”, “cancelou” e “remarcou”. Conferiu datas em formato incorreto. Separou registros sem valor de pagamento para análise posterior. Também criou uma coluna de mês, para poder

então criou uma cópia dos arquivos originais e começou a preparação. Padronizou os status de atendimento em quatro grupos: “compareceu”, “faltou”, “cancelou” e “remarcou”. Conferiu datas em formato incorreto. Separou registros sem valor de pagamento para análise posterior. Também criou uma coluna de mês, para poder observar o comportamento ao longo do semestre.

Essa etapa mostrou um aprendizado essencial: limpar dados não é “arrumar a planilha para ficar bonita”. É preparar a base para que ela represente melhor a realidade. Ferramentas como o Power Query, por exemplo, oferecem recursos para alterar tipos de dados, renomear campos, dinamizar informações e criar perfis de colunas, justamente para apoiar a preparação dos dados antes da análise.

Depois da limpeza inicial, Rafael partiu para a análise exploratória. Ele calculou o total de agendamentos por mês, o percentual de faltas, o faturamento mensal, o valor médio por procedimento e os procedimentos mais frequentes. A análise exploratória não tinha o objetivo de provar uma conclusão imediata, mas de procurar padrões, diferenças e pontos estranhos.

Logo apareceu um achado importante. A clínica realmente tinha muitos horários ocupados na agenda, mas cerca de uma parte significativa deles terminava em falta ou remarcação de última hora. O problema não era apenas quantidade de pacientes agendados; era a conversão desses agendamentos em atendimentos realizados.

Outro achado chamou atenção. Os procedimentos preventivos, como avaliação e limpeza, apareciam em grande volume, mas tinham menor valor médio. Já alguns procedimentos de maior valor, como próteses e tratamentos estéticos, tinham menor frequência e maior taxa de cancelamento. Isso ajudou Rafael a entender que a clínica precisava analisar não apenas “quantas consultas” eram feitas, mas também “quais consultas” eram realizadas.

Nesse momento, surgiu outro erro comum: olhar apenas para médias. O valor médio por procedimento parecia razoável, mas escondia diferenças importantes. Alguns procedimentos tinham valor alto e poucos registros; outros tinham valor baixo e muitos registros. Se Rafael apresentasse apenas uma média geral, a direção poderia acreditar que o faturamento estava equilibrado, quando na verdade havia forte dependência de poucos procedimentos mais rentáveis.

Para evitar esse erro, ele separou os dados por categoria de procedimento. Também comparou quantidade, faturamento e taxa de cancelamento. Assim, a análise ficou mais justa. Ele

percebeu que determinados procedimentos exigiam confirmação mais cuidadosa, pois quando eram cancelados geravam grande impacto financeiro.

O terceiro desafio apareceu quando Rafael precisou cruzar as tabelas. A tabela de agendamentos tinha o código do paciente. A tabela de pagamentos tinha o código do atendimento. A tabela de procedimentos tinha o código do procedimento e o código do atendimento. Para responder perguntas mais completas, ele precisava relacionar essas informações. Consultas que acessam várias tabelas ao mesmo tempo são chamadas de consultas com junção, ou joins, pois combinam linhas de uma tabela com linhas de outra a partir de uma condição de ligação.

Aqui, Rafael quase cometeu um erro perigoso: tentou cruzar pacientes pelo nome. Isso poderia gerar confusão, porque nomes podem ser repetidos, abreviados ou escritos de formas diferentes. Ao revisar a estrutura, percebeu que o campo correto era o código do paciente. Para os atendimentos, o campo de ligação era o código do atendimento. Essa escolha reduziu o risco de duplicar registros ou atribuir pagamentos ao paciente errado.

Com as tabelas relacionadas corretamente, ele conseguiu responder perguntas melhores: quais pacientes faltavam mais? Quais procedimentos tinham maior taxa de remarcação? Qual era o faturamento perdido estimado por faltas? Quais dias da semana concentravam mais ausências? Quais horários eram mais vulneráveis?

Ao usar agrupamentos, Rafael resumiu milhares de linhas em indicadores úteis. Em SQL, quando a cláusula GROUP BY é usada, os resultados podem ser combinados em grupos com valores iguais, permitindo calcular agregações como totais, médias e contagens por grupo. Na prática, isso permitiu transformar uma lista extensa de atendimentos em resumos por mês, procedimento, dia da semana e status.

O relatório final não foi uma coleção de gráficos bonitos. Rafael organizou a apresentação como uma história. Primeiro, mostrou o problema: agenda cheia, mas faturamento abaixo do esperado. Depois, explicou os cuidados com os dados: padronização de status, revisão de datas, tratamento de pagamentos vazios e cruzamento por códigos. Em seguida, apresentou os principais achados.

A conclusão foi clara: a clínica tinha três pontos críticos. Primeiro, muitas faltas estavam concentradas em determinados horários. Segundo, procedimentos de maior valor tinham impacto financeiro alto quando eram cancelados. Terceiro, a forma de registrar status na recepção dificultava análises

confiáveis. A recomendação foi criar uma padronização obrigatória no registro dos atendimentos, reforçar confirmação ativa para procedimentos de maior valor e acompanhar semanalmente a taxa de faltas por horário.

A direção percebeu que o maior valor da análise não estava apenas nos números, mas na mudança de postura. Antes, todos diziam que “a agenda estava cheia”. Depois da análise, ficou claro que agenda cheia não significava agenda produtiva. O dado bruto mostrava marcações. A informação organizada mostrou comparecimento, ausência, remarcação e faturamento. O insight mostrou onde agir.

Erros comuns observados no caso e como evitá-los

Erro 1 — Começar pelos gráficos antes de limpar a base.
Rafael poderia ter criado gráficos logo no início, mas eles mostrariam categorias duplicadas, valores incompletos e status inconsistentes. Para evitar esse erro, o analista deve revisar a base antes da visualização, observando campos vazios, duplicidades, datas incorretas e categorias mal preenchidas.

Erro 2 — Acreditar que uma planilha visualmente organizada está correta.
As tabelas tinham boa aparência, mas escondiam problemas de preenchimento. Para evitar esse erro, é preciso verificar a qualidade dos dados, e não apenas sua aparência. Uma base bonita pode conter erros graves.

Erro 3 — Padronizar dados sem preservar o original.
Se Rafael alterasse diretamente os arquivos recebidos, poderia perder informações importantes. Para evitar isso, o ideal é manter uma cópia da base original e registrar as mudanças feitas.

Erro 4 — Tratar campos vazios como zero.
Um pagamento vazio não significa necessariamente pagamento de R$ 0,00. Pode indicar atraso no lançamento, erro de registro ou pagamento ainda não realizado. Para evitar esse erro, campos vazios devem ser investigados antes de qualquer substituição automática.

Erro 5 — Confundir repetição legítima com duplicidade.
Um paciente pode aparecer várias vezes porque realizou várias consultas. Isso não é duplicidade. O erro ocorre quando o mesmo atendimento aparece repetido indevidamente. Para evitar confusão, o analista deve entender o que cada linha representa.

Erro 6 — Usar médias sem observar a distribuição.
O valor médio por procedimento escondia diferenças entre procedimentos simples e procedimentos mais caros. Para evitar esse erro, o analista deve comparar grupos, observar mínimos, máximos, frequências e percentuais.

Erro 7 — Cruzar tabelas por nome em vez de código.
Nomes podem variar ou se repetir. Para

evitar cruzamentos errados, o ideal é usar identificadores únicos, como código do paciente, código do atendimento ou código do produto.

Erro 8 — Concluir causa sem investigação suficiente.
A análise mostrou que determinados horários tinham mais faltas, mas isso não provava imediatamente o motivo. Poderia ser dificuldade de transporte, horário comercial, falha de confirmação ou perfil dos pacientes. Para evitar esse erro, o analista deve apresentar hipóteses e recomendar novas verificações.

Proposta de atividade prática para o aluno

Imagine que você recebeu quatro planilhas de uma clínica: pacientes, agendamentos, procedimentos e pagamentos. Sua tarefa é montar um plano de análise para descobrir por que o faturamento está abaixo do esperado.

Primeiro, descreva quais problemas de limpeza poderiam existir nas planilhas. Depois, indique quais campos deveriam ser padronizados. Em seguida, proponha cinco indicadores para acompanhar o desempenho da clínica, como taxa de faltas, faturamento por procedimento, valor médio por atendimento, cancelamentos por horário e comparecimento por dia da semana.

Depois, explique quais tabelas precisariam ser cruzadas para responder à pergunta: “quais procedimentos geram maior perda financeira quando o paciente falta?”. Por fim, escreva uma recomendação prática para a direção da clínica, com base nos dados analisados.

Fechamento do estudo de caso

O Módulo 2 mostra que o trabalho do analista de dados depende de três atitudes fundamentais: preparar, explorar e relacionar. Preparar significa limpar e organizar os dados antes de confiar neles. Explorar significa observar padrões, diferenças e valores fora do comum. Relacionar significa entender como tabelas diferentes se conectam para responder perguntas mais completas.

O caso da Clínica Sorriso Vivo mostra que uma análise bem conduzida pode mudar a forma como uma organização enxerga seus problemas. A pergunta inicial era sobre faturamento, mas a resposta passou por qualidade dos dados, comportamento da agenda, faltas, tipos de procedimento e cruzamento correto de tabelas. Esse é o papel do analista: transformar bases confusas em entendimento prático, útil e responsável.

Referências bibliográficas

IBM. O que é limpeza de dados? IBM Think.

IBM. Como as métricas de qualidade de dados ajudam a gerar insights. IBM Think.

MICROSOFT. Limpar, transformar e carregar dados no Power BI. Microsoft Learn.

POSTGRESQL. Documentação oficial: SELECT.

POSTGRESQL. Documentação oficial:

Joins Between Tables.

Parte inferior do formulário