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

On Jan 26, 7:46 pm, "JOG" <j..._at_cs.nott.ac.uk> wrote:
> On Jan 26, 10:05 pm, "dawn" <dawnwolth..._at_gmail.com> wrote:
>
> > [snip]
> > > > 4. the branch of a science or art that deals with its principles or
> > > > methods, as distinguished from its practice: music theory.
>
> > > Now we have something, a description of a human pursuit. This makes as much
> > > sense as #5 below.
>
> > > > 5. a particular conception or view of something to be done or of the
> > > > method of doing it; a system of rules or principles.

> There you go. A combination of 4 & 5 seems like a definition that might
> apply best to cdt.

Sounds good. So, now, does Occam's razor apply to 4 or 5 at all? My understanding is that those who believe in Occam's razor, apply it to theories that align with definition 1. Is that your impression as well? I think we can completely dismiss this seemingly false argument related to relational theory, but I want to be sure.

> Look, its absolutely fine to take an MV view and
> investigate it - others have discussed it on here without producing
> mass offence, because they approach the subject theoretically and
> scientifically because they will back up their analyses with rules and
> principles, follow them through logically and mathematically, be
> concise, address the disadvantages they generate, etc. T

I'm attempting to be very precise on this point, including requesting the definitions of others so I do not assume anything I should not be assume. I'm going back to the arguments for relational theory and will address them logically. Although I have issues with relational theory, there is nothing in the mathematics of relational theory with which I disagree, so there are no mathematical argument for me to produce. Does that make sense from your perspective, or not? Is "database theory" entirely mathematics from your perspective? It doesn't seem like it would be if you take 4&5 as definitions for theory. We also need the part where we apply the mathematics and any other rules or priinciples to the subject matter. It is that aspect of database theory that interests me most.

> hey have no need to fear an uproar, because they keep their arguments
> free of business politics and crusades!

You must not be referring to the start of relational database theory, I'm thinkin' (or you might want to ask some CODASYL folks some questions about that). Perhaps relational theorists at the start also appreciated the words of George Bernard Shaw that I had next to my computer for many years:

"The reasonable man adapts himself to the world; the unreasonable one persists in trying to adapt the world to himself. Therefore all progress depends on the unreasonable man."

I realize that I'm an "end-user" of database theory, as well as a student. I am not an entirely satisfied user, and I do voice my concerns (rather than keeping them to myself). In my profession, when a user is dissatisfied, I listen carefully to their requirements and determine what is feasible to meet their requirements in line with all others (resources, for example). I don't know if those who consider themselves in the profession of "database theorists" (I think there are such, right?) have a similar approach to their users -- I might be over-estimating the discipline, but I gotta think and I am hopeful that at least some do. I have seen gains since I started watching, reading, and asking questions in this area, so that is a good sign from my perspective, although there have not been enough gains to rest on them.

> They might distinguish
> implementations with underlying model clearly. But and most
> importantly, they steer clear of hand way appeals to woefully
> unreliable /anecdotal evidence/ (which is like committing discursive
> suicide without a plethora of caveats attached to it).

That is when I'm functioning as an end-user of database theory, even if treating myself as both end-user and attempting to tap into what database theory developers are thinking when they do not meet "my" requirements. I am both voicing my end-user concerns and trying to figure out how others address such concerns.

> After all if anecdotal evidence was of any merit we'd all believe in
> Ghosts, Telepathy, Martians, Elvis being alive,

You were doing OK until this one. I'm from Kalamazoo, 'nuf said.

> or that I can look at
> greasy sodden tea leaves to see if England are ever going to win a
> cricket match again.

I understand. To my recollection, I have never used anecdotes as proof (and certainly do not think of them as proof, but also do not discount intuition as a valid starting point for a hypothesis). Anecdotes can provide reason enough to seek a better understanding of why an anecdote does not align with related theory, for example, or as counter-examples.

> > > Sounds the same as 4, generally speaking.

> >OK, that was my impression too. So, one person might have 2VL in their
> > theory and another might have 3VL, right? How would one judge whether
> > one was better than another? I would think that would be by applying
> > each system of rules along with some means of measuring which system
> > produces better results in various areas. Judging database theories
> > would be much like judging software products - what features does it
> > provide, what quality requirements does it meet, etc. Does that make
> > sense?

> Not to me. Database theory is grounded in the nature of information in
> a dynamic world, and how it can be communicated and manipulated, and
> its integrity maintained.

OK, so it is some subset of "theory" as it relates to "databases" -- is that what you are indicating? I can understand how you can get precision in the latter part of your statement, but not the start of it.

> Logicians and Linguists have spent centuries
> addressing these issues, scientifically and diligently.

Yes, indeed. I'm familiar with the Chomsky hierarchy, for example. [warning, anecdote -- when my father, a linguist, had the opportunity to publically ask Chomsky a question, maybe 40 years ago, he asked one about "pragmatics." So, perhaps I'm just genetically inclined to such questions ;-) ]

> We are far from
> getting to the truth of what information is, and how it best be
> handled, but we have progressed

By what measurement have we progressed? I do not doubt you, but I'm interested in how you have reached such a conclusion.

> and it is through this sort of applied
> epistimology that advances will continue to be made. Progress does not
> occur through saying "my mate used this graph thing to organize his wii
> game collection and it was leet. I don't understand it doesn't 0wnage
> the world. It must be because all the man has have been lying to us all
> these years."

But wouldn't you think it could advance at least a little by collecting the requirements of its user base. I have never before asked my end-users to come up with mathematical proofs for what they say they need to do their jobs well.

