☕ Um Café no Bellacosa Mainframe

Kojak Entra no CPD — O Caso do Db2 que Tinha um IMS Escondido no Porão

Ou: como uma chave composta de 47 bytes entregou a árvore genealógica do sistema, por que uma tabela pode agir como arquivo e o que QSAM, VSAM, DL/I e Edgar Codd estavam fazendo na mesma cena do crime

Prólogo — Quem ama você, banco de dados?

Era uma tarde comum no CPD, o que significa que nada estava realmente comum.

O processamento batch havia terminado com RC=00, os operadores respiravam aliviados e um programador COBOL iniciante recebera uma manutenção considerada pequena: incluir uma nova forma de consultar lançamentos de conta. O pedido parecia inocente. Bastava localizar os lançamentos por documento, sem informar empresa, filial, cliente e contrato.

Ele abriu a tabela no Db2 e encontrou a primeira pista: uma chave composta tão longa que parecia a ficha criminal de metade de Nova York.

CD-EMPRESA
CD-FILIAL
NR-CLIENTE
NR-CONTRATO
TP-PRODUTO
NR-PARCELA
NR-SEQUENCIA

Para alcançar o lançamento, todos os programas percorriam a mesma rota. Primeiro encontravam o cliente. Depois a conta. Depois o contrato. Finalmente chegavam ao movimento. Havia SQL por toda parte, mas o cheiro era de DL/I.

Foi quando a porta do CPD se abriu. Entrou o detetive Kojak, sobretudo impecável, olhar desconfiado e pirulito no lugar onde outros investigadores carregariam um cachimbo.

Ele observou o diagrama de tabelas e fez a pergunta que ninguém queria ouvir:

“Se isto é relacional, por que todo mundo precisa entrar pela mesma porta?”

Silêncio.

O Db2 era moderno. O COBOL compilava. O catálogo estava disponível. Mas alguma coisa antiga vivia no porão. Não era exatamente um defeito de software. Era uma maneira de pensar.

O caso estava aberto.

1. A primeira testemunha: hierarquia não é crime

Kojak começou eliminando uma suspeita comum: a hierarquia.

Hierarquias existem naturalmente no mundo real:

uma empresa possui departamentos;
um departamento possui funcionários;
um pedido possui itens;
uma conta recebe lançamentos;
um país possui estados e municípios;
um produto pode conter componentes;
um gerente pode supervisionar outros funcionários.

Portanto, encontrar uma estrutura pai-filho dentro de um banco relacional não significa encontrar o culpado. O modelo relacional representa hierarquias sem dificuldade. Uma tabela pode referenciar a si mesma, como ocorre numa estrutura de funcionários e gerentes:

CREATE TABLE FUNCIONARIO (
    ID_FUNCIONARIO BIGINT NOT NULL,
    ID_GERENTE     BIGINT,
    NOME           VARCHAR(100) NOT NULL,
    PRIMARY KEY (ID_FUNCIONARIO),
    FOREIGN KEY (ID_GERENTE)
       REFERENCES FUNCIONARIO (ID_FUNCIONARIO)
);

O problema não é existir pai e filho. O problema é o filho somente poder ser encontrado depois que o programa percorre toda a linhagem familiar.

Num modelo hierárquico, a navegação faz parte essencial da estrutura. Imagine:

CLIENTE
  └── CONTA
       └── LANÇAMENTO

Para localizar determinado lançamento, tradicionalmente se encontra o cliente, dentro dele a conta e, dentro dela, o lançamento. É como um detetive que só pode chegar ao apartamento 32 entrando primeiro na delegacia, passando pelo arquivo central e pedindo autorização ao síndico.

No modelo relacional, o lançamento pode possuir identidade própria:

SELECT *
  FROM LANCAMENTO
 WHERE ID_LANCAMENTO = 987654;

Também pode ser encontrado pela conta:

SELECT *
  FROM LANCAMENTO
 WHERE ID_CONTA = 12345;

Ou associado ao cliente:

SELECT L.*
  FROM CLIENTE C
  JOIN CONTA A
    ON A.ID_CLIENTE = C.ID_CLIENTE
  JOIN LANCAMENTO L
    ON L.ID_CONTA = A.ID_CONTA
 WHERE C.ID_CLIENTE = 100;

