☕ Um Café no Bellacosa Mainframe
Gostou do conteúdo? Ajude a manter o café quente, o COBOL compilando e o mainframe acordado. 😄
☕ Pague um café ao Bellacosa

Translate

Mostrar mensagens com a etiqueta Data Quality. Mostrar todas as mensagens
Mostrar mensagens com a etiqueta Data Quality. Mostrar todas as mensagens

terça-feira, 30 de junho de 2026

Agentic Data Intelligence no IBM watsonx.data intelligence: Quando a Inteligência Artificial Descobre que Dados Sem Contexto São Apenas Bits Perdidos

 

Bellacosa Mainframe introduz o agentic data intelligence no ibm watsonx

☕ Um Café no Bellacosa Mainframe

Agentic Data Intelligence no IBM watsonx.data intelligence: Quando a Inteligência Artificial Descobre que Dados Sem Contexto São Apenas Bits Perdidos

Como um Programador COBOL Padawan Pode Entender a Próxima Grande Revolução da Inteligência Artificial Corporativa

Durante muito tempo, ouvimos que a Inteligência Artificial iria substituir programadores.

Depois disseram que bastava conectar um LLM (Large Language Model) ao banco de dados da empresa e todos os problemas estariam resolvidos.

Hoje sabemos que nenhuma dessas ideias estava completamente correta.

O verdadeiro desafio nunca foi fazer a IA "ler" dados.

O desafio sempre foi fazer a IA entender o significado daqueles dados.

Essa diferença parece pequena.

Na prática, ela separa uma IA que apenas gera respostas bonitas de uma IA capaz de trabalhar como um verdadeiro analista de negócios.

É exatamente esse o objetivo do novo Agentic Data Intelligence, incorporado ao IBM watsonx.data intelligence.

Para quem trabalha com IBM Z, COBOL, CICS, DB2, VSAM ou IMS, esse assunto é muito mais importante do que parece. Na realidade, ele conversa diretamente com um problema que todo programador experiente já enfrentou: como descobrir o impacto de uma mudança em um sistema gigantesco criado ao longo de décadas?

Pegue sua caneca de café.

Hoje vamos conversar sobre uma das tecnologias que provavelmente fará parte do futuro do desenvolvimento em Mainframe.


O maior problema da IA nunca foi inteligência

Imagine que amanhã você seja contratado por um grande banco.

No primeiro dia, entregam seu usuário RACF.

Você recebe acesso ao:

  • TSO/ISPF

  • SDSF

  • DB2

  • CICS

  • JCL

  • dezenas de bibliotecas PDS

  • milhares de programas COBOL

Você consegue abrir qualquer programa.

Consegue consultar tabelas.

Consegue executar jobs.

Mas consegue entender o sistema?

Claro que não.

Você não sabe:

  • qual tabela é oficial;

  • qual copybook está obsoleto;

  • qual campo representa uma regra de negócio;

  • quem é o responsável por determinado cadastro;

  • quais programas utilizam aquele arquivo VSAM;

  • quais APIs dependem daquele campo.

Agora imagine uma Inteligência Artificial.

Ela sofre exatamente do mesmo problema.

Ela consegue acessar dados.

Mas não conhece a empresa.


Dados não são conhecimento

Essa talvez seja a primeira grande lição deste artigo.

Existe uma enorme diferença entre:

Dados

e

Conhecimento Corporativo.

Por exemplo:

CLIENTE.STATUS = "A"

Para você isso significa o quê?

Nada.

Agora imagine que o glossário da empresa define:

"A = Cliente Ativo"

Já faz sentido.

Mas e se outra empresa definir:

"A = Cliente Aposentado"

Ou ainda:

"A = Cliente de Alto Valor"

Percebe?

O dado é exatamente igual.

O significado muda completamente.

É isso que chamamos de contexto.


O que é o IBM watsonx.data intelligence?

Pense nele como um enorme cérebro corporativo.

Ele não guarda apenas tabelas.

Ele guarda conhecimento sobre essas tabelas.

Ele sabe:

  • quem criou;

  • quem mantém;

  • quem utiliza;

  • quais sistemas dependem;

  • de onde vieram os dados;

  • quais regras foram aplicadas;

  • qual o nível de qualidade;

  • quais políticas de segurança existem.

Em outras palavras...

Ele transforma metadados em conhecimento utilizável.


Fazendo uma analogia com o Mainframe

Todo ambiente z/OS possui diversos "cérebros invisíveis".

Por exemplo:

  • ICF Catalog

  • RACF

  • SYS1.PARMLIB

  • PROCLIB

  • SMS

  • JES2

Nenhum deles processa transações bancárias.

Mesmo assim...

