Re: 3-ary relationship and association class

From: H. S. Lahman (h.lahman_at_verizon.net)
Date: 09/21/04 

Date: Tue, 21 Sep 2004 16:40:44 GMT

Responding to Riemenschneider...

>>The RDB approach is the first approach.
>
>
> We'll have to agree to disagree. While what you describe may be your
> experience with RDBs, I'd have to say it is as bad a database design
> as leaving the associations off the class model. What you described
> sounds like what Date often refers to as logical-physical confusion.

We seem to be talking past one another again. Why do we always seem to
do that?

Every RDB I've ever seen provide schemas that that have embedded data
attributes for both tuple identity and referential attributes:

Customer:
   Customer Name // values: "ACE", "ACME", ... "Zephyr United"
   Address
   ...
   Contact Name --------+ // values: "Irving Frumpkin", "Joe Blow", ...
   ... |
                        |
Contact: |
   Contact ID <---------+ // values: "Irving Frumpkin", "Joe Blow", ...
   Phone Number
   ...

There are no pointers in that schema; all identity and referential
attributes have explicit identity values. More important, if you ask
for a join of Customer and Contact information, the RDB engine takes the
stored value of "Joe Blow" in Customer::Contact Name and does an index
lookup to find the Contact tuple with that Contact ID in order to
extract the data. 

-- 
*************
There is nothing wrong with me that could
not be cured by a capful of Drano.
H. S. Lahman
hsl@pathfindermda.com
Pathfinder Solutions  -- Put MDA to Work
http://www.pathfindermda.com
blog (under constr): http://pathfinderpeople.blogs.com/hslahman
(888)-OOA-PATH

Relevant Pages

  • Re: Relational database & OO
    ... It really doesn't matter to the time management problem solution whether the data is persisted in an RDB, an OODB, flat files, or clay tablets. ... So one could regard the DB Access subsystem I proposed as being a PSE from the perspective of the problem solution. ... I argue that the DB Access subsystem needs to deal with the particular persistence mechanisms that are at hand. ... Here is a basic example that you may find in a customer care & ...
    (comp.object)
  • Re: Help! Difficulty understanding DB -> Object mapping
    ... Solve the customer's problem first and then worry about how objects in that solution will map into tables in the RDB. ... If addresses are stored in a separate table, then the Customer_Address_ID should be in the Customer table, not the Order table. ... Product, not the OrderLineItem. ... access subsystem to properly access the RDB to obtain the information, ...
    (comp.object)
  • Re: Help! Difficulty understanding DB -> Object mapping
    ... > The first thing to do is forget about what the RDB looks like. ... > depends on the Customer identity, ... > Product, not the OrderLineItem. ... > To do that the persistence access subsystem needs to know more about ...
    (comp.object)
  • Re: Help! Difficulty understanding DB -> Object mapping
    ... If addresses are stored in a separate table, then the Customer_Address_ID should be in the Customer table, not the Order table. ... That's because things like product descriptions are unique to the Product, not the OrderLineItem. ... That allows you to address performance problems in RDB access in that subsystem or layer so that it does not affect your problem solution logic. ... The persistence access subsystem needs to map that notion of Order into the actual tables in the RDB. ...
    (comp.object)
  • Re: Queries and OO
    ... > this one of the reason why network databases was abandoned. ... the problem in hand and one instantiates them one at a time. ... index to an RDB table. ... First I can navigate to the customer object, ...
    (comp.object)