Re: Storing query language in relations

Paul. You are raising the question of when to model non-scalar types as single attribute values and when to model them as relation values.

The cheating answer is to point out that in the RM you can have your cake and eat it.
All you need do is to create a set of virtual relvars over your non-scalar attribute.

> a relational database is the most logical way to
>hold structured data

I would rather say, 'the relational model is the most logical general way to structure and query persistent data'.

>why not go a step further and store the actual
>queries in relational format?

Also be careful with the word 'store'. To many it will suggests physical storage mechanisms. However, it is a good word, and I use it below but do not mean to imply anything about physical storage

>I know some DBMSs store the text of queries, view definitions,
>stored procedures etc. in tables but not in a normalised fashion.
>An advantage would be that the DB constraints would automatically
>validate the query so no need for parsing SQL code for syntax.

The downside being that you would need some horrendous multiple relvar assignments to enter a new query.

Can I suggest that a more pragmatic (and human friendly) idea would be to recognise the need for a new non-scalar type generator. Such a generator would take a BNF grammar and create a non-scalar 'language' type for that grammar. It would also create a parser to take a text string and return a value of the new type for all valid inputs.

If called from a Relation Type generator (i.e. CREATE TABLE, VALUES in SQL), such a language generator could, if desired, produce virtual relvars that normalise any non-scalar language attributes. Along with such virtual relvars, a mass of relational constraints corresponding to the particular BNF grammar would be generated, thereby ensuring that the relvars could only be set to values corresponding to valid paragraphs of the language.

But I would ask why? What would we gain? The usual answer for normalising non-scalar types is that we want to be able to ad-hoc query the components of the non-scalar types using the expressive power of relational algebra. As an example, breaking written language attributes into their consistence parts (e.g. words) is a sensible step if you are building a simple text search database. This would allow you to say find the set of sentences with 6 or more words in common, using a relational query.

In the general case of languages, (e.g. SQL, C, relational algebra, etc) I find it hard to conceive of a common need to relationally query their components. I guess that a DIFF function could be coded relationally, but frankly I think that traversing parse trees is going to be easier.

Having said that I think it would be a good test of a true relational language. If such a language Type generator was provided, it would show that they were eating their own food.

>Wasn't one of Codd's guidelines that metadata should also be
> stored relationally?

Indeed. I don't have the quote to hand, but the upshot is that EVERYTHING that is needed to be stored persistently, should be stored relationally.

>I know the table definitions (DDL)are
>in many DBMSs. But generally a separation is made between the
>database and its query language (DML).

>I've not thought too deeply about how a schema for SQL queries (for
>example) could be implemented but it must be possible (kind of like
>the MS Access query grid but normalised).

So the MS Access query grid can specify all possible relational expressions? Humm. As above, I would suggest using the grammar for the language as your schema. Nasty hey?

>Is this taking things too far or might this line of thinking
>produce something useful? Has this been done already in some
>DBMS?
As long as the ideas hold water, you have to go a long way to go to far in a theory newsgroup.

:-)

Regards
Paul Vernon
Business Intelligence, IBM Global Services Received on Tue Sep 24 2002 - 11:15:43 CEST