sem eles o banco simplesmente para.

O watsonx.data intelligence exerce um papel semelhante.

Ele não substitui o DB2.

Nem o VSAM.

Nem o IMS.

Ele explica para a IA como interpretar tudo isso.


Como funciona o Agentic Data Intelligence?

Vamos imaginar um fluxo simples.

Um usuário pergunta:

"Quais clientes Premium tiveram queda no faturamento este mês?"

Uma IA tradicional faria algo parecido com isto:

Pergunta

↓

Procura tabelas

↓

Executa SQL

↓

Entrega resposta

Parece bom.

Mas há vários riscos.

Ela pode consultar:

  • tabela errada;

  • coluna desatualizada;

  • dados duplicados;

  • informações sem governança.

Agora veja o novo fluxo.

Pergunta

↓

Consulta o catálogo corporativo

↓

Verifica definições de negócio

↓

Consulta Data Lineage

↓

Verifica políticas

↓

Avalia qualidade

↓

Gera resposta

É um processo muito mais inteligente.


O que significa "Trusted Context"?

Esse é provavelmente o conceito mais importante do watsonx.data intelligence.

Traduzindo livremente:

Contexto Confiável.

A IA deixa de confiar apenas nos dados.

Ela passa a confiar também nas regras que explicam aqueles dados.

Isso muda completamente a qualidade das respostas.


O papel do Business Glossary

Imagine um banco.

A palavra "Saldo" pode significar:

Saldo Contábil

Saldo Disponível

Saldo Projetado

Saldo Bloqueado

Saldo Médio

Todos são "Saldo".

Mas representam conceitos diferentes.

O Business Glossary resolve exatamente esse problema.

Ele funciona como um dicionário oficial da empresa.

Quando a IA encontra um termo, ela consulta o glossário antes de responder.

É como perguntar ao analista de negócios:

"Quando vocês dizem saldo, qual saldo exatamente?"


Data Lineage: seguindo o caminho dos dados

Agora imagine um campo chamado:

LIMITE_DISPONIVEL

De onde ele veio?

A IA consegue descobrir algo como:

PIX

↓

Movimentações

↓

Conta Corrente

↓

Motor Financeiro

↓

Tabela DB2

↓

Dashboard

Ela enxerga toda a cadeia de transformação.

Isso é chamado de Lineage.


Pensando como um Programador COBOL

Imagine alterar um copybook.

01 CLIENTE.
   05 LIMITE        PIC S9(9)V99 COMP-3.

Antes de alterar esse campo, você gostaria de saber:

  • Quantos programas usam esse copybook?

  • Quais transações CICS dependem dele?

  • Existe algum Job Batch?

  • Alguma API REST utiliza esse campo?

  • Existe integração com sistemas externos?

Hoje isso normalmente exige:

SDSF.

Pesquisa no Endevor.

Ferramentas de Impact Analysis.

Consulta a analistas.

Reuniões.

Com Agentic Data Intelligence, boa parte dessa investigação pode ser automatizada.


O poder do Data Quality

Imagine perguntar:

"Qual o faturamento do último trimestre?"

Uma IA comum responde.

Uma IA inteligente responde:

"O conjunto de dados possui 97,8% de qualidade, porém existem registros duplicados na origem."

Essa pequena diferença aumenta enormemente a confiança na resposta.


Governança não é burocracia

Muitos iniciantes acham que Governança serve apenas para gerar documentação.

Na verdade...

Governança protege a empresa.

Por exemplo:

CPF.

A IA sabe que:

  • deve mascarar;

  • exige autorização;

  • está protegido pela LGPD;

  • possui classificação confidencial.

Ela aprende regras.

Não apenas dados.


Ownership: quem é o dono da informação?

Imagine encontrar uma tabela chamada:

CLIENT_MASTER

Quem responde por ela?

Financeiro?

CRM?

Marketing?

TI?

A IA consulta o catálogo.

Descobre o proprietário.

E informa.

Isso reduz muito o tempo gasto procurando especialistas.


O que é o MCP?

MCP significa:

Model Context Protocol.

Você pode imaginar o MCP como um "idioma universal" entre agentes de IA e sistemas corporativos.

Assim como:

ODBC

JDBC

ODBC permitiu acessar bancos de dados diferentes.

O MCP pretende permitir que qualquer IA consulte conhecimento corporativo da mesma maneira.

Isso significa integração com:

  • IBM Bob

  • Claude

  • GitHub Copilot

  • watsonx Orchestrate

  • aplicações internas


Agent Skills: ensinando experiência para a IA

Aqui está uma das partes mais interessantes.

Imagine ensinar um estagiário.

Você não diz apenas:

"Cadastre um novo Data Product."

