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.