Re: Relational and multivalue databases

"Dawn M. Wolthuis" <dwolt_at_tincat-group.com> wrote in message news:c1brgh$ui9$1_at_news.netins.net...
>
> So, we have people and we have addresses with a M-M relationship. In a PICK
> model, the implementation would likely include a PEOPLE function and an
> ADDRESSES function (called "files").

If I understand correctly, your use of the word "function" here means a mapping from one set to another. In the PEOPLE case, it would be from something analogous to a primary key, to all the other attributes of a person. Yes?

Doesn't this mean that a Pick, uh, "file" is the same thing as an SQL relation with the restriction of only having one unique attribute? Again, I'm not sure I understand, but it sounds like another difference is that (no distinction is made | it's easy to change) in deciding if an attribute is single valued or set-valued. Does that mean that every attribute has zero-or-more values?

> The PEOPLE function would map to a
> list of ADDRESSES identifiers.

Among other things, one assumes?

> Two files with a link between them.
>
> Often the implementation would include return-links to improve performance
> if there would be queries not just about what addresses a person has, but
> also who lives at a particular address. Then extensions could be made to
> the vocabulary of each function so that queries like this would be the norm:
>
> LIST PEOPLE FULL-ADDRESSES
>
> LIST ADDRESSES FULL-NAMES
Okay, but this introduces all kinds of opportunities for inconsistent data. Is there anything keeping the two sets of data in sync? Is it automatic or manual?

> This is a different approach to creating a VIEW with COLUMNS from each TABLE
> against which the user would query. In the case of the RDBMS, we then come
> up with a new vocabularly for an entity, while often retaining the names of
> the attributes. PICK lets the user of the database think of each
> file/function as a portal into the database, increasing the language for
> that file/function but not altering the name of the file unless there is
> some purpose to doing so. Each "view" in PICK looks through the eyes of one
> of the implemented functions (files).
>
> This approach is much more like the web, where there are documents with
> links to other documents, which might then have return links to all docs
> that point to them. Part of the charm is in the simplicity of the approach.

I note that the web is a disaster from a data management point of view.

Marshall Received on Wed Feb 25 2004 - 04:53:09 CET