Banco de Dados

Banco de dados é a área que estuda como armazenar, organizar e recuperar dados de forma confiável e eficiente. SQL e o modelo relacional dominam a indústria há mais de 40 anos — e continuam sendo a habilidade técnica mais universalmente cobrada em vagas de tecnologia.

Por que estudar isso?

Todo sistema que você já usou — o app do banco, o sistema acadêmico do IFF, o e-commerce onde você compra — tem um banco de dados no centro. Quando o sistema acadêmico calcula seu coeficiente de rendimento, ele está executando consultas SQL sobre tabelas de matrículas, disciplinas e notas, com transações garantindo que uma matrícula não seja gravada pela metade se o servidor cair no meio do processo. Errar o projeto ou o uso desse banco significa dados corrompidos, sistemas lentos e, em casos reais e famosos, empresas perdendo dinheiro por vender o mesmo assento de avião duas vezes.

Do ponto de vista de carreira, SQL é possivelmente o conhecimento com melhor relação custo-benefício da computação: aparece em vagas de backend, dados, ciência de dados, infraestrutura e até em áreas de negócio. E diferente de frameworks que mudam a cada dois anos, o modelo relacional de 1970 continua sendo a base — o que você aprender aqui não expira.

Trilha de estudo

1. SQL básico e o modelo relacional (iniciante)

Aprenda o que é tabela, linha, coluna, chave primária e chave estrangeira, e domine o SQL de consulta: SELECT, WHERE, ORDER BY, JOIN, GROUP BY e funções de agregação. Pratique todos os dias um pouco — o SQLBolt tem exercícios interativos que dão fluência rápida. Tempo típico: 4 a 6 semanas.

2. Modelagem e normalização (intermediário)

Aprenda a projetar o banco antes de criá-lo: modelo entidade-relacionamento, mapeamento para tabelas e formas normais (1FN, 2FN, 3FN). Pratique modelando sistemas que você conhece: a biblioteca do campus, um sistema de matrículas, um delivery. Este passo tem trilha própria em Modelagem de Dados. Tempo típico: 4 a 6 semanas.

3. Transações, índices e desempenho (intermediário-avançado)

Entenda as propriedades ACID, níveis de isolamento e o que acontece quando duas transações concorrem pelos mesmos dados. Aprenda como índices funcionam (árvores B) e a ler um plano de execução com EXPLAIN para descobrir por que uma consulta está lenta. Instale o PostgreSQL e pratique em uma base com milhões de linhas geradas — desempenho só se aprende com volume. Tempo típico: 6 a 8 semanas.

4. Administração e além do relacional (avançado)

Backup e recuperação, controle de acesso, replicação e noções de bancos não relacionais (documentos, chave-valor) — e principalmente quando cada modelo faz sentido. O roadmap de PostgreSQL DBA organiza bem esse universo. Tempo típico: 8+ semanas, melhor com um projeto real rodando.

Conceitos que você precisa dominar

• Modelo relacional — dados organizados em tabelas (relações) manipuladas por operações de álgebra relacional: seleção, projeção, junção. A elegância está em ser matemática aplicada: toda consulta SQL, por mais complexa, se decompõe nessas operações — e é assim que o SGBD a otimiza por baixo dos panos.
• Chaves primárias e estrangeiras — a chave primária identifica unicamente cada linha; a estrangeira cria o vínculo entre tabelas e é o que o JOIN percorre. Integridade referencial (impedir uma matrícula apontando para um aluno que não existe) depende inteiramente delas.
• JOINs — a operação que reconstrói informação espalhada em várias tabelas. Saber a diferença entre INNER, LEFT e FULL JOIN — e o que acontece com linhas sem correspondência em cada caso — separa quem escreve SQL de quem copia SQL do Stack Overflow.
• Normalização — o processo de eliminar redundância dividindo dados em tabelas menores e bem definidas. Sem ela, o mesmo dado vive em três lugares, alguém atualiza só um, e o banco passa a contar mentiras (as chamadas anomalias de atualização).
• Transações e ACID — atomicidade, consistência, isolamento e durabilidade: a garantia de que operações compostas ou acontecem por inteiro ou não acontecem. É o que impede uma transferência bancária de debitar de uma conta sem creditar na outra quando algo falha no meio.
• Índices — estruturas (geralmente árvores B) que trocam espaço em disco e custo de escrita por leituras muito mais rápidas. Saber o que indexar — e entender por que índice demais também é problema — é a intervenção de desempenho mais comum da vida real.
• Concorrência e isolamento — o que acontece quando centenas de usuários leem e escrevem ao mesmo tempo: bloqueios, deadlocks e fenômenos como leitura suja. Os níveis de isolamento são o botão que regula o compromisso entre correção e desempenho.
• SQL DDL vs. DML — a distinção entre definir a estrutura (CREATE, ALTER) e manipular os dados (SELECT, INSERT, UPDATE, DELETE). Parece burocrática, mas organiza o aprendizado e mapeia direto para permissões e responsabilidades em equipes reais.