A família continua existindo. O que desaparece é a obrigação de visitar o avô antes de perguntar pelo neto.

Kojak anotou no bloco:

Hierarquia: liberada por falta de provas. Prisão de caminho: permanece sob investigação.

2. IMS presta depoimento — a cidade construída com ruas predefinidas

O IMS não tentou esconder sua natureza. Ele trabalha com segmentos organizados hierarquicamente. Existe uma raiz e, abaixo dela, segmentos dependentes.

CLIENTE
├── ENDEREÇO
├── TELEFONE
└── CONTA
    └── LANÇAMENTO

Cada ocorrência de CONTA pertence a determinado CLIENTE. Cada LANÇAMENTO está subordinado a uma CONTA. Para navegar, a aplicação utiliza chamadas DL/I, entre elas:

GU — Get Unique;
GN — Get Next;
GNP — Get Next Within Parent;
ISRT — Insert;
REPL — Replace;
DLET — Delete.

Há uma diferença importante entre perguntar o que se deseja e informar como navegar. No IMS, o programa conhece a estrutura e percorre seus caminhos. O DBD descreve a organização do banco. PSBs e PCBs ajudam a definir as visões e os acessos permitidos às aplicações.

Isso não faz do IMS um criminoso antiquado. Seria uma conclusão preguiçosa. IMS é uma tecnologia madura, sofisticada e extremamente eficiente para grandes volumes transacionais e caminhos previsíveis. Índices secundários e logical relationships ampliam as possibilidades de acesso. Seu desempenho, estabilidade e integração com o ambiente transacional ajudaram a sustentar sistemas críticos durante décadas.

O detetive experiente não confunde idade com culpa.

O IMS funciona muito bem quando:

as relações pai-filho são naturais e estáveis;
os caminhos de navegação são conhecidos;
o volume transacional exige comportamento previsível;
a hierarquia representa fielmente o domínio;
as aplicações foram desenhadas para esse modelo.

As dificuldades aparecem quando surgem muitas relações muitos-para-muitos, quando consultas inesperadas precisam atravessar a árvore em novas direções ou quando uma mudança estrutural afeta muitos programas.

O IMS declarou:

“Eu nunca prometi ser relacional. Se encontraram minha árvore escondida dentro do Db2, interroguem quem fez a migração.”

Kojak concordou. O depoimento era consistente.

3. Db2 entra na sala — tabela não é apenas arquivo com gravata

No modelo relacional, a unidade lógica é a relação, normalmente representada como tabela. Cada tabela deveria expressar um tipo claro de fato.

Por exemplo:

CLIENTE
ID_CLIENTE | NOME | DATA_NASCIMENTO

Cada linha afirma:

Existe um cliente identificado por este código, com este nome e esta data de nascimento.

Outra tabela:

CONTA
ID_CONTA | ID_CLIENTE | DATA_ABERTURA | SITUACAO

Cada linha afirma:

Existe uma conta identificada por este código, relacionada a determinado cliente.

A relação não deveria depender apenas de um programa COBOL saber que CONTA.ID_CLIENTE combina com CLIENTE.ID_CLIENTE. Ela pode e, quando apropriado, deve ser declarada:

ALTER TABLE CONTA
  ADD CONSTRAINT FK_CONTA_CLIENTE
  FOREIGN KEY (ID_CLIENTE)
  REFERENCES CLIENTE (ID_CLIENTE);

Quando a regra existe apenas no programa, temos uma convenção. Quando está declarada como constraint, temos uma regra central protegida pelo SGBD.

Outra característica fundamental: o SQL é declarativo. Em geral, o programador informa o resultado desejado; o otimizador analisa estatísticas, índices, cardinalidades, custos e alternativas para escolher um caminho físico.

SELECT C.NOME,
       A.ID_CONTA,
       SUM(L.VALOR) AS TOTAL
  FROM CLIENTE C
  JOIN CONTA A
    ON A.ID_CLIENTE = C.ID_CLIENTE
  JOIN LANCAMENTO L
    ON L.ID_CONTA = A.ID_CONTA
 WHERE L.DATA_MOVIMENTO >= :WS-DATA-INICIAL
 GROUP BY C.NOME, A.ID_CONTA;

