Bellacosa Mainframe apresenta DBMS

☕ Um Café no Bellacosa Mainframe

🐒 Detetive Chimp e o Mistério do Banco de Dados que Jurava Ser Consistente

DBMS, modelagem ER, SQL, normalização, índices, ACID, locks, concorrência, COMMIT, ROLLBACK e recovery investigados por um detetive que sabe que os dados sempre deixam pistas

Há uma coisa que aprendi observando sistemas durante muito tempo: quando um programa diz que “não fez nada”, comece procurando o log.

Quando um usuário afirma que “clicou apenas uma vez”, procure duas transações.

Quando uma aplicação garante que “ninguém alterou aquele registro”, procure um UPDATE.

E quando um banco de dados afirma que está tudo consistente...

...chame o Detetive Chimp.

Nosso investigador chega ao data center usando seu tradicional chapéu, examina o terminal 3270 e encontra a primeira pista:

03:17:00.001  TRANSACTION T1
03:17:00.003  TRANSACTION T2

Dois milissegundos.

Uma diferença ridiculamente pequena para um humano.

Uma eternidade para um computador.

Sobre a mesa há ainda cinco folhas intituladas DBMS Quick Revision Sheet. Elas falam de DBMS, ER Model, SQL, normalização, ACID, transações, concorrência e índices.

Chimp olha para aquilo.

— Interessante.

Acende seu cachimbo imaginário.

— Temos vários suspeitos.

E assim começa nosso caso.

---

🕵️ CAPÍTULO 1 — O cadáver era um banco de dados

Antes de investigar o crime precisamos entender a vítima.

DBMS significa:

Database Management System — Sistema Gerenciador de Banco de Dados.

Para o iniciante, é tentador pensar:

banco de dados = lugar onde guardamos informações.

Não está errado.

Mas é tão incompleto quanto dizer que um aeroporto é um lugar onde estacionamos aviões.

Um DBMS precisa armazenar, organizar, localizar, proteger, compartilhar, alterar e recuperar dados, além de arbitrar o que acontece quando diversos usuários tentam mexer neles simultaneamente.

Imagine:

              USUÁRIOS
                 │
                 ▼
          ┌─────────────┐
          │ APLICAÇÕES  │
          └──────┬──────┘
                 │
                 ▼
          ┌─────────────┐
          │    DBMS     │
          └──────┬──────┘
                 │
                 ▼
          ┌─────────────┐
          │    DADOS    │
          └─────────────┘

O DBMS fica entre as aplicações e os dados.

Mas Detetive Chimp imediatamente acrescentaria vários departamentos escondidos naquele retângulo:

                  DBMS
                    │
       ┌────────────┼─────────────┐
       │            │             │
     SQL        Segurança     Transações
       │            │             │
   Optimizer     Controle      Logging
       │                          │
   Access Path                  Recovery
       │
     Storage

É uma pequena cidade funcionando atrás de uma palavra de quatro letras.

---

🐒 CAPÍTULO 2 — O primeiro suspeito: SQL

Chimp encontra uma consulta:

SELECT NOME, LIMITE
FROM CLIENTE
WHERE CPF = :WS-CPF;

— Parece inocente.

O programador COBOL iniciante concorda.

Chimp continua:

— É exatamente por isso que devemos investigá-la.

SQL é uma linguagem declarativa.

Quando escrevemos:

SELECT NOME
FROM CLIENTE
WHERE CPF = '123';

estamos essencialmente dizendo:

“Db2, quero o nome do cliente cujo CPF é 123.”

Não estamos necessariamente dizendo:

“vá até determinado cilindro, encontre determinada página, leia o registro número 427...”

O DBMS precisa descobrir uma estratégia eficiente.

Simplificando:

SQL
 │
 ▼
PARSER
 │
 ▼
OPTIMIZER
 │
 ▼
ACCESS PATH
 │
 ├── INDEX?
 │
 ├── SCAN?
 │
 └── JOIN?
 │
 ▼
DADOS

Aqui aparece um personagem que aquelas folhas introdutórias mal conseguem explorar: o optimizer.

