Fase 2 — Análisis del modelo origen (DSNube)

Proyecto: GuajiraNet ISP
Esquema origen/destino Bronze: guajiranetispsas
Motor: PostgreSQL (API DSNube → Aurora db_bronze)
Versión documento: 1.0 — Mayo 2026

1. Objetivo del análisis

Revisar el comportamiento de tablas, identificadores y relaciones del sistema fuente para:

Evaluar coherencia estructural antes del MER priorizado.
Identificar entidades núcleo usadas por reportes IT (37 consultas SQL).
Definir riesgos para integración y gobierno de datos en Bronze.

2. Panorama cuantitativo

Métrica	Valor	Fuente
Objetos totales en esquema	827	`inventario_tablas.md`
Tablas base (`BASE TABLE`)	~778	information_schema
Vistas (`VIEW`, prefijo `v*`)	~49	information_schema
Tablas con columna fecha (delta ETL)	280	ETL delta
Tablas en consultas IT priorizadas	~45 útiles	`inventario_consultas_sql.md`

3. Convención de nombres (prefijos)

El modelo origen usa prefijos semánticos sobre un mismo esquema plano (sin bases de datos separadas por módulo):

Prefijo	Rol típico	Cantidad aprox.	Observaciones
`ma*`	Maestros (catálogos, parametrización)	233 tablas	Productos, terceros, perfiles, estratos, CRM catálogos
`tr*`	Transacciones / movimientos	218 tablas + 2 vistas	Facturas, contabilidad, CRM oportunidades, nómina
`tm*`	Tablas mixtas / integración (JSON, cartera)	37	`tmjsoncontract`, `tmcartera` — críticas para ISP/Wispro
`tn*`	Transacciones auxiliares / nómina relacionada	58	Complemento operativo
`nr*`	Nómina / RRHH (base)	76	Empleados, apropiaciones
`si*`	Sistema / usuarios	31	`siusuarios`, CRM usuarios
`v*`	Vistas de presentación	49	Lógica de negocio embebida en SQL; no siempre tienen tabla base 1:1
`nu`, `rb`, `sy`, `em`, `sp*`	Módulos menores / empresa	< 20	`empresa` como vista/tabla única

Implicación MER: El modelo no está normalizado por capas en origen; la priorización debe ser por dominio de negocio, no por prefijo solo.

4. Patrones de identificación (IDs)

Actualizado con metadatos reales (_metadata_pk_fk.json): 568 PK, 1238 FK declaradas en origen.

4.1 Claves primarias (confirmadas en origen)

Tabla	PK en origen
`materceros`	`nit`
`matercerosuc`	`nit`, `idsuc` (compuesta)
`trfacturas`	`idsuc`, `prefijo`, `numero`
`trfacturasdet`	`idsuc`, `prefijo`, `numero`, `pos`
`trcontab_docenc`	`idsuc`, `prefijo`, `numero`
`trcontab_docdet`	`id_gen` (surrogate; encabezado es compuesto)
`trcrmoportunidad`	`id`
`tmjsoncontract`	(ver `05_metadatos_pk_fk_priorizado.md`)

Muchas tablas ma* usan PK surrogate (id, idproducto).
Documentos transaccionales usan clave compuesta (idsuc, prefijo, numero) de forma consistente.
Hallazgo: trcontab_docdet no comparte PK con el encabezado; enlaza por FK fk_documentopk hacia trcontab_docenc.

4.2 Relaciones lógicas recurrentes (validadas en consultas IT)

Desde	Hacia	Condición de join (origen)	Dominio
`matercerosuc`	`materceros`	`nit`	Maestro tercero
`matercerosuc`	`trfacturas`	`nit` (+ `sucursal` / `idsuc`)	Facturación
`trfacturas`	`trfacturasdet`	`idsuc, prefijo, numero`	Detalle factura
`trfacturasdet`	`maproductos`	`idproducto`	Producto
`matercerosuc`	`trcontab_docdet`	`nit` + `sucursal`/`idsuc`	Contabilidad / cartera
`matercerosuc`	`tmcartera`	`nit` + `sucursal`	Cartera
`matercerosuc`	`maperfilcartera`	`idperfilcartera`	Perfil cartera
`matercerosuc`	`tmjsoncontract`	`idcontrato`	Contrato Wispro
`matercerosuc`	`maestrato`	`codestrato` → `id`	Estratificación
`mafacturasperiodiconit`	`mafacturasperiodiconitproducto`	`id` = `idfacnit`	Facturación periódica
`mafacturasperiodiconit`	`mafacturasperiodico`	`idfactper`	Config. periódica
`trnrhapropiaciondet`	`trnrhapropiacion`	`idsuc, prefijo, numero`	Nómina
`trnrhapropiaciondet`	`nrhempleado` / `vnrhempleado`	`idempleado`	Empleado

4.3 Integración JSON (Wispro / ISP)

Tablas tmjson* almacenan payloads (datajson) con identificadores externos (public_id, planes). Las consultas hacen:

(w.datajson ->> 'public_id')::integer AS contrato

Riesgo: Relaciones no declaradas como FK en BD; dependen de convención en JSON.

5. Coherencia estructural — hallazgos

Fortalezas

Modelo maduro y completo para ERP/ISP (contabilidad + facturación + CRM + nómina).
Joins de reportes IT son consistentes en nit, idsuc, prefijo/numero.
Bronze (Fase 1) replica fielmente nombres y tipos → trazabilidad con origen.

Debilidades / riesgos

#	Hallazgo	Impacto MER / Bronze
1	Vistas `v*` usadas en reportes sin equivalencia documentada a tablas base	MER debe marcar vistas como entidades lógicas; Bronze puede materializar vistas o recrear en Silver
2	FKs en origen: 1238 declaradas; algunas son multi-columna no estándar (ej. `trfacturas.nit` → `matercerosuc.idsuc`)	Replicar en Bronze solo FKs validadas; ver `05_metadatos_pk_fk_priorizado.md`
3	Tablas voluminosas (`trcontab_docdet` > 1M filas)	MER priorizado no implica full historial en todos los análisis
4	Alias en consultas (`cambios`, `primer_cambio`) no son tablas	Excluir del subconjunto físico
5	Tipos y longitudes inferidos en ETL	Revisar columnas críticas (`numeric`, `varchar`) en validación funcional

6. Dominios de negocio (agrupación para MER)

flowchart TB
  subgraph maestros [Maestros]
    MT[materceros]
    MTS[matercerosuc]
    MP[maproductos]
    ME[maestrato]
    MPC[maperfilcartera]
  end
  subgraph operacion [Operación ISP]
    TC[tmjsoncontract]
    TCL[tmjsonclient]
    MFP[mafacturasperiodiconit]
  end
  subgraph facturacion [Facturación]
    TF[trfacturas]
    TFD[trfacturasdet]
  end
  subgraph contabilidad [Contabilidad / Cartera]
    TCD[trcontab_docdet]
    TCE[trcontab_docenc]
    TCAR[tmcartera]
  end
  subgraph crm [CRM]
    TOP[trcrmoportunidad]
    TIC[trispcampana]
  end
  MTS --> MT
  MTS --> TF
  TF --> TFD
  TFD --> MP
  MTS --> TCD
  MTS --> TCAR
  MTS --> TC
  MFP --> MTS