Você entrega um procedimento.

Receber dados

↓

Classificar

↓

Enriquecer metadados

↓

Aplicar LGPD

↓

Publicar

↓

Validar

Esse fluxo recebe o nome de Agent Skill.

São habilidades reutilizáveis.

É como um PROC em JCL.

Você encapsula conhecimento.

Depois reutiliza quantas vezes quiser.


Um exemplo para quem conhece JCL

Veja este comando:

//STEP01 EXEC PROC=BACKUP

Você não precisa lembrar:

  • IDCAMS

  • SORT

  • DELETE

  • DEFINE

  • REPRO

Tudo já está preparado.

Agent Skills funcionam exatamente assim.


Um exemplo de uso no mundo real

Imagine um auditor perguntando:

"De onde veio o valor mostrado neste Dashboard?"

A IA pode responder:

Dashboard

↓

Data Product

↓

Tabela Curada

↓

Pipeline ETL

↓

DB2

↓

Programa COBOL

↓

Arquivo VSAM

↓

Sistema de Origem

Tudo automaticamente.

Sem abrir dez ferramentas diferentes.


Outro exemplo para o Padawan

Você altera um Copybook.

Antes do Deploy, pergunta:

"Qual será o impacto?"

O agente responde:

  • 218 programas COBOL afetados;

  • 12 aplicações Java;

  • 31 APIs REST;

  • 4 sistemas parceiros;

  • 6 dashboards;

  • 2 modelos de IA.

Isso é muito mais poderoso do que uma simples pesquisa textual.


Como isso muda a vida do Programador COBOL?

Muito.

Hoje gastamos boa parte do tempo tentando descobrir:

"Quem usa isso?"

No futuro a pergunta será:

"IA, mostre todo o impacto desta alteração."

A IA não apenas responderá.

Ela mostrará:

  • dependências;

  • riscos;

  • qualidade;

  • governança;

  • responsáveis.


Como começar a estudar?

Se você é um COBOL Padawan, siga esta ordem.

Etapa 1 — Domine o Mainframe

Antes de IA, conheça bem:

  • JCL

  • TSO

  • SDSF

  • VSAM

  • DB2

  • CICS

  • IMS

Sem isso, você não entenderá de onde vêm os dados.


Etapa 2 — Aprenda Modelagem de Dados

Estude:

  • Chaves primárias

  • Chaves estrangeiras

  • Normalização

  • Data Warehouse

  • Data Lake

  • Data Products


Etapa 3 — Aprenda Governança

Entenda conceitos como:

  • Metadata

  • Business Glossary

  • Data Steward

  • Lineage

  • Data Quality

  • Data Catalog

  • Ownership

Esses termos aparecerão cada vez mais no mercado.


Etapa 4 — Estude IA Corporativa

Depois avance para:

  • LLM

  • RAG (Retrieval-Augmented Generation)

  • Agentes de IA

  • MCP (Model Context Protocol)

  • IBM watsonx

  • IBM Bob

  • watsonx Orchestrate

Você perceberá que IA corporativa é muito diferente de simplesmente conversar com um chatbot.


Dicas práticas para evoluir

✔ Aprenda SQL profundamente. A IA depende de dados bem estruturados.

✔ Leia documentação de arquitetura dos sistemas onde trabalha. O contexto de negócio é tão importante quanto o código.

✔ Familiarize-se com ferramentas de análise de impacto, catálogos de dados e governança. Muitas das capacidades do Agentic Data Intelligence automatizam tarefas que hoje são feitas manualmente.

✔ Estude conceitos de segurança, LGPD e classificação de dados. Um bom profissional de Mainframe entende que proteger a informação é tão importante quanto processá-la.

✔ Experimente copilotos e agentes de IA, mas sempre valide as respostas. A confiança em IA corporativa nasce da combinação entre automação e governança.


Curiosidades

  • A maior parte do conhecimento de uma empresa não está no código COBOL, mas nas regras de negócio documentadas — ou, muitas vezes, apenas na cabeça dos especialistas.

  • Grandes bancos mantêm aplicações com mais de 40 anos de evolução contínua. Compreender suas dependências é um desafio monumental.

  • O conceito de lineage existe há anos em ferramentas de integração de dados, mas agora passa a fazer parte das respostas produzidas por agentes de IA.

  • O Model Context Protocol (MCP) está se consolidando como um padrão importante para conectar modelos de IA a ferramentas e fontes de conhecimento corporativo.

  • O futuro da IA empresarial dependerá menos de modelos gigantes e mais da capacidade de utilizar dados confiáveis, governados e contextualizados.


Conclusão: o futuro pertence a quem entende contexto

