Como montar um banco de dados para TCC sem perder o semestre
A maioria dos alunos de graduação que chega no estágio de projeto final subestima a parte de dados. Eles pensam em modelos ER bonitos e queries elegantes, e só começam a se preocupar com dados reais quando já estão na reta final. Isso dá errado. Eu vi isso acontecer em pelo menos cinco turmas diferentes. Quando eu falo banco de dados graduação, não estou falando só da matéria de BD1 do segundo período. Estou falando do sistema que você vai construir pra resolver um problema real, com dados sujos, prazos apertados e professor cobrando entrega. A diferença entre quem passa fácil e quem sofre nessa fase é basicamente uma coisa: ter os dados mapeados antes de criar a primeira tabela.
Definindo o escopo do banco de dados graduação
Você precisa decidir o que o banco vai guardar e, mais importante, o que ele não vai guardar. Eu Costumo fazer isso em uma folha de papel mesmo, não no banco. Lista de entidades, lista de atributos, e uma linha riscando o que está fora do escopo. Sem isso, o projeto cresceUntil vira algo que você não consegue entregar no prazo. No meu primeiro projeto de graduação, eu tentei modelar um sistema completo de gestão de uma clínica. Em vez de focar nas entidades principais, eu acabei gastando duas semanas criando tabelas para coisas secundárias como controle de estoque de materiais. Quando cheguei no módulo principal, não tinha tempo nem pra colocar os dados de teste. A solução foi cortar metade das tabelas, voltar pro básico e entregar algo funcional em vez de algo incompleto que parecia bonito no papel.
O conselho aqui é simples: modela só o necessário. Um banco de dados acadêmico bem-feito com quatro ou cinco entidades bem relacionadas vale mais do que um esboço ambicioso que nunca funciona na prática.
A parte que ninguém conta: dados de teste
O maior gargalo não é o modelo, é conseguir dados pra testar. Alunos geralmente tentam inventar dados na mão ou usam geradores online que produzem dados irreais. Isso causa dois problemas sérios. Primeiro, as consultas que funcionam com dados artificiais quebram quando aparecem edge cases reais. Segundo, o professor percepção na hora da defesa quando vê que os dados parecem gerar por uma função randomica. Uma solução prática é usar datasets públicos relevantes pro seu domínio. Pra um sistema de gestão escolar, você pode usar o Censo da Educação Básica do INEP. Pra saúde, o DATASUS disponibiliza dados abertos. Pra varejo, o dataset do Mercadorix ou do Kaggle. O trabalho é limpar e adaptar, mas leva menos tempo do que construir do zero.
Eu tenho um script Python que gera dados sintéticos com realistcs baseado nas estatísticas reais que você extrai de datasets abertos. Ele lê um CSV com informações demográficas e produce registros que mantêm a mesma média, desvio padrão e correlações. O processo leva uns dez minutos pra gerar uns mil registros. Antes eu levava duas tardes inteiros fazendo isso na mão.
Modelagem prática: o que funciona
A estrutura que eu mais vejo dar certo em projetos de graduação é um modelo relacional normalizado até a terceira forma normal, sem exageros. Ninguém precisa de BCNF num TCC. O importante é evitar redundância óbvia e garantir que cada tabela tenha uma chave primária clara. Relacionamentos muitos-para-muitos são onde a maioria erra. A tendência é criar uma tabela intermediária com chave primária composta e esquecer de colocar índices. Num banco pequeno isso não parece problema, mas quando o professor pede pra fazer uma query com join triplo, a consulta trava ou retorna resultados errados por falta de indexação.
Uma dica específica que eu aprendi na hard way: sempre define regras de delete e update nos relacionamentos. ON DELETE CASCADE quando faz sentido, ON DELETE SET NULL pra campos opcionais, e nunca deixe o banco deixar referências órfãs. Eu já perdi horas debugando dados inconsistentes porque esqueci de configurar isso num projeto anterior.
👉 Clique no botão abaixo para saber mais sobre o assunto!
Ferramentas e como começar
PostgreSQL com pgAdmin é a combinação mais usada em faculdades brasileiras e a que menos dor de cabeça dá. MySQL também é comum, mas ele tem comportamento diferente em questões de tipo de dados e validação de constraints que pode te surpreender. SQLite é prático pros primeiros testes, mas não representa a realidade de produção e o professor pode questionar a escolha. pra modelagem visual, o dbdiagram.io ou o MySQL Workbench funcionam. Eu prefiro o dbdiagram porque exporta o SQL diretamente e sincroniza com o banco via CLI. O workflow que eu uso é: modelo no dbdiagram, export pro SQL, executa no PostgreSQL, popula com dados de teste, e depois refina as queries no pgAdmin.
Se o projeto exige integração com aplicação web, usa SQLAlchemy ou Prisma pra ORM. Evita SQL puro em strings concatenadas, isso é erro de principiante que professor nota rápido. Um ORM mal configurado é pior que SQL puro, então configura o N+1 query problem desde o início.
Erros comuns que eu vejo repetidamente
Nome de coluna em português com acento e espaço. Isso funciona tecnicamente mas quebra exportações, ferramentas de migration e qualquer coisa que precise de script automatizado. Usa snake_case sempre. Chave primária do tipo VARCHAR. UUID ou INT AUTO_INCREMENT são muito mais eficientes. Eu já vi aluno usar código de matrícula como PK e quando o sistema precisou suportar reingressos, o banco inteiro precisou de redesign.
Sem índice nas colunas de relacionamento. Cada foreign key deve ter um índice. Sem exceção. Query de seleção com join em tabela grande sem índice é uma das causas mais comuns de projeto que funciona com dez registros e morre com mil. Não fazer backup do esquema. Migrações de banco que você não versiona são um risco real. Se algo quebrar, você perde dias reconstruindo tabelas. Usa migrações do Django, Flyway, ou até scripts SQL numerados num repositório git. Leva cinco minutos a mais e economiza horas.
Performance no contexto acadêmico
Projeto de graduação raramente escala pra milhões de linhas, mas o professor pode testar com volumes maiores pra ver se você entende o básico de indexação e explain analyze. Rodar EXPLAIN nas suas queries mais pesadas e entender o plano de execução é uma habilidade que diferencia um aluno que decorou models de um que entende o que o banco tá fazendo. Um plano de execução mal é obvious quando o Professor pede pra otimizar. Se o Explain mostra um Sequential Scan numa tabela de milhares de linhas numa query que poderia usar índice, você tem trabalho pra fazer. Às vezes um índice composto resolve em segundos. Outras vezes o problema é na ordenação ou no join, e aí a solução é restructuring a query.
Para projetos menores, manter aNormalização evita duplicação e garante integridade. Desnormalizar gera inconsistência e manutenção cara. Só desnormaliza se o profiling mostrar que é realmente necessário, o que é raro num TCC.
O que entregar e como apresentar
No dia da defesa, o banco é o coração do projeto. Você precisa ter o schema documentado, as queries principais funcionando, e dados de teste suficientes pra demonstrar as funcionalidades. Leva um dump do banco no dia, não confie na máquina do professor ou no repositório GitHub que pode estar desatualizado. Um arquivo SQL com create tables, inserts de dados de teste, e views uteis resolve muita dor de cabeça na apresentação. Se o professor pedir pra rodar uma query específica ao vivo, ter esse banco pronto e populado faz toda a diferença entre uma demonstração fluida e um silêncio constrangedor de cinco minutos tentando conectar no servidor.
A estrutura do projeto no GitHub deve ter: migrations ou schema.sql, seed data, queries de exemplo, e um README explicando o modelo e como subir o banco. Isso demonstra profissionalismo e é algo que muitos alunos negligenciam até a última hora. Se o seu projeto envolve API, expõe endpoints que retornam os dados e mostra o banco por trás. Isso deixa claro que você domina tanto a camada de dados quanto a camada de aplicação. Projeto que tem frontend bonito mas banco mal estruturado é fácil de identificar e o professor nota.