O programa formula a pergunta. O Db2 decide se utilizará determinado índice, qual tabela acessará primeiro e qual estratégia de join será mais adequada.

Essa separação entre visão lógica e implementação física é uma das grandes ideias do modelo relacional. O programa não deveria precisar memorizar cada corredor do depósito.

4. A impressão digital: a chave de 47 bytes

O primeiro indício concreto apareceu nas chaves.

CLIENTE
  CD_EMPRESA + CD_FILIAL + NR_CLIENTE

CONTA
  CD_EMPRESA + CD_FILIAL + NR_CLIENTE + NR_CONTA

LANCAMENTO
  CD_EMPRESA + CD_FILIAL + NR_CLIENTE + NR_CONTA
  + DATA_MOVIMENTO + SEQUENCIA

Chave composta não é ilegal. Às vezes, a identidade verdadeira de um fato é composta. O item de um pedido pode ser identificado pelo pedido e pelo número do item. Uma ocorrência de tabela associativa pode usar as chaves das duas entidades relacionadas.

A pista suspeita é outra: cada descendente carregar todos os códigos de seus ancestrais apenas para reproduzir o caminho antigo.

Uma alternativa seria:

CLIENTE
  ID_CLIENTE PK

CONTA
  ID_CONTA PK
  ID_CLIENTE FK

LANCAMENTO
  ID_LANCAMENTO PK
  ID_CONTA FK

Cada entidade possui identidade própria e relacionamentos explícitos. Alterar um vínculo não exige necessariamente redefinir a identidade inteira do registro.

Mas Kojak não aceitava soluções automáticas. Substituir todas as chaves naturais por números artificiais também pode esconder regras. A decisão correta exige perguntas:

A chave natural é realmente estável?
Pode mudar por correção, fusão empresarial ou legislação?
É grande demais para se propagar por todas as tabelas?
Expõe CPF, conta ou outra informação sensível?
Possui significado duradouro?
A chave técnica substituta será acompanhada de uma UNIQUE para proteger a regra do negócio?

Uma prática frequente é utilizar uma chave substituta como primary key e proteger a chave natural com unique constraint.

CREATE TABLE CLIENTE (
    ID_CLIENTE BIGINT       NOT NULL,
    CPF        CHAR(11),
    NOME       VARCHAR(100) NOT NULL,
    CONSTRAINT PK_CLIENTE
       PRIMARY KEY (ID_CLIENTE),
    CONSTRAINT UK_CLIENTE_CPF
       UNIQUE (CPF)
);

O número técnico fornece estabilidade. A constraint sobre CPF preserva a regra definida pelo negócio — considerando, naturalmente, estrangeiros, dados incompletos e demais exceções reais.

5. O crime do `SELECT` em série

Kojak encontrou outro padrão no fonte:

selecionar um cliente;
para esse cliente, selecionar suas contas;
para cada conta, selecionar lançamentos;
para cada lançamento, consultar sua descrição;
repetir milhares de vezes.

Em espírito:

SELECT CLIENTE
  SELECT CONTA
    SELECT LANCAMENTO
      SELECT TIPO_LANCAMENTO

Era DL/I encenando uma peça de SQL.

Esse processamento linha a linha pode gerar enorme quantidade de chamadas e o conhecido problema de consultas repetitivas. O pensamento relacional procura operar sobre conjuntos:

SELECT C.ID_CLIENTE,
       A.ID_CONTA,
       T.DESCRICAO,
       SUM(L.VALOR) AS TOTAL
  FROM CLIENTE C
  JOIN CONTA A
    ON A.ID_CLIENTE = C.ID_CLIENTE
  JOIN LANCAMENTO L
    ON L.ID_CONTA = A.ID_CONTA
  JOIN TIPO_LANCAMENTO T
    ON T.ID_TIPO = L.ID_TIPO
 GROUP BY C.ID_CLIENTE,
          A.ID_CONTA,
          T.DESCRICAO;

Isso não significa escrever um SQL gigantesco, impossível de compreender e tratar. Significa identificar quando o banco pode resolver uma operação de conjunto melhor do que o COBOL percorrendo cada galho individualmente.

