# Alineacion Backend vs Schema Consolidado

Estado: **DIAGNOSTICADO, NO CORREGIDO**

El backend actual sigue modelando una estructura previa, incompatible con el schema consolidado de importación SGTECBA. No se aplicaron cambios en código en esta fase; solo se dejó el diagnóstico para priorizar una futura alineación controlada.

## Resumen de impacto

- El schema consolidado define la relación académica alrededor de `inscripciones`, `ofertas_asignaturas`, `sesiones_asistencia` y `detalle_asistencia`.
- El backend actual sigue exponiendo `matriculaciones`, `ofertas_asignatura` y `asistencias`.
- Si se ejecutara una carga final sobre el schema consolidado sin alinear backend, las rutas y consultas actuales no leerían correctamente la estructura final.

## Hallazgos

| archivo_backend | linea_aprox | nombre_usado_actualmente | nombre_correcto_schema | impacto | cambio_recomendado | prioridad |
|---|---:|---|---|---|---|---|
| `backend/app/models/entities.py` | 110 | `__tablename__ = "ofertas_asignatura"` | `ofertas_asignaturas` | La entidad ORM no apunta a la tabla real del schema consolidado. | Renombrar tabla ORM y relaciones a `OfertaAsignatura` -> `ofertas_asignaturas`. | ALTA |
| `backend/app/models/entities.py` | 144 | `__tablename__ = "matriculaciones"` | `inscripciones` | La capa ORM persiste una tabla inexistente en el schema final. | Reemplazar `Matriculacion` por `Inscripcion` con las columnas reales del schema consolidado. | ALTA |
| `backend/app/models/entities.py` | 160 | `__tablename__ = "asistencias"` | `detalle_asistencia` + `sesiones_asistencia` | El modelo actual colapsa en una sola tabla una estructura que en el schema final está separada. | Rediseñar el modelo ORM para distinguir sesión de clase y detalle de asistencia. | ALTA |
| `backend/app/models/entities.py` | 152 | `ForeignKey("ofertas_asignatura.id")` | `ForeignKey("ofertas_asignaturas.id")` | Las FKs ORM quedarían rotas contra el schema consolidado. | Ajustar referencias y nombres de relación. | ALTA |
| `backend/app/models/entities.py` | 176 | `ForeignKey("ofertas_asignatura.id")` | `ForeignKey("ofertas_asignaturas.id")` | Mismo problema de FK en asistencia. | Ajustar referencias y separar la lógica en sesión/detalle. | ALTA |
| `backend/app/models/entities.py` | 92, 139 | `matriculaciones` como relación de `Estudiante` y `OfertaAsignatura` | `inscripciones` | Las relaciones ORM no reflejan la semántica ni el nombre real del modelo final. | Cambiar relaciones a `inscripciones`. | ALTA |
| `backend/app/api/v1/api.py` | 18 | prefijo `/matriculaciones` | `/inscripciones` | La API pública expone nombres que no corresponden al modelo final. | Reemplazar router y prefijo por `inscripciones`. | MEDIA |
| `backend/app/api/v1/api.py` | 19 | prefijo `/asistencias` | `/sesiones-asistencia` y/o `/detalle-asistencia` | La API actual no distingue sesión de detalle. | Rediseñar endpoints según el schema final. | ALTA |
| `backend/app/api/v1/routes/matriculaciones.py` | 8-45 | `Matriculacion`, `OfertaAsignatura`, `fecha_registro` | `Inscripcion`, `ofertas_asignaturas`, `fecha_inscripcion` | Las consultas no operarán sobre el schema consolidado. | Reescribir la ruta usando `Inscripcion` y el join correcto a `ofertas_asignaturas`. | ALTA |
| `backend/app/api/v1/routes/asistencias.py` | 8-52 | `Asistencia` único registro por evento | `sesiones_asistencia` + `detalle_asistencia` | Las consultas no podrán representar la nueva integridad referencial. | Separar lectura de sesión y detalle, y usar `estado_asistencia` desde `detalle_asistencia`. | ALTA |
| `backend/app/services/dashboard_service.py` | 19-20 | `total_matriculaciones`, `total_asistencias` | `total_inscripciones`, `total_detalle_asistencia` | El dashboard cuenta entidades con nombres y granularidad antiguas. | Reescribir métricas con las tablas finales. | MEDIA |
| `backend/app/services/dashboard_service.py` | 30-35 | `Asistencia` agregado directo por estado | `detalle_asistencia` unido a `estados_asistencia` | La agregación actual no respeta la separación sesión/detalle. | Rehacer consulta sobre `detalle_asistencia`. | ALTA |
| `backend/app/schemas/common.py` | 53 | `MatriculacionRead` | `InscripcionRead` | Los contratos de respuesta no reflejan la semántica final. | Renombrar schema y ajustar campos. | MEDIA |
| `backend/app/schemas/common.py` | 65 | `AsistenciaRead` | `DetalleAsistenciaRead` / `SesionAsistenciaRead` | El DTO actual combina conceptos distintos. | Separar contratos por nivel de entidad. | MEDIA |
| `backend/app/schemas/dashboard.py` | 13-16 | `total_matriculaciones`, `total_asistencias`, `asistencias_por_estado` | `total_inscripciones`, `total_detalle_asistencia`, agregados revisados | Inconsistencia semántica de contratos de dashboard. | Ajustar nombres y métricas expuestas. | MEDIA |

## Referencias clave

- [entities.py](/C:/Users/Usuario/Documents/ZIS%20TECBA/PROYECTOS/sgetecba/backend/app/models/entities.py:110)
- [matriculaciones.py](/C:/Users/Usuario/Documents/ZIS%20TECBA/PROYECTOS/sgetecba/backend/app/api/v1/routes/matriculaciones.py:15)
- [asistencias.py](/C:/Users/Usuario/Documents/ZIS%20TECBA/PROYECTOS/sgetecba/backend/app/api/v1/routes/asistencias.py:15)
- [dashboard_service.py](/C:/Users/Usuario/Documents/ZIS%20TECBA/PROYECTOS/sgetecba/backend/app/services/dashboard_service.py:19)
- [api.py](/C:/Users/Usuario/Documents/ZIS%20TECBA/PROYECTOS/sgetecba/backend/app/api/v1/api.py:18)

## Diagnóstico final

La importación final y el backend no deben evolucionar como tareas separadas. Si se aprueba una futura FASE 2 de datos, el backend debería alinearse en el mismo ciclo o inmediatamente después, porque hoy existe una incompatibilidad estructural real entre:

- nombres de tablas
- claves foráneas ORM
- granularidad de asistencia
- contratos de API
- métricas de dashboard

Prioridad general: **ALTA**.
