DB2 Data Links Manager Quick Beginnings

Overview to DB2 Data Links

The amount of data stored digitally is growing rapidly because computer systems and storage systems have become very affordable. The file paradigm is very common for such datatypes as video, image, text, graphics, and engineering drawings because capture, edit, and delivery tools use the file paradigm for these datatypes.

A large number of applications store, retrieve, and manipulate data in files. These applications may use files to store their data for one or more of the following reasons:

Cost

You should consider the expense required to rewrite applications that use standard file I/O semantics to use a database as a repository.

Also, your applications may use existing tools that work with the file paradigm. Replacing these tools can also be expensive.

Performance

The store and forward model of data is unacceptable for performance reasons. For example, it may be unacceptable for the database manager to materialize a Binary Large Object (BLOB) into a file, and the converse, each time the data needs to be accessed as a file.

Also, data is captured in high volumes, and you do not want to store it in the database.

Network considerations

You want to access data directly from a file server that is physically close to a workstation. For example, the file server can be configured so that the network distance is much shorter to the user, compared to the database where all the BLOBs are stored. The number of bytes that flow for a large object are much larger than the number of bytes for an answer of an SQL query. Network distance between resources is therefore a significant consideration.

Isochronous delivery

The application uses a stream server because it has real time requirements for delivery and capture. The data are expected to be large, and you may require isochronous delivery. An example of isochronous delivery might be a video server that delivers high-quality (or "jitter-free") video to a client workstation in real time. In these kinds of applications, it is likely that such data will not be moved into the database as a BLOB, but rather stay on the file server.

Many of these applications need search capabilities to find the data in the files. These search capabilities, however, do not require physically bringing the data into the database system, because their raw content is not needed for the query. Typically, you would extract features of an image or a video and store them in the database for performing a search on the extracted features. An example of the features that can be extracted from an image are color, shape, and texture. The IBM DB2 Universal Database Extender for Image product supports extraction and search functions on such features.

The ability to store a reference to such files, along with parametric data that describes their contents is, in general, the approach used by these applications to combine the search capabilities of SQL with the advantages of working directly with files to manipulate the raw data. The DB2 relational extenders for text, voice, image (and so on) provide this functionality. The extenders allow you to specify whether the object itself is to be maintained either in or outside the database.

Currently, the DB2 relational extenders do not provide referential integrity between files on a server and their references in databases. Therefore, it is possible to independently delete either the reference or the file. Moreover, the extenders do not provide access control to the related files or coordinated backup and recovery schemes for a database and its associated files.

DB2 Data Links technology solves these problems and provides the functionality required by such applications. Future releases of the DB2 relational extenders will use Data Links technology.