Un modelo de base de datos para un servicio de taxi

Llámelos taxis o taxis, estos convenientes viajes en alquiler han existido durante siglos. Hoy en día, es mucho más complicado operar un servicio de taxi. En este artículo, veremos un modelo de base de datos diseñado para satisfacer las necesidades de una empresa de taxis.

La historia de "llamar un taxi" comenzó en el Londres del siglo XVII. En la mayoría de los lugares, los taxis son más asequibles que nunca. También se están volviendo mucho más accesibles:podemos pedir un taxi por teléfono, a través de aplicaciones móviles o en la Web. O podemos usar las mismas técnicas que han estado funcionando durante cientos de años:formar fila en una estación de taxis o señalar uno en la calle.

El modelo de negocio de los taxis no está estancado de ninguna manera. Conceptos más nuevos como Uber y Lyft están ganando popularidad y sin duda tendrán un impacto en el futuro de los servicios de taxi. Por supuesto, todo esto complica la vida de quienes dirigen las empresas de taxis. Echemos un vistazo a las partes pertinentes de un modelo de datos que una empresa de taxis podría usar para mantenerse organizada.

¿Qué queremos lograr con este modelo de base de datos de cabina?

El modelo presentado en este artículo podrá:

• Crear horarios de conductores
• Haga un seguimiento de la disponibilidad del conductor en tiempo real
• Proporcionar a los conductores una lista de posibles viajes
• Permitir que los conductores seleccionen un viaje de la lista
• Calcule las horas de trabajo y los ingresos de los conductores
• Almacene varias estadísticas (por ejemplo, porcentaje de viajes que se cancelan, pagos por conductor por mes, etc.)

¿Qué debemos saber sobre las empresas de taxis?

Antes de diseñar un modelo de datos para una empresa de taxis, deberíamos poder responder las siguientes preguntas:

1. ¿Cuándo funcionan los controladores?
   En la mayoría de las empresas de taxis, los conductores tienen horarios predefinidos. Sabremos las horas exactas en que el conductor comienza y termina un turno. En algunos casos, las horas de inicio y finalización del turno no se definen de antemano. Por ejemplo, los miembros de una asociación de taxis pueden iniciar sesión y comenzar a trabajar cuando lo deseen. También pueden cerrar sesión y finalizar su turno cuando lo deseen. Nuestro modelo debería ser compatible con ambas opciones.

2. ¿Puede un conductor trabajar varios turnos el mismo día?
   Si el conductor es miembro de una asociación de taxis, es posible que pueda trabajar en la mañana, irse a casa y luego trabajar nuevamente esa misma noche. Sin embargo, en algunas áreas (como la ciudad de Nueva York) existen restricciones legales sobre la duración de los turnos y/o la cantidad de horas que los taxistas pueden trabajar cada día.

3. 3. ¿Quién inicia un viaje?
   En la mayoría de los casos, un cliente se comunicará con el centro de llamadas de taxis y el despachador ingresará su solicitud en el sistema. Otro escenario ocurre cuando el cliente solicita un taxi directamente (a través de una aplicación móvil, por ejemplo) y no hay ningún empleado del centro de llamadas involucrado en el proceso. Una tercera opción, que también pasa por alto el centro de llamadas, ocurre cuando un cliente toma un taxi en la estación o llama a uno en la calle.

El modelo de datos

Nuestro modelo tiene dos secciones principales y tres tablas sin clasificar. Echaremos un vistazo más de cerca a cada uno de ellos.

Sección 1:Taxis, conductores y turnos

Todo comienza con los taxis y los conductores:necesitamos autos en una empresa de taxis y necesitamos conductores. (En el futuro, probablemente necesitemos ajustar nuestro modelo para autos autónomos. Pero, por ahora, permanezcamos en el presente).

Comenzaremos nuestra exploración del modelo de datos con el driver mesa. En esta tabla, incluiremos los atributos habituales como nombre, apellido y fecha de nacimiento. También tendremos algunos atributos que son bastante específicos de este modelo:

• driving_licence_number – Este es un número de identificación o código alfanumérico que generalmente se encuentra en una licencia emitida por el gobierno. Dado que esta identificación es única en el mundo real, también será única en nuestra base de datos. (En algunas áreas, los taxistas deben tener un tipo especial de licencia de operación para trabajar; asumiremos que la tienen).
• expiry_date – Esta es la fecha en que una licencia de conducir ya no es legalmente válida. Tenga en cuenta que no almacenaremos el historial de licencias, por lo que simplemente sobrescribiremos driving_licence_number y expiry_date con nuevos datos según sea necesario. Si queremos almacenar historiales de licencias, necesitaríamos agregar otra tabla a nuestro modelo.
• working – Este es un valor booleano que simplemente se activa y desactiva cuando los conductores inician sesión en el sistema. Estableceremos este atributo de forma predeterminada en "Sí" (valor 1) y lo cambiaremos a "No" solo cuando el conductor ya no pueda iniciar sesión en el sistema.

Hay muchos otros detalles relacionados con los conductores que podríamos almacenar en la base de datos:nombres de usuario y contraseñas, la fecha en que cada conductor comenzó a trabajar y el tipo de empleo actual de cada conductor. No entraremos en estos detalles ahora porque no están relacionados específicamente con este modelo. Los clasificaría bajo administración de usuarios, que es lo mismo en la mayoría de los sistemas.

Ahora, pasemos al cab y el car_model mesas. Aquí es donde almacenaremos una lista de los automóviles que opera nuestra empresa. También almacenaremos ciertos detalles sobre cada vehículo. Los atributos más importantes en estas dos tablas son:

• model_description – Este es un atributo de texto que mantiene una descripción especificada por la empresa de un cierto tipo de automóvil. Por ejemplo, es posible que las compañías de taxis deseen almacenar la cantidad de pasajeros que puede transportar un automóvil, el espacio de la cajuela (maletero) y otros datos.
• license_plate – El número en una placa de matrícula (placa de matrícula del vehículo o placa de matrícula) define de manera única un automóvil, tanto para una empresa como para fines gubernamentales. Por supuesto, es posible que necesitemos cambiar la información de la matrícula si se compra o vende un automóvil. En esta tabla, solo almacenaremos los vehículos actuales de la empresa; si necesitamos mantener un historial, podemos agregar una tabla más a nuestro modelo.
• owner_id – Este atributo es una referencia al driver mesa. Es opcional porque solo lo usaremos cuando el conductor sea dueño de su cabina. (Este suele ser el caso en las asociaciones de taxis).
• active – Este es un valor booleano que indica si la empresa todavía usa un automóvil.

Finalmente, echemos un vistazo a la tabla más importante de esta sección:el shift mesa. La idea detrás de esta tabla es almacenar las horas de trabajo reales y los turnos de horario para automóviles y conductores. Cada turno tendrá al menos un taxi (cab_id ) y un controlador (driver_id ). Aparte de la clave principal, que es un número de identificación de turno único, estos son los únicos atributos obligatorios en esta tabla.

El shift_start_time y shift_end_time los atributos son los momentos reales en que comienza y finaliza un turno. A menudo, estos están predeterminados. En caso de que no haya horario, como en una asociación de taxis, estos tiempos serían los mismos que el login_time y logout_time atributos, respectivamente. La login_time y el logout_time son las horas reales en que los conductores inician sesión (a través de un dispositivo móvil en su automóvil o cualquier método que use la compañía de taxis). Cuando el conductor inicie sesión en el sistema, aparecerá una lista de viajes disponibles y el conductor elegirá uno. Por supuesto, el despachador también será notificado de que el conductor ahora está trabajando.

Sección 2:Paseos

Esta sección está compuesta por solo dos mesas, pero son el verdadero corazón de este modelo.

En el cab_ride tabla, almacenaremos un registro para cada recorrido potencial. Actualizaremos este registro de acuerdo con lo que suceda. Veamos una descripción general rápida de los atributos:

