🔍 Relatório de Redundâncias entre Schemas

Este documento identifica redundâncias, duplicações e estruturas similares entre os schemas do CSuite.

Última atualização: 2025-12-31

📊 Resumo Executivo

Redundâncias Identificadas

1. Tabelas Duplicadas: 4 encontradas → 3 removidas, 1 mantida (intencional)
2. Views Duplicadas: 6 encontradas → Todas removidas de csuite (stubs)
3. Prefixos Cross-Schema: 4 prefixos analisados → Nenhuma redundância real encontrada
4. Estruturas Similares: 12 encontradas → Requerem análise individual

Status Geral

• ✅ Tabelas duplicadas: 3 removidas (csuite.core_interactions, csuite.core_orders, csuite.companies_raw)
• ✅ Views duplicadas: 6 removidas de csuite (stubs do Dashboard Executivo)
• ✅ Prefixos cross-schema: Nenhuma redundância real (separações são intencionais)
• ✅ Estruturas similares: 7 grupos analisados → 6 sem redundância, 1 requer investigação (Policies)

🔍 Análise Detalhada

1. Tabelas Duplicadas (4 encontradas)

Tabelas com o mesmo nome encontradas em múltiplos schemas:

✅ core_interactions - RESOLVIDO (31/12/2025)

• Schemas: core, csuite
• Análise:
• core.core_interactions - Tabela principal com dados reais (235 rows) ✅ Mantida
• csuite.core_interactions - Vazia (0 rows) ✅ REMOVIDA
• Ação: Removida de csuite (não estava sendo usada, vazia)

✅ core_orders - RESOLVIDO (31/12/2025)

• Schemas: core, csuite
• Análise:
• core.core_orders - Tabela principal com dados reais (76,491 rows) ✅ Mantida
• csuite.core_orders - Vazia (0 rows) ✅ REMOVIDA
• Ação: Removida de csuite (não estava sendo usada, vazia)

✅ companies_raw - RESOLVIDO (31/12/2025)

• Schemas: csuite, csuite_staging
• Análise:
• csuite.companies_raw - Vazia (0 rows) ✅ REMOVIDA
• csuite_staging.companies_raw - Dados de staging (14 rows) ✅ Mantida
• Ação: Removida de csuite (staging correto é csuite_staging)

✅ pg_case - MANTIDO (intencional)

• Schemas: csuite_executive, csuite_memory
• Análise:
• csuite_executive.pg_case - Policy Guardian principal (29 rows, 17 colunas) ✅ Mantida
• csuite_memory.pg_case - Memória institucional (14 rows, 21 colunas) ✅ Mantida
• 13 IDs em comum (podem ser relacionadas)
• Estruturas diferentes (17 vs 21 colunas)
• FK encontrada: csuite_memory.pg_case.source_item_id → csuite_memory.mm_item.item_id
• Conclusão: MANTIDAS AMBAS - Separação de concerns intencional:
• csuite_executive.pg_case = Policy Guardian (decisões, violações)
• csuite_memory.pg_case = Memória institucional (precedentes, aprendizado)

2. Views Duplicadas (6 encontradas)

Views do Dashboard Executivo duplicadas entre csuite e csuite_context:

✅ Views vw_exec_dashboard_* - RESOLVIDO (31/12/2025)

• Schemas: csuite, csuite_context
• Views afetadas:
• vw_exec_dashboard_inbox_today
• vw_exec_dashboard_kpis
• vw_exec_dashboard_lowturn_top20
• vw_exec_dashboard_radar_top
• vw_exec_dashboard_ruptura_top20

• vw_exec_dashboard_sellers

• Análise:

• csuite_context é o schema correto (dados reais, 48 views relacionadas) ✅ Mantido
• csuite tinha views antigas/stubs (vazias) ✅ REMOVIDAS
• Ação:
• ✅ Removidas de csuite (eram stubs vazias)
• ✅ Mantidas em csuite_context (fonte de verdade)
• ✅ Código Python já usa csuite_context.vw_exec_dashboard_*

3. Prefixos Cross-Schema

Prefixos que aparecem em múltiplos schemas:

✅ Prefixo core_* - ANALISADO (31/12/2025)

• Schemas: core (11 tabelas), csuite (2 tabelas)
• Análise:
• core schema: Dados gerais de clientes/pedidos (11 tabelas com dados reais)
• csuite schema: 2 tabelas específicas do CSuite B2B
  • csuite.core_revendas (0 rows) - Revendas (carteira do canal)
  • csuite.core_sellers (0 rows) - Vendedores (equipe de vendas)
• Nenhum nome duplicado: Tabelas são diferentes
• Foreign Keys: Ambas têm FKs apontando para elas:
  • context_radar.features_revenda_rfr.revenda_id → csuite.core_revendas
  • context_radar.tasks_seller_day.revenda_id → csuite.core_revendas
  • context_radar.tasks_seller_day.seller_id → csuite.core_sellers
  • csuite.core_revendas.seller_id → csuite.core_sellers
