IB Diploma Computer Science  |  First Exams 2027

A3.3
Database
Programming

Theme A  ·  Databases  ·  SL & HL (with HL extensions)

🧮

6 Assessment Statements

A3.3.1 – A3.3.6
A3.3.4–A3.3.6 are HL only

🎯

Command Terms

Outline · Construct · Explain · Describe

⏱

Teaching Hours

SL: 11 hours (A3 total)
HL: 18 hours (A3 total)

A3.3 — Unit Overview

What We'll Cover in A3.3

Guiding Question

How do we use SQL to retrieve, manipulate and protect the data inside a relational database?

Assessment Statements

A3.3.1 Outline data language types (DDL vs DML)
A3.3.2 Construct queries between two tables
A3.3.3 Explain how SQL updates data (INSERT/UPDATE/DELETE)
A3.3.4 HL Construct calculations using aggregate functions
A3.3.5 HL Describe different database views
A3.3.6 HL Describe how transactions maintain data integrity (ACID)

The SQL Journey

1️⃣

Languages of SQL

Recognise the four sub-languages: DDL, DML, DCL and TCL — each has its own purpose.

2️⃣

Reading Data

SELECT queries with filtering, joining, grouping and ordering across two or more tables.

3️⃣

Modifying Data

INSERT, UPDATE and DELETE — and how indexes affect performance when data changes.

4️⃣

Reporting HL

Aggregate functions and views support analytics, security and abstraction.

5️⃣

Protecting Integrity HL

Transactions and ACID guarantees keep data correct even when things go wrong.

A3.3.1 — Outline

Data Language Types within SQL

SQL is not one single language — it is a family of sub-languages, each with a distinct purpose. The IB syllabus focuses on DDL and DML, but you should also recognise DCL and TCL.

DDL

Data Definition Language

Defines and modifies the structure of the database — tables, columns, keys, indexes. It changes the schema, not the data.

Main Commands

CREATE TABLE Student ( StudentID INT PRIMARY KEY, Name VARCHAR(50), DOB DATE ); ALTER TABLE Student ADD Email VARCHAR(100); DROP TABLE Student;
  • CREATE — make a new table, view, index
  • ALTER — add, modify or remove columns
  • DROP — delete the entire object
  • TRUNCATE — empty a table but keep its structure
DML

Data Manipulation Language

Works with the data stored inside existing tables — retrieving, adding, modifying or removing rows. It does not change the schema.

Main Commands

SELECT Name FROM Student WHERE DOB > '2008-01-01'; INSERT INTO Student VALUES (101, 'Aisha', '2009-04-12'); UPDATE Student SET Email = 'a@x.com' WHERE StudentID = 101; DELETE FROM Student WHERE StudentID = 101;
  • SELECT — query data
  • INSERT — add new rows
  • UPDATE — modify existing rows
  • DELETE — remove rows
DCL

Data Control Language

Manages permissions — who can do what. Commands: GRANT, REVOKE.

TCL

Transaction Control Language

Manages transactions — covered in A3.3.6 (HL). Commands: BEGIN TRANSACTION, COMMIT, ROLLBACK.

Exam tip: "Outline" needs only a brief description — name each language type, state its purpose (structure vs data) and give one or two example commands.

A3.3.2 — Construct (Part 1 of 3)

Querying Data — SELECT, WHERE, Filtering

Sample Tables (used throughout A3.3.2)

Student

StudentIDNameYearCourseID
101Aisha12CS01
102Ben12MA02
103Chen11CS01
104Dev13PH03
105Ella12NULL

Course

CourseIDTitleCredits
CS01Computer Science6
MA02Mathematics6
PH03Physics5
BI04Biology5

Basic SELECT Syntax

SELECT columns FROM table WHERE condition ORDER BY column ASC|DESC;

SELECT * returns every column. Use it sparingly — name columns explicitly in production queries.

DISTINCT — eliminate duplicates

SELECT DISTINCT Year FROM Student; -- Returns: 12, 11, 13 (each year listed once)

WHERE with relational operators

SELECT Name FROM Student WHERE Year = 12; -- Aisha, Ben, Ella SELECT Name FROM Student WHERE Year >= 12 AND CourseID = 'CS01'; -- Aisha

BETWEEN — inclusive range

SELECT Name FROM Student WHERE Year BETWEEN 11 AND 12;

LIKE with % wildcard — pattern matching

