Client Server Databases

Literature

Tamer Özsu and Patrice Valduriez : Principles of distributed database systems. Second Edition,
Prentice Hall, Englewood Cliffs, New Jersey, 666 pages, 1999
ODBC - Tutorial : ADABAS ODBC Reference
PERL - Reference
 

What You'll Learn This Week

 Database System Architectures

o Mainframe Architecture
o Stand-Alone PC Architecture
o File Sharing Architecture
o Classic Client/Server Architecture
o Three-Tier Client/Server Architecture
 Open Database Connectivity

Database System Architectures

 There are a number of database system architectures presently in use.
 One must examine several criteria:
1. Where do the data and DBMS reside?
2. Where are the application program executed (e.g., which CPU)? This may include
the user interface.
3. Where are business rules (applications logic) enforced?

Traditional Mainframe Architecture

 Database (or files) resides on a mainframe computer.

 Applications are run on the same mainframe computer. e.g., COBOL programs or JCL
scripts that access the database.
 Business rules are enforced in the applications running on the mainframe.
 Multiple users access the applications through simple terminals (e.g., IBM 3270 terminals
or VT220 terminals) that have no processing power of their own. User interface is text-
mode screens.
  Example: DB2 database and COBOL application programs running on an IBM 390.
 Advantages:
o Excellent security and control over applications
o High reliability - years of proven MF technology
o Relatively low incremental cost per user (just add a terminal)
 Disadvantages:
o Unable to effectively serve advanced user interfaces
o Users unable to effectively manipulate data outside of standard applications

Personal Computer - Stand-Alone Database

 Database (or files) reside on a PC - on the hard disk.

 Applications run on the same PC and directly access the database. In such cases, the
application is the DBMS.
 Business rules are enforced in the applications running on the PC.
 A single user accesses the applications.
File Sharing Architecture

 PCs are connected to a local area network (LAN).

 A single file server stores a single copy of the database files.
 PCs on the LAN map a drive letter (or volume name) on the file server.
 Applications run on each PC on the LAN and access the same set of files on the file
server. The application is also the DBMS.
 Business rules are enforced in the applications - Also, the applications must handle
concurrency control. Possibly by file locking.
 Each user runs a copy of the same application and accesses the same files.
 Example: Sharing MS Access files on a file server.
 Advantages:
o (limited) Ability to share data among several users
o Costs of storage spread out among users
o Most components are now commodity items - prices falling
 Disadvantages:
o Limited data sharing ability - a few users at most

Classic Client/Server Architecture

 Client machines:
o Run own copy of an operating system.
o Run one or more applications using the client machine's CPU, memory.
o Application communicates with DBMS server running on server machine through
a Database Driver
o Database driver (middleware) makes a connection to the DBMS server over a
network.
o Examples of clients: PCs with MS Windows operating system. Forms and reports
developed e.g. Oracle Developer/2000,  etc.
 Server Machines:
 o Run own copy of an operating system.
o Run a Database Management System that manages a database.
o Provides a Listening daemon that accepts connections from client machines and
submits transactions to DBMS on behalf of the client machines.
o Examples: Sun Sparc server running UNIX operating system. RDBMS such as
Oracle Server, Sybase, Informix, DB2, etc.

PC with Windows NT operating system.

 Middleware:
o Small portion of software that sits between client and server.
o Establishes a connection from the client to the server and passes commands (e.g.,
SQL) between them.
o See ODBC below.
o Examples:

For Oracle: SQL*Net (or Net8) running on both client and server.
For Sybase: Sybase Open Client and Open Server.
For IBM DB2: Client Application Enablers

 Business rules may be enforced at:

o The client application - so called "Fat Clients".

o Entirely on the database server - so called "Thin Clients"
o A Mix of both.
2. We can also call this a "Two Tier" or "Two Level" Client/Server Architecture
3. Advantages of client/server:
o Processing of the entire Database System is spread out over clients and server.
o DBMS can achieve high performance because it is dedicated to processing
transactions (not running applications).
o Client Applications can take full advantage of advanced user interfaces such as
Graphical User Interfaces.
4. Disadvantages of client/server:
o Implementation is more complex because one needs to deal with middleware and
the network.
o It is possible the network is not well suited for client/server communications and
may become saturated.
o Additional burden on DBMS server to handle concurrency control, etc.
o As more business rule logic is programmed into the client side applications, they
can become unwieldy. Stored procedures and triggers can help in this case.
5. Examples:

o Oracle Server RDBMS running on a server.

 Oracle Developer/2000 running on a client PC (connected with SQL*Net as the
middleware).

o Oracle Server RDBMS running on a server.

Sybase-PowerSoft PowerBuilder running on a client PC.

o Oracle Server RDBMS running on a server.

MS Visual Basic application running on a client PC.

o Sybase Adaptive Server RDBMS running on a server.

C++ application running on a UNIX workstation.

Three-Tier Client Server

 Same general situation as traditional client/server.

 Difference is the enforcement of business rules (applications logic) is done in a "middle"
layer. Sometimes called "application logic" server.
 Another option is to aggregate transactions from multiple users with a Transaction
Monitor
 Is "web friendly". The web browser becomes the user interface on the client.
 Advantages:
o Centralize applications logic (one place to make changes)
o Relieves clients from having to load up on applications logic (the "fat client"
approach).
o Frees up DBMS server to efficiently process transactions
 Disadvantages:
o System complexity - extremely complex to program and debug
o Security issues
 Examples:
o Oracle Server RDBMS running on a server.

BEA Tuxedo Transaction Processing System running on the "Middle tier"

Sybase-PowerSoft PowerBuilder running on a client PC.

o Oracle Server RDBMS running on a server.

Oracle Web Applications Server running on the "Middle tier"

MS Internet Explorer (web browser) running on a client PC.

o Sybase Adaptive Server RDBMS running on a server.

Sybase Enterprise Application Server including the Sybase Jaguar CTS

transaction processing system running on the "Middle tier"
C++ application running on a UNIX workstation.

o Microsoft SQL Server running on a Windows NT Server

Microsoft Transaction Server (MTS) running on the Middle tier

Microsoft Visual Basic application running on the client PC

o IBM DB2 RDBMS running on the back end

IBM CICS transaction management

COBOL application
BTW, for those of you from the UNIX world, simply replace "PCs" with "UNIX Workstations"
in the phrases above. 

Example Study : Sybase Client-Server Databases

Mainframe Computing

Mainframe computing was the popular computing model before the client/server model became
the widespread standard. In mainframe computing, the mainframe performs all processing and
uses a "dumb" terminal (one with no processing power of its own) as a display unit. For
example, retrieving and displaying employee information on a terminal requires the following
steps:
 
1. Display a form on the terminal into which a user can enter an employee ID

 
2. Accept the employee ID information.

 
3. Validate the format of the information.

 
4. Check the availability of the employee information.

 
5. Get the employee information from the database.
6. Format the data for display on the users terminal.

 
7. Display the employee information on the terminal.
  
 

 We can categorize these tasks as those related to data presentation (steps 1, 6, and 7),
those related to data validation (steps 2 and 3), and those related to data access (steps 4
and 5). The mainframe performs all of the steps because the terminal has no processing
capability.

 In the mainframe processing model, the server is heavily loaded because it performs all
of the processing for every client (mainframes are computing monsters) In the
client/server model, however, clients can perform some portion of the application
processing, such as data presentation and some data validation. This off-loading of some
tasks to clients with processing power improves performance because the server has more
time for processing requests.

Client/Server Computing in the Database Environment

In just the last few years, the client/server model has gone from being the "new trend" in
distributed (networked) computing to the "traditional model" for implementing distributed
computing. It divides processing into client applications and server applications that cooperate
to accomplish tasks for the integrated application.
 

Here are a few of the many advantages that client/server computing offers over the
computing models that came before it:

 Simplifies computer interactions for the user because smart clients implemented on
desktop workstations present graphical user interfaces (GUIs) and multimedia
applications. The cost of developing applications that use these types of interfaces for
desktop workstations is less expensive than it is for the servers in mainframe computing.

 Reduces network traffic, which improves performance. Consider the example given
previously in the section ``Mainframe Computing''. The mainframe model requires three
network events: in step 1 when the host must display the form on the screen; in step 2
when the client sends the employee ID back to the host; and in step 6 when the host sends
the employee information back to the terminal and displays it. The same example using
the client/server model requires only two network events: for step 4 when the client sends
the employee ID to the server and in step 6 when the server sends the employee
information back to the client.

 
  Allows an organization to use a variety of equipment to meet the needs of different