• Uso no código: Usadas em csuite-sales-manager (JOINs em queries)
• Conclusão: NÃO são redundâncias - Tabelas diferentes com propósitos diferentes
• Recomendação:
• ✅ MANTER: Tabelas são necessárias e usadas no código
• ⚠️ AÇÃO: Verificar se devem ser populadas (estão vazias mas têm FKs)

✅ Prefixo ops_* - ANALISADO (31/12/2025)

• Schemas: csuite_cfo_ops (10 tabelas), csuite_context (2 tabelas), csuite_reality (1 tabela)
• Análise:
• csuite_cfo_ops: Operações financeiras e logística (10 tabelas com dados)
  • ops_alert, ops_capacity_usage_daily, ops_cost_rate_snapshot, ops_event, etc.
• csuite_context: Sinais de contexto para decisões (2 tabelas, 0 rows)
  • ops_context_signal, ops_signal_evidence
• csuite_reality: Eventos brutos (1 tabela, 0 rows)
  • ops_raw_event
• Nenhum nome duplicado: Todas as tabelas têm nomes únicos
• Propósitos diferentes: CFO ops, context signals, raw events
• Conclusão: Separação intencional de concerns - Não são redundâncias
• Recomendação: ✅ MANTER - Nenhuma ação necessária

✅ Prefixo pg_* (Policy Guardian) - ANALISADO (31/12/2025)

• Schemas: csuite_executive (14 tabelas), csuite_memory (14 tabelas)
• Análise:
• csuite_executive: Policy Guardian principal (14 tabelas)
  • pg_audit_log, pg_case, pg_case_link, pg_decision_log, pg_director_decision, etc.
  • Engine de decisões, violações, auditoria
• csuite_memory: Memória institucional (14 tabelas)
  • pg_case, pg_case_alert, pg_case_event, pg_policy_decay_log, etc.
  • Precedentes, aprendizado, tuning de políticas
• Apenas 1 nome duplicado: pg_case (já analisado na seção 1)
• Outras 13 tabelas: Todas diferentes em cada schema
• Conclusão: Separação intencional de concerns - Não são redundâncias
• csuite_executive.pg_* = Policy Guardian (decisões, violações)
• csuite_memory.pg_* = Memória institucional (precedentes, aprendizado)
• Recomendação: ✅ MANTER - Nenhuma ação necessária (já documentado)

✅ Prefixo policy_* - ANALISADO (31/12/2025)

• Schemas: csuite_executive (8 tabelas), csuite_governance (2 tabelas)
• Análise:
• csuite_executive: Engine de políticas (8 tabelas)
  • policy_change_log, policy_executions, policy_parameters, policy_rule_actions, policy_rules, etc.
  • Execução, regras, parâmetros
• csuite_governance: Governança de políticas (2 tabelas)
  • policy_change_proposal (1 row), policy_performance_snapshot (0 rows)
  • Aprovação, monitoramento
• Nenhum nome duplicado: Todas as tabelas têm nomes únicos
• Propósitos diferentes: Engine (execução) vs Governance (aprovação, monitoramento)
• Conclusão: Separação intencional de concerns - Não são redundâncias
• Recomendação: ✅ MANTER - Nenhuma ação necessária

4. Estruturas Similares (7 grupos analisados)

Tabelas com nomes muito similares (80%+ similaridade):

✅ Policy Guardian Output - ANALISADO (31/12/2025)

• pg_guardian_output (csuite_executive, 353 rows, 7 cols) ≈ guardian_output (csuite_governance, 1 row, 15 cols)
• Análise: Estruturas diferentes (7 vs 15 colunas), apenas 2 colunas em comum
• Conclusão: ✅ NÃO são redundâncias - Separação intencional (execução vs governança)
• Recomendação: ✅ MANTER - Nenhuma ação necessária

✅ Policy Violations - ANALISADO (31/12/2025)

• cv_policy_violation (csuite_customer_value, 4,803 rows, 12 cols) ≈ policy_violations (csuite_executive, 0 rows, 10 cols)
• Análise: Estruturas diferentes (12 vs 10 colunas), apenas 4 colunas em comum
• Conclusão: ✅ NÃO são redundâncias - Diferentes domínios (Customer Value vs Policy Engine)
• Recomendação: ✅ MANTER - Nenhuma ação necessária

✅ Policy Rules - ANALISADO (31/12/2025)

• ctx_policy_rules (csuite_context, 6 rows, 7 cols) ≈ cv_policy_rule (csuite_customer_value, 3 rows, 14 cols) ≈ policy_rules (csuite_executive, 11 rows, 12 cols)
• Análise: Estruturas diferentes (7, 14, 12 colunas), apenas 3 colunas em comum
• Conclusão: ✅ NÃO são redundâncias - Servem contextos diferentes (context, customer value, executive)
• Recomendação: ✅ MANTER - Nenhuma ação necessária

