Re: A database theory resource - ideas

From: Marshall <marshall.spight_at_gmail.com>
Date: 16 Mar 2007 08:43:06 -0700
Message-ID: <1174059786.343994.223430_at_d57g2000hsg.googlegroups.com>


On Mar 16, 6:58 am, "JOG" <j..._at_cs.nott.ac.uk> wrote:
>
> So my question to cdt is to ask what /you/ believe the priorities for
> such a resource would be?
> - which pivotal questions are most misunderstood?
> - where does most ignorance lie in our field?
> - are there are any crucial topics that you believe it would be useful
> to address that I have not listed.

My suspicion is that such a body of information would be able to grow for a long time. That is, I wouldn't think it would be particularly important to try to identify all the topics up front.

That said, here are some of my thoughts:

The purpose of normalization is the elimination of update anomalies, not space savings. (Dammit!)

A Guide to the Normal Forms. These were hard for me; when I first started reading about them, the best information I could find generally plops you down in the middle of a bunch of fairly abstract statements about functional dependencies etc. and I had a really hard time linking it to anything familiar. It would be cool to have something that lists what all the functional dependencies are, identifies what the important ones are, and focuses on them. (BCNF, anyone?)

Re:
> That Data models involve not just structure, but also manipulation
and integrity.

I'd go further and emphasize that structure is in fact the least and the easiest of these.

And how about an explanation of the term "query bias?" That one really took me a long time. In fact in general I find that, lacking the long-term exposure to data management and lacking the educational background in same, that a lot of the terms in the data management field are opaque. And like in most fields the terms tend to get used with the assumption that the listener already understands the terms and their long history!

In fact I came to my first deep understanding of the fact that hierarchies can only organize around one dimension after wrestling with a particular tree in a particular app for a long time. I think this could be explained, with examples, in a way that was quite useful.

A quick thought: it might be desirable to use examples that aren't customers/invoices or suppliers/parts. I think this contributes to the overall impression that RM is only for accounting applications. There might be some advantage to playing against type, like when Robin Williams plays the bad guy. Maybe a database of MP3s or something?

Also: crappy writing is easy; good writing is hard. I think making this worthwhile will require some nontrivial investment. I am imagining a closed-edit wiki, maybe?

Marshall Received on Fri Mar 16 2007 - 16:43:06 CET

Original text of this message