Re: RM and definition of relations/tuples

Jonathan Leffler wrote: 
Martin Zapf wrote:

vc wrote:

Martin Zapf wrote:

I have a question to the Relational Model and the definition of
relations and tuples.


I learned the following definitions:

A relation schema R is a set of Attributes R={A_1,A_2,...,A_n}
Each Attribute A has a domain dom(A)

Here comes the problem, there are two definitions for relations/tuples

1. defintion:

    A relation r for schema R is a mathematical relation (cartesian
    product) over the
    domains from the attributes of R.
    So r:=dom(A_1)xdom(A_2)x...xdom(A_n)
    A tuple is an element of r.

2. definition

    A relation r for schem R is a set of tuples.
    A tuple t is a function
    t: R -> Union (dom(A_1),dom(A_2),...,dom(A_1))
    t maps each Attribute of R to an value of its domain.
    So a relation is a set of functions, which are called tuples.

I noticed, that the difference between this two definition is that
definition 1 forces a certain order for the Attributes and the values
for them in the tuples.
The 2. definition doesnt need any order for the attributes.

Im quite confussed, is there a "better" definition or should you always
use both?



The first definition is closer to the "mathematical" relation where a
tuple is an *ordered* sequence.  The second definition is what database
folks prefer to use (see Codd, Date, et al) where a tuple is a *set* of
attribbute:value pairs.  One can be mapped to the other and I would not
worry too much about the difference unless you are doing some d.b.
theoretical research.


I also figured that out, a mathematical relations (subset of catesian product) is ordered because the elements of a cartesian products are ordered sets by definition.


I don't think so. The mathematical relation is an unordered set of ordered tuples. The cartesian product is a unordered set too - of ordered tuples to be sure.


You are right, I did describe that wrong. The cartesiaon product or relation itself is of course not ordered. Only the components inside their elements are ordered.

I think of an ordered tuple as one where the elements are implicitly named by index number (position in the tuple); in comparison, a tuple in the relational model has explicitly named elements, and therefore they form a set of elements (one reason you can't have several attributes with the same name) and do not need to be explicitly ordered. I find this analogy/contrast helpful; you may or may not find it so.

And yes I have to do some theoretical db stuff so Im asking myself:
If there are two definitions for the same thing, what is the universal valid and precise definition for the RM? This two definitions cant come out of nowhere, can they.


There are many definitions for many things. "Infinite are the arguments of mages" - a (mis?)quote from a sci-fi story. Similarly, different people in the DB world have different versions of the definition. There isn't any one universal truth.

.

Relevant Pages

  • Re: cdt glossary 0.1.0 [Relation]
    ... Am) formed by the Cartesian ... mathematical relation: ... matrix construction may include the Cartesian product, ... unordered set of n-attributes," ...
    (comp.databases.theory)
  • Re: RM and definition of relations/tuples
    ... A relation r for schema R is a mathematical relation (cartesian ... product) is ordered because the elements of a cartesian products are ordered sets by definition. ... I think of an ordered tuple as one where the elements are implicitly named by index number; in comparison, a tuple in the relational model has explicitly named elements, and therefore they form a set of elements and do not need to be explicitly ordered. ... If there are two definitions for the same thing, what is the universal valid and precise definition for the RM? ...
    (comp.databases.theory)
  • Re: RM and definition of relations/tuples
    ... >>> A relation r for schema R is a mathematical relation (cartesian ... >> 2 certainly seems on the money to me, but in the first definition I see ... > 'Database System Concepts, ...
    (comp.databases.theory)