Relational Database
A relational database is a database that organizes data into tables of rows and columns, where relationships between tables are expressed through shared key values rather than by physically nesting or embedding one record inside another. A customer and their orders live in two separate tables, connected by a shared customer_id rather than the orders being stored inside the customer's own record — a design choice that lets the same customer_id be referenced from orders, support tickets, and payment records alike without duplicating the customer's information in each place.
The model comes directly from Edgar F. Codd's 1970 paper "A Relational Model of Data for Large Shared Data Banks," written while Codd was a researcher at IBM, and its core innovation was mathematical: representing data and the relationships between data points using the formal language of set theory and predicate logic (relational algebra), rather than the pointer-based, physically-linked storage structures that preceded it (hierarchical and network database models). This abstraction is what makes SQL possible: because the relational model describes data in terms of logical relationships rather than physical storage locations, a query can ask what data it wants without specifying how to navigate to it, leaving the database engine free to decide the most efficient retrieval path — a separation of "what" from "how" that was a genuine conceptual leap over the database models Codd's paper was responding to.
Normalization — the process of structuring tables to eliminate redundant data, formalized through a progression of "normal forms" Codd and later researchers defined — is the organizing discipline underneath good relational schema design, and its core goal is preventing the same fact from being stored in more than one place where it could drift out of sync. A poorly normalized schema that stores a customer's address directly on every order row (rather than once, in the customers table, referenced by key) risks exactly this: updating the customer's address on one order but not another leaves the database internally inconsistent about a fact that should have a single source of truth, an error that normalization structurally prevents by design rather than relying on application code to keep duplicated copies in sync.
Primary and foreign keys are the mechanical implementation of relationships in this model: a primary key is a column (or set of columns) that uniquely identifies each row in a table, and a foreign key is a column in one table that references a primary key in another, with the database engine enforcing referential integrity — refusing to let an order reference a customer_id that doesn't actually exist in the customers table. This constraint-level enforcement is a meaningful advantage over storing the equivalent relationship in an unconstrained format like a spreadsheet or flat file, where nothing stops an order from referencing a nonexistent or mistyped customer ID; a relational database makes that specific class of error structurally impossible rather than something that has to be caught after the fact.
Joins — SQL operations that combine rows from two or more tables based on a related key — are how the relational model's split-apart, normalized data gets reassembled into a usable combined view at query time, and query performance at scale depends heavily on how efficiently the database engine can execute these joins, which is the primary reason indexing on join columns (typically the primary and foreign keys involved) is one of the most consequential performance decisions in relational database design.
Read a relational database as data deliberately kept apart, structurally, so it can be recombined correctly on demand: Codd's 1970 formalization is what made that split-and-rejoin approach mathematically rigorous rather than ad hoc, normalization is the discipline that decides how far apart related facts should be kept to avoid inconsistency, and primary keys, foreign keys, and joins are the concrete mechanisms — enforced by the database engine itself, not by application code — that make reassembling the pieces both fast and reliably correct.