Subjects and lessons to explore.

Law

Databases & SQL · Foundations

Relationships

9 min read 5 practice questions
9 key termsSourcesReport an error
Want it in plain words first? Jump to Eli explains — the same idea, no jargon.
On this page 9 sections
  1. In 30 seconds
  2. Why this matters
  3. The college version
  4. Eli explains
  5. Worked example
  6. Key takeaway
  7. Quick check
  8. Study tools
  9. Sources & references

In 30 seconds

A is the logical link between two tables, built on shared key values: a in one table points to a in another. Relationships exist because real-world things relate — customers place orders, and orders contain products — and a well-built database records those links without copying data. The three cardinalities — one-to-one, one-to-many, many-to-many — describe how many rows can connect on each side. Diagrams draw tables as boxes joined by lines, with symbols marking one or many. Relationships are the "relational" in relational databases.

Why this matters

Relationships are what turn a collection of tables into a database you can actually ask questions of. Without them, each table is an island: you could list all orders or all customers, but not which customers ordered a specific book. With them, facts are stored once and queries travel between tables along the links. That is why a well-designed database keeps your address in one place while every order, invoice, and delivery points at it. Relationships also give you the mental model behind the diagrams, key conventions, and query tools you will meet next — and they are the reason the whole approach is called relational.

The college version

The working definition: a logical link built on shared keys

A relationship is the logical link between two tables, and it runs through shared key values. Oracle's explainer makes the mechanism concrete: two tables may have only one thing in common — an ID column — but because of that common column, the relational database can create a relationship between them. IBM describes the same idea from the other direction: data in a relational database is structured across multiple tables joined through identifiers such as primary or foreign keys, and those identifiers demonstrate the relationships between the tables. Two features matter: a relationship is not stored separately from the tables — it is a property of how their values line up — and the link is carried by keys, not by copying rows.

Why relationships exist: the real world is connected

Relationships exist because the things a database tracks are connected in reality. If you build a table for each of these things, the connections between them do not disappear — they must live somewhere, and the relational model's answer is to let the tables reference one another. IBM's example shows the pattern with a customer table and a transaction table: one holds account-level information such as company name and industry, the other records individual purchases, and the two are joined by a common customer ID field. Connections are where the useful questions live, so the relational model chooses to model them.

The mechanism: keys that point across tables

The mechanism of a relationship is the key. A primary key marks each row as unique inside its own table; a foreign key in another table carries that same value, pointing back at the row it identifies. When an order row stores a customer ID, that value is the relationship between the order and the customer. Foreign keys and primary keys each have their own lessons in this unit; the point here is how they work together. The link exists whenever values in one table match key values in another, and the database can enforce that every value points at a real row.

The three cardinalities: how many rows connect

describes how many rows on one side of a relationship can connect to rows on the other side. IBM's data-modeling guide defines it as the number of instances in one entity that relate to the instances of another, and Visual Paradigm's guide lists the same three common forms. In a , each row in one table links to at most one row in the other, and vice versa — a country and its capital city. In a , one row on the first side links to many rows on the second, while each row on the second side links to exactly one row on the first — one band, many songs. In a , rows on both sides can link to many rows on the other side — a recipe uses many ingredients, and an ingredient appears in many recipes. Each has its own lesson in this unit; here they are the vocabulary for describing how much of one table a row of another can touch.

Relationship diagrams: drawing the links

Because relationships are connections, they are often drawn. An is a visual model of how the items in a database relate: tables appear as boxes, and lines connect the boxes that share a relationship. IBM describes the diagram as a specialized type of flowchart whose symbols are linked with connecting lines; Visual Paradigm notes that a relationship is presented as a connector between entities. The lines carry meaning at their ends: a single mark shows the "one" side, while a forked symbol — the crow's foot, named for its three-pronged shape — shows the "many" side. Reading the diagram tells you at a glance which tables are linked and what cardinality the link has.

Why relationships matter: queryable data, less duplication

The payoff of relationships is twofold. First, they make data queryable across tables: because tables are linked by shared key values, a single question can reach into several tables at once — which customers bought a specific product. IBM's example joins customer and transaction tables by customer ID to produce sales figures by industry. Second, relationships avoid duplication: because a relationship carries a key rather than a copy of the data, each fact lives in exactly one table and every other table points at it. When a customer's address changes, one row is updated and every linked order reflects it automatically. The formal discipline of splitting data so it is not duplicated is called normalization — its own topic — but relationships are the reason duplication is unnecessary in the first place.

The honest framing: the "relational" in relational databases

The honest framing is that relationships are the core idea of the whole approach. PostgreSQL's documentation notes that "relation" is essentially the mathematical term for a table — but a database of unrelated tables would not earn the name "relational." IBM puts the emphasis where it belongs: a relational database organizes data into tables where the data points are related to each other, and relationships are what analysts exploit with queries. When you hear "relational database," the word is not decoration. It is the promise that your tables are connected — and this lesson's definitions, cardinalities, and diagrams are the vocabulary for saying exactly how.

Eli, the EliExplains learning guide

Eli explains

The same idea, in plain words

Explain it like I’m 10

A relationship is simply a connection between two tables, and the connection runs through a shared value. One table stores the ID of a row in another table, so you can follow the ID from one table to the other — that path is the relationship. The path lets you ask questions that span both tables, like which customers ordered a certain book, without ever copying the book into the customer table. The three cardinalities just say how many rows the path can reach: one or many on each side. Draw the tables as boxes and the paths as lines, and you have a relationship diagram.

Picture it like this

