Olá! Eu sou Vitorino Villa e quero começar agradecendo por ter escolhido estar aqui comigo nesta nova jornada.
Neste curso de MySQL para análise de dados, com foco em preparação, qualidade e entrega de insights (percepções), nós vamos avançar no uso do MySQL para o trabalho analítico.
Ao longo das aulas, nós vamos trabalhar com situações que fazem parte da rotina de uma pessoa analista de dados.
Nós vamos entender o papel da preparação dos dados antes de entregar uma resposta.
Nós vamos identificar campos úteis, campos problemáticos e campos que podem dificultar uma análise.
Também vamos criar consultas de verificação para validar a base de dados, revisar hipóteses com apoio de inteligência artificial e processar textos, números, arredondamentos, valores financeiros e categorias.
Além disso, vamos trabalhar com datas, períodos de análise, evolução temporal, valores nulos, duplicidades, inconsistências e regras de negócio.
Mais adiante, veremos como manipular JSON no MySQL, criar campos derivados, simplificar uma estrutura para Business Intelligence (Inteligência de Negócios) e detectar sinais de consultas lentas. Ao final do curso, trataremos de documentação, resultados e recomendações, pois uma boa análise não termina no SELECT, termina quando o resultado pode ser entendido, revisado e utilizado para tomar uma decisão.
Esse conhecimento é muito importante para a carreira da pessoa analista de dados. No mercado de trabalho, não basta saber escrever uma consulta que retorne um número. É preciso saber preparar os dados, validar a regra, identificar riscos, explicar os limites e entregar uma resposta confiável para o negócio.
Esse é o tipo de cuidado que diferencia quem apenas executa comandos de quem realmente ajuda a empresa a tomar melhores decisões.
Por isso, fico muito feliz em começar este curso com você. Espero que você aproveite cada aula, pratique bastante e observe cada exemplo pensando em como ele aparece no mundo real. Agradeço novamente por estar aqui, nos vemos no próximo vídeo.
O papel da preparação de dados no trabalho da pessoa analista. No curso anterior, utilizamos SQL para explorar a base Suprema Shop, criamos métricas, cruzamos tabelas e respondemos a perguntas de negócio. Agora, neste curso, a conversa muda um pouco. A pergunta deixa de ser apenas: qual é o resultado? E passa a ser também: podemos confiar nesse resultado?
Esse é um ponto muito importante no trabalho de análise de dados, porque uma consulta pode estar sintaticamente correta, executar sem erro, devolver uma tabela adequada e, ainda assim, produzir uma resposta incorreta se os dados de entrada forem problemáticos. Imagine que a área de logística pergunte: quantas entregas estão atrasadas? Parece uma pergunta simples, mas, antes de responder, precisamos entender se todas as entregas têm data de envio, se todas têm data de entrega, se os estados fazem sentido e se há pedidos cancelados incluídos na contagem. Se ignorarmos essas validações, corremos o risco de transformar dados inconsistentes da base em conclusões de negócio. Quando isso ocorre, o problema não fica apenas no SQL. Ele aparece nos relatórios, nos dashboards (painéis), nas reuniões e até na tomada de decisões.
Por isso, preparar dados reduz esse risco. Preparar dados é observar a base antes da entrega, antes da resposta final. É identificar quais são os campos importantes, quais estão incompletos, valores fora do padrão, duplicidades e regras que precisam ser respeitadas. Essa etapa não é burocrática; é uma etapa de proteção da análise. Ela nos ajuda a entender o que a base realmente permite afirmar.
Um ponto importante: preparação de dados não significa modificar tudo. Muitas vezes, o primeiro trabalho é apenas investigar. Por exemplo, encontrar nulos, comparar totais, buscar formatos diferentes para a mesma informação e entender se um valor estranho é um erro, uma exceção válida ou até uma nova regra de negócio. Antes de corrigir qualquer coisa, precisamos enxergar o problema com clareza.
Na prática, essa etapa fica entre a demanda do negócio e a entrega da análise. A área de negócio traz a pergunta, exploramos a base, depois preparamos e validamos os dados necessários para poder responder. E então, somente então, calculamos a métrica, montamos a consulta final e entregamos o resultado. Sem essa camada intermediária, a análise fica frágil. Com ela, a resposta ganha contexto, limites e confiança.
No caso de Suprema Shop, isso é ainda mais importante, porque a base foi construída com situações parecidas às que aparecem em empresas reais. Vamos encontrar clientes com dados repetidos ou suspeitos, produtos sem categoria, entregas sem data final e pedidos que talvez não batam exatamente com a soma dos itens. Todos esses problemas não estão na base para atrapalhar; estão lá para aprendermos a investigar.
Estamos no MySQL Workbench, observando a base Suprema Shop Analytics. Recordamos que tanto a instalação do MySQL quanto a do MySQL Workbench e a recuperação dessa base de dados, Suprema Shop Analytics, foram realizadas no curso anterior de MySQL para análise de dados. Portanto, se essa base não estiver disponível, é necessário voltar ao curso anterior para verificar a criação do ambiente e a recuperação da base de dados.
Com a base disponível, vamos analisar e verificar se há anomalias. Vamos criar um script (roteiro de comandos) para escrever alguns comandos SQL e executar o USE para selecionar a base. Observação: no código, o schema aparece como supremashop_analytics (sem espaços, com sublinhado). No MySQL Workbench, se o nome da base aparecer em negrito, significa que já estamos conectados a ela.
Para selecionar a base, execute:
USE supremashop_analytics;
A ideia aqui não é resolver os problemas da base, e sim levantar sinais de alerta. Vamos começar verificando, por exemplo, quantas entregas não têm data de entrega. Para isso, consideramos a tabela entregas e aplicamos um COUNT com a condição WHERE data_entrega IS NULL para contar os registros sem data.
Primeiro, uma checagem simples com um alias genérico:
SELECT COUNT(*) as registros
FROM entregas
WHERE data_entrega IS NULL;
Ao executar essa verificação, identificamos, por exemplo, cerca de duas mil entregas sem data.
Para tornar o resultado mais claro, incluímos uma constante literal com o texto “Entregas sem datas” para indicar o tipo de verificação e padronizamos os aliases: a coluna do tipo de checagem se chama checagem, e o total fica em num_registros.
SELECT 'Entregas sem datas' as checagem,
COUNT(*) as num_registros
FROM entregas
WHERE data_entrega IS NULL;
Também podemos querer verificar produtos sem categoria. Para isso, copiamos a estrutura da consulta anterior e combinamos os resultados com UNION para consolidar diferentes verificações em uma única saída. Ao utilizar UNION, precisamos remover o ponto e vírgula ; da consulta anterior antes de adicionar a próxima verificação, mantendo apenas um ; ao final do conjunto.
SELECT 'Entregas sem datas' as checagem,
COUNT(*) as num_registros
FROM entregas
WHERE data_entrega IS NULL
UNION
SELECT 'Produtos sem categorias' as checagem,
COUNT(*) as num_registros
FROM produtos
WHERE id_categoria IS NULL;
Dessa forma, levantamos alertas sobre entregas sem data, produtos sem categoria e outras inconsistências que precisam ser compreendidas e validadas antes de calcular métricas, montar a consulta final e entregar o resultado. Essa abordagem dá contexto e confiança à análise e evita que dados problemáticos se transformem em conclusões equivocadas.
Para ampliar o diagnóstico, podemos incluir clientes com datas suspeitas. Por exemplo, vamos observar a tabela de clientes e filtrar casos em que a data de nascimento é nula ou em que a data de nascimento seja 1900-01-01. São possíveis anomalias que podemos encontrar. Em seguida, unificamos tudo no mesmo relatório:
SELECT 'Entregas sem datas' as checagem,
COUNT(*) as num_registros
FROM entregas
WHERE data_entrega IS NULL
UNION
SELECT 'Produtos sem categorias' as checagem,
COUNT(*) as num_registros
FROM produtos
WHERE id_categoria IS NULL
UNION
SELECT 'Clientes com datas suspeitas' as checagem,
COUNT(*) as num_registros
FROM clientes
WHERE data_nascimento IS NULL OR data_nascimento = '1900-01-01';
Para obter os produtos sem categoria, precisamos fazer um COUNT. Vamos alterar um nome, definindo o alias num_registros, e repeti-lo onde for necessário. Em seguida, vamos à tabela de produtos e filtrar onde o identificador de categoria seja nulo. Ao observarmos a tabela de produtos, vemos o identificador de categoria; se estiver vazio, significa que o produto não tem categoria.
Lembramos do curso anterior: precisamos conhecer a base. Temos o esquema com as tabelas e as conexões entre elas. Assim, conhecemos os campos e realizamos as buscas de forma consciente. Vamos executar essa consulta e verificar os resultados.
Obtemos 2.000 entregas sem datas e 50 produtos sem categoria. Podemos aplicar outro UNION e incluir uma seleção de clientes com datas suspeitas. Ao executar a consulta completa, obtemos 300 clientes com datas suspeitas.
Agora, podemos investigar se há clientes com e-mails repetidos. A ideia é selecionar o campo email da tabela clientes, agrupar por email com GROUP BY e aplicar HAVING COUNT(*) > 1. Isso nos mostra a lista de e-mails repetidos.
Primeiro, listamos apenas os e-mails repetidos:
SELECT email
FROM clientes
GROUP BY email
HAVING COUNT(*) > 1;
Se quisermos ver também quantas vezes cada e-mail aparece, incluímos a contagem:
SELECT email, COUNT(*)
FROM clientes
GROUP BY email
HAVING COUNT(*) > 1;
No entanto, nosso objetivo não é saber quantas vezes cada e-mail aparece, mas apenas listar os e-mails repetidos e, sobre essa lista, aplicar uma subconsulta. Vamos rotular essa verificação como checagem e aplicar um COUNT para contar o número total de e-mails que estão repetidos. Também atribuiremos um alias à tabela resultante, chamando-a de emails.
SELECT 'E-mails repetidos' as checagem,
COUNT(*) as num_registros
FROM
(SELECT email FROM clientes
GROUP BY email
HAVING COUNT(*) > 1) AS emails;
Nossa camada de frontend (camada de interface) estará baseada nessa consulta. Ao executarmos a consulta completa, percebemos a necessidade de incluir um UNION para consolidar tudo em um relatório com várias linhas. Com isso, temos um diagnóstico: 2.000 entregas sem datas, 50 produtos sem categoria, 300 clientes com datas suspeitas e 100 e-mails repetidos.
Para consolidar todas as checagens em um único resultado, unimos as quatro verificações:
SELECT 'Entregas sem datas' as checagem,
COUNT(*) as num_registros
FROM entregas
WHERE data_entrega IS NULL
UNION
SELECT 'Produtos sem categorias' as checagem,
COUNT(*) as num_registros
FROM produtos
WHERE id_categoria IS NULL
UNION
SELECT 'Clientes com datas suspeitas' as checagem,
COUNT(*) as num_registros
FROM clientes
WHERE data_nascimento IS NULL OR data_nascimento = '1900-01-01'
UNION
SELECT 'E-mails repetidos' as checagem,
COUNT(*) as num_registros
FROM
(SELECT email FROM clientes
GROUP BY email
HAVING COUNT(*) > 1) AS emails;
É importante destacar que esse resultado não constitui a entrega final de uma análise. Trata-se de um diagnóstico inicial, um tipo de consulta que auxilia a pessoa analista a decidir quais cuidados tomar antes de calcular uma métrica ou montar um dashboard (painel). Por exemplo, se quisermos analisar prazo de entrega, precisamos definir como tratar as entregas sem data final. Se quisermos analisar vendas por categoria, precisamos decidir como tratar os produtos que estão sem categoria. Além disso, se quisermos contar clientes únicos, precisamos observar com atenção as duplicidades que estão ocorrendo.
Esse é o papel da preparação: revelar as condições da base antes de apresentarmos a resposta como verdade. A preparação de dados muda a postura da pessoa analista. Em vez de simplesmente perguntar qual consulta responderá à pergunta, passamos a perguntar quais dados sustentarão a resposta que vamos entregar à pessoa usuária. Isso nos obriga a olhar para a origem da métrica, para os filtros que serão aplicados e para os registros que ficarão de fora por apresentarem problemas. Assim, a análise deixa de ser apenas uma extração e passa a ser uma entrega confiável, na qual as pessoas usuárias poderão confiar no número apresentado.
Então, pessoa estudante deste curso, trabalharemos essa preparação em várias frentes. Vamos identificar na base campos úteis, campos prescindíveis e campos problemáticos. Criaremos consultas de verificação. Lidaremos com textos, números, valores financeiros, datas, JSONs e também campos derivados. Abordaremos mudanças controladas, desempenho básico e documentação da análise. Tudo isso tem o mesmo foco: preparar dados para responder melhor à pessoa usuária.
Vamos encerrar este vídeo por aqui. No próximo vídeo, daremos um passo mais concreto: vamos analisar a base Suprema Shop e separar campos úteis, campos que exigem cuidado e campos que talvez não auxiliem na análise. Adotaremos um hábito simples, porém muito poderoso para o trabalho em análise de dados: antes de escrever uma consulta extensa, precisamos entender quais colunas realmente importam para a pergunta. É assim que a preparação começa a se tornar um método de trabalho.
Agradecemos. Até o próximo vídeo.
Identificando campos úteis, descartáveis e problemáticos
No vídeo anterior, vimos que preparar dados é uma etapa de proteção para a pessoa analista, pois, antes de calcular uma métrica ou montar um dashboard (painel), precisamos entender se os dados que sustentam a resposta fazem sentido.
Agora, vamos dar um passo mais prático. Vamos observar as colunas da base de dados e separar os campos em três grupos: campos úteis, campos descartáveis (para uma pergunta específica) e campos problemáticos. Essa separação parece simples, mas muda bastante a forma como vamos trabalhar, porque nem toda coluna disponível ajuda na análise, e nem toda coluna importante está pronta para uso direto.
Quando uma área de negócio faz uma pergunta, a base pode ter dezenas ou centenas de colunas. O papel da pessoa analista de dados não é usar todas as colunas existentes, e sim identificar quais campos ajudam a responder aquela pergunta. Se a pergunta for, por exemplo, sobre faturamento por canal, provavelmente vamos olhar para a data do pedido, valor total, status e canal de venda. Se a pergunta for sobre logística, vamos observar datas de envio, datas de entrega e centros de distribuição. Portanto, o campo correto depende de cada pergunta.
Os campos úteis são aqueles que entram diretamente no raciocínio da análise. Eles podem:
Esses campos são a matéria-prima do cálculo da métrica.
Já os campos descartáveis não são campos inúteis, e essa diferença é muito importante. Um campo pode ser descartável para um análise e essencial para outro. Por exemplo, se quisermos medir vendas por canal, talvez o nome do cliente não seja necessário. Mas, se quisermos revisar duplicidade de registros, o nome do cliente passa a ser relevante. Assim, a classificação não é fixa; ela depende da pergunta que está sendo respondida.
Os campos problemáticos exigem cuidado antes do uso. São campos que podem ter valores nulos, formatos diferentes para a mesma informação, valores suspeitos, datas estranhas, categorias ausentes ou registros duplicados. Isso não significa que o campo deva ser ignorado; significa que precisa ser validado antes de entrar em uma resposta final. Um campo problemático pode ser muito útil, mas precisa de tratamento ou, no mínimo, de alguma regra clara.
No contexto da Suprema Shop, temos bons exemplos disso. O campo valor total em pedidos é muito útil para análises de faturamento. O campo canal de venda ajuda a comparar site, aplicativo ou vendas em loja física. Já o campo data de entrega em entregas é essencial para o prazo logístico, mas, se algumas entregas não tiverem data final, esse campo se torna um ponto de atenção. Esse é o tipo de leitura que precisamos desenvolver.
Vamos consultar os metadados de algumas tabelas importantes. Uma maneira simples é visualizar o esquema de forma gráfica, conforme a figura exibida na tela. Porém, muitas vezes precisamos ver também a estrutura da tabela por meio de comandos do MySQL, pois os metadados são informações que mostram a estrutura da base de dados: nome da tabela, nome da coluna, tipo de dado, se o campo aceita ou não nulos, entre outros. E, em muitos casos, não conseguimos ver tudo isso no diagrama visual.
Vamos voltar ao MySQL Workbench, abrir um novo script e garantir que estamos olhando para a nossa base Suprema Shop Analytics. Em seguida, vamos executar a seguinte consulta conceitual:
TABLE_NAME, COLUMN_NAME, DATA_TYPE e IS_NULLABLE da tabela information_schema.columns.TABLE_SCHEMA = o nome da nossa base de dados (no ambiente físico, usamos o schema supremashop_analytics).clientes, pedidos, produtos e entregas.TABLE_NAME e por ORDINAL_POSITION.Começamos listando exatamente os quatro campos do catálogo de colunas que nos interessam:
SELECT TABLE_NAME,
COLUMN_NAME,
DATA_TYPE,
IS_NULLABLE
Em seguida, acrescentamos a origem desses metadados, que é o catálogo information_schema.COLUMNS:
SELECT TABLE_NAME,
COLUMN_NAME,
DATA_TYPE,
IS_NULLABLE
FROM information_schema.COLUMNS
Agora garantimos que a consulta está olhando apenas para o nosso schema da Suprema Shop (no banco, nomeado como supremashop_analytics):
SELECT TABLE_NAME,
COLUMN_NAME,
DATA_TYPE,
IS_NULLABLE
FROM information_schema.COLUMNS
WHERE TABLE_SCHEMA = 'supremashop_analytics'
Restringimos às tabelas que queremos observar. Na primeira tentativa, acabamos escrevendo pedido (no singular), o que fará a consulta ignorar a tabela correta:
SELECT TABLE_NAME,
COLUMN_NAME,
DATA_TYPE,
IS_NULLABLE
FROM information_schema.COLUMNS
WHERE TABLE_SCHEMA = 'supremashop_analytics'
AND TABLE_NAME IN ('clientes', 'pedido', 'produtos', 'entregas')
Para facilitar a leitura, adicionamos a ordenação por tabela e pela posição ordinal das colunas:
SELECT TABLE_NAME,
COLUMN_NAME,
DATA_TYPE,
IS_NULLABLE
FROM information_schema.COLUMNS
WHERE TABLE_SCHEMA = 'supremashop_analytics'
AND TABLE_NAME IN ('clientes', 'pedido', 'produtos', 'entregas')
ORDER BY TABLE_NAME, ORDINAL_POSITION;
Percebemos que, inicialmente, não havíamos incluído a tabela pedidos no filtro. Corrigimos o nome e executamos novamente. Agora, sim, temos a tabela pedidos listada:
SELECT TABLE_NAME,
COLUMN_NAME,
DATA_TYPE,
IS_NULLABLE
FROM information_schema.COLUMNS
WHERE TABLE_SCHEMA = 'supremashop_analytics'
AND TABLE_NAME IN ('clientes', 'pedidos', 'produtos', 'entregas')
ORDER BY TABLE_NAME, ORDINAL_POSITION;
Vamos verificar se a consulta está correta. Obtivemos os resultados com as informações específicas para cada uma dessas tabelas.
Vamos observar primeiro a tabela pedidos. Nela, encontramos campos muito úteis para análises de vendas. Por exemplo, a data do pedido é essencial. Se quisermos observar vendas, precisamos analisar por data.
O valor total nos dará o faturamento. O status indica o estado da venda. O tipo de venda e o canal em que a venda foi realizada (canal de venda) também são campos importantes.
Os campos idPedido e idCliente, por serem identificadores, não são relevantes para a análise direta. Eles servem para estabelecer conexão com outras tabelas, por exemplo, com a tabela de clientes.
Na tabela de clientes, os campos úteis podem ser a cidade e o estado, a data de cadastro e, possivelmente, a data de nascimento. O campo sexo pode ser utilizado para analisarmos vendas entre homens, mulheres e outras identidades de gênero. O e-mail não é particularmente útil neste contexto. O nome do cliente só será necessário se quisermos um nível de detalhamento maior.
Na tabela de produtos, observamos o nome do produto e o preço base. O campo idCategoria é importante para visualizarmos os dados por categoria.
Na tabela de entregas, a data de envio e a data de entrega são os dois campos essenciais para analisarmos prazos.
Agora, vamos observar o conceito de campos nullable (aceitam nulo). Isso indica que alguns campos podem ficar vazios. Precisamos identificar, nas tabelas mencionadas, quais campos aceitam nulos e verificar quantas linhas existem nessas tabelas em que esses campos estão nulos.
Por exemplo, em clientes, o campo que aceita nulo é a data de nascimento. Embora aceite nulo, ter clientes com data de nascimento nula não é adequado, portanto precisamos verificar se existem clientes com data de nascimento nula.
No caso de entregas, quem aceita nulo é a data de entrega. Precisamos verificar se há entregas com data de entrega nula.
No caso de pedidos, não há campos que aceitam nulo.
Em produtos, o identificador de categoria (idCategoria) pode aceitar nulos.
Vamos aproveitar a consulta que elaboramos no vídeo anterior e adaptá-la. No caso de entregas, o importante é verificar se a data de entrega é nula, pois, conforme observamos na tabela de entregas, é o único campo que aceita nulo. Em produtos, precisamos verificar o idCategoria. Na tabela de clientes, devemos verificar se a data de nascimento é nula e, adicionalmente, checar valores suspeitos, como datas de nascimento iguais a 1901-01-01.
Também podemos adotar uma regra baseada na idade máxima plausível. Supondo que estejamos em 2026, não esperamos ter clientes com mais de 120 anos. Assim, podemos verificar se há datas de nascimento menores ou iguais a 1906-01-01 (120 anos antes de 2026). Se encontrarmos clientes com mais de 120 anos, trata-se de um valor suspeito. Pode existir? Pode, mas é algo muito incomum.
Quanto a duplicidades, não vamos trabalhar com isso agora, pois neste momento estamos focados em verificar resultados que possuam campos nulos.
Com isso em mente, montamos uma consulta de verificação consolidada para contar, em um único retorno, os potenciais problemas que mapeamos: entregas sem data de entrega, produtos sem categoria e clientes com datas de nascimento nulas ou suspeitas (<= 1906-01-01).
SELECT 'Entregas sem datas' AS checagem,
COUNT(*) AS num_registros
FROM entregas
WHERE data_entrega IS NULL
UNION
SELECT 'Produtos sem categorias' AS checagem,
COUNT(*) AS num_registros
FROM produtos
WHERE id_categoria IS NULL
UNION
SELECT 'Clientes com datas suspeitas' AS checagem,
COUNT(*) AS num_registros
FROM clientes
WHERE data_nascimento IS NULL
OR data_nascimento <= '1906-01-01';
Vamos executar a consulta para verificar se há algum erro. O resultado mostra três frentes que podem ser úteis, mas exigem cuidado:
Dessa forma, já identificamos, na base, campos que representam risco de comprometer os resultados das análises.
Uma boa prática é montar um pequeno mapa de campos antes de escrevermos a consulta principal: especificar quais campos identificam as entidades, quais medem algo, quais segmentam os resultados e quais podem apresentar problemas. Essa leitura prévia evita que as consultas cresçam sem direção e retornem resultados incoerentes.
Também é importante documentar as decisões: se um campo foi descartado, por que foi descartado; se um campo nulo foi filtrado, qual foi a regra; se um valor suspeito foi mantido, se foi uma escolha consciente. Essas respostas ajudam quem revisará a análise posteriormente e também nos ajudam quando precisarmos retomar a consulta dias ou meses depois.
Vamos encerrar o vídeo por aqui e, no próximo, vamos transformar essa lógica em consultas de verificação. Em vez de olhar apenas uma coluna por vez, vamos construir consultas que chequem volumes, nulos, duplicidades e inconsistências básicas. Esse tipo de consulta criará uma primeira camada de confiança na base e é uma etapa fundamental antes de entregarmos qualquer indicador.
Agradeço, pessoal! Um abraço, até o próximo vídeo.
O curso MySQL para Análise de Dados: preparação, qualidade e entrega de insights possui 354 minutos de vídeos, em um total de 71 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:
O Plano Plus evoluiu: agora com Luri para impulsionar sua carreira com os melhores cursos e acesso à maior comunidade tech.
2 anos de Alura
Matricule-se no plano PLUS 24 e garanta:
Jornada de estudos progressiva que te guia desde os fundamentos até a atuação prática. Você acompanha sua evolução, entende os próximos passos e se aprofunda nos conteúdos com quem é referência no mercado.
Back-end, Dados, Front-end, DevOps, Mobile, Gestão & Negócios, UX & Design, Cibersegurança, Cloud, Inteligência Artificial
Formações com mais de 1500 cursos atualizados e novos lançamentos semanais, em Programação, Inteligência Artificial, Front-end, UX & Design, Data Science, Mobile, DevOps e Inovação & Gestão.
A cada curso ou formação concluído, um novo certificado para turbinar seu currículo e LinkedIn.
Acesso à inteligência artificial da Alura.
No Discord, você participa de eventos exclusivos, pode tirar dúvidas em estudos colaborativos e ainda conta com mentorias em grupo com especialistas de diversas áreas.
Catálogo de tecnologia para quem é da área de Marketing
Faça parte da maior comunidade Dev do país e crie conexões com mais de 120 mil pessoas no Discord.
Acesso ilimitado ao catálogo de Imersões da Alura para praticar conhecimentos em diferentes áreas.
Explore um universo de possibilidades na palma da sua mão. Baixe as aulas para assistir offline, onde e quando quiser.
20% de desconto na Pós Tech
Luri Vision chegou no Plano Pro: a IA da Alura que enxerga suas dúvidas, acelera seu aprendizado e conta também com o Alura Língua que prepara você para competir no mercado internacional.
2 anos de Alura
Todos os benefícios do PLUS 24 e mais vantagens exclusivas:
Acesso ao catálogo da Casa do Código e leitura dentro da plataforma
Chat, busca, exercícios abertos, revisão de aula, geração de legenda para certificado.
Envie imagens para a Luri e ela te ajuda a solucionar problemas, identificar erros, esclarecer gráficos, analisar design e muito mais.
Aprenda um novo idioma e expanda seus horizontes profissionais. Cursos de Inglês, Espanhol e Inglês para Devs, 100% focado em tecnologia.
Para quem quer atingir seus objetivos mais rápido: Luri Vision ilimitado, vagas de emprego exclusivas e mentorias para acelerar cada etapa da jornada.
2 anos de Alura
Todos os benefícios do PRO 24 e mais vantagens exclusivas:
Catálogo de tecnologia para quem é da área de Marketing
Envie imagens para a Luri e ela te ajuda a solucionar problemas, identificar erros, esclarecer gráficos, analisar design e muito mais de forma ilimitada.
Conecte-se ao mercado com mentoria individual personalizada, vagas exclusivas e networking estratégico que impulsionam sua carreira tech para o próximo nível.
