sql >> Base de Datos >  >> RDS >> Database

Tap and Park:un modelo de datos de la aplicación de estacionamiento

Varias aplicaciones prometen hacer que su búsqueda de estacionamiento sea sencilla. Examinemos este tipo de aplicación usando nuestras gafas de modelado de datos. ¿Cómo es el modelo subyacente?

En un artículo anterior, explicamos cómo se estructura un estacionamiento y cómo se puede diseñar un modelo de datos para administrarlo. En este artículo, estamos examinando el modelo de datos para una aplicación de estacionamiento. Conoce estas aplicaciones:enumeran las opciones de estacionamiento cercanas, le informan los precios y le permiten reservar o reservar un espacio o comprar un pase de estacionamiento.

Esta aplicación hace que su búsqueda de estacionamiento sea relativamente sencilla. Yo diría que el factor más importante a la hora de elegir un lugar de estacionamiento es el precio. Una caminata de cinco minutos que ahorra unos cuantos dólares siempre vale la pena. Dicho esto, pongámonos nuestras gafas de modelado de datos y echemos un vistazo de cerca al mundo de las aplicaciones de estacionamiento.

¿Qué debemos saber sobre los estacionamientos y las aplicaciones de estacionamiento?

Las aplicaciones de estacionamiento son bastante simples:podemos esperar funciones para rastrear la disponibilidad y el precio de los espacios de estacionamiento en tiempo real, reservar dichos espacios y pagar las tarifas.

Además de la ubicación, que es relativamente fácil de manejar para un modelador de datos, el factor clave para los estacionamientos es el precio. La estrategia de tarificación de los espacios de estacionamiento es bastante sencilla y ciertos métodos o reglas son prácticamente universales:

  • Los estacionamientos a menudo tienen diferentes precios para diferentes horarios. Un día se suele dividir en tres partes:mañana (6:00 a. m. a 11:00 a. m.), mediodía (11:00 a. m. a 5:00 p. m.) y tarde (5:00 a. m. a 10:00 p. m.).
  • Las tardes y las mañanas suelen tener precios más altos, ya que es probable que más automóviles necesiten un espacio durante estas horas.
  • Los precios también pueden diferir según los días de la semana. Por ejemplo, un estacionamiento cerca del centro de una ciudad cobrará más el fin de semana (sábado y domingo) porque es cuando más personas lo visitan.
  • La mayoría de las veces, los lotes usan sus precios estándar. Sin embargo, hay días en los que pueden cobrar más, p. los estacionamientos cerca de los estadios de béisbol pueden cobrar más cuando hay un juego o evento en el estadio.
  • Los estacionamientos cerca de los centros de transporte (aeropuertos, estaciones de tren y paradas de autobús) pueden permitir el estacionamiento durante las 24 horas del día o la semana. Es probable que tengan una tarifa especial para estacionamiento a largo plazo.
  • Algunos estacionamientos emiten pases mensuales a un costo fijo. Los titulares de pases mensuales pagan la cantidad fija cada mes en lugar de pagar un cargo diario.

El modelo de datos




Como puede ver, hay tres áreas temáticas:

  1. “Estacionamiento”
  2. “Cliente”
  3. “Reserva de estacionamiento”

Tomemos primero el área temática más importante:la que se ocupa de los estacionamientos y sus precios.

Estacionamiento

Esta área temática gira en torno al parking_lot tabla, que almacena detalles sobre cada estacionamiento en nuestro sistema. Esta tabla se explica detalladamente en nuestro artículo anterior sobre un modelo de datos de gestión de estacionamientos. Sin embargo, reiteraremos algunas columnas importantes aquí:

  • zip – Un código postal; esto juega un papel importante en la función de búsqueda.
  • is_slot_available – Actualizado por los operadores de estacionamientos e indica si hay espacio disponible actualmente.
  • is_reentry_allowed – Si un cliente puede volver a aparcar en el aparcamiento después de haberlo dejado. Si no se permite el reingreso, el cliente que regresa tendrá que comprar otro espacio.
  • is_valet_parking_available – El servicio de aparcacoches cuesta más, pero la gente suele preferirlo, especialmente cuando están en una cita. 😉
  • operational_in_night – Si el estacionamiento está abierto por la noche. ¡Esta información se vuelve muy importante cuando su automóvil está estacionado cerca de un aeropuerto y su vuelo llega a medianoche!
  • minimum_hr_pay – La tarifa mínima para estacionar su automóvil en un lote. Por ejemplo, algunos estacionamientos tienen un mínimo de tres horas, lo que significa que usted paga por tres horas incluso si solo está estacionado durante 30 minutos.
  • is_monthly_pass_allowed –Si muchos ofrecen pases mensuales.

