Modelo de datos de transporte integrado

El transporte integrado es algo que a menudo escuchamos en Internet o en las noticias. Si bien no es algo nuevo, definitivamente es un proceso continuo, con cambios constantes que se implementan. Hoy, veremos un modelo de datos que podría manejar información de zona, pasajero y boleto.

Profundicemos en nuestro modelo de datos de transporte integrado, comenzando con la idea detrás de todo.

Idea

La integración del transporte es necesaria para maximizar su eficiencia y, para los clientes, su fácil uso. La integración está relacionada con los costos, pero también con el tiempo, la accesibilidad, la comodidad y la seguridad. Esto se aplica tanto a las ciudades más grandes como a las más pequeñas. La idea es utilizar la infraestructura de transporte existente y optimizarla para obtener mejores resultados; esto podría significar crear nuevos horarios, notificaciones, líneas o estaciones. Tal vez tener algo de información sea suficiente para que decidas esperar el autobús, alquilar una bicicleta o simplemente caminar hasta tu destino.

Expliquemos esto usando dos ejemplos.

En el caso de una gran ciudad, normalmente hay muchos medios de transporte diferentes disponibles:autobuses, taxis, tranvías, ferrocarriles, metro, etc. Esto puede llevar a muchas empresas privadas diferentes que brindan diversos servicios de transporte. La combinación de algunos de estos servicios definitivamente beneficiaría a los pasajeros y las empresas al reducir los costos, aumentar la eficiencia y brindar más servicio por boleto.

También hay beneficios similares para una ciudad más pequeña. Puede que no haya la misma cantidad de opciones para combinar, pero podrían organizarse para lograr la máxima eficiencia.

Este artículo se centrará principalmente en los sistemas integrados de emisión de billetes de transporte. No nos centraremos en todos los aspectos de la integración y los distintos tipos de transporte; eso sería demasiado complejo.

Con esto en mente, pasemos a nuestro modelo.

Modelo de datos

El modelo consta de dos áreas temáticas:

• Cities & companies
• Tickets

Los describiremos en el orden en que aparecen.

Ciudades y Empresas

En la primera área temática, almacenaremos todas las tablas necesarias para configurar las zonas de transporte en las ciudades.

El country la tabla contiene una lista de country_name ÚNICOS valores. Esta tabla se usa solo como referencia en la city mesa. Si bien podemos esperar que nuestro modelo cubra el transporte en un solo país, queremos tener la opción de incluir varios países. Para cada ciudad, almacenaremos la combinación ÚNICA city_name – country_id .

Las ciudades más pequeñas probablemente tendrán solo una zona, mientras que las ciudades más grandes tendrán múltiples zonas. Una lista de todas las zonas posibles se almacena en la zone mesa. Para cada zona, almacenaremos su zone_name y una referencia a la ciudad correspondiente. Este par forma la clave alternativa de esta tabla.

Podemos esperar que nuestro sistema almacene información sobre múltiples empresas de transporte. Las empresas emitirán sus propios billetes, pero también podrán emitir billetes conjuntamente con otras empresas. Para cada company , almacenaremos la combinación ÚNICA de company_name y el city_id donde esta ubicado. Cualquier información adicional necesaria se puede almacenar en los details textuales campo.

Lo último que necesitamos definir es la forma de transporte que ofrece cada empresa. Algunos valores esperados son "autobús", "tranvía", "metro" y "ferrocarril". Para cada valor en el transport_form tabla, almacenaremos el ÚNICO form_name.

• zone_id – Hace referencia a la zone tabla e indica el área donde esta empresa proporciona esta forma de transporte.
• company_id – Hace referencia a la company brindando este servicio en esta zona.
• transport_form_id – Hace referencia al transport_form tabla e indica el tipo de servicio proporcionado.
• date_from y date_to – El período durante el cual este servicio fue prestado por esta empresa. Tenga en cuenta que date_to puede contener un valor NULL si este servicio aún está disponible y/o no tiene una fecha de vencimiento prevista.
• details – Todos los demás detalles, en un formato de texto no estructurado.
• is_active – Si este servicio está activo (en curso) o no. Este es un simple interruptor de encendido/apagado que podemos usar en algunos casos en lugar del date_from – date_to intervalo de actividad de servicio. El mejor uso de este atributo sería simplificar las consultas, es decir, probar este valor en lugar de probar el intervalo de fechas y "jugar" con valores NULL.