SELECT Title FROM Course WHERE Title LIKE '%Science%'; -- Computer Science (% = any characters) SELECT Name FROM Student WHERE Name LIKE 'A%'; -- Names starting with A
🔒
Preview Only
Full presentation available at CSExamReady.com
A3.3.2 — Construct (Part 2 of 3)

Ordering & Grouping Results

ORDER BY — sort the result set

SELECT Name, Year FROM Student ORDER BY Year DESC, Name ASC;

First sort by Year (highest first); within the same year, sort by Name alphabetically.

ASC = ascending (default, low → high). DESC = descending (high → low).

GROUP BY — collapse rows that share a value

SELECT CourseID, COUNT(*) AS NumStudents FROM Student GROUP BY CourseID;
CourseIDNumStudents
CS012
MA021
PH031

Rule: Every column in SELECT must either appear in GROUP BY or be inside an aggregate function.

HAVING — filter after grouping

SELECT CourseID, COUNT(*) AS NumStudents FROM Student GROUP BY CourseID HAVING COUNT(*) > 1; -- Only CS01 (2 students) is returned

⚠ WHERE vs HAVING

WHEREHAVING
Filters rows before groupingFilters groups after grouping
Cannot use aggregate functionsCan use aggregate functions
Used with single-row dataUsed with grouped data

Combining WHERE + GROUP BY + HAVING

SELECT Year, COUNT(*) AS N FROM Student WHERE CourseID IS NOT NULL -- pre-filter GROUP BY Year -- group HAVING COUNT(*) >= 2 -- post-filter ORDER BY N DESC; -- sort

Logical processing order: FROM → WHERE → GROUP BY → HAVING → SELECT → ORDER BY

🔒
Preview Only
Full presentation available at CSExamReady.com
A3.3.2 — Construct (Part 3 of 3)

JOINs — Querying Two Tables

A JOIN combines rows from two tables based on a related column (usually a primary key in one table matching a foreign key in the other). This is the heart of A3.3.2 — "queries between two tables".

The four JOIN types

INNER JOIN only matching rows LEFT JOIN all left + matched right RIGHT JOIN all right + matched left FULL OUTER JOIN everything from both
TypeReturns
INNEROnly rows where the join condition is true in BOTH tables
LEFT (OUTER)All rows from left table; NULL where right has no match
RIGHT (OUTER)All rows from right table; NULL where left has no match
FULL OUTERAll rows from both; NULL on whichever side has no match

INNER JOIN — only matched students

SELECT S.Name, C.Title FROM Student S INNER JOIN Course C ON S.CourseID = C.CourseID;
NameTitle
AishaComputer Science
BenMathematics
ChenComputer Science
DevPhysics

Ella excluded — her CourseID is NULL. Biology excluded — no student is enrolled.

LEFT JOIN — keep all students

SELECT S.Name, C.Title FROM Student S LEFT JOIN Course C ON S.CourseID = C.CourseID;
NameTitle
AishaComputer Science
BenMathematics
ChenComputer Science
DevPhysics
EllaNULL

JOIN with extra filtering & ordering

SELECT DISTINCT C.Title FROM Course C INNER JOIN Student S ON C.CourseID = S.CourseID WHERE S.Year = 12 ORDER BY C.Title ASC;

Exam tip: Always use table aliases (S, C) when joining — they prevent ambiguous column errors when both tables have a column with the same name (e.g. CourseID).

🔒
Preview Only
Full presentation available at CSExamReady.com
A3.3.3 — Explain

Modifying Data — INSERT, UPDATE, DELETE

INSERT INTO

Add new rows

-- Specify columns INSERT INTO Student (StudentID, Name, Year, CourseID) VALUES (106, 'Farah', 12, 'BI04'); -- Multiple rows at once INSERT INTO Student VALUES (107, 'Gus', 11, 'CS01'), (108, 'Hana', 13, 'MA02');
  • Order of values must match column order
  • Omitted columns get NULL or DEFAULT
  • Fails if a NOT NULL column is missing
UPDATE … SET

Modify existing rows

UPDATE Student SET Year = 13 WHERE StudentID = 101; -- Update many columns & rows UPDATE Course SET Credits = Credits + 1 WHERE Credits < 6;

⚠ Missing WHERE updates every row in the table — a classic and costly mistake.

DELETE

Remove rows

DELETE FROM Student WHERE StudentID = 105; -- Delete many rows by condition DELETE FROM Student WHERE Year = 13; -- Empty whole table (still rolls back) DELETE FROM Student;
  • DELETE = DML, can be rolled back
  • TRUNCATE = DDL, faster but cannot be rolled back in most DBMSs
  • Foreign-key constraints may block deletion of parent rows

