Re: A database theory resource - ideas
From: Bob Badour <bbadour_at_pei.sympatico.ca>
Date: Fri, 16 Mar 2007 23:41:39 GMT
Message-ID: <TWFKh.11276$PV3.115808_at_ursa-nb00s0.nbnet.nb.ca>
>>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?
Date: Fri, 16 Mar 2007 23:41:39 GMT
Message-ID: <TWFKh.11276$PV3.115808_at_ursa-nb00s0.nbnet.nb.ca>
> "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 don't see how that will help anyone learn to think in the abstract. If one can only understand recipes, one can go work for a restaurant. Received on Sat Mar 17 2007 - 00:41:39 CET