Creación de un modelo de datos para viajes compartidos

Hoy en día, el uso compartido del automóvil es aceptado y promovido por personas de todo el mundo. Sin duda, reduce la huella de carbono personal y puede ser más rentable que alquilar o comprar un automóvil.

El uso compartido del automóvil también requiere mucho trabajo:un trabajo de organización que se puede realizar fácilmente con una base de datos bien diseñada. Este artículo explica un modelo de datos detallado que podría usar un sitio web de viajes compartidos.

Diseño de datos, conozca el uso compartido del automóvil

Entonces, necesitamos diseñar un modelo de datos para un sitio web de viajes compartidos (también conocido como carpooling).

Compartir coche es un poco diferente a alquilar un coche. En el uso compartido del automóvil, el automóvil es propiedad de una persona y ofrecen viajes a otros. Cualquier compañero de viaje paga el costo del viaje, incluido el combustible, los peajes, etc.

Requisitos del proyecto:

El sitio web debe permitir a los usuarios (también conocidos como miembros de viajes compartidos) para registrarse usando su nombre, número de teléfono, dirección de correo electrónico, número de licencia de conducir, etc.
Se debe permitir a los miembros establecer sus preferencias con respecto a viajes y compañeros de viaje.
Los miembros llamados propietarios de viajes pueden crear un viaje ingresando los detalles de su viaje (es decir, puntos de inicio y destino, hora de inicio, costos por pasajero, etc.)
Otros miembros pueden buscar viajes disponibles a una ciudad de destino .
Los miembros que buscan un viaje pueden comunicarse con el propietario del viaje y hacer una reserva para sus asientos.
El propietario del viaje debe poder aprobar o rechazar las solicitudes de reserva.
Según la acción realizada por el propietario del viaje en la solicitud de reserva, se debe actualizar el recuento de asientos disponibles.
El propietario del viaje también puede marcar ciudades en ruta, que son ciudades en el camino desde su punto de partida hasta su destino. Si lo desean, los propietarios de las atracciones también deberían poder acomodar personas para las ciudades en ruta.

Con estos parámetros en mente, identifiquemos las principales entidades y relaciones para nuestro modelo de datos de viajes compartidos.

Identificación de entidades y relaciones

Cuando veo los requisitos en su conjunto, puedo descifrar fácilmente las entidades principales. Ellos son:

miembros (incluidos los propietarios de ciclistas y compañeros de viaje )
coche
preferencias
paseo
ciudad
Solicitud de viaje

Miembro – Todo aquel que visite este sitio web tiene que registrarse antes de usarlo. En este proceso, deben proporcionar detalles como first_name , last_name , gender , email y contact number . Para los compañeros de viaje, estos artículos son suficientes. Los propietarios de las atracciones, que presumiblemente conducirán, deben completar algunos detalles adicionales como driving_license_number y driving_license_valid_from también debe incluirse. La información de la licencia les dice a los compañeros de viaje algo sobre la experiencia de conducción del propietario del viaje. Esto ayudará a los compañeros de viaje a seleccionar el mejor viaje disponible. Agregaré una tabla llamada member con todas las columnas requeridas.

Coche – El propietario del viaje debe agregar detalles de al menos un automóvil antes de crear un viaje. Así que vamos a crear otra tabla, llamada car , para almacenar esta información. Un miembro puede tener más de un automóvil. Un viaje puede depender de un par miembro-automóvil, por lo que necesitamos otra tabla para establecer esta relación. Llamaremos a esta tabla member_car . Haré referencia a la clave principal de esta tabla en mi ride tabla donde almacenaré los detalles del viaje. También agregaré una columna, a saber, comfort_level , que almacena el nivel de comodidad de un automóvil en una escala de 0 a 5. El sistema calcula automáticamente este nivel, en función de los otros detalles proporcionados por los miembros sobre el automóvil.

Preferencias – Las preferencias son importantes para todos. El sitio web permite a los miembros completar sus preferencias sobre el automóvil y sus compañeros de viaje. Estos detalles siguen siendo opcionales en el momento del registro, pero deben completarse antes de crear un viaje . Es probable que el propietario del viaje busque personas con preferencias similares para que todos viajen cómodamente. Las personas que buscan viajes hacen lo mismo.

