Re: Storing query language in relations

From: Paul <pbrazier_at_cosmos-uk.co.uk>
Date: 2 Oct 2002 09:57:03 -0700
Message-ID: <51d64140.0210020857.278ac3ba_at_posting.google.com>


Paul Vernon <paul.vernon_at_ukk.ibmm.comm> wrote in message news:<anconi$10l8$1_at_sp15at20.hursley.ibm.com>...
> Remember the principle of interchangeability - views and relations are
> interchangeable.
>
> In principle you can switch the set of views & relations that you consider
> to be the 'real' database at any given point in time.

I'm not totally clear on this - the DBMS I'm using here (SQL Server) defines a view to basically be a query result that is treated as if it were a "real" table - but I presume that this is not the definition that you have. I've been looking at the other thread on view updateability and I think this confusion is the heart of the problem. If you have aggregates or derived columns or indeed anything that uses the properties of the *domains* rather than the *relations* then clearly my simple definition of a view is not always updateable and hence not equivalent to the "real" tables.

So in a sense we are defining a view to be the subset of queries that have inverses and are thus updateable. So views are updateable by definition really.
Is this equivalent to the set of "pure" relational queries i.e. queries not using domain properties at all?

> >Well you might say: if all queries have to be stored in relations, how
> >do you INSERT any data to begin with?
>
> You might just as well ask, how do the system catalog tables get populated
> with the data that describes themselves?

good question - I guess this is the exact analogy for DDL what my thoughts were for DML. I guess the system table is "hardcoded" into the database (like my hypothetical INSERT function).

I'm wondering why the requirement that metadata and data are both stored relationally is there? Maybe a separation between the two is a good thing - with too much self-referentiality might we get Godel-style problems like trying to define a view of all tables/views that don't contain definitions of themselves? i.e. does *this* view contain itself or not?

Or maybe you'd be OK because of computers being finite and the fact that you build relations constructively rather than non-constructively (can't remember what the term is for this though vaguely remember something about Axiom of Choise from set theory)

Maybe data and metadata should be in an (infinite?) hierarchy where you can't "join" tables that are at different levels. Not that I can think of a reason why you'd want to though.

Are there DBMSs where you can "create" new tables, views, indexes, constraints, etc. just by inserting into the appropriate system tables? So the DDL becomes redundant?

Just thinking as well - by storing queries in relational form you remove the need for relation-valued domains because they could be indexed by integers.

> It's interesting to note that most database designs consist entirely of
> empty relations. It seems to me that this is a massive restriction on the
> set of possible database designs. Many plausible constraints evaluate to
> false when a database is full only of empty relvars.

for example?

> So next question. Anyone like to propose a mapping of a BNF grammar to a
> set of relvars and constraints?

Maybe even you could have the BNF syntax itself stored relationally (would this be meta-meta-data?) so that you could automatically generate the schema for any particular BNF grammar you feed it?

You could also go the opposite way to metadata and think about storing domains relationally as well. e.g. define the domain of integers (at least up to a certain value) and operations like addition upon it. Maybe just store numbers as binary and consider each binary digit to be atomic. Is there a relational equivalent of the Turing machine? Could you have a computer hardware architecture that was implemented relationally instead of the traditional von Neuman architecture? I'm just thinking aloud here so forgive me if some of these thoughts are nonsense.

Paul. Received on Wed Oct 02 2002 - 18:57:03 CEST

Original text of this message