✅ Action Items - ANALISADO (31/12/2025)

• action_items (csuite, 31 rows, 13 cols) ≈ ctx_action_items (csuite_context, 1,922 rows, 14 cols) ≈ gov_action_item (csuite_governance, 0 rows, 16 cols)
• Análise: Estruturas diferentes (13, 14, 16 colunas), apenas 5 colunas em comum, FKs diferentes
• Conclusão: ✅ NÃO são redundâncias - Diferentes domínios (geral, contexto, governança)
• Recomendação: ✅ MANTER - Nenhuma ação necessária

⚠️ Policies - ANALISADO (31/12/2025) - REQUER INVESTIGAÇÃO

• cv_policy (csuite_customer_value, 7 rows, 9 cols) ≈ gov_policy (csuite_governance, 5 rows, 11 cols) ≈ pg_policy (csuite_executive, 6 rows, 10 cols)
• Análise: Estruturas muito similares (8 colunas em comum), todas têm dados (5-7 rows)
• Conclusão: ⚠️ REQUER INVESTIGAÇÃO - Estruturas muito similares, podem ser relacionadas
• Recomendação: 🔍 INVESTIGAR - Verificar se são a mesma entidade "Policy" vista de diferentes perspectivas. Considerar view unificada ou sincronização se forem relacionadas.

✅ Alert Rules - ANALISADO (31/12/2025)

• alert_rules (csuite, 1 row, 10 cols) ≈ mm_alert_rule (csuite_memory, 16 rows, 14 cols)
• Análise: Estruturas diferentes (10 vs 14 colunas), apenas 3 colunas em comum
• Conclusão: ✅ NÃO são redundâncias - Diferentes domínios (geral vs memória)
• Recomendação: ✅ MANTER - Nenhuma ação necessária

✅ Ops Events - ANALISADO (31/12/2025)

• ops_event (csuite_cfo_ops, 4 rows, 18 cols) ≈ ops_raw_event (csuite_reality, 0 rows, 12 cols)
• Análise: Estruturas diferentes (18 vs 12 colunas), apenas 5 colunas em comum
• Conclusão: ✅ NÃO são redundâncias - Pipeline de dados (raw → processado)
• Recomendação: ✅ MANTER - Separação intencional (raw vs processado)

💡 Recomendações

✅ Concluído (31/12/2025)

1. ✅ Tabelas duplicadas removidas
2. csuite.core_interactions - Removida (vazia)
3. csuite.core_orders - Removida (vazia)
4. csuite.companies_raw - Removida (vazia)

5. pg_case - Mantida em ambos schemas (intencional)

6. ✅ Views duplicadas removidas

7. 6 views vw_exec_dashboard_* removidas de csuite (stubs)

8. Mantidas em csuite_context (fonte de verdade)

9. ✅ Prefixos cross-schema analisados

10. Nenhuma redundância real encontrada
11. Todas as separações são intencionais (diferentes concerns)

⏳ Pendente

1. ✅ Estruturas similares analisadas (31/12/2025)
2. 7 grupos analisados
3. 6 grupos: Nenhuma redundância (separação intencional)
4. 1 grupo (Policies): Requer investigação adicional

5. Ver docs/ESTRUTURAS_SIMILARES_ANALYSIS.md para análise detalhada

6. Verificar necessidade de popular tabelas vazias

7. csuite.core_revendas (0 rows, mas tem FKs apontando para ela)
8. csuite.core_sellers (0 rows, mas tem FKs apontando para ela)

📋 Documentação

1. Documentar decisões arquiteturais
2. Por que certas redundâncias existem
3. Quando são intencionais vs acidentais
4. Ver docs/PREFIXOS_CROSS_SCHEMA_ANALYSIS.md para análise detalhada

🔄 Processo de Consolidação

Se decidir consolidar redundâncias:

Fase 1: Análise

1. Identificar todas as redundâncias
2. Mapear dependências
3. Avaliar impacto

Fase 2: Planejamento

1. Definir fonte de verdade
2. Criar plano de migração
3. Preparar rollback

Fase 3: Execução

1. Migrar dados
2. Atualizar código
3. Testar extensivamente

Fase 4: Limpeza

1. Remover estruturas antigas
2. Atualizar documentação
3. Validar sistema

📝 Notas Importantes

• Nem toda redundância é ruim: Algumas podem ser intencionais para performance ou isolamento
• Análise cuidadosa necessária: Verificar se estruturas similares servem propósitos diferentes
• Impacto de mudanças: Consolidação pode quebrar código existente
• Testes extensivos: Sempre testar após consolidação

Para atualizar este relatório, execute:

python3 analyze_redundancies.py