Foundations of the Relational Model

What Is the Relational Model?

The relational model was introduced by E. F. Codd in his landmark 1970 paper, "A Relational Model of Data for Large Shared Data Banks." Before this model existed, data was stored in hierarchical or network structures that required programmers to navigate physical storage paths by hand. Codd's insight was that data should be described by its logical content, not by how it is physically arranged on disk. That separation—logical structure from physical storage—remains the foundation of every modern relational database system, including PostgreSQL, Oracle Database, and Microsoft SQL Server.

Relations, Tuples, and Attributes

In the relational model, data is organized into relations. A relation is formally a two-dimensional table made up of rows and columns, but the term carries precise meaning beyond a simple spreadsheet grid.

• A tuple is one row in a relation. It represents a single instance of the entity being described—for example, one customer, one order, or one product. The order of tuples in a relation does not matter; there is no "first" or "last" row in a mathematical sense.
• An attribute is one column in a relation. Each attribute has a name and describes exactly one property of the entity. For example, a `customer` relation might have attributes named `customer_id`, `last_name`, `email`, and `city`.
• The set of all attributes in a relation is called its schema. A schema is written in the form `customer(customer_id, last_name, email, city)`.

Domains

Every attribute draws its values from a domain—the complete set of permitted values for that attribute. A domain can be a standard data type such as integer, date, or character string of a fixed length, or it can be a more constrained set defined by a business rule. For example, the domain of a `ship_state` attribute might be restricted to the fifty US state abbreviations. Domains enforce data integrity at the most basic level: a phone number column should never hold a negative integer.

Null is a special marker meaning "value unknown or not applicable." Nulls are distinct from zero or an empty string. Relational systems handle nulls carefully because they complicate comparisons and aggregate calculations.

Keys: Candidate, Primary, and Surrogate

A candidate key is any minimal set of one or more attributes whose combined values uniquely identify every tuple in a relation. "Minimal" means you cannot remove any attribute from the set and still guarantee uniqueness. A relation may have more than one candidate key.

A primary key is the candidate key the database designer selects as the official identifier for tuples in that relation. Primary key values must be unique and must never be null—this rule is called the entity integrity constraint.

A surrogate key is an artificial identifier—usually a system-generated integer or UUID—added to a relation when no natural attribute or combination of attributes makes a reliable primary key. Surrogate keys have no business meaning; they exist solely to serve as a stable, compact row identifier. Many practitioners prefer surrogate keys because natural keys (such as a Social Security number or a product code) can change over time or contain sensitive information.

How Relations Differ from Flat-File Storage

A flat file—such as a CSV spreadsheet—stores all related information in a single table with no enforced structure. Consider a CSV that stores customer orders. Each row might repeat the customer's name, address, and phone number for every order that customer places. This creates three well-known problems:

1. Insertion anomaly: You cannot record a customer who has placed no orders yet, because every row requires order data.

2. Update anomaly: If a customer moves, you must update every row containing that customer's address. Missing even one row leaves the data inconsistent.

3. Deletion anomaly: If you delete the only order for a particular customer, you lose the customer's contact information entirely.

The relational model solves these problems by splitting data into separate relations—one for customers, one for orders—and linking them through foreign keys. A foreign key is an attribute in one relation whose values correspond to the primary key of another relation. This enforces referential integrity: you cannot have an order that points to a non-existent customer.

Data Integrity and Professional Responsibility

Database administrators bear direct responsibility for the accuracy and availability of data that organizations depend on. Errors in schema design—such as missing key constraints or incorrect domains—can propagate silently into business decisions, financial reports, or even safety-critical records. Always apply constraints at the database level rather than relying on application code alone; applications change, but the database outlasts any single application.

When working with systems that store personal or regulated data, be aware that your design choices have privacy and compliance implications. Attribute-level domains, key constraints, and careful normalization are not abstract academic exercises—they are the first line of defense against data corruption.

Summary

The relational model organizes data into relations composed of tuples and attributes. Each attribute is governed by a domain that restricts acceptable values. Keys—candidate, primary, and surrogate—uniquely identify tuples and enforce entity integrity. Compared to flat-file storage, the relational model eliminates insertion, update, and deletion anomalies by separating entities into distinct relations linked by foreign keys. These concepts underpin every topic in this course and every credential exam you will sit.