Brincadeiras de criança, memoria do Luigi a enviar beijinhos a Tia Nana...

 Nanazinha com carinho e amor do seu pequeno sobrinho Luigi, um super beijo para começar 2010 com ótimo estilo.

Fim de ano, 2009 terminando e o pequeno Luigi bem animado, brincando com seu pai lelé, mandando muitos beijos e abraços.... Ficando com frio e fazendo careta por causa do cheirinho ruim, ai esse pequeno é um barato, que rapazola fofo... te amo pequenino.

Coral dos Esquilinhos Malucos

O Natal dos Esquilinhos

Foi uma diversao quando comprei os Esquilinhos Cantores e ainda nao tinha ideia que o Luigi voce adorar a brincadeira. Imagine ele do alto dos seus quase 2 anos... iria abraçar, agarrar e brincar com eles.

E aproveitando o espirito natalino, aproveitamos para deixar mensagens de carinho para a familha.

 

Bellacosa Mainframe apresente IBM Mainframe Quiesce

🔷 QUIESCE no DB2: Congelando Tabelas com Segurança

No DB2 para IBM z/OS, QUIESCE é uma operação usada para garantir consistência de dados durante operações administrativas, especialmente quando você precisa fazer backup, reorganização ou manutenção de tabelas sem corromper os dados.

---

🕰️ Origem e Contexto

• Em ambientes mainframe, tabelas DB2 são acessadas 24/7, com milhares de transações simultâneas.

• Antigamente, para garantir integridade, os DBAs precisavam parar o sistema inteiro para fazer backups ou reorganizações.

• A IBM introduziu o QUIESCE para “congelar” temporariamente uma tabela ou partição, permitindo:

  • Manutenção de tabelas

  • Criação de backups consistentes

  • Redução do impacto nas transações online

---

⚙️ O que o QUIESCE faz?

Quando você executa um QUIESCE TABLE, o DB2:

1. Impede alterações na tabela

   • Nenhum INSERT, UPDATE ou DELETE é permitido.

2. Permite leitura

   • Transações de SELECT ainda podem ser executadas normalmente (dependendo da configuração).

3. Cria um ponto de consistência

   • Ideal para backup ou reorganização.

Pense no QUIESCE como uma pausa temporária e controlada na tabela, sem desligar o banco ou impactar outras tabelas.

---

🔹 Sintaxe básica

-- Congela a tabela para manutenção
QUIESCE TABLE schema.tabela;

• schema.tabela → tabela que você quer “congelar”

• DB2 mantém o estado consistente até que você libere a tabela.

Liberando a tabela:

QUIESCE TABLE schema.tabela RELEASE;

• Permite que transações de escrita voltem ao normal.

---

💡 Dicas e Boas Práticas

1. Use somente quando necessário

   • Congelar muitas tabelas por muito tempo = impacto em aplicações.

2. Combine com backups offline

   • QUIESCE + COPY OUT = backup consistente sem travar o banco inteiro.

3. Evite longos períodos de quiesce

   • Transações concorrentes ficam bloqueadas, podendo causar timeout ou deadlocks.

4. Verifique o status

SELECT * FROM SYSIBM.SYSTABLES
WHERE NAME = 'TABELA' AND CREATOR = 'SCHEMA';

• O estado QUIESCED indica que a tabela está congelada.

---

🔍 Curiosidades / Easter Eggs Bellacosa

• O comando QUIESCE só existe no DB2 para z/OS. Em DB2 LUW (Linux/Unix/Windows), a abordagem é diferente (LOCK + BACKUP).

• Internamente, DB2 usa locks especiais e pontos de consistência para garantir que mesmo transações longas não corrompam o backup.

• Alguns DBAs chamam o QUIESCE de “pause mágico”, porque a tabela parece congelada, mas outras operações continuam normalmente.

---

⚡ Impacto na Performance

• Transações de escrita ficam suspensas, então:

  • Muitas sessões concorrentes → podem acumular espera

  • Bancos com alto volume de updates → planejar QUIESCE fora do horário de pico

• Transações de leitura não são bloqueadas (depende do tipo de lock).

