Re: Stored fields ordered left to right

"Dawn M. Wolthuis" <dwolt_at_tincat-group.com> wrote in message news:<bsl23t$5ih$1_at_news.netins.net>...
> Do you agree, Bob, that relational database theory seems to require
> constructs that are NOT mathematical relations (because they have no logical
> ordering among attributes)?
>
> Do you also agree that some of the data models that are not considered by
> relational theorists to be relational are, in this way, actually MORE
> relational in that they do require logical constructs (ordered tuples) that
> correspond to mathematical relations?
>
> This is one of several issues I'm trying to square away or at least get a
> vocabulary that is not so contradictory. Thanks --dawn

To clear this very issue Date & Darwen define a relation in a relational database as a set of sets, each set consisting of a set triplets. For example, we could have the relation value

Person =
 {
   { (person_id, integer, 1), (person_name, string, 'Jill') },    { (person_id, integer, 2), (person_name, string, 'Joe') }  }

(the second component is there to allow for subtyping)

So, I guess, strictly speaking, you could argue that this is not really a relation. However, the distinction is superficial, since there is a simple mapping from this structure to a mathematical relation by just mapping each attribute name to an ordinal number, e.g.

Person_mapping = {(person_id, 1), (person_name, 2)} and simply obtain the "true" mathematical relation

Person_math =
  { (1, 'Jill'), (2, 'Joe') }

or, if you want to include type information,

Person_math =
  { (1, integer, 'Jill', string ), (2, integer 'Joe', string) }

Given a certain ordering there is a trivial 1:1 mapping from the value of Person to the value of Person_math.

Since the ordinal position is immaterial for the user (or it should be) we can assume any order of attributes, and, hence, just forget about the whole issue.

The conversion from the "Codd" or "D&D" "relation" to the mathematical relation is (logically) done by the system. Note, that all relational operators (UNION, PROJECTION, RESTRICTION, etc..) are expressed very simply even with these "relational database relations" and the mapping to the corresponding mathematical operations is trivial.

The reasons (in my view) why Codd got rid of ordinal positions in his definition of a relation in a relational database were

1. so as not to burden the user with ordinal positions (e.g. column number 87, instead of, say, column named 'discount')
2. to not imply that the system actually stores the values in a certain order (=the system is free to map the columns to physical storage as it wishes)

However, there is no easy mapping between SQL-tables and mathematical relations.
Take the SQL-table

SQL-Person

person_id person_name
--------- -----------

1           Joe
1           Joe

In order to get a mathematical relation out of this we have to number the duplicates, or include some hidden values in the original table. However way this is done, it complicates the mapping.

best regards,
Lauri Pietarinen Received on Sun Dec 28 2003 - 08:56:58 CET