Monday, July 22, 2024

New Paper: THE FINAL NULL IN THE COFFIN - A RELATIONAL SOLUTION TO MISSING DATA




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
 

 

 

 

 

Sunday, July 14, 2024

New Paper: LOGICAL ACCESS, DATA SUBLANGUAGE, KINDS OF RELATIONS, DATABASE REDUNDANCY AND CONSISTENCY



 

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





Monday, July 8, 2024

New Paper: INTERPRETATION AND REPRESENTATION OF DATABASE RELATIONS




 

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

Wednesday, June 26, 2024

New Paper: FIRST NORMAL FORM - A DEFINITIVE GUIDE



 Available from PAPERS page.

 



Table of Contents

Introduction
1.     The Normal Form
2.     First Normal Form
3.     Domain Decomposability & Value Atomicity
4.     1NF & Tables
5.     SQL & 1NF
5.1.   Repeating Groups & Repeated Attributes
5.2.   Information Principle & SQL

 


Monday, June 17, 2024

SQL AT 50, OR WHY THERE ARE NO RDBMS'S



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.

Saturday, June 1, 2024

SMS: DOMAINS & SQL




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.”
Can you identify the fallacies before you proceed?

Saturday, May 11, 2024

TLC: TABLES, DIMENSIONS & RDM



 

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.” 

View My Stats