• É mais leve que DB2 LOCK TABLE ou downtime total.

---

🔑 Resumo Bellacosa

Conceito	Detalhe
O que é	Congela temporariamente uma tabela para manutenção/backup
Sintaxe	QUIESCE TABLE schema.tabela; e RELEASE
Permite SELECT?	Sim (dependendo do lock)
Permite INSERT/UPDATE/DELETE?	Não durante o quiesce
Quando usar	Backup consistente, reorganização, manutenção de dados
Impacto	Leve se curto; bloqueia transações de escrita

---

💡 Easter Egg:

Se você fizer QUIESCE de uma tabela grande, é quase como colocar a tabela em “hibernação”: DB2 mantém tudo consistente internamente, e você nem sente nada até liberar.

 

 

Bellacosa Mainframe explica como funciona uma query no Db2

☕ DB2 no IBM Mainframe: o que realmente acontece quando você executa um SQL

---

🧠 Introdução – “É só um SELECT”… será mesmo?

Para quem está começando, parece simples:

SELECT * FROM CONTA WHERE SALDO > 1000;

Mas no IBM Mainframe, esse comando aciona uma cadeia de decisões complexas, refinadas por décadas de engenharia.
Antes de qualquer dado ser lido, o DB2 passa por um verdadeiro ritual técnico — silencioso, preciso e implacável.

Hoje vamos abrir a caixa-preta e entender, passo a passo, o que o DB2 faz quando recebe um SQL:

1. Parse da query e validação de sintaxe

2. Bind de tabelas e colunas

3. Criação do executável

4. Cálculo do plano de execução

5. Execução do plano

Tudo isso antes do primeiro byte sair do disco.

---

🧩 Passo 1 – Parse da query: o DB2 vira professor de português

Parse the query and check for proper syntax

Neste primeiro momento, o DB2:

• Analisa a sintaxe SQL

• Verifica comandos, cláusulas e ordem

• Garante que a query está gramaticalmente correta

Exemplo de erro clássico:

SELEC * FROM CLIENTE;

⛔ Resultado: erro imediato.
O DB2 não tenta adivinhar sua intenção.

☕ Comentário Bellacosa
Mainframe não é Google.
Se escreveu errado, aprende rápido — na marra.

---

🧩 Passo 2 – Bind lógico: tabelas e colunas entram em cena

Bind the tables and columns

Aqui o DB2 pergunta:

• Essa tabela existe?

• Esse schema está correto?

• Essa coluna pertence a essa tabela?

• Você tem permissão para isso?

Exemplo:

SELECT CPF FROM ELJEFE.CLIENTE;

Se:

• Schema errado

• Coluna inexistente

• Falta de autorização RACF

⛔ Falha antes da execução.

🧠 Curiosidade Bellacosa
Grande parte dos erros “objeto não encontrado” não é objeto inexistente —
é SQLID e schema mal resolvidos.

---

🧩 Passo 3 – Criar o executável: SQL vira código de verdade

Create an executable and hand it to the optimizer

Aqui acontece a mágica que muitos ignoram.

No DB2 z/OS:

• SQL não é interpretado a cada execução

• Ele é transformado em um executável

• Esse executável é armazenado em um PACKAGE

💡 Em programas COBOL:

• O BIND cria o package

• O package faz parte de um PLAN

• O programa executa o PLAN

☕ Comentário El Jefe
No mainframe, SQL não é script descartável.
É artefato compilado, tratado com o mesmo respeito que código fonte.

---

🧩 Passo 4 – O Otimizador entra em ação

Calculate the optimal execution plan

Agora o DB2 pensa — muito.

O otimizador avalia:

• Índices disponíveis

• Estatísticas do catálogo

• Volume de dados

• Ordem de joins

• Tipo de acesso (index scan, table scan, etc.)

Ele calcula:
👉 o plano de execução mais eficiente possível

🧠 Easter Egg técnico
O otimizador do DB2 z/OS é considerado um dos mais sofisticados do mundo, porque:

• Precisa decidir rápido

• Precisa acertar

