These are the core ideas every relational database is built on. Understanding them makes everything you do later — tables, queries, joins — click into place faster.

A relational database stores data in tables made of rows and columns, connected to each other through relationships. A non-relational database stores data in more flexible shapes, like documents or key-value pairs.

Neither is "better" — relational fits data with clear structure and relationships (like orders linked to customers); non-relational fits data that's flexible or changes shape often.

A table represents one type of thing — for example books or customers. Each row in that table is one specific record. Each column is one attribute shared by every row.

Example: in a books table, each row is one book, and columns like title, author, and price describe that book.

The schema is the blueprint of a database — which tables exist, what columns they have, what data types those columns use, and how tables relate to one another.

Think of the schema as the architecture plan drawn up before any actual data (rows) gets added.

Keys are how rows are uniquely identified and how tables connect to each other.

Normalization is the process of organizing tables to avoid storing the same information more than once.

Without normalization: every row in an orders table repeats the customer's full name and address.

With normalization: the customer's details live once in a customers table, and orders just stores a customer_id pointing to it.

Why it matters:

• Avoids inconsistencies (the same customer's name spelled two different ways in two rows)
• Saves storage space
• Makes updates easier — change the customer's address once, not in every order

Normalization is usually described in stages called normal forms (1NF, 2NF, 3NF), each removing a specific kind of duplication. At a basic level, just remember the core idea: one fact, stored in one place.

Learn more about normalization

ACID is a set of guarantees that a reliable database follows whenever it makes changes to data.

Simple example: transferring money between two bank accounts involves subtracting from one and adding to the other. Atomicity guarantees both happen together — you'll never end up with money deducted from one account but not added to the other.

Constraints are rules attached to columns that stop invalid data from being saved.

An index is a structure that speeds up how quickly the database can find rows — similar to an index at the back of a book. Indexes make reads faster but add a small cost to writes. This gets covered in depth in the Performance module, but it's worth knowing the term exists.

A database like MySQL runs as a server — a background process managing the actual data. Anything that connects to it — a terminal, an app, VS Code — is a client sending it commands. All reads and writes go through the server, which is what keeps the ACID guarantees intact even when many clients connect at once.

Learn more about the client-server model