1.1 Writing Applications with UNIBASE

UNIBASE makes application writing very easy, however it can’t replace good design. For those interested there are many good books and training courses on design, however if you organization has a formal development procedure it should be used.

The final product of any design process is normally some sort of Dataflow, a list of tables and their relationships, a list of forms and reports that are needed, and a set of processes that must be provided.

Normally a UNIBASE application is written by creating table definitions and then the physical files, followed by a Data Entry screen or form to get some data into the tables, some simple reports to prove the data, and finally the processing that converts, updates, etc the data.

This manual is laid out to give the details and examples for each of these functions.

Modern database systems are described variously as relational, semantic, and object orientated. UNIBASE has elements of all these database models. Of particular interest to Entity-Relationship model users is UNIBASE’s ability to model directly and E-R diagram.

1.2 Unibase application structure

There are no firm rules for how a Unibase application should be structured. However over the years good practice and experiment suggest the following layout.

These rules also allow use of many of the automated application integrity checking utilities.

The root directory of an application should be /usr/local/app/<application>. Eg /usr/local/app/uniquote.

There can be may options under this directory. The most common are:

• bin – commands, scripts, compiled programs
• dct – data dictionary components
• prm – forms (prompts)
• rep (reports)