Brief History Of Databases


In the 1960\'s, the use of main frame computers became widespread in many
companies. To access vast amounts of stored information, these companies
started to use computer programs like COBOL and FORTRAN. Data accessibility and
data sharing soon became an important feature because of the large amount of
information recquired by different departments within certain companies. With
this system, each application owns its own data files. The problems thus
associated with this type of file processing was uncontrolled redundancy,
inconsistent data, inflexibility, poor enforcement of standards, and low
programmer maintenance.
In 1964, MIS (Management Information Systems) was introduced. This
would prove to be very influential towards future designs of computer systems
and the methods they will use in manipulating data.
In 1966, Philip Kotler had the first description of how managers could
benefit from the powerful capabilities of the electronic computer as a
management tool.
In 1969, Berson developed a marketing information system for marketing
research. In 1970, the Montgomery urban model was developed stressing the
quantitative aspect of management by highlighting a data bank, a model bank, and
a measurement statistics bank. All of these factors will be influential on
future models of storing data in a pool. According to Martine, in 1981, a
database is a shared collection of interrelated data designed to meet the needs
of multiple types of end users. The data is stored in one location so that they
are independent of the programs that use them, keeping in mind data integrity
with respect to the approaches to adding new data, modifying data, and
retrieving existing data. A database is shared and perceived differently by
multiple users. This leads to the arrival of Database Management Systems.
These systems first appeared around the 1970=s as solutions to problems
associated with mainframe computers. Originally, pre-database programs accessed
their own data files. Consequently, similar data had to be stored in other
areas where that certain piece of information was relevant. Simple things like
addresses were stored in customer information files, accounts receivable records,
and so on. This created redundancy and inefficiency. Updating files, like
storing files, was also a problem. When a customer=s address changed, all the
fields where that customer=s address was stored had to be changed. If a field
happened to be missed, then an inconsistency was created. When requests to
develop new ways to manipulate and summarize data arose, it only added to the
problem of having files attached to specific applications. New system design
had to be done, including new programs and new data file storage methods. The
close connection between data files and programs sent the costs for storage and
maintenance soaring. This combined with an inflexible method of the kinds of
data that could be extracted, arose the need to design an effective and
efficient system.
Here is where Database Management Systems helped restore order to a
system of inefficiency. Instead of having separate files for each program, one
single collection of information was kept, a database. Now, many programs,
known as a database manager, could access one database with the confidence of
knowing that it is accessing up to date and exclusive information.



Some early DBMS=s consisted of:
Condor 3 dBaseIII Knowledgeman Omnifile Please Power-Base R-Base 4000 Condor 3,
dBaseIII, and Omnifile will be examined more closely.

Condor 3
Is a relational database management system that evolved in the
microcomputer environment since 1977. Condor provides multi-file, menu-driven
relational capabilities and a flexible command language. By using a word
processor, due to the absence of a text editor, frequently used commands can
automated.
Condor 3 is an application development tool for multiple-file databases.
Although it lacks some of the capabilities like procedure repetition, it makes
up for it with its ease to use and quick decent speed.
Condor 3 utilizes the advantages of menu-driven design. Its portability
enables it to import and export data files in five different ASCII formats.
Defining file structures is a relatively straightforward method by typing the
field names and their length, the main part of designing the structure is about
complete. Condor uses six data types:

alphabetic alphanumeric C. numeric C. decimal numeric C. Julian
date C. dollar
Once the fields have been designed, data entry is as easy as pressing
enter and inputting the respective values to the appropriate fields and like the
newer databases, Condor too can use the Update, Delete, Insert, and Backspace
commands. Accessing data is done by creating an index. The index can be used
to perform sorts and arithmetic.

dBaseIII
DbaseIII is a relational DBMS which was partially built on dbaseII.
Like Condor 3, dbaseIII is menu-driven and has its menus built in several levels.
One of the problems discovered, was that higher level commands