Once to author of this article it was suggested to develop the software for Oracle database server. The customer had a database and there were a process of updating data in this database.
It was necessary to develop the software (database query tool), which would allow the users easily to obtain the information from this database. In addition it was necessary To take into account the following circumstances:

• The software should be intended for usual users, not possessing knowledge of the SQL language;
  
• The information in database is considered as strictly confidential. The unauthorized access to the data is inadmissible;
• The users should receive access only to that part of database, which is really necessary for them, and should not know the real structure of database objects;
• the clients should use slow modem connections for access to database.

In this article the author considers the basic moments, which were used while developing concrete project, which satisfies to the above listed conditions.

Software architecture choice

The traditional client-server:

The client software directly interacts with the ORACLE server. All algorithms of business - logic are realized on the client. This solution requires additional client's software installation of the used RDBMS (in given case - ORACLE SQL Net).

multi-tiered application with the application server:

This decision is much more flexible than previous. Here occurs intermediate application layer (application server), where all necessary algorithms of business - logic are realized and interaction with RDBMS is carried out. To the client only the roles of organization of the user's interface and functional interaction with the application server are delegated.
Thus in this case, software is partitioned into two logical units, which run in conjunction on separate computers - thin client (installed on the end user's host) and remote server (installed in a central networking location accessible to all clients).

Having analysed these two solutions we came to a conclusion, that optimum choice for realization is a multi-tiered application. Let's result the basic reasons for the benefit of this choice:

• It is possible to assume, that the client will be a very simple program, and expense on installation and tuning of the client's workplaces will be minimal, because the thin client does not interact directly with database and there is no necessity in installation of any additional software of this DBMS;
• If there will be a necessity of business - logic algorithms modifications , then in a case of multi-tiered architecture it will make easier, because all is realized in one place - on a application server;
• Multi-tiered application provides the best protection from non-authorized access to the data. Really, client is the most vulnerable part in classical client-server application. Every time to open access session, it must pass to a server a name and password. In this case, drain of the password can entail the non-authorized access to database. In multi-tiered application the client should not to transfer the password to DBMS (interaction with DBMS - the function of the application server);
• There is a good idea to design the application server so, that it should be independent from the concrete DBMS. It will transform a product into universal query tool not only for the ORACLE DBMS, but also for the other databases.

Database protection against the unauthorized access

On the client the counter of connections to the application server is supported. The similar counter also is supported on the application server in the user's account. Before each attempt of the client connection to the server, the server checks equality of the own and client counters. If the counters are equal, then the client will be connected to the server, otherwise access will be locked. After successful connection, counters on both hosts synchronously incremented.

Let's examine a situation, when with the same name and password the different hosts try to be connected to the application server. It is obvious, that in this case on one of hosts inevitably there will be a mismatching counters on client and server and the access will be locked.

So finally was decided for data protection against unauthorized access to use the authorized connection of the client to the server with its additional binding to client's host.

Information data model

As the task was put to create application for the usual operator, it was necessary to design a clear for perception data model for the end user.

We are sure, that than easier user imagines a real database structure and than less he knows about real database objects, the better. Really, what for to him to know where and how database is located, what tables it consists of, on what servers etc.? All that is necessary for him is to set search criteria on necessary subject area and to receive the answer in an acceptable kind.

Therefore was decided to organize client's interaction with application server through the beforehand prepared models - access schemes. For the user the scheme is the simplified formalized representation some certain subject domain. Let it will be the simple list of fields, on which the data search conditions on concrete subject domain can be set.

If on the client the scheme looks very simply, but on a application server absolutely on the contrary. All database objects (tables) representing a subject domain of the scheme are included in the special description, which is located on a server's host and is used by the application server at query processing. This description should contain all information of database objects - description of the tables and their fields; description of tables relationships, output data formats etc.

Results