Relation Definition

I'll try this another way (persistence is my middle name?). I use a precise
definition of "relation" from mathematics. It is in the glossary mAsterdam
collected that I sent out a few days ago. However, it seems that most folks
here use some other definition(s) of the term. When I try to get precision
with this other definition, I find as many different definitions as there
are writers. These are often not just other ways of saying the same thing,
but really different definitions of what a "relation" is. I would like to
know which ones are typically used by practitioners and/or theorists. It
would be great if there were some general agreement on the definition, but
I'd settle for having to work with 2-3 if needed.

Is this one from Date the best in the industry? Can anyone suggest a better
one?

Date, C. "An Introduction to Database Systems", Addison Wesley 2004, p. 146

" A relation value (relation for short), r say, consists of a heading and a
body[4], where:

--The heading of r is a tuple heading as defined in Section 6.2. Relation r
has the same attributes (and hence the same attribute names and types) and
the same degree as that heading does.

--The body of r is a set of tuples, all having that same heading; the
cardinality of that set is said to be the cardinality of r. (In general,
the cardinality of a set is the number of elements in the set.)"

Note: definitions of "relation type" and "relation type name" follow this
definition.
This definition relies on the definition of "tuple" and "tuple heading".
Since his definition of "tuple" is also not the definition of a mathematical
tuple, we also need to understand that from the below definition:

p. 141 "Given a collection of types Ti (i=1, 2, ..., n), not necessarily all
distinct, a tuple value (tuple for short) on those types--t, say--is a set
of ordered triples of the form <Ai,Ti,vi>, where Ai is an attribute name, Ti
is a type name, and vi is a value of type Ti, and:
--The value n is the degree or arity of t
--The ordered triple <Ai,Ti,vi> is a component of t.
--The ordered pair <Ai,Ti> is an attribute of t, and it is uniquely
identified by the attribute name Ai (attribute names Ai and Aj are the same
only if i=j). The value vi is the attribute value for attribute Ai of t [1]
The type Ti is the corresponding attribute type.
--The complete set of attributes is the heading of t.
--The tuple type of t is determined by the heading of t, and the heading and
that tuple type both have the same attributes (and hence the same attribute
names and types) and the same degree as t does."

I'm thinking that def must be done at this point, and "tuple type name" is
defined immediately following this quotation.
This definition (of tuple) depends at least on the definition of "type" and
it wasn't so easy to zero in on a definition from the text, so I'll quote
what I think is the best I can find in this book:

p. 111 "The data type concept (type for short) is fundamental; every value,
every variable, every parameter, every read-only operator, and in particular
every relational attribute is of some type. So what is a type? Among other
things, it is a set of values.
....
"We are trying to be reasonably precise in this part of the book.
Therefore, instead of saying that, for example, type INTEGER is the set of
all integers, we ought really to say that it is the set of all integers that
are capable of representation in the computer system under consideration...

Any given type is either system-defined (i.e., built in) or user-defined.
.... Any type whatsoever, regardless of whether it is system- or
user-defined, can be used as the basis for declaring relational
attributes..."

Since I haven't found where the rest of any such definition is in this book,
I think perhaps we can just use the definition that a type is a set of
values. The rest of this is descriptive and we would not want the term
"relational" in the definition so we avoid a circular definitions.

You can perhaps see why I work with the definition of a mathematical
relation & mathematical tuples instead, but I really would like to know what
database folks mean by these terms. If I want a very precise definition of
relation as database relational theorists use the term, is this the best
that the discipline has to offer?

Thanks in advance. --dawn

