No quality control

[Ed. note: This is Fabian's last column for SearchDatabase.com. Join me in thanking him for nearly two years of irascible, confrontational, and educational columns. It's been quite a ride! You can find more of his contributions in SearchDatabase.com's Ask the Expert section, as well as at DBDebunk.com, DBAZine.com, The Journal of Conceptual Modeling, and The Data Administration Newsletter.]

I have frequent arguments in the industry, particularly with the trade media, which is not too keen on my "negative" critical articles (of vendors, products, and "experts" especially) and would like to see me do "positive" pieces about why relational technology is "obviously" better than anything else, instead of "reactive" pieces that involve "criticizing a criticism of a response to a response." If relational technology is "obviously" better than any other and the only one based in scientific principles, the argument goes, then my job making a compelling argument for it should be easy.

There was a time when I did nothing but expounded the advantages of the relational model, but I got attention only for a short period of time -- times during which the model was the "current resident fad." When many other fads followed, claiming, erroneously, superiority over the relational model, it became much more important to debunk those. This was not my choice, it has been imposed on me by the huge amount of nonsense being published either on "better alternatives" to the relational model, or on the model itself. It is very easy to marginalize correct arguments if they are at odds with everything else being published. It is rather disingenuous, therefore, for the media to generate lots of unsupportable or weak arguments, then dismiss critical attempts to set matters straight as "not popular."

Consider, for example, the excerpt titled "The Relational Database Model" by Ryan Stephens & Ronald Plew from their book "Teach Yourself Database Design" (which got a rating of 3.76 out of 5 on SearchDatabase). They write:

I doubt that the "understanding" of database types they provide can enhance intelligence of anything, because:

• There is no such thing as a "flat-file database." Flat-files were part of application-based (read: non-database) data management, which was replaced by database management, the managing of databases by DBMSs. In fact, non-database products were actually file, not database, managers.
• The OO approach, invented for programming, does not offer any specific data model analogous to the relational model, and lacks a sound theoretical foundation as well as consensus on its concepts and features, in large part because they are fuzzy (see OO for Application Development, Not Database Management and Oh, Oh Not OO Again).
• The so-called "object-relational" approach is bogus (see Date and Darwen's The Third Manifesto).

"The modern database of choice is the relational database (RDB). So why is the relational model so attractive?"

Of choice? Attractive? Let's be serious. The dominant database model is not relational, but that underlying SQL. SQL was not a matter "of choice," but was imposed on the industry by IBM at a time when it dominated the industry, despite Codd's warning that SQL was a poor implementation of the model, defeating arguably better alternatives (e.g. Ingres' QUEL). SQL is so far from what true relational implementations could and should have been, that Date and Darwen explicitly prohibit it from being the data language for true relational implementations and outline an alternative, Tutorial D, in The Third Manifesto.

If relational is attractive, then why is it overwhelmingly dismissed, criticized and substituted for by such questionable approaches as object-orientation, "universal," "multidimensional," "associative," and so on?

The authors cite what, in their mind, are the advantages of relational technology:

• "It is the most stable."

  It would be very important to know why, but they don't say.

• "RDB standards are well established by organizations such as the International Standards Organization (ISO) and the American National Standards Institute (ANSI). There are many RDB vendors to choose from, including Oracle, Microsoft, Informix, IBM, and Sybase."

  The authors mean SQL, not relational standards, of course; the term "relational" does not occur once in the standards, which is intentional. Further, the standards are becoming even less, not more, relational. The recent addition of pointers, a fundamental violation of the model, takes the cake.

• "It is easy to convert between different relational database implementations."

  Between truly relational (DBMS, not database) implementations yes, but much less than between SQL ones.

• "It is easy to define and maintain data with SQL. It is easy to manipulate data with SQL. The ad hoc query process is simple."

  Perhaps easier and simpler than what preceded SQL -- that was easy -- but not anywhere near as easy and simple as with relational.

• "Data is well-protected through referential integrity and other constraints."

  Actually, the poor support of the critical function of integrity is the one of the main problems in SQL. SQL started without any integrity capabilities at all, then some were added post-hoc and suffer from limitations and complexities that almost defeat their usability. Implementations are still far from integrity completeness, in large part because it is difficult to add them post-hoc, or because the various existing flaws in SQL inhibit it.

The authors proceed to discuss "characteristics of relational databases" by regurgitating, without explanation, Codd's 12 rules for relational fidelity. The rules suffer from certain weaknesses and while they do have some value, they are no longer an "active" basis for evaluating products. They certainly should not be stated without adequate clarifications and revisions.

They then move to "relational database objects," oblivious to the fact that the relational approach has nothing to do with the fuzzy OO terminology, which lacks a theoretical foundation. They enumerate some of the "various types of objects can be found in a relational database":

• "Table -- A table is the primary object used to store data in a relational database. When data is queried and accessed for modification, it is usually found in a table. A table is defined by columns. One occurrence of all columns in a table is called a row of data."

Database tables are logical and, therefore, data is not (physically) stored in tables, but represented by them. The relational model is intentionally mute on physical storage and access, giving vendors complete freedom to do what they darn please to maximize performance. I don't know what it means for a table to be "defined by columns" and I don't care for their row definition.

• "View -- A view is a virtual table, in that it looks like and acts like a table. A view is defined based on the structure and data of a table. A view can be queried and sometimes updated."

Views don't just "act as tables," they are tables! And I dare anybody to figure out what views are based on their definition.

• "Constraint -- A constraint is an object used to place rules on data. Constraints are used to control the allowed data in a column. Constraints are created at the column level and are also used to enforce referential integrity (parent and child table relationships)."

Here the lack of knowledge and understanding, and the confusion become rampant. An integrity constraint is a representative in the (logical) database of a business rule in the real world. There are four types of constraints in the relational world: domain, column, table and database (see Chapter 2 in PRACTICAL ISSUES IN DATABASE MANAGEMENT). Referential integrity is one type of database constraint. "Parents" and "children" are hierarchic, not relational concepts.

• Index -- An index is an object that is used to speed the process of data retrieval on a table. For example, an index might be created on a customer's name if users tend to search for customers by name. The customer names would be stored alphabetically in the index. The rows in the index would point to the corresponding rows in the table, much like an index in a book points to a particular page."

This is more or less correct, although the language is very imprecise, forcing the authors to use an example (incidentally, had they used examples for the previous "objects", they might have discovered how poor their definitions are, which may be the reason they did not.)

• "Trigger -- A trigger is a stored unit of programming code in the database that is fired based on an event that occurs in the database. When a trigger is fired, data might be modified based on other data that is accessed or modified. Triggers are useful for maintaining redundant data."

Triggers are not relational objects, they were added by SQL vendors as a procedural workaround their failure to support full declarative integrity. They are used to enforce many types of constraint, but they should be used to prevent redundancy, not maintain it (see articles on normalization in this series). After all, didn't the authors say (above) that the relational model was invented to avoid/reduce redundancy?

• "Procedure -- A procedure is a program that is stored in the database. A procedure is executed at the database level. Procedures are typically used to manage data and for batch processing"

Triggers are just a special kind of stored procedures, so all comments on triggers apply.

• "The first four objects deal with the definition of the database, whereas the last two objects deal with methods for accessing database objects. Objects in a relational database provide users with a logical representation of data, such that the physical location of the data is immaterial to the user."

The first three object types (not objects) deal with data definition and the second and third also with data manipulation; the fourth object type improves the performance of physical access to the data (and is not part of the logical representation of data), and the last two object types are a procedural (and therefore, inferior to the declarative) way to enforce integrity.

Why aren't those who try to explain relational technology required to know and understand what they are explaining? For each attempt I make to explain the advantages of relational technology, a dozen or more like this one are published. And without exposing the scope of this problem via criticism, how exactly will it be resolved?

About the author

Fabian Pascal has an international reputation as an independent technology analyst, consultant, author and lecturer specializing in data management. He was affiliated with Codd & Date and for more than 15 years held various analytical and management positions in the private and public sectors, has taught and lectured at the business and academic levels, and advised vendor and user organizations on database technology, strategy and implementation. Clients include IBM, Census Bureau, CIA, Apple, Borland, Cognos, UCSF, IRS. He is founder and editor of Database Debunkings, a web site dedicated to dispelling prevailing fallacies and misconceptions in the database industry, where C.J. Date is a senior contributor. He has contributed extensively to most trade publications, including Database Programming and Design, DBMS, DataBased Advisor, Byte, Infoworld and Computerworld. His third book, Practical issues in database management (Addison Wesley, June 2000), serves as text for a seminar bearing the same name. He can be contacted at editor@dbdebunk.com.

For More Information

• What do you think about this column? E-mail the Editor at tdichiara@techtarget.com with your feedback.
• The Best Web Links on the relational model
• Post your technical database questions--or help out your peers by answering them--in our live discussion forums.
• Ask the Experts! Our database design, SQL, Oracle, DB2, SQL Server, relational model, and data warehousing gurus will answer your toughest questions.