A leader of one of the consulting firms I’ve worked for in my career answered our title question by stating that “Data is structured, unstructured, or semi-structured”. That answer is the equivalent of saying that the package in which a product is delivered is the product. But his answer isn’t surprising, given the dominance of data engineering thought in the Data & Analytics industry today.

In the domain of business, data is simply the documentary evidence of human business action. Each attribute value is a language element describing an aspect of an action performed. And of course, we perform business action according to a pattern dictated by business process. 

Data without context is meaningless, and action is an abstract thing existing for a moment, which makes its context somewhat elusive. Further, data’s business use demands a contextual form that aligns it to the nature of business questions. 

Language isn’t just a communication mechanism. It’s the mental construct we use to perceive abstract ideas and give shape to abstract things.

Business questions are posed in a language narrative form. So, the data’s context as a description of action must be in a narrative form, as business questions are.

Peter Chen did not create Entity Relationship Modeling notation to merely define database tables, which is the limit to which most of the industry uses it today. He gave ER Modeling a semantic foundation to set data within a narrative context describing the business action that it is evidence of. 

Narrative gives mental shape to the abstract subjects of data, and the model of the narrative gives visual form to that narrative. In turn, this form is the basis on which we organize data solutions. 

The narrative focuses modeling on business reality, rather than engineering notions of data. It places attributes according to named functions that perform the action, as illustrated in Figure 1. By doing so, we not only create a foundational form for data solutions, we also “see” the errors, gaps, and ambiguity in the model’s narrative, to perfect the foundation. 

An entity names a function (a thing of action). The entity’s relationship verb phrase denotes the specific action it performs, in relationship to another function. Each attribute is evidence of one of the entity’s relationship actions. 

What an entity is, is what it does. Its function is defined by the action it performs, which its relationship predicates express. For instance, the following entity definitions summarize the predicate phrasing of its relationships:

• “A Policy Claim compensates for losses incurred in a Loss Incident, to fulfill the financial obligation of a Policy.”
• “A Claim Exposure is a basis of insurance carrier loss for a Claim, due to a requirement to compensate for a Loss covered by a Policy Coverage.”

An entity function may be, and each data attribute is, evidence of one of the entity relationship actions.

• The Policy Claim itself is evidence of Claimant action (not illustrated) in submitting a Claim. The action is made possible by the Policy’s action of giving standing and control as a basis for the submission. The Policy Claim’s Submission Date is evidence of the Claimant’s submission action. 
• Claim Exposure itself is evidence of an Adjuster’s action to establish a basis for Loss compensation based on applicable Policy Coverage. The Loss Estimate Amount and Loss Estimate Date are evidence of the Adjuster’s estimating action.

Status attributes of both functions are evidence of business process progression based on claim settlement, which are not included in the illustration.

The reasons for modeling business action in such detail are multiple. 

• The narrative of action forces the modeler to learn the business rather than modeling words, engineering fantasies, and/or obfuscations.
• It grounds the model in the real-world of the business architecture, instead of the system architecture.
• It provides a business language basis for communicating and validating the model with the business.
• It aids normalization by indicating misplaced attributes that have nothing to do with the actions associated with the function. It may also indicate missing relationships.
• It aligns a data solution’s definition and structure with the basis of business questions, which eliminates a significant source of solution dysfunction. 

Relationship narratives are far more

important than entity definitions in model development because they force the shaping of the model’s logical relationships according to actions that answer the interrogatives of business questions. 

• Who performed a specific action and the nature of that action. 
• What exactly was done by the function’s action
• Where an action occurred
• When the action occurred
• How was the action performed 

A robust relationship action narrative is the key component of overall model development, ensuring the entirety of the data’s functional context is modeled. By explaining the action of one entity’s function to another, the involvement of other functions not yet modeled is often exposed. In our example, the Adjuster’s action narrative with Claim Exposure identifies the need for Coverage to establish a basis for the Claim Exposure. The Policy Coverage relationship provides this support. 

Additionally, modelers who do not understand business functions often obfuscate the interrogative basis of entities by tacking extraneous words, such as info, detail, profile, level, layer, etc., onto the entity names. The narrative of action grammatically exposes this muddling of entity function.

Once the data’s natural definition and narrative structure is modeled, engineering can make intelligent decisions to shape its foundational structure into physical solutions that meet business needs. It doesn’t just form a basis for relational solutions, but does so for any organization of data, including dimensional design. Dimensional denormalizations must still be based on logical business relationships. And each data attribute must carry the context of the function it describes into reporting, through its name and definition which are established in the narrative modeling process.

The data modeling community and model software vendors claim that data modeling is like creating a blueprinted design for a new building. They imply it guarantees data solution success. But they offer little more than the engineering packages of Universal Data Models, Anchor Models, Data Vault Models, Dimensional Models, Canonical Models, and others as the product.

The product definition of data, as evidence of business action, is only realized when data’s packaging created by engineering delivers data as evidence of human action according to its natural narrative of business function.

The power of Entity Relationship modeling is its capacity to express data’s context according to its action narrative, if we would only learn to do so.