In summary, the answer to this question is: because unlike the general concept of an object type or class, the general concept of an association, as defined by UML, does not have a direct computational counterpart, neither in common object-oriented (OO) programming languages, nor in SQL. Only the simplest case of an association has a direct computational counterpart: a uni-directional functional association corresponds to a reference propertiy of a class in OO programming languages, and to a foreign key of a table in SQL. But then we still have bi-directional and non-functional associations not being directly supported in OO languages and SQL We could also express this in the following way:

Neither OO programming languages, nor SQL, do support associations as first class citizens.

Even in the definition of UML by the Object Management Group, which is the result of more than ten years work by hundreds of smart people, there was quite some confusion about associations until recently, when they finally (in 2012 with UML 2.5) clarified the concept of 'association ends' onwed by an associated class, introducing a new visual notation for reference properties represented by a uni-directional functional association, called the 'association end ownership dot'.

We can illustrate this correspondence with the help of two class diagrams. In the first diagram, on the right, the class Committee has a functional reference property chair, referencing the class ClubMember.

In the second diagram, on the right, the single-valued reference property chair is represented visually in the form of a corresponding functional uni-drectional association between the classes Committee and ClubMember. Notice the dot at the association end annotated with 'chair'. This dot indicates that the association end is owned by Committee, which is equivalent to the previous model where chair is a reference property of Committee.

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 second class diagram shown above, may classify the relationships FinanceCommittee-has-PeterMiller-as-chair, RecruitmentCommittee-has-SusanSmith-as-chair and BerlinRotaryClub-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.

A property defined for an object type, or class, is called a reference property if its values are references that reference an object from some class. For instance, the class Committee shown in the first class diagram above, has a reference property chair, the values of which are references to objects of type ClubMember.

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 tutorial 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) architecure. 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".

The following table provides an overview about the different cases of functionality of an association:

Table 1. Functionality types

Functionality type	Meaning
one-to-one	both functional and inverse functional
many-to-one	functional
one-to-many	inverse functional
many-to-many	neither functional nor inverse functional

Notice that the directionality and the functionality type of an association are independent of each other. So, a unidirectional association can be either functional (one-to-one or many-to-one), or non-functional (one-to-many or many-to-many).

When we make an information model in the form of a UML class diagram, we typically end up with a model containing one or more associations that do not have any ownership defined for their ends. When there is no ownership dot at either end of an association, this means that the model does not specify how the association is to be represented (or realized) with the help of reference properties. Such an association does not have any direction. According to the UML 2.5 specification, the ends of such an association are "owned" by itself, and not by any of the classes participating in it.

A model without association end ownership dots is acceptable as a relational database design model, but it is incomplete as an information design model for classical object-oriented (OO) programming languages.There are three options how to turn a model without association end ownership dots into a complete OO design model where all associations are either uni-directional or bi-directional: we can place an ownership dot at either end or at both ends of the association. Each of these three options defines a different way how to represent, or implement, the association with the help of reference properties.

You can read more about associations in general, and how they can be implemented with JavaScript, in the third part of my book on Engineering Frontend Web Apps with Plain JavaScript.