Re: Natural keys vs Aritficial Keys

Someone whose usenet posts are filtered sent a private email with a question related to this thread. Since I took the time to reply, I figured I would share it here too. Other than fixing a typo, I include the entire reply here:

SIRA_PRISE wrote:

> Bob Badour wrote:
>
>> Nope, that's still the first blunder: mapping object instances to
>> tuples. Derived tuples are still tuples.
>
> Curious. Would you care to explain ? I thought that if any mapping
> made sense, so far as it goes, it was precisely to let an object
> correspond to a member of a relation.

Objects are "encapsulated" so internal structure is hidden information. A tuple is plain composition. Very different. An individual value for a single attribute of a tuple hides its internal structure, while a tuple exposes the attributes composing it. In a well-designed data management system, one can treat a data value as if it had any reasonable internal structure as its representation regardless of the actual physical representation chosen. In fact, physical independence requires this.

Thus, object class maps to data type, and the current state of an object instance is a data value, which maps to a single attribute of a tuple not an entire tuple.

Every logical data model has structure, operations etc. In the relational model, the only structure is relation, which is a set of tuples. Thus a tuple is a structural element of the data model.

The structural elements in OO languages vary but the primary structural element is pointer, reference or address.

It's true one can have tuple data types and tuple valued attributes just as one can have relation data types and relation valued attributes, but those are not intrinsic to the relational model, required by the relational model, or even highly recommended by the relational model.

> I thought the first blunder was about equating Classes with Relations/
> Relvars, not about equating Objects (not "object instances") with
> Tuples.

If one equates classes with relations, one really equates the extent of a class with a relation. If one equates the extent of a class with a relation, one synonymously equates object instances with tuples: The extent of a class is the set of its instances, and a relation is a set of tuples.

> The arguments I've seen in that context all demonstrate that
> Classes are Types. How does this preclude an instance of a Class from
> "corresponding" to a member of a Type ?

A relation is not a type. In the context of a relation, neither is a tuple.

> Given that OO has, roughly speaking, two concepts to make the world
> turn (Class and Object)

Actually it has far more than that, but confuses things by calling different concepts by the same name. There are object classes, object references, object collections, object instances, object extents, object variables, object values -- just off the top of my head.

> , and that RM has, roughly speaking, four
> (Types, Tuples, Relations and Constraints), and given furthermore that
> lots (maybe all, i don't know) of OO systems don't have a clean
> distinction between values and variables (objects can be variables but
> can be values too), whereas a system like TTM does scrutinously uphold
> such a distinction, I'd say that the real blunder is to simply even
> attempt any mapping.

That's why Date and Darwen didn't bother to do a mapping. Instead, in TTM, they explored the topic of OO to see what new concepts, if any, could be useful for data management. They found none. The only useful concepts they found already existed in the RM with other, more precise names. Received on Fri Jun 12 2009 - 15:40:38 CEST