Over the years, many technologies (and those marketing these technologies) have claimed that data has become irrelevant and that some “new and improved” technology, technique, or ideology will replace data as the center of IT and data processing. But it has yet to happen, and it never will happen, either!

Object-oriented Fantasy

One pretender to the throne was (dare I say, is) object-oriented (OO) technology. The object proponents claim that objects, because they encapsulate both data and the processes that manipulate the data, are superior to data. This is pure fantasy. OO development works well for pre-planned, recurring workloads. When the developer can plan and implement all of the methods required for the object, the OO way of doing things will work fine. But is this really anyone’s idea of reality?

Many workloads and requests are unplanned. Ad hoc queries, OLAP, and data mining require access to data in ways that were not originally imagined when the data (or object) was first created. A proper database design, created from a logical data model, and implemented using a “relational” database enables ad hoc access to data using SQL. If instead you had to rely on the “OO way,” you would have to develop new methods for the objects to look at the data encapsulated therein in a different way. The performance of the new methods is likely to be poor if the data within the object must be accessed in very different ways.

But the matter gets further complicated if your unplanned data analysis requires data encapsulated in multiple objects. The OO way would require multiple methods to be invoked by each object that contained the required data and then some program to cobble the results together. The beauty of relational databases using SQL is their flexibility and suitability to perform unplanned data gathering and analysis, quickly and with minimal effort. And, without redesigning the database or writing complex new programs (or methods).

Furthermore, with today’s DBMS technology, code can reside in multiple places: procedural code on the database server in the form of stored procedures; and user-defined functions, within active database rules in the form of triggers and constraints, and on multiple application tiers. Rigid conformance to encapsulated methods within objects imposes a strict development methodology that may cause more harm than good.

More Natural Way

The basic argument made by most OO proponents goes something like this: First of all, an object is a more natural model for representing the real world. By adhering to OO tenets, the potential for reuse is high. Furthermore, OO properties such as inheritance and polymorphism provide additional flexibility for application development, enabling the programmer to modify objects to suit the circumstances. The overall goal is to use OO development techniques to create reusable components that can be combined together to build applications.

The argument is compelling, but misleading. To whom is an object “more natural,” and as compared to what? It is very natural indeed for people to relate to most data the way a relational database does, as rows and columns — we do it every day on business forms, checkbook registers, spreadsheets, phone books, and so on. Furthermore, it is quite possible to create reusable components without adhering to the OO philosophy or using OO development techniques. Component-based Development (CBD) proponents are doing this very well today without rigidly conforming to OO development rules. And for those gray-beards out there, isn’t that what COBOL copy books were all about?

Now, I don’t want to totally and completely dismiss object-oriented technology, but it is within the realm of programming that it provides benefit. Any benefits OO can provide to DBMS technology have already been incorporated into most DBMS products (that is, extensible data types). For OO to achieve any long-term success, a practical OO development environment that interoperates with and maps to relational databases must be established. And it must not compromise good data modeling and relational database design practices in doing so.

Data as Corporate Asset

The bottom line is that data has intrinsic value and it should not be forced to co-exist with program logic (methods) before it can be stored. Neither should limitations be placed on data that would require complex object-oriented program logic to be written for every data access requirement.

Data is a corporate asset and should be treated as such. There are myriad benefits to modeling data. Persistent data stored in relational databases is an elegant and useful way to support the planned and unplanned needs of your organization. And it will continue to be so for many years to come.

--

Craig Mullins is an independent consultant and president of Mullins Consulting, Inc. Craig has extensive experience in the field of database management having worked as an application developer, a DBA, and an instructor with multiple database management systems including DB2, Sybase, and SQL Server. Craig is also the author of the DB2 Developer’s Guide, the industry-leading book on DB2 for z/OS, and Database Administration: Practices and Procedures, the industry’s only book on heterogeneous DBA procedures. You can contact Craig via his web site at http://www.craigsmullins.com.