SQL and Networking

The dramatic growth of computer networking in the 1990s had a major impact on database management and gave SQL a new prominence. As networks became more common, applications that traditionally ran on a central minicomputer or mainframe moved to local area networks of desktop workstations and servers. In these networks, SQL plays a crucial role as the link between an application running on a desktop workstation with a graphical user interface and the DBMS that manages shared data on a cost-effective server. More recently, the exploding popularity of the Internet and the World Wide Web has reinforced the network role for SQL. In the emerging three-tier Internet architecture, SQL once again provides the link between the application logic (now running in the middle tier, on an application server or web server) and the database residing in the back-end tier. The next few sections discuss the evolution of database network architectures and the role of SQL in each one.

1. Centralized Architecture

Figure 3-2 shows the traditional database architecture used by DB2, SQL/DS, and the original minicomputer databases such as Oracle and Ingres. In this architecture, the DBMS and the physical data both reside on a central minicomputer or mainframe system, along with the application program that accepts input from the user’s terminal and displays data on the user’s screen. The application program communicates with the DBMS using SQL.

Suppose the user types a query that requires a sequential search of a database, such as a request to find the average order size for all orders. The DBMS receives the query, scans through the database fetching each record of data from the disk, calculates the average, and displays the result on the terminal screen. Both the application processing and the database processing occur on the central computer, so execution of this type of query (and in fact, all kinds of queries) is very efficient.

The disadvantage of the centralized architecture is scalability. As more and more users are added, each of them adds application processing workload to the system. Because the system is shared, each user experiences degraded performance as the system becomes more heavily loaded.

2. File Server Architecture

The introduction of personal computers and local area networks led to the development of the file server architecture, shown in Figure 3-3. In this architecture, an application running on a personal computer can transparently access data located on a file server, which stores shared files. When a PC application requests data from a shared file, the networking software automatically retrieves the requested block of the file from the server. Early PC databases, such as dBASE and later Microsoft’s Access, supported this file server approach, with each personal computer running its own copy of the DBMS software.

For typical queries that retrieve only one row or a few rows from the database, this architecture provides excellent performance, because each user has the full power of a personal computer running its own copy of the DBMS. However, consider the query made in the previous example. Because the query requires a sequential scan of the database, the DBMS repeatedly requests blocks of data from the database, which is physically located across the network on the server. Eventually, every block of the file will be requested and sent across the network. Obviously, this architecture produces very heavy network traffic and slow performance for queries of this type.

3. Client/Server Architecture

Figure 3-4 shows the next stage of network database evolution—the client/server database architecture. In this scheme, personal computers are combined in a local area network with a database server that stores shared databases. The functions of the DBMS are split into two parts. Database front-ends, such as interactive query tools, report writers, and application programs, run on the personal computer. The back-end database engine that stores and manages the data runs on the server. As the client/server architecture grew in popularity during the 1990s, SQL became the standard database language for communication between the front-end tools and the back-end engine in this architecture.

Consider once more the query requesting the average order size. In the client/server architecture, the query travels across the network to the database server as a SQL request. The database engine on the server processes the request and scans the database, which also resides on the server. When the result is calculated, the database engine sends it back across the network as a single reply to the initial request, and the front-end application displays it on the PC screen.

The client/server architecture reduces the network traffic and splits the database workload. User-intensive functions, such as handling input and displaying data, are concentrated on the user’s PC. Data-intensive functions, such as file I/O and query processing, are concentrated in the database server. Most importantly, the SQL language provides a well-defined interface between the front-end and back-end systems, communicating database access requests in an efficient manner.

By the mid-1990s, these advantages made the client/server architecture the most popular scheme for implementing new applications. All of the most popular DBMS products—Oracle, Informix, Sybase, SQL Server, DB2, and many more—offered client/server capability. The database industry grew to include many companies offering tools for building client/server applications. Some of these came from the database companies themselves; others came from independent companies.

Like all architectures, client/server had its disadvantages. The most serious of these was the problem of managing the applications software that was now distributed across hundreds or thousands of desktop PCs instead of running on a central minicomputer or mainframe. To update an application program in a large company, the information systems department had to update thousands of PC systems, one at a time. The situation was even worse if changes to the application program had to be synchronized with changes to other applications, or to the DBMS system itself. In addition, with personal computers on user’s desks, users tended to add new personal software of their own or to change the configuration of their systems. Such changes often disrupted existing applications, adding to the support burden. Companies developed strategies to deal with these issues, but by the late 1990s, there was growing concern about the manageability of client/server applications on large, distributed PC networks.

4. Multitier Architecture

With the emergence of the Internet and especially the World Wide Web, network database architecture took another step in its evolution. At first, the Web was used to access (browse) static documents and evolved outside of the database world. But as the use of web browsers became widespread, it wasn’t long before companies thought about using them as a simple way to provide access to corporate databases as well. For example, suppose a company starts using the Web to provide product information to its customers by making product descriptions and graphics available on its web site. A natural next step is to give customers access to current product availability information through the same web browser interface. This requires linking the web server to the database system that stores the (constantly changing) current product inventory levels.

The methods used to link web servers and DBMS systems evolved rapidly in the late 1990s and early 2000s, and have converged on the three-tier network architecture shown in Figure 3-5. The user interface is a web browser running on a PC or some other thin client device in the front tier. It communicates with a web server in the middle tier. When the user request is for something more complex than a simple web page, the web server passes the request to an application server, whose role is to handle the business logic required to process the request. Often, the request will involve access to an existing (legacy) application running on a mainframe system or to a corporate database. These systems run in the back tier of the architecture.

As with the client/server architecture, SQL is solidly entrenched as the standard database language for communicating between the application server and back­end databases. All of the packaged application server products provide a SQL-based callable API for database access. As the application server market has converged around the Java2 Enterprise Edition (J2EE) standard, Java DataBase Connectivity (JDBC) has emerged as the standard API for application server access to databases.

Source: Liang Y. Daniel (2013), Introduction to programming with SQL, Pearson; 3rd edition.

Leave a Reply

Your email address will not be published. Required fields are marked *