• E não pode errar em escala bilionária

---

🧩 Passo 5 – Execução do plano: agora sim, o dado anda

Run the execution plan

Somente agora:

• O DB2 acessa tablespaces

• Usa índices (ou não)

• Aplica filtros

• Retorna os dados

Importante:

• O DB2 não executa o SQL

• Ele executa o plano previamente calculado

☕ Comentário Bellacosa
Você escreve SQL.
Quem manda é o plano de execução.

---

🧠 Visão Jedi – o fluxo completo

Tudo isso acontece nesta ordem:

SQL
 ↓
Parse (sintaxe)
 ↓
Bind lógico (tabelas / colunas / segurança)
 ↓
Criação do executável (PACKAGE)
 ↓
Otimizador calcula o plano
 ↓
Execução do plano

Se algo falhar em qualquer etapa…
👉 nada executa.

---

🧪 Dicas práticas Bellacosa Mainframe

✔ Erro de SQL geralmente é erro de modelagem ou schema
✔ Estatísticas ruins = plano ruim
✔ BIND mal feito vira problema eterno
✔ Não confunda SQL bonito com SQL eficiente
✔ EXPLAIN é seu melhor amigo

---

🥚 Curiosidades finais

• Um mesmo SQL pode ter planos diferentes em ambientes distintos

• ALTER de índice pode mudar performance sem mudar código

• Em produção, o DB2 prefere estabilidade a “milagre”

• Otimizador não é mágico — ele só decide com base no que você fornece

---

☕ Conclusão – SQL no Mainframe é disciplina

No IBM Mainframe:

• SQL não é improviso

• Execução não é tentativa

• Performance não é sorte

Cada SELECT passa por um pipeline rigoroso, desenhado para não falhar.

No El Jefe, a verdade é simples:

Quem entende o caminho do SQL dentro do DB2, para de culpar o banco e começa a dominar o sistema.

Até o próximo café ☕
— Bellacosa Mainframe

🐉 DB2 Compilação, DBRM, BIND, PACKAGE e PLAN

Bellacosa Mainframe apresenta compilaçao COBOL com DB2 plan e package

🐉 DB2 + COBOL no Mainframe

Compilação, DBRM, BIND, PACKAGE e PLAN

Ao estilo Bellacosa Mainframe – do big bang ao SELECT

---

☕ Introdução (pegue seu café)

Todo padawan que entra no mundo do IBM Mainframe + COBOL + DB2 escuta termos quase místicos:

DBRM, BIND, PACKAGE, PLAN…

No começo parecem nomes de monstros de RPG 🧙‍♂️, mas na prática eles formam o coração da integração entre COBOL e DB2.

Este artigo explica de onde isso veio, por que existe, como funciona, como compilar, como errar (e sobreviver) e como pensar como um Jedi do Mainframe.

---

🕰️ Origem e História (por que tudo isso existe?)

📜 Anos 70–80: quando DB2 nasceu

• IBM precisava de um banco relacional para rodar junto com aplicações COBOL críticas.

• COBOL não entende SQL nativamente.

• Solução: criar um pré-compilador.

👉 Nasce o conceito de SQL EMBUTIDO (EXEC SQL).

Mas…

💥 Problema:

• O compilador COBOL não sabe o que é SQL.

💡 Solução IBM:

• Criar um artefato intermediário → DBRM (Database Request Module).

---

🧩 Visão Geral do Fluxo (o mapa do tesouro)

COBOL + EXEC SQL
        |
        v
DB2 PRECOMPILER
        |
        +--> COBOL PURO
        +--> DBRM
                  |
                  v
               BIND
                  |
                  v
               PACKAGE
                  |
                  v
                PLAN
                  |
                  v
              EXECUÇÃO

👉 Nada aqui é opcional.

---

📦 O que é DBRM (Database Request Module)?

🎯 Definição

DBRM é o arquivo que contém todas as instruções SQL extraídas do seu programa COBOL.

📌 Características

• Criado pelo pré-compilador do DB2

• Contém:

  • SELECT

  • INSERT

  • UPDATE

  • DELETE

  • CURSORS

