Stop 08 · Systems & Technical UnderstandingTopics · 2/9

Databases 101 for BAs

In short

'Can we just add a field for alternate phone number?' sounds like a five-minute job. Knowing how tables and links work shows you why it sometimes isn't, and helps you write better requirements.

A basic mental model of tables, rows and relationships — enough to understand why 'just add one field' isn't always trivial, and to write requirements that account for data structure realistically.

The purple blob has a big open register on a desk, with a red string linking a line on one page to a line on the other.

Think of it like this

Two school registers

The attendance register lists students by roll number. The marks register also uses roll numbers, not names. To see Priya's marks, find her roll number in one book, then look it up in the other. That shared roll number is how database tables connect.

Watch it happen

A small shop database

Shop database

customers

orders

id (key)

name, phone

customer_id

amount, date

1/5A database holds several tables. Each table is like a sheet with fixed columns.

The big ideas

What you need to know

Tables, rows, columns

A table stores one kind of thing. Each row is one record, each column one attribute.

Keys connect tables

A primary key uniquely identifies a row. A foreign key in another table points back to it.

One-to-many is common

One customer has many orders. Asking 'how many of X per Y?' helps you describe data correctly.

Rules live in data too

Is phone required? Unique? Max length? These questions are part of your requirements.

See it in code

Walk through the code

sql

1SELECT c.name, COUNT(o.id) AS total_orders2FROM customers c3JOIN orders o ON o.customer_id = c.id4WHERE o.created_at >= '2026-01-01'5GROUP BY c.name6ORDER BY total_orders DESC7LIMIT 10;

1/3Pick each customer's name and count their orders.

Top 10 customers by number of orders this year. Being able to read a query like this helps you check reports yourself.

Save yourself the pain

Common mistakes

Oops

Assuming a new field is just a new box on the screen.

Do this instead

Ask where it's stored, who else reads that data, and whether old records need a value.

Oops

Describing data loosely: 'customer details'.

Do this instead

List each field with type, whether it's required and an example, like 'phone: 10 digits, required'.

Your mission

Run your first query

~30 min

Quick check

Why do orders store customer_id instead of the customer's full name and address?

Go deeper

1Sketch a simple database schema (e.g. customers, orders) for a system you're documenting requirements for.
2Learn the difference between a relational and non-relational database at a high level.
3Understand why changing an existing field's type can be a risky change, not a quick fix.