Bem-vindos!

Não tivemos aula em 01/09, então hoje abrimos a disciplina e já entramos no primeiro tema.

• Parte 1. O que é a disciplina, o que vamos construir e como vocês são avaliados
• Parte 2. Armazenamento: a página, o arquivo de dados e o registro
• Fechamos escrevendo o primeiro código do minidb, que vocês levam para a semana do CBSoft

Em Banco de Dados I, escrevemos SQL

• Por que a mesma consulta roda em 3 ms e em 40 s
• O que o SGBD faz entre o SELECT e o resultado
• Por que um banco não perde dados quando a máquina cai

O critério de pronto

Sacou? O conteúdo do semestre foi escolhido de trás para frente, a partir dessa frase.

A anatomia de um SGBD

Vamos construir de baixo para cima, porque cada camada depende da anterior. A camada de baixo começa hoje.

O minidb 0.0

Cinquenta linhas de Python.

$ python3 hello.py dados.db < demo.sql
CREATE TABLE aluno (id, matricula, nome);
OK
INSERT INTO aluno VALUES (1, 20260001, Ana);
OK 1
SELECT * FROM aluno WHERE id = 2;
2|20260002|Bruno
(1 linha)

Cria tabela, insere, filtra e guarda em disco. É um banco de dados, e é também lento, esquecido e frágil. Consertar cada um desses defeitos é um módulo do semestre.

Os sete módulos

• M1 Página e arquivo de dados
• M2 Cache de páginas
• M3 Árvore B+, busca e inserção
• M4 Parser e catálogo
• M5 Executor: varredura sequencial e por índice
• M6 Transações: BEGIN, COMMIT, ROLLBACK
• M7 Recuperação: log de escrita antecipada

Uma aula teórica e duas de laboratório por módulo.

O que não vamos construir

• Remoção na árvore B+, com fusão e redistribuição de nós
• Registros de tamanho variável, VARCHAR livre, mapa de nulos
• Junções, ORDER BY e agregação
• Otimizador com modelo de custo
• Concorrência: bloqueios, isolamento, deadlock
• Checkpoint, número de sequência de log e ARIES completo

Esses temas viram seminários em 24/11 e 26/11, sorteados em 10/11, respondendo sempre à mesma pergunta: o que precisaria mudar no minidb para ter isso?

A linguagem é escolha de vocês

• C, Python, Go, Rust, Java, o que preferirem
• C ensina mais sobre memória e disco, e custa perto do dobro do tempo
• Python some do caminho e deixa vocês pensarem em estrutura
• Escolham na primeira semana, e não mudem depois

Não estamos competindo em desempenho com o PostgreSQL. A escolha é sobre o que vocês querem aprender.

O que eu forneço é o contrato

O minidb lê comandos da entrada padrão e escreve o resultado na saída padrão, em formato definido. Assim os mesmos testes valem para qualquer linguagem.

$ ./minidb dados.db < consultas.sql
CREATE TABLE aluno (id INT, matricula INT);
OK
INSERT INTO aluno VALUES (1, 20260001);
OK 1
SELECT * FROM aluno WHERE id = 1;
1|20260001
(1 linha)

Repositório e registro de avanços

• Repositório público no GitHub, criado nesta semana
• Commits pequenos e frequentes, feitos enquanto vocês trabalham
• Um NOTES.md por módulo, com um parágrafo sobre a decisão de projeto mais difícil dele

Avaliação

Cada módulo: metade pelos testes de aceitação, um terço pela qualidade do código e do histórico, o restante pelo NOTES.md.

Sobre ferramentas de LLM

• Se vocês fizerem isso, terão um repositório bonito e nenhum aprendizado
• A defesa oral vale 20 pontos exatamente por esse motivo
• Use para explicar, não para produzir: peça o desenho da divisão de nó, peça outro exemplo, peça revisão do que vocês escreveram
• O NOTES.md não sai de código que vocês não entenderam

Cronograma · setembro e outubro

Cronograma · novembro e dezembro

O disco não sabe o que é uma linha

• Um bloco inteiro, porque é assim que o hardware trabalha
• Pedir 8 bytes ou pedir 4096 leva quase o mesmo tempo
• Para o disco não existe linha, nem coluna, nem tabela. Existe bloco