• shift_id – Esta es una referencia al shift mesa; nos proporciona información sobre el conductor y la cabina para un viaje determinado.
• ride_start_time y ride_end_time – Estos se actualizan cuando los conductores señalan que están ocupados actualmente (inicio del viaje) y, posteriormente, están disponibles nuevamente (fin del viaje).
• address_starting_point y address_destination – Estos son los lugares donde comienza y termina un viaje. El conductor probablemente buscará ambas ubicaciones para obtener la navegación en su tableta o GPS, por lo que es probable que actualicemos estos dos atributos.
• GPS_starting_point y GPS_destination – Estas son las coordenadas GPS de las ubicaciones de inicio y finalización descritas anteriormente. Estos valores son opcionales porque los actualizaremos solo cuando tengamos datos.
• canceled – Este es un valor simple de Sí/No que nos dice si un viaje ha sido cancelado. Ya tendremos un registro para ese viaje en nuestra tabla, así que podemos marcar el viaje como cancelado.
• payment_type_id y price – Estos proporcionan información sobre el monto pagado por un viaje y el método de pago utilizado por el cliente.

La mayoría de los atributos en el cab_ride la tabla puede contener un valor NULL. Hay dos razones para esto:

• Los viajes se cancelan, lo que significa que no se ingresarán datos en estos campos;
• Aunque finalmente tengamos todos los datos, no los tendremos todos cuando se inserte inicialmente el registro. Actualizaremos cada registro varias veces; como mínimo, lo actualizaremos cuando el viaje comience y finalice (o se cancele).

La segunda tabla de esta sección es el cab_ride_status mesa. Aquí, se agrega un registro para cada cambio relacionado con un solo viaje. Cuando el despachador ingrese un nuevo viaje en el sistema, agregará un registro al cab_ride pero también se creará un registro relacionado en el cab_ride_status tabla (junto con el estado correspondiente). Después de cada cambio relacionado con ese viaje, se agregará un registro más a esta tabla. Los atributos son:

• cab_ride_id y status_id – Estas son claves foráneas que están relacionadas con el atributo id en el ride tabla y el atributo id en el status tabla (que cubriremos a continuación). Ambos son obligatorios.
• status_time – Esto almacena la hora real cuando se insertó el registro. También es obligatorio.
• cc_agent_id y shift_id – Estas son referencias al empleado que insertó una actualización de estado. Puede ser un despachador o un conductor. Probablemente el despachador insertará el estado inicial y el conductor insertará todos los siguientes estados.
• status_details – Este es un atributo de texto que se puede utilizar para almacenar información adicional. Por ejemplo, un despachador podría usar este atributo para registrar instrucciones especiales sobre un viaje.

Tablas sin categorizar

Finalmente, repasemos rápidamente nuestras tablas sin clasificar.

El cc_agent La tabla contiene una lista de agentes o despachadores del centro de llamadas que pueden agregar nuevos registros en el cab_ride y cab_ride_status mesas.

En el status diccionario, almacenaremos una lista de todos los estados posibles que podríamos asignar a un viaje. Algunos valores incluyen “nuevo viaje” , “viaje asignado al conductor” , “viaje iniciado” , “viaje terminado” o “viaje cancelado” .

Payment_type es otra tabla de diccionario. Su contenido se utiliza para actualizar el payment_type_id atributo en el cab_ride mesa. Los valores comunes son “efectivo” y “tarjeta de crédito” .

¿Cómo mejoraría el modelo de datos de taxis?

El modelo de base de datos de cabina/taxi presentado en este artículo se centra solo en las funcionalidades más importantes. Hay numerosas mejoras que podríamos hacer. Las rutas son solo una que se me ocurre.

En el futuro, probablemente tendremos taxis sin conductor. En ese caso, eliminaríamos el controlador del modelo y lo sustituiríamos por cosas como tiempos de recarga y reparación.

Siéntete libre de comentar y agregar tus ideas.