Durante décadas, o diferencial de um excelente programador COBOL nunca foi decorar comandos do compilador ou conhecer todas as instruções da linguagem. O que realmente fazia diferença era compreender profundamente as regras de negócio, as dependências entre sistemas e a história por trás de cada aplicação.

O Agentic Data Intelligence leva essa mesma filosofia para a Inteligência Artificial.

Em vez de responder apenas com base em dados brutos, os agentes passam a consultar glossários de negócio, políticas de governança, linhagem dos dados, métricas de qualidade e informações sobre responsabilidade dos ativos. Em outras palavras, eles começam a agir como faria um analista experiente que conhece o ambiente da empresa.

Para o COBOL Padawan, isso representa uma oportunidade extraordinária. Dominar apenas a linguagem COBOL continuará sendo importante, mas já não será suficiente. O profissional que se destacar será aquele capaz de unir programação, arquitetura de dados, governança, inteligência artificial e conhecimento do negócio.

Assim como o Mainframe evoluiu de cartões perfurados para APIs REST, microsserviços e integração com nuvem, a próxima evolução será impulsionada por agentes inteligentes capazes de compreender o contexto completo da organização.

E talvez essa seja a maior lição deste café no Bellacosa Mainframe:

O código continua sendo essencial, mas o verdadeiro poder está em compreender o significado dos dados. Quem dominar esse conhecimento ajudará a construir a próxima geração de sistemas inteligentes sobre a plataforma mais confiável do mundo: o IBM Z.

 

quarta-feira, 14 de maio de 2025

☕ O Holocron da Inteligência de Dados: Por que a IA Não Entende seu COPYBOOK e Como o watsonx.data Está Tentando Resolver Isso

Bellacosa Mainframe e a ajuda do watsonx no mainframe


☕ O Holocron da Inteligência de Dados: Por que a IA Não Entende seu COPYBOOK e Como o watsonx.data Está Tentando Resolver Isso

"Muitos Padawans acreditam que Inteligência Artificial significa apenas conversar com um chatbot. Os Mestres sabem que a verdadeira batalha acontece muito antes: na compreensão dos dados."


Introdução – O Dia em que o Padawan Descobriu que a IA Não Sabia o que era um PIC X(10)

Imagine a seguinte cena.

Você é um programador COBOL júnior.

Recebe a missão de modernizar uma aplicação bancária construída há quase quarenta anos.

O gerente de inovação aparece sorrindo.

— Vamos colocar IA nisso.

Você pensa:

— Fácil. Basta enviar os dados para um modelo generativo.

Então encontra o seguinte layout:

01 CLIENTE-REG.
   05 CLI-NUMERO        PIC 9(09).
   05 CLI-NOME          PIC X(40).
   05 CLI-RENDA-LIQ     PIC S9(07)V99.
   05 CLI-SITUACAO      PIC X.

A IA observa aquilo.

E responde:

Não faço ideia do que seja CLI-RENDA-LIQ.

Nesse momento, o Padawan aprende uma das maiores lições da Engenharia de Dados moderna.

IA não entende tabelas.

IA entende contexto.

E é exatamente aqui que entra o conceito de Data Intelligence.


Durante muitos anos, empresas compraram ferramentas separadas

O mercado tradicional funcionava assim.

Equipe de Governança:

Possui uma ferramenta.

Equipe de Qualidade:

Possui outra.

Equipe de Catálogo:

Possui outra.

Equipe de Linhagem:

Mais uma.

Equipe de Compliance:

Outra plataforma.

Equipe de Segurança:

Mais uma solução.

Resultado?

Cinco contratos.

Cinco bancos de metadados.

Cinco interfaces.

Cinco APIs.

Cinco equipes discutindo.

Algo parecido com isto:

Governança
     │
Qualidade
     │
Lineage
     │
Catálogo
     │
Compliance
     │
IA

Parece organizado.

Mas na prática é um enorme spaghetti corporativo.


O que a IBM percebeu

A IBM começou a observar um padrão interessante.

As perguntas feitas pelas equipes eram sempre parecidas.

Governança pergunta

Quem é o dono?

Quem aprovou?

Quem pode acessar?


Qualidade pergunta

Posso confiar?

Está completo?

Possui erros?


Lineage pergunta

De onde veio?

Quem alterou?

Qual programa produz?


IA pergunta

O que significa?

Posso usar?

Existe restrição?

Na realidade, todas essas perguntas falam sobre a mesma coisa.

Conhecimento sobre os dados.


A pilha do watsonx.data intelligence

Podemos imaginar a arquitetura como um holocron dividido em cinco camadas.


Primeira camada

Hybrid Cloud Platform

É a fundação.

Conecta:

Db2

