Núm. 5Proyecto para CESVI México

CESVI RAT

Base de datos para reconstrucción de accidentes · CESVI México

Mi rol: Coordinador de base de datos · equipo de 6
Periodo: Feb – abr 2026

El problema

Los peritos de CESVI México documentaban mediciones en papel, hacían cálculos en hojas de cálculo y no tenían un sistema único para consultar casos. El módulo RAT (Reconstrucción y Análisis de Tránsito) tenía que cubrir el flujo completo, del levantamiento en la escena al reporte, integrado a la plataforma base que CESVI ya usa.

Qué construí

Fui el coordinador de base de datos en un equipo de 6 (28 de los 132 commits del proyecto). Mi trabajo fue la capa de datos:

El esquema de 54 tablas en 7 grupos funcionales: 3 de infraestructura, 1 del módulo de IA, 1 de perfil del perito, 27 catálogos, 3 tablas técnicas McHenry, 15 transaccionales (del incidente al reporte) y 4 del sistema de plantillas.
La evolución del modelo por versiones, conforme se aclaraban los requisitos: 51 tablas en la primera, 49 en la v1.1, 51 en la v1.3 y 54 en la v1.4.
Un script SQL de 969 líneas para MySQL 8.0+ con InnoDB, llaves foráneas y catálogos precargados.
6 migraciones que crean las 54 tablas, y los modelos Eloquent. 50 de mis 54 modelos y 3 de mis 4 controladores llegaron sin cambios al backend del equipo, incluido el de la captura del expediente paso a paso.
El diccionario de datos v1.4 y la documentación técnica de cada versión, para que backend, frontend y cliente trabajaran sobre el mismo modelo.

Arquitectura

Diagrama del modelo de datos: el frontend React del equipo llama a una API Lumen con Eloquent; la API trabaja sobre 7 grupos de tablas: infraestructura (3), módulo de IA (1), perfil del perito (1), catálogos (27), tablas técnicas McHenry (3), transaccionales del incidente al reporte (15) y plantillas (4); la infraestructura se apoya en la tabla de usuarios de la plataforma base de CESVI.

Resultados

No hay métricas de uso: el entregable fue el modelo de datos y su documentación. Lo comprobable es que el esquema y el diccionario están en el repositorio y que el backend del equipo usa mis migraciones y modelos.

Límites conocidos

El esquema incluye la tabla de rigidez A/B por categoría McHenry y un endpoint para consultarla, pero los coeficientes no están precargados y el backend no calcula la velocidad. Eso quedó fuera del alcance entregado.
El proyecto no tiene tests propios, CI ni despliegue, y el README principal es una plantilla.