Ideia central

O modelo relacional organiza dados em tabelas (relações) compostas por linhas (tuplas) e colunas (atributos). Relacionamentos entre tabelas são expressos via chaves estrangeiras. É o modelo mais usado em aplicações transacionais pela sua consistência e poder expressivo do SQL.

Conceitos fundamentais

Chaves:

  • Primary Key (PK): identifica unicamente cada linha. Não pode ser NULL, deve ser imutável
  • Foreign Key (FK): referencia a PK de outra tabela, garantindo integridade referencial
  • Unique Key: garante unicidade sem ser PK (ex: e-mail do usuário)
  • Composite Key: PK composta por mais de uma coluna

Integridade referencial:

CREATE TABLE pedidos (
    id          INT PRIMARY KEY,
    cliente_id  INT NOT NULL,
    CONSTRAINT fk_cliente
        FOREIGN KEY (cliente_id)
        REFERENCES clientes(id)
        ON DELETE RESTRICT
        ON UPDATE CASCADE
);

Normalização

Processo de organizar tabelas para reduzir redundância e dependências anômalas:

Forma NormalRegra principal
1FNAtributos atômicos, sem grupos repetidos
2FN1FN + sem dependência parcial de chave composta
3FN2FN + sem dependência transitiva (atributo depende só da PK)
BCNF3FN + todo determinante é chave candidata

Na prática, 3FN é suficiente para a maioria dos sistemas OLTP. Desnormalizar pode ser necessário para performance em OLAP.

ACID

Garantias fundamentais em transações relacionais:

  • Atomicity: a transação é tudo ou nada, ou todas as operações completam, ou nenhuma é aplicada
  • Consistency: a transação leva o banco de um estado válido para outro estado válido
  • Isolation: transações concorrentes não interferem entre si
  • Durability: dados commitados persistem mesmo após falhas (escrito em disco/log)
BEGIN TRANSACTION;
    UPDATE contas SET saldo = saldo - 1000 WHERE id = 1;
    UPDATE contas SET saldo = saldo + 1000 WHERE id = 2;
COMMIT;
-- Se qualquer UPDATE falhar, o ROLLBACK desfaz tudo

Níveis de isolamento

Do mais fraco para o mais forte (maior isolamento = menor concorrência):

NívelDirty ReadNon-repeatable ReadPhantom Read
READ UNCOMMITTEDSimSimSim
READ COMMITTEDNãoSimSim
REPEATABLE READNãoNãoSim
SERIALIZABLENãoNãoNão

Joins: os principais

-- INNER JOIN: apenas linhas que têm correspondência em ambas as tabelas
SELECT p.id, c.nome
FROM pedidos p
INNER JOIN clientes c ON p.cliente_id = c.id;
 
-- LEFT JOIN: todas as linhas da esquerda, mesmo sem correspondência
SELECT c.nome, p.id
FROM clientes c
LEFT JOIN pedidos p ON c.id = p.cliente_id;
 
-- FULL OUTER JOIN: todas as linhas de ambos os lados
SELECT c.nome, p.id
FROM clientes c
FULL OUTER JOIN pedidos p ON c.id = p.cliente_id;

Quando usar banco relacional

Ideal quando:

  • Os dados têm estrutura bem definida e estável
  • Integridade e consistência são prioritárias (financeiro, ERP, e-commerce)
  • Queries complexas com múltiplos joins são necessárias
  • Transações ACID são obrigatórias

Considere alternativas quando:

  • Schema muda com muita frequência
  • Volume é massivo e escala horizontal é obrigatória
  • Os dados são naturalmente hierárquicos ou em grafo

Conexões

Referências