Performance — Updating Indexed Columns

An index is a separate data structure (often a B-tree) that lets the DBMS find rows quickly without scanning the whole table. But indexes have a cost: every INSERT, UPDATE or DELETE on an indexed column must also update the index.

Why this matters

  • An indexed column makes SELECT faster but INSERT/UPDATE/DELETE slower
  • Each modification triggers an additional write to the index structure
  • Bulk modifications can fragment the index — leaf pages become scattered, slowing future reads
  • Heavily-modified tables eventually need the index rebuilt (drop + recreate) or reorganised (defragmented in place)

Trade-offs

More indexesFewer indexes
Faster SELECT & JOINFaster writes
Slower writesSlower reads
More disk spaceLess disk space
Maintenance overheadMinimal maintenance

Rule of thumb: Index columns frequently used in WHERE, JOIN or ORDER BY — but avoid indexing columns that change very often.

A3.3.4 — Construct  HL only

Aggregate Functions for Reporting

An aggregate function takes many rows of input and returns a single summary value. They are the foundation of reporting and decision-making — turning raw rows into totals, averages, counts and extremes.

The five required aggregate commands

FunctionPurposeExample
COUNT(*)Number of rowsHow many students?
SUM(col)Total of numeric columnTotal credits
AVG(col)Mean of numeric columnAverage credits per course
MIN(col)Smallest valueLowest year level
MAX(col)Largest valueHighest year level

NULL handling: All aggregates except COUNT(*) ignore NULL values. COUNT(column) ignores NULLs in that column; COUNT(*) counts every row.

Simple aggregates — whole table

SELECT COUNT(*) AS Total, AVG(Credits) AS AvgCr, MIN(Credits) AS MinCr, MAX(Credits) AS MaxCr FROM Course;
TotalAvgCrMinCrMaxCr
45.556
🔒
Preview Only
Full presentation at CSExamReady.com

Aggregates on grouped data

SELECT Year, COUNT(*) AS NumStudents, MIN(StudentID) AS First, MAX(StudentID) AS Last FROM Student GROUP BY Year ORDER BY Year;
YearNumStudentsFirstLast
111103103
123101105
131104104

With JOIN — total credits per year level

SELECT S.Year, SUM(C.Credits) AS TotalCredits FROM Student S INNER JOIN Course C ON S.CourseID = C.CourseID GROUP BY S.Year HAVING SUM(C.Credits) >= 10 ORDER BY TotalCredits DESC;

Why this matters for reporting: Aggregates let a database answer business questions ("How many sales last week?", "What's the average order value?") in a single query — no application-side counting needed.

Common error: Mixing a non-aggregated column into a SELECT without putting it in GROUP BY. SELECT Name, COUNT(*) FROM Student; is invalid — Name varies per row, COUNT(*) returns one value.

🔒
Preview Only
Full presentation available at CSExamReady.com
A3.3.5 — Describe  HL only

Database Views

A view is a stored, named query that behaves like a virtual table. Users SELECT from it as if it were a real table, but underneath the DBMS executes the saved query.

Virtual View

Stores only the query definition, not the data. Each time you query the view, the underlying SELECT is re-run, so results are always current.

CREATE VIEW Year12CS AS SELECT S.Name, C.Title FROM Student S INNER JOIN Course C ON S.CourseID = C.CourseID WHERE S.Year = 12; -- Query it like any table SELECT * FROM Year12CS;
  • Always up-to-date — reflects underlying changes immediately
  • No extra storage
  • Slower for complex queries (recomputed each call)

Materialised (Snapshot) View

Stores the query result as a physical copy. Reads are very fast, but the snapshot can become stale until refreshed.

CREATE MATERIALIZED VIEW SalesDaily AS SELECT ProductID, SUM(Qty) AS TotalSold FROM Sales GROUP BY ProductID; -- Periodically refresh REFRESH MATERIALIZED VIEW SalesDaily;
  • Pre-computed → very fast SELECT
  • Costs storage space
  • Data may be out of date until refreshed
  • Ideal for heavy reporting on large datasets

Why use views? — Benefits

🔒 Security

Hide sensitive columns. A payroll view can expose Name and Department but not Salary or SSN.

🧩 Hide complexity

A view of a 6-table JOIN looks like one simple table to the user — query simplification.

🛡 Data consistency

