Relationship Object

[See SymmetricalReference for context.]

My interpretation is an object that serves to define a relationship between two other objects. An example might be a dependent EJB object that serves to resolve a many-many relationship between two entity beans. --JohnHarby

IMHO, all attributes arise out of relationships. Objects do not have any attributes themselves. --Todd

Your comment above strikes a responsive chord with some thoughts I recently had about relationships (associations) in the context of relational database-based applications. Except I used "many", even "most", but I never got to "all". Please share your thoughts further. --JimRussell

If you do a lot of design and you consider issues at a deeper level, it seems that all attributes come from relationships. It is, however, inconvenient to make models this way so we tend to toss attributes into records/objects. I maintain all attributes arise out of relationships and have yet to see a counter. Objects/records simply supply identity. The relationship may be with space or time or other concepts that traditionally have not been modeled. --Todd

How about attributes like date of birth, SSN, Postal Code, IP address, auto license plate number, SIC code, race, blood type, hair color, country code, domain name, etc.?

SSN is relation with the social security admin. Postal Code is in relationship with a geographical area, time, governing body. Our has changed once. IP addresses our relationship with your ISP (or whatever). Race is in relationship with whatever group is defining what constitutes race, there are many opinions. Hair color is in relation with time. Etc. Drop what is in relation-to and the attributes either go away or aren't really accurate. Hair color changes with time, may change with diseases, etc. Time is an important relationship yet is normally ignored for pragmatic reasons. If the agency giving you the SSN doesn't exist then you don't have an SSN, thus i think the attribute is properly part of the relationship and not the thing in itself. -- Todd

I recently attempted an "ultra-normalized" database design, which combined minimalist entity tables (enterprise, person, phone, street address, city, country, etc.) with a many-to-many three column association table for every pair of entity tables where a relationship existed. (The third column, "role", an attribute of the relationship, took values such as employer, customer, voice, fax, mobile, modem, home, ship to, bill to, etc.) I was struck by how few entity table attributes I was left with, and how much information was represented by the relationships -- including information that was not anticipated in the initial systems design.

But I was left with attributes like those above, mostly externally assigned, or inherent to the entity. (I also reinforced my opinion that classification-related assignments need to be kept separate from entity attributes, but that is another discussion). -- JimRussell

Objects/records simply supply identity.

I've discovered that "non-object" attribute values are always a kind of foreign key. If they don't refer to other objects, they are values where the identity and value are the same. Hence the attribute is the key and the target value, all at once.