applications and users because it supports a heterogeneous environment. Programmers
can get the processing power they need from workstations, and managers can work with
computers that are best for creating schedules and other spreadsheets using desktop
computers. The organization can save money by giving each employee the right amount
of computing power needed to do their jobs.

 Facilitates implementation of open systems because it is built around the International

Standards Organization (ISO) Reference Model for networked systems. This model
specifies an application programming interface (API) layer which hides the intricacies of
lower level software, making it easy to add new hardware and applications.

 
 

Client/Server Nodes and Implementation

Client and server applications can reside on the same computer, or node; however, in a
distributed computing environment, they usually reside on different nodes. Nodes are
distinguished as client nodes and server nodes depending on their role.

Client nodes tend to be generalized. Computers that run client applications may include many
types of clients, such as a directory client, a file client, and a print client. There are often many
nodes running the same client applications so that a single server node, such as a print server,
serves several client nodes. Although a single server node can accommodate more than one
server application, system designers often implement server applications on dedicated server
nodes because servers tend to be more specialized and require more processing and system
resources than clients.

A server application is typically a continuous process (for example, a daemon in UNIX) while a
client application is most often a standard application program. During the course of its normal
processing, a client application calls API routines to send the requests to a server. When the
client has finished its work, it stops execution. As a dedicated process, the server runs
continuously: it waits for requests, detects them, processes them, returns the results, and then
waits for the next request.
 

Relative Roles of Clients and Servers

The terms "client" and "server" characterize relative roles rather than absolute roles. For
example, in executing a print request, the print server becomes a client if it has to ask a file
server to send it a copy of the file it is going to print.
Architecture is fully functional when it allows clients to act as servers and servers to act as
clients when necessary. For example, Sybase implements this capability with the Open Client
and Open Server products. Sybase applications that have both client and server functionality
incorporate both Open Client and Open Server libraries.

FigureClientServer shows an example in which an application acts as both a client and a server.
As a server, it responds to requests from and returns results to the Open Client application. As a
client, it makes requests of the SQL Server and processes the results of those requests.

FigureClientServer: An application can act as both client and server

Sybase Client/Server Database Environment

In the Sybase client/server database environment, SQL Server runs all of the actual database
management system¯it does all the processing associated with database access. The database
server carries out the tasks initiated by client requests directed to the database. It is built on a
multithreaded architecture and ensures data integrity, concurrency control, and the ability to
recover from failures. The database server also maintains the data dictionary which defines the
structure and contents of the database. The database client performs all the processing not
associated with database access.
 

The Two-Tier Model

In a two-tier configuration, client applications connect directly to server applications and submit
requests using Open Server applications or remote procedure calls (RPCs). RPCs allow users to
open a connection to a single SQL Server, and that SQL Server can then access data from many
other servers. A SQL Server application programmer can write custom event handlers to process
client requests.

The first tier in a two-tier configuration consists of presentation and application logic. Examples
of applications at this layer are:
  

 SQL access tools

 Application development tools (code generators)

 
The second tier in a two-tier configuration offers direct service management and handles
connections. It can include database servers and general purpose servers such as e-mail and print
servers. Examples of these applications are:
 

 SQL Server applications that do not require global distributed transaction support
 Print, mail, or compute servers built with Open Server
 Client messaging services built on event notification that use Open Server as a messaging
hub

 
 
FigureTwoTier shows SQL Server and Open Server applications in a two-tier configuration.

Figure TwoTier: Two-tier architecture

 
 

The Three-Tier Model

When developers design and implement software using a component model, they create self-
contained software blocks or components, each with a specific function. A component can be
replaced by another that has the same specifications without rewriting or changing surrounding
components. This component model for software design also results in the ability to reuse
components.

Three-tier architecture, based on the component model, is a popular design solution for large or
complex server applications that run under some type of middleware, such as a transaction
processing monitor or an object-oriented environment. The three-tier architecture allows the
flexibility and freedom to replace components without affecting the rest of the system.

Advertissment ????? Sybase is the only database company that makes it easy to implement an
independent application in the middle tier of a three-tier software architecture. FigureThreeTier
illustrates the three-tier topology using Sybase products.

Figure ThreeTier: A Sybase three-tier model

The functionality of each tier is as follows:

 The first tier supports presentation services on the client system. Minimally, it helps
windowing systems display and manipulate data. This tier might also validate user input.
This tier consists of Sybase products from the "tools" layer, such as PowerBuilder or
Optima++.

 The second tier (or middle tier) can enforce business rules and referential integrity
