 We talked about users, a clerk in the railway reservation system or an application programmer. There is another kind of user, special kind of user. He is called DBA or database administrator. You would have seen some advertisements for IT jobs as DBA experience of 5 years. Somebody who has managed databases as a database administrator. What does a DBA do? First coordinates all activities of the database system. Has a good understanding of the enterprise's information, resources and need and can perform the following duties. A, he can define schema and modify schema. Why that is important? Suppose there are 50 users. Suppose there is a reservation clerk. Suddenly decides that I should have this additional attribute or decides that I don't need this address attribute. With things work. Database schema definition is an extraordinarily important task and only one person is authorized to do that. That person is called DBA. It's like root in any multi-user operating system. Root has special powers. Storage structure and access method definition. What are the best physical storage such that when used in conjunction with the query optimizer, I'll get the best performance. Backup and recovery. So if a disk crashes, true, the SQL engine is able to recover. But somebody has to execute that recovery portion of the executed. And there is a certain method and discipline in doing that. User authorization. New user comes saying I want to be able to access the database. Then the DBA will say okay, what are your access levels? You can access this, this and this but not this, this and that. You can perform read but you can't perform insert. You can perform insert but you can't change. So no update. That's it. And then he does performance monitoring and tuning. When you execute the database, there is a lot of volatility of data. All data goes out. New data comes in. Data values change. Suddenly you find the indices which were created for a certain set of data are still not performing. You need to create new indices. You need to restructure indices. Whatever, all these jobs to get best performance and tune the database parameters is handled by DBA. Clearly DBA is a specialized functionality. If you look at an application program, typically the application programs will perform in the context of information system as opposed to numerical computational programs. They'll perform any one of these three tasks. First, there is a user interaction. So take a reservation clerk. There is an interaction with the user. Or you take, for example, you are sitting on a network and you are saying, give me a ticket. This will be a train model. So user has given some information which has to be collected. Then the application logic has to be executed. So whether the seat is there, what, what, what. And finally you have to access and update the database. These are the three components. Similarly, any application, you can have these. For example, the user interaction may consist of displaying a menu. So choices to the users. You want to do, you go to a site called xpedia.com or mytrip.com or something. You will get choices. You want to book a car. You want to book an aeroplane ticket. You want to book this. You want to book a hotel. You want to book whatever. These are the choices. You choose one choice. After making such choices, you will keep getting menus and finally you will have to somewhere give your data. What is your name? What's your data birth? From where to where you want to fly? This is input data. The user is given from the terminal. So you collect the data input through specially designed data entry forms and you have to perform data validation. So these tasks are required to be done and are considered part of user interaction. Finally, you collect query parameters if there is an SQL query. Select all names which begin with p. So you want to get fata, parquet, whatever. All the names. Now there is some query. The parameter of the query p will be given by the end user. We will see how to write such queries but this parameter has to be collected and sent back where the query has to be executed. From wherever back you send it, ultimately when the results come, these results are needed to be displayed or printed. This is also part of user interaction. And any special interaction like I am moving the mouse. Notice that when I move the mouse, this cursor is moving. If I type a character, the character appears here. I don't know how many of you are aware that in old Unix systems, when you type a character, that character is not displayed immediately although it appears displayed. That character actually travels back to the Unix server. The Unix server has a program which says character type K. Then it determines where this K should be displayed. Fifth row, 35th column. It will give that command and then my terminal will display it on fifth row and 25th column. Because your server and your front end machine is sitting just next to each other, you think that you are typing and something is up here. But if your server is 10,000 miles away and connected through a reset link, you can type, go smoke a cigarette, come back and then the character will appear. These precisely are the considerations which lead to a multi-tier architecture of the applicant. On the other hand, if you are sitting on a PC, when you type, actually what you type is not even a character K. What you type is a funny combination of row number and column number on the keyboard. That goes to the PC. PC determines, oh, this means character P and it keeps track of where your current cursor is on the display for which it has an internal data structure and then it sends the command back to the display. Keyboard and display are not connected to each other. Both are connected to the back end process. You don't realize this when you are using a PC. Essentially then, all user interaction in any information system, whether it is displaying menus, whether it is collecting parameters from the user, whether it is collecting data from the user or whether after processing of the query, update, insert, whatever, the results that you get are to be displayed or to be printed or any interaction such as mouse etc. are to be handled. All of these activities come under user interaction. And you will need spatial programming for determining this user interaction. Fortunately, many of these programs are built in as part of either the database management system or some other supporting software. But if you want any specialized thing, for example, database management system has no clue that if I move my mouse, this cursor should move like this. This has to be handled by something else. So it is very clear what user interaction is. It is also very obvious that user interaction is an important part of information system. First lesson that we learn. Why DBMS is extremely important in managing our data in a secure, efficient way? That alone is not sufficient to build an information system because user interface or user interaction is outside the database. Then you have application logic. It actually does the processing of data. Please note that this is not access to data. That is the job of database management system. But actually doing some computations. For example, computation of monthly payroll, calculating student CPI. You will send an SQL query to access the data. That is data access path, access update, read data, put data. That is data base management integral. But if you want to calculate the CPI, you have to write mathematical formula. Today you can do that in SQL itself. You might require some other programming language. Whether you use some other programming language or whether you use SQL itself, there is a portion of logic which we call the application logic. Where will this application logic be executed on some computer? If there is only one computer, the same computer handles user interaction. The same computer handles a program or runs a program which is doing this application logic. Additionally, there is accessing and updating database which we have just seen. Through DDL, DML, whatever, whatever, some data is accessed. All these three when put together constitute an application. I think that is common sense. Any information system processing application will require to access and update data. Will require to execute some computational logic which is called the application logic. And will be required to interact with the end user. So therefore it will require user interaction. Consequently, when we say we have built an information system, we imply not only definition of database, not only writing SQL queries for querying the database or update or insert. We also mean we write in some programming language the application logic of computation of CPR, whatever. And we also write additionally a user interface provision which will be interacting with the user to collecting information, showing information. All of these together constitute the application software or the information system software. Three components, user interaction, application logic, computations and data interaction. Now we come to the notion of application architecture. Traditionally, in the conventional third generation programming language system, a single program would do all these tasks. Even if there are multiple programs, they would typically all execute on the same computer. In fact, the standard model is the one which you are most familiar with. You have a PC and you have a monitor keyboard. It's all connected together. Your database is also on the PC on the disk. You might have actually a database on the PC. Your user interaction has to be performed by some logic inside the same computer. And your application calculation or application logic also has to perform the same. This is called a single tier application where all the three component programming pieces execute on a single computer. That's the standard way. There's nothing new. This is the standard application architecture that you are all familiar. Even when you execute a 4-turn program, the same 4-turn program has logic to say display this value or collect input from the user. Then you will perform some computations. You will go to a database. Means you will open a file, read some data, write some data. So database access is also being done by the same program. Computation of inverse of a matrix is also done by another function or program inside the same machine. And finally, the results are displayed by some statements in the 4-turn program. So you have a single monolithic program as one way of application architecture. But when we have computer networks, it is possible to have large systems or servers connected to a number of smaller systems which are called clients. The clients provide user access and the database is kept on the server. So consequently you have a Unix machine which is connected to 20 clients. And these 20 clients are connected to the computer on a network. These are not terminals. A terminal is driven directly from the back-end machine. A client is an independent machine, a PC. Now if you have 10 PCs connected to a server, does it make sense to execute interaction with all 10 users, computational application logic execution for all 10 users who are doing these programs plus the database access all on the back-end server? If you are, then you are using actually the client machines as Dumbo terminals. You suddenly have the facility of saying, oh my God, I got 10 intelligent machines which are working as clients. They have their own computational power. They have all the 3GL, 4GL capability. And I have a common server where the data is maintained. It makes sense to put the database on the back-end server because everybody will require to access the common data. But it makes a lot of sense to put the user interaction directly to run on that PC. So a PC itself could be provided with a program which displays a screen, menu choices. You select the menu. Then you choose what program to execute. And then you take a form. That form is also displayed by a program which is executing on local PC. Fill up the data in that form. Now the data is filled up by the user interaction. You send this data to back-end. This architecture is called client-server architecture because each of these two client and server are capable of executing some component of application here or there. This is called 2TR architecture. 2TR architecture means databases are on server machines which are managed by the database back-end. And user interaction portion and the application logic runs on client machine. Application logic is a very funny fellow. You can run the application logic on a client machine. You can also run the application logic on a back-end. So application logic can be anyway. Traditionally however, in a 2TR architecture the common database is at the back-end and individual programs which are being executed by 10, 15, 20, 30, 100 users run on their client machines. This is the traditional client-server architecture where the user interaction and application logic happens on the front-end machine. This presupposes that the front-end machines are full-fledged computers having their own operating system, having all the software components required to execute both the user interaction and the application. But you will agree that 2TR architecture will permit reduced load on the server. If you did everything on the server and server could support, say, 10 users from a performance point of view, the moment you build a 2TR application, you can possibly support 50 users. Only the back-end database activity is done on that and all the front-end things are exploited. A 3TR architecture goes further and says, why can't I run application logic at some other place than the client? It is quite possible that out of 10, 25 users, most of them are actually executing the same application. Consider real-life reservations. All users are actually doing the same thing, you know, compare whether the seat available or not, etc., etc. You get the data from the database. Everybody is going to do something similar. So why not combine that application logic and run it on a separate server? Any time a user data comes, it goes to the application logic. There are re-entrant programs, so there are 10, 25, 30 programs which could all be executing application logic on the application server. Consequently, you further separate out the database access, the application logic and the front-end. When you do that, you call it a 3TR architecture and the layer that you so create is called the application server layer. And it could be a physically separate server. Now, when you build a new application, ideally you would like to do this, so that you can maximize the application logic execution capability of a server for as many users as you have. Reduce the load on front-end, reduce the load on back-end. And if necessary, you can put multiple application server instances. Application server is a software. You can put multiple instances on a single server which is separate from database. Consequently, you can do a whole lot of load balancing. This architecture is called a 3TR architecture. When I say that either on a separate machine or on the same machine as database server, what would it mean? After all, if I have separated the logic, why would I put it on the same database server? Firstly, I may not want to put in a different hardware. Then why separate out the layer? The purpose is as follows. When I construct a modern information system, I should ideally develop that modern information system in a modular way, which clearly has user interaction, application logic, application logic, and database. Once I have done it like that, if I have a single server, I can put database server and application logic both there. But tomorrow, if somebody gives me two different servers for optimizing the performance, I do not know how to rewrite the whole thing. It's not a composite model. I can just take out the application logic or application program and run them on this server. Consequently, even if I put both of these on the same machine, then logically there will be different models. The application logic will access the database as if it is accessing a database on some other server. It will actually have IP address. There is that and everything. If you take this logic anywhere else, it will still go to the same fellow to get there. The back end, therefore, is split. So this is called three-tier architecture. And you get a multi-tier architecture because now a server could intern access another server somewhere. So you could have another three-tier application there, three-tier application there, servers talking to each other, all kinds of crazy things. But very neatly, logically, moduled and partitioned. This, generally, you call a distributed multi-tier architecture. So what we have seen in this session is major components of a DBMS, typical architecture of a DBMS itself. Like a DDL interpreter, a DML query optimizer, or storage manager, transaction manager and the physical storage handling. We also saw the components of application software for information system, user interaction, application logic, back end database. And we saw different architectures in which the application software could be organized in a modern networked environment. This completes the way in which we are going to see applications deployed or applications designed. This is the software technology of building modern information systems. We will now look at the components of building an application in a different perspective. Before that, of course, we will continue to study the database management system.