Graph Data Model for Timetabling

Having discussed advantages of graph databases for representing interconnected data, this section delves into the specifics of a proposed graph data model tailored for university timetabling.

An Iterative Approach

Due to flexibility, creating graph data models is an iterative process: design -> build -> test -> review -> revise -> …and repeat.

My first model was small in scope, incorporating minimal nodes and properties in an MVP¹ approach. Eventually, my expanded model was created in a cloud-instance of Neo4j Aura.

Core Nodes - Building Blocks

At its core, the timetable model revolves around four key entities represented as nodes:

Node	Property	Description	Data Type
Student	firstName	Legal first name	string
	lastName	Legal last name	string
	studentID	University identifier	integer
	splusID	Timetable URN	string
Lecturer	firstName	First name	string
	lastName	Last name	string
	staffID	University identifier	integer
	splusID	Timetable URN	string
Room	name	Room name	string
	splusID	Timetable URN	integer
Activity	name	Activity name	string
	description	Activity description	string
	startTime	Scheduled start time	datetime
	endTime	Scheduled end time	datetime
	date	Date of activity	date

Relationships - Connecting the Dots

The core nodes are interconnected through relationships that reflect the dynamics of a timetable:

(Student)-[IS_ALLOCATED_TO]->(Activity)
(Staff)-[TEACHES_ON]->(Activity)
(Activity)-[TAKES_PLACE_IN]->(Room)

MVP model

Neo4j Interface showing basic nodes and properties

Footnotes

Minimum Viable Product: “First, a definition: the minimum viable product is that version of a new product which allows a team to collect the maximum amount of validated learning about customers with the least effort or in other words building the most minimum version of their product that will still allow them to learn.” (Ries, 2024)↩︎