Table of Contents

Introduction
1. “Inapplicable Data”: Nothing's Missing
2. Missing Data: Into the Unknown
3. SQL NULL: What-Valued Logic?
4. Known Unknowns: Metadata
5. A Relational Solution
5.1. The Practicality of Theory
5.2. A Real World Example
5.3. Relation Proliferation
6. Questions/Comments/Objections
Conclusion
 

Table of Contents

Introduction
1. Logical Symmetric Access
2. Universal Data Sublanguage
2.1. FOPL vs. SOL
2.2. Relational Completeness
2.3. Computational Completeness and Hosting
3. Kinds of Relations
3.1. Expressible and Named Relations
3.2. Derived Relations
3.3. Data Storage
4. Derived Relations and Redundancy
4.1. Database Consistency
5. Database Catalog
Conclusion

Table of Contents

Series Preface
Introduction
1. Interpretation of Database Relations
1.1. Attributes as Constrained Domains
1.2. Time-Varying Relations
2. Representation of Database Relations
2.1. Physical Data Independence
2.1.1. Uniquely Named Attributes
2.1.2. Primary Keys
2.1.3. Relations and R-tables
3. Normalization
3.1. First Normal Form and “Simple” Domains
3.2. Normalization and Nonsimple Domains
3.2.1. Foreign Keys
Conclusion

In "Codd Almighty!  Has it been half a century of SQL already?" the Register's Lindsay Clark interviews "Donald Chamberlin, Michael Stonebraker and more" about the legendary programming [sic] language. Chamberlin with Raymond Boyce were the authors of "the 1974 paper SEQUEL: A structured English query language as a way of addressing data in IBM's newly proposed System R, the first database to embody Edgar Codd's paper describing the relational model for database management.”

C. J. Date, who worked at IBM at the time, has often stated that the designers of SQL never understood RDM, and I expressed a similar stance in If You Liked SQL, You'll love XQuery. This has had an extremely detrimental effect on database technology--regress rather than progress--none of which transpires in the interview. So here is my reality check take on what you would not know from the interview.

I am working on entirely new papers (not re-writes) in the PRACTICAL DATABASE FOUNDATIONS series. I have already published two:

• THE FIRST NORMAL FORM - A DEFINITIVE GUIDE
• PRIMARY KEYS - A NEW UNDERSTANDING

available for ordering from the PAPERS page, and two more:

• RELATIONAL DATABASE DOMAINS: A DEFINITIVE GUIDE
• DATABASE RELATIONS: A DEFINITIVE GUIDE

are in progress and forthcoming, respectively.

In the process I am coming across common and entrenched industry "pearls" that I am using for my "Setting Matters Straight" (SMS) and "To Laugh or Cry" (TLC) posts on Linkedin. I do those posts to enable the few thinking database professionals left realize how scarce foundation knowledge is, and to illustrate fallacies that abound in the industry, of which they are unaware, and which the papers are intended to dispel.

Time permitting, I may expose and dispel some of those fallacies, treated in more depth in the papers, such that those thinking professionals can test their knowledge and decide whether the papers are a worthy educational investment.

Here's one.

 “A domain in most SQL usage is essentially an alias name for an existing type + restrictions on an existing type that can be used in a column. As for an attribute, it's essentially a COLUMN in SQL, a field in other types of databases, etc.”

I am working on entirely new papers (not re-writes) in the PRACTICAL DATABASE FOUNDATIONS series. I have already published two:

• THE FIRST NORMAL FORM - A DEFINITIVE GUIDE
• PRIMARY KEYS - A NEW UNDERSTANDING

available for ordering from the PAPERS, and two more:

• RELATIONAL DATABASE DOMAINS: A DEFINITIVE GUIDE
• DATABASE RELATIONS: A DEFINITIVE GUIDE

are in progress and forthcoming, respectively.

In the process, I am coming across industry common and entrenched "pearls" that I am using for my "Setting Matters Straight" (SMS) and "To Laugh or Cry" (TLC) posts on Linkedin. I do those posts to enable the few thinking database professionals left realize how scarce foundation knowledge is, and to illustrate fallacies that abound in the industry, of which they are unaware, and which the papers are intended to dispel.

Time permitting, I may expose and dispel some of those fallacies, treated in more depth in the papers, such that those thinking professionals can test their knowledge and decide whether the papers are a worthy educational investment.

Here's one.

“Data is stored in two-dimensional tables consisting of columns (fields) and rows (records). Multi-dimensional data is represented by a system of relationships among two-dimensional tables.” 

• FT Data Sublanguage & Programming Languages
• FT Relational Domains & Programming Data Yypes
• TLC RDM & "Arbitrary Data Types"
• FT RDM & Complex Domains
• FT RDM & Objects Permanent Identification
• SMS Surrogate Keys
• FT Primitive & Derived Domains
• SMS Primary Keys: Mandate & Selection
• FT Database Relations & Functions

I am working on entirely new papers (not re-writes) in the PRACTICAL DATABASE FOUNDATIONS series. I have already published two:

• THE FIRST NORMAL FORM - A DEFINITIVE GUIDE
• PRIMARY KEYS - A NEW UNDERSTANDING

available for ordering from the PAPERS page, and two more:

• RELATIONAL DATABASE DOMAINS: A DEFINITIVE GUIDE
• DATABASE RELATIONS: A DEFINITIVE GUIDE