Ele analisa possibilidades para executar a consulta.

Portanto, duas consultas SQL que produzem resultados semelhantes podem apresentar comportamentos de performance radicalmente diferentes.

Saber escrever SQL é uma habilidade.

Entender como o banco chega aos dados é outra.

---

🧩 CAPÍTULO 3 — Antes do banco havia o mundo real

Chimp desenha três objetos no quadro:

CLIENTE
CONTA
TRANSAÇÃO

Antes de existir tabela, índice ou SELECT, alguém precisou transformar uma realidade de negócio em um modelo de dados.

É aí que entra o ER Model — Entity Relationship Model.

Temos três conceitos fundamentais:

ENTITY
ATTRIBUTE
RELATIONSHIP

Uma entidade pode ser:

CLIENTE

Seus atributos:

ID_CLIENTE
CPF
NOME
DATA_NASCIMENTO

Outra entidade:

CONTA

Com:

ID_CONTA
AGENCIA
SALDO

Existe então uma relação:

CLIENTE ───── POSSUI ───── CONTA

Um cliente pode possuir várias contas.

Podemos representar:

CLIENTE 1 ───────── N CONTA

Chimp bate o cachimbo no quadro.

— Eis uma pista importante: muitos crimes de dados começam antes de existir código.

Um modelo ruim acaba contaminando tabelas, programas, APIs, relatórios e integrações.

---

🔑 CAPÍTULO 4 — O caso das chaves desaparecidas

A apostila apresenta:

Super Key, Candidate Key, Primary Key, Alternate Key e Foreign Key.

Parece matéria de prova.

Não é.

Imagine:

CLIENTE
-----------------------
ID_CLIENTE
CPF
NOME

Escolhemos:

ID_CLIENTE → PRIMARY KEY

Outra tabela:

CONTA
-----------------------
ID_CONTA
ID_CLIENTE
SALDO

Aqui:

ID_CONTA   → PRIMARY KEY
ID_CLIENTE → FOREIGN KEY

Agora existe uma relação:

CLIENTE
 ID_CLIENTE
     │
     │
     ▼
CONTA
 ID_CLIENTE

A chave estrangeira representa uma relação entre os dados.

Sem integridade adequada poderíamos encontrar:

CONTA 999999
CLIENTE 777777

mas descobrir que:

CLIENTE 777777

não existe.

Chimp imediatamente pergunta:

— Então de quem é essa conta?

Silêncio no data center.

Temos um órfão de dados.

---

🧹 CAPÍTULO 5 — Normalização: arrumando a cena do crime

Agora encontramos uma tabela criada por alguém numa sexta-feira às 17:58:

PEDIDO
---------------------------------
CLIENTE
ENDERECO
PRODUTO1
PRECO1
PRODUTO2
PRECO2
PRODUTO3
PRECO3

Chimp olha horrorizado.

— Quem fez isso?

Ninguém responde.

Naturalmente.

A normalização procura organizar estruturas de dados reduzindo redundâncias e dependências problemáticas.

A apostila percorre:

1NF
 ↓
2NF
 ↓
3NF
 ↓
BCNF

Uma modelagem mais organizada poderia resultar em:

CLIENTE
   │
   │
   ▼
PEDIDO
   │
   │
   ▼
ITEM_PEDIDO
   │
   │
   ▼
PRODUTO

Isso reduz problemas clássicos de:

INSERT
UPDATE
DELETE

Imagine armazenarmos o endereço do cliente repetidamente em 30 mil pedidos.

Ele muda de endereço.

Quantas ocorrências precisam ser alteradas?

Esse tipo de redundância é terreno fértil para inconsistência.

Mas Chimp deixa uma observação importante no relatório:

Normalização é ferramenta de engenharia, não religião.

Projetos reais também consideram performance, padrões de acesso, volume, frequência de atualização e características específicas do workload.

---

🏦 CAPÍTULO 6 — Finalmente encontramos o dinheiro

Agora o caso fica sério.

Temos:

CONTA A = R$ 1.000
CONTA B = R$   500

Queremos transferir:

R$ 100

Conceitualmente:

A = A - 100
B = B + 100

Depois:

A = 900
B = 600

Perfeito.

Um programa COBOL poderia executar uma sequência equivalente a:

LER A
SUBTRAIR 100
UPDATE A

LER B
SOMAR 100
UPDATE B

Mas Chimp coloca uma banana exatamente entre os dois updates.

UPDATE A
   │
   ▼
A = 900

💥 ABEND S0C7

UPDATE B
   │
   X

Agora temos:

A = 900
B = 500

Os R$100 desapareceram.

Não foram transferidos.

Foram sacrificados aos deuses do processamento de dados.

É aqui que surge um dos conceitos mais importantes de toda a apostila:

TRANSACTION

---

🔄 CAPÍTULO 7 — A transação é o verdadeiro suspeito

Uma transação representa uma unidade lógica de trabalho.

Queremos que:

DEBITAR A
CREDITAR B

sejam tratados como parte de uma operação coerente.

Conceitualmente:

┌──── UNIT OF WORK ─────┐
│                       │
│ UPDATE A              │
│ UPDATE B              │
│                       │
│ COMMIT                │
│                       │
└───────────────────────┘

Se tudo funcionar:

COMMIT

Se alguma coisa der errado antes da confirmação apropriada:

ROLLBACK

Chimp sorri.

— Agora encontramos o mecanismo que impede o dinheiro de desaparecer.

Mas ainda não resolvemos o crime.

Porque existem outros usuários.

---

🧪 CAPÍTULO 8 — ACID entra para interrogatório

Na parede aparecem quatro letras:

A C I D

Não é uma banda psicodélica de mainframe.

São propriedades fundamentais das transações.

A — Atomicity

Tudo ou nada.

A - 100
B + 100

Não queremos:

A - 100 ✓
B + 100 ✗

A operação lógica deve ser tratada atomicamente.

---

C — Consistency

Antes:

A = 1000
B = 500

TOTAL = 1500

Depois:

A = 900
B = 600

TOTAL = 1500

O sistema deve preservar as regras de consistência definidas para os dados.

Mas cuidado: consistência não significa que o DBMS magicamente conhece todas as regras do negócio.

Se uma regra diz:

clientes menores de determinada idade não podem contratar determinado produto,

alguém precisa expressar e implementar essa regra adequadamente.

O banco não consulta uma bola de cristal.

---

I — Isolation

Chimp finalmente encontra a pista decisiva.

Temos limite disponível:

R$ 1.000

Duas compras chegam:

T1 → R$700
T2 → R$600

Quase simultaneamente.

T1 pergunta:

LIMITE?

Resposta:

1000

T2 pergunta:

LIMITE?

Resposta:

1000

T1 pensa:

700 < 1000

APROVADO

T2 pensa:

600 < 1000

APROVADO

Resultado:

700 + 600 = 1300

Oops.

É por isso que concorrência não é detalhe acadêmico.

---

D — Durability

Depois que uma transação é confirmada, esperamos que sua alteração sobreviva a falhas previstas pelo mecanismo transacional.

Não queremos:

COMMIT

e cinco minutos depois:

“Desculpe, perdemos sua transferência.”

Logging e recovery existem justamente porque computadores, discos, processos e aplicações podem falhar.

---

🔐 CAPÍTULO 9 — As impressões digitais chamadas LOCKS

A apostila apresenta dois conceitos:

S LOCK
X LOCK

Simplificando didaticamente:

Shared Lock permite compartilhamento compatível para determinados acessos de leitura.

Exclusive Lock protege recursos que estão sendo modificados contra acessos incompatíveis.

Chimp desenha:

TRANSACTION A
     │
     ▼
   RESOURCE
     ▲
     │
TRANSACTION B

Agora temos concorrência.

Um sistema empresarial não pode simplesmente dizer:

“Só uma pessoa pode usar o banco por vez.”

Imagine um banco com milhões de clientes operando assim.

