Association of Activities and Entities

The options available for associating activities with their associated entities are summarized in the table below. Card is an abbreviation for cardinality, or how many objects of the indicated type may participate in the association. This actually applies to any relationship from an entity-playing role A (here activity) of an association to an entity playing a role B (here the supertype Entity itself). The role A, role B aspect is just to indicate that associations have polarity, and this is weakly associated with which side or role the actual link can be found, and which direction the association is navigable.

Association method	Activity (or role A) Card	Activity (or role A) Subtype	Entity (or role B) Card	Entity (or role B) Subtype	Navigation	Advantages and Disadvantages
Use of Activity Entity_Id foreign key pointing to entity	One or many	Any	One	Fixed	Activity to Entity only unless the involved Activity types are known	Direct, fast
Use of Entity Activity_Id foreign key pointing to activity	One	Fixed	One or many	Any	Entity to activity only unless the subtype of involved entities is fixed and known	Direct, fast
Dedicated intersection table containing Ids of involved objects	One or Many	Fixed	One or many	Fixed	Bidirectional	Standard implementation of many-to-many relational associations but use of intermediate table imposes a join tax, and a distinct table is needed for every required combination of activity type and entity type to be associated.
Dedicated intersection table containing both the Ids and object types of involved objects (Assoc)	One or many	Any	One or many	Any	Bidirectional	Advantage: single table services the need for all activity-entity involvements; conveniently gives us a single place to carry the dependency graph info. Disadvantage: no delete semantics yet; imposes join tax; subject to abuse

The last of these methods deserves special mention. Physically, Assoc associations are carried in a distinguished Seabed internal table named Assoc_. This single table is used to implement all associations requiring flexibility in the data type of either or both participating objects. In database terms, it is an intersection table (supports many to many relationships) and has the property that it identifies the data type of the involved objects and identifies the objects (containing their respective primary keys � in Seabed E&P data, this is always a surrogate key called Id). This makes it useful for representing an association to an object in the subtype hierarchy rooted at a given object type X, and thereafter use the table to make an association with any subtype of X. For example, the Workflow for a gridding algorithm might define an input association with instances of a general Well_Marker data type, whereas the actual associations could be with subtypes (specializations) of Well_Marker like Well_Fluid_Feature_Marker, Well_Unconformity_Marker, and Well_Structural_Marker (this is an example

only, do not look for all these subtypes in Seabed). Applications conveniently access Assoc relationships through views specific to the object types they deal with. For example, the object type Generic_Activity makes use of several Assoc relationships, so the view Generic_Activity_Ref is provided to create and navigate the required Assoc relationships.

Seabed uses this Assoc association method to implement the associations between activity objects and their tracked input and tracked output data. Because of the unrestricted nature of Assoc associations, even many untracked associations between activities and entities are expected to be implemented using this method.