DataslopeWhat Relationships Are
Learn how associations between entities become the links that make a relational schema useful.
A database full of isolated tables is not very useful. Customers matter because they place orders. Orders matter because they contain products. Employees matter because they belong to departments.
A relationship is an association between entities. It says how the things in your model are connected.
Relationships are the verbs
If entities often come from nouns, relationships often come from verbs: a customer places an order, a book belongs to an author, a student enrolls in a course.
Those labels are plain English, but they are serious design clues. They tell you which tables will need to refer to other tables.
A relationship connects rows
At the entity level, we say "customers place orders." At the row level, a specific customer row is connected to specific order rows.
That is why relationships are central to relational design. They make separate tables act like one connected model.
From real-world link to schema link
In PostgreSQL, a relationship is usually realized with keys. One table has a primary key. Another table stores a foreign key that points to it.
The relationship is the idea. The foreign key is the database mechanism that stores and protects the idea.
The line says the entities are related. The customer_id FK column
shows how the relationship will be stored.
Quick check
In the sentence "A customer places an order," what does "places" most likely reveal?
A column data type.
A relationship between the customer entity and the order entity.
A primary key value.
A table that should store every possible noun.
Relationships answer business questions
Relationships are not just structure for structure's sake. They let the database answer questions that cross entity boundaries:
- Which orders did Ada place?
- Which products appear in order
101? - Which department does each employee belong to?
- Which students are enrolled in Biology?
Without the relationship, the query could list customers and list orders, but it could not reliably know which orders belonged to whom.
Some relationships become entities
A relationship can be important enough to store as its own entity. For
example, an enrollment is the relationship between a student and a
course — but it may also have attributes like enrolled_on or grade.
When the association itself has facts, a table for the association is often the cleanest design.
Relationship names should be readable
A good relationship label creates a sentence:
has is sometimes fine, especially in compact diagrams, but a more
specific verb can reveal business meaning. "Customer places order" is
clearer than "customer has order."
Check your understanding
What is a relationship in database design?
A rule that every table must have the same columns.
An association between entities, such as a customer placing an order.
A backup copy of a table.
A column that always stores text.
How is a relationship usually realized later in a relational schema?
By giving both tables exactly the same name.
By storing all rows from both entities in one cell.
By using a foreign key that points to a primary key.
By deleting the primary keys.
Why might an enrollment between a student and a course become its own table?
Because every verb must become a table.
Because students and courses cannot be queried together.
Because the association may have its own attributes, such as enrolled date or grade.
Because PostgreSQL does not allow course tables.