Re: Storing query language in relations

From: Paul <pbrazier_at_cosmos-uk.co.uk>
Date: 27 Sep 2002 01:56:24 -0700
Message-ID: <51d64140.0209270056.639ffef7_at_posting.google.com>


mikharakiri_at_yahoo.com (Mikito Harakiri) wrote in message
>
> It is difficult to define what normalized SQL query is.
>
> For example, would you consider
>
> select ename from emp where empno = 1000
>
> and
>
> select ename from emp where empno + 1 = 1001
>
> as "equivalent" queries (then, you normalize them into identical
> representation)?

Well in this case it you would be able to put the expression in some "canonical form" which would be analagous to, but separate from, normalisation. I think maybe what confuses the issue is that we look at not only relational theory here but also the theory of the underlying domains. It might be clearer to consider the case where the domains are just sets with no operators defined on them at all other than equality. Then build up to think about domains which are ordered sets of various categories, then groups, fields, algebras plus whatever other mathematical structures there are. You could for example have a database schema just for storing polynomial expressions.

Actually, are subqueries only needed when you have aggregate functions? And aggregate functions are only defined over domains with the appropriate operators defined on them (like addition, comparison etc.)

To go a step further you could also define your set operators in relations. For example to store the facts that 1 + 1 = 2, 1 + 2 = 3, etc.

You can see here how relational database theory converges with set theory and information theory - e.g. the set {a, {a, {b, c}}, {b, c}} could maybe be represented more succinctly because it contains {b, c} twice.
Or the sequence "abbaabccbbaac" can be compressed by noting the repeated subsequences. This would be analagous to normalisatin maybe?

> If you have an answer for simple predicates, then how about nested
> subqueries? Would query transformation that unnests subquery still
> give you an "equivalent" query?

Maybe the concept of "query equivalence" can't be well defined in SQL? Or perhaps in the general case of a database, normalisation is as much an art as a science since it depends on the interpretation given to the data which is often business-oriented and not rigorously defined. But if we consider a database to store some precisely defined mathematical construct then maybe you could have some way of having a unique way of storing each query. Or at least have some "canonical form" that would show that two different queries are in fact equivalent.

Is there a way in SQL of automating the process of transforming a subquery into a join or vice versa?

Are there any query languages that have only one way of expressing any query?

Paul. Received on Fri Sep 27 2002 - 10:56:24 CEST

Original text of this message