✨ Bem-vindo ao meu espaço! ✨
Este blog é o diário de um otaku apaixonado por animes, tecnologia de mainframe e viagens.
Cada entrada é uma mistura única: relatos de viagem com fotos, filmes, links, artigos e desenhos, sempre buscando enriquecer a experiência de quem lê.
Sou quase um turista profissional: adoro dormir em uma cama diferente, acordar em um lugar novo e registrar tudo com minha câmera sempre à mão.
Entre uma viagem e outra, compartilho também reflexões sobre cultura otaku/animes
🔍 COBOL Mainframe e o Código Legado: sobreviver, entender e não quebrar produção
Se você trabalha com COBOL no mainframe, preciso ser honesto logo de início:
👉 Seu trabalho provavelmente não é escrever código novo. 👉 Seu trabalho é entender código antigo o suficiente para não destruir um sistema que sustenta a empresa.
Este post é inspirado no IBM COBOL Software Development Practices – Module 3: Working with Existing Code, mas com uma diferença fundamental:
📌 aqui não tem romantização, marketing nem slide bonito. 📌 aqui tem legado, risco, produção e decisões difíceis.
1️⃣ A verdade que poucos cursos falam em voz alta
Muitos analistas acertam quando dizem que o foco do COBOL hoje não é criar sistemas novos do zero.
A realidade é esta:
código escrito por pessoas que já se aposentaram
regras de negócio que nunca foram documentadas
batch que roda há 15, 20, 30 anos
sistemas que não podem parar
Trabalhar com legado não é atraso tecnológico. 👉 É engenharia em ambiente hostil.
2️⃣ Identificar mudanças não é caçar erro
Um dos maiores erros de quem começa no legado é confundir:
❌ “isso está feio” com ✅ “isso está errado”
Antes de pensar em mudar qualquer linha, você deveria conseguir responder:
isso é bug ou regra de negócio?
esse código roda sempre ou só em exceção?
quem consome essa saída além do que aparece no programa?
📍 Situação real: Você encontra um IF gigante, cheio de GO TO e NEXT SENTENCE.
Junior pensa:
“Vou refatorar isso tudo.”
Mainframeiro experiente pensa:
“Onde está o dump? Qual batch chama isso? Quem usa esse arquivo?”
👉 No legado, entender vem antes de melhorar.
3️⃣ Decidir quanto mudar: o princípio do Do No Harm
Esse é o ponto mais valioso do módulo — e o mais ignorado na prática.
No mainframe, nem tudo que está errado deve ser corrigido.
Escala real de decisão:
🔴 Não mexer – código crítico, sem teste, sem histórico
Não é só em curso. Não é só ferramenta. Mas sim após horas de trabalho, analisando fluxogramas amarelados, ficando vesgo de analisar listagem de programas e apontar duvidas.
O ciclo real é:
ler o código
rodar o batch
analisar o dump
entender impacto
decidir não mexer
documentar
só então, talvez, mudar
☕ Conclusão Bellacosa Mainframe
Os conselhos, workshops, a literatura e o curso tem a mentalidade correta. A trincheira ensina o resto.
No mainframe:
O melhor programador não é o que escreve o código mais bonito.É o que entende o legado, muda pouco, documenta bem e mantém o sistema vivo.
Se você vive isso no dia a dia, comenta aqui 👇
🔹 Já encontrou código que parecia errado, mas salvava produção?
Bellacosa Mainframe apresenta o anime Level 1 Dakedo Unique skill de saikyou desu
☕ Bellacosa Anime
Level 1 dakedo Unique Skill de Saikyou desu
O isekai em que o sujeito morreu de excesso de trabalho e renasceu numa economia onde até cenoura precisa cair de slime
Ficha
Informação
Título original
レベル1だけどユニークスキルで最強です
Romanização
Level 1 dakedo Unique Skill de Saikyō desu
Título ocidental
My Unique Skill Makes Me OP Even at Level 1
Autor
Nazuna Miki
Light novel
Ilustrações de Subachi
Mangá
Arte de Mawata
Estúdio
Maho Film
Diretor
Yūji Yanase
Composição da série
Yuka Yamada
Lançamento do anime
8 de julho de 2023
Exibição final
23 de setembro de 2023
Episódios
12
Gêneros
Isekai, fantasia, aventura, comédia, harém leve, dungeon e slice of life
Classificação indicativa sugerida
14+
Streaming
Crunchyroll; também consta em alguns catálogos regionais da Netflix
A série adapta a obra de Nazuna Miki, publicada originalmente como web novel no Shōsetsuka ni Narō entre 2017 e 2020. A light novel terminou com 9 volumes em 2023; o mangá segue como a versão mais longa da história, com 17 volumes compilados registrados. Ficha editorial da Kodansha, dados da adaptação.
Sinopse
Ryota Satō é um trabalhador japonês que morre de excesso de trabalho. Não é atropelado por caminhão-kun, não enfrenta demônio-rei, não recebe uma despedida épica: simplesmente é consumido pela rotina de uma empresa exploradora.
Ele reencarna em um mundo onde tudo cai de monstros nas dungeons. Comida, dinheiro, roupas, armas, materiais de construção — tudo depende de alguém entrar numa masmorra e produzir.
O problema: Ryota está permanentemente preso no nível 1.
A solução: sua taxa de drop é absurdamente rara, de categoria S. Ele não evolui pela escada convencional de XP; evolui obtendo itens que aumentam seus atributos, criando munições especiais, encontrando recursos escassos e entendendo o sistema econômico daquele mundo melhor do que seus habitantes.
É o típico protagonista OP, mas com uma diferença: em vez de só humilhar nobres e dragões, Ryota começa a montar uma pequena infraestrutura de sobrevivência para gente que estava sozinha.
Resumo da história: o nível 1 que virou administrador de recursos
O primeiro contato de Ryota com o novo mundo já resume a proposta: ele é “dropado” por um slime e encontrado por Emily Brown, uma aventureira coelhinha de aparência fofíssima e martelo gigantesco.
Emily lhe explica as regras: dungeons produzem recursos, cada pessoa tem capacidades próprias e o poder social está ligado ao que se consegue coletar. Ryota descobre que, embora jamais vá subir de nível, seus drops S permitem compensar isso com equipamentos e itens que ninguém mais consegue obter.
A história avança em torno de dungeons, guildas, monstros, colheitas e novas companheiras de party. Mas a aventura não é sobre salvar o planeta de um rei demônio. É sobre transformar uma vida que seria de exploração em um lar.
Ryota reúne Emily, a maga Celeste, a garota coelho Eve, a elétrica Alice e outras figuras que chegam carregando seus próprios vazios. A casa dele vira uma espécie de operação doméstica de alta disponibilidade: comida, trabalho dividido, apoio emocional, proteção e alguém para voltar a encontrar ao fim do dia.
No fundo, o anime diz uma coisa muito simples: depois de morrer porque ninguém se importava com ele, Ryota decide que ninguém perto dele será tratado apenas como recurso.
O que parece e o que realmente é
Visualmente, Level 1 parece um isekai para vender chaveirinho:
paleta colorida;
garotas fofas;
monstros pouco ameaçadores;
cenouras caindo de slimes;
diminutivos, piadas e fanservice;
uma coelhinha simpática carregando um martelo maior que ela.
Mas o subsolo é bem mais escuro.
Quase todos os personagens vivem alguma forma de abandono, exploração, solidão, dependência ou insegurança. A fofura funciona como cobertor: primeiro o espectador baixa a guarda; depois percebe que há um mundo inteiro de pessoas feridas tentando sobreviver.
Você percebeu bem essa contradição. Não é um anime triste no estilo de Made in Abyss, que anuncia sofrimento desde o começo. É mais estranho: ele parece leve, mas deixa escapar pequenas histórias de pessoas que nunca tiveram uma base emocional segura.
Ryota Satō: o herói que não quer virar chefe tóxico
Ryota é OP, mas não é agressivamente exibicionista. Ele não tem grande ambição de domínio, título ou exército. O desejo dele é quase humilde: ter uma casa, uma rotina e pessoas que gostem de sua presença.
A morte por excesso de trabalho é o ponto de partida da obra. Por isso Ryota funciona melhor quando age como antítese da vida anterior:
Vida anterior
Vida no novo mundo
Era descartável
Torna-se necessário sem explorar os demais
Trabalhava até morrer
Divide tarefas e recursos
Não tinha pertencimento
Forma uma família improvisada
Era medido por produtividade
Passa a enxergar pessoas além de sua utilidade
Não controlava a própria vida
Escolhe como usar poder e riqueza
O rapaz no nível 1 é uma crítica discreta a rankings. O sistema o registra como fraco; a realidade demonstra que ele é excepcional. É uma boa metáfora para quem passou anos sendo classificado por cargo, título ou régua corporativa, enquanto fazia o trabalho que realmente segurava a operação.
Em linguagem Bellacosa Mainframe: o painel mostra “nível 1”, mas o cara é o único que entendeu o JCL, os datasets, o gargalo do batch e a regra de negócio escondida no copybook.
Emily Brown: fofura, marreta e exaustão
Emily é provavelmente a alma da série.
Ela aparece como personagem cômica — uma coelhinha de martelo, forte, meiga e inclinada a trabalhar demais. Só que sua energia constante esconde uma realidade pesada: ela está acostumada a sobreviver pelo esforço, a carregar peso literal e emocional, e a não esperar que alguém cuide dela.
Ryota não “salva” Emily como prêmio romântico. O que ele faz é mais importante: cria condições para ela não precisar se destruir para existir.
A cena cotidiana de dividir comida, descansar, cuidar da casa ou fazer uma refeição junto tem peso porque, para Emily, isso não é banalidade. É segurança.
Celeste, Eve, Alice e a party dos sobreviventes
A estrutura de harém existe, sim. Seria desonesto fingir que não. Mas ela é mais simpática do que em muitos isekais porque as personagens não entram somente para confirmar que o herói é desejável.
Celeste é a maga orgulhosa, inteligente e insegura; precisa provar que tem valor além do que os outros esperam dela.
Eve Callusleader carrega rejeição e desconfiança associadas à sua condição e origem.
Alice é energia pura, mas seu comportamento infantil e intenso também denuncia carência, abandono e busca de pertencimento.
A princesa Margaret é a grande ironia: possui título, palácio e empregados, mas pode ser manipulada e explorada dentro da própria casa.
Essa é uma das mensagens mais fortes do anime: status não é sinônimo de proteção.
A princesa é prova de que alguém pode estar no topo da hierarquia e ainda assim não ter autonomia. Uma pessoa pode ter empregados, mas continuar isolada; pode morar num palácio e viver numa prisão social.
A economia das dungeons: quando o RPG parece uma fábrica
O mundo de Ryota é uma ideia estranha e curiosa: não há produção normal como conhecemos. Cada dungeon entrega determinado recurso. Uma fornece vegetais; outra, dinheiro; outra, materiais ou monstros especiais.
Isso converte a fantasia em uma economia de extração.
A dungeon é ao mesmo tempo:
mina de recursos;
linha de produção;
fazenda;
supermercado;
local de trabalho;
fonte de dependência econômica.
Quem domina uma dungeon controla acesso a bens fundamentais. Quem controla aventureiros controla a produção. Quem controla a informação sobre drops obtém vantagem sobre todos.
Ryota não é só forte; ele é o personagem que entende supply chain. Ele vê um item raro e pergunta: “qual gargalo isso elimina?”. Um drop pode virar comida, remédio, construção, defesa, renda ou liberdade para alguém que estava preso a um explorador.
O sistema inteiro parece um mainframe sem documentação: todos dependem dele, poucos entendem suas regras e os oportunistas vivem de manipular quem precisa trabalhar lá dentro.
O velho explorador: o momento em que a dungeon deixa de ser brincadeira
O arco do velho que domina jovens aventureiros é o trecho que expõe a parte mais perturbadora da série.
Ele não explora apenas trabalho físico. Ele sequestra autonomia. Isola jovens, cria dependência, altera a percepção deles e os faz confundir obediência com gratidão.
É uma forma de abuso de poder muito real: pegar pessoas vulneráveis, cortar suas referências externas e convencê-las de que não há vida possível fora daquele ciclo.
A dungeon colorida vira fábrica-prisão.
Ryota o enfrenta não só derrotando um vilão. Ele devolve aos jovens a capacidade de decidir por si mesmos. E isso é importante: a obra trata liberdade como algo mais raro que poder de combate.
A mensagem é amarga: o monstro mais perigoso não precisa ter presas, chifres ou magia negra. Pode ser apenas alguém que aprendeu a transformar carência humana em mão de obra obediente.
Neptune Family: glamour, ambiguidade e uma piada que envelhece torta
Neptune e sua party são o espelho invertido do grupo de Ryota.
A família de Ryota é imperfeita, barulhenta e emocionalmente remendada, mas há cuidado real. A Neptune Family parece uma vitrine: bonita, forte, performática e quase artificialmente elegante.
Neptune é construído com postura afetada, vaidade, ambiguidade de gênero e comportamento de flerte. A cena em que ele passa a mão no rosto de Ryota e o encara de modo sugestivo realmente existe como linguagem visual de aproximação íntima. Não é apenas recrutamento profissional de party.
Mas o anime não desenvolve isso seriamente. Ele não confirma identidade ou orientação de Neptune; usa sua ambiguidade como gag, como elemento de estranhamento.
É uma limitação do texto. A mesma obra que consegue sugerir exploração, abandono e vulnerabilidade emocional usa a possível atração de um homem por outro como piada cômica. Não torna Neptune automaticamente um personagem mau, mas mostra uma convenção de anime que envelhece meio desalinhada.
As aventuras
As aventuras não giram tanto em torno de uma guerra épica. Elas são pequenos casos de dungeon e de comunidade:
Ryota aprende o funcionamento dos drops e melhora seus atributos.
A party enfrenta monstros específicos, inclusive inimigos que exigem balas especiais.
A economia das dungeons cria problemas de abastecimento e exploração.
Personagens isolados são acolhidos na casa e no grupo.
A guilda e outras parties revelam relações de poder e competição.
Festivais e eventos cotidianos mostram que a conquista principal é criar vida comum.
O grupo descobre que prosperar também traz novos riscos: atenção, burocracia, inveja e interesse externo.
É um anime de aventura sem grande pressa. A recompensa nunca é só matar o boss: é voltar para casa com todos vivos, comer junto e ter alguém para reclamar da quantidade de comida que caiu do monstro.
Temáticas e mensagens ocultas
1. Valor não é ranking
Ryota nunca deixa de ser nível 1. A série insiste que o sistema formal de avaliação pode estar errado. Cargo, XP, reputação ou título não resumem capacidade, caráter ou importância.
2. Produtividade sem cuidado destrói pessoas
Ryota morreu de excesso de trabalho. Emily se mata de trabalhar. Os jovens da dungeon são explorados. A fantasia fala de emprego sem pronunciar “corporate culture”.
3. Família pode ser construída
A party de Ryota não nasce de sangue ou tradição. Nasce de acolhimento. São pessoas que não sabiam pedir ajuda e descobrem que podem ficar.
4. Poder pode reproduzir abuso — ou interrompê-lo
Ryota recebe uma habilidade que poderia colocá-lo acima de todos. A questão do anime não é “ele vai vencer?”. É “ele vai tratar os outros como seu antigo chefe o tratava?”.
A resposta é o que torna o protagonista agradável.
O estúdio Maho Film
A Maho Film é um estúdio associado a produções de fantasia e isekai de orçamento moderado. Em Level 1, a animação não busca espetáculo cinematográfico constante. A prioridade é manter o tom leve, os personagens reconhecíveis e a progressão de dungeon clara.
Há limitações visíveis em ação e movimento, sobretudo se comparado a estúdios de primeira linha. Mas a direção de arte entende a missão: vender conforto visual. As cores, expressões faciais e design das personagens ajudam a sustentar a sensação de “mundo agradável”, justamente o contraste que torna os temas mais pesados perceptíveis.
O estúdio entrega um anime funcional, não uma aula de sakuga. Aqui, a qualidade está mais na coerência de clima do que em cenas de luta memoráveis.
Impacto cultural e recepção
O impacto cultural foi modesto. Level 1 não virou fenômeno do tamanho de Mushoku Tensei, Re:Zero, KonoSuba ou That Time I Got Reincarnated as a Slime.
Mesmo assim, encontrou público entre quem gosta de:
isekai confortável;
protagonistas OP educados;
economia de dungeon;
progressão de RPG;
romance/harém pouco agressivo;
histórias de “família encontrada”.
Seu valor está menos em revolucionar o gênero e mais em representar um subgrupo muito popular: o isekai onde a competência do protagonista serve para construir estabilidade, não para conquistar o mundo.
Censura e conteúdo sensível
Não houve uma controvérsia pública de censura estrutural ligada ao anime. A adaptação televisiva mantém fanservice leve, insinuações românticas e violência de fantasia sem se tornar explícita.
O ponto curioso é a censura de tom, não de imagem: assuntos pesados — burnout, exploração, doutrinação, abandono e dependência — aparecem diluídos numa embalagem infantilizada. O anime não esconde sangue; ele esconde dor atrás de uma cenoura que caiu de um slime.
Mangás, novels e games
Mídia
Situação
Web novel
Publicada no Shōsetsuka ni Narō, de 2017 a 2020
Light novel
9 volumes; texto de Nazuna Miki e ilustrações de Subachi
Mangá
Arte de Mawata; 17 volumes compilados registrados
Anime
12 episódios, exibidos em 2023
Games
Não há jogo próprio de console, PC ou mobile relevante/oficialmente estabelecido para a franquia
Segunda temporada
Sem anúncio oficial confirmado
Veredito Bellacosa Mainframe
Level 1 dakedo Unique Skill de Saikyou desu é um isekai de aparência inocente, feito de cores de confeitaria e personagens “inhos”, mas com um banco de dados emocional bem mais sombrio do que a interface mostra.
Não é uma obra tecnicamente extraordinária. Tem conveniências de roteiro, harém, piadas que não envelhecem perfeitamente e ação apenas competente. Mas há uma sinceridade inesperada em seu núcleo: pessoas quebradas encontram alguém que não quer extrair delas trabalho, status, sexo, obediência ou utilidade.
Ryota não é forte porque tem level alto. Ele é forte porque, depois de morrer em um sistema que o tratou como descartável, decide que ninguém da sua party será só um recurso de produção.
Nota Bellacosa: 7,5/10 — um pequeno ABEND emocional escondido sob uma tela pastel de dungeon.
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.
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.
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:
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:
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.
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.
Vagner Renato Bellacosa trabalha com IBM Mainframe
desde 1988
,
é IBM Champion e especialista em COBOL, CICS, Db2,
z/OS e IBM Z. Compartilha experiências profissionais,
conhecimento técnico, história da computação e práticas
do universo mainframe para aproximar novas gerações das
tecnologias que sustentam empresas, bancos e governos
ao redor do mundo.
IBM Champion
IBM Z
COBOL
CICS
Db2
z/OS
Mainframe desde 1988
.png)
