"... [DBMS] deficiencies are, it seems to me, directly due to the widespread lack of understanding (not least on the part of vendors), of fundamental database principles. Certainly it is undeniable that they flout those principles in numerous ways. And the practical consequences are all too obvious: First, users must understand where the deficiencies lie; second, they have to understand just why they are deficiencies; third, they have to understand how to work around them; and fourth, they have to devote time and effort in persuading the vendors to remedy them. The trouble is, of course, users too tend to be unaware of those same fundamental principles and, hence, find themselves unable to carry out their side of the "contract" ... What is more, this sad state of affairs is not likely to change, given the apparent lack of interest on the part of the trade press--itself ignorant of those same principles--in trying to improve matters."

-- C. J. Date

It has long been my contention -- supported by ample evidence at Database Debunkings and in my writings and lectures -- that the widespread lack of understanding of data fundamentals cripples database practice. One of the consequences is the trade media's lack of capacity to serve its function of providing meaningful analysis and assessment of database technologies, products and trends, and - worse -- its ability to get away with it. Most media resporting is fluff, mindless regurgitations of vendor marketing, or outright nonsense. Consider, for example Mario Apicella's Infoworld article of January 31, 2002 about database technology in 2001.

"Given the mature state of the modern Relational Database Management System (RDBMS), it's difficult to imagine a splashy breakthrough that could revolutionize the market in any given year. Nevertheless, many leading RDBMS vendors, including IBM, Microsoft, Oracle, and Sybase, still found room for improvement in 2001. IBM's DB2 and Oracle's 9i in particular wowed us in 2001."

But no truly and fully relational DBMS is available! What Apicella refers to are SQL DBMSs which, despite their relational origins, are so far from what a RDBMS would be that when Date and Darwen outlined the nature of a true RDBMS in their book The Third Manifesto, they categorically prohibited it from being based on SQL. It is, therefore, not difficult, but rather easy to imagine a breakthrough -- in fact, the only real one -- that could revolutionize the market: a true relational DBMS. Instead, all the splash is about developments that not only drive us away from the real solution, but actually throw us decades back to the bad old days of hierarchic databases and application files, which were discarded as obsolete and unproductive.

Note: In fact, a new technology has recently been developed that allows implementation of true RDBMSs (see below).

"Most of last year's major advances came in the area of interoperability, with emerging technologies such as Web services and XML strengthening RDBMS support for analytical applications, and increasing performance and scalability. For example, Microsoft, Oracle, and Sybase caught up with IBM in XML structure support, whereas IBM tried to break away from the pack by adding support for InfiniBand and consolidating DB2's data and online analytical processing (OLAP) capabilities."

One of the most obvious technological regressions is XML, which I have criticized thoroughly in my Against the Grain column as a reinvention of the hierarchic database wheel. For a while XML proponents protested this criticism by arguing that XML is just a data exchange technology, not intended for data management. Even if that were so, this begs the questions as to why a new format was needed for sheer exchange, as we already have many agreed-upon formats; and why a physical exchange format needs components of a data model such as data structure (trees) and manipulation (query)? Be that as it may, it was predictable that, having introduced a new format, the industry would -- as is usual -- extend it to data management, without realizing the implications.

OLAP is another type of regression. By ignoring sound logical design principles such as normalization, data warehouses take us back to application-biased files and incorporate analytical presentation functions, which belong at the application level, into the DBMS.

"In general, the improvements we saw in 2001 gave companies faster performance, simplified management, and a common data structure to support transactional and highly interactive applications. But because Web services remain a work in progress, a good deal of the emerging RDBMS technology is still up in the air."

This sort of statement is at best meaningless fluff, at worst misleading. One of the many advantages of relational technology is performance optimizability by the system. Because SQL ignores or violates most relational principles, it inhibits optimization and imposes very complex administration burdens. For example, SQL implementations maintain a 1:1 relationship between logical rows and physical records, imposing a certain physical order on rows and columns. That robs SQL tables of their relational property as mathematical sets -- which don't have any ordering -- and, therefore, constrains optimization. A relational implementation relieved from this constraint - that is, one with maximal support of physical data independence -- would not only allow for better optimization, but would also be simpler to administer, e.g., indexes and all they entail could become unnecessary. This is precisely what the new implementation technology I mentioned facilitates.

"For example, although hierarchical and object-oriented databases no longer pose a serious threat to RDBMSs, the jury is still out on whether or not Web services will spur RDBMS vendors to adopt native XML databases. For companies that spread business data over multiple databases and platforms, the tendency to deploy e-business applications highlights the need to access those databases concurrently."

Hard to know whether to laugh or cry. While Apicella refers on the one hand to the adoption of XML by DBMS vendors, he states almost in the same breath that hierarchic databases no longer pose a threat to SQL databases (not RDBMSs, which don't currently exist). This is possible only for somebody ignorant of the fact that XML native databases are hierarchic databases!!! And it is hardly the case that the jury is still out on them, something that he makes quite clear in his next paragraph.

"Solutions that consolidate multirelational data structures into a single XML view, such as Software AG's Tamino, could become a tempting approach to simplify development and management issues. But IBM's Relational Connect solution for unified access to different RDBMSs favors DB2 semantics while maintaining the pristine structure of the original database. As yet, no clear winner has emerged."

Terminology such as "multirelational data structures" is a dead giveaway for the trade media using (often mindless) jargon, or inventing some without a clue as to what they mean. What the heck are "multirelational data structures"? And how can such structures be consolidated in a single XML view, which is hierarchic and, thus, nonrelational in character?

"Through the years, enterprises have come to expect a lot from database systems. Vendors must offer increasingly faster access, smooth adaptation to the latest technological twists, backward-compatibility, resilience, scalability, and flexibility. But 2001 was a banner year for RDBMSs, which made significant inroads to comply with the burgeoning Web services revolution. And given the importance of databases on [sic] the modern data structure, the lock-step progress of Web services and relational database technology isn't likely to change anytime soon."

Unfortunately, whatever users demand from DBMSs, it is certainly not what they really need and ought to demand, because they cannot -- they themselves are not knowledgeable of, and interested in data fundamentals. They are, therefore, unaware that the only way to obtain all those nice properties of resilience, scalability and flexibility, is via true and full relational implementations, and not via throwbacks to the days of hierarchic databases and application-managed data, which relational DBMSs was intended to replace. It is this that makes it only too easy for the media and vendors -- themselves ignorant of fundamentals -- to disseminate and promote nonsense, and get away with it.

--

Fabian Pascal has a national and 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 and is author of the contrarian column "Against the Grain." His third book, Practical Issues in Database Management - a Guide for the Thinking Practitioner (Addison Wesley, June 2000), serves as text for a seminar bearing the same name.