Follow @DBDebunk Follow @ThePostWest

“... In ORM there is no concept of an entity record (tuple), although relational tables can be automatically generated from an ORM model (furthermore, guaranteed to be fully normalized).” --Online comment

“Object Role Modeling (ORM) is a ...a fact-oriented modeling approach for specifying, transforming, and querying information at a conceptual level. Unlike [other modeling approaches] ... fact-oriented modeling is attribute-free, treating all elementary facts as relationships ... In practice, ORM data models often capture more business rules, and are easier to validate and evolve than data models in other approaches. --ORM.net

               --------------------------------------------------------------------------------------------------------

SUPPORT THIS SITE
This content here is not available anywhere else,  except in regurgitations and hallucinations of  LLMs, potentially mixed with other garbage.  If you deem it useful, particularly if you are a regular reader, please help upkeep it by purchasing papers, donating, or contact me for online seminars/consulting.

USING THIS SITE
- To work around Blogger limitations, the labels are mostly abbreviations or acronyms of the terms listed on the SEARCH  page. For detailed instructions on how to understand and use the labels in conjunction with that page, see the ABOUT page. The 2017 and 2016 posts, including earlier posts rewritten in 2017 were relabeled accordingly. As other older posts are rewritten, they will also be relabeled. For all other older posts use Blogger search.
- The links to my AllAnalytics columns no longer work. I re-published only the 2017 columns @dbdebunk, and within them links to sources external to AllAnalytics may or may not work.

 

SOCIAL MEDIA
You can follow me @LinkedIn, and ThePostWest on X.

               -------------------------------------------------------------------------------------------------------

Fundamentals

As we explain in WHAT MEANING MEANS: BUSINESS RULES, PREDICATES, CONSTRAINTS, AND SEMANTIC CONSISTENCY, there are four kinds of models in data management, three of which correspond to levels of representation (conceptual, logical, and physical), the fourth is a data model—a formal logic data theory used to produce logical models (LM) of the theory from conceptual models (CM).

A CM is a model of information—a collection of business rules (BR)—statements in natural language that describe object (entity, group, multigroup) types by specifying their properties:

·         1^st and 2^nd order properties (1OP,2OP) of entities;

·         3^rd order properties (3OP) of groups;

·         4^th order properties (4OP) of  the multigroup.

and is the source of meaning (semantics). When the meaning is assigned to a data model/theory, the theory acquires an interpretation, producing a formal logical model (LM) of the theory—essentially an application of the theory to the aspect of reality modeled by the CM for database representation. The LM is a model of data (not information!), but not a data model.

·         Attributes represent conceptual entity properties at the logical level;

·         Tuples represent conceptual entities at the logical level;

·         Records represent logical tuples at the physical level;

All this is fundamental and should not be controversial, but is either abused,  ignored, or both in industry practice.

“Attribute-Free”?

ORM is a conceptual modeling approach. Aside from the explicit claim to that effect,

·         It models information (not data)—it is “fact-based”, and facts are the elements of  information.

·         It “captures business rules” (BR), which are components of CMs.

So “ORM models” are CMs.

If ORM CMs are fact-based and capture BRs, facts and BRs must be related.

A fact type is a general pattern (or predicate in logic), for example,

Person was hired on Date.

of which a fact is then an instance (an instantiation of the predicate)—a true proposition in logic), for example:

 John Smith was hired on 5 January 1995.

Here’s how Codd refers to them:

“The individual description for an individual object is called an entity. The prototype description for a class of objects is called an entity type.”

From all the above it follows that:

·         A fact type is essentially a BR that describes an object type (here, a person entity type) by specifying its defining properties (here, hire date);

·         A fact is a BR that describes an object (entity) of that type (here, person John Smith) by specifying its property values (here, 5 January 1995)

Properties in a ORM CM are represented by attributes in the corresponding LM. This is why database relations (not relational tables!) can be generated from an ORM CM—had ORM been “attribute-free”, this would have not been possible.

Database relations (not “relational tables”) generated from ORM CMs will be fully normalized (in 5NF) not just normalized (in 1NF) iff the generator produces a relation from each fact type.

Notes: Attributes do not appear in ORM CMs because they are logical, but their conceptual counterparts, properties do, and “attribute-free” creates a misleading impression. A claim of “attribute-free” was also made with respect to E/RM, and I demonstrated otherwise (ON PROPERTIES & CHEN'S E/RM).

No “entity records (tuples)”?

Similarly, the claim that in ORM there is no concept of an entity record (tuple) is also misleading.

Tuples are not “entity records” (whatever that means)—they are logical representations of conceptual facts (ORM), or of entities (Codd)—which are essentially the same thing.

ORM models are CMs, not “data models”.

It is to avoid such confusions that I advocate the three-fold terminology conceptual modeling, logical database design, and physical implementation,