A database is an organised, persistent store of data with efficient query and update. The dominant model is relational (Codd, 1970): data lives in tables (relations) of rows (records) and columns (fields). A primary key uniquely identifies each row; a foreign key in one table references the primary key of another, encoding relationships between tables.

SQL (Structured Query Language) is the declarative language for relational data. You state what you want, not how to fetch it — the database's query optimiser devises an efficient plan. Core verbs: SELECT (read), INSERT, UPDATE, DELETE, and JOIN (combine rows across tables on a matching key).

Normalisation organises tables to eliminate redundancy so that each fact is stored exactly once, preventing update anomalies. Transactions guarantee ACID properties: Atomicity (all-or-nothing), Consistency, Isolation (concurrent transactions don't interfere), and Durability (committed data survives crashes).

The relational model's genius is separating logical structure from physical storage. You query by describing relationships between values; the engine decides which indexes to use, in what order to scan, how to join. This declarative style is why the same SQL runs efficiently on a laptop or a thousand-server cluster — the optimiser adapts, you don't rewrite.

Why normalise? Consider storing a customer's address alongside every one of their orders. Change address and you must update dozens of rows; miss one and your data contradicts itself — an update anomaly. Normalisation splits customers and orders into separate tables linked by a foreign key, so the address lives in exactly one place. The JOIN reassembles the full picture on demand.

We create two related tables, insert data, and answer a real question with a JOIN plus aggregation: "How much has each customer spent?"

-- Two tables linked by a foreign key
CREATE TABLE customers (
    id    INTEGER PRIMARY KEY,
    name  TEXT NOT NULL,
    city  TEXT
);

CREATE TABLE orders (
    id          INTEGER PRIMARY KEY,
    customer_id INTEGER REFERENCES customers(id),   -- foreign key
    amount      REAL NOT NULL
);

INSERT INTO customers VALUES (1, 'Aisha', 'Kuala Lumpur'),
                             (2, 'Ben',   'Singapore'),
                             (3, 'Chen',  'Kuala Lumpur');

INSERT INTO orders VALUES (10, 1, 250.00), (11, 1, 100.00),
                          (12, 2,  75.50), (13, 3, 400.00);

-- Total spend per customer, highest first (JOIN + GROUP BY + aggregate)
SELECT  c.name,
        c.city,
        COUNT(o.id)   AS num_orders,
        SUM(o.amount) AS total_spent
FROM        customers AS c
JOIN        orders    AS o  ON o.customer_id = c.id
GROUP BY    c.id, c.name, c.city
HAVING      SUM(o.amount) > 100          -- filter groups after aggregation
ORDER BY    total_spent DESC;

-- Result:
-- name  | city          | num_orders | total_spent
-- Chen  | Kuala Lumpur  |     1      |   400.00
-- Aisha | Kuala Lumpur  |     2      |   350.00

Read it declaratively: JOIN stitches each order to its customer via the key; GROUP BY collapses rows per customer; SUM/COUNT aggregate each group; HAVING filters the groups; ORDER BY sorts. Ben is excluded because his 75.50 fails the HAVING test. You never told the engine how to loop — only what you wanted.