The Hamilton and Alexandra College · Year 12 · 2026

A data dictionary documents **every piece of data your software stores** — what each field is called, what type it is, how big it is, and what a valid value looks like. It is the design tool that turns "we'll store some student details" into a precise specification someone could actually build a database from.

---

You use a data dictionary for your **data sources** — the data your software *stores and reads back*. In a real system that is almost always a **database**; in your SAT it might be a database, a file, or a structured collection in code. **If your solution stores data, it needs a data dictionary.**

The picture below shows the idea. The top table is the actual **data**; the bottom table is the **data dictionary** that describes it — the name of each column, its data type, its size, and what it means.


The data dictionary is *metadata*: data about your data.

---

**🎯 Watch for:** how every column in the stored data gets one row in the dictionary, and how the dictionary fixes the type and size of each field *before* any data is entered.

{{Video|src=https://www.youtube.com/watch?v=kH0bcw9P2Lc}}

---

A strong data dictionary uses these columns:

| Heading | What it records |

|---|---|

| **Field name** | the variable / column name |

| **Data type** | Integer, Text, Boolean, Date/time, Float |

| **Data format** | the storage/display *pattern* (e.g. `999999`, `YYYY-MM-DD`) |

| **Size** | the maximum length |

| **Description** | what the field is for |

| **Example** | a sample valid value |

| **Validation** | the rule that keeps the value valid |

---

Here is a data dictionary for the **student records** a school timetable app might store:

| Field name | Data type | Data format | Size | Description | Example | Validation |

|---|---|---|---|---|---|---|

| `studentID` | Integer | `999999` | 6 | Unique ID for each student | 123456 | Required; exactly 6 digits |

| `firstName` | Text | `Xxxxxxxxxx` | 50 | Student's given name | Jane | Required; letters only |

| `lastName` | Text | `Xxxxxxxxxx` | 50 | Student's family name | Smith | Required; letters only |

| `DOB` | Date/time | `YYYY-MM-DD` | 8 | Date of birth | 2009-07-19 | Required; valid date; not in the future |

| `yearLevel` | Integer | `NN` | 2 | Current year level | 11 | Required; between 7 and 12 |

| `email` | Text | `xxx@xxx` | 100 | School email for notifications | jsmith@hac.vic.edu.au | Required; valid email format |

| `isBoarder` | Boolean | `true/false` | 1 | Whether the student boards | false | Required; true or false |

Notice that **Data type** and **Data format** are two different columns — that is the trap in the next section.

---

This is the single most common data-dictionary mistake.

**Data type** is the *kind* of data — Integer, Text, Boolean, Date/time, Float.

**Data format** is the *storage or display pattern* — the exact shape a valid value takes.

If you write `Integer` in the Format column, you have answered the wrong question. The format strings use a small set of symbols:

| Symbol | Meaning |

|---|---|

| `9` or `N` | one digit (0–9) |

| `X` | one uppercase letter |

| `x` | one lowercase letter |

| `YYYY` `MM` `DD` | four-digit year, two-digit month, two-digit day |

So `studentID` has type **Integer** but format `999999` ("exactly six digits"); `DOB` has type **Date/time** but format `YYYY-MM-DD` ("ISO date, not DD/MM/YYYY"). The type tells you *what kind*; the format tells you *what a valid value looks like*.

---

**🎯 Watch for:** how the same idea applies when the data lives inside a program (objects, structures), not just a database table.

{{Video|src=https://www.youtube.com/watch?v=MdMsjxT-EoU}}

---

The level descriptors build upward:

- **Level 3** — reference to **data types** (Integer, Text, Boolean, Date/time, Float).

- **Level 5** — data types **and data structures** (arrays, records — not just single variables).

- **Level 7** — data types, data structures **and data sources** (where does each value come from: user input, a database, a calculation?).

You cannot skip levels — a dictionary with no data structures cannot reach Level 5.

---

1. Build a data dictionary for the **student data your own system stores**. Use all seven headings above. Aim for at least five fields.

2. Then watch one student's attempt:

**🎯 Watch for:** which fields they included, and whether their Format column is really a format — or just a repeated data type.

{{Video|src=https://www.youtube.com/watch?v=xu0c1Dm9xWk}}

3. Write down: **what do you agree with, and what would you change?** Be specific — name the field and the column.

---

Write the *pattern* instead: `999999`, `NN`, `YYYY-MM-DD`. If you cannot write a pattern, you have probably copied the Type column.

Every field at Level 7 needs a source — "user input", "calculated from `DOB`", "retrieved from the student database". Blank does not score.

Size is a **number** — the maximum characters or digits the field can hold.

---

1. What are the three headings every data dictionary must include?

>| **Field name, data type, and description.** Size, format, example and validation make it stronger, but those three are the minimum that makes it a data dictionary.

2. `email` has data type **Text**. What might its *format* be, and why is that different information?

>| A format such as `xxx@xxx` (or `name@domain`) shows the *shape* a valid email takes — text before an `@`, a domain after it. The type "Text" only says it is characters; the format says how those characters must be arranged.

3. Your dictionary lists variables and arrays but no data sources. Which VCAA level can you reach, and which is out of reach?

>| You can reach **Level 5** (types and structures). **Level 7** needs data sources as well — add a source for every field to unlock it.

---

ScotRail's station announcements are stitched together from a **database of pre-recorded phrases**. This tool lets you assemble your own announcement from those stored fragments:

- [ScotRail — assemble a sentence](https://scotrail.datasette.io/scotrail/assemble_sentence?terms=i+am+sorry%2C+scotrail%2C+from%2C+bath+spa%2C+is+delayed%2C+due+to%2C+bomb)

Try assembling a sentence, then think about how it works: each phrase is one **record** in a data source. If you wrote the data dictionary for that data source, what fields would it need — the phrase text? an audio-file reference? a category? That is the same design tool you just practised, behind a real system.

---

- Data table / data-dictionary illustration — [mrAnmol](https://commons.wikimedia.org/wiki/User:MrAnmol), via Wikimedia Commons (CC0).

---

- [Object Descriptions and Class Diagrams](/sd/C05/Object%20Descriptions%20and%20Class%20Diagrams) — each class attribute is a data-dictionary field

- [IPO Charts — Process Means Steps](/sd/C05/IPO%20Charts%20-%20Process%20Means%20Steps)

- [VCAA Pseudocode — Not Python](/sd/C05/VCAA%20Pseudocode%20Not%20Python)

- [C05 Resources](/sd/Resources/C05-Resources)

← Back to [C05 Home](/sd/C05/C05-home) · [VCE Software Development Hub](/sd/VCE%20Software%20Development%20Hub)