Managing Conditions and Effects of Interactions

This document is supplementary to Unified Semantic Model for Types, Attributes, Relationships and Behaviors, by the same author. The focus of this document is on the rationale for establishing the relationship types.

A relationship represents a semantic triple, each triple being like the subject, verb and object of an elementary sentence. The infinite number of nuance can be expressed with a description and one label on each end of the relationship, like the following:

While entire prose can be written in this form, such specification of interactional relationships is incomplete and directly convertible into implementation. The dependencies, conditions and effects associated with the relationships are unexpressed. A data management system needs to go under the nuance and regulate the data elements.

We aim not only to express the conditions and effects of the interactions but to provide an infrastructure for their implementation. When standardized pre-fabricated implementation is provided, specification becomes a selection of the elements of the implementation.

Relational triple

The semantic triple is translated into a relational triple: the primary (P), the relationship (R) and the secondary (S). The relational triple serves as the carrier for the semantic triple. We seek to find the behavioral patterns of the relational triples as far as condition and effect of the interactions are concerned. On a RDB, the relationship instance as an object is not always clear because a relationship can be expressed as a foreign key between two columns in separate tables. Techniques available for implementing the interactions are 

1. No cascading. This prevents deleting P if S exists.
2. Delete cascading. This ensures P and S are deleted simultaneously
3. Delete set null. This allows P and S to exist independently.
4. Non-nullable foreign key ensures P to be the creational condition for S.

Relationship instance as object

These techniques are adequate for expressing creational and existential conditions for one-to-many heterogeneous relationships where P and S are in different tables. For the sake of generality and uniformity, we use mapping tables to implement all relationships. A relationship instance (R), therefore, is an object of a relationship class that fully describes the semantics of the relationship. A mapping table has four columns:

P_id  -- id of P

S_id – id of S

Relationship_id – id of the relationship class

Modifier – time, location or any description of this relationship instance

Let’s explore the patterns of the interactions. Bear in mind that P can always be created independently.

Creational dependency for S and the consequences

If the creation of S depends on P, we use a foreign key constraint on the P end of R. The deletion of P is logically constrained: It must either cascade to R then to S, or be stopped by the existence of R.

Since S can only be created once, the S_id column must have a uniqueness constraint.

Temporally speaking, P must exist prior to R and perish posterior to R. R and S co-exist and co-perish. P.endRelation() method must delete the related S.

Since the cascade conditions on R from S are determined, the variations in these relationship types are cardinality. Without the restriction on the multiplicity of S, that is, allowing one-to-many and many-to-many relationships between P and S, there are four possible combinations of multiplicity and cascade:

	Deletion of P cascades to S	Deletion of P does not cascade to S
One-to-many	1. Composition Notation:	2. Derivation Notation:
Many-to-many	3. Not  useful	4. Hybridization Notation:

The diamond-shaped end indicates the entity is the container or originator.

Case 1 is the typical “part of” relationship, applicable to order and item. Case 2 describes causal or consequential or sequential relationships, such as order and return. In case 3, a number of entities have joined to create S. Withdrawal of one of the participants causing S to be destroyed is excessively disruptive. Case 4 is a more reasonable situation in which S has to be removed before the P’s can be deleted.

While it is possible to establish one-to-one relationships in both Cases 1 and 2 by placing a uniqueness constraint on the P end of the relationship, there are two arguments against doing so:

1. This falls in the realm of pure application logic, rather than data integrity
2. For practical purposes, P and S are indeed two parts of one entity.

Relationships among independent entities

If the creation of both P and S are independent, their deletion must be so. The question becomes how their deletion affects the relationship or whether the relationship prevents their deletion. Since they are created independently of each other, there is no means of limiting their multiplicity.

The two variables are two ends of the relationship and the values are cascade or no cascade, as summarized below:

	Deletion of P cascades to relationship	Deletion of P does not cascade to relationship
Deletion of S cascades to relationship	1. Association Notation:	2. Utilization Notation:
Deletion of S does not cascade to relationship	3. Utilization Notation:	Coagulation Notation:

The circle-shaped end indicates the entity is “in use”.

Cases 2 and 3 are symmetrical and only one is needed. Case 1 represents a free party for the participants who can join and quit. An example for Case 1 is committee and person. A committee has many persons and a person can be on many committees. A committee and dissolve and a person and quit from a committee. Case 2 can describe the relationship between tasks of a project. Some tasks are dependent on others.  The ones that have dependents are on the P side of the relationship and “in use”. The ones on the S side can be removed. Case 4 describes a tied-up co-occurrence. Most such co-occurrences produce results, and thus are better modeled with hybridization relationship. Coagulation can be used to describe the relationships between lightning and thunder in a system that tracks cloud (with attributes of height, thickness etc.) interactions.

Semantic Island

With the relationship types we identified and the corresponding notations, we can explore a situation where entities in a system are dead-locked into an island formation. An intelligent system should be able to identify such island formations and breakpoints.

In the following diagram, ABCD form a deadlocked island with no breakpoint. The must be processed as one unit.

In the next diagram, the seemingly island formation has a breakpoint at E.