Follow @DBDebunk Follow @ThePostWest


In Part 1 we presented some foundation knowledge with which to debunk misconceptions lurking in the "data models" mess in the industry that Friesendal has tried to catalog. In Part 2 we applied this knowledge to the first two industry "data models" considered by Friesendal, the E/RM and the RDM. In Part 3,  we applied it to OO/UML and (a yet formally undefined) "GDM". Here we apply it to fact modeling (FM).

Fact Modeling

“... another school of modelers working with "fact modeling". Their approach is not new. It goes back to the 70's, where Eckhard Falckenberg and Sjir Nijssen started working on the approach (in parallel). Fact Modeling was known for many years as Object-Role-Modeling (ORM), and it was supported by the popular Visio diagramming tool at the time that Microsoft bought the company behind Visio. I like Nijssens name “Binary Relationship Modeling” a lot and it has been in the back of my head since the early 80's. Fact Modeling is definitely at the right level (concepts and their relationships), but it also contains all of the logic details required for formal, precise specifications. The visual syntax goes back to: Nijssen, G.M. and T.A. Halpin, Conceptual Schema and Relational Database Design — A fact oriented approach, Prentice Hall 1989.”

• The Key to Relational Keys: A New Perspective. 
• THE DBDEBUNK GUIDE TO MISCONCEPTIONS ABOUT DATA FUNDAMENTALS, my latest book, is available to order here (Reviews: Craig Mullins, Todd Everett, Toon Koppelaars, Davide Mauri).
• Logical Symmetric Access, Data Sub-language, Kinds of Relations, Database Redundancy and Consistency, paper #2 in the new UNDERSTANDING OF THE REAL RDM series, is available for ordering here.
• Interpretation and Representation of Database Relations, paper #1 in the new UNDERSTANDING OF THE REAL RDM series, is available for ordering here.

• To work around Blogger limitations, the labels are mostly abbreviations or acronyms of the terms listed on the FUNDAMENTALS page. For detailed instructions on how to understand and use the labels in conjunction with the 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. 
• Following the discontinuation of AllAnalytics, the links to my columns there no longer work. I moved the 2017 columns to dbdebunk and, time permitting, may gradually move all of them. Within the columns, only the links to sources external to AllAnalytics may work.

• @DBDdebunk on Twitter: will link to new posts to this site, as well as To Laugh or Cry? and What's Wrong with This Picture posts, and my exchanges on LinkedIn.
• @The PostWest blog: Evidence for Antisemitism/AntiZionism – the only universally acceptable hatred – as the (traditional) response to the existential crisis of decadence and decline of Western (including the US)
• @ThePostWest Twitter page where I comment on global #Antisemitism/#AntiZionism and the Arab-Israeli conflict.

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

Points arising:

• Fact modeling (FM) has been around from late 80s under various names (the industry has a knack for promoting re-labeled, often distorted, old stuff as new[1,2,3,4]). We have long referred to Nijssen's foundational work (his book is recommended) the name of which was Nijssen's Information Analysis Modeling (NIAM). Object-Role Modeling (ORM) is the name of the n-ary extension of binary NIAM by his student, Halpin), and FM is the name currently used in the industry;
• All modeling is identifying some "concepts and relationships", modeling approaches differ only in levels of abstraction (conceptual, logical, or physical[5]) and specific concepts. There is no absolute "right level" -- one must be clear about which level one operates at, and not confuse/conflate them, as is common in the industry[6];
• As we explained, a "visual syntax" symbolizes FM constructs, but is not the FM per se (besides, not everything can be expressed visually, or is necessarily comprehensible if it can).

“Fact Modeling is indeed at the level of individual concepts having properties and named relationships. In consequence, it is a graph data model. With many bells and whistles. Also note the "verbalization technique" used to describe the "facts" (which I see as relationhips, born, hired, uses...). It is certainly a lot more precise and detailed than the concept mapping that I usually propose. ORM can handle even the most complex semantic challenges and it is absolutely fine for describing business rules in general. However, precision comes at a cost, and this makes it (fact modeling) as complex as UML® and in consequence, it is not suited for business-facing specifications (the visual syntax looks too complex for most business people).”

Points arising:

• As the name of Nijssen book attests, it is a conceptual, not data modeling[7,8] approach that, due to its linguistic roots, has affinity to RDM's FOPL at the logical level: a conceptual model created with FM includes a collection of sets of facts of different types expressed in a specialized natural language that specify properties of (1) individual entities and (2) groups thereof, some of which are relationships. Each group is represented by a database relation[9] (note that a data model has a manipulation component, but a conceptual model does not);
• As we explained, the RDM represents formally at the logical level the semantics of entity groups and their relationships, while an as yet unspecified formal GDM would represent semantics of individual entities and their relationships[10]. FM expresses group, not entity semantics, hence its affinity to FOPL/RDM, not DGT/GDM.

References

[1] Pascal, F., Forward to the Past Out-clevering the DBMS.

[2] Pascal, F., Forward to the Past: Sounds Familiar?

[3] Pascal, F., Forward to the Past: From Codd to SQL to NoSQL.

[4] Pascal, F., Forward to the Past Application-Managed Data Not a Distributed DBMS Make.

[5] Pascal, F., Levels of Representation: Conceptual Modeling, Logical Design, and Physical Implementation.

[6] Pascal, F., The Conceptual-Logical Conflation and the Logical-Physical Confusion.

[7] Pascal, F., Conceptual Modeling Is Not Data Modeling.

[8] Pascal, F., Structure, Integrity, Manipulation: How to Compare Data Models.


[9] Pascal, F., Understanding Conceptual vs. Data Modeling Parts 1-4.