Re: Stored fields ordered left to right
Date: Tue, 13 Jan 2004 22:06:25 -0600
Message-ID: <bu2f83$7k3$1_at_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.
>> > a separate concept from functions does not apply just as well to
> > 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
> > 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 Wed Jan 14 2004 - 05:06:25 CET