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