Tap and Park: A Parking App Data Model

Various apps promise to make your search for parking painless. Let’s examine this type of app using our data modeling glasses. What does the underlying model look like?

In an earlier article, we explained how a parking lot is structured and how a data model can be designed to manage one. In this article, we are examining the data model for a parking app. You know these apps: they list nearby parking options, tell you the prices, and let you book or reserve a space or buy a parking pass.

This application makes your search for parking relatively painless. I’d say that the most important factor in choosing a parking place is price. A five-minute walk that saves a few bucks is always worth it. That being said, let’s don our data modeling glasses and take a close look at the world of parking lot apps.

What Should We Know About Parking Lots and Parking Apps?

Parking apps are pretty simple: we can expect functions for tracking the availability and price of parking spaces in real time, booking said spaces, and paying the fees.

Aside from location, which is relatively easy for a data modeler to handle, the key driver for parking lots is price. The pricing strategy for parking spaces is quite straightforward, and certain methods or rules are practically universal:

• Parking lots often have different prices for different times. A day is commonly divided into three parts – morning (6:00 to 11:00 am), midday (11:00 am to 5:00 pm), and evening (5:00 to 10:00 pm).
• Evenings and mornings usually have higher prices, as more cars are likely to need a space during these hours.
• Pricing can also differ based on the days of a week. For example, a parking lot near a city center will charge more on the weekend (Saturday and Sunday) because that’s when more people visit.
• Most of the time, lots use their standard prices. However, there are days when they may charge more – e.g. parking lots near baseball stadiums may charge more when there is a game or event at the stadium.
• Parking lots near transportation hubs (airports, railway stations, and bus stands) may allow parking for a 24-hour day or a week. They will likely have a special rate for longer-term parking.
• Some parking lots issue monthly passes at a fixed cost. Monthly pass holders pay the fixed amount each month instead of paying a daily charge.

The Data Model

As you can see, there are three subject areas:

1. “Parking Lot”
2. “Customer”
3. “Parking Reservation”

Let’s take the most important subject area first – the one that handles parking lots and their pricing.

Parking Lot

This subject area revolves around the parking_lot table, which stores details about each parking lot in our system. This table is thoroughly explained in our earlier article about a parking lot management data model. However, we will reiterate a few important columns here:

• zip – A postal code; this plays a major role in the search function.
• is_slot_available – Updated by parking lot operators and signifies if space is currently available.
• is_reentry_allowed – Whether a customer can park again in the lot after they have left it. If re-entry is not allowed, the returning customer will have to buy another space.
• is_valet_parking_available – Valet parking costs extra, but people often prefer it – especially when they are on a date. 😉
• operational_in_night – Whether the parking lot is open at night. This information becomes very important when your car is parked near an airport and your flight gets in at midnight!
• minimum_hr_pay – The minimum fee to park your car in a lot. For example, some lots have a three-hour minimum, meaning that you pay for three hours even if you are only parked for 30 minutes.
• is_monthly_pass_allowed –Whether a lot offers monthly passes.

We’ve already discussed the factors that go into setting parking prices. Now let’s see how we’ll handle pricing in our model. We’ll use the parking_pricing table to keep a record of regular prices and the pricing_exception table to record any exceptions. Both tables have a similar structure, and the columns are self-explanatory. The only differences are:

1. The parking_pricing table has a column (day_of_week) that stores the day of week relevant to a price. The pricing_exception table has a calendar_date column that holds the actual date when the special price was applicable.
2. When the app is showing prices, the pricing_exception table takes precedence over the parking_pricing table. So if the regular rate for today is $5 an hour but there’s a special rate in effect for $7, the app will show $7 per hour.

The final table in this subject area is offers. It holds records of discount coupons and their associated details. We’ve explained the data model behind offers, deals, and discounts in an earlier article. This table is based on the same theory, and all the columns should be self-explanatory.

Customer

When we think of a parking app, we usually think of these three elements:

• Customers – This includes a unique customer ID and basic details about app users, like their name and phone number. Also, it would be good to have their billing address.
• Vehicles – One person can have multiple cars, so we should have the capability for a one-to-many relationship between an app user and their vehicles. Obviously, we’d need a way to ID vehicles, such as by their license number.
• Payment methods– Since this application allows customers to reserve a parking slot and pay for it, we need a way to store payment methods. Once again, there should be a way to have multiple payment methods per user.

This model has one table for each of these entities. The customer_id attribute is referenced in the vehicle and payment_method tables; it links users to vehicles and payment methods.

Parking Reservation

This subject area contains just two tables. Of the two, the “parking_one_time_reservation” table stores reservation details. Some of its columns are self-explanatory; the others are:

• start_timestamp – The date and time when the reservation period starts.
• pay_for_min_hr – Holds an ‘N’ if the reservation is for a specific number of hours (e.g. from 9 a.m. until noon). Otherwise, this attribute will have a ‘Y’.
• booking_for_hr – The number of hours of a reservation. This is a nullable field; it will have a value only when pay_for_min_hr is set to ‘N’. In the example above, it would be set to “3” for the three hours that elapse between 9 a.m. and noon.
• basic_parking_cost – The basic parking cost, in local currency.
• offer_code – A coupon code, if any apply. Since applying an offer code is optional and is subject to availability, this column is nullable.
• net_cost – The actual amount customers pay at checkout (when they leave the lot).
• is_paid – Whether parking charges have been paid. This becomes an important column when re-entry is allowed on the same parking slip. In such cases, payments are usually settled at the first checkout (i.e. the first time the car leaves the lot).

The parking_monthly_pass table records information about all monthly passes issued to customers through this application. Monthly passes can be purchased at any time, even for future dates. So we have two separate columns, purchase_date and start_date, that enable app users to buy passes that are valid in the future. The other columns are self-explanatory.

What Else Can We Add to the Parking App Data Model?

Modern parking lots are equipped with all kinds of technologies, like license plate readers, sensors, automated parking access control systems, and smart parking meters. These advanced systems make parking lots easier to run and easier for motorists to use.

What additional changes does this data model need to support fully-equipped parking lots? Please tell us your thoughts in the comments section.