"Dawn M. Wolthuis" wrote
 > I'll try this another way (persistence is my middle name?). I use a
 > precise definition of "relation" from mathematics. It is in the glossary
 > mAsterdam collected that I sent out a few days ago. However, it seems
 > that most folks here use some other definition(s) of the term. When I try
 > to get precision with this other definition, I find as many different
 > definitions as there are writers. These are often not just other ways of
 > saying the same thing, but really different definitions of what a
 > "relation" is. I would like to know which ones are typically used by
 > practitioners and/or theorists. It would be great if there were some
 > general agreement on the definition, but I'd settle for having to work
 > with 2-3 if needed.
 >
 > Is this one from Date the best in the industry? Can anyone suggest a
 > better one?
 >
 > Date, C. "An Introduction to Database Systems", Addison Wesley 2004, p.
 > 146
 >
 > " A relation value (relation for short), r say, consists of a heading and
 > a body[4], where:
 >
 > --The heading of r is a tuple heading as defined in Section 6.2. Relation
 > r has the same attributes (and hence the same attribute names and types)
 > and the same degree as that heading does.
 >
 > --The body of r is a set of tuples, all having that same heading; the
 > cardinality of that set is said to be the cardinality of r. (In general,
 > the cardinality of a set is the number of elements in the set.)"
 >
 > Note: definitions of "relation type" and "relation type name" follow this
 > definition.
 > This definition relies on the definition of "tuple" and "tuple heading".
 > Since his definition of "tuple" is also not the definition of a
 > mathematical tuple, we also need to understand that from the below
 > definition:
 >
 > p. 141 "Given a collection of types Ti (i=1, 2, ..., n), not necessarily
 > all distinct, a tuple value (tuple for short) on those types--t, say--is a
 > set of ordered triples of the form <Ai,Ti,vi>, where Ai is an attribute
 > name, Ti is a type name, and vi is a value of type Ti, and:
 > --The value n is the degree or arity of t
 > --The ordered triple <Ai,Ti,vi> is a component of t.
 > --The ordered pair <Ai,Ti> is an attribute of t, and it is uniquely
 > identified by the attribute name Ai (attribute names Ai and Aj are the
 > same only if i=j). The value vi is the attribute value for attribute Ai
 > of t [1] The type Ti is the corresponding attribute type.
 > --The complete set of attributes is the heading of t.
 > --The tuple type of t is determined by the heading of t, and the heading
 > and that tuple type both have the same attributes (and hence the same
 > attribute names and types) and the same degree as t does."
 >
 > I'm thinking that def must be done at this point, and "tuple type name" is
 > defined immediately following this quotation.
 > This definition (of tuple) depends at least on the definition of "type"
 > and it wasn't so easy to zero in on a definition from the text, so I'll
 > quote what I think is the best I can find in this book:
 >
 > p. 111 "The data type concept (type for short) is fundamental; every
 > value, every variable, every parameter, every read-only operator, and in
 > particular every relational attribute is of some type. So what is a type?
 > Among other things, it is a set of values.
 > ...
 > "We are trying to be reasonably precise in this part of the book.
 > Therefore, instead of saying that, for example, type INTEGER is the set of
 > all integers, we ought really to say that it is the set of all integers
 > that are capable of representation in the computer system under
 > consideration...
 >
 > Any given type is either system-defined (i.e., built in) or user-defined.
 > ... Any type whatsoever, regardless of whether it is system- or
 > user-defined, can be used as the basis for declaring relational
 > attributes..."
 >
 > Since I haven't found where the rest of any such definition is in this
 > book, I think perhaps we can just use the definition that a type is a set
 > of values. The rest of this is descriptive and we would not want the term
 > "relational" in the definition so we avoid a circular definitions.
 >
 > You can perhaps see why I work with the definition of a mathematical
 > relation & mathematical tuples instead, but I really would like to know
 > what database folks mean by these terms. If I want a very precise
 > definition of relation as database relational theorists use the term, is
 > this the best that the discipline has to offer?
 >
 > Thanks in advance. --dawn

This is not directed at you Dawn - but whatever happened to the KISS
principle. Personally I usually suspect elaborate definitions (for a
concept that would appear to me to be simple) as coming from high church
adherents. My two bob's worth. Frank<!-- ~MESSAGE_AFTER~ -->