Re: Clean Object Class Design -- What is it?

Jim Melton wrote in message <3B8B43D1.234B2142_at_Technologist.com>...
>Bob Badour wrote:

>> >How do
>> >domains play?
>>
>> Domains specify data type, allowed values and available operations. How
do
>> object classes play?
>
>One difference that I can imagine between domains and object classes is
that
>object classes constrain access to the internal (non-public) representation
of
>the class. A data member of a class may not (should not) be publicly
>accessible. Do domains enforce separation of public interface from
>implementation details?

Absolutely. Physical independence requires us to go even further and suggests that the DBMS should be able to handle multiple possible representations for any given interface.

>> >> >so is the row-id generated by commercial
>> >> >RDBMSs.
>> >>
>> >> Which violate 1NF and which make commercial SQL databases
non-relational.
>> As
>> >> do duplicate rows etc. Do you have a relevant point?
>> >
>> >I guess not. Just trying to map this stimulating theoretical argument
into
>> the
>> >practical world in which I must code. I thought Carl was comparing ODBMS
>> and
>> >(commercial) RDBMS -- SQL-DBMS if you please.
>>
>> You seem to accept that SQL databases are non-relational and then you
equate
>> RDBMS with SQL-DBMS. Is the irony lost on you?
>
>I accept that you do not accept SQL databases as relational. This is why I
>qualified my statement as (commercial) RDBMS.

Commercial SQL database. Please do not equate the limitations of SQL with any so-called limitation of the relational model.

>Perhaps. But in the object database I use, associations (relations or
pointers
>as you choose) are explicit, can be symmetric and are navigational.

Exactly! The problem is that they require navigation. While values allow navigation, they do not require it.

>The only
>way to model the associations as value-based would be to create synthetic
IDs.

Why? Do the entities you manipulate have no logical identity?

>> >I find attribute joins
>> >problematic, especially where they force synthetic IDs into the data
model
>>
>> Do you mean you would prefer not to have any form of logical identifier?
You
>> will find such a lack much more problematic.
>
>I find that a normalized model does not usually consist of stand-alone
>entities. For example (again), a contact database should have multiple
phone
>numbers for a contact.

And the user should have some method for identifying each of these phone numbers. Home, work, fax, cell, emergency, alternate office on tuesdays and thursdays...

>Perhaps each number would include a "type" tag (home,
>cell, etc.). In order to associate this phone information with the contact
>info, either a synthetic ID must be generated or the primary key values
must be
>replicated.

I am not sure I understand your complaint. Are you complaining about redundant information in the logical view of the data? Pointers are as redundant, if not more so.

I question whether any synthetic ID is required. The contact identifier and the phone number suffice.

>I'd rather just store the array of phone numbers with the contact
>where they belong.

Nothing prevents you from doing that. The relational model only requires that you allow the user to query the phone numbers as if they are independent of the contact. To the user, the DBMS must expose the association between the phone number and the department explicitly using values regardless of how the DBMS physically establishes the association.

>> Purity is not the issue. Simplicity and comprehensibility are. Users will
>> not get the answers they want when confronted with a complex,
>> incomprehensible representation of the data.
>
>I find an object database a marvelous tool for managing complexity. To each
his
>own.

Then I must question whether you understand the concept. If every object class has a different, unique interface, the user has a huge amount to learn before the user can become productive. Relations are simple -- as are relational expressions. Objects are complex -- so complex that no such thing as an object expression really exists, or ever will. Received on Fri Aug 31 2001 - 23:35:04 CEST