Re: Storing derived and derivable data

David Cressey wrote:
> "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.

Yes, I tried to be careful with the wording to indicate that the organization determined that the software would work this way. In reality, it is more likely that entering a zip code would bring up a best guess for the user to override. I guessed that it was less likely that anyone had used anything at a database level (rather than app level) to indicate that something was "mostly-derivable." So, I simplified the example. You could put names of a, b, c... for the ones I used to make it a more abstract question.

I'm looking at that fuzzy line where code and data meet. Given that I have seen (or at least noticed) more derived and derivable data of late, I thought perhaps there were ways to at least do the conceptual modeling, but perhaps even the implementation of such attributes differently so as to reflect this information about the attributes, perhaps supplying appropriate derivation code.

Thanks. --dawn Received on Fri Apr 21 2006 - 20:53:20 CEST