Think of two maps of the same city — one showing restaurants, one showing subway stations. The maps have nothing in common except the street grid they both use. Because they share the same street names, you can lay one over the other and find "restaurants within two blocks of a station." The street grid is the shared key; the answer comes from connecting the maps, not from redrawing either one. That is what a relationship does for tables: it lets two lists answer questions together, using the values they already share.

Where the picture stops working

The comparison stops short in one way. Maps overlap everywhere — every point on one map sits somewhere on the other — but a database relationship only connects rows whose key values actually match. An order links to a customer only if the customer ID appears in both tables, and the database can refuse to store a link that points at nothing. Overlaying maps is a visual act; a database relationship is a rule about matching values.

Worked example

A small veterinary clinic keeps three tables. The pets table has one row per animal, each with a pet ID. The visits table logs every checkup and stores the pet ID on each visit — the foreign key pointing at the pet's row. One pet can have many visits, while each visit belongs to exactly one pet, so the relationship between pets and visits is one-to-many. The owners table links to pets the same way: one owner may bring in several pets, another one-to-many. When the clinic wants a list of pets treated for allergies last spring, it follows the pet IDs from the visits table back to the pets table and reads each pet's name and owner. Nothing is copied: the visits table stores only the pet ID, and each pet's details live once in the pets table. A relationship diagram of the clinic would draw three boxes — owners, pets, visits — with a line from owners to pets and another from pets to visits, a single tick on the "one" side and a fork on the "many" side of every link.

Key takeaway

A relationship is a logical link between tables, carried by shared key values and described by its cardinality — one-to-one, one-to-many, or many-to-many. Relationships are what make data queryable across tables and what make duplication unnecessary, which is why they are the core idea of the relational model.

Quick check

3 questions here, of 5 in this lesson’s practice set. Answers stay hidden until you check.

Question 1 of 3foundational

What connects two tables in a relational database?

Choose an answer, then check it.
Question 2 of 3intermediate

Which statement best explains why relationships between tables exist?

Choose an answer, then check it.
Question 3 of 3intermediate

A gym keeps a members table and a check-ins table. Each check-in row stores the member ID of the person who scanned in. What creates the relationship between the two tables?

Choose an answer, then check it.
Practice all 5

Keep learning

Ready to build on this? Continue to the next lesson.

Practice this lesson
Study tools & related lessonsYou’ll learn to · Common mistakes · Easily confused · Key vocabulary · Related

You’ll learn to

  • Define a relationship as a logical link between tables based on shared key values.
  • Explain why relationships exist, using an original example of customers placing orders and orders containing products.
  • Describe how a foreign key pointing to a primary key creates the link between two tables.
  • Distinguish the three cardinalities — one-to-one, one-to-many, and many-to-many — with an example of each.
  • Interpret relationship diagrams as boxes connected by lines, with symbols at each end showing whether the link means one or many.
  • Apply the relationship concept to explain why relational databases support cross-table queries and avoid duplication.

Common mistakes

  • Thinking a relationship is a separate object stored between the tables.

    A relationship is not a row or a file of its own; it exists because key values in one table match key values in another. Remove the shared values and the relationship is gone, even though the tables remain.

  • Confusing cardinality with the total number of rows.

    Cardinality describes how rows on each side connect — one row to many, many to many — not how many rows a table happens to hold. A table with thousands of rows can still sit on the "one" side of a one-to-many relationship.

  • Assuming every pair of tables is related.

    Tables only have a relationship when they actually share meaningful key values. Two tables with no common key are simply unrelated, and no diagram line should connect them.

  • Reading a diagram's symbols backwards.

    On a relationship diagram, the forked end (the crow's foot) means "many" and the single mark means "one." Reversing them turns a one-to-many link into a many-to-one — the same connection, misread.

Easily confused

One-to-many vs. Many-to-many

In one-to-many, only one side's rows can repeat: one band, many songs. In many-to-many, both sides repeat: many recipes, many ingredients. The distinction is whether the "many" applies to one end or both.

Relationship vs. Foreign key

A relationship is the logical link between tables; a foreign key is the column that carries it. The relationship is the idea, the foreign key is the mechanism.

Relationship diagram vs. Table listing

A diagram shows the connections between tables at a glance, with symbols for one and many; a listing shows each table's rows and columns but hides how the tables fit together.

Key vocabulary

relationship
The logical link between two tables, created when key values in one table match key values in another.
cardinality
The description of how many rows on one side of a relationship can connect to rows on the other side.
one-to-one relationship
A relationship in which each row in one table links to at most one row in the other table, and vice versa.
one-to-many relationship
A relationship in which one row in the first table can link to many rows in the second, while each row in the second links to exactly one row in the first.
many-to-many relationship
A relationship in which rows on both sides can link to many rows on the other side.
foreign key
A column in one table that holds the primary key value of a row in another table, carrying the link between them.
primary key
The column, or combination of columns, that uniquely identifies each row within its own table.
entity relationship diagram (ERD)
A drawing that shows tables as boxes connected by lines, with symbols at each end describing how many rows can connect.
crow's foot notation
A diagram convention that marks the "many" side of a relationship with a three-pronged fork at the end of the connecting line.

Sources & references

  1. What is a relational database? — IBM
  2. What Is a Relational Database? — Oracle
  3. What is an entity relationship diagram? — IBM (IBM Think)
  4. What is Entity Relationship Diagram (ERD)? — Visual Paradigm
  5. PostgreSQL Documentation 18: Chapter 2. The SQL Language — 2.2. Concepts — The PostgreSQL Global Development Group

EliExplains lessons are original prose written from the open, credible references above. See Copyright & Licensing.

Researched 2026-08-21

Educational content only. It is not medical, legal or professional advice. Found an error? Tell us.