Everyone uses the same definition (e.g. "active customer") — no two reports calculate it differently.

🔌 Independence

If the underlying tables change, only the view definition needs updating — the apps using the view stay the same.

⚡ Performance

Materialised views pre-compute expensive joins/aggregates for fast reporting dashboards.

📖 Read-only or updatable

Views can be marked read-only; simple views may also allow INSERT/UPDATE that flow through to base tables.

🔒
Preview Only
Full presentation available at CSExamReady.com
A3.3.6 — Describe  HL only

Transactions & ACID

A transaction is a logical unit of work — one or more SQL statements that must succeed or fail together. Transactions protect data integrity when many users access the database concurrently or when failures occur mid-operation.

The four ACID properties

A — Atomicity

"All or nothing". A transaction's statements are treated as a single indivisible unit. If any step fails, every change made so far is rolled back.

C — Consistency

A transaction moves the database from one valid state to another, never violating rules (constraints, foreign keys, triggers). Bad transactions are aborted.

I — Isolation

Concurrent transactions appear to run one at a time. The intermediate state of one is not visible to another, preventing dirty reads and lost updates.

D — Durability

Once COMMIT succeeds, the change is permanent — it survives power loss, crash or reboot, typically via the write-ahead log on non-volatile storage.

Transaction Control Language (TCL)

BEGIN TRANSACTION; -- Step 1: take £100 from Alice UPDATE Account SET Balance = Balance - 100 WHERE Holder = 'Alice'; -- Step 2: give £100 to Bob UPDATE Account SET Balance = Balance + 100 WHERE Holder = 'Bob'; COMMIT; -- both succeeded → save -- if anything went wrong: ROLLBACK; -- undo all changes since BEGIN
CommandWhat it does
BEGIN TRANSACTIONMarks the start of a transaction
COMMITPermanently saves all changes since BEGIN
ROLLBACKUndoes all changes since BEGIN — restores prior state
SAVEPOINTOptional checkpoint inside a transaction to roll back partially

⚠ Bank transfer — without a transaction

If the system crashes between Step 1 and Step 2, Alice loses £100 but Bob never receives it. ACID transactions prevent this — both updates either commit together or both roll back.

A3.3 — Quick Reference

SQL Cheat Sheet

Full SELECT syntax (in logical order)

SELECT [DISTINCT] columns FROM table1 [INNER|LEFT|RIGHT|FULL OUTER] JOIN table2 ON table1.col = table2.col WHERE condition GROUP BY column HAVING aggregate_condition ORDER BY column [ASC|DESC];
🔒
Preview Only
Full presentation at CSExamReady.com

Comparison & logical operators

OperatorMeaning
= <> < > <= >=Equality & comparison (note: <> = not equal)
BETWEEN x AND yInclusive range
IN (a,b,c)Matches any value in list
LIKE '%abc%'Pattern match (% = any chars)
IS NULL / IS NOT NULLTest for missing values
AND / OR / NOTCombine conditions

DDL essentials

CREATE TABLE name (col type, ...); ALTER TABLE name ADD|DROP col; DROP TABLE name;

DML essentials

INSERT INTO t (cols) VALUES (vals); UPDATE t SET col = val WHERE cond; DELETE FROM t WHERE cond;
🔒
Preview Only
Full presentation at CSExamReady.com

Aggregates  HL

COUNT(*) -- rows SUM(col) -- total AVG(col) -- mean MIN(col) -- smallest MAX(col) -- largest

Views  HL

CREATE VIEW v AS SELECT ...; CREATE MATERIALIZED VIEW mv AS ...; DROP VIEW v;

TCL  HL

BEGIN TRANSACTION; ...statements... COMMIT; -- save ROLLBACK; -- undo

📐 Logical processing order

1. FROM & JOIN  →  2. WHERE  →  3. GROUP BY  →  4. HAVING  →  5. SELECT  →  6. DISTINCT  →  7. ORDER BY

🔒
Preview Only
Full presentation available at CSExamReady.com
Summary

Key Terms — A3.3 at a Glance

