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

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

and are available for ordering from the PAPERS page.

One is in progress:

RELATIONAL DATABASE DOMAINS: A DEFINITIVE GUIDE

and two are forthcoming:

DATABASE RELATIONS: A DEFINITIVE GUIDE
THE FINAL NULL IN THE COFFIN - A RELATIONAL SOLUTION TO MISSING DATA

will be forthcoming.

In the process I come across matters that, while not includable the papers, are worthy of setting straight in brief posts here. Here is another:

“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

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

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

and are available for ordering from the PAPERS page.

Two more:

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

are in progress.

In the process I come across matters that that are not included in the papers, but are worthy of setting straight in brief posts here. Here is one of them.

• 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

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

In the process I am coming across industry common and entrenched "pearls" that I am using for my "What's Right/Wrong with this Database Picture, or "Setting Matters Straight" (SMS), and "To Laugh or Cry" (TLC) posts on Linkedin. I do these 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 specify those fallacies in brief posts that I set straight in the papers, 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 just posted on LinkedIn.

 New, completely re-written. Available to order here

Table of Contents

Series Preface

Abstract

Introduction

1. Entities, Properties, Names, and Identification

2. Relational Representation

3. Relational Keys

    3.1. Kinds of Keys

           3.1.1. Candidate, Primary and Alternate Keys

           3.1.2. Natural and Surrogate Keys

4. Formal Primary Key Mandate

5. Primary Key Designation

6. Keys and Constraints

7. Keys and Performance

   7.1. Keys and Indexes

Conclusion

References

Appendix A: Keys in SQL

Appendix B: Duplicates and Consequences

B1. Duplicate Interpretation

B2. Duplicates in SQL

      B2.1. Duplicates and Correctness

      B2.2. Duplicates and Query Nestability

      B2.3. Language Redundancy & Duplicates

      B2.4. Duplicates and Performance Optimization

      B2.5. Duplicate Removal

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.