Storing derived and derivable data

From: dawn <dawnwolthuis_at_gmail.com>
Date: 21 Apr 2006 05:21:17 -0700
Message-ID: <1145622076.958951.174100_at_t31g2000cwb.googlegroups.com>



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?

For example, if a system is to be written that accepts US zip codes and populates city and state based on the zip, storing all three values, must the code for the derivation and the fact that this is derived data be known only through the code?

Similarly, if data could have been derived, but was not, is there any way to specify that? For example, if the zip+4 information could be derived from the rest of the address, but we don't want to require that it be derived to the DBMS -- apps could collect it directly from a user if that meets the requirements for that app -- could we identify that the zip+4 can be derived using this or that service or this or that code?

If there are materialized attributes, such as a student GPA, where the data should never be collected by any application and should only be derived, is there a way to specify or even ensure that it is derived (then materialized) data? Is there any notation that works with derived, but stored, data any differently than any other attributes?

I also have not seen anything in conceptual modeling techniques, including ORM (I'm not an expert on that), to collect information about what is or can be derived from what in the conceptual model. Does anyone have suggestions in that area? Thanks. --dawn Received on Fri Apr 21 2006 - 14:21:17 CEST

Original text of this message