Skip to content

Data structure diagrams

Design question 3: How is data organised and stored?

Arrays, linked lists, queues, stacks, sets, maps, trees and graphs.

What it explains and when it is useful

Data structure diagrams show how data is organised in memory while the program runs, and which operations you use on it. Draw the structures that matter to your algorithms, with real example data.

When to use it: Whenever an algorithm in Criterion C or D depends on a data structure: a queue for fairness, a 2D array for a grid, a graph for connections, a dictionary for fast lookup.

Worked example

Illustrative: PracticePal is a fictional project used throughout this guide.

Each example uses PracticePal data. Where PracticePal itself does not need a structure, the example is labelled as an alternative.

One-dimensional array

One-dimensional array rooms holding six room codes at indexes 0 to 5; rooms[4] is "P5"rooms"P1"0"P2"1"P3"2"P4"3"P5"4"P6"5indexrooms[4] → "P5" (fixed size, O(1) access by index)
Room codes in a fixed-size array; access by index.

Scroll sideways to see the whole diagram.

Two-dimensional array

Two-dimensional array grid[day][slot] for room P5: rows are days 0 to 4, columns are time slots 0 to 6; each cell holds a student id, B for blocked, or is empty; grid[3][1] holds 440grid[day][slot] for room P5, week of 2 Nov012:00112:30213:00313:30416:00516:30617:00Mon0381381BBTue1102440Wed2215Thu3440381Fri4BBBBBBBgrid[3][1] = "440" (Thu 12:30) · a whole row grid[4] is Friday · B = blocked by the head of music
The week grid for one room as grid[day][slot]: the structure behind the week view (SC2).

Scroll sideways to see the whole diagram.

Linked list

Alternative. PracticePal keeps bookings in the database; a linked list would suit an in-memory list that changes often in the middle.

Singly linked list of P5's bookings on Tuesday in start-time order: 12:30, 16:00, 17:00; the last node's next pointer is null12:30 u38116:00 u44017:00 u215first
One room's bookings for a day, in start-time order.

Scroll sideways to see the whole diagram.

Queue (FIFO)

Queue (first in, first out) of students waiting for room P5 on Tuesday at 12:30: u102 is at the front and is offered the slot first; new students join at the rearu102u440u215u093frontreardequeue()offer slotenqueue(u377)joins the listPython: collections.deque · Java: ArrayDeque / LinkedList as Queue · SQL: ORDER BY joined_at
A slot's waiting list: first to join is first offered (SC7).

Scroll sideways to see the whole diagram.

Stack (LIFO)

Alternative. An undo feature for the head of music's block editor.

Stack (last in, first out) of the head of music's recent changes in the room-block editor; undo pops the most recent change from the topblock P3 9–13 Novunblock P1 2 Novblock P5 4 Nov 12:00–14:00top →push(change)pop()= undoPython: list with append() / pop() · Java: ArrayDeque push() / pop()
Undo stack: the most recent change is undone first.

Scroll sideways to see the whole diagram.

Set

Two sets of student ids: students with a booking this week and students on a waiting list; the intersection (shaded) holds u381, who is in bothbooked this weekwaitingu102u215u381u440u093
Set operations on student ids: the intersection finds students who are booked and also waiting.

Scroll sideways to see the whole diagram.

Dictionary / map

Dictionary (map) neighbours from a room code to the set of rooms next to itneighbourskeyvalue"P1"{P2}"P2"{P1, P3}"P4"{P3, P5}"P5"{P4, P6}"P6"{P5}
neighbours: room code → set of rooms sharing a wall (used in Criterion D, Feature 2).

Scroll sideways to see the whole diagram.

Tree (binary search tree)

Alternative. PracticePal uses an indexed database column instead; a BST is the in-memory equivalent for fast ordered search.

Binary search tree of Tuesday's booking start times (24-hour clock) inserted in the order 1230, 900, 1600, 800, 1030, 1330, 1700: smaller times go left, larger go right80090010301230133016001700
Start times in a binary search tree.

Scroll sideways to see the whole diagram.

Graph

Undirected graph of the practice rooms: an edge joins two rooms that share a wall; P5 and P6 (shaded) allow loud instruments, so a loud booking in P5 is checked against P4 and P6P1P2P3P4P5P6highlighted edges:neighbours checkedfor a loud booking in P5Corridor layout: P1–P3 on one side, P4–P6 opposite; only rooms sharing a wall are joined.
Rooms as an undirected graph; edges are shared walls (SC6).

Scroll sideways to see the whole diagram.

Notation and legend

Symbol or partMeaning
Array cells with indexesFixed positions, direct access by index
Box-and-pointer nodesLinked list: data + next pointer; slash = null
front / rearQueue ends: dequeue at the front, enqueue at the rear
topStack: push and pop at the top only
CirclesSets (Venn) or graph vertices
key → valueDictionary entries
ShadingThe element an operation is about

Design decisions it communicates

A diagram earns marks when you explain the decisions it shows. In PracticePal's documentation these would each be one sentence:

  • A queue, not a list sorted by name, because fairness means first come, first served.
  • A dictionary of sets for neighbours, because membership tests are fast and the data is naturally “room → rooms”.
  • A 2D array for the grid because the view is literally days × slots and is filled cell by cell.

Common mistakes

  • Drawing a structure your code does not use.
  • No example data, so the diagram explains nothing.
  • Not saying which operations you use (enqueue, push, lookup) and why that structure suits them.

Checklist for your own version

Ticks are saved in this browser only, so you can use the list while you draft.