Oracle

SAP

Snowflake

MongoDB

Kafka

AWS

Azure

IBM Z

IMS

VSAM

CICS

É como um grande tradutor universal.


Segunda camada

Data Governance

O catálogo corporativo.

Aqui ficam armazenadas informações como:

Campo:

CPF

Classificação:

PII

Sensível:

Sim

LGPD:

Aplicável

Owner:

Área Financeira


Terceira camada

Data Quality

Pergunta simples.

Posso confiar?

Exemplo.

Esperado:

CPF válido

99,99%

Encontrado:

88%

Problema detectado.


Quarta camada

Data Lineage

Talvez a mais fascinante.

Permite responder:

De onde veio?

Imagine:

COBOL

VSAM

DFSORT

Db2

Kafka

Data Lake

LLM

Tudo rastreado.


Quinta camada

Data Product Hub

Talvez seja a ideia mais moderna.

Os dados deixam de ser arquivos.

Viram produtos.

Exemplo.

Produto:

Customer360

Contém:

Dados cadastrais

Histórico

Score

Endereços

Risco

Consumidores:

Fraude

CRM

Analytics

IA


Um exemplo para o Programador COBOL Jr.

Imagine este campo.

05 CLI-RENDA-LIQ PIC S9(07)V99.

Você sabe o que significa.

Mas a IA não.

Precisamos adicionar conhecimento.

Nome comercial:

Renda Líquida Mensal

Descrição:

Valor recebido após descontos.

Periodicidade:

Mensal

Sensibilidade:

Alta

Origem:

Programa COBCL001

Arquivo:

CLIENTES.KSDS

Consumidores:

CRM

Motor de crédito

Modelo IA

Agora sim.

A IA consegue responder.

Pergunta:

"Qual renda média dos clientes premium?"

Resposta:

Campo identificado.

Qualidade validada.

Autorização concedida.

Origem conhecida.

Consulta realizada.


E o Mainframe?

Aqui está a parte que mais interessa ao leitor Bellacosa Mainframe.

O IBM Z sempre teve metadados.

Só nunca os chamamos assim.

O catálogo Db2

É metadado.


Copybooks

São metadados.


RACF

É metadado.


JCL

É metadado.


DBD IMS

É metadado.


SMF

É metadado.


SYS1.PARMLIB

Também.

Durante décadas, o Mainframe guardou informações valiosíssimas.

O problema é que elas estavam dispersas.

E não eram consumidas por modelos de IA.


O novo ouro das empresas

Muitos acreditam que o ativo mais importante seja o modelo generativo.

Não é.

Modelos podem ser trocados.

GPT.

Granite.

Llama.

Mistral.

Claude.

O diferencial competitivo está em algo muito mais difícil.

Os metadados.

Porque representam conhecimento acumulado.

Décadas de regras de negócio.

Decisões.

Políticas.

Histórico.

Governança.

É aquilo que impede uma IA de produzir respostas brilhantes e completamente erradas.


Conselhos para o Padawan COBOL

Se você está iniciando sua jornada no IBM Z, comece a olhar seus programas de outra forma.

Não enxergue apenas instruções COBOL.

Enxergue conhecimento de negócio.

Documente copybooks.

Padronize nomes.

Descreva regras.

Mantenha linhagem.

Entenda quem consome seus dados.

Aprenda governança.

Estude LGPD.

Conheça APIs.

Explore Data Mesh.

Entenda catálogos modernos.

Porque o profissional mais valorizado da próxima década talvez não seja aquele que apenas programa COBOL.

Será aquele capaz de explicar para uma Inteligência Artificial o significado dos cinquenta anos de sabedoria escondidos dentro de um simples:

05 CLI-RENDA-LIQ PIC S9(07)V99.

E quando esse dia chegar, o velho programador COBOL descobrirá algo surpreendente.

Ele nunca foi apenas um codificador.

Ele sempre foi o guardião dos holocrons de dados da empresa.

Espero que este artigo ajude o Padawan COBOL a perceber que Data Intelligence é, em grande parte, a evolução natural da disciplina que o Mainframe pratica há décadas: conhecer profundamente a origem, o significado, a qualidade e a responsabilidade de cada byte armazenado no sistema corporativo.


domingo, 28 de novembro de 2021

SQL sem Mistérios — O Caminho do Programador COBOL Padawan para Pensar Como um Analista Sênior

  

Bellacosa Mainframe e o sql sem misterios

☕ Um Café no Bellacosa Mainframe

SQL sem Mistérios — O Caminho do Programador COBOL Padawan para Pensar Como um Analista Sênior

Da Tela Verde do IBM Z à Ponte da USS Enterprise: por que escrever SQL é apenas o começo da missão

