Database Design
This is the database setup we will use for the RegterschotRacing API. A full description of every tables usage and datatypes can be found below. All green boxes will be made by Smalltalk in order to provide a sound foundation to build an API on. The red boxes could be implemented for future expansions, but they are out of our current scope. These have been placed here as an example to provide future developers with a stepping stone.
Database Glossary
Tablenames and formats are written in italic; Columns that contain the primary key are underlined.
| Table | Column | Datatype | Null / Not Null | Comments |
|---|---|---|---|---|
| Graph | This table contains all data that is required to show a graph. It contains the sensor it is displaying the data for, and the type of graph it is. | |||
| GraphID | int | Not null | This is the unique identifier of the graph. | |
| SensorID | int | Not null | The unique identifier of the sensor that the graph is displaying the data of. | |
| Race | This table contains all information relevant to a race. | |||
| RaceID | int | Not null | The unique identifier of the race. | |
| NumberOfLaps | int | Not null | The number of rounds that the race possesses. | |
| RaceName | varchar(255) | Not null | The name of the race. | |
| Date | DATETIME | Not null | The date of the start of the race. | |
| Sensor | This table functions as collection of all sensors. | |||
| SensorID | int | Not null | The unique identifier of the sensor. | |
| SensorName | varchar(255) | Not null | The name of the sensor. | |
| Type | varchar(255) | Not null | The type of graph, can be anything from the following:
| |
Tab | This table contains all information that is relevant to a Tab. | |||
| TabID | int | Not null | The unique identifier of the tab. | |
| TabName | varchar(255) | Not null | The name of the tab. The name is set when creating a new tab in the frontend web-application. | |
| RaceID | int | Not null | The unique identifier of the race that the tab belongs to. | |
| UserID | int | Not null | The unique identifier of the user that the tab belongs to. | |
| User | This table handles all user data and other data relevant to have users that can interact with the application. | |||
| UserID | int | Not null | The unique identifier of the user. | |
| Username | varchar(255) | Not null | The unique name of a user that will be on display in the frontend web-application. | |
| Password | varchar(255) | Not null | The hashed password of the user that is needed when logging in into the web-application. | |
Design decisions related to the database
Decision 1 | Description |
|---|---|
Problem/Issue | Throwing all of the different sensors and their data into one big table will quickly create a very clumped and hard-to-read table. |
| Decision | Create a different table for every sensor and add a new table that contains all sensor IDs. |
| Alternatives | - |
| Arguments | By dividing data over multiple tables, query time can be shortened significantly and keeps all of our tables in line with the normalization principle. |
| Decision 2 | Description |
|---|---|
| Problem/issue | A driver is only driving a couple of rounds in a race, which will create quite a confusing table if thrown into a single race tables. |
| Decision | Divide the different datatypes into multiple tables: a rounds table, a race table and a driver table. Create a linking table that links all of these three tables together. |
| Alternatives | - |
| Arguments | By dividing the table into a multitude of different tables, there's three distinct tables that are in line with the normalization principle. |
| Decision 3 | Description |
|---|---|
| Problem/issue | When adding a new graph to a tab the system must know what type of graph must be drawn for that sensor. |
| Decision | We decided to add the graph type to the sensor in the sensor table. |
| Alternatives |
|
| Arguments | Currently every sensor will have one specific type of graph. Later this could be changed to a user having to make a choice. Using the code we have currently and using this database design this change has less impact compared to the alternative. Beisdes the change having less of an impact we can also make the adding process smoother since a user wouldn't have to choose from all the possible graphs but only from the graphs that make sense for this sensor. Lastly we are able to make some query's faster and more compact this way. |
Security decisions
Regterschot indicated we do not have to worry too much about security yet, as they want to have a functional web application first. Therefore we are only implementing security measures for very high security risk scenarios.. Because of this we have chosen to hash the password, we do this because we are legally obliged tot do. In addition to this, we have chosen to use a Json Web Token. We do this to ensure that unwanted people can not make calls to the API and only retrieve the data through the Web application.