Rich Cooper wrote: (01)
> I have always considered the definition of an RDB-class correspondence to be
> partially in the mind of the modeler, not in the RDB structure itself. I
> know of no formal definition of what a RDB-class consists of, which would
> provide a rigorous foundation for translating RDBs to classes with one
> exception; there is at least one class per table. Modelers may often add
> definitions of subclasses within a table, but that's usually some form of
> correspondence between groups of columns from a table that fit within the
> human "chunk" size of 7+/-2 concepts. So it seems every bit as subjective
> as any other method of constructing classes from data. Data mining (and
> text mining) consists of discovering those subclasses, along with classes
> that relate one table to other(s). (02)
I would not dispute any of this. (03)
> Do you have reference(s) (URLs especially) to other documented points of
> view which might more rigorously define how the RDB translates into classes? (04)
To be honest, I haven't been concerned with that for more than 10 years.
I wasn't writing about "mapping classes to tables". I was writing about
the distinctions in the arity concept in RDBs, and the analogies to the
arity of relations in formal logic. (05)
The critical underlying difference is the means of reference. Formal
logic languages assume that a constant term denotes an individual, and
relations relate sequences of terms to true/false. RDB languages assume
that a set/vector of key values denotes some notion of individual, and
that a table represents one or more functions (properly "mathematical
relations"), each of which maps a domain vector of key values to a range
vector of values. There are obvious mappings from logical relations to
RDB tables, but the arity concepts are not comparable. (06)
That there are obvious mappings from a set of logical relations to a set
of RDB tables doesn't mean that is the best RDB implementation of the
same knowledge base. Matthew correctly observed that relational tables
are pre-joined for both documentary and performance reasons. And that
in turn means that there are no reliable assumptions that can be made
about mappings from RDB tables to logical relations. As you say, a lot
of data mining is about figuring out what that mapping is. (07)
-Ed (08)
--
Edward J. Barkmeyer Email: edbark@xxxxxxxx
National Institute of Standards & Technology
Manufacturing Systems Integration Division
100 Bureau Drive, Stop 8263 Tel: +1 301-975-3528
Gaithersburg, MD 20899-8263 FAX: +1 301-975-4694 (09)
"The opinions expressed above do not reflect consensus of NIST,
and have not been reviewed by any Government authority." (010)
_________________________________________________________________
Message Archives: http://ontolog.cim3.net/forum/ontolog-forum/
Config Subscr: http://ontolog.cim3.net/mailman/listinfo/ontolog-forum/
Unsubscribe: mailto:ontolog-forum-leave@xxxxxxxxxxxxxxxx
Shared Files: http://ontolog.cim3.net/file/
Community Wiki: http://ontolog.cim3.net/wiki/
To join: http://ontolog.cim3.net/cgi-bin/wiki.pl?WikiHomePage#nid1J
To Post: mailto:ontolog-forum@xxxxxxxxxxxxxxxx (011)
|