Bellacosa Mainframe e o  Relation Problem 

🧩 O “Relational Problem”: quando o modelo relacional começa a ranger os dentes

Teve uma época — lá pelos anos 70 e 80 — em que o modelo relacional era praticamente um presente divino.
Ted Codd apareceu com tabelas, chaves, normalização e alguém pensou:

“Pronto, agora dá pra organizar o mundo inteiro em linhas e colunas.”

E funcionou. Funcionou bem demais.
Funcionou tanto que virou padrão em bancos, governos, ERPs, mainframes, folha de pagamento, compensação bancária, impostos, seguros… o pacote completo.

Só que aí veio o mundo moderno.
E ele veio sem pedir licença.

---

📈 A explosão de dados (ou: quando o DB começou a suar frio)

Web, mobile, redes sociais, IoT, logs, sensores, streaming, analytics em tempo real…
De repente, o banco relacional passou a ouvir frases como:

• “Preciso escalar horizontalmente.”

• “Tem que responder em milissegundos.”

• “O schema muda toda semana.”

• “Esse JSON aqui é meio… flexível.”

Nesse momento nasce o que chamamos de Relational Problem:
👉 a dificuldade crescente de gerenciar, escalar e consultar dados usando RDBMS tradicionais em ambientes cada vez maiores, mais variados e mais exigentes.

O vilão clássico?

• Schemas rígidos

• Joins caros

• Crescimento exponencial de volume

• Performance sofrendo conforme a complexidade aumenta

📌 Easter egg: se você já viu um EXPLAIN com 12 joins e custo astronômico, você já sentiu o Relational Problem na pele.

---

🏗️ Solução 1: Escalar pra cima (o famoso “compra mais ferro”)

A primeira reação clássica é:

“Coloca mais CPU, mais memória e mais disco.”

No mundo mainframe isso tem nome, sobrenome e fatura alta 💸.

✔️ Funciona? Funciona.
❌ Resolve pra sempre? Não.

• É caro

• Tem limite físico

• E uma hora… acaba

👉 Vertical scaling resolve dor imediata, não o problema estrutural.

---

🔧 Solução 2: Otimizar até a última gota

Aí entra o arsenal conhecido:

• Índices

• Partitioning

• Denormalização

• Tuning de SQL

• Estatísticas afinadas na lua certa 🌕

Isso melhora muito, mas cobra seu preço:

• Mais complexidade

• Mais overhead operacional

• Mais chances de alguém quebrar tudo num ALTER inocente

📌 Fofoquinha: todo ambiente tem aquele índice criado “em produção às pressas” que ninguém sabe se pode remover.

---

🌐 Solução 3: Relacional distribuído (o meio do caminho)

Aqui a ideia é ousada:

“Vamos manter o modelo relacional, mas espalhar os dados.”

Resultado:

• Mais escalabilidade

• Mais disponibilidade

• E… mais complexidade de consistência e transação

💡 ACID distribuído não é trivial.
Quem já estudou two-phase commit sabe que não existe almoço grátis.

---

🚀 Solução 4: NoSQL — o rebelde sem gravata

Aí surgem os NoSQL:

• Key-value

• Documento

• Colunar

• Grafos

Eles dizem:

“Relaxa o schema, relaxa o relacionamento, escala horizontalmente e seja feliz.”

✔️ Alta performance
✔️ Flexibilidade
✔️ Escala global

❌ Menos garantias transacionais
❌ Consistência eventualmente… eventual 😅

📌 Easter egg: NoSQL não significa “No SQL”, mas muita gente usa como “No JOIN, graças a Deus”.

---

🔀 Solução 5: Abordagem híbrida (o mundo real)

Na prática, o que venceu foi o híbrido:

• Relacional para transação crítica

• NoSQL ou Data Warehouse para analytics e volume massivo

• Cada banco no seu quadrado

👉 O banco certo para o problema certo.

💬 Comentário Bellacosa:
Mainframe + DB2 continua reinando onde consistência, auditoria e confiabilidade não são opcionais.

---

⚖️ Os grandes trade-offs (onde mora a dor)

Resolver o Relational Problem é basicamente escolher qual dor você aceita.

🔐 Consistência vs Disponibilidade & Escala

• Relacional ama ACID

• Distribuído ama performance

• CAP theorem fica no meio rindo da sua cara

🧱 Rigidez de schema vs Flexibilidade

• Schema fixo protege a integridade

• Schema flexível acelera mudança

• Um trava, o outro corre… e tropeça às vezes

⚙️ Performance vs Complexidade

• Tuning melhora performance

• Mas aumenta custo, risco e dependência de especialistas

