Table of Contents
- 1. References and Reference Properties
- 2. Referential Integrity
- 3. Modeling Reference Properties as Unidirectional Associations
- 4. Representing Unidirectional Associations as Reference Properties
- 5. Adding Directionality to a Non-Directed Association
- 6. Our Running Example
- 7. Eliminating Unidirectional Associations
- 8. Rendering Reference Properties in the User Interface
- 9. Collection Types for Multi-Valued Reference Properties
- 10. Quiz Questions
A property defined for an object type, or class, is called a reference
property if its values are references that reference an object of another, or
of the same, type. For instance, the class Committee shown in
Figure 8.1 below
has a reference property chair, the values of which are
references to objects of type ClubMember.
An association between object types classifies relationships between objects
of those types. For instance, the association Committee-has-ClubMember-as-chair, which is visualized as a connection line in
the class diagram shown in Figure 8.2 below, classifies the relationships FinanceCommittee-has-PeterMiller-as-chair, RecruitmentCommittee-has-SusanSmith-as-chair and AdvisoryCommittee-has-SarahAnderson-as-chair, where
the objects PeterMiller, SusanSmith and SarahAnderson are of type
ClubMember, and the objects FinanceCommittee, RecruitmentCommittee and AdvisoryCommittee are of type
Committee. An association as a set of relationships can be
represented as a table like so:
| Committee-has-ClubMember-as-chair | |
|---|---|
| Finance Committee | Peter Miller |
| Recruitment Committee | Susan Smith |
| Advisory Committee | Sarah Anderson |
Reference properties correspond to a special form of associations, namely to unidirectional binary associations. While a binary association does, in general, not need to be directional, a reference property represents a binary association that is directed from the property's domain class (where it is defined) to its range class.
In general, associations are relationship types with two or more object types participating in them. An association between two object types is called binary. In this book we only discuss binary associations. For simplicity, we just say 'association' when we actually mean 'binary association'.
While individual relationships (such as FinanceCommittee-has-PeterMiller-as-chair) are important information items in business communication and in information systems, associations (such as Committee-has-ClubMember-as-chair) are important elements of information models. Consequently, software applications have to implement them in a proper way, typically as part of their model layer within a model-view-controller (MVC) architecture. Unfortunately, many application development frameworks lack the required support for dealing with associations.
In mathematics, associations have been formalized in an abstract way as sets of uniform tuples, called relations. In Entity-Relationship (ER) modeling, which is the classical information modeling approach in information systems and software engineering, objects are called entities, and associations are called relationship types. The Unified Modeling Language (UML) includes the UML Class Diagram language for information modeling. In UML, object types are called classes, relationship types are called associations, and individual relationships are called "links". These three terminologies are summarized in the following table:
| Our preferred term(s) | UML | ER Diagrams | Mathematics |
|---|---|---|---|
| object | object | entity | individual |
| object type (class) | class | entity type | unary relation |
| relationship | link | relationship | tuple |
| association (relationship type) | association | relationship type | relation |
| functional association | one-to-one, many-to-one or one-to-many relationship type | function |
We first discuss reference properties, which implicitly represent unidirectional binary associations in an "association-free" class model (a model without any explicit association element).
A reference can be either human-readable or an internal object reference. Human-readable references refer to identifiers that are used in human communication, such as the unique names of astronomical bodies, the ISBN of books and the employee numbers of the employees of a company. Internal object references refer to the computer memory addresses of OOP objects, thus providing an efficient mechanism for accessing objects in the main memory of a computer.
Some languages, like SQL and XML, only support human-readable, but
not internal references. In SQL, human-readable references are called
foreign keys, and the identifiers they
refer to are called primary keys. In
XML, human-readable references are called ID
references and the corresponding attribute type is
IDREF.
Objects in an OO program can be referenced either with the help of
human-readable references (such as integer codes) or with internal object
references, which are preferable for accessing objects efficiently in main
memory. Following the XML terminology, we call human-readable references
ID references. We follow the standard
naming convention for ID reference properties where an ID reference
property defined in a class A and referencing objects of
class B has the name b_id using the suffix
_id. When we store persistent objects in the form of records
or table rows, we need to convert internal object references, stored in
properties like publisher, to ID references, stored in
properties like publisher_id. This conversion is performed as
part of the serialization of the object by assigning the standard
identifier value of the referenced object to the ID reference property of
the referencing object.
In OO languages, a property is defined for an object type, or class,
which is its domain. The values of a
property are either data values from
some datatype, in which case the property is called an attribute, or they are object
references referencing an object from some class, in which case
the property is called a reference property. For instance, the class Committee shown in
Figure 8.1 below
has an attribute name with range String, and a
reference property chair with range
ClubMember.
Object-oriented programming languages, such as JavaScript, PHP, Java and C#, directly support the concept of reference properties, which are properties whose range is not a datatype but a reference type, or class, and whose values are object references to instances of that class.
By default, the multiplicity of a property is 1, which
means that the property is mandatory and functional (or,
in other words, single-valued), having
exactly
one value, like the property chair in
class Committee shown in Figure 8.1. When a
functional property is optional (not mandatory), it has the
multiplicity 0..1, which means that the property's minimum
cardinality is 0 and its maximum cardinality is 1.
A reference property can be either single-valued (functional) or
multi-valued (non-functional). For
instance, the reference property Committee::chair shown in
Figure 8.1 is
single-valued, since it assigns a unique club member as chair to a club.
An example of a multi-valued reference
property is provided by the property Book::authors shown in
Figure 8.11
below.
Normally, the collection value of a multi-valued reference property is a set of references, implying that the order of the references does not matter. In certain cases, however, the order matters and, consequently, the collection value of such a multi-valued reference property is an ordered set of references, typically implemented as a list. Only rarely, the collection value of a multi-valued reference property may be a, possibly ordered, multi-set (also called bag).