Re: Database-valued attributes?

"Paul Vernon" <paul.vernon_at_ukk.ibmm.comm> wrote in message news:<boqhlv$1226$1_at_gazette.almaden.ibm.com>...
> "Jonathan Leffler" <jleffler_at_earthlink.net> wrote in message
> news:Ir%rb.7052$nz.2397_at_newsread2.news.pas.earthlink.net...
> > Marshall Spight wrote:
> >
> > > There's been the occasional incidental discussion of relation-valued
> > > attributes on the list lately. This has got me thinking: what about
> > > database-valued attributes? That is to say, what about an attribute
> > > that consists of a set of relation values?
> >
> > Hmmm...would the elements of the set of tables all need the same type?
> > In the RMD (relational model of data), the values in a column are
> > homogeneous in type, usually. For example, in a table with one or
> > more RVAs, the RVAs for a given attribute have the same structure/type
> > in each row.
> >
> > What is a database? That isn't intended to be wholly facetious.
>
> No, indeed this is a very important question, and not one that to my
> knowledge that has an agreed answer. Well, I have an answer, but I don't
> believe that is it is widely agreed upon.
>
> See this thread
> http://groups.google.co.uk/groups?selm=3cccff99%241%40news.uia.ac.be
>
Thanks for pointing me back to this discussion. Your comments at the end concerning the implications of how we represent a database or a nested set of relation values in terms of data integration was very apt.

> In particular, Jan's comments:
> "a database instance is not a set of relations but more like a tuple of
> relations"

Interestingly, I recently had an opportunity to review a paper that runs along a similar vein, and that presents a representation that closely corresponds with Jan's assertion of how databases are defined in formal literature. In "Language Features for Interoperability of Databases with Schematic Descrepancies", Krishnaurthy, Litwin, and Kent describe a model of a universe a databases as a tuple of database variables where each database value is comprised of tuples of relations (implicitly bound to relation type defs), as a general framework for schema and view integration over a relational multi-database:

u = (db1:(r11: {(a111:O111,...)...},
          r12: {(a121:O121,...)...}..),
     db2:(r21: ((a211:O211,...)...},
          r22: {(a221:O221,...)...}..)
     .
     .
     .
     )

[the following is added by me and not necessarily paraphrased from the paper]

where u is the view universe of a databases under consideration,

      dbx is a named variable for a dabase value,
      rxx is a named relation type variable name,
      axxx is named attribute variable (type was left off),
      Oxxx is a "value".

A notable break from the concept of a true relation is that the model allows for varying arity of tuples in a collection.

The paper actually centers on using higher order expressions to overcome schematic discrepancies for multi-database views, but it still has an orthogonal relationship in that it considers a generalization that allows for different database "values" or parts of the database value to be information content equivalent in spite of different schema representations. A good read.       

This
>
> "I have seen lots of formal definitions of a relational database and not one
> of them defined a schema as a set (as in set theory) of tables (or
> relations, to be more exact)."

>

This is interesting.

>
> Oh, my answer is that
>
> a database is a set of tuples.
>
> nice and simple.
>
> :-)
>
> P.S. That's tuples not necessarily of the same type of course.

Huh?
>
>
> Regards
> Paul Vernon
> Business Intelligence, IBM Global Services

Regards,

• Dan