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

Previous | Table of Contents | Next

## Chapter 15
OLE DB and Active Data Objects

• OLE DB and Active Data Objects used to gain access to stored data in non-object-based format • Thor is special product for DB2 access from OLE DB • Outgoing interfaces can be used with Active Data Objects • Storage Objects provided as part of DCOM—own file system

One of the key things that developers have always found is that computing consists of a combination of the execution of functions and the manipulation of data. Some functions only need data stored in the computer’s memory, but the majority of functions need data that is stored safely on a secure storage medium—a storage medium that can maintain a record of the data even after the computer has been switched off. All simple and obvious stuff, of course, but object-based computing is based on the idea that data is stored with function, which makes any data access that much more complex. In this chapter, we will find that OLE DB is just one of a number of features within DCOM that enable a developer to access data—data in a variety of formats.

### Back to Basics-Storing Data

There are four main methods that can be used to store data generated or used by a program:

  • Memory
  • Shared memory
  • Distributed shared memory
  • File systems and DBMSs

Figure 15.1 OLE DB and Active Data Objects

A single program can store temporary data in its memory, two or more programs on a single machine can store their shared data in shared memory, two or more programs on different machines can store their data in distributed shared memory, and one or more programs can store its data in a file system or DBMS.

As we saw in chapter ten, DCOM supports the storage of data in memory and shared memory via Windows NT. Windows NT provides a virtual memory system that enables up to 32 processes to read shared memory on that host as long as the manufacturer’s HAL drives are installed. MTS also provides shared memory support. Neither DCOM nor Windows NT supports distributed shared memory.

Memory provides a mechanism of storing temporary data—data that is needed only for the duration of the execution of the program. But practically all programs need to store data permanently so that it can be used again by different programs at different times. This permanent storage mechanism must preserve the state of the data even if the machine is switched off. All very obvious, but the proponents of object-oriented methods have coined a phrase for this—persistent data.

Over the years we have seen an extraordinary multiplicity of different types of persistent data mechanisms emerge. The start, of course, was the early file systems with products like ISAM and VSAM. But over the years we have seen all sorts of “models” for data storage emerge. I will first take a look at the types of persistent storage system there are now to understand something of the reasons why products such as ODBC and OLE DB exist.

A brief history of DBMSs

The first DBMSs started to appear in the late ’60s and early ’70s. Since then, the IT industry has seen a plethora of different “types” of DBMS, in other words, products conforming to some basic set of principles. The main types of DBMS are:

  • two-level networks
  • hierarchical
  • network (Codasyl)
  • relational
  • object oriented
  • extended relational

The very first types of DBMS were based on “two-level networks” and included DBMSs such as TOTAL or IMAGE. IBM then produced a DBMS based on what is now referred to as a “hierarchical” model and which we now know as IMS or DL1. Other more esoteric DBMSs used at this time were based on transposition and inverted lists, for example, ROBOT.

Even in the late 1960s, DBMS vendors and end users started to realize the benefits of standardization, and the first standards work to be undertaken was initiated by the Codasyl (Conference on Data System Languages) committees, a group established in 1959 and responsible for the language COBOL. Two subcommittees—the Database Task Group and the Data Description Language Committee—produced a specification for the DML (Data Manipulation Languages) and DDL (Data Definition Languages) for what were to be called “network databases.”

Products conforming to this specification include IDMS/X and CA-IDMS, IDS, VAX DBMS (from Digital), DMS 1100, MDBS, and so on. These DBMSs proved to be high performance, reliable, and excellent transaction processing machines, and large numbers of firms bought and developed strategic systems using them.

IBM rejected the Codasyl proposals (primarily from a marketing standpoint, as it had no DBMS conforming to the standard) and started to promote the relational model proposed by Ted Codd via a number of papers produced in the early 1970s.

IBM, along with many new startups, realized they could leapfrog to the new relational paradigm by using the work of the exploratory System R* research project and consequently bypass the competition. The combination of IBM, Ted Codd, and the publicity that surrounded him and the emergence of companies like Oracle with equally good marketing muscle tolled the death knell for the Codasyl proposals, and, by the early to mid-1980s, Codasyl DBMSs ceased to be developed.

Oracle was released in 1979 and represented the first commercialised version of SQL. In 1981, IBM produced SQL/DS, a commercial version of System R* for VM/370. This was followed in 1983 by SQL/DS, rewritten for MVS and known as DB2. The release of DB2 created considerable publicity for IBM and the relational approach in general.

A flood of products has since appeared conforming to the relational model. They included Ingres, Sybase, Informix, Rdb, Interbase, SQLBase, Rbase, CA-DB, Non Stop SQL, and so on. End users have bought and developed large numbers of systems using them.

Previous | Table of Contents | Next