Kjell,

'Relation' is a term borrowed from mathematics. A relation is a set of points (tuples) in N-space.
Each point has N attributes, each one containing a value from a given domain. A relation is a
subset of all such possible points, which you can get through a cartesian product (thus a cartesian
space is the set of all possible points in the given dimensions.)

http://en.wikipedia.org/wiki/Relation_(mathematics)

'Domain' is also a term borrowed from mathematics, and simply means "set of possible values."

'Table', 'row', 'column' are associated with spreadsheets, where order matters. In a set, only
uniqueness matters. Attributes (columns) must be unique, but need not have an order. Tuples (rows)
must also be unique, but need not have an order. Tables imply a "two-dimensional" representation
(you'll often hear anti-relational-database zealots claim that relational databases are two-
dimensional) when in fact relations are N-dimensional.

The relationship between tables, defined in foreign keys, is actually a constraint, and is
therefore part of "the domain of the relation variable" -- that is, the constraint on the variable
that determines what relation values in may contain. Every change to the table must result in a new
relation value that matches this constraint. But this is not where the term 'relation' comes from.

A relational database is required (by EF Codd) to contain only variables whose values are of a
relation type. There are relation-variables, relvars. (Similarly, a 'database' should be a value,
and a database-variable should be the named thing that holds such a value, and conforms to the
database-variable's constraints -- database constraints.) So there should be domains that
are "possible relations" and "possible databases" (schema?), and we should be creating variables
with those domains ...

But because it's so rare to have multiple variables of the same type in a database (most of us, I
think, avoid making several tables with exactly the same definition) the type of the variable
(defining its attributes, etc.) and the variable itself (the name) get merged. And because there's
only one variable of a specific type, there's also only one value at a time -- so the value (the
relation) gets directly associated with the type and name of the variable (the relation-variable,
the table.) That's why 'relation' gets used to mean both the value and the variable sometimes.

So, why use those terms? They're more correct, they remind us that relational databases (unlike
certain other types) are grounded in sound mathematical theory (set, predicate theory) and they
avoid confusion stemming from spreadsheet-mentality. But they do sound a wee bit high a mighty,
yes, and still get misused on occasion.

There. Pedantic enough?

-Philip

---------- Original Message -----------
From: Dennis McFall <dennis@...>
To: firebird-support@yahoogroups.com
Sent: Fri, 17 Jun 2005 16:21:13 -0500
Subject: Re: [firebird-support]

> Kjell Rilbe wrote:
>
> >Ann W. Harrison wrote:
> >
> >
> >
> >>Alan McDonald wrote:
> >>
> >>
> >>>One contact table with 3 FKs into
> >>>the three master tables. For each relation, the other two FKs remain null
> >>>while the one FK is the key to the relation in question.
> >>>Now this obviously leads to high dups on the FK index.
> >>>
> >>>
> >>I'm probably confused by your use of "relation" - which to me equates to
> >>table, and seems to mean something else you.
> >>
> >>
> >
> >I've never been able to understand why "relation" is supposed to be a
> >synonym to "table" in relational DB lingo. To me it seems so obvious
> >that the "relational aspect" of relational databases is their ability to
> >relate *tables* with each other. So, the "relation" is not the table
> >itself - it's something "between" two tables (or a table and itself).
> >The relation is usually implemented as on or a set of columns in a
> >table, or in the M-M case as a separate table, but that's beside the point.
> >
> >Feel free to explain to me why "relation" is used like this in
> >relational DB lingo.
> >
> >Also feel free to kick my butt for bringing this up, since it might very
> >well be considered off topic.
> >
> >Kjell
> >
> >
>
> E.F. Codd came up with the concept of the "relational" data model in
> 1970, as an improvement on the existing "hierarchical" and "network"
> models. He defined a database as a collection of "relations," which
> could be represented as tables (rows,columns). Relational algebra uses a
> set of operations (selection,projection...). So, use of the term has a
> sound basis in the theory/history of SQL database.....
>
> --
> Dennis McFall
> ACEware Systems, Inc.
>
> ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
>
> Visit http://firebird.sourceforge.net and click the Resources item
> on the main (top) menu. Try Knowledgebase and FAQ links !
>
> Also search the knowledgebases at http://www.ibphoenix.com
>
> ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
>
> Yahoo! Groups Links
>
>
>

------- End of Original Message -------