CLIENTE 1 → terminou?
CLIENTE 2 → pode entrar.
CLIENTE 3 → espere.
CLIENTE 4 → senha 493827.

😂

Precisamos permitir enorme paralelismo enquanto preservamos integridade.

Esse é um dos grandes desafios do DBMS.

---

💀 CAPÍTULO 10 — Deadlock: encontramos dois cadáveres

Chimp encontra:

T1 possui LOCK A
T2 possui LOCK B

Depois:

T1 precisa de B
T2 precisa de A

Visualmente:

       espera
   ┌──────────────►
   │
  T1              T2
   ▲               │
   ◄───────────────┘
       espera

Parabéns.

Criamos um deadlock.

T1 espera T2.

T2 espera T1.

Nenhum resolve voluntariamente a situação.

O DBMS precisa detectar e solucionar esse tipo de conflito, normalmente escolhendo uma transação como vítima para quebrar o ciclo.

E aí o programador descobre uma lição maravilhosa:

ROLLBACK não significa necessariamente que o DBMS está quebrado.

Às vezes o rollback é justamente o mecanismo impedindo que o sistema permaneça preso.

---

🚦 CAPÍTULO 11 — Isolation Level: quanta privacidade você quer?

Aqui começamos a sair definitivamente da apostila de revisão e entrar na engenharia.

No Db2 encontramos níveis como:

UR
CS
RS
RR

Conceitualmente podemos imaginar um controle:

MAIS ISOLAMENTO
      ▲
      │
      │ proteção
      │
      │
      │ concorrência
      ▼
MENOS ISOLAMENTO

Isso não significa simplesmente:

“mais isolamento é melhor.”

Um sistema transacional gigantesco precisa equilibrar:

integridade
concorrência
latência
throughput
CPU
locks
tempo de resposta

O programador que escolhe mecanismos de isolamento sem entender o workload está fazendo engenharia com os olhos vendados.

---

💾 CAPÍTULO 12 — SAVEPOINT, a máquina do tempo

Chimp encontra:

SAVEPOINT SP1

— Finalmente uma testemunha inteligente.

Imagine:

PASSO A
PASSO B
PASSO C

SAVEPOINT SP1

PASSO D
PASSO E
PASSO F

O passo F falha.

Dependendo da situação e do desenho da aplicação, podemos voltar a um savepoint apropriado:

A ✓
B ✓
C ✓

--- SP1 ---

D ↶
E ↶
F ↶

É quase um:

SAVE GAME

do processamento transacional.

Só não diga isso durante entrevista para DBA.

Ou diga.

Talvez ele goste.

---

🔎 CAPÍTULO 13 — O índice não matou ninguém... provavelmente

Chimp encontra uma tabela gigantesca:

CLIENTE
100.000.000 ROWS

Consulta:

SELECT NOME
FROM CLIENTE
WHERE CPF = :CPF;

Como encontramos aquele CPF?

Sem uma estrutura de acesso adequada, poderíamos ter um trabalho enorme de procura.

Com um índice apropriado:

CPF
 │
 ▼
INDEX
 │
 ▼
LOCALIZAÇÃO
 │
 ▼
DADO

Muito melhor.

Então surge a ideia perigosa:

“Vamos criar índice para tudo!”

Chimp imediatamente fecha o notebook.

— Não.

Índices também possuem custo.

Precisam ser armazenados e mantidos quando dados são inseridos, removidos ou alterados.

Temos novamente um compromisso:

MAIS ÍNDICES
     │
     ├── potencial de melhores acessos
     │
     └── maior custo de manutenção/espaço

Banco de dados é uma sucessão de decisões de engenharia.

---

🧠 CAPÍTULO 14 — O verdadeiro cérebro estava escondido: Optimizer

Finalmente encontramos o personagem que faltava nas folhas.

O programador escreve:

SELECT ...
FROM CLIENTE C
JOIN CONTA A
  ON C.ID_CLIENTE = A.ID_CLIENTE
WHERE C.CPF = :CPF;

O DBMS precisa descobrir como executar aquilo.

