Databases Reference
In-Depth Information
11.1.2 Understanding Client/Server Connectivity
In the traditional client/server model, you have two computer types involved.
These are the client that provides the interface with the user and the server that
stores and maintains the database. Though the traditional model puts the appli-
cation on the database server, realistically it can reside just as easily on the client
computers. In fact, that's the model used in most small-scale database applica-
tions. A copy of the application runs on each client PC and the client PCs share
the database stored on a central database server.
The basic foundation for connectivity, including the communication path,
physical connection, and the basic communication protocol, are provided by the
network. These are primarily the responsibility of network administrators (or a
similar role) within your company. That doesn't mean that you don't have your
own responsibilities as well. You might have protocol options available and have
to configure protocol use at the server.
Most discussions about database design focus almost exclusively (at least ini-
tially) on the data. However, the data is useless if you don't have a way to access it.
Database connectivity, built on the foundation provided by the network, is a
necessary part of your final design and a required component during imple-
mentation. The requirements for designing and configuring connectivity require-
ments are somewhat DBMS-specific, but there are some common factors that
should be discussed. When looking at requirements specific to DBMS imple-
mentations, we'll use SQL Server 2005 as our example. Though the implemen-
tation details may be different with other DBMSs, the general concepts and
requirements will be similar.
Understanding Connectivity Interfaces
During database design and implementation, you will make final decisions about
the communication path. Even though this is a function of the network on which
the clients and server are deployed, there are DBMS-specific options that con-
trol communication flow. After making these decisions, you have to determine
which data application programming interface (API) you will use.
To understand the role of the data API, imagine yourself as a bicycle courier.
You've been called by one of General Hardware Company's customers. You need
to pick up a package and deliver it to the customer. You arrive at General Hardware
Company, identify yourself, identify the customer, and request the package.
Package in hand, you ride across town and deliver it to the customer.
That's not unlike what happens in a communication session between a client
and a server. The requirements for that session are also similar to the physical
transfer. The client needs to identify itself to the server. In some configurations,
the server must also identify itself to the client through a process known as
mutual authentication.
The client needs to pass commands to the server and
receive a response. Your first thought might be that this is all handled by the