O desempenho deve ser medido. Um join bem modelado, com estatísticas e índices adequados, pode ser excelente. Um SQL mal escrito também pode ser desastroso. A teoria relacional não dispensa análise do access path, EXPLAIN, cardinalidade, distribuição e custo.

Como diria Kojak, gostar de SQL não fornece álibi para um SELECT * sem critério numa tabela de bilhões de linhas.

6. O cúmplice invisível: integridade mantida apenas pelo COBOL

Em vários sistemas, o programa verifica manualmente se o cliente existe antes de inserir a conta:

EXEC SQL
   SELECT COUNT(*)
     INTO :WS-COUNT
     FROM CLIENTE
    WHERE ID_CLIENTE = :WS-ID-CLIENTE
END-EXEC

IF WS-COUNT > 0
   EXEC SQL
      INSERT INTO CONTA (...)
      VALUES (...)
   END-EXEC
END-IF

O código parece cuidadoso, mas a regra pode estar duplicada em dezenas de programas. Além disso, existe uma janela de concorrência entre verificar e inserir.

A foreign key permite ao banco proteger a relação:

FOREIGN KEY (ID_CLIENTE)
REFERENCES CLIENTE (ID_CLIENTE)

O COBOL continua responsável por tratar SQLCODE, produzir mensagens adequadas e controlar a unidade de trabalho. O COMMIT continua sendo parte da história. A diferença é que a integridade não depende de todos os programas se lembrarem da mesma regra para sempre.

Naturalmente, há ambientes que evitam constraints por razões históricas, cargas em grande volume, replicação, desenho distribuído ou receio de custo. Algumas razões podem ser legítimas; outras apenas repetem crenças não medidas desde 1994.

A pergunta saudável é:

Se o banco não protege esta relação, quem protege, como protege e como provamos que funciona em todos os caminhos de atualização?

Se ninguém consegue responder, temos um suspeito sem vigilância.

7. QSAM — a testemunha que só anda para a frente

QSAM aparece diariamente no processamento batch do z/OS. É usado com datasets sequenciais para entradas, saídas, relatórios, arquivos de erro, cargas e intercâmbios.

READ ARQ-CLIENTES
   AT END
      SET FIM-ARQUIVO TO TRUE
END-READ

O significado dos bytes costuma estar num copybook:

01  REG-CLIENTE.
    05 REG-ID       PIC 9(09).
    05 REG-NOME     PIC X(40).
    05 REG-STATUS   PIC X(01).

QSAM é excelente para uma grande varredura sequencial. Se o objetivo é ler quarenta milhões de registros do começo ao fim, aplicar uma transformação e produzir uma saída, a simplicidade sequencial pode ser uma virtude.

Porém, QSAM não fornece por si só join, foreign key ou integridade referencial entre datasets. O sistema operacional não deduz que os bytes de determinada posição representam uma relação com outro arquivo. Essa semântica vive no copybook, nos programas e nos procedimentos.

Uma curiosidade importante: dataset é um conceito amplo no z/OS. QSAM é um método de acesso, não um banco de dados. Dizer “dataset versus QSAM” seria misturar o recipiente com uma das formas de acessá-lo.

Kojak interrogou o arquivo sequencial. Ele respondeu:

“Eu só leio do começo ao fim. Não fui eu quem prometeu relacionamento.”

Álibi aceito.

8. VSAM — a testemunha com índice e acesso direto

VSAM oferece diferentes organizações. Entre as mais conhecidas:

KSDS — registros organizados por chave, com acesso direto e sequencial;
ESDS — registros preservados em ordem de entrada, acessíveis também por endereço relativo;
RRDS — registros associados a números relativos;
LDS — espaço linear utilizado por componentes e casos específicos.

No COBOL, um KSDS pode ser acessado pela chave:

READ ARQ-CLIENTE
   KEY IS WS-ID-CLIENTE
   INVALID KEY
      CONTINUE
END-READ

O KSDS encontra registros rapidamente e pode suportar aplicações muito eficientes. Contudo, dois clusters com campos semelhantes não ganham automaticamente integridade referencial.

Se CONTA contém ID-CLIENTE, é a aplicação que normalmente impede uma conta órfã. Excluir o registro do cliente não dispara por natureza uma verificação relacional em todos os outros arquivos.

