Relational Databases and Transactions
Relational Databases and Transactions 🗃️
This lesson introduces the relational database: the common cloud default when records need a dependable structure and related changes must succeed together.
In this lesson, you will learn to:
- Explain how tables, rows, columns, schemas, and SQL work together in a relational database.
- Identify what a managed relational service takes off your team's operational workload.
- Distinguish workloads that benefit from strict structure and reliable transactions.
Tables, Rows, Columns, and SQL 🧾
A relational database stores data in tables. If you've ever used a spreadsheet, you already have most of the mental model. A table has columns, which are the named fields every record must fit into, and rows, which are the individual records themselves. A "Patients" table might have columns for patient identifier, first name, last name, and date of birth, and each row is one patient.
What makes it relational is that tables refer to one another. An "Appointments" table doesn't repeat the patient's name; it stores the patient identifier and points at the row in the Patients table. That pointing is called a relationship, and it's why the data stays consistent. Change a patient's surname in one place and every appointment linked to them is automatically correct, because the surname was only ever stored once. The column that uniquely identifies each row (that patient identifier) is called the primary key. A foreign key is the matching field in another table, such as patient_id in Appointments, that points back to that primary key.

The diagram captures the practical payoff: you store a patient's details once, then use the identifier to connect every appointment to the right record.
The rules about which tables exist, which columns they have, and what type of data each column accepts are called the schema. The schema is defined up front and enforced by the database. If someone tries to save a payment record with no amount, or types text into a date column, the database refuses it. That strictness sounds inconvenient until you consider the alternative, which is discovering three months later that half your records are missing a field nobody noticed.
You ask questions of a relational database using SQL, which stands for Structured Query Language. It's a readable, English-like language for retrieving, adding, changing, and deleting data, and it has been the standard for decades. Being able to read basic SQL is a useful skill for a new cloud engineer, because it's the common language between engineers, analysts, and reporting tools.
