QCE Digital Solutions Unit 2
QCE Digital Solutions Unit 2 — Application and data solutions — is the second Year 11 unit of the Queensland (QCAA) Digital Solutions syllabus: data-driven problems, data and programming techniques, and building a prototype data solution with a relational database and code.
This page lists the 76 free modules written for Unit 2: data-driven problems, input controls, output requirements and error tolerance; the benefits and social impacts of databases; the elements and principles of visual communication; data acquisition, completeness and consistency; insertion, update and deletion anomalies; filtering, transforming and aggregating streams of records; ALTER TABLE, CREATE VIEW, secondary keys and null values; normalising to 1NF, 2NF and 3NF; HAVING and sub-queries; and connecting Python to a SQLite database, running queries from code and parameterised INSERTs. Each module includes real practice questions and a full answer key.
Each topic has its own journey below, split into smaller journeys, and they reuse Cloodit's ACARA, VCE and pseudocode modules where the topic is the same, so each journey is a complete course. Teachers can assign a whole topic or one part of it, with progress tracking, class sprints and badges.
Add this whole curriculum to your class, or just the modules your unit needs — Cloodit tracks who's stuck automatically.
Data-Driven Problems and Solution Requirements (19 modules)
2
What a data-driven problem is
A problem whose solution depends on collecting, storing, processing and presenting data, such as keeping records or reporting results. Problems needing no data are not data-driven.
12
Problems caused by inconsistent data formats when inserting data
Data from different sources written in different ways (dates, text vs numbers, delimiters). It must be converted to one consistent format before it can be inserted into a data store.
23
Pattern recognition in a problem
Spotting similarities or repeated features in sub-problems so that one solution can be reused for similar tasks, such as repeated data entry steps or similar record structures.
70
User input controls for entering data
An on-screen element, such as a text box, drop-down list, option button or checkbox, that lets users enter data. Each suits a different kind of data.
71
Presenting data to the user
Showing data to users as a table, list, form, report or chart, chosen to suit the data and the user's task, and showing only the data they need.
74
Specifying output requirements
A statement of what information a solution must produce, in what format and medium, for which audience, and how often it is produced.
81
Error tolerance
An interface design quality where mistakes are prevented, reasonable input variations are accepted, and users can easily recover, such as with undo, confirmations and clear error messages.
113
Benefits of storing data in a database for organisations and governments
An organised store of data that organisations and governments can quickly search, share and update to give faster services, cut paper and errors, and inform decisions.
114
Social impacts of government databases
How large government databases affect people: they can improve access to services, but raise surveillance and trust concerns and risk excluding or profiling groups.
115
Risks of collecting and keeping too much data
The more data a system keeps, the more harm if it is stolen or leaked. Extra stored data makes identity theft and misuse of that data more likely and more damaging.
122
Visual communication element: line
A mark that connects points. It guides the eye, divides space or shows structure, and can be straight, curved, thick or thin, as in borders and dividers.
123
Visual communication element: shape
A flat, enclosed area with a clear edge, like a button or panel, that groups or highlights content. Shapes can be geometric (circles, squares) or organic (free-form).
125
Visual communication element: texture
The look or feel of a surface, shown with patterns or fills, used to add depth or tell areas apart. It can be real (felt by touch) or simulated (only looks textured on screen).
126
Visual communication element: tone
Tone is how light or dark an area is. Designers use it to create contrast, depth and emphasis, for example light text on a dark background, or a greyscale shade to show importance.
127
Visual communication element: form
The appearance of a three-dimensional object, or the illusion of depth on a flat screen, created using shading and perspective.
129
Visual communication element: proportion
The relationship in size between the parts of a design and the whole, such as how large one element is compared with the others around it.
130
Visual communication element: scale
The overall size of an element compared with a reference, such as other elements or the page. Enlarging or reducing it shows importance, so bigger elements draw the eye first.
133
Visual communication principle: proximity
A design principle: place related items close together and unrelated items further apart, so users see the groups clearly. Eg group name fields, then leave space before the next group.
134
Visual communication principle: harmony
Harmony is when the elements of a design, such as colours, shapes and style, work together so the visual feels unified and pleasing rather than clashing.
Just this content description: the Data-Driven Problems and Solution Requirements journey · Add Data-Driven Problems and Solution Requirements to a class →
Data and Programming Techniques (31 modules)
139
Wisdom: using information to decide
Wisdom is using information and experience to make good decisions. It is the top step of the DIKW pyramid, above data and information, and it needs context to work.
144
Programming requirements: SQL and algorithms
The list of SQL statements and algorithms a data-driven solution must include so it can carry out each of its functions, with each requirement linked to a task.
145
System requirements: platforms
A requirement stating the operating system, device type or environment (desktop, web, mobile, database software) that the solution must run on.
146
System requirements: hardware
The processing power, memory, storage and peripherals needed to run a solution and hold its data, such as disk space for a database or RAM for large files.
155
Data acquisition
Capturing data from a source and bringing it into a solution in a usable form: choose the source, capture it accurately, then check it on arrival.
179
Data completeness
Data is complete when every required value is present, with no missing fields or records. A presence check finds blank required fields.
180
Data consistency
The same fact has the same value and format everywhere it is stored, with no spelling variations or conflicting copies. Storing each fact in one place helps keep it consistent.
181
Insertion anomaly
A problem where a new fact, like a new course, cannot be stored until unrelated data, like a student, exists, forcing null values or dummy rows in a single table.
182
Update anomaly
A problem where a repeated fact is changed in one row but not its other copies, so the data disagrees. Caused by redundancy, and fixed by normalisation.
183
Deletion anomaly
Deleting a row also wipes out a separate fact stored only in that row, e.g. deleting the last student enrolled in a course also erases the course details.
185
Data security: integrity
Data stays accurate and unaltered unless an authorised person changes it, so a tampered bank balance breaks integrity.
186
Data security: availability
Authorised users can reach data and systems when they need them. Hardware failure and attacks can threaten it, so backups and protection keep a system running.
188
Streams of structured data
A sequence of structured records that arrives or is read one at a time, such as sensor readings, file lines or API results, and is processed as it flows.
192
Filtering a stream of records
Keep only the records in a stream that meet a condition and discard the rest, usually with an if inside a loop that adds matches to a result list.
193
Transforming a stream of records
map() applies a function to every record in a stream and gives back changed records, such as converting a type, trimming and changing the case of text, or computing a derived field.
195
Aggregating a stream of records
To aggregate is to combine many records into one summary value, such as a running total, a count of matching records, or an average worked out after the loop.
217
SQL ALTER TABLE
An SQL command that changes the structure of an existing table, such as adding a column with ADD, removing one with DROP COLUMN, or adding a FOREIGN KEY, without deleting the table.
218
SQL CREATE VIEW
Saves a SELECT query as a named virtual table. It shows chosen columns and rows, can hide others, and stores no copy of the data, so you query it like a table.
226
Secondary key
A non-primary field used to search or sort records, such as surname. Unlike a primary key, its values need not be unique, and it is often indexed to make searches faster.
227
Null values
A field with no value at all. It is not zero and not an empty string. Test for it with IS NULL, never = NULL. A primary key can never be NULL.
228
Views in a relational database
CREATE VIEW makes a view: a stored query shown as a virtual table. It shows chosen data without a second copy, and can restrict access or simplify joins.
234
Reading a relational schema
A relational schema lists each table and its fields, marks the primary key (underlined) and foreign keys (FK), and shows how tables link.
236
Unnormalised data and why normalise
Organising tables to reduce repeated data and prevent anomalies by splitting data into linked tables, using the normal forms 1NF to 3NF.
237
First normal form (1NF) (Data and Programming Techniques)
A table is in 1NF when every field holds one atomic value, there are no repeating groups or repeating columns, and each row is identified by a key.
238
Second normal form (2NF) (Data and Programming Techniques)
Second normal form: the table is in 1NF and every non-key field depends on the WHOLE primary key, so no field depends on only part of a composite key. Move partial fields to their own table.
239
Third normal form (3NF) (Data and Programming Techniques)
Third normal form: the table is in 2NF and no non-key field depends on another non-key field (no transitive dependency), e.g. suburb depends on postcode, so move it to its own table.
240
Normalising a table to 3NF step by step
Work through 1NF, 2NF, then 3NF, splitting data into new tables linked by foreign keys so no data is lost and anomalies are removed.
282
Pseudocode: validating a record before insertion
Only insert the record if every validation check left the valid flag true. If any check set valid to false, skip the bad record or report it instead of inserting it.
283
Pseudocode: processing a file of records for insertion
A loop that reads each line, splits it into fields, trims and validates them, then builds an INSERT statement for each good row and counts accepted and rejected rows.
284
Pseudocode: user interaction loop with a menu
A menu loop: repeat shows the menu, reads the choice, picks an action with if or else if, and stops on the exit choice. Any other value gets an invalid choice message.
285
Pseudocode: presenting query results
Loops through the returned records, printing each as a formatted line under a heading, then prints a summary such as a count or total. If there are none, print a no results message.
Just this content description: the Data and Programming Techniques journey · Add Data and Programming Techniques to a class →
Prototype Data Solutions (26 modules)
305
Insert, update and delete anomalies
A problem caused by repeated (redundant) data: adding, changing or deleting a record leaves data inconsistent or lost. The three types are insert, update and delete anomalies.
306
First normal form (1NF) (Prototype Data Solutions)
First normal form: every field holds one atomic value, with no repeating groups or multi-valued fields, and the table has a primary key to identify each row.
307
Second normal form (2NF) (Prototype Data Solutions)
Second normal form: a table is in 1NF and no non-key field depends on only part of a composite primary key. Removing partial dependencies means each field relies on the whole key.
308
Third normal form (3NF) (Prototype Data Solutions)
A table in 2NF where no non-key field depends on another non-key field (no transitive dependency). Every field depends on the key, the whole key and nothing but the key.
309
Evaluating a database against the normal forms
Test a table against 1NF, then 2NF, then 3NF, naming each dependency problem found (repeating group, partial or transitive) and backing it up with an example row.
310
Modifying a database to 3NF
Third normal form: move fields that depend on a non-key field into a new table with its own primary key, then link the tables with a foreign key. Check no data is lost.
321
SQL HAVING
Filters groups after GROUP BY using an aggregate condition, such as HAVING COUNT(*) > 3. WHERE filters rows before grouping.
330
Sub-query in a WHERE clause with IN
A sub-query is a SELECT inside brackets in a WHERE clause. It returns a list of values, and IN keeps only the rows whose value is in that list. NOT IN keeps the rows that are not in it.
331
Sub-query returning a single value
A sub-query in brackets returns one value, like the average. The outer WHERE compares each row's field to it. MIN or MAX work too.
336
CREATE VIEW
Saves a SELECT query under a name so you can query it like a table. A view stores the query, not a copy of the data, so it always shows current rows. Remove it with DROP VIEW.
337
Changing data across related tables
Add the parent row before its child rows, and delete child rows before their parent. Otherwise the foreign key rule is broken and SQL gives a foreign key error.
359
Connecting Python to a SQLite database
Opens a SQLite database file from Python and returns a connection. Call conn.cursor() on it to get a cursor for running SQL, and conn.close() when finished.
360
Running a SELECT from code and fetching rows
Returns every row from the SELECT that cursor.execute() ran, as a list of tuples. An empty result gives an empty list []. fetchone() returns just one row.
361
Displaying query results
Loops over each fetched row and prints its fields with an f-string, padded into columns so results are readable. Check for an empty list to show a no records message.
362
Running a join query from code
Runs a JOIN query stored in one string. Each row fetched back is a tuple holding fields from both tables, which you can unpack into variables.
363
Parameterised INSERT with commit
Adds a new record using ? placeholders filled safely from a tuple of values. The new row is only saved to the database file once conn.commit() is called.
364
Parameterised UPDATE and DELETE from code
A parameterised DELETE or UPDATE run from code: the ? in WHERE is filled by a value so only that record changes. cursor.rowcount of 0 means record not found.
365
A menu loop that controls user interaction
A menu loop repeats: show the menu, read a choice, call that option's function, and stop only when the user picks quit. Other input gets an invalid choice message.
373
Validating data before it is stored
Run the validation function first and only execute the INSERT or UPDATE when it returns True, so bad data is rejected before SQL runs and never reaches the database.
374
Handling database errors in code
Catches a failed database call, such as an IntegrityError from a broken constraint, so the program shows a friendly message instead of crashing. Call rollback() to undo.
375
Useability principles for an interface
Six criteria for judging an interface: accessibility, effectiveness, ease of learning, efficiency, error tolerance and engagement. A good interface does well on all of them.
389
Testing that stored data changed correctly
Run a SELECT before and after an INSERT, UPDATE or DELETE, then compare both results with the expected data and check that no other rows changed.
395
Reliability of a solution
A reliable solution gives correct results every time and keeps working when input is bad or an error occurs, so no data is lost.
403
Efficient SQL queries
An efficient query asks only for the fields and rows it needs: name fields instead of SELECT *, WHERE to filter early, and an index or key to find records fast.
407
Data quality: completeness
Data quality where every record has a value in each required field and no needed records are missing. In SQL, a missing value shows as NULL.
409
Checking data quality with SQL queries
Tests whether a field has no value. Use WHERE field IS NULL, often with COUNT(*), to find and count incomplete records when checking data quality.
Just this content description: the Prototype Data Solutions journey · Add Prototype Data Solutions to a class →
Printable QCE Digital Solutions Unit 2 Crosswords & Word Searches
Built from the key terms of each block of modules, every one with a full answer key. All free printables →
✎
Crossword: Data-Driven Problems and Solution Requirements (Modules 2–115)
10 clues · What a data-driven problem is, Problems caused by inconsistent data formats when inserting data, Pattern recognition in a problem, User input controls for entering data and more
✎
Crossword: Data-Driven Problems and Solution Requirements and Data and Programming Techniques (Modules 122–139)
10 clues · Visual communication element: line, Visual communication element: shape, Visual communication element: texture, Visual communication element: tone and more
✎
Crossword: Data and Programming Techniques (Modules 144–185)
10 clues · Programming requirements: SQL and algorithms, System requirements: platforms, System requirements: hardware, Data acquisition and more
✎
Crossword: Data and Programming Techniques (Modules 186–228)
10 clues · Data security: availability, Streams of structured data, Filtering a stream of records, Transforming a stream of records and more
✎
Crossword: Data and Programming Techniques (Modules 234–285)
10 clues · Reading a relational schema, Unnormalised data and why normalise, First normal form (1NF) (Data and Programming Techniques), Second normal form (2NF) (Data and Programming Techniques) and more
✎
Crossword: Prototype Data Solutions (Modules 305–336)
10 clues · Insert, update and delete anomalies, First normal form (1NF) (Prototype Data Solutions), Second normal form (2NF) (Prototype Data Solutions), Third normal form (3NF) (Prototype Data Solutions) and more
✎
Crossword: Prototype Data Solutions (Modules 337–409)
10 clues · Changing data across related tables, Connecting Python to a SQLite database, Running a SELECT from code and fetching rows, Displaying query results and more
🔎
Word Search: Data-Driven Problems and Solution Requirements and Data and Programming Techniques (Modules 2–139)
20 words to find · What a data-driven problem is, Problems caused by inconsistent data formats when inserting data, Pattern recognition in a problem, User input controls for entering data and more
🔎
Word Search: Data and Programming Techniques (Modules 144–228)
21 words to find · Programming requirements: SQL and algorithms, System requirements: platforms, System requirements: hardware, Data acquisition and more
🔎
Word Search: Data and Programming Techniques and Prototype Data Solutions (Modules 234–409)
22 words to find · Reading a relational schema, Unnormalised data and why normalise, First normal form (1NF) (Data and Programming Techniques), Second normal form (2NF) (Data and Programming Techniques) and more
Journeys using these modules
Frequently Asked Questions
Are these worksheets free?
Yes — every worksheet and its answer key is free to view, download, and print, with no account required to access any individual module.
Do I need an account?
No account is needed to view or print a worksheet. A free teacher account adds extras like assigning modules to a class and tracking progress automatically — it takes under three minutes to set up and doesn't need a credit card.
What year level is this for?
This curriculum is aligned to the Australian Curriculum (ACARA) and Victorian Curriculum, spanning roughly Years 3 to 10 — from first sequencing and variables through to object-oriented programming and advanced data structures. Start wherever matches your class's current level; each module builds on the last.
Can I print them?
Yes — every module has a one-click Print Worksheet button that generates a printable page with the practice questions and a full answer key.
Is this aligned to a curriculum?
Yes — the module sequence is mapped to the Australian Curriculum (ACARA) and Victorian Curriculum, and a class's progress is reported back against those curriculum bands (e.g. ACARA Years 5–6 sequencing and iteration, Years 7–8 functions and data structures), not just a generic difficulty scale.
Can students use this without a teacher?
Yes — students can start any module and practice directly, no class or account required. Joining a teacher's class with a class code adds progress tracking, class badges, and live Sprints, but isn't needed to work through the worksheets or modules solo.
Do I need to know QCE Digital Solutions Unit 2 myself to teach this?
No — every module comes with a full worked answer key, and Cloodit tracks who's stuck automatically, so you don't need to solve each exercise yourself before assigning it or be able to debug a student's work line by line.
Cloodit turns curriculum-aligned coding content into journeys students work through one biome at a time.
Students earn collectable badges
Over 100 of them, across seven natural biomes.
Study Buddy
Students build a real study resource
Turns their work into revision material ready for Flash Cards and Exam study.
Students lock in with Sprints
Live, competitive practice for the start of the lesson or a teacher-led lesson finisher.
Custom printable certificates
Honour your top performers, or encourage a student who's trying hard — ready to print in seconds.
For Teachers
Set this curriculum for your class and see who needs help, automatically.
Create a free teacher account →No credit card. No setup fee. Make a class and invite students in under three minutes.
For Students
Practice this topic interactively, track progress, and unlock badges.
Start Learning Free →