Re: Storing derived and derivable data

dawn wrote:
> Jan Hidders wrote:
> > dawn wrote:
> > > Is there database theory that includes identification of
> > >
> > > 1. the fact that values for an attribute either were or could have been
> > > derived?
> > > 2. how values for an attribute were derived?
> > > 3. how values for an attribute could have been derived?
> >
> > That is usuallly taken care of by specifying the database constraints
> > that define the relationships between the derived column and the other
> > data, and then marking it as either derived or not.
> >
> > This is rather trivial. So I'm wondering if I understood your question
> > correctly.
>
> It is very possible that I'm missing something basic. I know how to
> tie derived data specifications to the stored data from which they are
> derived. Now let's use that derived data to determine a value and
> store it back in an existing base table. Is there a way for the DBMS
> to retain the information about the source of this materialized
> attribute?

What do you mean by 'the source' and what information do you want to keep about it? Apparently not the definition of the derived column. Are you talking about data provenance here?

> Or said differently, is there a way, other than app or trigger code, to
> tie the materialized version of an attribute to the derived attribute
> from which the value was taken?

?? The derived attribute *is* the materialized version.

> David pointed me to Sybase as a DBMS that seems to have the feature of
> storing materialized attributes, otherwise I'm figuring with most
> DBMS's it is an app or trigger where the code resides to store the
> data, but I might be completely missing something as my direct
> experience with sql constraint specification is limited.

One simply specifies the query that derives the value of the column, or in the case of a materlized view the whole table. That is the definition of the derived column. What more do you want?

> Given that
> the RM has as a goal not to have duplicate data and this is clearly a
> duplication of data, I was thinking this might be one place where the
> application would have the knowledge, rather than the DBMS.

Another goal of the RM is to shield the data from sloppy applications, so if duplication cannot be avoided then at least the DBMS should be in charge of it and not the applications.

• Jan Hidders