Relationships are Not Verbs
In conceptual (“ontological”) data modeling, relationships describe the structure of the connections between pairs of entity types. It is therefore inappropriate to use the part of speech that describes actions—that is to say, verbs—to describe them. Rather, since a model is intended to describe simply “what exists”, the structure should be represented by prepositions and prepositional phrases. What is the relationship of instances of one entity type to instances of another entity type? The only verb involved is “to be”—possibly in the form of “must be” or “may be”.
The year 2020 so far has produced three new books on data modeling. Each of these attempts to introduce a particular way of modeling that is oriented towards the business people whose enterprises ostensibly are being modeled.
All three are very good at defining the nouns (the things of significance) in a domain. But where relationships among those things of significance should be describing static structure, each of these authors instead use verbs to describe, in effect, what one entity type does to the other entity type. This is the domain of process modeling, not data modeling. For this reason, these books represent a very good canvas on which to make the arguments here.
- Steve Hoberman: The RoseData Stone: Achieving a Common Business Language using The Business Terms Model
- Joseph Danielewicz: Models, Metaphor, and Meaning: How Models Use Metaphors to Convey Meaning
- Ron Ross: Business Knowledge Blueprints Enabling Your Data to Speak the Language of the Business
Among other things,, the models presented here appear to be playing the role of enterprise “ontologies”. The word onto-logy was a 17th century construction (“study of things”) to describe the branch of philosophy that in fact originated with Aristotle in the third century BCE, as the study of being or the essence of things that exist.
In modern times, the term is used to describe any catalogue of terms describing the things that are assumed to exist:
- In a domain of interest
- With rules governing how these terms can be combined to make valid statements,
- Along with sanctioned inferences that can be made.
Think of “ontology” as the world’s first three-thousand-year-old hot new buzzword.
All three of the authors described here are very good about capturing the names of things that are assumed to exist—or at least categories of those things. (The boxes these gentlemen are presenting in their diagrams represent entity types—classes of things—not entities—the things themselves.) What is noteworthy is that these categories of things are labeled with nouns. The means for arriving at definitions for nouns is well established (also by Aristotle).
This is unfortunate for several reasons:
First, since our objective here is to describe what exists, the only verb that applies is “to be”. These are assertions that a relationship exists.
Second, the part of speech that is a verb describes processes and functions. The definition of a thing that exists does not include what actions it may take on another thing. The part of speech that describes the structure between two classes is the prepositional phrase. Remember Sesame Street and how Grover taught you about “over”, “under” and “around”?
Now Douglas Adams has something to say about defining relationships correctly. “the editors of The [Hitchhiker’s] Guide [to the Galaxy] got sued by the families of those who had died as a result of taking the entry on the planet Traal literally (it said ‘Ravenous Bugblatter Beasts often make a very good meal for visiting tourists’ instead of ‘Ravenous Bugblatter Beasts often make a very good meal of visiting tourists’
Picking the right word (even if it is a preposition) is important.
UML is a remarkable notation precisely because it does not describe data in terms of their structure. Rather it describes each class (analogous to an entity type) in terms of its “behavior”. This behavior then describes how it acts upon other classes. That’s fine for the object-oriented world, but if we are to define the nature of what things exist and how they are related to each other, this definition should not include a description of what one may do to another.
At about the same time (in the 1980s that James Martin and Clive Finklestein were inventing Information Engineering, Richard Barker and his colleague Harry Ellis came up with a different approach to naming relationships:
<subject entity type>
one and only one
one or more
<object entity type>.
For example, “each Project Assignment must be of one and only one Person.” (This is the first example shown in the next section below.) Here, while the structure is determined by the modeler, each of the phrases underlined here is for the business-oriented subject matter expert to evaluate as to whether it is true or not. So in this case, is it possible that you can have a Project Assignment without a Person? Can a Project Assignment be of more than one Person?
My evaluation of these three books was intended to appear in The Data Administration Newsletter, but so far only the first two have appeared. The review of Mr. Ross’ book is pending.
Unfortunately, in this newsletter, I couldn't insert the diagrams from Steve's book, so a summary of what I wanted to present here is attached to this posting.
 Steve Hoberman, 2020. The Rosedata Stone: Achieving a Common Business Language using the Business Terms Model. Technics Publications, LLC.
 Joseph Danielewicz. 2020.. Models, Metaphor, and Meaning: How Models Use Metaphors to Convey Meaning. Kindle Direct Publishing.
 Douglas Adams. 1982. The Restaurant at the End of the Universe. New York: Pocket Books, pp. 37–38.
 Aristotle. 323 BCE. Posterior Analytics, Book II. From Great Books Foundation, Ninth Year, Volume Two. Page 1.
 Armstrong Laboratory AL/HRGA. 1994. Information Integration for Concurrent Engineering. Knowledge based Systems, Inc.
 Thomas A. Bruce. 1992. Designing Quality Databases with IDEF1X Information Models. Dorset House.
 James Martin. 1987. Recommended Diagramming Standards for Analysts and Programmers.
 David Hay. 2020. "Relationships are not Verbs". The Data Administration Newsletter. [ https://tdan.com/relationships-are-not-verbs-part-one/26996 ]