Saturday, May 21, 2022


Note: To demonstrate the correctness and stability due to a sound theoretical foundation relative to the industry's fad-driven "cookbook" practices, I am re-publishing as "Oldies But Goodies" material from the old (2000-06), Judge for yourself how well my arguments hold up and whether the industry has progressed beyond the misconceptions those arguments were intended to dispel. I may revise, break into parts, and/or add comments and/or references. You can acquire foundation knowledge by checking out our POSTS, BOOKS, PAPERS, LINKS (or, even better, organize one of our on-site SEMINARS, which can be customized to specific needs).

The following is an email exchange with a reader and DBMS designer.


(originally published in 2001)

"I would like to hear your (or Date's) opinion on The Suneido Database … it seems to me self-contradictory. They aren't typed ... so how can they define operators, or even the idea of domains. They also say they include administrative commands, which as far as I understand isn't allowed in the THIRD MANIFESTO. While they do not claim to be an implementation of the Manifesto, their claims that their database language was created by CJ Date do not sound appropriate."

 "They don't know what [domains (distinct from programming data types)] are and what their function in the RDM is. That's common for all DBMS vendors, the claims of which should be always taken with more than a grain of salt."


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.


SMS: "Relation Proliferation"?

04/25 SMS: Relational Database and Set Theory

04/10 SMS: Quota Queries

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

- To work around Blogger limitations, the labels are mostly abbreviations or acronyms of the terms listed on the
FUNDAMENTALS 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.

I deleted my Facebook account. You can follow me @DBDdebunk on Twitter: will link to new posts to this site, as well as To Laugh or Cry? and What's Wrong with This Picture? posts, and my exchanges on LinkedIn.

DBMS designer:
"I noticed your recent posting on the Suneido DBMS on As the primary developer on this project, I'm certainly interested in any and all feedback. I'm curious what seemed self-contradictory about the database article I'd be happy to clarify any points that are unclear or misleading.
Contrary to the email from LD, we do not claim that our database language was created by C.J. Date. The article in question says "The query language is based on the relational algebra language suggested by C.J.Date". Suneido's query language is similar to that used in AN INTRODUCTION TO DATABASE SYSTEMS. Suneido is criticized because it doesn't use SQL. I wanted to say we based our query language on existing work, that we didn't totally reinvent the wheel. Perhaps this could have been stated more clearly -- I would be happy to revise the statement if Mr. Date objects to its current form.
As far as the THIRD MANIFESTO goes, I have read it, and I think I have a crude understanding of it, including its concept of what types are and what their function in a data model is. Suneido does not implement these concepts, nor does it make any claims to. Suneido's goals are pragmatic. We don't claim to implement any standard, or to be complete or correct in any theoretical sense. Our only hope is that Suneido is useful for certain applications. And we are always open to suggestions on how Suneido can be improved.

Suneido is an open source project, and no one sells it, so I'm not really a vendor, but, of course, you can still take my statements with more than a grain of salt. -) I look forward to further discussion."
"My short response to the reader was not based on -- and is not intended to be -- an evaluation of the product. It only responds to a very specific comment regarding [relational] domains (vs. programming data types).

I have not criticized any product on whether it does or does not use SQL -- I happen to think that SQL is a non-relational poor language -- but, unfortunately, that's what the industry [was capable of due to lack of understanding of data fundamentals and the RDM].

[For correctness,] a DBMS must [concretize some] data model -- a formal theory of data with the following components:

[The data structure in RDM is the relation on domains -- a relationship among them -- constrained semantically to represent a group of related entities of the same type. Since Suneido does not support domains, it does not support relations and, therefore, the RDM. It is not clear what formal data model, if any, Suneido is grounded in (if it is, please define its three components) and, if so, it guarantees neither correctness, nor any of the other relational advantges].

Don't worry, we don't suspect any DBMS developer these days of adherence to theoretical foundations -- [they don't know and appreciate them], so I don't have to dig deep into products to know that they are problematic.

The theory is not there for its own sake, but for very pragmatic purposes. Ignoring theory makes products less sound and, thus, not more practical. This has nothing to do with whether a product is commercial or open source. In fact, open source should enable those serious about database management [as distinct from sheer profit-oriented vendors] to do things right by grounding their products theoretically, but unfortunately they [neither know, understand, or appreciate data fundamentals either].

Note on re-publication: No particular data sublanguage (i.e., syntax, such as Date's and Darwen's D) is required for a DBMS to be a RDBMS, as long as it's relational -- grounded in SST/FOPL and concretizes the RDM as currently understood (i.e., 5NF relations, a RA with 5NF closure and multi-relation results). Syntactic "similarity" does not count. Suneido did not seem to have a formally defined data model and does not support domains and, therefore, no relations. Consequently it is not a RDBMS and cannot guarantee correctness, namely by-design semantic consistency and system-guaranteed logical validity.

Unlike Date and Darwen, for whom relational domains and programming data types are one and the same thing, we follow Codd, who identified important differences between them.

Domains: The Database Glue

Understanding Domains and Attributes

What Domains Are and Are Not

No comments:

Post a Comment

View My Stats