“Relation” versus “relationship” in RDBMS/SQL?

Question

Coming from question “Relation” versus “relationship”

What are definitions of "relation" vs. "relationship" in RDBMS (or database theory)?

Update:
I was somewhat perplexed by comment to my question:

"relation is a synonym for table, and thus has a very precise meaning in terms of the schema stored in the computer"

Update2:
Had I answered incorrectly that question , in terms of RDBMS, having written that relation is one-side direction singular connection-dependence-link,
i.e. from one table to another while relationship implies (not necessarily explicitly) more than one link connection in one direction (from one table to another)?

Answer 1

A RELATION is a subset of the cartesian product of a set of domains (http://mathworld.wolfram.com/Relation.html). In everyday terms a relation (or more specifically a relation variable) is the data structure that most people refer to as a table (although tables in SQL do not necessarily qualify as relations).

Relations are the basis of the relational database model.

Relationships are something different. A relationship is a semantic "association among things".

Answer 2

Relation is a mathematical term referring to a concept from set theory. Basically, in RDBMS world, the "relational" aspect is that data is organized into tables which reflect the fact that each row (tuple) is related to all the others. They are all the same type of info.

But then, your have ER (Entity Relationship) which is a modeling methodology in which you identify objects and their relationships in the real world. Then each object is modelled as a table, and each relationship is modelled as a table that contains only foreign keys.

For instance, if you have 3 entities: Teacher, Student, Class; then you might also create a couple of tables to record these 2 relationships: TaughtBy and StudyingIn. The TaughtBy table would have a record with a Teacher ID and a Class ID to record that this class is taught by this teacher. And the StudyingIn table would have a Student ID and a Class ID to reflect that the student is taking this class.

That way, each student can be in many Classes, and each Teacher can be in many classes without needing to have a field which contains a list of class ids in any records. SQL cannot deal with field containing a list of things.