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 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.