💰 Custo vs Controle

• Hardware e licenças caros

• Cloud e distribuído mais baratos (até não serem)

---

🏦 Quem escolhe o quê?

• Bancos, governos, seguradoras
  👉 Consistência, governança, auditoria
  👉 Relacional forte, bem cuidado, bem documentado

• Empresas web-scale, data-driven
  👉 Escala, agilidade, crescimento rápido
  👉 Distribuído, NoSQL, híbrido

📌 Não é sobre tecnologia “melhor”.
É sobre prioridade de negócio.

---

☕ Conclusão estilo café no mainframe

O Relational Problem não significa que o modelo relacional falhou.
Significa que ele foi bom demais por tempo demais em um mundo que mudou radicalmente.

A maturidade está em entender:

• Onde ele brilha

• Onde ele sofre

• E como combiná-lo com outras abordagens

💬 Última fofoquinha:
Quem decreta a “morte do relacional” geralmente nunca precisou fechar um balanço financeiro auditado.

 

Bellacosa Mainframe e o SQL no Mainframe muito alem do select

---

☕ SQL NO MAINFRAME: MUITO ALÉM DO SELECT

Como Dominar os Fundamentos de SQL no DB2 13 for z/OS

Quando alguém abre o SPUFI, Data Studio, DBeaver ou qualquer ferramenta SQL pela primeira vez, normalmente executa algo simples:

SELECT *
FROM CLIENTES;

A consulta retorna dados.

O usuário sorri.

Acredita que aprendeu SQL.

Mas na realidade acabou de dar apenas o primeiro passo de uma longa jornada.

No universo Mainframe, SQL é a língua falada entre:

• COBOL

• CICS

• IMS

• Java

• Web Services

• APIs REST

• z/OS Connect

• Analytics

• Inteligência Artificial

Todo sistema corporativo moderno passa por SQL em algum momento.

E o DB2 13 elevou ainda mais essa importância.

---

A HISTÓRIA QUE TODO PROFISSIONAL DE MAINFRAME DEVERIA CONHECER

Antes do SQL, bancos relacionais eram apenas uma teoria.

Em 1970, Edgar F. Codd publicou um artigo revolucionário na IBM:

A Relational Model of Data for Large Shared Data Banks

Esse trabalho mudou a computação.

A ideia era simples:

Ao invés de navegar registros fisicamente, os usuários deveriam dizer:

"Quero estes dados."

E o banco decidiria:

"Eu descubro a melhor forma de encontrá-los."

Nascia o conceito de SQL.

Décadas depois, essa filosofia continua viva dentro do DB2 13.

---

O QUE É SQL?

SQL significa:

Structured Query Language

Ou:

Linguagem Estruturada de Consulta

Ela permite:

• Consultar dados

• Inserir dados

• Alterar dados

• Excluir dados

• Criar estruturas

• Gerenciar segurança

Praticamente tudo que fazemos no DB2 passa por SQL.

---

OS QUATRO GRANDES GRUPOS DE COMANDOS SQL

DQL – Data Query Language

Consulta de dados.

Exemplo:

SELECT *
FROM FUNCIONARIOS;

---

DML – Data Manipulation Language

Manipulação de registros.

INSERT INTO FUNCIONARIOS
VALUES
(100,'CARLOS');

UPDATE FUNCIONARIOS
SET SALARIO = 5000
WHERE MATRICULA = 100;

DELETE
FROM FUNCIONARIOS
WHERE MATRICULA = 100;

---

DDL – Data Definition Language

Definição das estruturas.

CREATE TABLE CLIENTES
(
 ID INTEGER,
 NOME VARCHAR(50)
);

---

DCL – Data Control Language

Controle de segurança.

GRANT SELECT
ON CLIENTES
TO USER01;

---

A TABELA É O CORAÇÃO DO DB2

Imagine um arquivo VSAM KSDS.

Agora imagine esse conceito evoluído.

Uma tabela é composta por:

• Linhas

• Colunas

• Relacionamentos

• Índices

• Constraints

Exemplo:

ID	NOME	CIDADE
1	ANA	SÃO PAULO
2	JOÃO	SANTOS
3	MARIA	RIO

Essa simplicidade aparente esconde uma enorme complexidade de armazenamento.

---

SUA PRIMEIRA CONSULTA DE VERDADE

O erro mais comum é usar:

SELECT *
FROM CLIENTES;

Em produção isso costuma ser um desastre.

O profissional experiente utiliza:

SELECT
    ID,
    NOME,
    CIDADE
FROM CLIENTES;

Por quê?

Porque reduz:

