The future of software development is with object-oriented development techniques. Many practise it already, and many more are adopting each day. It is backed by such software giants as Microsoft, IBM and Sun with their application development platforms, but driven by the practical benefits ranging from quicker development times to lower costs and easier maintenance.
Unfortunately, the majority of corporate development includes accessing data held in relational databases, leading to what is known as impedance mismatch between object and relational technology. Henry Adams, country manager of InterSystems South Africa, examines the conundrum.
Impedance mismatch is the term commonly used to describe a problem that occurs when an object-oriented (OO) application houses its data in a legacy relational database (RDBMS). It is the result of an inherent lack of affinity between the object and relational models, and it gives rise to a host of development problems. Some of these problems include lengthier time to market and increased costs of design, lengthier development and quality assurance cycles, and compromised code maintainability and extensibility. In addition, the hardware bill also increases because the organisation is forced to buy more powerful systems if it is to ensure that response and throughput times are maintained.
The impedance mismatch condition results from the differences in relational and object-oriented database management systems. Simply stated, tables in the relational model organise data in rows. Complex data structures can require many tables with expensive joins, and the business logic operations are applied from sources outside the table: for example, via embedded SQL or static, pre-coded stored procedures or triggers.
To build an effective and efficient application in the relational model, the developer must have a comprehensive knowledge of the tables, any relationships among them and of the external logic components.
In contrast, classes in the object model are self-contained entities that store related data (embedded classes and collections) within the "container" class rather than as a separate table. Business logic is not applied externally in the object model; instead, a class implements methods that contain code for operating on the class`s properties. Methods provide interfaces through which they are called and the application developer is buffered from the complexities of the schema.
Impedance remedies
There are four approaches organisations can select from to address the impedance mismatch issue:
1. Using the object facilities of a relational database
While RDBMS vendors have made valiant efforts to add object capabilities to their engines, they have not solved the problem. None is a true object implementation and, in many ways, they suffer from the impedance mismatch themselves.
Inheritance, polymorphism and encapsulation are not concepts easily blended into the core technologies offered by these vendors. In the end, a developer is reduced to manipulating a quasi-object layer on top of the still-existent RDBMS.
2. Using object-relational mapping tools
Many database vendors or third parties offer products that provide "object-relational mapping" software to associate application classes with underlying tables in an RDBMS. These tools can be very effective in helping develop the code required to expose a relational schema to an object-based application. However, object-relational mapping tools tend to shift responsibility back to the developer, as problems become more complex and incur cumulative costs as the application is changed to meet evolving organisational needs.
3. Adoption of an object database
Another approach to dealing with impedance mismatch is to adopt a purely object database. The advantage to using these databases is their affinity for OO concepts. Unfortunately, problems still occur because transactions posted against the RDBMS must be available to the object-oriented database management system (OODBMS); and impedance mismatch can still exist between SQL-based applications and object databases. They also tend to adopt one proprietary object implementation over another, primarily Java, which reduces the freedom of the developers to innovate and often encumbers them with overly complex layers of technology.
4. Adoption of post-relational databases
Post-relational databases use a multidimensional storage engine, but abstract it in order to project multiple data models simultaneously. They do not require any intervening mapping tools or caching middle tiers. Object persistence methods are projected directly to the object developer, while simultaneously being projected to the relational developer as familiar tables with stored procedures. Each sees what they would normally expect from their native environment with the database automatically and transparently taking care of the translation. In fact, the developers can mix object and relational access methods as their applications require. This approach minimises, if not obviating, impedance mismatch issues.
When evaluating which solution suits a particular situation, some questions to consider are:
* Is the technology quickly and easily adopted and integrated?
* Is the technology extensible enough to satisfy future application and database needs?
* Is the technology flexible enough to integrate newer technologies such as XML and SOAP?
* Can the technology provide the scalability and performance needed to enable an organisation to deploy it to the Web and/or enterprise-wide without undue impact on infrastructure and operations?
* Is the technology useful in resolving certain development issues, only to create additional downstream run-time problems?
One thing is certain: The marketplace is quite clear that OO is the desired approach for new application development and the evolution of legacy applications. Organisations with heavy investments in RDBMS must decide whether they will take a short, medium or long-term view in mitigating the effects of the impedance mismatch between the object and relational paradigms.
Share