Re: The term "theory" as in "database theory"

On Jan 30, 6:55 am, "JOG" <j..._at_cs.nott.ac.uk> wrote:
> I just don't see the point of this thread yet Dawn. Obviously there is
> an agenda there, so If we can clarify what it is, perhaps it can be
> discussed? Why not put those cards on the table - are you intending to
> say:
>
> 1) MV representations are preferable to RM because MV appeals to
> occams razor.

Nope.

> 2) RM appeals to occam's razor, indicating that in your opinion as a
> set based MV-crusader, occam's razor is wrong in this case

Nope.

> 3) Others who have said RM as "a theory as a whole" (I have never seen
> such a quote but there you go) appeals to occam's razor are
> misapplying it.

Yes. I have read at least two articles from Date and I think also something from Pascal that appeal to Occam's Razor. At least one indicated that this was some type of proof that the relational model, particularly the information principle, were golden--there was no chance they could be replaced by anything simpler. I also recall the argument that sets are simple and graphs (or networks) are not as an argument for the relational model being repeated in various ways over the years.

I do not think this argument holds water, and I suspect that most would agree that this is not a logically tight argument for the relational model at all. I also think that it is a misapplication of Occam's razor and thought that others would agree, but am not quite understanding the response. Is Occam's razor applicable to relational theory? I do not think so. I do not think that we are talking about observing something so much as making rules for something. However, if we do think that the relational model is an explanation of facts or a model of something observable in the natural world, then it would apply.

I asked about our use of the term "theory" in relational theory to get an idea of whether people think it is like defs 3-5 (which is how I see it) or if we think that database theory is observing the great database in the sky or something that we can study and then try to explain with a mathematical model. If so, then Occam's razor, an unprovable rule of thumb, could be appealed to. This would be using "theory" as in Def 1 in the OP.

If you agree that Occam's razor does not apply to relational theory, that does not mean that we ought not care about simplicity. While we might want to aim for the simplest overall solution that meets a set of requirements, that does not mean that everything about the solution (for example, the database theory employed) must be the simplest. When a user has suggestions related to ease-of-use, we sometimes do hand stands (add complexity) in order to accomplish this simplicity. Similarly, there is no heuristic that would suggest that software developers should model data with sets instead of maps or graphs when doing so might make the overall solution simpler.

> I have said several times now that in the case of databases a much
> apter "a theory should be as simple as possible, but not one bit
> simpler" so be sure to mention that in your blog post that all this is
> clearly leading up to ;)

Wasn't thinking of writing on this topic right now, just doing some research trying to understand this discipline. [I am hoping to write up some guidelines for modeling data using an NF2 data model, so feel free to pass along any suggestions for that ;-) ]

But your statement above is the statement I have oft heard and the one I am refuting. I think it is a very good rule of thumb when talking about a theory of some observable phenomenon that we choose the simplest explanation, but no simpler. However, we are talking about a theory that provides rules and steps for modeling data in order to create something (software). This is the def 3-5 theory, not def 1 theory. There is no rule of thumb that says that when we build something, we should choose the simplest building blocks even when that might prompt us to do more difficult work elsewhere.

So, for example, the fact that we can use that-which-was-once- termed-1NF for persisted text-based data, plus the fact that such sets are simpler than those which include NF2 data together do not imply, even using a rule of thumb, that we should use this construct. That is what I am trying to get to -- this simplicity thing is a false argument in this case. When crafting a house, as with crafting software, we can often use simple components, but at times a sweet but more complex component is just what it takes to make the overall construction simple.

> FWIW one can nevertheless still employ
> occam's razor to suggest, for example, why one should address by value
> and not by an OID.

How does that argument go?

> And remember that in the end Occam's Razor is only
> a guiding heuristic.

Yes, agreed, but it seems a good heuristic related to mathematical models of observable phenomena. I don't think it is a heuristic for the components of any constructions, including software. It might be another good rule of thumb to write the simplest code/solution that meets the requirements for any software, but that has nothing to do with Occam's razor, unless I am misunderstanding Occam's razor when I think it is applicable to theories as in Def 1 in the OP and not to the others. Am I making any progress with this point or could you point me to which aspect of this I have wrong? Am I misunderstanding Occam's razor or what a "database theory" is, for example? Thanks. --dawn

> Jim.
Received on Tue Jan 30 2007 - 18:56:11 CET