TermDefinition
SQLStructured Query Language — the standard language for creating, reading, updating and deleting data in a relational database
DDLData Definition Language — statements that define structure: CREATE, ALTER, DROP
DMLData Manipulation Language — statements that manipulate data: INSERT, UPDATE, DELETE
TCL (HL)Transaction Control Language — BEGIN TRANSACTION, COMMIT (save changes), ROLLBACK (undo changes)
JOINCombines rows from two or more tables based on a related column — INNER, LEFT, RIGHT, or FULL OUTER
Aggregate function (HL)Summarises many rows into one value — COUNT, SUM, AVG, MIN, MAX
GROUP BY / HAVINGGroups rows sharing a value, then filters those groups (HAVING filters after grouping; WHERE filters before)
View (HL)A saved, virtual table defined by a query — always reflects live data; a materialized view stores a physical snapshot instead
TransactionA group of database operations treated as a single all-or-nothing unit
A3.3 — Pitfalls

Common Mistakes & Exam Tips

⚠ Missing WHERE on UPDATE / DELETE

UPDATE Student SET Year = 13; changes every student. Always include a WHERE clause unless you genuinely intend a bulk operation.

⚠ WHERE vs HAVING confusion

Use WHERE to filter rows before aggregation, HAVING to filter the result of aggregation. WHERE COUNT(*) > 5 is invalid.

⚠ Forgetting JOIN condition

An INNER JOIN without an ON clause produces a Cartesian product — every row in A paired with every row in B (e.g. 1000 × 500 = 500,000 rows!).

⚠ Comparing to NULL with =

WHERE col = NULL never matches anything. Use IS NULL / IS NOT NULL.

⚠ String quotes

Use single quotes for string literals: 'Aisha'. Double quotes are reserved for identifiers in many DBMSs.

✓ Use table aliases when joining

FROM Student S INNER JOIN Course C ON S.CourseID = C.CourseID — keeps column references unambiguous and queries readable.

✓ Choose the right JOIN type

If a question says "list all customers, including those with no orders", that signals a LEFT JOIN (keep all on the left). "Customers and their orders" usually means INNER JOIN.

✓ Read command terms carefully

TermExpected response
OutlineBrief overview, no detail required
ConstructWrite the SQL statement
ExplainReasons / causes / consequences
DescribeDetailed account, no need to justify

📝 SQL syntax in exams

Minor syntax variations between DBMSs are tolerated. Examiners look for correct logic and structure — not whether you ended every statement with a semicolon. Always use uppercase keywords for clarity.

🔒
Preview Only
Full presentation available at CSExamReady.com
A3.3 — Practice (SL)

Exam Practice — SL Questions

Use the Student and Course tables from earlier slides.

1 Outline the difference between DDL and DML in SQL. [4 marks]
Hint: name each language type, state what it does (structure vs data), and give one example command of each.
2 Construct an SQL query to list the names of all Year 12 students whose CourseID starts with 'CS', ordered alphabetically. [4 marks]
Hint: SELECT … FROM Student … WHERE … AND … LIKE 'CS%' … ORDER BY Name ASC.
3 Construct an SQL query that lists every student's Name together with the Title of their course. Students who are not enrolled on any course must still appear in the result. [4 marks]
Hint: which JOIN type keeps unmatched students? Use a table alias to avoid the ambiguous CourseID.
4 Explain the performance impact of repeatedly updating an indexed column in a relational database, and how this issue can be addressed. [5 marks]
Hint: indexes speed up SELECT but slow down INSERT/UPDATE/DELETE. Mention fragmentation and rebuilding/reorganising the index.
🔒
Preview Only
Full presentation available at CSExamReady.com
A3.3 — Practice HL only

Exam Practice — HL Questions

5 Construct an SQL query to find, for each Year level, the number of students enrolled and the average number of credits across the courses they take. Only show year levels where the average exceeds 5. [6 marks]
Hint: JOIN Student and Course, GROUP BY Year, use COUNT and AVG, then HAVING AVG(C.Credits) > 5.
6 Describe the difference between a virtual view and a materialised view, including one situation in which you would prefer each. [6 marks]
Hint: virtual = stored definition, always current, no extra space. Materialised = stored result, very fast reads, can become stale. Real-time OLTP vs nightly reporting dashboards.
7 Describe how the four ACID properties ensure data integrity when a bank transfer is processed by a database. [8 marks]
Hint: 2 marks per property — name it, define it, and link it to the bank-transfer scenario (e.g. atomicity prevents the system from debiting one account but failing to credit the other).
🔒
Preview Only
Full presentation available at CSExamReady.com
A3.3 — Mark Scheme

Mark Scheme — Model Answers

1 DDL vs DML [4]
  • DDL [2]: Defines / modifies the structure of the database (1); examples include CREATE, ALTER, DROP (1)
  • DML [2]: Manipulates the data inside existing tables (1); examples include SELECT, INSERT, UPDATE, DELETE (1)