Algunas preferencias básicas para viajar en automóvil son:

¿Está permitido fumar dentro del automóvil?
¿Se permiten mascotas?
¿Qué tan hablador es el dueño del viaje? ¿Qué nivel de charla es aceptable durante el viaje? (Las posibles respuestas aquí incluyen ninguna, cháchara ligera, gabfest.)
¿Qué tipo de música le gusta al propietario de la atracción?
¿Qué volumen de música permite el propietario del viaje?

Dado que estos detalles son opcionales durante el registro, crearé otra tabla llamada member_preference para almacenar estos detalles. Dos tablas adicionales almacenan posibles opciones de música (music_preference ) y conversación en el coche (chitchat_preference ).

Tengamos una relación de cero a uno entre el member y member_preference tablas, ya que los miembros pueden o no establecer sus preferencias en el sistema cuando se registran, y solo hay un registro de preferencias por miembro.

Ciudad – Una tabla maestra, city , es necesario para almacenar una lista de todas las ciudades servidas por el sitio web. Debe incluir la información relevante del estado y del país para cada ciudad.

Paseo – Un miembro puede crear un viaje completando en qué automóvil viaja; de qué ciudad parte; a qué ciudad se dirige; la fecha y hora del viaje; el número de asientos disponibles; y contribución per cápita. La contribución por persona es la cantidad que cada compañero de viaje tiene que pagar por los gastos del viaje. El propietario del viaje también puede mencionar cuánto equipaje espera de los compañeros de viaje para que todo quepa en el automóvil. Así que agregamos una columna, luggage_size_allowed , para este artículo. Los valores posibles para esta columna serían ligero, medio y pesado.

Solicitud de viaje – Los miembros pueden ver la lista de viajes disponibles de una ciudad a otra o solicitar un viaje específico. Definitivamente necesitamos una tabla para almacenar detalles sobre tales solicitudes. Una tabla llamada request se ajusta al propósito. La solicitud se ingresa inicialmente como una solicitud "enviada", y el propietario del viaje es la única persona que puede aprobarla o rechazarla. El número de asientos disponibles en la tabla de viajes se ajustará para cada aprobación y/o rechazo.

Ciudades en ruta – Compartir viaje no se trata solo de ir directamente desde el punto de partida hasta el destino. También se puede compartir un viaje con otros para las ciudades en ruta. Por ejemplo, si un hombre viaja de Chicago a Miami, puede acomodar a alguien que quiera ir de Chicago a Nashville. Nashville es una de las ciudades por las que pasará en su ruta, por lo que es una ciudad en ruta. Nuestro sistema debería permitir a los propietarios de viajes establecer ciudades en ruta según la ruta que van a seguir para llegar a su destino. Si los compañeros de viaje lo desean, pueden bajarse en cualquiera de las ciudades en ruta; sus gastos de viaje se prorratearán en consecuencia.

Crearemos otra tabla llamada enroute_city para este propósito. Los registros se agregarán cuando el propietario del viaje agregue ciudades en ruta a su viaje. Luego, los miembros pueden solicitar reservas para viajar a una de las ciudades en ruta. Por lo tanto, remito la clave principal de esta tabla a la request mesa.

El order_from_source columna en enroute_city La tabla indica el curso que el propietario del viaje va a seguir para el viaje.

Informes en el sitio web:

Hay varios informes (extractos de datos) que se pueden mostrar en este sitio web. Permítanme explicar algunos de ellos:

Viajes disponibles de una ciudad específica a otra – Este es uno de los informes que se extraerán con bastante frecuencia, ya que describe la esencia de este sitio web. La mayoría de los miembros accederán a este sitio web para buscar alternativas de viaje o viajes compartidos. Al extraer este informe, los miembros deben ingresar los nombres de las ciudades de origen y de destino. El SQL sigue:

Select m.first_name || ‘ ‘ || m.last_name as “Ride Owner”, c.name as “Car”, c.comfort_level as “Comfort Level”, mp.is_smoking_allowed, mp.is_pet_allowed, r.travel_start_time, r.contribution_per_head, seats_offered 
from ride r, member_car mc, car c, member m, member_preference mp
where r.member_car_id = mc.id and mc.member_id = u.id 
and mc.car_id = c.id and m.id = mp.member_id
and source_city_id = (select city_id from city where city_name = ‘CHICAGO’)
and destination_city_id = (select city_id from city where city_name = ‘MIAMI’)
and seats_offered > (select count(id) from request req, request_status reqs where req.request_status_id = reqs.id and upper(reqs.description) = ‘APPROVE’ and req.ride_id = r.id);

Lista de solicitudes enviadas/aprobadas para un viaje – Este informe se mostrará al propietario del viaje. Mostrará quién envió la solicitud de viaje, y el propietario puede tomar medidas en las solicitudes de este informe únicamente. El SQL para esto sigue:

select first_name || ‘ ‘ || last_name as “Submitter”,  req.created_on as “Submitted on”, rs.description as “Request Status” 
from member m, request req, request_status rs
where m.id = req.requester_id and rs.id = req.request_status_id
and req.ride_id = ;

Viajes anteriores y actuales ofrecidos – Estos informes se mostrarán a los propietarios de viajes en sus propios paneles. El siguiente SQL se puede usar para generar una lista de viajes que ofrece actualmente el propietario del viaje:

Select m.first_name || ‘ ‘ || m.last_name as “Ride Owner”, c.name as “Car”, c.comfort_level as “Comfort Level”, mp.is_smoking_allowed, mp.is_pet_allowed, r.travel_start_time, r.contribution_per_head, decode(seats_offered,0,’FULL’, seats_offered || ‘ seats available‘) from ride r, member_car mc, car c, member m, member_preference mp
where r.member_car_id = mc.id and mc.member_id = m.id 
and mc.car_id = c.id and u.id = mp.member_id
and r.travel_start_time >= sysdate
and m.id = ;

Y este SQL se puede usar para extraer una lista de viajes ofrecidos anteriormente:

Select m.first_name || ‘ ‘ || m.last_name as “Ride Owner”, c.name as “Car”, c.comfort_level as “Comfort Level”, mp.is_smoking_allowed, mp.is_pet_allowed, r.travel_start_time, r.contribution_per_head, decode(seats_offered,0,’FULL’, seats_offered || ‘ seats available‘) from ride r, member_car mc, car c, member m, member_preference mp
where r.member_car_id = mc.id and mc.member_id = m.id 
and mc.car_id = c.id and u.id = mp.member_id
and r.travel_start_time < sysdate
and m.id = ;

Lista de compañeros de viaje para un viaje – Este informe estará disponible para todos los compañeros de viaje, incluido el propietario del viaje. Todos ellos pueden generar una lista de todos los compañeros de viaje para cualquiera de sus viajes pasados o futuros.

select first_name || ‘ ‘ || last_name 
from member m, request req, request_status rs
where m.id = req.requester_id and rs.id = req.request_status_id
and rs.description = ‘APPROVED’
and req.ride_id = 
UNION
select first_name || ‘ ‘ || last_name 
from member m, member_car mc, ride r
where m.id = mc.member_id and mc.id = r.member_car_id 
and r.id = ;

El modelo de datos final

¿Qué pasa con las mejoras?

¿Podemos mejorar aún más este modelo? ¡Si podemos! Todavía hay algunas áreas que necesitan ser atendidas.

¿Qué pasa si uno quiere crear solicitudes de viaje recurrentes? Supongamos que un conductor viaja de una ciudad a otra todos los fines de semana y siempre está dispuesto a compartir este viaje. Una solicitud recurrente sería más conveniente.

¿Cómo puede una persona confiar en un tipo desconocido que ofrece un paseo? Debe haber alguna manera de ayudar a las personas a evaluar a otros antes de solicitar un viaje. Un mecanismo viable es publicar y compartir comentarios sobre los propietarios de viajes y los compañeros de viaje. Estos detalles seguramente ayudarán a otros a reservar un viaje con extraños con más confianza. Para que esto suceda, ¿qué cambios se requieren en nuestro modelo de datos?

Siéntase libre de compartir sus aportes sobre este modelo.