• I/O

• CPU

• Network Traffic

• Uso de buffer pools

No DB2 13 isso continua sendo uma das melhores práticas.

---

APRENDENDO A FILTRAR DADOS

O poder real surge com o WHERE.

SELECT
    NOME
FROM CLIENTES
WHERE CIDADE = 'SANTOS';

Sem WHERE:

SCAN TOTAL

Com WHERE:

BUSCA DIRECIONADA

Diferença gigantesca.

Principalmente em tabelas com bilhões de linhas.

---

OPERADORES MAIS UTILIZADOS

Igualdade

WHERE ID = 100

Diferente

WHERE ID <> 100

Maior

WHERE SALARIO > 10000

Menor

WHERE SALARIO < 5000

Intervalo

WHERE SALARIO
BETWEEN 5000 AND 10000

Lista

WHERE CIDADE
IN ('SANTOS','CAMPINAS')

---

LIKE: A ARMA SECRETA DOS ANALISTAS

SELECT *
FROM CLIENTES
WHERE NOME LIKE 'MAR%';

Retorna:

• MARIA

• MARCOS

• MARCELO

Mas atenção.

LIKE mal utilizado pode destruir a performance.

Exemplo ruim:

LIKE '%MAR%'

O otimizador normalmente perde a possibilidade de usar índices eficientemente.

---

ORDER BY

Organizando resultados.

SELECT
NOME,
SALARIO
FROM FUNCIONARIOS
ORDER BY SALARIO DESC;

Maior salário primeiro.

Muito simples.

Muito poderoso.

Muito custoso quando mal utilizado.

---

DISTINCT

Eliminando duplicidades.

SELECT DISTINCT
CIDADE
FROM CLIENTES;

Resultado:

SANTOS
CAMPINAS
RIO

Sem repetições.

---

CONTANDO REGISTROS

Todo DBA utiliza:

SELECT COUNT(*)
FROM CLIENTES;

Mas poucos iniciantes sabem que em tabelas gigantes isso pode gerar leituras enormes.

Por isso estatísticas e catálogos do DB2 também são utilizados para estimativas.

---

FUNÇÕES DE AGREGAÇÃO

Soma

SELECT SUM(VALOR)
FROM VENDAS;

---

Média

SELECT AVG(SALARIO)
FROM FUNCIONARIOS;

---

Máximo

SELECT MAX(SALARIO)
FROM FUNCIONARIOS;

---

Mínimo

SELECT MIN(SALARIO)
FROM FUNCIONARIOS;

---

GROUP BY: ONDE O SQL COMEÇA A FICAR INTERESSANTE

Exemplo:

SELECT
CIDADE,
COUNT(*)
FROM CLIENTES
GROUP BY CIDADE;

Resultado:

Cidade	Quantidade
Santos	1200
São Paulo	5800
Campinas	900

Aqui começamos a transformar dados em informação.

---

HAVING

Filtrando grupos.

SELECT
CIDADE,
COUNT(*)
FROM CLIENTES
GROUP BY CIDADE
HAVING COUNT(*) > 1000;

Somente cidades relevantes aparecem.

---

JOINS: O SUPERPODER DO SQL

Aqui nasce o verdadeiro banco relacional.

Tabela CLIENTES:

ID	NOME
1	ANA

Tabela PEDIDOS:

PEDIDO	ID_CLIENTE
100	1

Consulta:

SELECT
C.NOME,
P.PEDIDO
FROM CLIENTES C
INNER JOIN PEDIDOS P
ON C.ID = P.ID_CLIENTE;

Resultado:

ANA 100

Magia?

Não.

Modelo relacional.

---

INNER JOIN

Retorna apenas correspondências.

INNER JOIN

É o JOIN mais utilizado do mundo.

---

LEFT JOIN

Mantém todos os registros da esquerda.

LEFT JOIN

Mesmo sem correspondência.

Muito usado em auditorias.

---

SUBSELECTS

Uma consulta dentro da outra.

SELECT *
FROM FUNCIONARIOS
WHERE SALARIO >
(
SELECT AVG(SALARIO)
FROM FUNCIONARIOS
);

Funcionários acima da média.

Excelente exemplo de lógica relacional.

---

SQL E COBOL: UMA DUPLA IMBATÍVEL

Em Mainframe o SQL raramente vive sozinho.

Exemplo Embedded SQL:

EXEC SQL
SELECT NOME
INTO :WS-NOME
FROM CLIENTES
WHERE ID = :WS-ID
END-EXEC.

Esse padrão movimenta bancos, seguradoras, governos e bolsas de valores há décadas.

---

