Re: Storing derived and derivable data

From: dawn <dawnwolthuis_at_gmail.com>
Date: 22 Apr 2006 07:44:41 -0700
Message-ID: <1145717081.072600.109970_at_i39g2000cwa.googlegroups.com>


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?

By this I mean derived data, vritual fields, computed columns... derived from other stored data, but then stored (materialized). Is there any identification (flagging) of such columns in any theory, any conceptual models, any logical models?

> 2. how values for an attribute were derived?

If this is a UDF in SQL Server (which I have not used, so I'm guessing), then we have the code for the derived data, but if we materialize the values then how is the derivation function associated with this new column? I'm not so concerned with how that is done in practice right now, but how that is reflected in any modeling.

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

I see I missed the word "application" before the last "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 am referring to any notation anywhere, perhaps in a conceptual or logical data model, for example. While there are terms to distinguish between a base table and a materialized view, for example, I have not found the right terms to distingish a derived materialized attribute from on that is not derived from values in the database. I would like to write about such attributes and am not finding terminology or notation to do so.

> 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

I hope this helps to clarify the question. Thanks. --dawn Received on Sat Apr 22 2006 - 16:44:41 CEST

Original text of this message