Re: Relational and multivalue databases

"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?

> 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.

> 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.

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."

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