Sunday, July 30, 2017

Integrity Is Not Only Referential

Many years ago I wrote an article with this title that carried a dual meaning. The first alluded to vendors claiming relational features--in that case Borland's Paradox referred to a form--based (i.e., application-based) feature as referential integrity. Vendors get away with this because of the second, literal meaning: data professionals may be familiar with uniqueness (PK) and referential (FK) constraints only because they are the only two types of constraints with shorthands enforced by SQL DBMSs that are "out of the box", but are unaware of the several other types of relational constraints and their lack of support in SQL. They are either unsupported declaratively, supported via stored procedures outside the RDM, or not at all, with loss of relational advantages. Even if they were supported, they require proficiency in formalization of conceptual business rules as logical constraints and validation--that most practitioners don't possess.

Read it all



Sunday, July 23, 2017

This Week

1. Database Truth of the Week

"And [AI] weaknesses there are. Watson requires many months of laborious training, as experts must feed vast quantities of well-organized data into the platform for it to be able to draw any useful conclusions. And then it can only draw conclusions based upon the body of data, or ‘corpus’ (plural: ‘corpora’) that it has been trained on. The ‘well-organized’ requirement is especially challenging for Watson, as unprepared data sets are typically insufficient. As a result, Watson customers must hire teams of expert consultants to prepare the data sets, a time-consuming and extraordinarily expensive process." --Is IBM's Watson a Joke?

Sunday, July 16, 2017

Relations and Relationships Part II

This is a 6/21/17 rewrite of a 4/21/13 post, to bring it in line with McGoveran's interpretation of the real RDM envisioned by Codd. It is the second part of a debunking of a LinkedIn thread (the rewrite of the first part of which was posted two weeks ago).

The misconception that the RDM represents relationships of only one type--referential--most likely originates with the E/R conceptual modeling approach. It assumes an "absolute" distinction between entities (objects) and relationships. The distinction, however, is in the "eye of the modeler": objects, properties and object groups are all, in fact, relationships labeled differently as a matter of subjective, pragmatic convenience.  All those relationships expressed as business rules comprising a conceptual model are expressible in a relationally complete FOPL-based data language as integrity constraints enforcible by a RDBMS for consistency with the rules. That neither SQL, nor any other current data languages can express--nor can the DBMSs based on it enforce--all of them is the deficiency of their implementation, not a RDM weakness.  
 
Read it all.


Due to a glitch an earlier revision of an older post seems to have gotten lost. If you have not seen it, read it it here: To Really Understand Integrity, Don't Start with SQL.







Sunday, July 9, 2017

This Week

1. Database Truth of the Week

"For the operations of a formal system to have inverses within some specific use of that system (like a specific application):
  • The basic elements must be orthogonal (independent), hence the Principle of Orthogonal Design;
  • The combination of basis elements and operations must be expressive enough to represent every aspect of the subject matter, hence the Principle of Expressively Complete Design;
  • And, at the same time, not so expressive that there is more than one way to express each aspect of the subject matter, hence the Principle of Representation Minimality Design.
The basic elements of a relational database is the relation. Adherence to these principles ensure thatthere is a unique relational expression for every aspect of the subject matter--either a base relation or a derived relation--and if there are two ways to derive a derived relation, then those two expressions are provably equivalent (i.e., the differences are merely syntax and never meaningful)." --David McGoveran

Monday, July 3, 2017

New Paper: Logical Symmetric Access, Data Sub-language, Kinds of Relations, Database Redundancy and Consistency

NEW!!! Paper #2 in the Understanding the Real RDM series. NEW!!!

 

The data management field cannot and will not progress without educated and informed data professionals and users. UNDERSTANDING THE REAL RDM is a new series of papers that offers informal access to the forthcoming McGoveran interpretation of the formal real RDM envisioned by E. F. Codd (EFC), contrasts it with the current understanding that emerged after EFC's death and demonstrates the practical implications of the differences.

If you are a thinking data professional interested in understanding the scientific foundations of data management, as opposed to the "cookbook" industry practices, these unique papers are a must read. They give you new insights into the RDM--which I call the real data science--and the practical benefits that fail to materialize due to its misuse and abuse promulgated by DBMS vendors, the trade media, "experts" and poor SQL implementations, all of which ignore its formal theoretical grounding from which all the practical benefits derive. You will also learn to minimize the consequences of deficiencies of and optimize the use of SQL.

The series starts with an analysis of the evolution of E. F. Codd's thinking between 1969-1980, which will then be used to show how McGoveran's interpretation follows from his RDM vision and with what consequences. Paper #1, The Interpretation and Representation Of Database Relations, covers the structural component of of the RDM as introduced in EFC's two initial 1969-70 papers.

Paper #2 covers the sections not discussed in paper #1 (net of the relational algebra, which is deferred to a future paper), as follows:

Table of Contents

Acknowledgement

Preface

Introduction

1. Logical Symmetric Access

2. Universal Data Sub-language

2.1. FOPL vs. SOPL
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. Relations with Stored Data


4. Derived Relations and Redundancy
4.1. Database Consistency

5. Database Catalog

Conclusion

References

Both papers are available to order from the PAPERS page.