DB 문서들
DSN 갤러리
DBMS Tutorials 916 게시물 읽기
 News | Q&A | Columns | Tutorials | Devel | Files | Links
No. 916
Client/Server Database System
2004-02-05 21:31

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

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

                *   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

                *   provides/processes/handles the application's user

                *   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
                        *   "The role of this software is to interact
                        with the communications hardware to send and
                        receive messages between the DBMS driver and the

                        *   sometimes this communications software is called an
                       (API), an implementation of a protocol or set of
                       protocols designed specifically for this purpose. (I

                        *   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

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

1065[참고자료] 공개커넥션풀 프로그램 (connection pooling)
1057Howto Install Tomcat 5 + Apache 2 in WinXP
923Apache Module mod_authn_dbi
916Client/Server Database System
915Introduction to data warehousing [1]
866SQL 의 기초 (3)
865SQL 의 기초 (2)
Valid XHTML 1.0!
All about the DATABASE... Copyleft 1999-2024 DSN, All rights reserved.
작업시간: 0.017초, 이곳 서비스는
	PostgreSQL v16.2로 자료를 관리합니다