"A lógica é o princípio da sabedoria, não o seu fim."
— Adaptado de Spock


Introdução — O dia em que descobri que SQL não era o verdadeiro problema

Existe um momento na carreira de praticamente todo programador COBOL em que acontece algo curioso.

Você termina seu primeiro programa COBOL com Embedded SQL.

Compila.

Faz o BIND.

Executa o JCL.

O programa termina RC=0000.

Os dados aparecem na tela.

Você sorri.

"Parece que deu certo."

Dias depois...

O usuário telefona.

— "Os números estão errados."

Você verifica novamente.

O programa funciona.

O SQL executa.

Nenhum SQLCODE negativo.

Nenhum ABEND.

Mesmo assim...

Os números continuam errados.

Foi exatamente nesse momento que milhares de desenvolvedores descobriram uma verdade que nenhum livro de SQL ensina:

Escrever SQL é fácil. Produzir informação confiável é a verdadeira profissão.

É justamente essa diferença que separa um analista iniciante de um analista experiente.

No universo do IBM Z, essa diferença pode representar:

  • milhões de registros processados corretamente;

  • horas de CPU economizadas;

  • auditorias aprovadas;

  • noites tranquilas para o operador do JES2.

Hoje embarcaremos na USS Enterprise para entender por que dois profissionais podem escrever praticamente o mesmo SQL e, ainda assim, entregar resultados completamente diferentes.

Prepare seu tricorder.

O Capitão autorizou nossa missão.


Capítulo 1 — A USS Enterprise e o IBM Z

Imagine a Enterprise.

Todos conhecem o computador da nave.

Mas quem realmente toma decisões?

Não é o computador.

É a tripulação.

O computador apenas executa ordens.

O Db2 faz exatamente isso.

Ele não sabe o significado de:

  • cliente

  • pagamento

  • imposto

  • comissão

  • salário

Ele apenas processa relacionamentos matemáticos.

Quem entende o negócio é você.

E aí aparece a primeira lição do Dr. Spock.

"O computador não produz inteligência.
Apenas executa lógica."


Capítulo 2 — O maior erro do Padawan

O iniciante abre o SPUFI ou o Data Studio.

Digita:

SELECT *
FROM CLIENTES;

Executa.

Olha.

Executa novamente.

Adiciona uma coluna.

Executa outra vez.

Coloca um JOIN.

Executa novamente.

Esse comportamento possui um nome.

Programação por tentativa e erro.

Funciona?

Às vezes.

Escala?

Nunca.


Como o veterano trabalha

Antes de abrir qualquer editor, ele responde perguntas.

O que o usuário deseja?

Qual decisão será tomada com esse relatório?

Quem utilizará esses dados?

Qual é a definição oficial desse indicador?

Qual a granularidade?

Cliente?

Pedido?

Produto?

Contrato?

Conta bancária?

Só depois disso ele escreve SQL.

O código nasce praticamente pronto.


Capítulo 3 — A Granularidade: o segredo escondido

Poucos iniciantes aprendem isso.

Na verdade, talvez seja um dos conceitos mais importantes do Data Warehouse moderno.

Imagine estas tabelas:

CLIENTES

Cliente
Nome
Cidade

PEDIDOS

Pedido
Cliente
Valor

ITENS

Pedido
Produto
Quantidade

Pergunta simples:

Qual o faturamento por cliente?

Muitos fazem:

CLIENTES

PEDIDOS

ITENS

SUM()

Resultado?

Dobrou.

Triplicou.

Explodiu.

Por quê?

Porque cada pedido aparece várias vezes.

Cada item multiplica o valor.

Esse fenômeno recebe um nome:

Cardinality Explosion

No Db2 ele custa CPU.

Na empresa custa credibilidade.


Curiosidade Bellacosa ☕

A maioria dos erros financeiros em SQL não acontece porque alguém escreveu uma função errada.

Acontece porque alguém esqueceu a granularidade.


Capítulo 4 — O mito do DISTINCT

Todo mundo já viu isso.

SELECT DISTINCT

Magicamente...

Os números diminuem.

Parece resolvido.

Na verdade...

Você acabou de esconder um problema.

DISTINCT remove linhas iguais.

Mas não explica por que elas ficaram iguais.

É como desligar o alarme de incêndio sem apagar o fogo.


Como Spock resolveria

Primeiro ele perguntaria:

Existe chave primária?

Existe chave composta?

Existe relacionamento 1:N?

Existe histórico?

Existe duplicidade legítima?

Depois faria o JOIN.


Capítulo 5 — O verdadeiro significado do JOIN

JOIN não significa unir tabelas.

JOIN significa combinar entidades diferentes preservando significado.

