features matrixintro pageOODBTG Reference Model
A "relationship" ("association") is a logical relationbetween instances of one or more classes of objects. Relationships canbe binary or n-ary. Binary relationships may be one-to-one, one-many, ormany-many.
In generalized object models, a relationship may be realized as a separateclass, as an operation along with its result, as a separate modeling construct,or not at all. In different object systems, relationships can be established,traversed, or removed, and may be system or user defined. In differentsystems, the implementation of relationships may be unidirectional or bi-directional.
OMG Core Object Model
See entry under 9. Noteworthy Objects.
OMG CORBA IDL
Not addressed.
ODMG
Relationships are a kind of property defined between two mutable objecttypes. Relationships are not objects.
A relationship can be one-to-one, one-to-many or many-to-many. Relationshipsare defined in the interface(s) of the object type(s) involved in the relationshipas a "traversal path" from one type to another. A two-way relationshipwill have a name in each type interface, and an inverse" clause ineach path declaration.
EXPRESS
"In EXPRESS the declaration in one entity data type (the declaringentity) of an attribute whose domain is another entity data type (the representingentity) explicitly establishes a relationship between these two data types.This relationship is referred to as a simple relationship, and relatesan instance of the declaring entity to one instance of the representingentity." [ISO DIS-10303:11]
The cardinality of this relationship gets considerably more complexas aggregate types and inverse attributes are added. The cardinality inthe forward direction of the relation can be constrained by use of variousaggregate data types. The cardinality of the reverse direction can be constrainedby explicitly naming the reverse direction as an inverse attribute of thesecond type representing entity and then once again making use of the variousaggregate data types for this inverse attribute.
It is common usage in the STEP community to explicitly model whole-partand other relationships using entities, although the language does notdirectly support this usage. It is likely that future versions of EXPRESSwill directly support the modeling of n-ary relationships as first-classobjects.
Open Distributed Processing
Treated as an Information Viewpoint concept where virtually any conceptof a binary relationship can be defined.
Management Information Model
The inheritance and containment relationships are explicitly representedin the management information model by subclassing and name binding, respectively.Currently, other relationships are represented by the use of attributeswhose values are pointers to related objects. Although these methods havebeen effective so far, much of the semantics of the relationships is hidden.
However, there is currently significant work going on in standards tospecify how a relationship between objects may be defined independentlyof the particular managed object classes that take part in it and independentlyof attributes that may be used to represent it [ISO/IEC CD 10165-7, GRM].It provides a general model and specification tools for the definitionof relationships among managed objects in order to promote a better understandingof relationships.
The MIS-User needs the ability to manage relationships that exist betweenmanaged objects. In order to provide a standardized technique for managingrelationships, a relationship model must be defined. The relationship modelmust satisfy the following requirements: [GRM]
- provide notational tools for specifying behavioral properties of arelationship, such as roles, cardinality and consistency constraints; [GRM+ US Comments]
- provide a mechanism to specify new relationship classes based on existingrelationship classes;
- provide a mechanism to specify generic reusable relationship classes(e.g., composition, dependency) that are common to multiple applications...[GRM]
A managed relationship is a manageable binding between managed objects,where the characteristics of at least one of the participating managedobjects, such as attribute values and behavior, are affected by characteristicsof the other participating managed objects. [GRM]
The GRM work also involves the definition of a Relationship Template,which defines the characteristics of a relationship and its roles, anda Relationship Binding Template, which defines the object classes thatmay be used to fulfill the roles of a relationship.
The general relationship model and specification tools are applicableon two levels:
- The specification of generic, re-usable relationship classes (e.g.,composition, dependency) that are common to multiple applications and thatare specified independent of how the relationship is represented in managedobject class definitions.
- The specification of relationships in terms of the characteristicsthat must be present in the managed objects participating in a relationship,including the specification of the characteristics required for the managementof the relationship.
Relationship behavior includes, for example, roles, cardinalities, andentry/departure rules. The relationship behavior is specified in termsof:
- Invariants that are in effect for the entire lifetime of the relationship
- Preconditions that identify the conditions valid just before the operations(e.g., adding, removing, and changing participants) used to manage therelationship can be carried out
- Postconditions that identify the conditions which must hold followingthe processing of an operation used to manage the relationship.
The specification tools in [ISO/IEC CD 10165-7, GRM] include the definitionof a relationship template, and a role binding template. Relationship templatesare defined for formally specifying the behavior of a relationship classand its supporting roles. Role behavior includes relationship cardinality,role cardinality, object class cardinality, whether dynamic entry and departureis allowed, and the packages that are (sometimes conditionally) presentin a managed object that fulfills this role. Additionally, a role bindingtemplate is defined for specifying which object classes may be used tofulfill the roles of a relationship class.
SQL3
Relations (tables) can be used to define generalized n-ary relationships,as in SQL92; referential and other integrity constraints can be definedon these tables. Columns whose types are reference types also allow modelingof relationships in SQL3. References to groups of objects can be specifiedusing rows containing (directly or indirectly) instances of the SQL3 MULTISET(..),LIST(..), and SET(..) collection types (see 9.5 aggregates).
Matisse
The Matisse metamodel specifies the structure of relationships. Inverserelationships are automatically supported. Referential integrity is guaranteedby enforcing the simple rule: "No object can be deleted until itslinks to other objects are deleted."
The metaclass supports specification of cardinality of a relationship.It also includes user-specified triggers that fire before and after addingor deleting a link.
At the metaclass level, a relationship is a class that is physicallystored as a first class object. At the class level, a relationship is anobject with instantiated values of the attributes that are specified atthe metaclass level. An the instance level, a relationship is physicallystored as an OID(s) of a related object(s).
Smalltalk
The most common relationships in Smalltalk are the inter-class relationshipsdefined by the inheritance class hierarchy. In addition, an object is relatedto another object when it has a pointer to that object. Most implementationsof Smalltalk include support for "dependency" using these instancerelationships. This serves the need to link objects together and coordinatethe behavior between them. An example of this would be for one object toknow when a variable value change occurs in a "dependent" object.
Eiffel
A relationship between two classes is established when one class declaresan attribute, parameter or local variable, of the other class's type. Thisis a `client-supplier' relationship. The client is the class using theservices of the other. The supplier class is the class that provides theservices required by the client. The client-supplier relationship is one-way,it can only be traversed from the client side.
See also entry under 8. Inheritance and Delegation.
System Object Model (SOM)
Not addressed.
Analysis and Design Methods
SA: Relationship includes ordinary ERDrelationships and the 'is-a' relationship for sub/supertyping and inheritance.Relationships are not considered to be objects.
CA: 'Association,' is used, defined generallyas "the union or connection of ideas." The technical meaningdoes not seem to be defined explicitly. This term corresponds to the term'relationship' as used by others. Associations are not considered to beobjects.
RA: "A link is a physical or conceptualconnection between object instances." Links are not considered tobe objects.
"An association describes a groupof links with common structure and common semantics." The terms 'link'and 'association' correspond to the term 'relationship' as used by others,while distinguishing between instances of relationships and the class ofall such instances.
"A link attribute is a propertyof the links in an association."
"A role is one end of an association...whichmay have a role name."
"A qualified association relatestwo object [classes] and a qualifier. The qualifier is a special attributethat reduces the effective multiplicity of an association. One-to-manyand many-to-many associations may be qualified. ... Qualification usuallyreduces multiplicity from many to one, but not always."
JA: "The models objects [instances]... have relations with each other. ... These relations can be of two sorts.First, static relations, namely relations existing over a longer period,which means that two objects know about each other's existence. Secondly,dynamic relations, namely relations by which two objects actually communicatewith each other. There is an abundance of different static relations inconnection with semantic modeling" Relationships are not consideredto be objects.
Inheritance relations are an associationbetween classes.
"A class association ... is an associationbetween classes."
An instance association is an associationbetween instances.
"An acquaintance association isa static association between instances and means that the instance knowsof the existence of another instance."
"A communication association modelscommunication between two objects. Through these associations, an objectsends an receives stimuli."
"There is a large and fundamentaldifference between data modeling and object orientation. In data modeling,you think of the model as a flat structure viewed from above. In this wayit is natural to see the relationship as a binding between two objects.The relationship here is often bi-directional. In object orientation, however,the view is instead made from an object [instance], you place yourselfat an object and then see what references you have to other objects. Thisfundamental difference is hard to get used to for people used to data modeling."
WD: Types of relationship include: "depends-upon,""has-knowledge-of," "is-analogous-to," "is-kind-of,"and "is-part-of." Relationships are not considered to be objects.
MD: [A] "field [of an object, and,likewise, an attribute of a class] may contain references to other objects."The relationships indicated by these references are to objects. Relationshipsare not considered to be objects.
EA: "A relationship establishesa logical connection among objects." "A relationship set is aset of relationships where each matches the same template ["with objectclasses designating slots for objects and phrases that express a logicalconnection among the objects"] and has as its name the text of thesame template." "Special types of relationship sets include...the is a relationship set, the part of relationship set, and the is memberof relationship set." Relationships are not considered to be objects.
FA: "A relationship is a tuple ofobjects..." "The object model shows classes, not objects. Thuswe extend the notion of relationship to classes. In the object model arelationship is used to model the idea of associations or correspondencebetween the objects belonging to classes." Relationships are not consideredto be objects.
OA: "Associations provide a meansto link objects of various types in a meaningful way. While object typesinvolve sets of objects, associations involve connections of objects betweensets. ... This collection of connections between object types forms a specialkind of object type called a relationship type. Furthermore, using theseconnections enables us to map the objects of one set into objects of another-andback again. Together, relationship types and mappings are two techniquesfor describing associations between objects."
BD: "In all, there are three kindsof class relationships[:]" generalization/specialization, whole/part,and association. Association is "[a] relationship denoting a semanticconnection between two classes."...A "link [b]etween two objectsis one instance of an association." Associations do not indicate direction;links are unidirectional.
HA: "Relationships between classes... are association, aggregation and generalization." "Associationis a meaningful relationship between two O/Cs such that one O/C may requesta service from another. This represents the direct use of the servicesof one O/C by another"
NA: "Relation[:] A dependency betweentwo entities; used ... as an abbreviation for the term relationship."There are three kinds of relationships. "Only two kinds of staticrelations are needed in object oriented systems, inheritance relationsand client relations." "For the [dynamic] relationship betweena calling object and the callee, we use the term ... message relation ..."features matrixintro page