Re: sql views for denomalizing

From: dawn <dawnwolthuis_at_gmail.com>
Date: 30 Jul 2005 14:13:11 -0700
Message-ID: <1122757991.621894.231550_at_g44g2000cwa.googlegroups.com>


Marshall Spight wrote:
> 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."

You are right -- my bad. In this particular case, unlike most of the others, I was unaware that I had made a negative statement. I spent enough time doing BI, that I think of data being stuck in databases, while I star schema it out of there.

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

Thanks. Perhaps a Marshall filter for all of my postings would serve me well :-)

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

Wow! What do I do now? Is it time to retire?

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

So we have a marketing issue, rather than a theory issue. I'll get on that.

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

WOW -- we are in COMPLETE AGREEMENT AGAIN! However "repeating groups", which used to be what 1NF aligned with, does mean something, right?

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

exactly and yet it is the ONLY one of the NF's that is dictated by many DBMS tools and text books.

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

it appears that way to me too, given that the committee adjourned indefinitely (or something like that).

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

The SQL standards have already attempted to address it, but few seem to care and I'm not sure that the solutions offered get me too excited anyway.

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

What is interesting to me is that I have already seen an environment that clearly (clear to me, that is) contributed to a much lower cost of ownership for software applications. It, too, lacks a ton of desirable features, and I'm not suggesting we return to a strictly pre-relational model, but I think it would be smart to start there and add in new features than to start with a SQL-DBMS. We would not be saddled with a 3VL, length constraints on attributes for arbitrary reasons, old-fasioned 1NF, etc. I'll grant that most people would prefer to start with Oracle, DB2, SQL Server, or even MySQL and make changes on top of that, but I think it would be enormously more difficult.
>
> > 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.

Hmm. I just mean something like

<name>
  <firstName>Henri</firstName>
  <lastName>Kachoeff</lastName>
</name>

Or, it's been a couple of decades for me, but something like

03 NAME.
   05 FIRST-NAME PIC X(18).
   05 LAST-NAME PIC X(30). Is that what you are suggesting brings in recursion?

> And
> the better question is, in my mind, is there anything in relational
> theory that forbids it? And the answer is no,

There is that rule that informally says that the only complex types supported are relations. Isn't that part of relational theory?

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

It might. I clearly am not up on that product. Of these four types of developers:

  1. Those who attempt to keep at least somewhat current in the MS s/w dev world
  2. Those who attempt the same in non-MS s/w dev (e.g. Java, etc)
  3. Those who keep a foot in both worlds
  4. Those who don't attempt to keep current

I'm a 2. It isn't a religious thing, just practical. So, I wish Dataphor didn't say .NET all over it. It might be good enough that I should move from a 2 to a 3, but I just can't fit that in right now, what with javascript, php, xhtml, css, xml, dtd, xsl, xquery, rss, dom, etc. i suspect I should not have taken that time figuring out jsf (java server faces).

cheers! --dawn Received on Sat Jul 30 2005 - 23:13:11 CEST

Original text of this message