Quem transforma bloco em linha é o programa que vocês vão escrever.

Por que página, e não linha?

• O tempo se vai quase todo em localizar o dado, e quase nada em transferir
• Então o SGBD lê e escreve sempre um bloco, que a gente chama de página
• Página pequena demais: muita ida ao disco. Grande demais: memória jogada fora
• No minidb: 4096 bytes, sempre

A página por dentro

Uma página é um vetor de bytes, e nada além disso. O que dá sentido a ela é saber onde cada coisa começa.

página de 4096 bytes
+-----------+-------+-------+-------+------------------+
| cabeçalho | reg 0 | reg 1 | reg 2 |   espaço livre   |
+-----------+-------+-------+-------+------------------+
   16 bytes   8 b     8 b     8 b

O cabeçalho diz quantos slots estão ocupados. O resto são registros, um atrás do outro.

Registro de tamanho fixo

CREATE TABLE aluno (id INT, matricula INT);

  id           4 bytes
  matricula    4 bytes
  registro     8 bytes,  sempre o mesmo

Custa espaço, e proíbe texto de tamanho livre. Em troca, achar uma linha vira uma conta.

E o arquivo, como fica?

dados.db
+-----------+-----------+-----------+-----------+
| página 0  | página 1  | página 2  | página 3  |  ...
| metadados |  registros, registros, registros  |
+-----------+-----------+-----------+-----------+
   4096 b      4096 b      4096 b      4096 b

• A página 0 guarda os metadados: quantas páginas existem e quais ainda têm espaço
• Da página 1 em diante, são os dados
• O arquivo cresce de 4096 em 4096 bytes, nunca de byte em byte

Sem ordem nenhuma

• Inserir é achar uma página com espaço e escrever lá
• Ninguém garante que a linha inserida antes venha antes no arquivo
• O preço disso: procurar alguém sem índice custa ler o arquivo inteiro

Esse preço é exatamente o que a árvore B+ vai resolver, lá no M3.

O endereço de uma linha

• Vejam de quebra como o PostgreSQL chama o dele, e rodem SELECT ctid, * FROM alguma_tabela;
• A pergunta para trazer respondida: o que acontece com esse endereço quando a linha é atualizada?

Glossário de hoje

• Arquivo. A sequência de páginas gravada em disco. No minidb, uma tabela é um arquivo
• Página. Um pedaço de 4096 bytes do arquivo. É o que o SGBD lê e escreve, sempre inteira
• Slot. Uma posição numerada dentro da página, a partir do zero. Cada slot guarda um registro
• Endereço. O par (página, slot), que diz onde uma linha mora. É o RID
• Bloco. A mesma ideia da página, mas do lado do hardware. Quem escolhe o tamanho aqui é o disco, e não nós

Arquivo contém páginas, página contém slots, e o slot guarda um registro. Escolhemos 4096 bytes para uma página cair em cima de um bloco, e não em cima de dois.

O que os bancos de verdade fazem

Tamanho fixo custa espaço e proíbe VARCHAR livre. Ganhamos o semestre inteiro em troca.

O M1 cabe em três funções

No fim das contas, o módulo inteiro é isto:

le_pagina(n)               →  devolve os 4096 bytes da página n
escreve_pagina(n, bytes)   →  grava os 4096 bytes na página n
insere(registro)           →  acha espaço, grava, devolve o RID

O resto do semestre é construído em cima dessas três. Se elas estiverem certas, o M2 e o M3 vêm bem mais tranquilos.

Exercício: comecem o minidb

• 1. Implementem escreve_pagina(n, bytes) e le_pagina(n) sobre um arquivo comum, na linguagem que a dupla escolheu
• 2. Gravem um registro no slot 0 da página 2, encerrem o processo, abram de novo e leiam o registro de volta
• 3. Commit no repositório da dupla, com um NOTES.md dizendo em que byte do arquivo o registro foi parar

Entrega até 15/09, junto com a escolha da linguagem e a saída do script de testes falhando por inteiro. Em 08 e 10/09 não há aula, por conta do CBSoft 2026.