Modeling Verb Phrases

Author: Kenny Yu, PhD

This document is supplementary to Unified Semantic Model for Types, Attributes, Relationships and Behaviors, by the same author. The reader is advised to refer to that article to understand how this fits into the unified model.

Meaning of business rules can be encoded in sets of triples, each triple being like the subject, verb and object of an elementary sentence. These triples can be expressed as two classes and a relationship between them with the relationship being further described by a name and two end labels. This structure turns out to be a natural way to describe the vast majority of the data processed by machines.

The relationship among a bank branch, a cashier and a branch manager can be modeled as follows:

The relationship has a description and labels. The labels on the ends of the relationship line drive the GUI. The label “Cashier” appears on the Branch view panel pointing to a list of cashiers, as follows:

The notations RA and RU are explained below.

The description of the relationship, unlike in UML, determines the precise dependency among the object and the relationship and specifies implementation. The specified implementation, in the form of multiplicity and mapping tables and foreign key constraints with or without cascade condition reduces the need for coding that is profusely generated by developers to manage relationships.  On an RDBMS, all relationship should be modeled with mapping tables. The [Branch – Cashier] relationship is “Association”, or RA, which fully depends on both ends. If a branch closes or a cashier quits, the relationships ends. On the database, this is expressed on the table RA(master_id, detail_id) with two foreign key constraints, both having “on delete cascade” condition.

The [Branch – Manager] relationship, however, is stronger since a branch cannot function without a manager. On the database, this is expressed on the table RU(master_id, detail_id) with two foreign key constraints. The master_id has “on delete cascade” condition, but the detail_id has none. This forces the relationship to be broken before a manager can be dismissed.

The [Customer – Account] relationship is more complex since there can be joint accounts:

The association relationship is inappropriate here since it does not describe the dependency of the account on all the joint customers. A customer cannot be removed without changing the nature of the account. Both the creation and the existence of the account depend on the customers. The dependency is one-way in that the account can be removed without affecting the existence of the customers. On the database, this is expressed on the table RH(master_id, detail_id) with two foreign key constraints. The detail_id has “on delete cascade” condition, but the master_id has none. This forces the account to be deleted (logically) before the customers can be deleted.

Another strong relationship is coagulation, in which the creation of both the primary and the secondary are independent. Removal of the primary or the secondary fails if the primary-secondary relationship exists. An example is the interaction of drugs under certain conditions. All of them may be created independently. But once they form this relationship, none of them can be deleted. In semantic network terms, this is “functionally interacts with” relationship (see Page 17 of Unified Semantic Model).

The unified semantic model identifies six relationship types that help enforcing business rules (see Page 4 of Unified Semantic Model).  While the description and labels serve to communicate the relationship semantics to the user and the designer, the unified implementation of the relationships manages relationships without the developers writing code.