Is every relation binary?

No; relations can have different numbers of attributes.

Is a relation always a function?

No. Functions impose additional association rules.

Does changing row order change a mathematical relation?

No, because its members form a set.

AI Glossary / Data governance and quality / Advanced

Relation

Definition

A relation is a set of tuples that describes which combinations of values belong together. Mathematically, an n-ary relation can be defined as a subset of a Cartesian product of n domains. In database terminology, a relation is commonly represented as a table with named attributes. In AI, relations can represent structured facts about objects. The intended meaning depends on the domains, attributes and interpretation, not on the table's visual layout alone.

What it means

Consider a relation Reviews(reviewer, article). Each tuple states that a particular reviewer reviews a particular article. The tuple (R1, A1) is one member of the relation, while the collection of all such members is the relation itself.
A relation can have one attribute, two attributes or more; it is not limited to links between pairs of objects. Its schema describes the attributes, while its current value contains the tuples. Two relations can share a schema yet contain different tuples. Conversely, identical-looking values can mean different things when their attribute roles differ.

How it works

Start by defining the domains and roles of the attributes. Then specify which combinations are members. In the classical set model, listing a tuple twice does not create two distinct members, and rearranging the displayed rows does not change the relation.
A mathematical positional tuple distinguishes its component positions. A database formulation with named attributes associates values with those names, so rearranging displayed columns while retaining their labels does not change their roles.
Operations can select tuples meeting a condition, project onto fewer attributes or join compatible information. SQL implementations require additional care: ordinary query results can retain duplicates, while DISTINCT removes duplicate result rows. A SQL result should not automatically be treated as a mathematical set without checking its semantics.

Three practical examples

Editorial coverage: Reviews(reviewer, article) records assigned review relationships. An article may have several reviewers, so this relation need not behave like a function from article to reviewer. The team can ask which articles have any assignment without assuming exactly one reviewer per article.
Learning prerequisites: Prerequisite(earlier_topic, later_topic) records an explicitly defined ordering relationship. A pair does not automatically imply its reverse. If inference about indirect prerequisites is needed, the model must specify the relevant rule rather than assuming every relation is transitive.
AI knowledge representation: A project records UsesTool(team, tool) as structured facts. The relation gives a precise form to a statement, but its members still need evidence. Recording a tuple does not make the real-world assertion true, current or complete.

Think of it this way

Think of a guest list that records pairs of people and events. Each listed pair says that one person is associated with one event under a stated rule, such as confirmed attendance. Reordering the list changes its presentation, not who is listed. Adding an identical pair again does not create a new fact under set semantics. Invited, registered and attended describe different relations despite sharing two columns.

Worked example

Let the reviewer domain be {R1, R2} and the article domain be {A1, A2, A3}. Their Cartesian product contains 2 × 3 = 6 possible reviewer-article pairs. Define Reviews as {(R1, A1), (R1, A2), (R2, A2)}. This relation contains three of the six possible pairs.
Selecting tuples whose reviewer is R1 produces two pairs: (R1, A1) and (R1, A2). Projecting the original relation onto article produces {A1, A2}. Although A2 appears in two original pairs, it appears once in this set-valued projection. Listing (R1, A1) again would not increase the relation's cardinality beyond three.
The relation has arity two because each tuple has two roles, and cardinality three because it has three distinct tuples. It is not a function from reviewer to article: R1 is associated with two articles. Nor is it a function from article to reviewer, because A2 has two reviewers.
A3 does not appear in the relation. Whether that means no review is assigned or merely no assignment is currently recorded depends on the surrounding information model. The mathematical membership test and the interpretation of missing real-world knowledge must be kept distinct.

Illustrative case study

A fictional AI glossary team receives spreadsheets labeled Article and Reviewer. One department uses them for proposed assignments, another for accepted assignments and another for completed reviews. The files look compatible, so an initial report combines their rows and overstates review completion.
The team defines separate relations with explicit meanings and records the relevant workflow state. It also identifies repeated pairs that are duplicate records rather than separate review events. Where repeated rounds genuinely matter, it adds a round identifier to the model rather than relying on duplicate rows to carry unstated meaning.
The revised report answers a narrower, clear question about completed reviews. This invented case shows why table headings alone may not capture essential business distinctions.

Common misconceptions and mistakes

A relation is not necessarily a function, and it need not be symmetric or transitive. The number of attributes differs from the number of tuples. Duplicate SQL rows also differ from duplicate members of a mathematical set, where repetition adds nothing. Another mistake is confusing the schema with the relation's current contents. Finally, a missing tuple does not have one universal interpretation across every database or AI knowledge system; assumptions about completeness must be stated.

Business use

For an AI website, define relations using meaningful roles and a clear statement of what membership asserts. Reviews, proposed assignments and publication approvals may need distinct representations even when they involve similar entities. Decide whether multiple events require dates, round identifiers or other attributes. When preparing reports, specify whether repeated results should be retained or deduplicated. This makes counts interpretable and helps prevent a technically valid query from answering the wrong business question.

Check your understanding

How many possible pairs are in the example's Cartesian product?

Answer: Six.

How many belong to Reviews?

Answer: Three.

What is its arity?

Answer: Two.

Why does projection yield only two article values?

Answer: Set projection retains distinct members.

Why is Reviews not a reviewer-to-article function?

Answer: R1 has two associated articles.

Related terms

Tuple
Domain
Schema
Cartesian Product
Predicate (logic)
attribute
relational algebra
predicate
function

Learn next

Extend the example with a review-round attribute. Compare counting distinct reviewer-article pairs with counting completed review events, and explain why the answers can differ.

Sources

Poole and Mackworth, Artificial Intelligence: Foundations of Computational Agents, Relations and the Relational Algebra: https://www.cs.ubc.ca/~poole/aibook/3e/html/ArtInt3e.A1.S4.html PostgreSQL, historical mathematical exposition: https://www.postgresql.org/docs/7.0/sql26902.htm PostgreSQL 18, Select Lists: https://www.postgresql.org/docs/18/queries-select-lists.html The reviewer dataset and publishing case are original illustrations. Historical documentation supports the mathematical definition, not current product support claims.

Previous: Relatedness Next: Relation extraction