VSAM não é um Db2 incompleto. É outra ferramenta, com outro modelo operacional. Pode ser exatamente o que determinada solução necessita. O erro está em copiar um KSDS para uma tabela e acreditar que a presença de SQL realizou toda a modelagem.

Uma tabela usada somente por chave, sem constraints, com ordem física presumida e todas as regras no COBOL pode ser, conceitualmente, um KSDS mais caro usando crachá de banco relacional.

9. A comparação no mural da delegacia

Tecnologia	Estrutura predominante	Acesso típico	Relacionamentos	Onde vive a semântica
QSAM	sequência de registros	leitura e gravação sequencial	mantidos pela aplicação	copybook e programas
VSAM KSDS	registros indexados por chave	chave e sequência de chave	mantidos principalmente pela aplicação	cluster, copybook e programas
IMS	segmentos hierárquicos	navegação DL/I	pai-filho estruturado	DBD, PSB/PCB e aplicação
Db2	conjuntos de fatos relacionados	SQL declarativo	PK, FK, valores e constraints	catálogo, modelo e aplicação

Nenhuma linha desta tabela declara um vencedor absoluto. O bom arquiteto escolhe conforme:

natureza dos dados;
padrão de acesso;
volume;
concorrência;
integridade necessária;
recuperação;
capacidade de mudança;
necessidade de consultas novas;
conhecimento e operação disponíveis.

Tecnologia não é concurso de beleza. É adequação ao caso.

10. Boa modelagem: a vítima precisa ser identificada

Kojak colocou uma tabela sob a luz e perguntou:

“Cada linha representa exatamente o quê?”

Essa é uma das melhores perguntas de modelagem.

Respostas claras:

um cliente;
uma conta;
um lançamento;
a participação de um aluno numa turma;
a titularidade de um cliente numa conta durante determinado período.

Resposta suspeita:

“É cliente, contrato, endereço atual, última cobrança e alguns campos reservados que dependem do tipo do registro.”

Provavelmente há vários conceitos misturados.

Uma boa tabela tem identidade clara, atributos coerentes e regras compreensíveis. Os nomes ajudam, mas não bastam. É preciso conhecer o significado, a granularidade e o ciclo de vida do fato.

O teste da dependência

Pergunte sobre cada atributo:

Este valor depende de quê?

Se o limite de crédito pertence à conta, não deve morar em CLIENTE apenas porque hoje existe uma conta por cliente. Se a taxa depende do produto e da vigência, talvez exija uma estrutura histórica própria.

Esse raciocínio conduz à normalização.

11. Normalização — separando suspeitos que estavam na mesma cela

Normalizar não significa fragmentar o banco até que uma consulta precise de 83 joins. Significa reduzir redundâncias e evitar anomalias.

Primeira forma normal

Evite listas escondidas em uma coluna:

TELEFONES = "11999999999;11888888888;11777777777"

Essa estrutura dificulta pesquisa, validação, indexação e alteração individual.

Também desconfie de:

TELEFONE_1
TELEFONE_2
TELEFONE_3

O quarto telefone já está a caminho da delegacia.

Uma tabela CLIENTE_TELEFONE permite representar zero, um ou muitos números, com tipo, preferência e validade.

Segunda forma normal

Se uma tabela possui chave composta, os atributos não-chave devem depender da chave inteira.

Em ITEM_PEDIDO, identificado por ID_PEDIDO + NR_ITEM, o nome do cliente depende do pedido, não do item completo. A descrição permanente do produto depende do produto, não da combinação pedido-item.

Terceira forma normal

Os atributos não-chave não deveriam depender de outros atributos não-chave.

Se CLIENTE contém ID_CIDADE, NOME_CIDADE e UF, e os dois últimos dependem de ID_CIDADE, talvez pertençam a uma tabela CIDADE.

Desnormalização consciente

Há casos legítimos de repetição: snapshots, relatórios históricos, data warehouses, integrações e otimizações comprovadas.

A diferença é simples:

redundância acidental cria várias versões da verdade;
redundância deliberada possui fonte oficial, momento de cópia e mecanismo de reconciliação.

Desnormalizar antes de medir é apresentar uma confissão antes mesmo de conhecer o crime.

12. Muitos-para-muitos: quando havia mais de dois suspeitos

