Re: database design method

D Guntermann wrote:
>
>Just prior to 1.4, he discusses confusion due to failure to distinguish
>between type and instance with a very direct reference to "record". I
>gather that he considers a relation value in a relation tuple to be of a
>_complex domain_ because he considers them to be repeating/multiple
>instances of tuple types rather than one encapsulated instance of a relation
>type.

Indeed, but the million dollar question is here what exactly is the definiton of "encapsulated instance" here. Have you seen a formal definition of this anywhere? In OO and in the context of ADT's I know what this means but there it concernes the *implementation* of a data type, but that cannot be approriate here because the nested relational model is a logical data model and therefore does not speak about implementation. The only definition I can think of is that you cannot unnest the set, but that is exactly what Date now has allowed.

>His naming of attribute roles as _jobhistory_, _salaryhistory_, and
>_children_ in Figure 3(a) almost seemed like abstract identifiers at one
>point.

They are readable strings and therefore not abstract.

>Could there be such a thing as "conceptual encapsulation"?

Exactly! My compliments. You are asking the right questions. I would say that term encapsulation in a logical conceptual data model is a contradiction in terms. This is actually one of the best and deepest arguments I know against the use of OO data models as logical data models.

• Jan Hidders