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!
|