Communication methods

The Relational Database Management Systems are based on the client-server architecture. There is a database server which handles queries incoming from multiple clients, called also users for simplicity. A single RDBMS handles multiple connections with the users at the same time.

Almost each of RDBMS available these days has its own communication protocol. It is usually provided to programmers as a library of API (Application Programming Interface) functions. A programmer is free to use such a library in his or her program to establish a two way communication between the program and the database. The program, which is a client application, can communicate with a given database system for which the library provides the communication protocol.

For example, an application designed to communicate with Oracle is capable of communication with Oracle only. It cannot be used to connect to another RDBMS, unless this RDBMS provides the same communication protocol as Oracle does.

The protocol serves the purpose of establishing the communication. It allows to send a query, and to retrieve the reply. It is also called the call-level-interface CLI [7]. Concerning RDBMS, the query is sent in a form conforming to the SQL syntax.

Having a separate CLI for each database significantly reduces flexibility. The first attempt to standardize the CLI was made in '90s by the SQLAccess Group (SAG). The SA specification served as the basis of ODBC: Open Database Connectivity specification developed by Microsoft^10.1. The interface is pretty complicated, but it became the standard for the database connectivity. It is an API (Application Programming Interface), a set of functions calls based on the SQLAccess Group specification.

ODBC is provided as three components: the ODBC Library, ODBC Driver Manager and ODBC Driver. Applications use the Library to communicate with an abstract data source using ODBC functions. The data source is provided by the Driver Manager along with an ODBC driver. The ODBC driver is a bridge between ODBC and the database.

The application accesses ODBC functions, through ODBC Driver Manager, which dynamically links to the appropriate ODBC driver. The driver translates ODBC request to native format specific for a particular database. An application, based on ODBC, can communicate with any data source which provides the ODBC driver. There are such drivers for most of the database systems these days, the list includes, but it is not limited to: Oracle, Informix, DB2, PostgreSQL, MySQL, Interbase.

Providing ODBC as the user-ReDaReS and ReDaReS-database communication method seems the most reasonable choice then. It gives flexibility, and makes the inference system database independent. The productive implementation of ReDaReS should consist of: the Inference Engine, Preprocessor, and the ODBC driver. Additionally, there will be relations, created in the database, holding the Matchings and Program.