F1 DATABASE
Modelled a relational database for the F1 championship
F1 Database is a relational database that models the Formula 1 World Championship, capturing teams, drivers, circuits, races, results, and end-of-season standings as one connected system. It was built to support realistic queries about performance, points, and championship rankings.
Timeline
One semester, Database course assessment.
Background
The project started from a real-world domain (formula1.com) and worked backward into a relational model, an ERD defining how teams, drivers, races, and results relate, then a working SQL layer with queries, constraints, and views on top.
The project moved from domain modelling into entity relationships, then into the SQL layer, queries, constraints, and views, that make the data usable.
Entity Relationship Design
I mapped the core entities, team, driver, circuit, race, result, and standing, into an ERD, defining how they connect. Each team has a name, principal, and country of origin. Each driver is contracted to exactly one team and carries personal details like nationality and date of birth. Each circuit is defined by its name, location, and country. Each race is a Grand Prix event held at a circuit on a specific date, and results record a driver's finishing position and points for that race. Standings then aggregate points and wins per driver across the season to produce the championship ranking.
Team and driver is a one-to-many relationship: one team can have many drivers, but each driver belongs to exactly one team. Driver and race is many-to-many, modelled through the result table, since one driver competes in many races, and one race features many drivers.
Querying the Data
I wrote a range of SQL queries to demonstrate the database in use, from simple filters to multi-table joins. This included natural joins and their cross-product equivalents to show a driver alongside their team, GROUP BY/HAVING queries to total points per team above a threshold, a subquery to find every Grand Prix where a British driver reached the podium, and a self-join to pair up teammates.
Constraints & Data Integrity
I added CHECK constraints to enforce data integrity at the table level, ensuring team names can't be blank, driver dates of birth are always in the past, finishing positions are positive, and points are never negative.
Referential Actions
I defined ON DELETE behaviour to control how related data responds to deletion. Driver and race use RESTRICT, so a team or circuit can't be deleted while drivers or races still reference it. Result and standing use CASCADE, so removing a race or driver automatically clears its associated results or standings.
Views
I created views to simplify common access patterns: UpcomingRace, which surfaces every Grand Prix still to come, and PodiumFinisher, which extracts every driver who finished in the top three for each race.
F1 Database gives a structured, query-ready model of an F1 season, with the relationships, constraints, and views needed to answer real questions about teams, drivers, and results.
Entity Relationship Diagram
A full ERD modelling team, driver, circuit, race, result, and standing, and how they connect.
One-to-Many & Many-to-Many Relationships
Clear modelling of team-to-driver (one-to-many) and driver-to-race (many-to-many) relationships, the structural backbone of the database.
SQL Query Set
A range of queries demonstrating simple filters, natural joins, GROUP BY/HAVING aggregation, subqueries, and self-joins.
Data Integrity Constraints
CHECK constraints across team, driver, and result tables to keep the data valid and meaningful.
Referential Action Rules
RESTRICT and CASCADE rules controlling how deletions propagate through the database.
Views
UpcomingRace and PodiumFinisher views, built to simplify common lookups for race fans or championship tracking.
Here, the outcomes of the project are highlighted, including the database's structure, query range, and built-in data integrity.
Fully Modelled Domain
The database captures the full structure of an F1 season, teams, drivers, circuits, races, results, and standings, as a connected relational system rather than flat, disconnected tables.
Demonstrated Query Range
The query set covers simple selection, joins (natural and cross-product equivalent), aggregation with HAVING, subqueries, and self-joins, showing the database can answer a wide range of real questions.
Built-In Data Integrity
CHECK constraints and referential actions (RESTRICT/CASCADE) ensure the database enforces its own rules, rather than relying on application code to catch bad data.
Built-In Data Integrity
F1 Database exists as a complete relational database design, ERD, relationship modelling, SQL queries, constraints, referential actions, and views, submitted as Assessment 5 for Database