> > > > 6. contemplation or speculation.
> > > > 7. guess or conjecture.
> > >"Ha! We'll get lots of wise-cracks on these two!Sometimes my statements align with 4 & 5, in which case they could be
> > judged by what features are present and which are not. Sometimes I get
> > responses or give statements that are more in the 6 or 7 category. But
> > if someone guesses that that relational theory is better for xyz in the
> > long term and I guess it is not, then a comparison of features (which
> > we might do to judge database theory as mentioned above) is not
> > sufficient because we can disagree on which approach is more
> > feature-rich or meets the requirements best. We actually need to know
> > which requirements we are aiming for and then perhaps collect emperical
> > data, not just think "hey, it seems to me that relational theory should
> > provide us with databases that are easier to maintain with quality data
> > over the long term than other databases." But when I bring up
> > emperical data, some indications are that this is outside the scope of
> > database theory.Having a 'theory' is not enough.

> One has to back it up, or develop it
> with a bit of scientific rigour for it to become worth people's time

Again, not something I say to my users, nor to myself-as-user when I am playing both user and "developer" but I am understanding that there are some who would like all of database theory to be within the confines of mathematics. That would be very tidy -- not necessary useful, but definitely tidy. Agreed?

> and consideration (and not embarrassing appeals to anecdotal evidence).
> Sadly empirical evidence is almost impossible to obtain in the field
> (as it is such areas as the Biological sciences, and especially in my
> old field Economics), so people have to appeal to other merits.
>

So, how do we judge whether a database theory is anything more than useful? If two products spring from two different theories and we give people the same task using the two tools, we could get some information, but there are too many other variables so that you could not get consensus about underlying theories based on a single such experiment. But perhaps 30 such experiments with different tools and people, but the same two theories, would give enough data to have a really good idea of which theory meets which requirements best?

> > So, I'm confused on how others are thinking one judges whether they
> > have a good "database theory." There seem to be some who indicate that
> > the judgment of whether a theory is good or not lies in the mathematics
> > of the theory. I do not understand how this could possibly be the case
> > (and that might be why I have been told that I do not appreciate
> > theory). The mathematics of a theory could be absolutely beautiful and
> > the resulting "database theory" could be awful, right? I do understand
> > that some features on our list where we could do comparisons include
> > "provability" and "query symmetry" but these are simply items on our
> > requirements list, not the only items on the list nor the only measures
> > of a theory. The feature list for databases (and DBMS's) is huge, and
> > similarly for related database theory, I would think. One requirement
> > I have for database theories, for example, is that they lead to
> > implementations that are a "big bang for the buck" for companies using
> > those products.

> No, your "bang for buck" argument is spurious

It is not an argument, but an unrefined requirement, one of many that would be on our sheet of what features and quality requirements we have for database tools.

> and always makes me
> cringe somewhat. It misses the fact that productivity wholly depends on
> the merits of a particular implementation, education levels of its
> users, what mindset they are used to, and a million an one other
> external factors. Imho, leave it well alone - it will just generate
> frustration to those who see it has little to no relevance to how good
> an underlying theory is.

So you are saying that developer productivity is off-limits as a requirement for a database theory? That actually explains, better than I have seen before, not only why my prodding would be so frustrating, but why relational theory folks might not have cared at all if it set our profession back in that regard (recognizing I have seen no proof that it did or did not). From my reading, I understood that there were productivity-over-time concerns that were being addressed. But if it is out of scope to even consider such matters...hmnmm.

> I hope (perhaps foolishly) that you yet might heed some of these things
> and who knows, it may even generate real discourse!

I'm attempting here to start from the basics -- what is theory, what is database theory -- so that I don't misunderstand what it is that database theorists care about and what the scope of the discipline might be. Perhaps if 1. my primary requirement is low cost-of-ownership over time for application software, and if 2. I suspect (but have no proof) that database theory has adversely affected this in the past, so that 3. I believe that it has the power to also right such wrongs (iff I'm correct about them, with no proof either way) then based on what I am understading from your comments 4. It can only do so as a by-product of addressing something else because it cares nothing for my requirement in 1. Am I understanding correctly?

> I still await a
> post without any agenda, or baiting, or getting drawn into business
> politics -

OK, it sounds like database theory is a profession that might want to have no users or at least users with no requirements, right? ;-) I could use some of those myself. There is that joke about the librarian who said that it was a wonderful day for the library because there were only two books checked out and they were both due today. Maybe we could write a similar joke about a database theorist? Just wondering if I'm getting the picture.

> perhaps a theoretical exploration of grouping and ungrouping
> aggregates? Regards, Jim.

Yes, I've been reading that and am interested. But you might understand if I tell you that since I have done my share of grouping and ungrouping (nesting and unnesting) of production data and I can recall many issues that I have encountered (unnest multiple multivalues in a relation and then sum another attribute, for example), I have an understanding of my requirements in this regard. However, I have no idea how to meet these requirements using only set-based queries against a single row-and-column-representation of the available data. This is an aside, and I might be misunderstanding, but when I ask questions about such things, I'm told that SQL isn't intended for such queries, so you need to use a "reporting tool" which, funny thing, does not use exclusively set-based queries in its underbelly (which is the reason it can do the job). So I think I need to just listen in on that discussion for now.

> > I also am not sure whether sometimes when a person writes "theory" they
> > are referring only to the mathematics portion of the rules. For
> > example, are "produce a nightly backup to disk" and "have a real-time
> > operational database that is a duplicate of the OLTP database" possible
> > statements in a "database theory" or not? Why or why not?
>
> > Thanks for the discussion on this. --dawn

Thanks for the discussion. --dawn

>
> > > --
> > > Kenneth Downs
> > > Secure Data Software, Inc.
> > > (Ken)nneth_at_(Sec)ure(Dat)a(.com)
Received on Sat Jan 27 2007 - 04:48:43 CET