The command language
of the dbms should be a high-level data language. Such a language provides
single commands which operate on the whole file at once, even multiple
files. Elements of the language include operations to:
- Select records from a file which satisfy a Boolean expression.
- Project named fields from those records.
- Derive additional values for each of these retrieved records.
- Sort the selected records for output.
- Calculate the statistics on certain fields for the whole file or at
- Present the output with appropriate titles and headings.
In a low-level language,
a single statement tends to be semantically simple but more statements
are needed to express a processing task. With many statements having
interdependencies and sequence constraints, a low level language is
more complex making it more difficult to learn and to use.
The user must know more details of the processing environment and the
data being processed. Using this detailed information, the user can
exercise control over time and space efficiency tradeoffs. Once a processing
task is written in a low level language, the proper execution of the
process specification probably depends upon the detailed picture used
in specifying the process.
By contrast, a single
statement in a high level language implies more underlying processing
steps. If the entire user request for processing against the database
can be expressed in one comprehensive language statement, there can
be no interstatement or procedural dependencies to contend with.
The user view of the data structure would consist of the minimum necessary
information, at the level of logical names and relationships excluding
physical storage and access path considerations. Using such a language
provides little control over efficiency tradeoffs. However, assuming
less detailed information about the data structure and using a high
level language, the processing specification is easier to write, easier
to understand when it is written and easier to modify.
High level data
- Allow the user to more closely and directly relate to the problem.
- Can insulate users from physical data
storage considerations and machine level constraints.
- Can reduce application development time by making it easier to define
a data structure and to specify processing against that structure.
- Are more readily understood by a user and, therefore, require less
training than low level languages.
These are all the
same reasons for the initial development and present widespread use
of high level programming languages such as COBOL AND FORTRAN to specifiy
processes. Unfortunately, the development of high level data languages
for definition and manipulation has lagged far behind the development
of high level programming languages. Data manipulation languages are
used to specify some processes or operation on a data structure such
as interrogation or update.
A low level data manipulation language provides commands which operate
on one record at a time. With the language, a user navigates through
the data structure. With a high level data manipulation language the
user thinks of processing one file or multiple files at once, often
with a single statement.
A high level language specifies criteria for selecting a subset of entries
from a file, names the attributes to be projected and defines functions
to be performed on the data. A high level data language statement attempts
to specify a complete unit or pattern of processing aginst the data
structure directly and succinctly. Ofcourse, some users may require
a low level data language. This may be necessary when they want greater
control over data flow, or greater efficiency or generality in processing
against a data structure.
The large proportion of human interaction with a database can and should
use high level data languages. A user does not always need to know they
way data is physically stored within the computer in order to use it.
A high level data language allows the user to interact at the level
of the logical data structure, unencumbered by physical details and