Re: sql views for denomalizing

dawn wrote:
> Marshall Spight wrote:
> >
> > Second, a variety of authors advocate nested relations, either
> > not considering them to violate 1NF (Date et al) or not caring.
> > (Me, say.)
>
> I'm thinking of data that are already stuck in an RDBMS, so perhaps
> this can be done now.

There were some typos in the above sentences. It should be: "I'm thinking of data that have already had their value tremendously enhanced through the superior management facilities available in an RDBMS, so perhaps this can be done now."

There, I fixed it for you. And the total overall prejudiciality of the sentence didn't go up any, either.

> When
> developing an application, I will need to model the data for CRUD and
> model the data for a UI. I would like to use the same modeling
> techniques for both, rather than modeling the UI with grouping
> attributes (like "Address" including all components of such) and
> multivalues and the CRUD without such.

I ... I ... completely agree with this sentiment. (It's sort of disconcerting. :-) The value of nested structure is quite high.

> > > If the view is supposed to be the view of the data, then why do we have
> > > this 1NF restriction when we don't care about the other NF's in a view?
> >
> > I don't agree that we do. In theory.
>
> It seemed that we did in theory until very recently and, for the most
> part, we still teach a theory that says that all NF depend on getting
> data into 1NF the way it is defined by all SQL-DBMS's I have ever
> worked with.

As I already said, not everyone agrees with this. Date doesn't, for example, and he's a fairly visible person. Nor do I nor you, although we're both a lot less visible.

Some phrasings of 1NF say this, and some just say "no repeated groups." I've pretty much reached the conclusion that 1NF doesn't really mean anything and isn't grounded in any particular theory. With, say, 2NF, 3NF, and BCNF, you can point to the specific redundancy, and the specific update anomalies. Can anyone do that with 1NF? It just doesn't seem to fit with the other normal forms.

> OK, so is the Dataphor approach the way that SQL-DBMS's are moving, or
> is it unique? Is the industry in agreement that relational databases
> should have views that permit multivalues in the views? Are there
> target dates for this in any other SQL-DBMS?

SQL isn't really moving. I'm sure Joe would disagree, but I think it's true. I would certainly *not* expect SQL to be the source of any major change such as this. I wouldn't expect "the industry" to do it either. Change will happen because a single guy (where the "guy" may be male or female) or a pair of guys comes up with a cool new design for a language, the way Stroustroup changed the face of development by bringing OO features and generic programming to C, or the way Gosling did the same for GC and late binding. Probably this "new design" will be full of features we've been talking about here for years.

> If so, then onward to the next question -- is there anything in
> relational theory that would permit attribute names that span multiple
> attributes, such as address consisting of this, that, city, postCode,
> and the other thing?

That would not be an "attribute name that spans multiple attributes." That would be a recursively defined type used in a relation. And the better question is, in my mind, is there anything in relational theory that forbids it? And the answer is no, outside of the paper-thin 1NF barrier, which you and I and various others have argued is not part of theory.

> Is there any implementation of a relational model
> or a SQL-DBMS that permits this?

Doesn't dataphor?

Marshall Received on Sat Jul 30 2005 - 21:54:27 CEST