• Não contém código COBOL

🧠 Pense assim:

DBRM = “O livro de feitiços SQL do programa”

---

🧱 O que é PACKAGE?

🎯 Definição

PACKAGE é o DBRM já compilado e otimizado pelo DB2.

📌 Por que PACKAGE existe?

Antigamente:

• Um PLAN gigante para tudo ❌

Hoje:

• Um PACKAGE por programa ✔️

• Melhor performance

• Melhor controle de versão

🧠 Analogia Bellacosa

PACKAGE = prato pronto na cozinha do DB2 🍝
DBRM = receita

---

🧠 O que é PLAN?

🎯 Definição

PLAN é o conjunto de PACKAGES que uma aplicação pode executar.

📌 Importante

• Quem executa é o PLAN

• O PLAN aponta para vários PACKAGES

• Normalmente 1 PLAN por aplicação/sistema

🧠 Jedi Tip:

Programa não executa PACKAGE direto. Executa PLAN.

---

🔨 Passo a Passo para um Padawan

🥋 Passo 1 – Escrever o COBOL com SQL

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

---

🥋 Passo 2 – Pré-compilação DB2

• Remove SQL

• Gera:

  • COBOL puro

  • DBRM

👉 Executado via DSNHPC

---

🥋 Passo 3 – Compilação COBOL

• Compila o código gerado

• Produz objeto (.OBJ)

---

🥋 Passo 4 – Linkedição

• Gera LOAD MODULE

---

🥋 Passo 5 – BIND PACKAGE

• Entrada: DBRM

• Saída: PACKAGE

---

🥋 Passo 6 – BIND PLAN

• Associa PACKAGES ao PLAN

---

🥋 Passo 7 – Executar

🎉 O programa roda feliz no CICS ou Batch.

---

📜 Exemplo de JCL – BIND PACKAGE

//BINDPKG EXEC PGM=IKJEFT01
//STEPLIB  DD DISP=SHR,DSN=DB2.DSNLOAD
//SYSTSPRT DD SYSOUT=*
//SYSUDUMP DD SYSOUT=*
//SYSTSIN  DD *
  DSN SYSTEM(DB2P)
  BIND PACKAGE(MEUSCHEMA.PKGPROG1)
       MEMBER(PROG1)
       ACTION(REPLACE)
       ISOLATION(CS)
       VALIDATE(BIND)
       OWNER(MEUSCHEMA)
