Follow @DBDebunk Follow @ThePostWest

Note: This a revision of an earlier post

RDM is an application to database management of mathematical relation theory (MRT) consistent with simple set theory (SST) expressible in first order predicate logic (SST/FOPL) that is used to formalize symbolically conceptual models of reality as logical models for database representation.

In RDM a domain can "appear" in multiple relations: the domain represents an abstract property, attributes defined on it represent that property in contexts of specific entity groups that relations represent. For example, attribute SALARY in relation EMPLOYEES represents the property represented by domain MONEY in the context of entities of type Employee and attribute BUDGET in relation DEPARTMENTS represents it in the context of entities of type Department.

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

SUPPORT THIS SITE
DBDebunk was maintained and kept free with the proceeds from my @AllAnalitics column. The site was discontinued in 2018. The content here is not available anywhere else, so if you deem it useful, particularly if you are a regular reader, please help upkeep it by purchasing publications, or donating. On-site seminars and consulting are available.Thank you.

LATEST POSTS

07/31 ON RELATIONAL KEYS (& DOMAINS) (t&n)

07/25 NULLS & THE “2^ND ADDRESS LINE”

07/19 PREDICATE LOGIC, SEMANTICS & RDM (sms)

UPDATES

08/13/23 Added Good explanation of 'class' and 'type' to the LINKS

LATEST PUBLICATIONS (order from PAPERS and BOOKS pages)

08/19 Logical Symmetric Access, Data Sub-language, Kinds of Relations, Database Redundancy and Consistency, paper #2 in the new UNDERSTANDING THE REAL RDM series.
02/18 The Key to Relational Keys: A New Understanding, a new edition of paper #4 in the PRACTICAL DATABASE FOUNDATIONS series.
04/17 Interpretation and Representation of Database Relations, paper #1 in the new UNDERSTANDING THE REAL RDM series.
10/16 THE DBDEBUNK GUIDE TO MISCONCEPTIONS ABOUT DATA FUNDAMENTALS, my latest book (reviewed by Craig Mullins, Todd Everett, Toon Koppelaars, Davide Mauri).

USING THIS SITE
- 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 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
I deleted my Facebook account. You can follow me @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.
------------------------------------------------------------------------------------------------------------------

Given a conceptual model, in FOPL a predicate captures only relationships among sets of entities--properties can only be expressed indirectly as such relationships. For example, the property "has salary X" is not captured in FOPL directly as such, but rather as something like "the member of the set of employee entities in the universe that is also a member of the set of entities with salary X in the universe". A database relation is like constructing a Venn diagram -- for each tuple in the relation we start with a universe of entities, then carve out the intersection of all employees by some specific employee#, then by specific name, then by departmental assignment, then by salary, and so on. Each employee tuple defined by specific property values is the intersection of multiple sets of employees, each of which has one of those values. Visually, in a R-table both the rows and columns ought to represent sets of entities, but in Codd's RDM columns represent attributes--properties--(i.e., "has salary X") rather than "the set of entities with salary X".

Since properties in FOPL are themselves predicates, it follows that a relation predicate (RP) is a predicate of predicates, requiring at least second order logic (SOL), or some logic higher than FOPL. But the relational advantages for database practice -- language declarativity and decidability, data independence, system-guaranteed correctness, simplicity--would then be lost. Which is why, having started initially with SOL, Codd had to switch to FOPL to avoid their loss.

Codd glossed over his sleight of hand -- allowing domains and attributes that are sets of property values instead of sets of entities that have those values--probably not noticing the implications. Consequently, while in FOPL an entity represented by a tuple is an intersection of different subsers of the universe of entities with pre-defined values, users intuitively think of the entity as having property values, which is one important reason they often get FOPL expressions of relations and tuples wrong.

Ontological Commitment

“As we explained elsewhere, conceptual modeling to date assumes the Ontological Commitment to Objects (OCO), where the world is comprised of a fixed number of immutable objects. This imposes some limitations: in database terms we cannot have dynamic, ever evolving schemas, and are limited to either simple schema extensions or periodic redesign (again, better than non-RDM alternatives, especially pre-RDM). This problem cannot be addressed by data independence alone -- it requires an Ontological Commitment to Properties (OCP). Neither any existing predicate logic, nor any existing set theory of which I am aware (and I've examined lots of both) can express OCP concepts. To take advantage of OCP requires modifying them, so that properties can be treated as primitive objects, and relationships among properties (instead of objects) can be expressed and deduced. I labor in the belief that OCP and building on and learning from Codd's RDM will lead to the creation of a powerful formal language, capable of capturing much more meaning and extending the relational algebra to handle extremely complex and dynamic models uniformly and consistently.” --David McGoveran

 

To be used for formalization of conceptual models that assume the OCP, not just Codd's RDM but SST/FOPL need to be revised and extended to treat the tuples of a relation as representing the instantiations of a predicate that has arguments taking property values. Much of McGoveran's published work to date has been about refining Codd's RDM based on OCO-FOPL. This should introduce a version of the RDM grounded in OCP-extended FOPL, while also incorporate David's semantic theory of types--to say that this is a tall order might be the understatement of at least the decade.

The posts here are intended to convey only some flavor thereof.