Follow @DBDebunk Follow @ThePostWest

“A set is an identification of zero or more objects (depending on context, the terms “elements” or even “entities” may be used) that can be referred to as a group by name (usually a symbol), and which are drawn from some pre-defined universe of objects. Such objects are then said to be the members of the set. The members of a set have one or more properties in common ... One property that deserves special attention is that of designation. The sole defining property of a set can be simply that the definer of that set has explicitly designated certain (one or more) objects as all the set’s members. Each such member then has the property of having been designated as a member of a specific (e.g., named) set. We will refer to such a property as a designating property ... To make the point more explicit, for any set, an assertion of set membership has definitional priority over the necessity of any other properties being shared among the members.”[1]

Thus, set members are "drawn from some pre-defined universe of objects" on the basis of sharing common properties -- if nothing else, at least a designation property (DP) -- the defining (required) properties that distinguish objects that are set members from non-members.

In database management, base (as distinct from derived) relations are sets defined such that their members -- tuples -- represent (facts about) groups of entities that share both (1) defining (required) properties and (2) a DP[1]. Because the DP is implicit in the semantics of update operations under the Closed World Assumption (CWA)[3] and:

• Is not included in conceptual models;
• Is not represented as an attribute or constraint in logical models; 
• Does not appear in R-table displays of relations with which practitioners interact (and confuse with relations[2])

and the conventional interpretation of the RDM has been silent on it, practitioners are completely unaware of it.


------------------------------------------------------------------------------------------------------------------
SUPPORT THIS SITE 

I have been using the proceeds from my monthly blog @AllAnalytics to maintain DBDebunk and keep it free. Unfortunately, AllAnalytics has been discontinued. I appeal to my readers, particularly regular ones: If you deem this site worthy of continuing, please support its upkeep. A regular monthly contribution will ensure this unique material unavailable anywhere else will continue to be free. A generous reader has offered to match all contributions, so let's take advantage of his generosity. Purchasing my papers and books will also help. Thank you. 

NEW PUBLICATIONS 

NEW: 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.

NEW: SOCIAL MEDIA 

I deleted my Facebook account. You can follow me on Twitter:
@dbdebunk: will contain links to new posts to this site, as well as To Laugh or Cry? and What's Wrong with This Picture, which I am bringing back.


HOUSEKEEPING

• 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 FUNDAMENTALS page, see the ABOUT page. The 2017 and 2016 posts, including earlier posts rewritten in 2017 are relabeled. As other older posts are rewritten, they will also be relabeled, but in the meantime, use Blogger search for them. 
• 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 work. 

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

Relation Predicates and Constraints

Conceptual modeling formulates business rules (BR) that specify the defining properties shared by entities required for group membership:

• First order (1OP) and second order properties (2OP) of individual members, 2OPs being relationships among 1OPs;
• Third order properties (3OP): relationships among members that are collective properties of the members as a group[4].

The BRs specifying defining 1OPs, 2OPs, and 3OPs jointly constitute the criterion for entity membership in a group. Otherwise put, entities must (1) individually have the 1OPs and 2OPs and (2) collectively with the other group members have the 3OPs, to be group members.

For computable database representation informal BRs must be formalized as predicates in first order predicate logic (FOPL). The conjunction of predicates corresponding to 1OPs, 2OPs, and 3OPs of a group comprise the relation predicate (RP) associated with the relation representing the group in the database. The RP is the membership criterion for a tuple representing a fact about a group member in that relation: every tuple in the database must satisfy (1) at least one RP and (2) the disjunction of all RPs.

Note: For a database with n relations R1, R2, ..., Rn  designate the relation predicates by PR1, PR2, ..., PRn. Any tuple in the database must satisfy the compound predicate pr1 OR pr2 OR ... OR prn. If the tuple is of the type of the ith relation Ri, then it will satisfy PRi. Assume POOD[5] is obeyed. If the tuple satisfies only one of the RPs, it belongs in a base relation. If it satisfies more than one RP, it is a view tuple. --David McGoveran

When expressed in a FOPL-based specific data sub-language, predicates are enforcible as constraints by the DBMS.

But, as we mentioned, group members also share a DP, for which there is no corresponding BR in the conceptual model, and no constraint in the logical model. 

