Re: Terminology for composite attributes

B-17 wrote:
> dawn wrote:
> >
> > Yes, this is something I do regularly, with little effort, as do
all
> > those working with XML or older models.
>
> Sounds like you're talking about the pick/universe/unidata/whatever
> model.

Yes, that is where I "live" (but not my only interest) -- there are many others. I think that the Cache' (or mumps-based) data model permits multivalues as well. I wouldn't be surprised if sleepcat.com products do too, as well as any databases that bill themselves as using an "XML data model". LDAP implementations use a tree model with multivalues. My interest is not only in pick, but graph-based data models.

>
> > > considering that it causes two new relations.
> >
> > in your logical model of choice, but not in mine. Date's new def
of
> > 1NF might also lead one to model multivalues in the same relation,
> but
> > most sql-dbms implementations would discourage it due to lack of
> > support in odbc/sql-92, for example
>
> If the "model" you speak of doesn't cause two new relations, there's
> something wrong.
>
> And what the heck is Chris Date's "new" definition of 1NF?

Off-topic story: I had a major setback in my database work with my purse and computer stolen from the trunk of my locked rental car at a hotel near the zoo in Washington DC recently. With no excuses (and tons of them) for why I didn't have a current backup and why the older backups are not usable (ugh!) on my little sony picturebook ... anyway, it is all very traumatic, but I have a point:

I no longer have Date's most recent def of 1NF (which I think was in a paper I downloaded for $10 from the dbdebunk site), so if anyone else does have it, could you post it for both me and B-17?

> I haven't
> seen it, or anything from him, that would promote multivalued
> attributes.

His terminology is "relation-valued attributes" so he doesn't have ordered lists, as pick and others do, but does have multiple "scalar values" (by old defs of "scalar") in a single attribute that has a type of Relation.

> The very concept is anti-normalization and should make
> every DB professional nauseous.

and then there is me -- delighted with this turn of events ;-) (and more where I came from, but most are not inclined to stick their necks out in forums like this where relational theorists live). There are also many good scholars out there working on this very topic, some of whom might be reading this (and, if so, thanks for your work!).

I do remember that Date defines 1NF in a way that it is not possible to have a relation that is not in 1NF, so he is not against normalization.  You can still have relations that are not in any of the other normal forms, but by Date's definition of 1NF and of relation (which I posted a month or so ago) relations are necessarily in 1NF.

>From my research and experience, I am convinced that the software
development profession would be well-served to leave RDBMS's behind (in most cases, that is -- I'm guessing there are exceptions) and move on to graph-based data models. The writing I'm doing right now (with the research sitting on the computer that was stolen )-: is on this topic.

I'm hopeful that it will not be too long before relational theory and SQL are taught in our colleges as lessons in the HISTORY of database management systems. It won't go away any time soon, but I'd like to see SQL in the same category as COBOL -- in use, but typically not the choice for new development when all options are available.

I realize that I didn't give any rationale for my opinion in this posting, but I have tried to do so at times in previous ones, so I'll click to sent this anyway.

Cheers! --dawn Received on Sat Apr 02 2005 - 03:35:49 CEST