DCOM Explained
by Rosemary Rock-Evans
Digital Press
ISBN: 1555582168   Pub Date: 09/01/98

Previous Table of Contents Next


SQL (Structured Query Language), upon which many of today’s products and standards are based, was originally called SEQUEL and was conceived as a query language for databases aimed at the end user. Not surprisingly, the end user didn’t show the slightest interest in the language, so SQL was then developed to be a programming language.

Most developers found that to be useful, SQL had to be embedded in another language (using either embedded code or the call level interface) and that the nonprocedural nature of SQL was at times highly confusing and difficult to program. Vendors such as Oracle provided P*SQL (procedural SQL) to get around the deficiencies of the language.

In the early 1980s, ANSI and ISO initiated efforts to standardize the language resulting in the 1986 and 1989 SQL standards. During 1992, a more comprehensive standard (previously called SQL-2 and now known as SQL-92) emerged. The standardization process has tended to lag the vendors’ efforts at extending the language. For example, data type definitions in the ANSI 89 standard covered only a very basic set—INTEGER, SMALLINT, CHAR, VARCHAR—and did not cover such other important types such as date, time, float, decimal, character set, and conversions, or “blob” type data such as images or sound.

During the late ’80s and early ’90s, yet another paradigm for DBMSs was proposed—the Object model. The interest sprang from the need by the CAD/CAM community for a DBMS that could support the complex data and structures that their applications used.

Early OODBMSs were developed as extensions of object-oriented programming languages such as C++ and Smalltalk, but later work has produced special purpose languages capable of supporting inheritance, locking, recovery, and so on. The main standards-making body for Object-Oriented Databases is the OMG, and perhaps the most influential description of OODBMSs is the “Object Database Standard” produced by the ODMG in 1993 and supported by most of the major OODBMS suppliers—Object Design, Ontos, O2 Technology, Versant, and Objectivity. Take-up of OODBMSs has not been large. Most end users have bought them to support specialized applications.

The final development in the ongoing saga of DBMS development is the emergence of the “Extended Relational Model,” a hybrid of a relational model with object-oriented extensions. This approach is proving to be more popular with end users than the pure OODBMS, simply because it represents a more evolutionary path—one which does not require them to discard yet another DBMS. ISO has been working on a standard in this area—SQL3—but many of the relational DBMS vendors have added object-oriented extensions to their products ahead of the standard.

So what is the point of this? What it does mean is that a typical company could be using anything up to six different sorts of DBMS, each with their own paradigm, data manipulation language, and data definition language.

Most large IT departments have at least two DBMS and sometimes far more. The DBMSs straddle the entire range of types of DBMS—many companies have relational DBMSs, Network DBMSs, hierarchical DBMSs, some even have Object-Oriented DBMSs as well. Recent surveys of DBMS use show that large numbers of users still have a vast investment in IMS, CAIDMS, and IDMS/X, even DBMSs such as Image (from HP).

Furthermore, they often have several relational DBMSs—Oracle, Sybase, Access, DB2 on the mainframe, Unix midrange, and PC. Most of the databases based on these DBMSs contain vital strategic data, essential to the everyday operations of the company. But many end users are discovering that to develop new applications they require access to all the data in all the DBMSs wherever it resides.

To exacerbate the problem further, companies are also introducing data warehouses—databases of data culled from production files with the duplication removed and data cleaned up. These data warehouses often reside on specialized file systems rather than normal DBMSs.

The ideal for many companies would be to replace the old databases with a well-designed integrated database based on a single DBMS, especially as there is often considerable data duplication between the databases and the designs often leave much to be desired. But most companies can only justify replacement of these databases as part of some much wider business-led initiative—and even then, there may be no good business reason why the data and database itself should be replaced; it may only be the functions and underlying technology which require updating.

It is worth noting that the argument often used by the DBMS vendors that you need different DBMSs for different applications is also a valid one, but for different reasons from those they tend to use. You only need different DBMSs when the one you have isn’t up to the job. A DBMS should be capable of supporting all types of application. All they are admitting is that their DBMSs aren’t very good!

So the user is stuck. He or she needs to access all these different databases, but they lie on different machines and are often supported by different DBMSs. Existing databases can’t be merged and integrated, partly because there is often no good business reason to do so and partly because the DBMS vendors themselves admit their products don’t cover all the application uses. So the only solution is to find a way of accessing them all as they are.

We have already seen that one service provided by Microsoft within DCOM supports the update of data in different DBMSs—MTS. But this does not solve one fundamental residual problem with all this data in all these DBMSs.

If a company wants to access this data, its developers will probably have to use many different data manipulation languages and versions of languages. In addition, these same developers will also have to understand the different underlying philosophies used by each DBMS in order to be able to understand the data structures.

Data access without help is potentially a time-consuming, painful, costly, and unproductive task—prone to error. And so, we see the emergence of a new class of middleware onto the scene to solve the problem—database connectivity middleware.

Database Connectivity Middleware

Database connectivity middleware provides an insulating layer between the application and the DBMS. The database programmer uses one standard language to access all the DBMSs, whether these are relational, object oriented, hierarchical, network, or some other type. The middleware converts this standard language to the various flavors, versions or other languages of the target DBMS. Thus, for example, the middleware may convert ANSI standard SQL to the version of SQL used by Oracle, or the version of SQL used by Sybase.

This is a nice idea in theory but it does have some limitations. To understand this we need to take a brief look at how these products actually work in practice.


Previous Table of Contents Next