across all components of the third tier, supports global distributed transaction
management, and supports service mapping similar to a gateway application. This tier is
implemented as an intermediate server. It consists of Sybase products from the
"middleware" layer, such as OmniCONNECT or Open Server.

 The third tier is a back-end server that handles data integrity and local transaction
branches. It has local responsibility for controlled resources, which are often database
systems. This tier consists of Sybase products from the "database" layer, such as SQL
Server, Sybase MPP, Sybase IQ, and SQL Anywhere.
  
 
Three-tier architecture gives the application complete independence with respect to both the
front-end tool and the back-end datastore and makes it easy to extend database functionality.
Many MIS developers find the three-tier construct essential.

In environments that do not support a three-tier topology, developers must integrate business
rules either in the front-end tool or the back-end datastore. Business rules can be integrated with
the back-end datastore by programming them in stored procedures or a trigger, a special kind of
stored procedure that automatically executes whenever data is inserted, updated, or deleted in the
columns with which the trigger is associated. Programming business rules in triggers results in
dependence on the datastore, so if business rules change, the database might need to be
reoptimized.
 
 

Open DataBase Connectivity (ODBC)

 Middleware has historically been proprietary. Note also subtle differences in SQL and
how it is implemented in various DBMS.
 How can a single client access multiple DBMS servers with minimal changes ?
 ODBC is middleware software that can connect a client to multiple servers from different
vendors.
 ODBC has two main portions that reside on the client: A Driver Manager and one or
more DBMS drivers.
 The Driver Manager presents a uniform interface to all clients. This consists of a set of
function calls to query, update and manipulate data on a server
 A DBMS Driver is typically supplied by the individual DBMS vendor and contains
routines to convert requests from the Driver Manager into commands the specific DBMS
understands.
 Try this: Visit several DBMS vendor's web sites and see if they offer an ODBC driver
that can be downloaded to your PC.

 
Example of the use of Open DataBase Connectivity (ODBC)

What ODBC means to application developers

ODBC was designed to allow application developers to decide between using the least common
denominator of functionality across DBMSs or exploiting the individual capabilities of specific
DBMSs.

ODBC defines a standard SQL grammar and set of function calls that are based upon the SAG
CLI specification, called the core grammar and core functions, respectively. If an application
developer chooses only to use the core functionality, they need not write any additional code to
check for specific capabilities of a driver.

With core functionality, an application can:

 Establish a connection with a data source, execute SQL statements, and retrieve results.
  Receive standard error messages.
  Provide a standard logon interface to the end user.
  Use a standard set of data types defined by ODBC.
  Use a standard SQL grammar defined by ODBC.

ODBC also defines an extended SQL grammar and set of extended functions to provide
application developers with a standard way to exploit advanced capabilities of a DBMS. In
addition to the above features, ODBC includes a set of extensions that provide enhanced
performance and increased power through the following features:

 Data types such as date, time, timestamp, and binary.

  Scrollable cursors.
   A standard SQL grammar for scalar functions, outer joins, and procedures.
  Asynchronous execution.
  A standard way for application developers to find out what capabilities a driver and data
source provides.

ODBC example: Win32::ODBC and Perl script

The following two tables will be used :

Table 1: Sauces

Field Name Type Length Notes 

ProductID AutoNumber n/a Sequence / Primary key 
ProductName Text 25  
Quantity Number Double in ounces 
Price Number Double  
PepperType Text 20 main type of pepper in sauce 
rating of heat content; Jalapeño pepper = 3-4,000 units,
Scoville Text Long
Scotch Bonnets (Habañero) = 2-300,000 units! 

Table 2: State

Field Name Type Length Notes 

PID Number Integer Process ID - Multi-key Primary key 
ProductID Number Long Foreign Key into Sauces table - Multi-key Primary key 
Sequence Number Integer Multi-key Primary key 

To get started, let's write a simple script that extracts all the data from the database and writes
them out in a table. The first thing to do, as when using any Perl module, is to tell the script that
we want to use the module.

        use Win32::ODBC;

Next we tell it to create a new ODBC object:
        my($db) = new Win32::ODBC("Article");
This creates an object ($db) which connects to the data source named 'Article'. If we had a user
name and password associated with this data source, we could supply them all using an ODBC
connect string:
        my($db) = new Win32::ODBC("dsn=Article; uid=foo; pwd=bar");
where 'Article' is the Data Source Name, 'foo' is the User ID, and 'bar' is the Password.