Um JOIN correto exige conhecer:

  • regras de negócio;

  • integridade referencial;

  • cardinalidade;

  • qualidade dos dados.

No mainframe isso é ainda mais importante porque muitas aplicações nasceram décadas antes da existência das chaves estrangeiras automáticas.

Você precisa conhecê-las.


Capítulo 6 — SELECT * custa dinheiro

O iniciante pensa:

"Mais fácil pegar tudo."

O Db2 pensa diferente.

Cada coluna significa:

  • mais páginas;

  • mais buffer pool;

  • mais cache;

  • mais leitura;

  • mais CPU.

Imagine uma tabela com 300 colunas.

Seu relatório usa apenas cinco.

SELECT *

lê as 300.

Num IBM Z isso significa MIPS.

MIPS significam dinheiro.


Regra de ouro

Selecione somente o que será utilizado.

Nem uma coluna a mais.


Capítulo 7 — A arte de confiar nos dados

O iniciante olha dez linhas.

"Parece certo."

Entrega.

O analista experiente nunca acredita na primeira execução.

Ele faz auditorias.


Checklist clássico

COUNT(*)

COUNT(coluna)

COUNT(DISTINCT)

MIN()

MAX()

AVG()

NULL

Duplicados

Valores negativos

Faixas inválidas

Datas futuras

Datas impossíveis

Esse ritual pode parecer exagerado.

Até o dia em que salva sua carreira.


Easter Egg Star Trek

Na Enterprise existe redundância em praticamente tudo.

Motores.

Computadores.

Sensores.

Por quê?

Porque confiar em um único indicador é perigoso.

O mesmo vale para SQL.

Nunca valide apenas uma métrica.


Capítulo 8 — NULL: o inimigo invisível

NULL é talvez o conceito mais incompreendido do SQL.

NULL não significa:

zero

vazio

espaço

falso

NULL significa:

valor desconhecido.

Veja:

WHERE SALARIO > 5000

Quem possui NULL?

Some.

Sem aviso.

Sem erro.

Sem SQLCODE.


Quantos relatórios já ficaram errados por causa disso?

Milhares.


Capítulo 9 — Performance não começa depois

Muitos pensam:

Primeiro faço funcionar.

Depois otimizo.

O veterano pensa diferente.

Ele escreve pensando no otimizador.


O EXPLAIN é seu tricorder

No Star Trek, ninguém entra em um planeta desconhecido sem usar o tricorder.

No Db2, ninguém deveria executar uma consulta crítica sem analisar o EXPLAIN.

Ele mostra:

  • índice usado;

  • tipo de JOIN;

  • SORT;

  • acesso sequencial;

  • custo estimado;

  • filtro aplicado.

É literalmente o mapa da missão.


Capítulo 10 — O índice é um elevador

Imagine um prédio.

Você precisa ir ao andar 90.

Sem elevador.

Escadas.

Isso é um Table Space Scan.

Agora imagine um elevador.

Isso é um índice.

Agora imagine alguém fechando a porta do elevador.

Quem faz isso?

Funções sobre colunas indexadas.

Exemplo:

WHERE YEAR(DATA)=2026

Melhor:

WHERE DATA BETWEEN ...

Agora o elevador funciona novamente.


Capítulo 11 — Window Functions

Antigamente fazíamos:

JOIN

JOIN

JOIN

Subconsulta

Mais JOIN

Hoje basta:

ROW_NUMBER()

RANK()

LAG()

LEAD()

SUM() OVER()

Essas funções diminuem:

CPU

complexidade

manutenção

e deixam o código muito mais elegante.


Capítulo 12 — CTEs: capítulos de uma história

O iniciante escreve um SQL de 700 linhas.

Sem espaços.

Sem comentários.

Boa sorte.

O veterano usa CTEs.

ClientesAtivos

↓

PedidosRecentes

↓

PedidosValidados

↓

ResumoFinanceiro

↓

Resultado

Cada bloco conta uma parte da história.

O SQL vira documentação.


Capítulo 13 — Comentários inteligentes

Comentário ruim:

-- soma valores

Comentário útil:

-- Clientes ativos são aqueles
-- que efetuaram pelo menos
-- uma compra nos últimos
-- 180 dias conforme definição
-- da área financeira.

Explique o motivo.

Nunca o óbvio.


Capítulo 14 — O poder da reutilização

Uma consulta salva na área de trabalho morre junto com o computador.

Uma View.

Uma Stored Procedure.

Uma biblioteca Git.

Sobrevivem anos.

O conhecimento coletivo vale muito mais que scripts isolados.


Capítulo 15 — O que o COBOL ensina sobre SQL