/*

---

🚨 Erros Comuns (e como sobreviver)

❌ -805

DBRM ou PACKAGE não encontrado

✔️ Solução:

• PACKAGE não está no PLAN

• PLAN não foi rebindado

---

❌ -818

Timestamp mismatch

✔️ Solução:

• Rebind do PACKAGE

• Código recompilado mas DBRM antigo

---

❌ -204

Objeto não existe

✔️ Solução:

• Tabela/view não existe

• Schema errado

---

💡 Dicas de Ouro Bellacosa

☕ 1 DBRM = 1 PACKAGE

☕ Nunca use PLAN gigante com tudo

☕ Sempre versionar PACKAGE

☕ Nomeie PACKAGE com ambiente:

PKGPROG1_DEV
PKGPROG1_HML
PKGPROG1_PRD

---

🥚 Easter Eggs (curiosidades)

🥚 DBRM é tão antigo que veio do System R, o avô do DB2

🥚 Muitos ambientes ainda têm PLAN criados nos anos 90 😱

🥚 Rebind pode melhorar performance sem recompilar COBOL

🥚 EXPLAIN do PACKAGE mostra o plano de acesso

---

🧙 Comentários de Mestre Jedi

Se você entende DBRM, PACKAGE e PLAN…
Você já saiu do nível Padawan.

Quem domina BIND domina o DB2.

---

📌 Conclusão

DB2 + COBOL não é magia negra.

É:

• Engenharia

• História

• Performance

• Disciplina

E quando bem feito…

🚀 Roda por décadas sem cair.

---

☕ Um Café no Bellacosa Mainframe

 

Bellacosa Mainframe apresenta Guia de Auditoria Z/OS

📘 Guia de Auditoria z/OS Completo

Do RACF ao SMP/E: como provar que seu mainframe é confiável

“Auditoria em z/OS não é caça ao erro.
É validação de maturidade operacional.”

---

🎯 Objetivo deste guia

Este guia serve para:

• Preparar ambientes para auditoria

• Responder auditores com evidência técnica

• Evitar não conformidades

• Padronizar governança em z/OS

👉 Não é teoria. É prática de campo.

---

🧠 Visão geral da auditoria em z/OS

Auditoria em z/OS gira em torno de 5 pilares:

1️⃣ Controle de acesso
2️⃣ Integridade do sistema
3️⃣ Gestão de mudanças
4️⃣ Rastreabilidade
5️⃣ Continuidade operacional

Cada pilar tem ferramentas nativas do mainframe.

---

🔐 Pilar 1 – Controle de Acesso (RACF / ACF2 / TSS)

O auditor verifica:

• IDs privilegiados

• Perfis genéricos

• UACC

• Logging

• Segregação de funções

Evidências:

• LISTUSER

• RLIST

• Relatórios SMF

• Revisão periódica de acessos

📌 Privilégio excessivo reprova auditoria.

---

🛡️ Pilar 2 – Integridade do Sistema

Ferramentas-chave:

• SMP/E

• CSI

• DLIB

• TARGET libraries

O auditor quer saber:

• Quem muda o sistema

• Como muda

• Se há controle

📌 Aqui o SMP/E reina absoluto.

---

🔁 Pilar 3 – Gestão de Mudanças

Avaliação típica:

• Processo RECEIVE/APPLY/ACCEPT

• APPLY CHECK obrigatório

• Análise de ++HOLD e ++ERROR

• USERMOD documentado

Evidências:

• Outputs SMP/E

• Change records

• APARs e PTFs

---

🧩 Pilar 4 – Rastreabilidade e Evidência

O auditor exige:

• Histórico preservado

• Logs acessíveis

• Responsáveis identificados

Ferramentas:

• CSI

• SMF

• Logs RACF

• Versionamento de JCL

📌 Sem evidência, não existe controle.

---

🔄 Pilar 5 – Continuidade e Recuperação

Avaliação:

• Backup de CSI

• Capacidade de RESTORE

• Planos de contingência

• Testes documentados

📌 Auditoria não aceita “nunca testamos”.

---

📦 Auditoria por componente (check rápido)

🔹 SMP/E

✔ Controle de acesso
✔ APPLY CHECK
✔ ACCEPT consciente
✔ USERMOD controlado

🔹 RACF

✔ UACC=NONE
✔ Logging ativo
✔ Revisão periódica

🔹 JES / System

✔ Parâmetros controlados
✔ Alterações documentadas

🔹 SMF

✔ Coleta ativa
✔ Retenção definida

---

🚨 Red flags clássicos em auditoria z/OS

❌ IDs genéricos
❌ ALTER irrestrito
❌ USERMOD esquecido
❌ PTFs de segurança atrasados
❌ Falta de documentação

👉 Tudo isso vira finding.

---

🧠 Caso real (estilo Bellacosa)

Auditor pergunta sobre um módulo alterado
Não há registro no SMP/E
Ninguém sabe quem fez

📌 Conclusão:

Ambiente sem governança.

---

🎓 Como se preparar para auditoria

• Trate auditoria como rotina

• Use SMP/E como aliado

• Automatize evidências

• Documente decisões

• Revise acessos

💡 Dica Bellacosa:

“Auditoria bem-sucedida começa meses antes.”

---

🧠 Curiosidades Bellacosa

• Auditor confia mais no CSI do que em planilha

• Mainframe já nasce auditável

• Falha é quase sempre humana, não técnica

---

🧾 Encerramento – Guia de Auditoria z/OS

z/OS não é inseguro.
Inseguro é rodar sem controle.

Quem domina:

• RACF

• SMP/E

• Processos

👉 passa em qualquer auditoria.

📘💾🛡️🔥

 

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.