Next, we write the SQL to extract the data (the capitalization is for stylistic reasons):
        $db->Sql("SELECT * FROM Sauces");
and then the loop to fetch the data, one row at a time:
        while ($db->FetchRow()) {
                ...
        }
Inside the while loop we actually get the data. In Win32::ODBC, there are two actions, one to
fetch the row, and one to get the data that was fetched. There are also two ways to get the fetched
data, Data() and DataHash(). The former returns the data into an array, in the order it was
selected in the SQL statement. The latter returns the data into a hash, in the form
'$hash{FieldName} = DataValue'. If you select all fields using the "*" wildcard, as we did, then
the field order that the data comes back in is undefined, so using Data() might not make sense.
We'll use DataHash(). Finally, we close the ODBC handle before the end of the program.

Putting it all together, the script should look something like the following:

        use Win32::ODBC;

        my($db) = new Win32::ODBC('Article');

        $db->Sql("SELECT * FROM Sauces");

        while ($db->FetchRow()) {

                my(%data) = $db->DataHash();

                print HTML "<TR><TD>$data{'ProductName'}";

                print HTML "    <TD>$data{'Quantity'} ounces";
                print HTML "    <TD>\$$data{'Price'}";
                print HTML "    <TD>$data{'PepperType'}";
                print HTML "    <TD>$data{'Scoville'} Scoville Units";
        }

        $db->Close();
Transactions
Some ODBC drivers support transactions, with commits and rollbacks (see Data Sources to find
out how to determine if your driver supports this). Sometime after connecting (usually
immediately after, but it depends on your logic flow) you can set the AutoCommit option off,
and then rollback or commit depending upon program flow:
        $db->SetConnectOption('SQL_AUTOCOMMIT', 'SQL_AUTOCOMMIT_OFF');
        ...
        if ($fatal_error) {
                $db->Transact('SQL_ROLLBACK');
                die "Error - rolling back\n";
        }
        ...
        $db->Transact('SQL_COMMIT');
Data Sources
Sometimes you don't know ahead of time which database you need to connect to. You can query
the ODBC Manager and get a list:
        print HTML "<SELECT NAME="DataSources" SIZE=1>\n";
        
        my(%dsn, $key) = Win32::ODBC::DataSources();
        
        foreach $key (sort keys %dsn) {
                print HTML "<OPTION>$key\n";
        }
        
        print HTML "</SELECT>\n";
This will produce a box with all of the data sources listed. But suppose you knew you only
wanted Oracle databases. The value of the returned hash contains the name of the driver, so you
could filter them:
        my(%dsn, $key) = Win32::ODBC::DataSources();
        
        foreach $key (sort keys %dsn) {
                print HTML "<OPTION>$key\n" if $dsn{$key} =~ /Oracle/;
        }
Once you have connected to a driver, you can query it to see if it can handle a specific ODBC
API function, such as transactions:
        my(%data) = $db->GetFunctions($db->SQL_API_SQLTRANSACT);
        my($transOK) = $data{$db->SQL_API_SQLTRANSAC};
        
        $db->SetConnectOption('SQL_AUTOCOMMIT', 'SQL_AUTOCOMMIT_OFF')
                if ($transOK);
or you could query the connection for things like the database name and version:
        my($db_ver) = $db->GetInfo($db->SQL_DBMS_VER);
        my($db_name) = $db->GetInfo($db->SQL_DBMS_NAME);
 
 

High-level ODBC

 Look in the Control Panel (shown here, from Windows 95):

 Open up the 32bit ODBC icon. This is called the ODBC Data Source Administrator or
ODBC Administrator for short.
 Click on the ODBC Drivers tab to see which drivers are installed:
 In the above example, we have ODBC drivers for

IBM DB2
Microsoft Access, MS Excel, MS Foxpro, MS Visual FoxPro
Borland dBase and Paradox
Text files
Oracle 8
MS SQL Server
Sybase System 11

To add more drivers, download or install the ODBC driver from the database
manufacturer. The ODBC driver will then appear on this list.
 

 Clicking on the User DSN tab shows those data sources that have been defined for this
user.

(DSN = "Data Source Name", see before)

A user data source simply gives a name to a configuration that includes:
The specific ODBC driver to be used
In some cases, the specific database table or file that will be used
 If necessary, a username and password required to gain access to the database
FInally, any other options the particular ODBC driver requires