Re: Stored fields ordered left to right

From: Dawn M. Wolthuis <dwolt_at_tincat-group.com>
Date: Tue, 13 Jan 2004 22:06:25 -0600
Message-ID: <bu2f83$7k3$1@news.netins.net>

Goodness Gracious -- way too many typos in that previous post of mine since I did it hastily and didn't proof it before sending. My apologies, but I trust that you can make your way through it. In case you prefer to read a cleaner version, I've cleaned it up below. --dawn

"Dawn M. Wolthuis" <dwolt_at_tincat-group.com> wrote in message news:bu210h$qq9$1_at_news.netins.net...
> "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.
> >

The following is "cleaned up"

> 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 otherwise 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 too 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. By nature of the data 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.

>

> 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
do
> those implementing a relational model have to think hard about whether to
> pull out an attribute into a separate table because it is possible or
likely that in the future
> one might want to have more than one of 'these' attributes 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 number "many"
(not fixed
> number).

>
> 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. The act of splitting up these
> propositions each into two separate propositions adds to the complexity
for both
> the developer and, unfortunately, typically for the end-user trying to do
> queries. This complexity is introduced without sufficient gains, in my
opinion.

>

> Or am I wrong? Thanks. --dawn

>
> Received on Tue Jan 13 2004 - 22:06:25 CST