Re: A database theory resource - ideas
Date: Fri, 16 Mar 2007 22:24:58 -0500
Message-ID: <9cJKh.3030$nh4.2956_at_newsfe20.lga>
"Walt" <wamitty_at_verizon.net> wrote in message
news: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.
In retrospect, "... for Dummies" was perhaps not the happiest title choice. And did they have to make the covers /bright yellow/? :-)
>
> 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.
"Sex for Dummies" (The 3rd ed.! The mind boggles ... :-) )
>
> On a more serious note, what I find wrong with the approach of lost of
> simple tightly focussed examples is that, generally, what the author
> underestimates is my capacity for abstraction. Making the same point over
> and over again with lots of examples is like denormalizing the data, and
> storing the same fact in multiple places.
>
> Well chosen examples don't suffer from this, I'll admit. But well chosen
> examples tend to be mutually orthogonal.
>
>
I could definitely support a few well-chosen examples over many mediocre ones. Received on Sat Mar 17 2007 - 04:24:58 CET