Dulcian,
Inc.
We’ve been hearing about object-relational (OR) databases for years. Over the last few years, my own papers and books have also included discussions of this important shift in the database community. C.J. Date’s book Foundation for Object/Relational Databases describes one vision of OR theory. OR databases will be our next paradigm shift in the database community. Relational databases will become the COBOL of the new millennium. Just like COBOL declined when newer languages such as C, and C++ came into being, relational databases will slowly decline in influence as OR technology takes hold. Of course, just as COBOL still clings to life, relational databases will continue to survive for many years. The relational products will evolve and take advantage of OO concepts. In his Foreword to Oracle8 Design Using UML Object Modeling book (Oracle Press, 1999), Martin Fowler, a leading object-oriented database theorist commented: “I do think that object databases will gain ground, but their share of the world’s data will still be very small. The big change will come from the relational databases as they extend their databases to support more object-oriented features.”
Object-relational databases have many advantages, but they will not be prevalent until vendors evolve their products to support the object-relational paradigm. Oracle has attempted to do this; but basic object-oriented features such as inheritance and polymorphism have not yet been fully implemented in the DBMS. We still don’t have the tools required to take advantage of the full potential of object-relational databases. However, this does not mean that we cannot take advantage of object-relational thinking right now. Dulcian started applying object-oriented thinking to relational systems design a few years ago with the result that the size of the systems being built greatly decreased, requiring smaller data models and fewer applications.
The core of object-relational thinking is the ability to incorporate greater levels of abstraction into our data models. This idea represents a major shift in the way that data modeling is done. Current relational databases are usually highly normalized models with little abstraction. Each “thing of interest” is instantiated as a relational table. As a result, systems frequently require hundreds of database tables and an equal number of screen modules and reports. The program modules are usually based directly on these tables with user workflow only instantiated through the way that the hundreds of screen modules interact.
However, a quiet revolution is taking place. A small number of data modelers are incorporating object-oriented thinking into their system designs. The enormous benefits of object-relational databases cannot be overstated. Systems that required 600 tables, 300-500 screen modules and hundreds of reports can now be built with a 50-table data model, a few dozen screen modules and less than twenty flexible reports. These OO-based systems deliver more functionality, are easier to maintain and will more easily support changes over time. In order to build these types of systems, a variety of techniques must be used. This article will outline four broad concepts necessary for creating “object-influenced” relational databases using object-oriented thinking:
1. Model abstractions
not specific object types. If you can abstract the objects you are modeling
to a higher level you can support a greater variety of objects and have a more
stable model. As an example, we built a system for a small retail organization.
Instead of using the traditional concepts such as Invoice, Purchase Order, etc.,
we thought more abstractly and came up with the notion of “Merchandise Movement”
which included all of the merchandise-oriented transactions associated with a
retail operation. This one simple shift allowed us to create a system with many
fewer tables, applications and reports while delivering more flexibility and
functionality. This was evident midway through the project when it was
discovered that, in gathering requirements, no one had mentioned the need for
making inter-store transfers of merchandise. In a traditional model, this would
have been disastrous and would have required extensive reworking of the original
data model. In our system, no extra effort was needed since the inter-store
transfers were simply included as another type of Merchandise Movement already
accounted for in the data model.
2. Business rules can be entered as data. Business rule storage and implementation is a popular topic at database conferences. Modelers are taking a variety of approaches to trying to model business rules with two approaches. The first is to try to come up with a general business rule engine that allows for the specification of any business rule. The second approach is to limit the domain of the business rules and create a more explicit model that supports the specification of rules in a relatively precise context. As yet, the generalized rule approach seems not to have been as successful. Though there have been some attempts to create a business rule grammar, these attempts seem to be too complex for most modelers to be able to use. On the other hand, context-specific grammars have generally been successful. These engines can be as specific as a simple rule engine that automatically calculates the status of an event, to complex generalized workflow engines. Even state transition diagrams and workflow rules can also be stored as objects in the database. This is done by creating code generators to build the necessary PL/SQL packages automatically.
Using these higher levels of abstraction leads to fewer necessary tables and applications. Once these types of structures are built, you have greatly expanded the functionality of your system. If your rule-based system is generic enough to support Rule A and Rule B, it is highly likely that when the inevitable Rules C and D crop up, they can be supported as well without expensive changes to the data model. Many different types of business rules can be stored as data.
3. Reports must be built
flexibly. Currently, it was common for systems to include hundreds of
reports using a different report for each specific business purpose. In an
object-relational environment, fewer structures and fewer applications also mean
fewer reports. Many reports such as Invoices and Purchase Orders may look
different but use very similar queries. Other than changes in the labels and the
fields displayed, the basic structure is very similar. In order to build the
types of reports needed for object-relational systems, a sophisticated reporting
tool such as the Reports component of Oracle Developer can be used to flexibly
pass information (sorts, breaks and filters) and allow users to dynamically
select fields. Creating these kinds of flexible reports can reduce the number of
reports needed from hundreds to a handful. Although this smaller number of more
complex reports may require more development skill, creating flexible reports
has the added benefit that when the database changes, only one or two reports
may need to be modified.
4. Build reusable
application components. In many
systems development efforts, you will find yourself building a structure with
very similar functionality to ones built for other systems. Sometimes, you may
be using the same type of structure multiple times within the same system. Not
only can this type of thinking be applied to small reusable components such as a
Calendar GUI widget, but it is also possible to build much larger and more
complex structures with their own small associated databases and applications.
One such example is a demographic information structure. The address and phone number of a
customer is the same type of information as the address and phone number of an
employee or internal organization unit. It is sensible to take such
functionality and encapsulate it, thereby creating one large application
component object (in this case, Demographics) that can be reused whenever
necessary. If a development organization adopts this philosophy, over time, a
larger and larger percentage of new application development can be supported
through these Complex OBjects (COBS). In systems that we now build, 20-40% of
the development effort is supported by pre-built COBs enabling us to focus all
of our attention on the parts of the system that are unique.
A second example of a good candidate for COB development is a workflow system. Many organizations have similar workflows. On the surface, the workflow steps may have different names, but recognizing core similarities across different businesses is a key step in creating reusable application components. In one project, we noticed that the procedure associated with purchase order processing was similar to that of the project approval process. Initially, the client identified nine separate workflow processes. Instead of building nine different workflows in our application, we were able to genericize a single workflow engine that could be attached to any portion of the system. This was particularly useful when the client discovered that there were actually twelve different workflows. Using our generic model, this discovery required no additional work.
Using this same
philosophy, in addition to reusable demographics and workflow components across
systems, we have developed components for handling Comments, Security, History,
Budgeting, and Reference Tables that can be bolted to any application with a
minimum of effort.
The object-oriented approach to data modeling will be something of a change for people familiar with entity relationship modeling. Even though we still end up with tables and relationships at the end of the process, the way to think about the modeling process has to change. Object-relational data models have several advantages over traditional data models:
· They require fewer entities (or “classes” in object-oriented terminology).
· They are more robust, in that they will support not only the specific user requirements gathered during the analysis phase, but will also usually support a broader class of requirements.
· They are more stable in that, as new requirements arise, the models will require fewer changes than traditional models.
Although object modeling has been around for some time, applying it to relational databases has not been widely discussed. Most database systems have been built using relational modeling. Object-relational (or “generic”) modeling is a relatively new way of thinking about database design. Going forward, we can build upon the best practices of relational databases and include object-oriented modeling with the goal of ultimately creating more efficient and flexible systems without sacrificing modeling clarity or performance.