Ya hemos discutido los factores que intervienen en la fijación de precios de estacionamiento. Ahora veamos cómo manejaremos los precios en nuestro modelo. Usaremos el parking_pricing tabla para mantener un registro de precios regulares y la pricing_exception tabla para registrar cualquier excepción. Ambas tablas tienen una estructura similar y las columnas se explican por sí mismas. Las únicas diferencias son:

  1. El parking_pricing la tabla tiene una columna (day_of_week ) que almacena el día de la semana relevante para un precio. La pricing_exception la tabla tiene una calendar_date columna que contiene la fecha real en que se aplicó el precio especial.
  2. Cuando la aplicación muestra precios, la pricing_exception la tabla tiene prioridad sobre la tabla parking_pricing mesa. Entonces, si la tarifa regular para hoy es de $5 por hora pero hay una tarifa especial vigente de $7, la aplicación mostrará $7 por hora.

La tabla final en esta área temática es offers . Mantiene registros de cupones de descuento y sus detalles asociados. Hemos explicado el modelo de datos detrás de las ofertas, ofertas y descuentos en un artículo anterior. Esta tabla se basa en la misma teoría y todas las columnas deben explicarse por sí mismas.

Cliente

Cuando pensamos en una aplicación de aparcamiento, solemos pensar en estos tres elementos:

  • Clientes – Esto incluye una identificación de cliente única y detalles básicos sobre los usuarios de la aplicación, como su nombre y número de teléfono. Además, sería bueno tener su dirección de facturación.
  • Vehículos – Una persona puede tener varios autos, por lo que deberíamos tener la capacidad de una relación de uno a muchos entre un usuario de la aplicación y sus vehículos. Obviamente, necesitaríamos una forma de identificar los vehículos, como por su número de licencia.
  • Métodos de pago – Dado que esta aplicación permite a los clientes reservar una plaza de aparcamiento y pagarla, necesitamos una forma de almacenar los métodos de pago. Una vez más, debería haber una manera de tener múltiples métodos de pago por usuario.

Este modelo tiene una tabla para cada una de estas entidades. El customer_id se hace referencia al atributo en el vehicle y payment_method mesas; vincula a los usuarios con los vehículos y los métodos de pago.

Reserva de estacionamiento

Esta área temática contiene solo dos tablas. De los dos, la tabla "parking_one_time_reservation" almacena los detalles de la reserva. Algunas de sus columnas se explican por sí mismas; los otros son:

  • start_timestamp – La fecha y hora en que comienza el período de reserva.
  • pay_for_min_hr – Tiene una ‘N’ si la reserva es por un número de horas determinado (por ejemplo, de 9 a 12 h). De lo contrario, este atributo tendrá una 'Y'.
  • booking_for_hr – El número de horas de una reserva. Este es un campo anulable; tendrá un valor solo cuando pay_for_min_hr se establece en 'N'. En el ejemplo anterior, se establecería en "3" para las tres horas que transcurren entre las 9 a. m. y el mediodía.
  • basic_parking_cost – El costo básico de estacionamiento, en moneda local.
  • offer_code – Un código de cupón, si corresponde. Dado que la aplicación de un código de oferta es opcional y está sujeta a disponibilidad, esta columna se puede anular.
  • net_cost – El monto real que los clientes pagan al momento de pagar (cuando salen del lote).
  • is_paid – Si se han pagado los cargos de estacionamiento. Esto se convierte en una columna importante cuando se permite el reingreso en el mismo boleto de estacionamiento. En tales casos, los pagos generalmente se liquidan en la primera salida (es decir, la primera vez que el automóvil sale del lote).

El parking_monthly_pass tabla registra información sobre todos los pases mensuales emitidos a los clientes a través de esta aplicación. Los pases mensuales se pueden comprar en cualquier momento, incluso para fechas futuras. Entonces tenemos dos columnas separadas, purchase_date y start_date , que permiten a los usuarios de la aplicación comprar pases válidos en el futuro. Las otras columnas se explican por sí mismas.

¿Qué más podemos agregar al modelo de datos de la aplicación de estacionamiento?

Los estacionamientos modernos están equipados con todo tipo de tecnologías, como lectores de matrículas, sensores, sistemas automatizados de control de acceso a estacionamientos y parquímetros inteligentes. Estos sistemas avanzados hacen que los estacionamientos sean más fáciles de operar y más fáciles de usar para los automovilistas.

¿Qué cambios adicionales necesita este modelo de datos para admitir estacionamientos completamente equipados? Cuéntanos tu opinión en la sección de comentarios.