Imagine uma cena de ensino: você quer descobrir quais alunos ainda não entregaram o trabalho e pede ao AI que escreva um trecho de SQL. O programa roda sem problemas e uma lista bem organizada aparece na tela.
Nenhum erro, os nomes das colunas batem. Você já se prepara para enviar o lembrete, mas percebe que um aluno que não tem nenhum registro de entrega não aparece no resultado.
O problema pode estar escondido na forma de junção. A consulta manteve apenas os registros que conseguem se corresponder nas duas tabelas; aquele "que ainda não tem registro" foi excluído desde o início.
Esse tipo de erro é silencioso. O banco de dados executou exatamente a operação que você escreveu; o que realmente precisa ser verificado é se essas operações expressam aquilo que você queria dizer.
A disciplina DSAI2202 Database Principles (Princípios de Banco de Dados) da Universidade Politécnica de Hong Kong aborda modelagem de dados, SQL, gestão de transações e segurança de bancos de dados, entre outros conteúdos. Entrar no curso com perguntas do tipo "por que falta uma pessoa no resultado" dá aos conceitos abstratos pistas concretas a investigar. Descrição oficial da disciplina na PolyU
Ele não está na lista porque não há registro, ou porque não existe essa pessoa?
Vamos reduzir o exemplo do início.
Na tabela de alunos há três pessoas: Ah Ming, Xiao Xin e Ah Jie. Na tabela de entregas há registros apenas de Ah Ming e Xiao Xin; Ah Jie ainda não entregou.
Se primeiro juntarmos as duas tabelas com uma junção interna e depois procurarmos os alunos "que não entregaram", Ah Jie já não estará no resultado intermediário. Por mais cuidadoso que seja o filtro seguinte, ele não consegue recuperar alguém que foi excluído antes.
Uma abordagem é partir da lista completa de alunos, manter cada estudante e depois verificar se existe um registro de entrega correspondente. A junção à esquerda (left join) ajuda a expressar essa relação, mas ainda é preciso continuar verificando o escopo do trabalho, os campos de correspondência e as condições de filtro posteriores. Trocar a palavra de junção não garante automaticamente que a resposta esteja correta. Tutorial oficial de junções do PostgreSQL
No Lab 7: raciocínio entre relações do EvoClass, os estudantes comparam a lista de matrículas com a lista da plataforma de aprendizagem e observam como diferentes formas de junção mantêm ou excluem registros.
O que vale a pena praticar aqui é explicar com clareza, antes de escrever a consulta: quem cada linha do resultado representa? Quem precisa obrigatoriamente ser mantido? O que significa não encontrar um registro correspondente?
Com essas poucas frases, o SQL passa a ter um alvo com o qual pode ser comparado.
Antes da consulta, decida como registrar o mundo
Continuemos com essa lista. Um aluno pode se matricular em várias disciplinas, uma disciplina pode ter vários trabalhos e cada trabalho pode permitir várias entregas.
Se tudo isso for colocado em uma única tabela grande, nomes, títulos de disciplinas e informações de professores podem se repetir. Ao alterar um desses pontos, outros lugares ainda guardam o valor antigo; ao contar alunos, a mesma pessoa pode ser contada mais de uma vez.
Nesse momento, o problema já ocorreu antes da consulta: o que exatamente cada linha da tabela está registrando?
O Lab 2: do mundo real às tabelas do PostgreSQL parte da redundância e dos problemas de atualização de tabelas planas para chegar ao projeto de bancos de dados relacionais, e o Lab 9: normalização de formulários de inscrição avança para a normalização.
Um pequeno exercício no papel pode ser um bom começo: escreva "aluno", "disciplina" e "relação de matrícula" em três folhas separadas e depois explique como elas se conectam. Se um aluno muda de curso, onde é preciso alterar? Se uma nova disciplina ainda não tem ninguém matriculado, é possível registrá-la antes?
Essas perguntas submetem a estrutura de dados ao teste das mudanças do dia a dia. Se as tabelas foram separadas de forma adequada depende de sua capacidade de expressar as relações com clareza e de manter a consistência no momento das alterações.
Voltando à consulta do início, também fica mais fácil julgar: as linhas extras diante de você são alunos diferentes ou várias entregas do mesmo aluno?
Uma instrução correta, mas a operação inteira pode ter ficado pela metade
Depois de obter o resultado, o sistema muitas vezes ainda precisa alterar dados.
Por exemplo, um aluno pede transferência de turma e precisa ser removido da turma antiga e incluído na nova. Se a primeira etapa já foi salva e a segunda falhar por algum motivo, o aluno pode ficar temporariamente sem pertencer a nenhuma turma. Vistas separadamente, as duas instruções podem estar corretas; vistas em conjunto, o sistema deixou um estado incompleto.
As transações oferecem uma ferramenta básica para esse tipo de problema: organizar etapas que precisam ser concluídas em conjunto, para que sejam confirmadas como um todo ou desfeitas em caso de falha. Como delimitar esse "todo" continua exigindo compreender a tarefa concreta. Tutorial oficial de transações do PostgreSQL
O experimento de transações e concorrência do Lab 10 leva o tema adiante, para os limites das transações e o controle de concorrência, tendo como pano de fundo o tratamento de vagas em um balcão de matrícula, e observa o que acontece quando duas sessões operam ao mesmo tempo.
No exercício, é possível provocar deliberadamente uma falha entre as duas etapas e depois verificar o que o banco de dados realmente deixou registrado. Em seguida, faça duas sessões operarem simultaneamente sobre os mesmos dados e observe se os passos que antes funcionavam sem problemas continuam válidos.
Assim, um experimento ganha outra dimensão: além de ver como as coisas dão certo, é preciso saber como elas falham.
Depois de pedir ao AI que escreva o SQL, o que cabe a você verificar?
Com as experiências anteriores, o foco muda quando você olha para a consulta proposta pelo AI.
A lista do início, que deixava alguém de fora, pode ser verificada com três registros fictícios de alunos; o problema de contagem duplicada pode ser checado incluindo um aluno com duas entregas; na operação de troca de turma, pode-se verificar o estado dos dados quando há falha no meio do processo.
Esses pequenos exemplos fornecem base para o julgamento. Uma explicação fluente não substitui a conferência do resultado.
O Lab 12: verificação de SQL gerado por AI incorpora a revisão ao exercício: ela roda? Responde à pergunta? O que pode quebrar? Quem tem permissão para executá-la?
Os estudantes podem seguir uma tarefa concreta com perguntas sucessivas: quais registros esta consulta mantém? Quantas linhas a alteração afeta? Se a expectativa é mudar apenas uma pessoa, como detectar antes da execução que o escopo foi escrito errado? E o fato de a ferramenta ter permissão de alteração significa que a tarefa atual permite que ela o faça?
Para quem está começando a lidar com bancos de dados relacionais ou já começou a usar o AI para escrever consultas, o portal do curso DSAI2202 no EvoClass oferece um caminho para aprofundar a partir das operações básicas. Vale preparar um conjunto pequeno de dados que você mesmo consiga conferir à mão e entrar no exercício já com um resultado esperado.
Na próxima vez que uma lista bem organizada aparecer na tela, procure primeiro a pessoa mais fácil de ser esquecida.
Quando você consegue explicar por que ela aparece e por que está ausente, começa a saber se essa resposta merece confiança.
A posicionação da disciplina baseia-se na descrição oficial da PolyU; a apresentação dos laboratórios baseia-se no material didático atual do EvoClass. Os links das aulas no texto apontam para materiais de estudo em chinês simplificado. As situações de lista, entrega de trabalhos e troca de turma são exemplos didáticos construídos para ajudar a compreender os conceitos, e não casos de estudantes nem registros de resultados de uso.