Re: Stored fields ordered left to right

"Adrian Kubala" <adrian_at_sixfingeredman.net> wrote in message news:slrnc08l1g.7ib.adrian_at_sixfingeredman.net...
> Dawn M. Wolthuis <dwolt_at_tincat-group.com> schrieb:
> > "Adrian Kubala" <adrian_at_sixfingeredman.net> wrote:
> >> It can't be the same mapping, as proven by example; the 3-part
predicate
> >> "person LIVES AT place DURING time period" has an obvious mapping to
the
> >> columns of a relation. To which parts of this predicate do the DOMAIN
> >> and RANGE of a function correspond?
> >
> > A predicate would look like this:
> >
> > person IDENTIFIED BY id LIVES AT place DURING time period
> >
> > I'll name the function using the plural rather than singular (for
reasons I
> > won't go into and of course there are differences of opinion on this)
and
> > the function is
> >
> > PEOPLE(id) = { (place, time period) }
>
> That's wrong because one person can live at many different places at
> different times. So you need to map each person to a list of tuples --
> in which case you have hidden the information necessary to make queries
> like "who all has every lived at this place" -- or you need to use a
> null range, in which case the range of the function is modelling nothing
> and is useless baggage.
>
I didn't take into account an entire specification. A typical implementation of one person living at different places, not taking into account past addresses might be modeled as:

PEOPLE(id) = { (place, start date, end date)* } where date is month/day only if it is an annual date and is month/day/year or as PEOPLE(id) = { (place, start date, end date, annual start, annual end)* }

No matter how you cut it, you are mapping something to something else.

> The point is that in most interesting relations there is no obvious way
> to split the predicate into TWO parts where one is more important than
> the other; you have N parts which are all equally-important.
>
> I still haven't heard (or overlooked) your explanation of why you think
> that whatever rationalization lead mathematicians to invent relations as
> a separate concept from functions does not apply just as well to
> databases? They're too abstract?

It is not a matter of being two abstract but the fact that with computers we are just talking about applying functions (processing) to objects. If we want to go into depth on objects that are relations and are not functions for some particular application, it is fine to define an object that is a relation, but I have never seen any need for that with retrievable stored data since by nature of it being accessible, it almost always (?can you think of cases this is not true) can be easily represented as a function operating on a key or reference id of some sort to retrieve the data.

While there are many types of propositions that are difficult to encode in an RDBMS and easy to encode in implementations of the Nelson-Pick model. These include, but are not limited to, multivalued attributes. How often to those implementing a relational model have to think hard about whether to pull out an attribute because it is possible or likely that in the future one might want to have more than one of 'these' for this entity. Even today, with cell phones having been out for over a decade, I've had someone tell me on the phone that their system permitted one phone number for home and one for business, but didn't have a spot for an additional phone number. This is highly unlikely in a system where cardinality of attribute values can be changed with the blink of an eye from 1 to a variable (not fixed number) "many".

So, where I have seen no instances that cannot be modeled equally well with functions as with relations, I have seen many times when a flexible function is a much better way to model the propositions.

Take some example propositions:

Hope has a cat named Geneva and a dog named Rugby. Shanna has no pets, but did have a dog named Monte who died in 2002.

Given only these statements, I might immediately come up with something like this:

a function named PEOPLE and the assignment of an arbitrary (or sequentially assigned) id for each person
PEOPLE("12345") = { "Hope", { ("cat", "Geneva", NULL) , ("dog", "Rugby", NULL)} }
PEOPLE("12346") = ( "Shanna", { ("dog", "Monte", "2002") } }

I've modeled this with a single function and I think I can even leave out telling you the metadata (although I wouldn't typically) because this so closely models the way we speak and think about these propositions. Now take these same propositions and model them with a relational model. This would require at least two relations and the act of splitting up these propositions into two separate propositions adds to the complexity for both the developer and unfortunately typically also for the end-user trying to do queriest, without any noticable gains.

Or am I wrong? Thanks. --dawn Received on Wed Jan 14 2004 - 01:03:23 CET