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.

 

 

Bellacosa Mainframe apresenta o motor do DB2 a algebra relacional

---

🔷 Relational Algebra no Mainframe

Uma viagem raiz pelo coração do DB2 (IBM Mainframe Edition)

Se você trabalha — ou sonha em trabalhar — com IBM Mainframe, cedo ou tarde vai ouvir um termo que parece saído de um livro de matemática dos anos 70:

👉 Relational Algebra

Calma. Respira.
Não é um bicho de sete cabeças.
É, na verdade, a Força por trás do SQL.

Antes de existir SELECT * FROM SYSIBM.SYSDUMMY1, alguém precisou pensar como os dados se relacionam. Esse alguém foi Edgar F. Codd, lá na IBM, em 1970. Sim, tudo isso nasceu dentro da IBM — respeita o mainframe. 🖥️

---

🕰️ Um pouco de história (porque mainframe sem história não é mainframe)

Nos anos 60 e 70:

• Arquivos eram sequenciais

• Relatórios demoravam horas

• Qualquer mudança era dor e sofrimento

Então a IBM apresentou o Modelo Relacional:

• Dados em tabelas

• Relações matemáticas

• Independência entre dados e programas

E para manipular essas tabelas, surgiu a Relational Algebra — uma linguagem conceitual, não escrita diretamente no sistema, mas usada pelo otimizador do DB2 por baixo dos panos.

💡 Easter Egg:
Quando você escreve SQL no DB2, o que o banco realmente executa internamente é Relational Algebra otimizada.

---

⚙️ Os 5 operadores essenciais (o sabre de luz do DBA)

Vamos aos clássicos:

---

1️⃣ Projection (π) — “Me mostra só o que eu preciso”

📌 O que faz
Seleciona colunas específicas de uma tabela.

📘 Conceito:

π (COLUNA1, COLUNA2)

🧠 Tradução DB2:

SELECT COLUNA1, COLUNA2
FROM TABELA;

🖥️ Exemplo Mainframe:

SELECT EMPNO, LASTNAME
FROM EMP;

💡 Dica Bellacosa:

Projection reduz I/O.
Menos coluna = menos leitura = batch mais rápido = operador feliz.

---

2️⃣ Selection (σ) — “Filtra isso aí”

📌 O que faz
Seleciona linhas com base em uma condição.

📘 Conceito:

σ (SALARY > 50000)

🧠 Tradução DB2:

SELECT *
FROM EMP
WHERE SALARY > 50000;

💡 Easter Egg:

WHERE é Selection.
Sempre foi. Sempre será.

---

3️⃣ Union (∪) — “Junta tudo, mas sem duplicar”

📌 O que faz
Concatena duas relações compatíveis (mesmas colunas).

📘 Conceito:

R ∪ S

🧠 Tradução DB2:

SELECT EMPNO FROM EMP_2023
UNION
SELECT EMPNO FROM EMP_2024;

⚠️ Alerta Mainframe:

• UNION remove duplicados

• UNION ALL é mais rápido (menos CPU)

💡 Dica de ouro:

Em batch pesado, pense duas vezes antes de usar UNION sem ALL.

---

4️⃣ Product (×) — “Multiplicação que dá dor de cabeça”

📌 O que faz
Combina todas as linhas de uma tabela com todas as linhas da outra.

📘 Conceito:

R × S

🧠 Tradução SQL (implícita):

SELECT *
FROM EMP, DEPT;

😱 Resultado:

• 100 funcionários × 10 departamentos = 1000 linhas

💡 Bellacosa comenta:

Cartesian Product é tipo JCL sem COND.
Pode até rodar… mas você vai se arrepender.

---

5️⃣ Natural Join (⨝) — “O casamento perfeito”

📌 O que faz
Relaciona tabelas usando colunas comuns automaticamente.

📘 Conceito:

EMP ⨝ DEPT

🧠 Tradução DB2:

SELECT *
FROM EMP
JOIN DEPT
ON EMP.DEPTNO = DEPT.DEPTNO;

💡 Easter Egg Mainframe:

Todo JOIN começa como um Product + Selection.
O DB2 só faz isso de forma inteligente pra você.

---

🧪 Exemplo prático estilo chão de fábrica

🎯 Objetivo:
Listar nome do funcionário e nome do departamento para quem ganha mais de 60k.

🧠 Relational Algebra:

1. Selection (salário)

2. Join (EMP + DEPT)

3. Projection (nome + depto)

🖥️ DB2 SQL:

SELECT E.LASTNAME, D.DEPTNAME
FROM EMP E
JOIN DEPT D
  ON E.DEPTNO = D.DEPTNO
WHERE E.SALARY > 60000;

💡 O DB2 otimiza isso usando Relational Algebra internamente.

---

🧙 Primeiros passos para Padawans do Mainframe

Se você está começando:

✅ Entenda Selection vs Projection
✅ Saiba quando usar JOIN vs UNION
✅ Evite Cartesian Product sem intenção
✅ Pense sempre em I/O e CPU
✅ Lembre-se: SQL é declarativo, mas o DB2 pensa em álgebra

📚 Estude:

• DB2 Explain Plan

• Access Path

• Index usage

---

🏁 Conclusão Bellacosa Style

Relational Algebra não é coisa velha.
É fundação.

Enquanto linguagens vêm e vão,
o DB2 continua rodando batch crítico,
pagando salários,
processando bancos,
e sustentando o mundo corporativo.

E por baixo de tudo isso?

👉 Projection, Selection, Union, Product e Natural Join.

Que a Força (e o z/OS) esteja com você. 🖥️✨