Um cliente pode participar de várias contas. Uma conta pode ter vários titulares.

Um modelo frágil cria:

ID_CLIENTE_1
ID_CLIENTE_2
ID_CLIENTE_3

Além do limite arbitrário, cada consulta precisa tratar colunas diferentes.

O modelo relacional representa o relacionamento por meio de uma tabela associativa:

CLIENTE
  ID_CLIENTE

CONTA
  ID_CONTA

CONTA_TITULAR
  ID_CONTA
  ID_CLIENTE
  TIPO_TITULARIDADE
  DATA_INICIO
  DATA_FIM

CONTA_TITULAR não é uma gambiarra técnica. Ela representa um fato real:

Este cliente participa desta conta, neste papel e durante este período.

Se o relacionamento possui atributos próprios, ele merece ser tratado como conceito do negócio.

13. `NULL`, branco e zero: três suspeitos com rostos diferentes

Nos sistemas antigos, é comum encontrar campos nos quais branco, zero, noves e datas impossíveis representam estados especiais.

No banco relacional, NULL representa ausência de valor, mas a ausência precisa ter significado controlado. Ela não deveria significar ao mesmo tempo:

não informado;
não existe;
não se aplica;
ainda será calculado;
ocorreu erro;
veio vazio no arquivo legado.

Esses estados podem exigir uma coluna de situação ou motivo.

Também é perigoso criar defaults apenas para evitar NULL. Uma data 1900-01-01 pode parecer conveniente, mas obriga todas as consultas a conhecer o código secreto. O default deve representar um valor verdadeiro, não uma cortina para esconder desconhecimento.

14. O álibi temporal: como o dado estava ontem?

Muitos modelos funcionam bem até alguém perguntar:

“Qual era a situação da conta no fechamento do mês passado?”

Se cada atualização substitui a linha anterior, a história desaparece.

Para cada data, pergunte:

é data de ocorrência?
é data de processamento?
é início ou fim de vigência?
períodos podem se sobrepor?
alterações retroativas são permitidas?
quem alterou o dado e quando?
precisamos reconstruir o estado de uma data passada?

Tempo de negócio e tempo de sistema são conceitos diferentes. Um pagamento pode ocorrer numa sexta-feira, ser recebido no sábado e processado na segunda. Misturar essas datas produz investigações contábeis dignas de uma temporada inteira.

15. Passo a passo da investigação de um modelo

Passo 1 — Escreva as regras em português

Antes do CREATE TABLE, registre frases:

um cliente pode participar de várias contas;
uma conta pode possuir vários titulares;
uma conta pode existir sem lançamentos;
cada lançamento pertence a exatamente uma conta;
o cancelamento não apaga o lançamento original;
a titularidade possui início, fim e tipo.

Essas frases revelam entidades, cardinalidades, opcionalidade e tempo.

Passo 2 — Identifique entidades, eventos e classificações

entidades: cliente, conta, produto;
eventos: pagamento, transferência, lançamento;
classificações: tipo de conta, moeda, situação.

Evite uma tabela genérica que represente tudo por meio de um código de tipo e centenas de colunas opcionais.

Passo 3 — Defina cardinalidades

Pergunte se o relacionamento é obrigatório, opcional, único, múltiplo e temporal. Não deduza a cardinalidade apenas do layout antigo.

Passo 4 — Escolha as chaves

Analise estabilidade, tamanho, significado, privacidade e possibilidade de mudança. Diferencie identidade técnica de unicidade do negócio.

Passo 5 — Declare constraints

Use PRIMARY KEY, FOREIGN KEY, UNIQUE, NOT NULL e CHECK quando correspondem a regras verdadeiras.

Passo 6 — Teste o ciclo de vida

Simule cadastro, correção, cancelamento, reativação, transferência, evento retroativo, auditoria, anonimização e consulta histórica.

Passo 7 — Escreva consultas reais

Valide se o modelo responde às perguntas essenciais do negócio sem depender de códigos secretos e sequências implícitas.

Passo 8 — Projete o físico

Depois do modelo lógico, trate índices, particionamento, clustering, compressão, tablespaces, estatísticas, concorrência, recuperação, retenção e padrões batch.

Um índice encontra rapidamente o dado. Não consegue decidir se o dado deveria estar ali.

