Re: A database theory resource - ideas
Date: Sat, 17 Mar 2007 02:25:35 GMT
Message-ID: <zkIKh.1762$FS5.917_at_trndny09>
"Bruce C. Baker" <bcbakerXX_at_cox.net> wrote in message
news:YbFKh.9320$Ng1.5772_at_newsfe19.lga...
>
> "Marshall" <marshall.spight_at_gmail.com> wrote in message
> news: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?
> >
>
> Lots and lots of simple, tightly-focused examples. Think "RDBMS for
> Dummies"! :-)
>
I have a bias against the "for dummies" series of books. When I open a book to learn something, I'll easily admit to ignorance. I don't expect to label myself as stupid. I don't I don't think an author who confuses those two is doing me any favors.
Sometimes I look for books "for dummies" in the bookstore, just to amuse
myself.
My favorites:
Bridge for Dummies.
Pregnancy for Dummies.
Aristotle for Dummies.