O mapa de hoje

• Bloco 1 — por que um arquivo solto não dá conta
• Bloco 2 — o que um SGBD resolve (as 4 garantias)
• Bloco 3 — de onde vieram os bancos de dados e quais existem hoje
• Bloco 4 — mão na massa: diagnóstico da locadora, em grupo

Três intervalos de 10 minutos, um entre cada bloco.

A locadora de jogos da esquina

Imagine uma locadora de jogos com três atendentes e uma planilha só, num computador compartilhado do balcão: locadora.xlsx.

A planilha tem uma aba com tudo misturado:

Funciona no primeiro dia. Vamos ver o que acontece no primeiro mês.

Problema 1 — duas pessoas salvam ao mesmo tempo

• A atendente Ana abre a planilha às 19h02 e começa a lançar um empréstimo
• O atendente Bruno abre a mesma planilha às 19h03 e lança outro empréstimo
• Ana salva às 19h10 · Bruno salva às 19h11
• O lançamento da Ana some. O arquivo do Bruno foi salvo por cima

Problema 2 — o mesmo dado escrito de três jeitos

Três atendentes digitando o nome do mesmo jogo:

Agora responda: quantas vezes esse jogo foi alugado no mês?

• Uma busca por God of War Ragnarok acha 1
• O chefe acha que o jogo não vende e tira do catálogo

Problema 3 — o telefone da Ana mudou

Na planilha, o telefone da Ana está repetido em toda linha em que ela aparece. Ela alugou 14 vezes este ano.

• Ela troca de número
• Alguém atualiza 11 linhas e esquece 3
• Qual das duas versões é a verdadeira?

Problema 4 — quem apagou a linha 200?

• A planilha não guarda quem mudou, o quê e quando
• Não dá para desfazer seletivamente: ou se volta o arquivo inteiro de ontem, ou nada
• Qualquer um que abre o arquivo pode apagar tudo — de propósito ou sem querer
• O backup é "uma cópia na pasta Downloads de alguém"

Contraexemplo — quando a planilha basta

Ser justo com a planilha: ela é ótima quando

• uma pessoa só mexe no arquivo,
• os dados cabem numa tela e não crescem,
• ninguém precisa saber quem mudou o quê,
• e perder o arquivo não quebraria o negócio.

Checagem do Bloco 1

A definição, em uma frase

Concorrênciamuita gente ao mesmo tempo, sem perder lançamento

Integridadeo dado só entra se fizer sentido

Persistênciacaiu a luz, o dado continua lá

Segurançacada um vê e muda só o que pode

O SGBD fica no meio do caminho

Ninguém fala com o arquivo no disco. Todo mundo fala com o SGBD.

Garantia 1 — Concorrência

Vários atendentes ao mesmo tempo, sem um salvar por cima do outro.

• O SGBD enfileira as alterações e resolve os conflitos
• O lançamento da Ana e o do Bruno entram — os dois
• Ninguém precisa combinar "agora é a minha vez de abrir o arquivo"

Isso mata o Problema 1.

Garantia 2 — Integridade

Os dados sempre fazem sentido, porque o banco recusa o que não faz.

• Não existe empréstimo de um jogo que não está no catálogo
• Não existe cliente sem nome
• A data de devolução não pode ser antes da retirada
• O mesmo jogo não é cadastrado com três grafias diferentes

Isso mata os Problemas 2 e 3.

Garantia 3 — Persistência

Os dados sobrevivem a travamento, queda de energia e reinício.

• Ou a operação inteira acontece, ou nada acontece — nunca metade
• Caiu a luz no meio do lançamento? O banco volta consistente
• "Salvar" deixa de ser uma decisão humana que alguém pode esquecer

Garantia 4 — Segurança

Nem todo mundo pode ver ou mudar tudo.

• O estagiário consulta o catálogo, mas não apaga clientes
• O dono vê o relatório de faturamento; o atendente, não
• O banco registra quem fez o quê

Isso mata o Problema 4.

Erro comum — "banco de dados é o Excel do programador"

Uma planilha com 1 milhão de linhas continua sendo uma planilha.
Um banco com 3 linhas já é um banco.

Quem é quem — três palavras que confundem

Checagem do Bloco 2

Antes das tabelas — o modelo hierárquico

Anos 60: os dados eram guardados em árvore, como pastas dentro de pastas.

• Ótimo para descer: plataforma → jogos daquela plataforma
• Péssimo para atravessar: "quais clientes alugaram jogos de PS5 e de Switch?"
• Mudar a estrutura significava reescrever os programas

Depois — o modelo em rede

Anos 70: cada registro podia apontar para vários outros, formando uma teia.

• Resolveu o problema de atravessar
• Criou outro: o programador tinha que saber o caminho até o dado
• Cada consulta nova exigia um programa novo

1970 — Edgar F. Codd e o modelo relacional

Um matemático da IBM propõe: guarde tudo em tabelas e deixe o programa dizer o que ele quer, não como buscar.

• Tabela = linhas e colunas, e nada além disso
• As tabelas se ligam por valores em comum, não por caminhos
• Você pede todos os jogos de PS5 — o SGBD decide como encontrar

Por que as tabelas venceram

• Simples de explicar — todo mundo entende linha e coluna
• Padronizadas — a mesma linguagem (SQL) serve para vários fabricantes
• Flexíveis — dá para fazer perguntas que ninguém previu quando o banco foi criado
• Com base matemática — dá para provar que uma consulta está certa

Os SGBDs relacionais de hoje

E o tal de NoSQL?

Existem bancos que não são tabelas: documentos, chave-valor, grafos.

• Servem para casos específicos (cache, catálogo sem formato fixo, rede social)
• Quase sempre convivem com um banco relacional, não o substituem
• Só fazem sentido depois que você entende o relacional

Erro comum — "SQL" e "MySQL" não são a mesma coisa

Demonstração — 5 minutos de PostgreSQL na tela

Só para vocês verem onde estamos indo. Não precisa anotar nada.

• Abro o pgAdmin e mostro um banco locadora já pronto
• Mostro as tabelas jogo, cliente, emprestimo — as "abas" da planilha, agora separadas
• Rodo uma pergunta: quantos jogos de PS5 existem?
• Tento cadastrar um empréstimo de um jogo inexistente — e o banco recusa

Checagem do Bloco 3