are in progress and forthcoming, respectively.

In the process I am coming across industry common and entrenched "pearls" that I am using for my "Setting Matters Straight" (SMS) and "To Laugh or Cry" (TLC) posts on Linkedin. I do those posts to enable the few thinking database professionals left realize how scarce foundation knowledge is, and to illustrate fallacies that abound in the industry, of which they are unaware, and which the papers are intended to dispel.

Time permitting, I may expose and dispell some of those fallacies, treated in more depth in the papers, such that those thinking professionals can test their knowledge and decide whether the papers are a worthy educational investment.

Here's one:

“There seams to be some confusion between what a Primary Key is, and what an Index is and how they are used. The Primary Key is a logical object. By that I mean that is simply defines a set of properties on one column or a set of columns to require that the columns which make up the primary key are unique and that none of them are null. Because they are unique and not null, these values (or value if your primary key is a single column) can then be used to identify a single row in the table every time. In most if not all database platforms the Primary Key will have an index created on it. An index on the other hand doesn’t define niqueness. An index is used to more quickly find rows in the table based on the values which are part of the index. When you create an index within the database, you are creating a physical object which is being saved to disk.”

 Can you identify the fallacies before you proceed?

• FT Relation Interpretation
  
• L/C Tree Prediction in SQL 
  
• L/C "Purpose built systems"
• SMS Primary Key Immutability
• FT Kinds of Surrogate Key
• SMS Imaginary Keys 
• FT Uniqueness Is Relationship
• SMS SST/FOPL & Keys

I am working on entirely new papers (not re-writes) in the PRACTICAL DATABASE FOUNDATIONS series. I have already published two:

• THE FIRST NORMAL FORM - A DEFINITIVE GUIDE
• PRIMARY KEYS - A NEW UNDERSTANDING

available for ordering from the PAPERS page, and two more:

• RELATIONAL DATABASE DOMAINS: A DEFINITIVE GUIDE
• DATABASE RELATIONS: A DEFINITIVE GUIDE

are in progress and forthcoming, respectively.

In the process I am coming across industry common and entrenched "pearls" that I am using for my "Setting Matters Straight" (SMS) and "To Laugh or Cry" (TLC) posts on Linkedin. I do those posts to enable the few thinking database professionals left realize how scarce foundation knowledge is, and to illustrate fallacies that abound in the industry, of which they are unaware, and which the papers are intended to dispel.

Time permitting, I may expose and dispel some of those fallacies (treated in more depth in the papers) in short posts here, such that those thinking professionals can test their knowledge and decide whether the papers are a worthy educational investment.

Here comes the first--a TLC I posted on LinkedIn.

“The company was using a [SQL] RDBMS . . . to handle data transactions for its trading applications. However, the applications required arbitrary data types, which is nearly impossible for relational systems, according to experts.”

 which contains three fallacies--can you identify them before you proceed?

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

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.

HOW TO USE 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, incl uding 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
You can follow me @DBDdebunk on X.

•  "SQL RDBMS" is a contradiction in terms. Not only are SQL DBMSs not relational (and, thus, fail to provide RDM's advantages), but--even leaving SQL out--the interpretation (and, thus, understanding, such as it is) of RDM dominant in the industry is flawed. Do you know why, and what are the missed advantages?

• "Arbitrary data types"--more precisely, domains of arbitrary complexity (not to be confused with SQL built-in types)--are not impossible in RDM properly understood, namely, as coupled with a strong type system: a notion of type hierarchy derived from a theory of types that governs manipulation of domain values, which is orthogonal to RDM, albeit necessary, for support of domains in general, and those so-called "complex" in particular (orthogonal in the sense that the relational data sublanguage is insulated from the implementation of the domains and their operators). Such a type system is incorporated in McGoveran's Semantic-Relational Data Model (SRDM)--the correct interpretation, extension and formalization of Codd's work.

• As to "experts", I do not know many (to understate the case) in RDM and I assure you that the above statement was not made by any of them.

References

McGoveran, D., LOGIC FOR SERIOUS DATABASE FOLK (draft chapters), forthcoming.
Pascal, F., RELATIONAL DATABASE DOMAINS, forthcoming.

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.

 with David McGovern

One purpose of our contributions here is to suggest a vocabulary that avoids confusion not just within the formal logical level, but also between conceptual and logical terminologies, which is widespread in the industry and is exacerbated by limitations of natural language (NL). We use the following terminology in our approach to conceptual modeling:

• Objects are:

- Primitive (basic entities);

- Compound:

  - groups of related entities;

  - multigroups (groups of related groups);

• Properties are:

- Individual (of basic entities);

- Collective:

  - Of groups: relationships among entities within a group;

  - Of multigroups: relationships among groups within a multigroup.

Note:  It is a McGoveran insight that relationships between objects at a lower aggregate level are properties of the object at the higher aggregate level which the former comprise (LOGIC FOR SERIOUS DATABASE FOLK, forthcoming; see draft chapters) http://www.alternativetech.com/ATpubs_dir.html For classification of properties as first, second, third and fourth order (1OP, 2OP, 3OP and 4OP) see RELATIONSHIPS AND THE RDM Parts 1-3. https://www.dbdebunk.com/2023/03/relationships-and-rdm-v2-part-1.html All such properties can be expressed logically in a FOPL-based relational data sublanguage as constraints, which is beyond the scope of this discussion.