Re: Theory IS Practical.

From: Kenneth Downs <firstinit.lastname_at_lastnameplusfam.net>
Date: Sat, 09 Oct 2004 15:47:55 -0400
Message-ID: <b9f9kc.oo1.ln@mercury.downsfam.net>

Laconic2 wrote:

>
> "Kenneth Downs" <firstinit.lastname_at_lastnameplusfam.net> wrote in message
> news:jks8kc.9nv.ln_at_mercury.downsfam.net...

>>
>> I am glad you brought this up.  I have been meaning to ask the question
>> "what is the relationship between theory and practice in computer

> science?"

>> It seems to me that there are some very large unstated assumptions in
>> this group about this relationship, which perhaps should come to light.

>
> Let me break it into parts:
>
> How much theory should you know in order to build a good DBMS?
>
> How much theory should you know in order to create a good database, given
> a good DBMS and good requirements?
>
> How much theory should you know in order to write a program that loads a
> good database with good data, and reacts gracefully to bad data?
>
> How much theory should you know in order to write a query against a good
> database that has been loaded with good data?
>
> I claim that each of these steps requires less theory than the one before
> it. If fact, I think people should learn these steps in the reverse
> order.
> I've never built a good DBMS, so I wouldn't be conversant with that level
> of theory. Some of the discussions in here are at exactly that level, or
> at least at the level of critiquing the DBMSes that have been built.

This is an interesting insight. But I would add that at the first couple of layers, where the need for theory is the greatest, the question is more about WHAT theory you should know. Your third level seems to be where we lose track of this, and impose the requirement for the first.

>

>> Finally we have the third relationship, which I posit is not valid but

> which

>> we see here.  This relationship jumps straight from free-floating

> axiomatic

>> systems to bridges.  A simplified example of this jump is "The RDM

> requires

>> sets instead of bags, and your system allows duplicate indistinguishable
>> row, ergo your system is *bad* *engineering*."  Huh?

>
> The only part I disagree with is the very last part. How about "ergo your
> system will be unable to distinguish between duplicate filled orders, and
> duplicate data entry of one order. Ergo, you will either lose money or
> alienate your good customers"? Isn't that more relevant?
>

Um, I think you just did what I was claiming is wrong, jumping from a description of which model was adopted (bags vs. sets) to the unconditional claim that the system will produce erroneous information. Perhaps I should have said that the acceptable claim would be "...ergo you will be unable to take full advantage of the RDM, but if you can ensure correctness by other means then so be it." Isn't the standard example of ok dups the cat food cans at the checkout lane?

>> >

>

>> How about the third half? This is information that cannot be stored in a

> 3NF

>> database such that information meaningful to human beings can be
>> retrieved without procedural code, such as hierarchies or the bipartite
>> matching problem?

>
> I guess I cop out on this one. I store data in a database, not
> information. I don't expect people who need information to go looking in
> a
> database. I expect processes that add value by turning data into
> information. I know that's a corny phrase, but I think it has real
> meaning.
>

>>
>> I find myself coming back over and over to the issue of derived data,
>> such
>> as extended price = price * qty.  If I am trying to satisfy a
>> mathematical theory, I will leave this out, but if I am trying to satisfy
>> human motives of convenience and correctness, I will find a way to store
>> it on save so that downstream users have a better time of it.

>
> Ok, here I go again! I harp on the subject of Star schemas as much as
> Dawn
> harps on 1NF. But I'm going to recommend that you look into one of Ralph
> Kimball's works on data warehousing, star schema, and the dimensional
> model. I thought I wouldn't find much of anything deep in there. I was
> wrong.

Ralph Kimball, will do.

-- 
Kenneth Downs
Use first initial plus last name at last name plus literal "fam.net" to
email me

Received on Sat Oct 09 2004 - 14:47:55 CDT