Curiosamente, programadores COBOL costumam desenvolver uma vantagem natural.

Eles aprendem cedo conceitos como:

  • precisão;

  • processamento determinístico;

  • validação;

  • tratamento de erros;

  • responsabilidade sobre os dados.

Esses princípios se encaixam perfeitamente em SQL.

O verdadeiro desafio é abandonar a mentalidade de "fazer funcionar" e adotar a mentalidade de "garantir que está correto".


Capítulo 16 — O Fluxo Mental de um Analista Sênior

Antes de escrever qualquer linha de SQL, um profissional experiente costuma seguir um roteiro semelhante:

  1. Compreender a pergunta de negócio.

  2. Identificar a fonte oficial dos dados.

  3. Definir a granularidade do resultado.

  4. Verificar chaves primárias, candidatas e relacionamentos.

  5. Planejar filtros para reduzir o volume de dados o mais cedo possível.

  6. Escolher apenas as colunas necessárias.

  7. Esboçar CTEs que representem cada etapa da lógica.

  8. Executar consultas de auditoria (COUNT, COUNT(DISTINCT), MIN, MAX, análise de NULL).

  9. Avaliar o plano de execução com EXPLAIN.

  10. Comparar o resultado com uma fonte confiável.

  11. Documentar as regras de negócio.

  12. Versionar a solução para que toda a equipe possa reutilizá-la.

Perceba que escrever o SELECT é apenas uma pequena parte desse processo.


Curiosidades

O primeiro SQL raramente é o melhor

Analistas experientes reescrevem consultas várias vezes antes de entregá-las. Não porque o SQL esteja errado, mas porque sempre existe uma forma mais clara, mais eficiente ou mais fácil de manter.


O melhor SQL é o que outro profissional entende

Uma consulta extremamente inteligente, mas impossível de ler, costuma gerar mais problemas do que benefícios. Clareza é uma característica de engenharia.


O DBA e o desenvolvedor não são adversários

Em muitas equipes, existe a falsa ideia de que o DBA apenas "reclama" das consultas lentas. Na prática, o DBA enxerga o comportamento do banco como um todo e pode identificar oportunidades que passam despercebidas durante o desenvolvimento.


Bellacosa Mainframe — Dicas do Capitão

✅ Entenda o problema antes de abrir o editor.

✅ Nunca use SELECT * em produção sem um motivo claro.

✅ Conheça a granularidade dos dados antes de fazer JOIN.

✅ Desconfie de qualquer DISTINCT que "resolve" um problema.

✅ Sempre audite NULL, duplicidades e totais.

✅ Aprenda a interpretar EXPLAIN com a mesma dedicação que aprende SQL.

✅ Escreva consultas para que outra pessoa consiga mantê-las daqui a cinco anos.

✅ Pense em reutilização: CTEs bem nomeadas, views, procedimentos e controle de versão transformam consultas em patrimônio da equipe.


Conclusão — O que Spock ensinaria sobre SQL

No final desta jornada, percebemos que a diferença entre um analista iniciante e um analista sênior não está na quantidade de comandos SQL decorados. Ambos conhecem SELECT, JOIN, GROUP BY e ORDER BY. O que realmente muda é a forma de pensar.

Spock jamais executaria uma consulta apenas porque ela compila. Ele questionaria a lógica, verificaria as premissas, confrontaria os resultados com outras evidências e só então confiaria na resposta. Essa postura científica é a essência da engenharia de dados.

No universo do IBM Z, onde milhões de transações financeiras, seguros, companhias aéreas e sistemas governamentais dependem da integridade dos dados, um SQL "que funciona" não é suficiente. Ele precisa ser correto, performático, auditável, reutilizável e compreensível.

O verdadeiro crescimento profissional acontece quando o desenvolvedor deixa de perguntar "Como faço esta consulta funcionar?" e passa a perguntar "Como posso garantir que esta informação continuará correta daqui a dez anos?"

Esse é o momento em que um Padawan do COBOL deixa de apenas escrever SQL e começa a pensar como um verdadeiro engenheiro de software — alguém que transforma dados em confiança, lógica em conhecimento e consultas em decisões que movem organizações inteiras.

Como diria o Sr. Spock ao encerrar a missão:

"A consulta mais rápida não é necessariamente a melhor. A melhor é aquela cuja lógica permanece verdadeira, mesmo quando todos os dados do universo são colocados à prova."

 

Vagner Renato Bellacosa, IBM Champion e especialista em IBM Mainframe
IBM Z17 SYSTEM ONLINE
Sobre o autor

Vagner Renato Bellacosa

IBM Champion 2026 • Especialista em IBM Mainframe

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
GitHub LinkedIn
Inicializando conteúdo...