Conceitualmente:

SQL
 │
 ▼
OPTIMIZER
 │
 ├── estatísticas
 ├── cardinalidade
 ├── índices
 ├── predicates
 ├── joins
 └── estimativas
 │
 ▼
ACCESS PATH

É por isso que:

SQL correto

não implica necessariamente:

SQL eficiente

Ele pode retornar exatamente os dados solicitados e ainda assim fazer um trabalho absurdamente maior do que o necessário.

Chimp escreve no relatório:

O suspeito tinha álibi funcional, mas não tinha álibi de performance.

---

🏭 CAPÍTULO 15 — Agora tragam CICS, COBOL e Db2

Chegamos ao Bellacosa Mainframe.

Coloque tudo junto:

                    CLIENTE
                       │
                       ▼
                ┌────────────┐
                │    CICS    │
                └─────┬──────┘
                      │
                      ▼
                ┌────────────┐
                │   COBOL    │
                └─────┬──────┘
                      │
                     SQL
                      │
                      ▼
                ┌────────────┐
                │Db2 for z/OS│
                └─────┬──────┘
                      │
            ┌─────────┴─────────┐
            ▼                   ▼
          INDEX                DATA

Agora multiplique por milhares de transações.

T000001
T000002
T000003
...
T999999

Todas querem:

READ
INSERT
UPDATE
DELETE
COMMIT

O problema deixa de ser:

“Como salvo um cliente?”

Passa a ser:

Como milhares de operações podem alterar um universo compartilhado simultaneamente sem destruir sua coerência?

Essa pergunta explica boa parte da existência dos mecanismos transacionais.

---

💳 CAPÍTULO 16 — Chimp investiga uma compra de cartão

Compra:

R$100

A mensagem chega ao sistema.

             COMPRA
                │
                ▼
              CICS
                │
                ▼
              COBOL
                │
       ┌────────┼─────────┐
       ▼        ▼         ▼
    CLIENTE   CARTÃO    PRODUTO
       │        │         │
       └────────┼─────────┘
                ▼
              LIMITE
                │
                ▼
             FRAUDE?
                │
                ▼
          AUTORIZAÇÃO
                │
         ┌──────┴──────┐
         ▼             ▼
      APPROVE        DECLINE

Parece simples.

Agora chegam duas compras:

03:17:00.001 → R$700
03:17:00.003 → R$600

Limite:

R$1000

Eis o easter egg.

03:17.

Chimp olha para o relógio.

— Sempre é 03:17 quando algo interessante acontece no mainframe.

Dois milissegundos separam um fluxo trivial de um excelente caso de concorrência.

Agora fazem sentido:

ACID
LOCK
ISOLATION
COMMIT
ROLLBACK
LOG
RECOVERY

Cada palavra da apostila ganhou consequências financeiras.

---

🧯 CAPÍTULO 17 — “Mas funcionou no teste!”

Chimp fecha os olhos.

Essa é uma das frases favoritas do culpado.

No teste:

1 usuário
1 transação
100 registros

Produção:

10.000 usuários
milhares de transações
milhões/bilhões de registros
concorrência
timeout
deadlock
falhas
rede
batch
online
APIs

O programa:

SELECT
UPDATE
COMMIT

funciona maravilhosamente sozinho.

Coloque centenas de instâncias disputando os mesmos recursos e você descobrirá características que nunca apareceram no teste simplificado.

É por isso que engenharia transacional exige pensar não apenas:

MEU PROGRAMA

mas:

              SISTEMA
                 │
     ┌───────────┼───────────┐
     ▼           ▼           ▼
  ONLINE       BATCH        APIs
     │           │           │
     └───────────┼───────────┘
                 ▼
                DB2

Seu programa nunca está realmente sozinho.

---

🐒 CAPÍTULO 18 — Detetive Chimp apresenta os suspeitos

