This chapter includes the following sections:
A distributed environment is chosen for various applications where:
The data is generated at various geographical locations and needs to be available locally most of the time.
The data and software processing is distributed to reduce the impact of any particular site or hardware failure.
When a relational database management system (RDBMS) allows data to be distributed while providing the user with a single logical view of data, it supports "location transparency." Location transparency eliminates the need to know the actual physical location of the data. Location transparency thus helps make the development of the application easier. Depending on the needs of the application, the database administrator (DBA) can hide the location of the relevant data.
To access a remote object, the local server must establish a connection with the remote server. Each server requires unique names for the remote objects. The methods used to establish the connection with the remote server, and the naming conventions for the remote objects, differ from database to database.
Oracle allows remote objects (such as tables, views, and procedures) throughout a distributed database to be referenced in SQL statements using global object names. In Oracle, the global name of a schema object comprises the name of the schema that contains the object, the object name, followed by an "at" sign (@), and a database name. For example, the following query selects information from the table named scott.emp in the SALES database that resides on a remote server:
SELECT * FROM firstname.lastname@example.org
A distributed database system can be configured so that each database within the system has a unique database name, thereby providing "effective" global object names.
Furthermore, by defining synonyms for remote object names, you can eliminate references to the name of the remote database. The synonym is an object in the local database that refers to a remote database object. Synonyms shift the responsibility of distributing data from the application developer to the DBA. Synonyms allow the DBA to move the objects as desired without impacting the application.
The synonym can be defined as follows:
CREATE PUBLIC SYNONYM emp FOR email@example.com;
Using this synonym, the preceding SQL statement can be changed to the following:
SELECT * FROM emp;
Microsoft SQL Server or Sybase Adaptive Server requires schema objects throughout a distributed database to be referenced in SQL statements by fully qualifying the object names. The complete name of a schema object has the following format:
server_name is the name of a remote server. The
database_name is the name of a remote database on the remote server.
Microsoft SQL Server or Sybase Adaptive Server does not support the concept of synonyms or location transparency. In a distributed environment, objects cannot be moved around without impacting the application, as the developers must include the location of the object in the application code.
Most of the static queries tend to include the references to the remote server and remote database. Some applications maintain a user table to map the complete object names (including the remote server name and the database name) to dummy object names. The queries refer to these dummy object names. The translations are performed in real-time with the help of the map in the user table. This limitation precludes any common scheme of referring to remote objects that can work for Oracle and Microsoft SQL Server or Sybase Adaptive Server.
The Microsoft SQL Server Omni SQL Gateway server allows location transparency, but this requires that the schema definitions of all the databases participating in the distribution must be available with the Omni SQL Gateway server.
Replication functionality in Microsoft SQL Server or Sybase Adaptive Server has the following characteristics:
Table-based, not transaction-based
No automatic conflict resolution (must be manual)
Heterogeneous replication through Open Database Connectivity (ODBC)
In addition to the preceding characteristics, Microsoft SQL Server 7.0 replication provides heterogeneous replication through ODBC.
Oracle replication has richer replication functionality, which includes the following:
Any database object can be replicated
Automatic conflict resolution
Heterogeneous replication provided through gateways
Since Oracle distributed environment and replication support is a superset of Microsoft SQL Server or Sybase Adaptive Server, conversion of distributed applications from Microsoft SQL Server or Sybase Adaptive Server to Oracle is feasible.
Several application development tools that are currently available use specific features of one of the various database servers; you may have to invest significant effort to port these products to other database servers. With critical applications, it is sometimes best to develop and maintain a different set of application development tools that work best with the underlying database, as ODBC support is not adequate in such cases.
The majority of Microsoft SQL Server or Sybase Adaptive Server applications are written using ODBC application programming interfaces (APIs) or Visual Basic. DB-Library is widely used to develop 3GL applications with Microsoft SQL Server or Sybase Adaptive Server as the back end.
Since Oracle provides ODBC connectivity, it is possible to convert ODBC-based Microsoft SQL Server or Sybase Adaptive Server applications to work with an Oracle back end.
If a Visual Basic application is written with ODBC as the connection protocol to access Microsoft SQL Server or Sybase Adaptive Server, it is possible to modify and fix the Visual Basic application to work with an Oracle back end.
Many Visual Basic applications use VB-SQL which is DB-Library for Visual Basic. VB-SQL allows Visual Basic programs to access Microsoft SQL Server or Sybase Adaptive Server natively (as opposed to using ODBC). Such applications can also be converted to work with an Oracle back end, if you replace the VB-SQL database access routines with Oracle Objects for OLE.
Oracle provides a call interface knows as Oracle Call Interface (OCI), which is functionally equivalent to the DB-Library API. Conversion of DB-Library applications to OCI applications is feasible.