Modelo de Base de Datos para el Sistema de Reservas de una Autoescuela. Parte 1

Necesito diseñar un modelo de datos para un sistema de reservas para una autoescuela. El área temática parece bastante sencilla, pero todavía hay complejidades involucradas. Debe realizar un seguimiento de todas las solicitudes de los clientes y realizar un seguimiento de los recursos (vehículo, tiempo e instructor) consumidos durante las lecciones.

Introducción

Me gusta usar un enfoque basado en el dominio para diseñar un modelo de datos. Me hace dejar de lado la obsesión por la tecnología y concentrarme principalmente en modelar el área temática que gira en torno a sus entidades asociadas y las relaciones entre ellas.

Requisitos en pocas palabras

Permítanme primero poner el requisito en un lenguaje sencillo primero.

Necesito un modelo de datos para una autoescuela para permitir clientes para hacer reservas para lecciones en línea. La autoescuela puede tener más de un instructor y más de un vehículo . El instructor se asigna a la lección en el momento de la reserva. El sistema debe permitir a los clientes cancelar la/s reserva/s en cualquier momento antes del día programado. El vehículo asignado a la lección también debe registrarse si la lección se lleva a cabo.

Entidades y relaciones involucradas

Cuando pienso en el tema, las entidades que me vienen primero a la mente son “Cliente” , “Instructor” , “Lección de manejo” , “Solicitud de reserva” y “Vehículo” . Permítanme comenzar con mi primera tabla para este modelo, y esa es customer . Es para almacenar datos maestros para los clientes. Probablemente necesitaría otra tabla para almacenar los detalles del Instructor, pero en lugar de crear una tabla con el nombre del instructor, crearé una tabla genérica llamada staff para los detalles del personal y mantenga "Instructor" como título de trabajo. Hará extensible mi modelo de datos para atender también a otras áreas de servicio, como el trabajo administrativo y legal, de una autoescuela.

Considero “curso de conducción” como uno de los servicios, creo otra tabla llamada service . Un servicio, “curso de conducción” en este caso, puede tener múltiples lecciones. Para manejar este requisito, ciertamente necesito otra tabla maestra, a saber, lesson y una tabla de relaciones, a saber, service_lesson , para administrar una relación de muchos a muchos entre estas dos entidades maestras, es decir, un servicio definitivamente puede tener múltiples lecciones, pero por otro lado, una lección también puede ser parte de más de un servicio.

Cuando uno envía una solicitud de reserva, se le pide que complete sus datos y preferencias preliminares, como qué tipo de servicio desea, la elección del vehículo y la fecha de inicio. Los detalles del cliente se almacenan en la tabla de clientes. Posteriormente, se crea una solicitud en la request tabla, y todas las preferencias se almacenan contra la solicitud en la misma tabla. Hay ciertos estados asociados con cada solicitud, como "enviar", "en proceso", "cancelar" y "completar". Crearé una tabla de apoyo llamada request_status .

En el momento de la presentación de la solicitud, uno pone una preferencia de vehículo, es decir, tipo de vehículo. Sin embargo, el vehículo en realidad se asignaría a una lección cuando se lleve a cabo. Por lo tanto, mantengo vehicle_type_id como una de las columnas en request mesa por ahora.

Cuando se procesa una solicitud, se realizan reservas para cada lección de la solicitud de servicio. Además, los instructores y los vehículos se asignan a cada lección según la disponibilidad de los instructores y las preferencias de vehículos de los clientes. Las lecciones están programadas para fechas futuras con el estado "Abierto". Todos estos detalles se capturan en otra tabla de transacciones llamada reservation . He resaltado todas las tablas de transacciones con un color diferente al de todas las tablas maestras.

Una tabla maestra, reservation_status , se crea para almacenar todos los valores posibles para los estados de reserva como "abierto", "en proceso", "cancelar" y "completado".

Este modelo permite que un cliente cancele una lección individual, así como la solicitud de servicio en su totalidad. Si el cliente cancela la solicitud de servicio, todas las lecciones restantes, que están programadas para el cliente, se cancelan en la tabla de reservas.

Consulte el modelo de datos creado por mí usando Vertabelo para obtener detalles a nivel de columna de todas estas tablas. Algunos puntos relacionados con la creación de columnas:

• Una columna de bandera llamada is_active se agrega a todas las tablas maestras para permitir la eliminación temporal de registros. Entonces, por ejemplo, si algún instructor abandona la escuela, cambiaremos la bandera a "N" para desactivar su registro.
• Ciertas columnas como created_date , created_by , last_modified_date y last_modified_by se agregan en todas las tablas de transacciones para habilitar un seguimiento de auditoría para los cambios en los registros. Las tablas de transacciones están resaltadas en azul en el modelo de datos creado en Vertabelo.
• Quizás se pregunte cuál es el address_id columna en el staff la mesa es para. He puesto esta columna a propósito en el staff table para que pueda extender mi modelo de datos para admitir un proceso automatizado para asignar un instructor a una solicitud en función de su ubicación. Por ejemplo, supongamos que en la ciudad de Nueva York llega una solicitud de White Plains. Mi sistema primero debe buscar un instructor disponible en la misma zona o en la más cercana. Mi sistema nunca debe asignar un instructor que se quede en Manhattan, que está a casi 50 millas de distancia del lugar del solicitante.

Características destacadas de este modelo

• Este modelo permite a los clientes realizar solicitudes de reserva según sus preferencias de fecha de inicio y vehículo.
• Les permite cancelar una o más lecciones de su curso, o todo el curso en sí.
• Este modelo captura los detalles del instructor y del vehículo para cada lección.
• Este modelo es extensible para manejar todos los servicios posibles proporcionados por una autoescuela.
• Nos permite diseñar cursos de capacitación y planificar lecciones de manera efectiva.

Modelo de base de datos

Aquí está el diseño de la base de datos para nuestro sistema de reservas. El modelo se creó en Vertabelo para la base de datos Oracle, pero el mismo diseño se puede implementar para otros motores de base de datos sin cambios significativos.

Conclusión

Hay ciertas áreas temáticas que no cubrimos en este artículo, como:

• ¿Podemos crear un enfoque automatizado para asignar vehículos e instructores a las lecciones?
• ¿Qué hay de facturar a los clientes? ¿Qué pasa si un cliente no quiere pagar el curso completo sino un par de lecciones? ¿Podemos hacer que estas lecciones estén disponibles para él?

¿Nuestro modelo existente es compatible con tales características? La respuesta es no. Probablemente cubriré estas áreas temáticas en mi próximo artículo.