Re: Relational and multivalue databases

"Eric Kaun" <ekaun_at_yahoo.com> wrote in message news:nnaZb.13694$3Z3.12356_at_newssvr31.news.prodigy.com...
> "Dawn M. Wolthuis" <dwolt_at_tincat-group.com> wrote in message
> news:c12vqr$a2k$1_at_news.netins.net...
> > "Mikito Harakiri" <mikharakiri_at_iahu.com> wrote in message
>
> > You got it -- simple, right? It's just a function that represents a
> graph.
> > We could call it a web! But on the outside to the user, it is a
> vocabulary
> > with functions (also part of the vocabulary).
>
> Isn't it a tree or hierarchy rather than a graph?

A tree is a special case of a graph. Yes, this can be modeled as a tree graph or it can be modeled as a graph that is not a tree, with or without cycles, once the links are made more explicit (and they are just functions and represent connections from one node to another). It is a di-graph (directed graph).
>
> > How do you decide whether info is a sub-table of an existing table or
> should
> > go in its own table? If the information is functionally dependent.
>
> Normalization is based entirely on this same principle, so this should be
an
> interesting point of comparison.

Yes, indeed. In fact, data normalization without 1NF works from my perspective -- it is 1NF that is very flawed. With the definition of each subsequent normal form including that the data must be in 1NF has a domino effect of corrupting the whole lot of these rules, however.

> > My phone numbers are information that one might think of as being in the
> > relationship between me and the telecom industry. But my phone numbers
> have
> > no meaning apart from me -- sure they are phone numbers that exist in
the
> > world, but the point of capturing the data is to capture information
about
> a
> > person.
>
> The phone numbers could have a great deal of meaning, and nesting them
> limits you unnecessarily. I can think of much better examples from my
> experience, but this one is more obvious and accessible. If I wanted to
> keep, for example, a phone record for each employee (what outside numbers
> they called), I'd then have to move the data, right? Since they're "only"
> attributes, the moment I want to enrich them (i.e. I think of any other
> predicate that involves them, other than "Joe Blow has phone number
> 123-456-7890"), I need to change my model.

Oddly enough, this is where the model excels -- first of all, in your example, outgoing calls (rather than "phone numbers") is quite a different matter and could very well warrant a separate table without changing anything about what the phone numbers (and e-mail addresses for that matter) are that refer to this person.

Additionally, it is changes to the data that are very easy in PICK. If you need to change the cardinality of any field (column-ish) in any file (table-ish), you just do it. Sometimes nothing at all need changing to coorespond, but often an input screen needs a field attribute changed along with the field attribute in the file. Sure it would be better if these were in synch, and I'm sure some tools have that, but it is not standard in implementations. Anyway, if you have a report that asks for a person and their phone numbers when the phone number was single-valued (which it was in many systems in the 70's and 80's) and then you permit multiple values for the phone number, the report prints out the new phone numbers too, without any changes.

>
> Functional dependency as you've illustrated it (not that espoused in
> relational theory / first-order predicate logic) is in the eye of the
> beholder, and in any system I've ever worked on, that changes. Different
> people see different parts of the DB, and different people consider
> different predicates ("entities", if you must) to be central. The local
> telecomm guy might want an application to look at phone usage, and to
enable
> multiple people to share a line - then the number itself (actually a
> connection, not necessarily a number) becomes "central."

Exactly! This idea of democracy of data is silly - data has meaning. If it didn't, then there would be no attributes for entities -- everything would be a top level entity. If the phone company system is added to the database then a link between their phone numbers and the people who have them could be made without harming anything at all (add a link to the person web page to navigate you to the info for the telco about that phone number and a link set to the telco system that shows all people associated with a phone number if desired)
>
> In relational, your model needn't change. And you haven't spent much time
> setting it up right, in my opinion - we're talking about a few extra
tables
> for a huge flexibility advantage.
>
> > Make sense? --dawn
>
> Not yet...
>
> - erk

Well, did that help or not? --dawn Received on Fri Feb 20 2004 - 00:55:51 CET