...
Delete Tab
Database Design
| draw.io Diagram | ||||||||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
|
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.
...
| 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.
...