O PAPEL DO BIND

Iniciantes aprendem SQL.

Profissionais Mainframe aprendem:

• Pré-compilação

• DBRM

• PACKAGE

• PLAN

• BIND

Sem isso o SQL não chega à produção.

---

O OTIMIZADOR: O CÉREBRO DO DB2

O usuário escreve:

SELECT *
FROM CLIENTES
WHERE ID = 100;

O DB2 pergunta:

• Uso índice?

• Faço scan?

• Quantas páginas?

• Quanto CPU?

Esse processo é chamado:

Access Path Selection

É aqui que a mágica acontece.

---

EXPLAIN: O RAIO-X DA CONSULTA

Nunca confie apenas porque uma consulta funciona.

Verifique o plano.

EXPLAIN PLAN FOR
SELECT *
FROM CLIENTES;

O DB2 mostrará:

• Índices usados

• Custo estimado

• Estratégias de acesso

DBAs vivem nessa análise.

---

O QUE MUDA NO DB2 13?

O DB2 13 trouxe avanços importantes:

Melhor exploração de estatísticas

O otimizador toma decisões mais inteligentes.

Melhor uso de CPU

Redução de consumo em workloads intensos.

Aprimoramentos em SQL Analytics

Funções analíticas mais eficientes.

Melhor integração híbrida

Conectividade moderna com APIs e aplicações distribuídas.

Evolução contínua do Machine Learning para otimização

Capacidade crescente de melhorar decisões de acesso com base em padrões observados.

---

ERROS CLÁSSICOS DOS INICIANTES

SELECT *

Evite.

---

Falta de índice

Performance despenca.

---

WHERE inadequado

Full table scan.

---

JOIN sem critério

Explosão de registros.

---

UPDATE sem WHERE

O terror dos DBAs.

UPDATE CLIENTES
SET STATUS='A';

Toda tabela alterada.

Acidente clássico.

---

O CAMINHO PARA VIRAR ESPECIALISTA

Etapa 1

Dominar SELECT.

---

Etapa 2

Dominar filtros.

---

Etapa 3

Dominar JOINs.

---

Etapa 4

Entender índices.

---

Etapa 5

Aprender EXPLAIN.

---

Etapa 6

Estudar catálogo DB2.

---

Etapa 7

Entender RUNSTATS.

---

Etapa 8

Compreender Access Paths.

---

Etapa 9

SQL embarcado em COBOL.

---

Etapa 10

Otimização avançada.

---

CONCLUSÃO: SQL É A NOVA LINGUAGEM UNIVERSAL DO MAINFRAME

Muitos profissionais acreditam que dominar COBOL é suficiente para trabalhar em Mainframe.

Não é.

O mercado moderno exige uma combinação poderosa:

• COBOL

• JCL

• CICS

• RACF

• DB2

• SQL

E dentro desse conjunto, SQL ocupa uma posição privilegiada.

Toda aplicação corporativa depende dele.

Toda API consulta dados através dele.

Toda IA corporativa precisa dele.

Todo analista precisa entendê-lo.

O segredo não é decorar comandos.

O segredo é compreender o que acontece por trás deles.

Quando você entende como o DB2 13 interpreta uma consulta, escolhe índices, calcula custos, acessa páginas e otimiza recursos, deixa de ser apenas alguém que escreve SQL.

Você passa a pensar como o próprio banco de dados.

E, no universo Bellacosa Mainframe, é exatamente aí que começa a verdadeira jornada: não em aprender comandos, mas em aprender a conversar com um dos sistemas mais sofisticados já construídos pela engenharia da computação.

☕🚀 Bem-vindo ao mundo do DB2 13. O primeiro SELECT é simples. O desafio real é transformar consultas em performance, conhecimento e valor para o negócio.

 

Bellacosa Mainframe apresenta IBM Mainframe DB2 Inner Join

🔷 INNER JOIN no IBM DB2 Mainframe – A Arte de Relacionar Tabelas

Se você trabalha com IBM Mainframe, provavelmente já precisou combinar dados de diferentes tabelas. E para isso existe o INNER JOIN, que é o clássico entre os joins em SQL.

Mas antes de entrar nos detalhes, vamos à história…

---

🕰️ História e Origem

O conceito de INNER JOIN vem diretamente do Modelo Relacional de Codd (1970), criado dentro da IBM.

• Edgar F. Codd, um cientista da IBM, imaginou que dados deveriam ser armazenados em tabelas relacionais e manipulados por álgebra relacional.

• Ele não inventou “INNER JOIN” como conhecemos hoje, mas a ideia de combinar tabelas via chaves comuns nasceu com ele.

