Hilari Web

🔍 Lección 3: Diseño del Modelo Entidad-Relación y Creación de Migraciones en Laravel 🚀🗄️

En este tercer capítulo nos sumergimos de lleno en la arquitectura de datos del proyecto. Diseñamos las tablas principales y estructuramos la lógica de negocio de nuestro Sistema de Turnos Laborales. Traducimos el diagrama Entidad-Relación (ER) directamente a archivos de migración de Laravel mediante comandos de Artisan, configurando restricciones de integridad, llaves foráneas y automatizaciones de borrado en cascada para soportar un ecosistema multirubro totalmente funcional.

🎯 Lo realizado en este capítulo

• 🖥️ Configuración del Entorno de Servidor Local: Cortamos la ejecución temporal de php artisan serve [01:06] para configurar el proyecto corriendo nativamente en el directorio raíz de WampServer. Accedimos al panel a través de http://localhost/turnos_laborales/public/, optimizando el flujo para desarrollo real [01:14, 01:22].
• 📐 Modelado Visual con DBML: Creamos el archivo diagrama.dbml dentro de la carpeta public/ para estructurar y documentar el esquema lógico utilizando una extensión especializada de Visual Studio Code [02:40, 03:13]. El core aprovecha el ecosistema ya integrado de la plantilla Hope UI (que incluye la gestión de usuarios users, roles y permisos de Spatie) [04:40, 16:24] como base para las nuevas entidades.
• 🗄️ Creación de Modelos y Tablas en Laravel:
  • employees (Empleados): Creada con php artisan make:model Empleado -mcr [08:37]. Vincula una llave foránea condicional con users (corrigiendo la referencia de usuarios a users [11:22]) para permitir el login de personal [05:03]. Almacena datos como documento de identidad único (unique), tipo de documento, teléfono, dirección, profesión, género, avatar y estado (activo/inactivo) [05:23, 10:03].
  • ausencias (Ausencias / Licencias): Relacionada mediante empleado_id con borrado en cascada (onDelete('cascade')) [13:17]. Controla las fechas de inicio/fin, los tipos (vacación, médica, permiso, otro) y estados de aprobación (pendiente, aprobado, rechazado) [13:41, 13:57].
  • sucursals (Sucursales): Estructura modular plana con los campos únicos de nombre y dirección para soportar la rotación de locaciones físicas del personal (bancos, condominios, oficinas, etc.) [15:32, 15:40].
  • categories (Categorías): Almacena las áreas, módulos o sectores específicos del rubro laboral mediante una columna simple de nombre [16:10, 16:57].
  • turnos (Turnos): Enlazada con categoria_id en cascada [18:08]. Define los rangos horarios de trabajo que posteriormente se sincronizarán con los componentes dinámicos de FullCalendar [06:35, 18:15].
  • cronogramas (Cronogramas / Horarios): La tabla pivote central del negocio. Vincula de forma cruzada empleado_id, turno_id y sucursal_id [06:43, 19:52]. Para evitar colisiones y los choques de horarios solicitados por el cliente, se implementó una restricción de clave única compuesta (unique(['empleado_id', 'fecha'])), impidiendo duplicidad de asignaciones en un mismo día [20:11].
• 🧬 Compilación y Verificación del Esquema: Corrimos de forma controlada el comando php artisan migrate para inyectar los nuevos esquemas en caliente en la base de datos de MySQL [11:01, 14:14]. Pasamos exitosamente de las 12 tablas iniciales del boilerplate a un total de 18 tablas funcionales [20:34], validando la integridad de las relaciones foráneas directo en el diseñador visual de PHPMyAdmin [12:08, 20:41].

🗄️ Próximo paso

Con la base de datos de 18 tablas perfectamente estructurada, las restricciones de llaves foráneas activas y el control de claves compuestas listo para bloquear dobles asignaciones en el cronograma, el motor de datos está completado. En la próxima lección (Capítulo 4), comenzaremos con el desarrollo del frontend de administración adaptando las vistas y controladores para poblar dinámicamente nuestra primera entidad: el listado maestro de Sucursales. ¡Nos vemos en el próximo video! 🐾