Follow @DBDebunk Follow @ThePostWest

“A set is an identification of zero or more objects (elements, entities, depending on context) 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 set members have one or more properties in common. It is, however, possible that the sole defining property of a set can be simply that the definer of a set has explicitly designated as members certain (one or more) objects that do not share any properties, so the only property shared by the set members is the designation property (DP) -- each member then has the property of having been designated member of the set. More explicitly, for any set, an assertion of set membership has definitional priority over the necessity of any other properties being shared among the members.” --David McGoveran

Thus, members of a set are "drawn from some pre-defined universe of objects" on the basis of shared properties (that define their type and are required for set membership) -- if nothing else, at least a designation property (DP). These properties distinguish members of the set from those in the universe that are not.

In database management objects share the DP too , but because it is implicit in the semantics of update operations under the Closed World Assumption (CWA), it:

• Is not included in conceptual models;
• Is not represented as an attribute or constraint in logical models;
• Does not appear in tabular displays of relations with which practitioners interact (and confuse with relations).
• It does not appear in the interpretation of RDM popular in the industry.

Interpretation of Database Relations

Mathematically, a database relation is a set of n-valued tuples that can be understood as a relationship of n domains, namely a subset of their Cartesian product (Cp) that is assigned the interpretation of a group of facts about entities which, by virtue of sharing n properties, are of the same type:

• Domains/attributes represent properties;
• Tuples represent facts that describe entities of the type.

“... each domain is a pool of values, some or all of which may be represented in the database at any time. While it is conceivable that, at some instant, all entities are represent, it is unlikely that all possible ones are ... As time progresses, each n-ary relation may be subject to insertion of additional n-tuples, deletion of existing ones, and alteration of components of any of its existing n-tuples. The totality of data in a data bank may be viewed as a collection of time-varying relations.” --E.F. Codd, 1970

This suggests that the Cp of the domains (also a relation) represents the class of all possible entities of a type, out of which each time-specific designated group is represented by a subset of the Cp, hence the domain-attribute distinction. (why?)

The interpretation of a relation -- the informal business rules (BR) that describe the type of entities represented by the tuples (i.e., their shared individual and collective properties) -- formalize in FOPL as a relation predicate (RP) which, expressed in a FOPL based relational data sublanguage, can be enforced by a RDBMS as constraints on the relation to ensure its consistency with the assigned interpretation.

Consistency vs. Truth

All the persons who share the properties required to be employed by some enterprise are members of the class of possible employees and any group thereof can be employed--designated employee--at any time. In other words, from a class of entities of a type -- a subset of entities can be designated at any time members of a time-specific group. What distinguishes group members from class members that are not group members is the DP. Note that time-specific group membership is not predictable and unlike shared properties, cannot be expressed as constraints.

When an authorized user presents (via an application) a tuple for insertion into the database, he asserts that the entity has the DP -- the fact is true. 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 a user deletes a tuple, he is asserting that the tuple no longer represent a true fact.

“The DP 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 make explicit the distinction between:

• To formalize this distinction, so that it is expressible in logic.

Note that the distinction means that a tuple can satisfy the RP, but represent a false fact, but a tuple that does not satisfy the RP cannot possibly represent a true fact.

“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 meta-linguistic 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 assigned interpretation (BRs) by enforcing RP constraints (logical truth), but cannot ensure factuality (i.e., physical truth). For factuality -- what is informally meant by "truth" -- the RDBMS must rely on trusted and authorized users.