|
Intro to Client-Server Database Systems
* also see: Connolly and Begg, Chapter 2, pp. 57-60
* First came the Mainframe/Terminal paradigm.
* Then came the equal Peer-to-Peer paradigm.
* Now comes something in between -- something that offers the
hierarchical structure of mainframes and the distributed computing
nature of peer-to-peer. CLIENT/SERVER.
* what do we mean by client-server?
* "A client-server system is a network of computers in
which some of the computers (called
clients) process applications while other computers (the
servers) provide services to the clients";
* hmm; I DON'T LIKE THAT; seems overly simplified;
* yes, there is a network of computers involved;
* some computers are servers of various services -
-- other computers, clients, can access these
services;
* ever heard of the idea of a process? (you would
have heard it in CIS 250, Operating
Systems); can think of a process as a program-in-
operation;
* I think you can think of a server program as
being a process running on one computer,
waiting for requests;
* when a client computer program --- process
--- on another computer wants to make such
a request, it sends the request to that server
process on that first computer;
* print-server? When you want to print, your program
sends a message to the computer running/handling printer services;
* web-server? Your browser process sends messages and
receives replies from a web-server process;
* and, of course, for this class, we are particularly
interested in a database server --- clients can
contact a database server process;
* By distributing the computing away from one place, the big
muscle of the mainframe can be replaced by less expensive
servers. (UNIX vendors are advertising heavily to fill this market,
threatening to push mainframes out.)
* On the software side, one can now buy off-the-shelf (no local
development costs!) client packages for the PCs and server
packages for the mainframes/servers to implement all sorts of
things nowadays. Such oftware has to be
* flexible,
* customizable, and
* capable of being run on all sorts of client and server platforms.
* in Kroenke, they consider each database to have a single database
server --- if a database were spread among two or more servers, that
would be a distributed database system; (more on that 2nd half of today's lecture);
* Remember, from the beginning we've pointed out how: (draw usual pic?)
* users often use application program
* application program communicates with DBMS
* DBMS handles nasty little file details, maintains
abstraction that database is a collection of tables
--- and, of course, it is the interface to the database.
* now, consider ---
* what does the application program do, in this
"relationship"?
* provides/processes/handles the application's user
interface
* invokes the application logic
* may enforce some business rules;
* calls the DBMS for database services;
* and, if the DBMS is relational, often
uses SQL statements to express such
service requests;
* what does the DBMS do, in this "relationship"?
* processes the SQL statements/requests it receives;
* may enforce business rules, too (those involving
triggers, for example, or those "set up" by
foreign key table constraints, for example)
* it returns data (in the form of tables) as well as error
or informational messages (the result of
the SQL statements sent?);
* and, of course, it (may!) provide reliability
(concurrency control, backups, etc.) and security
(passwords, access control, etc.)
* and, the DBMS will issue various commands that it needs to
to the operating system --- file input/output, etc.
* so, think about it --- all of these functions would be required in
any database system; they could easily all be done on a single computer.
* and, on a personal database running on a personal
computer, they are;
* one can also imagine a teleprocessing system, where
terminals access a mainframe, and everything
runs on the mainframe; (I prefer to think of this as the
mainframe/terminal paradigm)
* BUT --- one can also imagine this being split up onto
several computers in various ways!
* (most obviously?) the application program could be on 1
computer, and the DBMS and underlying
database on another; the DBMS and underlying database
could be on different computers; etc.
* according to Kroenke, p. 348, "With client-server database
systems, the application program is placed on the client computer
and the DBMS and operating systems file management programs
are placed on the server computer..."
* this makes sense to me, so I'll trust him on this!
* so, notice that redwood is our Oracle database server ---
* but, so far, in our work, we've been using it, really, in more of
a mainframe/terminal mode (I think) than a client/server mode;
we connect to redwood, and do ALL our work there! (None is
really being done by the client)
* could we use Oracle on redwood as a database server? Yes, indeed;
* but, you would need (as Kroenke says, p. 348) "a piece of
the DBMS, called the DBMS driver" on
the client;
* drivers are, I believe, commonly needed for
client/server interaction --- I've certainly heard of
printer drivers? (They're also common in terms of
software that interacts between the OS and
hardware, in general --- CD-ROM drivers, printer
drivers, math card drivers, etc.?)
* "The function of the DBMS driver is to receive
processing requests from the application and
format them for delivery to the DBMS";
* "it also receives responses from the DBMS
and formats them for the application";
* (DBMS lite? 8-) The local rep/liaison for
the DBMS? 8-) )
* There's also "a layer of communications software
placed on both the client and the
server."
* "The role of this software is to interact
with the communications hardware to send and
receive messages between the DBMS driver and the
DBMS"
* sometimes this communications software is called an
APPLICATIONS PROGRAMMING INTERFACE
(API), an implementation of a protocol or set of
protocols designed specifically for this purpose. (I
THINK)
* These protocols are implemented in the (in network
layer terms!) Application layer usually and are
sometimes referred to as MIDDLEWARE.
* [add: client may also be known as front-end
application, server may also be known as back-end
application]
* Let's consider Oracle, for a moment.
* Oracle database server uses SQL*Net as its
communications protocol with the client;
* (SQL*Net is a proprietary solution limited to
ORACLE databases, and is used by Oracle to send
SQL requests over a network)
* (seek to recreate pic on p. 348, fig 14-2 ---
User <--> | applic program | dbms driver | comm | <--nw--> | comm | dbms | os | <--> db
client computer(s) server computer
* so, note that the client computer
* manages the user interface,
* accepts data from the user,
* processes application logic,
* enforces (some) business rules,
* generates requests (SQL, usually?) for database services
* transmits those requests to the server and receives results
* formats the results for the user
* and, note that the server computer:
* accepts the clients' requests,
* processes them,
* returns a response
* while enforcing business rules,
* performing database integrity checking,
* maintaining the db overhead data,
* providing concurrent access control,
* providing recovery, and
* providing security!
* advantages and disadvantages
* (you know there are always tradeoffs in this sort of thing! 8-) )
* this kind of client/server system places application processing
closer to the user ---
* MAY result in better performance --- several CPU's, in a
sense, processing stuff in parallel!
* perhaps? less communication costs (than if all was being done
REMOTELY) (than for file-sharing systems?)
* only requests for DBMS processing and the responses
need to be sent over the communication network;
* CPU power is available to make user interface more elaborate;
(GUI's more practical!)
* potential for possibly a choice of clients
* control might be more difficult? (more truly parallel?)
* after all, the clients operate in parallel and process
applications in parallel;
* more chance of lost update, other multi-user control
problems; (hmm! Because I don't see how
you'd "lock" stuff based on SQL commands hmm)
* seque to distributed db's: in the above, we assumed that a database
was on a single computer, and that a single server provided access to
that database --- what if the database itself could be on more than
one computer?
That's getting into distributed database... more on that later!
|