Entradas

El área temática anterior era solo una preparación para lo principal:las entradas. Y eso es lo que cubrirá esta área temática.

Hemos definido empresas, zonas y formas de transporte, pero no tenemos ninguna provisión para pasajeros y boletos, el núcleo de este modelo. Asumiremos que un boleto podría usarse para una o más zonas cubiertas por una o más compañías.

Por lo tanto, primero debemos definir cada ticket_type . En esta tabla, enumeraremos todos los posibles tipos de boletos que venden las compañías en nuestra base de datos. Para cada tipo, almacenaremos los siguientes valores:

• type_name – Un nombre que denota ÚNICAMENTE este tipo.
• valid_from y valid_to – El período en el que este tipo de billete es (o era) válido. Ambos campos son anulables; un valor NULL significa que no hay una fecha de inicio (o finalización) para cuando esto era válido.
• details – Cualquier detalle necesario, en formato de texto no estructurado.
• recurring – Una bandera que indica si este tipo de boleto es recurrente (por ejemplo, anual, mensual) o no.
• interval_month – Si el tipo de boleto es recurrente, este atributo contendrá el intervalo, en meses, de cuándo se repite (por ejemplo, "1" para un boleto mensual, "12" para un boleto anual).

Ahora estamos listos para definir las zonas cubiertas por cada tipo de boleto. En el service_included tabla, almacenaremos solo el par ÚNICO ticket_type_id – service_available_id . Este último también indicará la compañía y la zona donde se puede utilizar este billete. Esta tabla nos permite definir múltiples zonas por ticket; las zonas pueden pertenecer a diferentes empresas. Dado que estos son tipos de boletos predefinidos, cada tipo de boleto tendrá las zonas definidas aquí (no para cada pasajero individual).

No almacenaremos demasiados detalles de los pasajeros en este modelo. Por cada passenger , almacenaremos solo su first_name , last_name , address , y una referencia a la ciudad donde viven. Todos estos datos se mostrarán en el ticket.

La última tabla en nuestro modelo es el ticket mesa. No nos centraremos aquí en los boletos de un solo uso; más bien, manejaremos la suscripción y los boletos prepagos. Estos boletos tendrán un saldo, una fecha de validez o ambos. Esto podría diferir significativamente, según la empresa y sus reglas. Si algunas empresas deciden emitir un billete, podemos respaldarlo en esta tabla:conoceremos todos los detalles importantes. Para cada boleto, almacenaremos:

• serial_number – Una designación ÚNICA para cada billete. Esto podría ser una combinación de números y letras.
• ticket_type_id – Hace referencia al tipo de ese ticket.
• passenger_id – Hace referencia al pasajero, en su caso, propietario de dicho billete. En caso de billete prepago, no puede haber propietario.
• valid_from y valid_to – Indica el período durante el cual este boleto es válido. Los valores NULL indican que no hay límite superior o inferior.
• credits – Los créditos (en valor numérico) actualmente disponibles en ese billete. Si es un boleto prepago, podemos suponer que los pasajeros comprarán créditos adicionales en el boleto. Si el boleto es válido durante todo el mes (o algún otro período de tiempo) sin límites de uso, este valor podría ser NULL.

Mejoras al Modelo Integrado de Datos de Transporte

Puede notar que este modelo se ha simplificado mucho. Esto se debe a que el transporte integrado es simplemente demasiado grande para cubrirlo en un solo artículo. Hay algunas cosas que creo que se podrían cambiar en este modelo:

• Las zonas están demasiado simplificadas; deberíamos poder definirlos de forma más dinámica.
• No cubrimos líneas (por ejemplo, líneas de autobús). ¿Qué pasa si van de una zona a otra, etc.?
• No almacenamos el historial de uso de boletos.
• No hay registro para empresas y pasajeros.

Todo esto llevaría al hecho de que careceríamos de datos importantes y no podríamos hacer ningún análisis más profundo. ¿Entonces, qué piensas? ¿Qué necesita este modelo? ¿Qué agregarías o quitarías? Comparte tus ideas en los comentarios.