Se “tabela”, “chave” e “SQL” ainda soam como palavras de outra pessoa, comece aqui. Esta seção não é do currículo: é o chão que ele pressupõe. Quinze minutos de leitura e o resto da nota passa a fazer sentido.

1. O que é um banco de dados, afinal

É o lugar onde um sistema guarda o que precisa lembrar. Quando você se cadastra num site e volta no dia seguinte e ele ainda sabe seu nome, é um banco de dados fazendo isso. Todo aplicativo que você usa — o banco, o iFood, o Instagram — é, por baixo, uma pilha de telas conversando com um banco de dados.

A comparação honesta é com uma planilha: linhas, colunas, valores. Se você já usou Excel, já viu 60% da ideia. O banco de dados é o que a planilha vira quando ela precisa aguentar coisas que planilha não aguenta:

2. A anatomia: tabela, linha, coluna, chave

Quase todo o vocabulário do semestre está nesta única imagem. Vale demorar nela.

3. Por que não uma tabela só

A pergunta natural de quem vem da planilha: se dá para colocar tudo numa aba só, por que dividir? Porque informação repetida sempre acaba divergindo. Se o telefone da Ana está copiado em cada um dos 40 pedidos dela, mudar o telefone significa acertar 40 lugares — e bastam 39 para o banco passar a mentir.

A solução é guardar cada coisa uma vez e ligar as tabelas por um número. O pedido não guarda “Ana Lopes, São Luís, ana@mail.com”; guarda apenas cliente_id = 1 — um endereço que aponta para a linha da Ana. Esse número emprestado é a chave estrangeira, e é literalmente tudo que existe por trás da palavra “relacional”.

Se você levar uma só ideia desta seção, leve esta: um banco de dados relacional é um conjunto de tabelas que se apontam por números. Modelar é decidir quais tabelas existem; consultar é seguir esses apontamentos para juntar de volta o que foi separado.

4. Como se conversa com um banco: SQL

Você não clica no banco — você escreve uma frase para ele, em SQL. E SQL foi desenhada nos anos 70 para parecer inglês, o que a torna surpreendentemente legível: cada linha da consulta é um pedaço da frase.

Junte as cinco linhas e você tem uma consulta de verdade, do tipo que roda em produção. É este o tamanho da coisa: o módulo 1 inteiro são variações e combinações dessa frase.

5. Quem é quem — os nomes que confundem no começo

Pronto para o resto da nota. Daqui em diante, quando aparecer “junção”, leia “juntar duas tabelas seguindo o número que uma guarda da outra”; quando aparecer “normalizar”, leia “separar em tabelas para não repetir informação”. Todo o resto são detalhes destas duas frases.

SQL é inegociável na carreira dev (todo posting pede) e é a espinha de qualquer sistema que você construir para cliente — site com conteúdo, dashboard, automação. Modelagem de dados é irmã da sua arquitetura de informação: os dois ofícios são “dar forma estruturada ao que o negócio significa”.

Veredito: aprofundar além do teto do curso — junto com Estrutura de Dados, a dupla mais valiosa do semestre.

Nota de ordem: SQL de leitura vem antes de modelagem de propósito — consultar dados dá fome de entender como eles são desenhados. Cursos costumam fazer o inverso e perder o aluno na teoria.

Como usar: siga o checklist na ordem dos módulos — a ordem deles já é a ordem de estudo. O capstone pode começar cedo: a partir do módulo 2 você já modela o domínio; cada módulo seguinte adiciona uma camada ao mesmo banco. Se algum termo da tabela acima ainda for opaco, a seção “Do zero” cobre o vocabulário que estes cinco módulos pressupõem.

Fazer perguntas a dados e obter respostas. É o que você usa todo dia — e o que toda vaga cobra.

-- um cliente por linha, com a data da última compra
SELECT  c.nome, MAX(p.data) AS ultima_compra
FROM    clientes c
LEFT JOIN pedidos p ON p.cliente_id = c.id
GROUP BY c.id, c.nome
HAVING  MAX(p.data) < CURRENT_DATE - INTERVAL '90 days'
     OR MAX(p.data) IS NULL   -- nunca comprou
ORDER BY ultima_compra NULLS FIRST;

Traduzir um negócio real em entidades e relações. É aqui que se decide se o banco vai trair o cliente daqui a um ano.

2.4 — Normalização, em uma planilha que dói

O ponto de partida de quase todo iniciante: uma tabela só, larga, que parece prática e mente três vezes.

Uma frase para levar: normalizar é garantir que cada fato viva em um só lugar. Toda anomalia de banco iniciante — duplicata que diverge, exclusão que apaga o que não devia, atualização que esquece uma linha — é um fato morando em dois lugares.

2.5 — E quando desnormalizar? Relatório lê e não escreve: se o total do pedido já está calculado numa coluna, ninguém corre risco de contradizê-lo — não há segunda escrita. Sistema transacional escreve o tempo todo, e cada cópia é uma chance de divergir. Daí a regra: relatórios perdoam o que sistemas não perdoam.

Criar, alimentar e alterar esquemas com segurança — inclusive contra você mesmo às onze da noite.

CREATE TABLE proposta (
  id          bigserial   PRIMARY KEY,
  cliente_id  bigint      NOT NULL
              REFERENCES cliente(id),
  valor       numeric(12,2) NOT NULL
              CHECK (valor > 0),
  status      text        NOT NULL
              DEFAULT 'rascunho'
              CHECK (status IN ('rascunho',
                     'enviada','aceita','recusada')),
  criada_em   timestamptz NOT NULL
              DEFAULT now()
);

-- 1. escreva primeiro como SELECT
SELECT * FROM proposta
WHERE  status = 'enviada'
  AND  criada_em < CURRENT_DATE - 30;

-- 2. confira a contagem. só então:
BEGIN;
UPDATE proposta SET status = 'recusada'
WHERE  status = 'enviada'
  AND  criada_em < CURRENT_DATE - 30;
-- olhe o número de linhas afetadas
COMMIT;  -- ou ROLLBACK, se assustou

3.4 — a view como móvel da casa: quando a mesma consulta é reescrita pela terceira vez, ela deixou de ser pergunta e virou parte da estrutura. CREATE VIEW lhe dá um nome, e a definição passa a viver num lugar só — a mesma economia da normalização, aplicada a consultas.

Índices, transações e por que consultas ficam lentas. O módulo que separa quem usa banco de quem entende banco.

Modelar e construir o banco de um negócio seu, de ponta a ponta — a peça que fica no portfólio e um dia vira o CRM real.

O capstone não começa no módulo 5 — ele termina nele. Cada módulo anterior adiciona uma camada ao mesmo banco, e o que o módulo 5 faz é fechar, documentar e publicar.

Os termos que esta nota (e o semestre) usam como se você já os conhecesse. Ler de cima a baixo é uma miniatura do curso.

O ato recorrente — a regra do laboratório: todo tópico estudado termina com SQL digitado por você contra um banco real. No módulo 1, cada conceito vira 3–5 consultas suas contra o Northwind — não copiadas: formuladas a partir de uma pergunta de negócio que você inventa. Do módulo 2 em diante, o alvo muda para o banco da prática DxE que você mesmo vai modelar e construir; cada módulo adiciona uma camada ao mesmo banco, até ele ser o capstone completo.

Plano de ensino ainda não disponível — colar aqui quando chegar e mapear: tópico oficial → código revisado; o que cai em prova; o que o plano omite.