In Part 1 we introduced in the **conceptual model** (CM) the
metalogical **designation property**. It represents—in the absence of known
shared **defining properties** of an entity type, the designation by a **group**'s
definer that an entity identifier (aka assigned name) or property value is a
member of the group. Such a** **group is not a group of entities, but a
group of name and property values. In the **logical model** (LM), it is
formalized as a **designation predicate** (DP) and defines a **domain**.

In Part 2, we introduce the metalogical **assertion property**.
It represents the assertion by an authorized database user that a specific
entity, represented by a tuple, either does or does not correspond to an actual
entity in the real world.

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

**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**

### 01/09 METALOGICAL PROPERTIES PART 1: Designation Property

### 09/17 DBDEBUNK REFRESH

08/17ENTITIES, PROPERTIES AND CODD'S SLEIGHT OF HAND

**UPDATES
**

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

** **

**LATEST****
PUBLICATIONS** (order from **PUBS** 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 **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**

I deleted my Facebook account. You can follow me @**DBDdebunk** on Twitter

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

### Logical & Physical Truth

Consider the universe of all candidates for a position in some
enterprise, who share all properties required for employment in that
capacity—their defining properties as candidates. Only some of these entities—a
subgroup—will be employed at any given time, and that subgroup membership—which
of the candidates are currently
employed—will almost always vary unpredictably over time. Entity groups in a CM
are represented in the logical database by **relations** and facts about employees
are represented by **tuples** (the term “fact” as used herein really means
any declarative sentence that is unequivocally either true or false).

A tuple presented for insertion into the relation representing the group of employees must be both:

·
*Logically true:* namely, it satisfies the **relation
predicate** (RP) that, expressed in a data sublanguage, consists of the
declared **constraints** that jointly guarantee consistency with the
interpretation of the relation. In other words, the tuple represents an entity *of
the proper type* (i.e., it has all the defining properties shared by members
of the group); and,

·
*“Physically” true*: namely, it represents a true
fact. In other words, there is actually an entity with those properties and
relationships in the real world.

Note: The term “physically true” suggest a too objective, absolute notion of the real world than is warranted, but we use it in the absence of a better alternative. The reader should not overinterpret the “physical” bit.

Since both candidates and employees are entities of the same type—share the same set of defining properties—“physical truth” is the only thing that distinguishes the latter from the former, but this distinction is not based on an observable property or relationship that can be represented in a straightforward way (it can be, but becomes convoluted quickly) by an attribute or constraint in the database.

### Assertion Predicate

In part, E.F. Codd (EFC) distinguished RDM from the formal systems of set theory, mathematical relation theory and logic as having not merely sets of tuples to represent facts (about entities and their relationships), but by introducing (rather vaguely) “time-varying” relations (TVR). That is, a database relation is like a set, but its tuple membership can vary over time.

Strictly speaking, a **set** (as defined in any formal set
theory) cannot change over time: the intrinsic semantics of set theories are
simply not expressively powerful enough. There are no set operators that define
such change. In other words, a symbol for a set is not and cannot be
variable—it is static once assigned to represent a specific set. At best, it is
a symbolic placeholder for some subset of the universe.

Likewise, first order predicate logic (FOPL), necessary to
interpret tuples as propositions having truth values, does not permit the value
of a variable to change with time. Whatever assignments are made to a symbol in
FOPL *remain fixed throughout a deduction*. Assignment of values to
variables in both simple set theory (SST) and FOPL are nothing more than symbol
*interpretations*—what the symbols mean.

By contrast, to use a symbol to represent a variable as it is
understood in computer science or computer languages requires at least a logic
as powerful as the **lambda calculus**, invented by the famous logician
Alonzo Church. It is the logic of Turing machines, computation, and
ยต-recursion. The required operation, found in programming languages, is called ** destructive
assignment**. It is not even an essential part of the lambda calculus, but
must be defined. In RA, “relational assignment” is usually understood as a kind
of destructive assignment, in which the relation represented by a relation
symbol can be altered or replaced.

The need for TVRs is so that we can formalize the idea that the
world’s “state” changes in time. But the danger in implementing “relational
variables” (relvars) is that the formal system then is so expressively powerful
that inconsistencies, paradoxes, deductive incompleteness, and undecidability
become possible and perhaps even a necessary consequence. Yet all of these are
undesirable in a DBMS, but especially one defined with *declarative*
operations (one of the primary advantages of the RDM): for example, the DBMS
must be able to compute the set of true tuples that instantiate an arbitrary
query, *itself a predicate*. That there is no evidence EFC even considered
these issues and that CJD likewise ignores them in insisting on relvars (versus
relation values) in the RA is rather astounding to us. Of course, the concept
of relvars has obvious pedagogical value; it’s just that its formal
implications are dangerous.

This is why we often refer to TVRs as an informal gloss by EFC.
TVRs create a natural division between the set of all tuples of a type—which
can be defined rigorously as a constrained subset of the *cross-product of
the domains* on which its attributes are defined—and the tuple subset that
has come to be termed variously a *relation’s state* or the relation’s *value
at a point in time*—the so-called **active relation**. In other words,
precisely the distinction between all potential entity members of the universe
and those group members identifiable at some time. This distinction has not
been satisfactorily and formally definable within any set theory, first order
logic, or mathematical relation theory, all of which are usually defined as
time-independent theories.

Even restricting a relational database to snapshots of its
relations representing groups at points of time (immediately after some
update), there has been no formal way of distinguishing logically between
tuples that *are* currently “in” a relation versus those that—being of the
same type—*could be* in the relation, but currently are not. Left
unformalized is, thus, an informal assertion (in EFC’s 1969 and 1970 articles)
that updates are the result of an assignment (via one of insert, delete, or
update operations) made by a “suitably authorized person.” In fact, it is this
issue that the notion of CWA vs. OWA partially addresses. In our example, in
using the DBMS to update the database, the hiring (or firing) official asserts
that the relation change represents a corresponding change in the real world.
While we cannot replace these non-deterministic, unpredictable assertions with
anything better (since we do not have an absolutely accurate computer
simulation of the real world), we can at least record them explicitly,
understanding that they each formally *mark the beginning of a new deductive
sequence*. Such assertions clearly occur during updates of the database, but
not in the CM of that part of the real world (i.e., the business or subject
matter) the database represents. Instead, they are about which facts are and
which are not true in the sense of correctly characterizing the real world and
so should be represented in the formal, logical system if it is to accurately
reflect the state of the world via a Universe of propositions.

Note: Practitioners often intersperse updates and queries. This is dangerous: incomplete changes to state, although they may be consistent insofar as declared constraints go, might yield different results depending on the specifics of interweaving—different deduction results! Consider how referential constraints might change query results.

By treating the concept of “having been asserted” as a metalogical property associated with each entity, we can formalize the distinction between a group of all potential entities of a type, and the subgroup that actually exists. The assertion meta-property as it pertains to tuple inclusion in a database relation is reflected in the direct or indirect assertion by some suitably authorized user, via update operations, that a tuple either is or is not a member of the active relation representing the entity group at the current time.

We proceed in a manner analogous to the way we handled designation
in Part 1: namely, we capture the assertion property by defining a special
two-place tuple **assertion predicate** (AP). While a DP formalizes the
designation of a membership relationship between a value (either an entity name
or property value) and a group (represented as a domain), an AP explicitly
asserts the physical truth or falsity of a specific tuple representing
facts]about an entity.

The AP has a placeholder for the specific tuple identifier t’, and a placeholder “asserted” for an assigned truth valuation:

AP(t’,asserted)

The placeholder t’ is defined over a domain of tuple identifiers and the "asserted" placeholder is defined over a Boolean domain comprised of the values TRUE and FALSE, with the AP evaluating to /T/ or /F/ accordingly. Thus, the AP allows a user to make a truth value assignment for the tuple. The defining predicate for an active relation, its RP, must include the AP as a conjunct, the truth value of which is recorded in the database along with each tuple. (Whether it is visible to users or not depends on choice of CWA vs OWA, or administrative decision.) Since it is a conjunct in the RP, it must evaluate to /T/ in order for the entire RP to evaluate to /T/. If, given the attribute values in tuple t’, any conjunct in the RP evaluates to /F/, the entirety does as well.

Once we have the AP, we can formally define the active relation (or relation state, or “relvar” value if you insist) as the set of tuples of the relation’s entity type for which the AP is asserted /T/ and excluding those for which the AP is asserted /F/. It should be obvious that the AP provides the desired functionality attributed to the vague notion of TVR. However, ordinary set semantics are restored and deductions (queries) result from evaluation of static (i.e., fixed value) relations.

## No comments:

## Post a Comment