If the goal was to create a query that joined two tables, the SQL statement could be revised to be:

Select order_id, customer_id, order_amt,

customers. customer_name from orders,



order_id='111222' and customers.customer_id

= orders.customer_id;

To the application developer, little must be done, other than issuing the query request. SQL is a data access language. It supports expressions, operators, and Create, Retrieve, Update, Delete (CRUD) operations. It’s a simplistic, powerful language, and is considered the de facto standard for data access.

As SQL became more accepted, the development community agreed to interfaces that simplified data access from application programs. This meant that developers could issue their SQL requests through one of those interfaces, and not have to worry about proprietary database Application Program Interfaces (APIs). A key attribute of an SBM is providing these interfaces as middleware components. Another name for these components is drivers or providers. Their main task is to receive the SQL request and control the execution logic necessary to fulfill the task. Ultimately, their request will entail making the appropriate action call on the data source.

Federated Data Access

There are times when multiple data sources are required to fulfill a business function. An example might be a VSAM record that has a lookup code that requires looking at an ADABAS record. Another request might be migrating data from one data source to another. Federated data access requires that the data dictionary be able to store more than a single data source. Several SBMs implement this feature, which lets developers use multiple data sources from a single virtual database (data dictionary).

Selecting a Provider

When evaluating an SBM solution, the vendor chosen is significant. The following are key considerations:

• Data source: Does the vendor provide support for all the needed data sources?

• Hardware/OS: Does the vendor provide a solution that runs on your hardware and operating system?

• Performance: Time the queries you intend to use and see which SBM is fastest.

• Data type support: Legacy sources tend to have many custom data types. Ensure that the SBM has all that are appropriate for your system.

• Correctness: Does the provided solution produce consistent, correct results?

• Importing legacy data: Can the SBM easily import your legacy data into its data dictionary?

• Evaluation: Does the vendor provide evaluations of their product and adequate support during the evaluation period?

• Price: A high price shouldn’t necessarily rule out a vendor; a low-cost solution might mask other hidden costs such as support.

• Security: Does the SBM offer protection for the data?

• Driver interfaces: Does the vendor supply interfaces for ODBC, JDBC, OLEDB, and .NET?

• Tools: Are there helpful tools that complement the SBM?

• Support: Are technical support and consulting continuously available?

• Vendor track record: How long has the vendor been in business?

A Google search on ODBC, JDBC, OLEDB, VSAM, Data Access, and IMS might provide several sites that link to SBM providers. Noted database expert Ken North offers a list of SBM providers at www.sqlsummit.com/ODBCVend.htm.


An SBM solution offers several advantages to organizations using legacy data. Real-time SQL access for Internet and desktop applications offers functionality that might postpone the need for a costly migration. Change seems to be the word for this new era, but make sure that it’s the right change.

6 Pages