Re: Storing derived and derivable data

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?

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?

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. 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.

Additionally, perhaps you can specify a constraint that says that a particular attribute can only be maintained by a specified process, but my googling came up short. I likely do not know the correct terminology.
Thanks. --dawn Received on Mon May 01 2006 - 05:59:03 CEST