I’ve written in the past on delusions and illusions in the industry about technology fads being advanced as innovations and new approaches, when in reality they are nothing new. In one case — XML — not only isn’t it new, but actually it’s a regression to something that was tried and discarded more than three decades ago, because it was not effective, cost- or otherwise (see “The XML Bug”). And XML is hardly a lone case: doing away with DBMSs altogether and handling everything in Java applications is another example of regression to the bad old days of files and application programs.

Such fallacies are rooted in the widespread lack of knowledge and understanding of data fundamentals. Fads characterized by accelerated obsolescence are exactly what should be expected when sound foundations are ignored, and without the damper effect of knowledge, there is a strong economic incentive for frequent fads: whole mini-industries emerge to support them — software and hardware tools, books, magazines, seminars, conferences, consultants (many gaining “expertise” practically overnight). If you don’t jump on the bandwagon, you’ll be left behind, they say. In reality, often just the opposite is true.

One such misconception currently making the industry rounds is the notion that business rules are some sort of innovation, a “new approach” to data management. A major proponent is the Business Rules Group (BRG), organizer of the Business Rules Forums (BRF). I already demonstrated the fallacy in that position (see “Something to Call One’s Own”). But now consider the following being advertised for the next BRF:

“**Standards Groups to Hold Joint Session at the 2003 Forum**

The Object Management Group (OMG) Business Rules SIG and the Business Rules Group (BRG) have teamed up for the second year to hold work sessions at the Forum.

The OMG Business Rules SIG is focused on developing standard approaches for integrating business rules into the OMG’s Model Driven Architecture (MDA). The Business Rules Group (BRG) has been publishing standards around the business rules approach since 1995.

These two standards organizations will hold a joint plenary session on Thursday afternoon. Topics of discussion will include …

• OMG’s roadmap for business rule standards.
• Collaboration with the BRG on a meta-model to respond to the OMG’s RFP covering Business Semantics and Business Rules for business people.
• Current activity on other business rule standards, including Production Rules for Inference Engines, Rule Management, and Business Models.”

Some Fundamentals

Business models are collections of business rules based on perceptions of reality (see “What Do You Mean?”) Here is a very simple business model consisting of two business rules:

• Employee identified by employee number (EMP#) is assigned to project (PROJ);
• An employee can be assigned to one or more projects;

Business models are inherently subjective and informal. Consequently, there is no scientific way to define and validate correctness — defined as accurate representation of reality — of business models/rules: there can be as many perceptions of reality as there are perceivers, and none can be objectively preferred over the others.

It follows that business rules are not directly merchandisable, such that their consistency, including that of inferences from them, can be guaranteed. In the above example, DBMS software would not understand what employee or employee number are, what “identified by” or “is assigned to” mean, and so on. Only users understand that.

To represent business models in computerized databases for the purpose of mechanizing consistent inferences from them, they must be mapped to representations that (a) capture as much of the user meaning as possible and (b) are formal and, therefore, mechanizable.

This is what logical models are: formal database representations of business models.

The mechanism for mapping business to logical models is the data model which, in order to produce formal representations amenable to computerization, must itself be formal. And as I argued so many times, the only known formal data model with a well-defined and most simple theoretical foundation — logic — is the relational model.

The above business model maps relationally to a R-table:

Logical models consist of integrity constraints, the formal representation in the database of business rules. Thus, the first rule above maps to the table header constraint, and the second to a composite key integrity constraint (uniqueness) on the EMP# and PROJ combination of columns.

Because R-tables have properties of mathematical sets, they can be computerized. And because integrity constraints are formal representations of business rules, formal logic — namely, predicate logic—can be applied to guarantees that the logical models and the mechanized inferences drawn from them are correct in the consistency sense.

Standardizing Perceptions?

Given that business models are — and have always been — nothing but collections of business rules, one must wonder, first, on what was OMG’s so-called “Model Driven Architecture” based, if not on rules? How is it possible to have a MDA that is not based on business rules, and to incorporate the rules into whatever a MDA is post-facto?

Second, if business rules (and models) are based on subjective, informal perceptions of reality, and if they are not computerizable “as is,” what sense does it make to try and “standardize” them, on what grounds should one standardization be preferred to another, and for what purpose? It is rather obvious from the amount of nonsense that OMG has expressed over the years (without any tangible achievement to show for it), that it does not understand data fundamentals (and cannot be expected to, given its reliance on fuzzy “objects”). And since it is willing to participate in such an endeavor, neither does BRG.

Note: The object approach to data management is notoriously poor at handling integrity constraints, hence the “Johnny-come-lately” to the rules game.

What does make a lot of sense is to standardize on a formal data model, because it produces formal logical models that are computerizable, and the results of their manipulation can be guaranteed to be consistent. And in the absence of a better alternative to logic, the best candidate is the relational model.

OMG and BRG are representative of the industry as a whole. As long as the fundamentals are ignored, the significance of a data model in general, and the relational model in particular will not be properly appreciated. The result is the abysmal failures in the industry’s data management standardization efforts.

One example is SQL. Even though it was developed as a concretization of the relational model, its incomplete and poor implementation by the industry is so far from the model, as to fail to deserve the relational label. Indeed, the ANSI SQL committee went out of its way to ensure that the term “relational” was not even once used in the whole standard. Others and myself have amply documented the negative and costly consequences for the language, including the predictable implementation errors and complications and the cross-variations that can hardly be deemed standardization.

Another example is XML. It is worse than SQL, in two senses. First, it had no concept of a data model at all — as its founders argue, it has a “purely syntactic” character. Second, by the time attempts were made to extend it to data management, which is impossible without a data model, the model chosen was not relational, but the hierarchic model, one that was already tried and discarded decades ago. And like the old hierarchic DBMS technology, XML has promptly run smack into the very same problems that the previous proponents of hierarchies had encountered earlier: complexity, inflexibility, and insufficient semantics (meaning), particularly in the integrity area on which the business rules proponents now focus. So much so, that they had to discard the core XML object, the “document,” with an abstraction called a “sequence.”

Note: Proponents of XML databases have not really realized that a data model is required, because most don’t even know what a data model is and, what is more, they do not care. Rather, they have been scrambling to produce essential data management features such as data types, integrity and manipulation features without realizing that these are actually the components of a data model.

Instead of addressing the real problem, now the industry is going down yet other slippery slopes that lead nowhere. How likely is success at a level devoid of a formal foundation? (see “Metacrap: Putting the Torch to Seven Straw men of the Meta-utopia” for a similar, not very promising effort).

--

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 20 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 data management technology, strategy and implementation. Clients include IBM, Census Bureau, CIA, Apple, Borland, Cognos, UCS, and IRS. He is founder, editor and publisher of Database Debunkings, a Web site dedicated to dispelling persistent fallacies, flaws, myths and misconceptions prevalent in the IT industry. Together with Chris Date he has recently launched the Database Foundations Series of papers. Author of three books, he has published extensively in most trade publications, including DM Review, Database Programming and Design, DBMS, Byte, Infoworld and Computerworld. He is author of the contrarian columns Against the Grain, Setting Matters Straight, and for The Journal of Conceptual Modeling. His third book, Practical Issues in Database Management serves as text for his seminars.

Special Offer: Author Fabian Pascal is offering DBAzine.com readers subscriptions to the Database Foundations Series of papers at a discount. To receive your discount, just let him know you’re a DBAzine reader before you subscribe! Contact information is available on the “About” page of his site.