2 Year 12 CS students [4]
SELECT Name FROM Student WHERE Year = 12 AND CourseID LIKE 'CS%' ORDER BY Name ASC;
  • SELECT … FROM Student (1)
  • WHERE Year = 12 (1)
  • AND CourseID LIKE 'CS%' (1)
  • ORDER BY Name (ASC) (1)
3 Students + course titles (LEFT JOIN) [4]
SELECT S.Name, C.Title FROM Student S LEFT JOIN Course C ON S.CourseID = C.CourseID;
  • Correct columns SELECT S.Name, C.Title (1)
  • FROM Student with alias (1)
  • LEFT JOIN (NOT INNER) — required to keep unmatched students (1)
  • Correct ON condition matching CourseID (1)
4 Index update performance [5]
  • Indexes speed up SELECT/JOIN by allowing the DBMS to find rows without a full table scan (1)
  • Every INSERT/UPDATE/DELETE on the indexed column must also update the index data structure (1)
  • Repeated modifications cause index fragmentation — leaf pages become disordered, slowing future reads (1)
  • Solution: periodically rebuild (drop + recreate) or reorganise (defragment in place) the index (1)
  • Trade-off — too many indexes worsen write performance; choose indexed columns based on query workload (1)
5 Aggregate query (HL) [6]
SELECT S.Year, COUNT(*) AS NumStudents, AVG(C.Credits) AS AvgCr FROM Student S INNER JOIN Course C ON S.CourseID = C.CourseID GROUP BY S.Year HAVING AVG(C.Credits) > 5;
  • Correct JOIN with ON condition (1)
  • SELECT includes Year, COUNT(*), AVG(C.Credits) (1)
  • GROUP BY Year (1)
  • Correct use of COUNT (1)
  • Correct use of AVG (1)
  • HAVING AVG(C.Credits) > 5 (NOT in WHERE) (1)
6 Virtual vs materialised views (HL) [6]
  • Virtual view [2]: Stores only the SELECT definition / no result data (1); query is re-executed on each access so results are always current (1)
  • Materialised view [2]: Stores the actual query result as a physical table (1); reads are fast but data may be stale until refreshed (1)
  • Use case for virtual [1]: Real-time / OLTP systems where data changes constantly and accuracy is essential
  • Use case for materialised [1]: Reporting dashboards / analytics on large datasets where queries are expensive and slight staleness is acceptable
7 ACID for a bank transfer (HL) [8]

Award 2 marks per property (define + link to scenario):

  • Atomicity [2]: Treats both the debit and the credit as a single unit (1); if the credit fails the debit is rolled back so money is never lost mid-transfer (1)
  • Consistency [2]: The total balance across the two accounts must remain the same before and after (1); constraints (no negative balance, valid account IDs) prevent invalid states (1)
  • Isolation [2]: Concurrent transactions appear sequential (1); another transfer on the same account cannot read the intermediate state and double-spend the funds (1)
  • Durability [2]: Once COMMIT succeeds the transfer is permanently recorded (1); even if the server crashes immediately afterwards the change survives via the write-ahead log on non-volatile storage (1)
🔒
Preview Only
Full presentation available at CSExamReady.com
A3.3 — Connections & Next Steps

Linking Questions & What's Next

Cross-Topic Connections

🔗 How does the schema design from A3.2 (primary keys, foreign keys, normalisation to 3NF) make the JOINs in A3.3 possible and efficient?

🌐 How might network latency (A2) affect the performance of multi-table JOINs in a distributed database, and how could materialised views help?

🤔 To what extent does the move toward NoSQL (A3.4 HL) compromise the ACID guarantees that relational databases provide? (TOK)

💡 How do indexes (A3.3.3) and views (A3.3.5) represent the same fundamental trade-off — pre-compute work to speed up reads, at the cost of storage and freshness?

Coming Up Next in Theme A

A3.4 HL only

Alternative Databases & Data Warehouses

NoSQL families — document, key-value, column-family, graph. OLTP vs OLAP. Data warehouses, ETL, and when relational is the wrong choice.

A4

Machine Learning & AI

Building on data fundamentals — how databases feed training pipelines and how queries become features for models.

A3.3 Key Takeaway

SQL is the universal language for working with relational data. Mastering SELECT (with JOINs, WHERE, GROUP BY) lets you ask any question; INSERT/UPDATE/DELETE lets you change the data safely; and ACID transactions guarantee that — no matter what goes wrong — your data stays correct.