Erros comuns de quem está começando

• Aprender SQL sem entender o modelo por trás. Quem decora sintaxe trava no primeiro JOIN triplo com agregação. Quem entende que consulta é operação sobre conjuntos monta consultas complexas com naturalidade.
• Testar tudo em bases minúsculas. Com 50 linhas, qualquer consulta é instantânea e qualquer modelagem “funciona”. Problemas de índice, plano de execução e normalização só aparecem com volume — gere dados em massa desde cedo.
• Usar SELECT * e confiar no ORM cegamente. Trazer colunas desnecessárias e disparar consultas em loop (o clássico problema N+1) são as causas mais comuns de sistema lento na prática. Olhe o SQL que sua ferramenta gera.
• Ignorar transações até o primeiro dado corrompido. Operações de múltiplos passos sem transação funcionam em desenvolvimento e quebram em produção, no pior momento possível. Adquira o hábito antes do acidente.
• Pular a modelagem e sair criando tabelas. Corrigir um esquema mal projetado com sistema em produção é dolorosíssimo — migração de dados, downtime, risco. Uma hora de diagrama economiza semanas de refatoração.

📚 Materiais recomendados

Livros abertos (licença pública):

• Introdução a Banco de Dados (Rede e-Tec Brasil / MEC) — apostila introdutória em português: modelo relacional, modelagem e primeiros passos de SQL. Disponível no portal Proedu, repositório público da Rede e-Tec.
• Banco de Dados I (Rede e-Tec Brasil / MEC) — sequência natural da anterior, aprofundando SQL e projeto de banco. Também no Proedu.

Bibliografia clássica (procure na biblioteca do campus):

• DATE, C. J. Introdução a Sistemas de Bancos de Dados. O clássico teórico — rigoroso sobre o modelo relacional e suas fundações. Leitura que dá profundidade depois que você já pratica SQL.
• ELMASRI, R.; NAVATHE, S. Sistemas de Banco de Dados. O livro-texto mais adotado nas universidades brasileiras; equilibra teoria e prática e cobre praticamente toda a ementa da disciplina.

🔗 Referências externas

• Roadmap: SQL — mapa completo do que aprender em SQL, do básico ao avançado. Use para se localizar e marcar progresso.
• Roadmap: PostgreSQL DBA — a trilha de administração de banco: backup, replicação, tuning. Para quando você já domina SQL e quer o lado de operação.
• SQLBolt — lições interativas de SQL direto no navegador, sem instalar nada. O melhor ponto de partida absoluto: comece aqui na primeira semana.
• PostgreSQL — o SGBD open source mais respeitado do mercado, e o que recomendo instalar para praticar. A documentação oficial é referência de qualidade rara.

Conexão com as disciplinas do curso

• Modelagem de Dados — o projeto conceitual que antecede o banco: entidades, relacionamentos e normalização.
• Banco de Dados — a disciplina central: SQL, transações, índices e a prática com SGBDs reais.