How To Describe The Co-existence Of Different User Interfaces In The DBMS Environment?

A community of users generally includes anyone from a first time novice to an experienced user who is developing sophisticated application systems for other end users.

A comprehensive dbms should provide interfaces appropriate to this broad spectrum of users. Yet there should be uniformity in underlying dbms functions and the semantics of the interfaces. For the same dbms, it is possible to have several different user interfaces:

- System driven interface with menus and prompts for the novice users and liberal use of help facilities.
-User driven interface with an ad hoc command language.
-An extended command language for building command files for deferred execution.
-Natural language interface for the casual user.


The question becomes Where to focus design and development effort? What can be built on top of what? From the standpoint of systems architecture, a system driven dialogue can be built on top of a command driven interface. Menu and prompting dialogues essentially capture all the necessary information that would otherwise be expressed in one or more commands. Similarly, a natural language interface for the casual user can be built on top of the command level. The natural language interface is still a user driven interface but for the intermittent user. They are not assumed to be able to correctly formulate a command to the system.

Therefore, dialoguing facilities are provided which allow the user to express a command in their natural language with all its ambiguities and contextual dependencies. The system then attempts to interpret the command, asking the user to resolve ambiguities and provide missing information. The output from the natural language processor is a correctly formulated command which can be executed by the formal command processor of the dbms.

There is some question whether novice of intermittent users should have a natural language interface where they attempt to initiate dialogue with the system, or a system driven interface where they are led through the use of the system by a series of menus and prompts. The latter may prove to be easier and more efficient for such users. Since all other user interfaces essentially construct a command for the user, it is important to design and implement a complete and comprehensive language first.


For a comprehensive dbms, all user modes should be supported. Furthermore a user should be able to change interfaces as appropriate depending on their general level of knowledge of the system and their experience with the particular function being performed. Any request should be expressible either as a command or using system driven prompts and menus. For human efficiency, the command language should have a narrative symantic style. However, for machine efficiency, the command language should be fixed position with encoded command verbs. Therefore, it is desirable to have an intermediate command language into which all other interfaces are translated before being stored or executed.

The intermediate command language would store commands in a condensed fixed format. Of course, the language would still be a high-level structured, data language. The user interfaces manage all dialogue with the user. This includes scanning and parsing the input, syntax checking and messages for syntax errors. The command manager receives syntactically correct commands, loads the appropriate program code to execute the command if necessary and initiates execution of the command that is the dbms function.

The above paragraph is intended only to give a brief glimpse into a possible architecture for accomplishing the objective of separating the user interface modes from the dbms functions, and of a user’s being able to freely move among the different interfaces.

The following discussion of menu handling gives specific ideas on the integration of commands and menus. In choosing between menu driven or command driven, this usually demonstrates a dbms functional capability using an illustrative command language statement. Furthermore, the emphasis is on the semantics of the language statement rather than the particular syntax. This is done recognizing that menus and prompts can be built on top of the command language to capture all the information and parameters required to perform the function.

| Advantages of server database management solutions | Books on concepts of database management | Choosing one of the right database management solutions for you business | Customer Database Management – How it improves your relationship with your customer | How a content management database improves communication and productivity | How a document management database improves your organization’s productivity | How a properly maintained asset management database improves your business | How to make use of the event management database | Introduction to database management | Inventory Management Database – How it improves your productivity | Need for Third-party tools for advanced database management | Some of the advantages of database management systems | Some of the Disadvantages of database management systems | Types of database management systems | Using the risk management database effectively | What is the need for third-party database management tools | What to expect from a database management tutorial |


FREE Subscription

Stay Current With the Latest Trends & Developments Realted to Management. Signup for Our Newsletter and Receive New Articles Through Email

Note: We never rent, trade, or sell our email lists to anyone. We assure that your privacy is respected and protected.