This is the first update to my Alternative Formula E Points Format project. So far I have made the tables and have populated them with records. Due to how MongoDB operates, there are some differences between the initial design of the database and its implementation. This will be explained the Changes and Clarifications section.
All files and documents are found in the GitHub repository: https://github.com/CulverT01/altfepointsformat
Please note that I have removed the username and password for the database from the admin program in the interest of security.

Updates

The tables (which MongoDB refers to as collections will be for the rest of this post and future ones) for Drivers, Teams, and Manufacturers have been created and populated with records (which MongoDB refers to as documents will be for the rest of this post and future ones).
The Manufacturers Collection in shown below as it appears in MongoDB Atlas (the cloud service in which the database is stored in).

The collection and documents were created using the afepf_admin_program Python file, which will be updated to allow other CRUD methods to be implemented. The 'add' option requires users to enter details regarding a either a team, or a driver or a manufacturer and those details are stored into a dictionary that is then inserted into the appropriate collection as document, as a JSON document and a Python dictionary are same in appearance. The program loops, providing the user has more drivers, or teams, or manufacturers they wish to enter and ends if they don't.
Below is the code from afepf_admin_program.py which allows teams to be added to the Teams collection.

Changes and Clarifications

MongoDB uses the document model to store and organise data, which is schema flexible, and allows for sub-documents within documents. Sub-documents means that I can store similar attributes, for example, the Customer Points and the Customer Trophy Position attributes from the Customer Driver table, together alongside related attributes of similar tables, such as the Driver table. This means that: the Customer Driver table, NPJT Driver table, and Customer Team table, now move into both the Drivers collection and Teams collection respectively and the attribute list now looks similar to what the initial tables looked before 1st form normalisation.
Another advantage of the document model is that documents can hve different structures, thanks to its flexible schema. This means some documents can have certain attributes, while others don't and it not result in empty sets. The Design document will be updated to include the implemented design of the database.