Note: There are fourth order properties (4OP) -- relationships among groups -- by virtue of which groups form a multigroup[4]. 4OPs formalize as multirelation predicates (MP) which, expressed in a data sub-language, become database (i.e., multirelation) constraints  enforceable by the DBMS. Relations must satisfy these constraints to be members of the multigroup. At any time a database satisfies the RPs, multirelation constraints, and the APs of the tuples. 4OPs and  multirelation predicates and constraints is a complex subject beyond the scope -- and unnecessary for the purposes -- of this discussion.

Database Consistency vs. Truth

In a universe of entities, those that share the individually required 1OPs and 2OPs, and collectively required 3OPs (i.e., are of the same type) are qualifying candidates for group membership. At any given time there may be more than one collection of candidates that satisfy the membership criterion, only one of which is the group of actual members. What distinguishes actual members from candidates is the DP[2].

For example, in a universe of persons, there may be more than one collection of persons that have the individual and collective properties required for being employees of an enterprise (i.e., they satisfy the criterion for membership in the group of its employees), but only one such collection is employed at any given time: each candidate hired was designated member of the group. Note that group membership at any time is not knowable in advance (e.g., which candidates will be employed is not predictable).

RP constraints represent in the database the BRs that specify the 1OPs, 2OPs and 3OPs, but not the DP! So by enforcing RP constraints the DBMS does not ensure that a tuple represents an actual member that also has the DP (e.g., a hire), rather than a candidate that does not.

When an authorized user presents (via an application) a tuple for insertion into the database, he asserts that it represents an entity that has the DP (i.e., an actual member). The DBMS checks that the tuple satisfies the RP constraints, and if it does, accepts the user assertion and inserts the tuple into the database. Conversely, when the user deletes a tuple, he is asserting that the tuple does not represent an actual member, and the DBMS removes it.

“The designating property as it pertains to tuple inclusion in a database relation is reflected in the direct or indirect assertion by some suitably authorized user that a tuple either is or is not, via update operations, a member of the relation representing the entity group. This property can be captured in the formal logical model as a special two-place tuple predicate which I call the assertion predicate (AP), denoted by

A(t,asserted)

where t represents a specific tuple and "asserted" is a Boolean variable taking the truth value constants TRUE or FALSE, with the AP evaluating to /T/ or /F/ accordingly.”
--David McGoveran

The AP was introduced by McGoveran:

• To distinguish between the set of tuples that satisfy the RP constraints given the values in the tuples on the one hand, and the subset thereof that represent the actual group members (i.e., that also have the DP) on the other hand; and,
• To formalize this distinction, so that it is expressible in logic[1].

“Entity properties in a conceptual model of reality are represented by attributes in the logical model, which correspond to some facts about entities and are data valued. The DP is different: a kind of property that is purely assertive and not "verifiable" according to any data. The AP that formalizes it is a statement about the evaluation of the fact that a tuple represents -- it reflects the assertion of an authorized user (i.e., a designation that stands on its own without definitive evidence) about whether a tuple represents a true fact and belongs in the relation, or a false fact and does not -- and so it is both a metalinguistic predicate, and about interpretation (meaning). It does not define a set of facts about entities, that the RP component predicates do, and its value is not determined by something in the conceptual model, but is reflective of the use of the DBMS.”

“For example, a HIRED attribute would typically represent recorded company data, whereas the AP makes explicit (for FOPL purposes) that the factual nature of the tuple has been asserted or denied (i.e., it does or does not represent an actual employee). The distinction is necessary: it is important for users to understand that some user performs update operations, and that such operations might not be consistent with recorded data (tuples that are inconsistent with the external world, fail to make timely updates, make mistakes, etc.) Such inconsistency with the external world is not checkable -- that is exactly what the authorized user making the assertion is taking responsibility for.”
--David McGoveran

All this is another way of saying that a true RDBMS can guarantee database consistency with the BRs by enforcing RP constraints (logical truth), but cannot ensure factuality (i.e., real world truth)[7]. For factuality --  what is informally meant by "truth" -- the RDBMS must rely on trusted and authorized users.


References

[1] McGoveran, D., LOGIC FOR SERIOUS DATABASE FOLK, forthcoming.

[2] Pascal, F., Understanding Relations Part 1: Tables? So What?

[3] Pascal, F., The Clouding Syndrome.

[4] Pascal, F., Relations and Relationships Parts 1,2,3.

[5] Pascal, F., The Principle of Orthogonal Database Design Parts 1,2,3.

[6] Pascal, F., Don't Confuse/Conflate Database Consistency with Truth.