Re: Storing derived and derivable data

"dawn" <dawnwolthuis_at_gmail.com> wrote in message news: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
>

This is slightly off topic, but city and state are not always determined by knowing zip code. I live in a zip code that spans two towns. On the way through to Maine, going north from Errol, there is a zip code that spans two states. Received on Fri Apr 21 2006 - 20:40:54 CEST