Re: Attribute Value Attributes, Fuzzy Sets, & Color-coded Data

"Dawn M. Wolthuis" <dwolt_at_tincat-group.com> wrote in message news:c61k4k$868$1_at_news.netins.net...
> Among the questions I have recorded from my recent database research is
one
> about the attributes of attribute values.
>
> Is there any provision in relational or other database theory that
> incorporates attributes about attribute values without treating these
> identically to other attributes? An example would be something like "age
of
> value in the database" or "person who last updated this information" or
> "time/date stamp for when data was last maintained".

I think this information would be (could be) stored in the system catalog, in the form of (of course) relations.

> Similarly, if one were
> to store fuzzy data, where there is a numer between 0 & 1 included with a
> value that declares the fuzziness of the data (which could be used for
> datasets where we want to record the likelihood of accuracy in the data,
for
> example), then the fuzzy set number could be seen as an attribute of a
> particular value.

I'd say the "fuzziness" of the data isn't exactly an "attribute of an attribute", because presumably it impacts queries and updates in the algebra itself. Assigning those fuzziness values would be a job for a person, thus requiring an interface of some sort for assigning the values.

> I'm guessing that there are some long lists of possible attributes of this
> nature. I have only ever seen such data placed into a data model as if it
> were yet another part of a proposition, rather than data about the
> proposition.
>
> So, the proposition becomes:
>
> John Doe ordered a pizza on 10JAN04 and his last name was updated last by
> Martha Stewart on 12NOV02 while the date was updated last by Bob Dylan on
> 10JAN04 at 6:30PM etc
>
> rather than the simpler:
> John Doe ordered pizza on 10JAN04
>
> Is there any database theory that does not treat the attributes of
attribute
> values as if they were the same as attributes about the main subject?

A relational data store with a system catalog could easily do this, allowing you to query such attributes according to the usual relational notions. And it wouldn't be a stretch to compose queries that combined catalog and "normal" data, although there might be implications I'm not considering.

> And a follow-on question -- since attributes about attribute values are
not
> about the key, the whole key, and nothing but the key (being about just
one
> value), once you add in any such attributes, what is the standard way of
> modeling this data?

They are dependent on keys in the system catalog, and values in those relations "relate" to values in your defined relations / views.

> Do you just ignore traditional normalization, figuring
> that instead of having the attribute "LastName" you have a tuple of
> (LastName, Fuzziness, LastUpdatedDate, ...) or do you consider the
"primary"
> attribute to be a relation-valued attribnute or what?
>
> Feel free to point me to resources on this -- I've searched a bit, but not
> among the most academic papers -- I'm looking for something immediately
> useful to the average DBA who is addressing data of this nature. What
would
> be a common way to handle?

I've yet to see a strong treatment of a relational system catalog, though they must exist. It would probably answer many of your questions. Note that constraints of various sorts on the catalog would also make for an interesting subject...

> I added "Color-coded Data" in the subject because ever since the company
> newsletter at my employer in 1985 had an article that talked about the
> company's "4-color database" (the IBM terminals used had 4 colors), I've
> thought it would be cool to have color-coded data. Color is a nice way to
> provide information about various data values without having to list it
out
> separately. For example, a data element shown to the user as "red" might
> mean it hasn't been updated in 20 years, while one in green might have
been
> recently added or updated information. Color would just added to a
> presentation of the data simply by interpreting an attribute of an
attribute
> value, of course. It is an example where one might want to add such an
> attribute for every attribute value stored in the database (which would be
> awful to do if the database does not provide that as a feature and I
haven't
> seen any that do as yet -- are there such?)

The color mapping is an application decision (though it could be stored in relations), though querying the catalog would give you the basis for the mapping.

• erk