SQLRelational Database (RDBMS)

Relational Database (RDBMS)

A Relational Database Management System (RDBMS) is a DBMS built around the relational model — a way of organizing data into tables made up of rows and columns, where each table represents a single type of entity. PostgreSQL, MySQL, SQL Server, Oracle, and SQLite are all RDBMSs, and SQL is the language they all speak.

Where the relational model came from

The relational model was introduced by E. F. Codd, a mathematician working at IBM, in a 1970 paper called “A Relational Model of Data for Large Shared Data Banks.” Codd proposed representing data as mathematical relations — which, conveniently for us, correspond very closely to what we now think of as tables. His work laid the theoretical foundation that every RDBMS (and SQL itself) is still built on today, decades later.

Tables, rows, and columns

The relational model organizes everything into three building blocks:

Concept

Represents

Example

Table

An entity — a type of "thing" the system tracks

customers, orders, products

Row (record)

One specific instance of that entity

One particular customer, e.g. "Jane Doe"

Column (attribute)

A single piece of information about the entity

email, signup_date, country

Put together, a table is essentially a grid: every row has a value (or is empty) for every column, and every row in the same table shares the same set of columns.

A conceptual customers table

SQL
-- customers
+----+------------+---------------------+-------------+
| id | name       | email               | country     |
+----+------------+---------------------+-------------+
| 1  | Jane Doe   | jane@example.com    | Canada      |
| 2  | Sam Osei   | sam@example.com     | Ghana       |
+----+------------+---------------------+-------------+
Relationships between tables

Rarely does one table tell the whole story. A customers table might relate to an orders table (each order belongs to a customer), which in turn relates to an order_items table (each order contains several items). These connections are established using keys — we’ll cover primary keys and foreign keys in detail in the upcoming pages on constraints. For now, just know that relationships between tables are how an RDBMS avoids duplicating the same information over and over.

A common misconception: what “relational” really means

It’s extremely common — and very reasonable — to assume that “relational database” refers to the fact that tables have relationships with each other (customers relate to orders, orders relate to products, and so on). That’s a satisfying story, but it’s not actually where the name comes from.

In Codd’s original terminology, a relation is simply the mathematical term for what we call a table: a set of tuples (rows) sharing the same attributes (columns). “Relational database” means a database built from mathematical relations — not a database whose tables happen to reference one another. Tables in a relational database don’t even need foreign keys pointing between them to qualify as “relational”; the term describes the underlying model, not the presence of cross-table links.

Note
It’s a genuinely common mix-up, even among working developers. Knowing the real origin of the term is a good way to sound sharp in a database interview — and it makes Codd’s foundational contribution easier to appreciate.
Why the relational model won
  • Predictability — a fixed schema means every row in a table has the same shape, which makes data easy to validate and reason about

  • Powerful querying — the relational model comes with relational algebra baked in, which is exactly what SQL's SELECT statements implement

  • Reduced duplication — splitting data into related tables (a process called normalization, covered later) avoids storing the same fact in multiple places

  • Strong consistency guarantees — RDBMSs are built around transactions that keep data correct even when many things happen at once