16. Cuidado ao prender o culpado: constraints numa base histórica

Ao modernizar um sistema, alguém pode decidir criar todas as foreign keys numa sexta-feira à tarde. Péssimo horário para heroísmo.

Antes de ativar constraints, investigue:

quantos registros órfãos existem;
quais programas atualizam cada tabela;
quais cargas dependem de ordem especial;
como funcionam deleções e cancelamentos;
quais dados chegam atrasados;
como será feita a correção;
qual é o plano de rollback;
qual impacto existe em disponibilidade e desempenho.

Se a foreign key encontrar milhões de órfãos, ela não criou o crime. Apenas acendeu a luz da sala de evidências.

Uma modernização segura pode usar views, serviços, reconciliações, constraints inicialmente informativas quando disponíveis e adequadas, correção gradual dos dados e migração por domínios.

17. Checklist de Kojak para descobrir um IMS usando SQL

Pegue uma tabela e responda:

Cada linha representa exatamente o quê?
Qual regra torna a linha única?
A chave representa identidade ou o caminho até a raiz?
Quais foreign keys existem e quais deveriam existir?
Há registros órfãos?
Existem listas dentro de colunas?
Existem campos numerados como TELEFONE_1, TELEFONE_2 e TELEFONE_3?
O mesmo fato aparece em várias tabelas?
Qual tabela é a fonte oficial?
Algum programa depende de ordem sem ORDER BY?
Existem SELECTs aninhados que imitam pai-filho-neto?
As regras estão no banco ou espalhadas por COBOL, Java, ETL e planilhas?
É possível reconstruir o passado?
Branco, zero, noves e NULL têm significados documentados?
Alterar um relacionamento muda a identidade do registro?
Uma nova consulta exige começar sempre pela mesma tabela raiz?
O desenho nasceu do negócio ou foi copiado de um arquivo?

Quanto mais respostas desconfortáveis, maior a chance de existir um modelo navegacional escondido sob a camada SQL.

Epílogo — Caso encerrado, pirulito devolvido

Kojak reuniu todos no CPD.

QSAM não era culpado. Fazia muito bem seu trabalho sequencial e nunca prometera relacionamentos.

VSAM também possuía um álibi. Sabia localizar registros por chave, mas não alegava conhecer automaticamente as relações de negócio entre clusters.

IMS admitia sua hierarquia desde o primeiro interrogatório. Seus caminhos eram parte do projeto e podiam oferecer enorme desempenho quando combinavam com o problema.

Db2, por sua vez, oferecia tabelas, constraints, SQL declarativo, otimização e operações de conjunto. Mas nenhuma versão moderna do produto poderia impedir uma equipe de reproduzir dentro dele a mentalidade de arquivos e segmentos.

O culpado não era uma tecnologia. Era a migração sem remodelagem, acompanhada pela crença de que mudar READ para SELECT transformaria automaticamente registros em relações.

Uma boa modelagem relacional apresenta:

conceitos com fronteiras claras;
linhas com identidade inequívoca;
atributos dependentes do fato correto;
relacionamentos declarados;
cardinalidades fiéis ao negócio;
regras protegidas perto dos dados;
tempo e ausência com significado;
redundância consciente, quando necessária;
liberdade para consultar por diferentes perspectivas;
separação entre a pergunta lógica e o caminho físico.

O programador COBOL olhou novamente para a chave de 47 bytes. Pela primeira vez, não viu apenas campos concatenados. Viu uma árvore genealógica, uma rota de navegação e décadas de decisões arquitetônicas preservadas como impressões digitais.

Kojak colocou o pirulito na boca, caminhou em direção à saída e deixou sua última observação:

“Uma tabela pode morar no Db2 e ainda pensar como arquivo. Quem ama você, banco de dados? Porque seus programas claramente amam o caminho mais longo.”

Naquela noite, ninguém reescreveu o sistema inteiro. Em vez disso, a equipe documentou as regras, mediu os órfãos, identificou as fontes oficiais e começou a melhorar o próximo domínio.

Era menos cinematográfico do que uma prisão.

Mas, em arquitetura de dados, evitar o próximo crime costuma valer mais do que posar ao lado do culpado.

Translate

sexta-feira, 7 de julho de 2023