Depois de horas investigando, Chimp monta o quadro:

              O CASO DBMS
                   │
       ┌───────────┼────────────┐
       ▼           ▼            ▼
    MODELAGEM     SQL       TRANSAÇÃO
       │           │            │
       ▼           ▼            ▼
      ER       OPTIMIZER       ACID
       │           │            │
       ▼           ▼            ▼
     KEYS       INDEXES      LOCKING
       │                        │
       ▼                        ▼
 NORMALIZATION              ISOLATION
                                │
                       ┌────────┴────────┐
                       ▼                 ▼
                    COMMIT           ROLLBACK
                       │                 │
                       └────────┬────────┘
                                ▼
                              LOG
                                │
                                ▼
                            RECOVERY

Nenhum deles isoladamente matou o banco.

O problema estava na interação entre todos eles.

---

🎓 CAPÍTULO 19 — A trilha para o programador COBOL iniciante

Se eu transformasse aquelas cinco folhas em uma trilha de estudo, seguiria esta ordem:

1. Entenda DBMS e a diferença entre dado, banco e gerenciador. Depois modele entidades, atributos, relacionamentos, cardinalidades e chaves. Aprenda SQL básico — SELECT, INSERT, UPDATE, DELETE e JOIN — e só então entre em normalização e integridade referencial.

2. Em seguida estude transações profundamente: Unit of Work, COMMIT, ROLLBACK, SAVEPOINT e ACID. Depois avance para concorrência, locks, isolamento, timeout e deadlock. Finalmente estude índices, optimizer, access paths, logging, backup/recovery e performance.

3. Só então faça o exercício realmente divertido: implemente mentalmente tudo isso em COBOL + CICS + Db2, primeiro com um usuário e depois imaginando 10.000 usuários concorrentes.

Nesse ponto o estudante deixa de decorar definições e começa a pensar como engenheiro.

---

☕ EPÍLOGO — O banco nunca mentiu

O sol começa a nascer sobre o data center.

Chimp termina seu café.

O jovem programador pergunta:

— Então quem era o assassino?

Chimp coloca o chapéu.

— Ninguém.

— Como assim?

— O banco fez exatamente aquilo que mandaram fazer.

Silêncio.

Essa talvez seja uma das maiores lições de sistemas.

Computadores são extraordinariamente obedientes.

Se você modelar mal, eles executarão rapidamente um modelo ruim.

Se escrever uma transação incorreta, executarão corretamente a transação incorreta.

Se criar SQL ineficiente, poderão produzir exatamente o resultado esperado — lentamente.

Se esquecer concorrência, o sistema poderá funcionar perfeitamente durante meses...

...até duas transações chegarem juntas.

03:17:00.001
03:17:00.003

E então você descobrirá que dois milissegundos podem revelar um erro arquitetural escondido durante anos.

Chimp deixa sobre a mesa as cinco folhas de revisão.

No começo da investigação elas diziam:

DBMS
ER MODEL
NORMALIZATION
SQL
ACID
TRANSACTION
INDEX

Agora significam:

REALIDADE
   ↓
MODELAGEM
   ↓
DADOS
   ↓
TRANSAÇÕES
   ↓
CONCORRÊNCIA
   ↓
INTEGRIDADE
   ↓
RECUPERAÇÃO
   ↓
PERFORMANCE
   ↓
NEGÓCIO

É essa a diferença entre decorar banco de dados para uma prova e compreender por que bancos, seguradoras, companhias aéreas, governos e sistemas de cartões investem tanto em engenharia transacional.

Aquelas quatro letras — ACID — parecem matéria de apostila.

Um COMMIT parece apenas um comando.

Um LOCK parece detalhe técnico.

Um índice parece somente uma maneira de procurar dados mais rapidamente.

Até o dia em que você percebe que do outro lado daqueles registros existem dinheiro, passagens, pedidos, pagamentos, estoques, contratos e pessoas.

Detetive Chimp abre a porta.

Antes de sair, olha novamente para o terminal.

READY

Caso encerrado?

Claro que não.

Em mainframe sempre existe outro JOB esperando na fila.

E provavelmente existe algum programador jurando:

“Mas eu não alterei nada...”

Chimp sorri.

Procure o log. 🐒🔎☕