• SQL evoluiu nos anos 80 para suportar explicitamente joins:

  • Sintaxe implícita: FROM A, B WHERE A.key = B.key

  • Sintaxe explícita: FROM A INNER JOIN B ON A.key = B.key

No DB2 para Mainframe, o INNER JOIN é altamente otimizado para lidar com milhões de linhas em transações batch ou OLTP, mantendo a performance crítica.

---

⚙️ O que é INNER JOIN?

INNER JOIN é a operação que retorna somente as linhas onde existe correspondência em ambas as tabelas, baseado em uma chave comum.

🔹 Sintaxe padrão DB2

-- Explicit INNER JOIN (recomendado)
SELECT E.EmployeeID, E.LastName, O.OrderID
FROM Employees E
INNER JOIN Orders O
  ON E.EmployeeID = O.EmployeeID;

-- Implicit INNER JOIN (estilo antigo)
SELECT E.EmployeeID, E.LastName, O.OrderID
FROM Employees E, Orders O
WHERE E.EmployeeID = O.EmployeeID;

🔹 Observações

• Chave comum: não precisa ter o mesmo nome, apenas valores compatíveis.

• Sem correspondência → linha é descartada.

• Pode usar múltiplas tabelas → INNER JOIN é associativo.

---

💡 Dicas Bellacosa para Mainframe

1. Prefira joins explícitos (INNER JOIN ON) em DB2 → facilita leitura e manutenção.

2. Sempre qualifique colunas se houver nomes repetidos → evita ambiguidade (E.EmployeeID, O.EmployeeID).

3. Use aliases curtos → economiza digitação e deixa o código limpo.

4. Evite cartesian products sem intenção → FROM A, B sem WHERE é um Product, que explode linhas.

5. Verifique estatísticas de tabela → DB2 otimiza join usando índices.

---

🔍 Curiosidades & Easter Eggs

• No DB2, todas as joins são INNER por padrão se você não usar OUTER.

• Internamente, o otimizador transforma INNER JOIN em operações de álgebra relacional: Product + Selection.

• Usar JOIN explícito ajuda o Explain Plan a gerar caminhos de acesso mais eficientes.

• Combinar índices corretos + INNER JOIN = batch mais rápido, menos I/O.

---

🧪 Exemplo prático

Imagine que temos duas tabelas no z/OS DB2:

EMPLOYEES

EmployeeID	LastName	DeptID
101	Smith	10
102	Jones	20

DEPARTMENTS

DeptID	DeptName
10	Accounting
20	HR
30	IT

Query: INNER JOIN

SELECT E.LastName, D.DeptName
FROM Employees E
INNER JOIN Departments D
  ON E.DeptID = D.DeptID;

Resultado:

LastName	DeptName
Smith	Accounting
Jones	HR

Observe: DeptID = 30 não aparece porque não há funcionário correspondente.

---

📈 Uso e Razão de Uso

• Combinar tabelas relacionadas → RELACIONAL puro

• Resumir informações em relatórios ou dashboards OLAP

• Criar answer sets consistentes para análises

• Fundamental para consultas em ERP, finanças e logística

No mainframe, INNER JOIN é usado em:

• Batch → processa milhões de registros rapidamente

• Online Transaction Processing (OLTP) → respostas rápidas e consistentes

---

⚡ Impacto na Performance e Otimização

1. Indexes importam muito:

   • JOIN em colunas indexadas = leitura rápida, menos I/O

   • Sem índice → DB2 faz table scan → lento em tabelas grandes

2. Estatísticas DB2:

   • RUNSTATS ajuda o otimizador a escolher o caminho ideal

3. Número de tabelas no JOIN:

   • Mais joins = mais complexidade e consumo de CPU

   • Prefira joins em cascata controlados, evite joins desnecessários

4. Filtros antes do JOIN:

   • Use WHERE/qualificação para reduzir linhas antes do INNER JOIN

   • Isso diminui o volume de dados processados e acelera o batch

---

🔑 Comentários finais Bellacosa

• INNER JOIN é a base do SQL relacional, especialmente no DB2 do mainframe.

• Sintaxe explícita + colunas qualificadas + índices corretos = performance top de linha.

• Mesmo em 2026, ele é indispensável em sistemas críticos da IBM.

• Dica bônus: use EXPLAIN PLAN para ver como DB2 executa seus INNER JOINs.

💡 Easter Egg:

Por baixo do capô, o DB2 transforma cada INNER JOIN em Product + Selection + Projection na álgebra relacional — a magia acontece silenciosa enquanto você apenas digita INNER JOIN.