The database consists of four tables: Game, Platform, GameCopy and RentalHistory.

Game table represents a game without reference to a specific Platform e.g. {Fifa, Advendure}
since a game can have versions, which run on different platforms. Platform table models a
platform e.g. Xbox.
GameCopy represents a real copy of a Game, hence it references both Game and Platform tables.
These three tables are populated from the Game_Info.txt file. RentalHistory table purpose is
self-explanatory and it is initialised from Rental_history.txt file. This file itself is
programmatically populated with data using a python function in database.py file.

Where applicable Auto-increment primary keys, foreign keys, indexes, default values and
unique keys have been properly used to tackle issues such as search performance,
maintainability, referential integrity and DB consistency. Example Title column in Game has
been designated as unique since no 2 games should have the same title.
Through this DB design, data redundancy has been eliminated and normalisation has been
carefully considered. Notice that dates are stored in the format ‘yyyy/MM/dd’ since it’s
a convenient pattern to compare 2 dates against each other.

Database.py (model layer) provides functionalities for interaction with DB:

•	initialise_database function which calls several sub-functions, generates the data for
	Rental_History.txt and subsequently populates all the tables in DB from 2 text files.
	As part of the import process 3 data cleaning mechanisms are implemented.
	A verbose log is provided when the initialisation process runs.

•	search_game searches for game title that contains (LIKE in SQL) the input string,
	it returns a list of Game objects.

•	Game renting is implemented through several functions which perform all the checks
	and validation such as integration with Subscription Manager, ensuring game is available
	for rent, etc.. before renting a game copy to a customer.

•	Return game implementation is straight-forward. 

•	get_popular_games, returns a tuple of 2 lists, for the 5 most rented games and genres
	since 1 year ago.

•	A Game class is added at the end, it models a complete representation of a Game Copy.

In controller layer:
 
•	gameInitialise, an initialisation module that calls init functionality in lower layer.

•	gameSearch searches for games with no more logic involved.

•	gameRent calls the relevant functions from database.py in a specific order to ensure renting
	is executed properly, in case of any issue or error a proper message is provided to the user.

•	Similarly, gameReturn executes specific functions in the model to check for Game Id existence
	and not already in store before proceeding in returning the Game Copy.

•	gameSelect.py which is concerned with recommending games titles/genres has 1 main function
	recommend_games, the algorithm accepts a proposed budget and after calling a specific function from
	the model layer it computes the no. of copies to purchase of the popular titles/genres according to
	each entry rent count to total count and its average purchase price.

Finally, menu.py i.e. the view, exposes the functionalities from the controller through 5 buttons
in the main menu. Upon clicking on one of the buttons, a related sub-menu appears which allows
for end-user interaction.