Re: A database theory resource - ideas

JOG wrote:
> I found one of the most interesting parts in a gargantuan recent
> thread was the listing of priorities for reaching a certain audience
> and determining what one wants to get across (Thanks to bob for that.
> You may object to his style but I've found there can be lot of value
> in his posts).
>
> Anyhow I have discovered a lot over the last year since my arrival,
> and as such I often feel the urge to contribute back to general
> knowledge in the field. So with the loss of sites such as dbdebunk and
> the general lack of a simple central resource for database theory I am
> intending to put together a form of FAQ site. Hopefully this will be
> useful to reducing retro-activity in the field, as well as being a
> useful educational resource. Additionally any audience is self-
> selecting and this can only ease a lot of the frustrations I have in
> trying to convince those in entrenched positions of advancements over
> the last few decades. Perhaps it may even provide a reference link for
> common arguments that continually arise. Who knows.
>
> Anyhow I am initially aiming to concisely cover the following topics:
>
> * The vital nature of separating conceptual/logical/physical layers in
> data modelling
> * Working in terms of Propositions and not Objects
> * The argument against OID's (and hence for the information principle)
> * Why Navigation was replaced by Declaration
> * That Data models involve not just structure, but also manipulation
> and integrity.
> * Why hypertext models are insufficient (due to irreducible tuples)
> (web 3.0 ... good grief)
> * What semistructured data is (or rather is not).
>
> I am planning to omit well covered ground such as eliminating
> redundancy and anomalies through normalization, simply referring to
> external links. Obviously all of the above has been covered somewhere
> in the literature, so the aim is rather to produce a central, concise
> and hence accessible resource as opposed to resorting to a text-book/
> academic paper format.
>
> The main purpose is to provide a purely educational resource, with as
> little impartiality as I can muster, constraining to established
> theory and facts, or clear logical arguments.
>
> 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.
>
> Any input is gratefully received.
>
> Regards, Jim.
>

I think the very exercise of arguing what are the pre-eminent topics is good. I say good for me, as my motive is not usually altruistic, eg., dispelling fallacies, rather just wanting to feel that anything I spend time on results in clearer thinking, which I think is synonomous with deeper understanding. For example, the physical/logical distinction you mention is so very important for efficiency in making implementations (which is sometimes different from making efficient implementations). Sometimes I imagine the IP is crucial for making the distinction, assuming that it constrains the possible operations.

When an engine has some feature such as OID's, I want to be able to say categorically that such is a physical feature and nothing to do with the logical aspect. Maybe I'm dreaming. The RM has been victim of the connotations of everyday words over the years, which I think wasn't Codd's intent - personally I think he chose his words to serve several purposes at the same time, knowing beforehand he was likely to be fighting an uphill battle. Somewhere in the second paper, he tips his hat to the idea of familiarity. Reminds me a little of a guy I knew who was introducing a certain product to people who had been using a very convoluted one. In frustration, he drew a jet plane (he had piloted them once) on the whiteboard, beside a hot air balloon. He ridiculed the customer's objections by drawing a gondola hanging below the jet plane and told them they couldn't have both.

p Received on Sat Mar 17 2007 - 00:17:34 CET