Connected Car Data

Solution Guide

Continuing from the previous Connected Car Overview, what this document outlines is the data model used by the AWS variants of the solution. This should provide some insight into the functionality of this solution.

The model used for the variants that store data in AWS DynamoDB is shown in the diagram below. The key attributes are in the second box for each table or secondary index, separate from the non-key attributes in the box below that. The secondary indexes are shaded in gray on the right. (If you're new to DynamoDB, think of these secondary indexes as materialized views that you can use to query for items with different keys).

What follows are short summaries for the tables shown above. Note that in accordance with the nomenclature for DynamoDB, we’re using the word “item” in place of “record”:

Dealer & Timeslot Tables

The Dealer table represents car dealership locations. For each of these locations the Timeslot table is populated with items representing a "serviceDateHour" and the number of service bays available for these times. In this way, the Timeslot items describe the service hours of the associated dealership.

Customer, Vehicle & Registration Tables

The Customer and Vehicle items are populated independently, with each durably representing their respective real-world entities. The items in these two tables can be linked together in the Registration junction table, which also has a status flag to indicate whether the link is active or not. This way, even after a vehicle is no longer "registered" with a specific customer, the history of that linkage is preserved.

Appointment Table

This is another junction table which is designed to link an active vehicle registration to an available Timeslot item. By design, there can only be as many appointments for a Timeslot “serviceDateHour” value as there are service bays.

Event Table

This is the table that holds information about runtime errors and warnings submitted by a vehicle.

Note that to avoid hot partitions, the partition keys in the solution are either GUIDs or reasonably long string-formatted fields such as the customer username or vehicle vin. If you're not sure what "hot partitions" are, then see the data modeling section of the Learning AWS Serverless course.