In a reaction to my writings, Neil Burnett states:
Although Mr. Pascal is obviously an exceedingly knowledgeable relational database expert, he misses the point throughout his articles and completely misnamed -- but terrifically readable -- book Practical Issues in Database Management. It is not acceptable to advise that the only practical course of action is to lobby RDBMS vendors to make better products.
I have not ever advised lobbying the DBMS (not the RDBMS!) vendors as the only practical course of action. Although, if done collectively and in an organized manner, this would probably be the most effective path, I am not so naive as to expect it in this society. (After all, if there was no collective reaction to the 2000 "election," how likely is a collective reaction to database product flaws?)
I usually refer primarily to demand as expressed in purchase patterns: were practitioners knowledgeable of data fundamentals, they would know and appreciate better products relative to weaker ones and, over time, would prefer the former to the latter, forcing gradual improvement. In other words, we would have true competition where it counts. As economic theory informs us, efficient markets require informed consumers and the least that can be said about database consumers is that they are informed. If practitioners don't understand the differences between RDBMS, SQL DBMS, ODBMS, UDBMS and XML DBMS, they can be sold anything, and they are. As I argued so many times, they are actually sold worsening, not improving technology; and they don't realize it.
We should lobby, of course, but it is imperative that we *continue to use* the available products without being seduced into the dead-end roads of object-oriented databases and -- even worse -- XML databases. We need "How to's".
Neither am I aware that I have advocated not to use existing products (although I question the notion that practitioners must continue to use flawed products just because the industry keeps making products that are even worse). What I have been arguing -- which is quite distinct -- is that practitioners should educate themselves in data fundamentals, such that they would, at the very least, be in a position to assess products correctly, and see through the marketing and media hype that drives the industry. Without such education -- as distinct from "how to's," which is training -- how can they see through absurdities such as the following (see The cloak of ignorance: Trade media and database reporting).
... hierarchical and object-oriented databases no longer pose a serious threat to RDBMSs ... Most of last year's major advances came in the area of interoperability, with emerging technologies such as Web services and XML ... For example, Microsoft, Oracle, and Sybase caught up with IBM in XML structure support ...
Note: If this does not make you laugh or cry, you're not sufficiently educated in the fundamentals yourself.
How can this be done? Well I had hoped his book would give me a start. Indeed, attempting to stick to the excellent concepts provided in it has been very helpful in producing significantly more robust designs than I used to produce. But more is needed.
We are in agreement: of course more is needed. But if Burnett read my editorials and exchanges at Database Debunkings, he should be familiar with the industry's practically absolute resistance to anything "theoretical" -- jargon for "not product-specific". Over a period of 15 years or so I have persisted in my efforts to convince trade magazines, book publishers, conference organizers, user groups, even academic departments, to dedicate more space and time to data fundamentals: concepts, principles, methods, etc. But I've become a lonely voice, because practitioners have bought lock, stock and barrel into the "how-to" that Burnett is referring to, and have no interest in "all that theoretical stuff." As a concrete example, I recently proposed a new book that would compare relational, SQL, object and XML DBMSs on their underlying data models (if any) and it was rejected by three major publishers. Without demand from practitioners, my arguments can be readily marginalized as "purist," "religious," "theoretical" (even my editor here joins the bandwagon by referring to me as "irascible"). Without demand for fundamentals, how does Burnett think he will get more such information in this so-called "free market" system, which supposedly supplies "only what customers demand"? And without knowledge of, or interest in fundamentals, how will such demand arise?
Note: Most events, publications and institutions have some direct or indirect business or other association with vendors and the trade media (e.g., sponsorships, show booths, lecturers, conferences, etc.) and vendor/media personnel sit on editorial committees which make decisions about articles, books and lectures. Vendors have a lot if interest in product-specific cookbooks, but no interest in (or even a negative attitude toward) fundamentals. In fact, one of the three rejections of my proposed book was by an editor of a book series employed by a major vendor and who could not see the difference between my proposal and other books already published by that publisher. If I disclosed the name of person involved, you'd be surprised.
One of the major reasons for the successful take-up of OOP (as opposed to OODBMS) was the book "Design Patterns" by the Gang of Four. This established a number of common problems and their solution with examples. It also established a methodology for defining new situations and their solutions. Irrespective of your programming religion, this book is a classic and a "must-read" by any software developer. Mr. Pascal would do us all a favour if he promoted a Relational Design Patterns book and website where common problems that need to be tackled through a relational design -- and their implementation -- are examined similarly to "Design Patterns." They could even publish the book with their own comments as a good source of revenue.
I'm afraid Burnett loses me here. Here's how I describe my book in the Preface:
It identifies a set of common, recurring database -- as distinct from application -- issues, that DBMS users and vendors seem to be particularly unclear on, have difficulties with, or fail to address correctly -- many examples are from actual database projects and all chapters include, where pertinent and possible, SQL and [sometimes] product-specific solutions and, when available, workarounds.
If that is not "establishing a number of common problems and their solutions with examples" and "a methodology for defining new situation and their solutions," then I don't know what is. And this has been consistently the kind of material I've been writing for years.
One of the most common misconceptions in the industry is that relational technology is all about database design. Just design your databases relationally and you'll be OK. But that misses a large part of the relational point: unless the DBMS itself is relational -- that is, it is a DBMS and it is a true and full implementation of the relational model -- practical benefits will not accrue, regardless of database design. In fact, in previous articles in this series, I demonstrated how SQL products, by ignoring, deviating from, or violating relational principles, make correctly designed relational databases a liability, rather than an asset. When that happens users, who are not properly educated, end up bastardizing their design, unaware of the integrity implications. There are many vendors and consultants who provide exactly such "how-to" advice for those interested and I leave it to them.
Note: If the book had the impact on OOP claimed by Burnett, there may have been another good reason for it. From reading my book, Burnett should know that OO is essentially a set of guidelines for writing "good" programs. Therefore, OOP makes sense. It is only when the industry tried to extend OO to database management that problems arose, because not having been intended for that task, the OO approach does not provide a specific data model equivalent to the relational model. What is more, OO concepts are fuzzy and lack a theoretical foundation. In their formal proposal for a truly relational data language called D, Chris Date and Hugh Darwen demonstrate that a true RDBMS would provide all the benefits claimed for ODBMSs, but without the latter's flaws (see their book The Third Manifesto).
After reading Mr. Pascal's columns (I read them all avidly) and his book, I feel enlightened but frustrated. Not only do I need to design better, but those designs need to be deployed with a practical user interface. It is my experience that the more detailed the design, with respect to the numbers of tables and relationships, the more time it takes to produce effective user interfaces to create, read, update and delete -- CRUD. This is especially so through the web, as most of my work seems to be nowadays, where controlling multi-table updates is a struggle. Mr. Pascal is spot on here when he points out the risks to data integrity when taking design shortcuts for user interface simplicity, so I simply fight hard to make my CRUD forms work properly.
If Burnett feels enlightened and frustrated, the book has achieved a major part of its objective. This is exactly how practitioners ought to feel and the knowledgeable ones do.
However, while user interfaces are critical aspects of database practice, they are at the application, not database level! As I explained in Understanding relational databases, they involve communication between the user/developer and the DBMS, and presentation of results. I agree that DBMSs should have good user interfaces, but this is a completely separate issue from what I am focusing on, which is database functionality. No matter how good a user interface is, if the DBMS does not provide a complete and sound foundation for data management (see, for example, MySQL and InnoDB: Are they DBMSs, let alone relational?, my exchange with Suneido DBMS's designer, and my exchange on the so-called "Associative Model of Data"), solving them at the application level defeats the whole purpose of database management.
The fact is, though, all CRUD activities for the limited number of ways tables can be organised together can be patterned. Just as an example, think of the entity super and sub type approach in Mr. Pascal's book. Try and actually implement this with an intuitive user interface and you will come across all sorts of problems unless you have understood that the user interface should not be aware of the super-sub split, but simply see views of each whole entity. Mr. Pascal points out that many RDBMSes do not support updating of multi-table views, but does not give us a handy list of those that do! I use RDBMSes that do support updateable views (within some limits, I admit). He also doesn't give us an alternative approach to entity super and sub types that can be used in all databases. In conclusion, my point is simply that design is meant to smooth the way for the real thing -- implementation. Simply slagging off (is this a UK English expression?) the vendors helps no-one. We need 'how to's' that take a problem, show its suggested design solution and then gives a practical approach to implementation in an RDBMS. If we can't or don't organise a well stocked and easily accessible store of relational design patterns, the OODBMS fellas will win.
I am not sure I understand Burnett's argument here. My point in the chapter on entity supertypes and subtypes that he refers to is that they are readily accomodated within the relational framework of views, whereby all theoretically updatable views are updatable by the DBMS. The mechanism of SQL "supertables" and "subtables" would have not been necessary at all, had SQL supported full view updatability. But SQL DBMSs do not permit multi-table views to be updated, which is caused by SQL's relational infidelity. This is not a user interface, but a database issue, and resolving it at the application level misses the point.
Note: The cost of limiting view updatability in SQL goes much beyond entity supertypes and subtypes. This restriction robs products of logical data independence, one of the major practical benefits of relational technology: it relieves users from having to change applications when certain types of change in tables occur. This is not a user interface issue either.
Burnett complains that I do not provide a handy list of those products that do allow multitable view updates. Well, the reason for that is simple: as far as I know, there are no SQL products that allow that (those that are claimed to do so cannot guarantee correctness). The reason is explained in my book: SQL does not support constraint inheritance, which means the DBMS cannot infer integrity constraints on derived tables (such as views) from the constraints on the base tables and the table operations underlying the derivation. Without such inference, the DBMS cannot guarantee the logically correct propagation of view updates to the underlying base tables and, therefore, vendors have simply restricted their products to not allow updates of such views. This should be very clear to anybody who really knows and understands relational technology and would not require any listing from me.
Note: The algorithms for updating multi-table views were specified in a three-part series of articles by Chris Date and David McGoveran in "Database Porgramming and Design" and as far as I know, no product supports those algorithms. I received one comment from an Oracle employee that the current version of Oracle does update multitable views, but he has not expanded on it and I just don't see how this could be done correctly without constraint inheritance and, particularly, without the assurance that each table has a key (keys are optional in SQL). Oracle certainly does not implement the said algorithms.
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
