Brief History Of Data Bases

In the 1960's, the use of main frame computers became widespread in many
companies. To access vast amounts of stored information, these companies start
ed to use computer programs like COBOL and FORTRAN. Data accessibility and data
sharing soon became an important feature because of the large amount of informa
tion recquired by different departments within certain companies. With this sys
tem, each application owns its own data files. The problems thus associated wit
h 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 woul
d prove to be very influential towards future designs of computer systems and th
e methods they will use in manipulating data.
In 1966, Philip Kotler had the first description of how managers could b
enefit from the powerful capabilities of the electronic computer as a management
tool.
In 1969, Berson developed a marketing information system for marketing r
esearch. In 1970, the Montgomery urban model was developed stressing the quant
itative aspect of management by highlighting a data bank, a model bank, and a me
asurement statistics bank. All of these factors will be influential on future m
odels 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 st
ored 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 dat
a, modifying data, and retrieving existing data. A database is shared and perce
ived differently by multiple users. This leads to the arrival of Database Manag
ement 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 are
as where that certain piece of information was relevant. Simple things like add
resses were stored in customer information files, accounts receivable records, a
nd so on. This created redundancy and inefficiency. Updating files, like stori
ng 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 happene
d 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 ha
ving 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 soar
ing. 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 syst
em of inefficiency. Instead of having separate files for each program, one sing
le collection of information was kept, a database. Now, many programs, known as
a database manager, could access one database with the confidence of knowing th
at 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 microcomp
uter environment since 1977. Condor provides multi-file, menu-driven relational
capabilities and a flexible command language. By using a word processor, due t
o 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. De
fining file structures is a relatively straightforward method by typing the fiel
d names and their length, the main part of designing the structure is about comp
lete. 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 en
ter and inputting the respective values to the appropriate fields and like the n
ewer databases, Condor too can use the Update, Delete, Insert, and Backspace com
mands. Accessing data is done by creating an index. The index can be used to p
erform sorts and arithmetic.
dBaseIII
DbaseIII is a relational DBMS which was partially built on dbaseII. Lik
e Condor 3, dbaseIII is menu-driven and has its menus built in several levels.
One of the problems discovered, was that higher level commands were not included
in all menu levels. That is, dBaseIII is limited to only basic commands and an
ything above that is not supported.
Many of the basic capabilities are easy to use, but like Condor, dBaseIII has in
consistencies and inefficiency. The keys used to move and select items in speci
fic menus are not always consistent through out. If you mark an item to be sele
cted from a list, once it=s marked it can not be unmarked. The only way to corr
ect this is to start over and enter everything again. This is time consuming an
d obviously inefficient. Although the menus are helpful and guide you through t
he stages or levels, there is the option to turn off the menus and work at a lit
tle faster rate.
DBaseIII=s command are procedural (function oriented) and flexible. It
utilizes many of the common functions like:
select records
C. select fields
C. include expressions ( such as calculations)
C. redirect output to the screen or to the printer
C. store results separately from the application
Included in dBaseIII is a limited editor which will let you create comma
nds using the editor or a word processor. Unfortunately, it is still limited to
certain commands, for example, it can not create move or copy commands. It als
o has a screen design package which enables you to design how you want your scre
en to look. The minimum RAM requirement of 256k for this package really illust
rates how old this application is. The most noticeable problem documented about
dBaseIII is inability to edit command lines. If, for example, an error was mad
e entering the name and address of a customer, simply backing up and correcting
the wrong character is impossible without deleting everything up to the correcti
on and re-entering everything again.
DBaseIII is portable and straightforward to work with. It allows users
to import and export files in two forms: fixed-length fields and delimited field
s. It can also perform dBaseII conversions. Creating file structures are simpl
e using the menus or the create command. It has field types that are still bein
g used today by applications such as Microsoft Access, for example, numeric fie
lds and memo fields which let you enter sentences or pieces of information, like
a customer=s address, which might vary in length from record to record. Unlike
Condor 3, dBaseIII is able to edit fields without having to start over. Insert
ing new fields or deleting old fields can be done quite easily.
Data manipulation and query is very accessible through a number of built
-in functions. The list and display commands enable you to see the entire file,
selected records, and selected files. The browse command allows you to scroll
through all the fields inserting or editing records at the same time. Calculati
on functions like sum, average, count, and total allow you to perform arithmetic
operations on data in a file. There are other functions available like date an
d time functions, rounding, and formatting.
Omnifile
Omnifile is a single-file database system. This database is form orient
ed meaning that it has a master form with alternate forms attached to it. There
fore, you can work with one file and all of its subsets at the same time. The i
dea of alternating forms provides for a greater level of security, for example,
if a user needed to update an address field, they would not be able to access an
y fields which displayed confidential information. The field in need of updatin
g would only display the necessary or relevant information.
Menus are once again present and used as a guide. The use of function k
eys allows the user to move about screens or forms quite easily. Menus are also
used for transferring information, either for importing or for exporting. One
inflexibility noted was that when copying files the two files must have the exac
t same fields in the same order as the master file. This can be problem if you
want to copy identical fields from different files.
Forms design is simple but tedious. Although it may seem flexible to be
able to paint the screen in any manner that you wish, it can be time consuming
because no default screen is available. Like other database management systems,
the usual syntax for defining fields apply, field name followed by the length o
f the field in braces. However, editing is a little more difficult. Changing t
he form can be done by inserting and deleting, one character at a time. Omnifil
e does not support moving fields around, nor inserting blank lines. This means
that if a field was to be added at the beginning of the record, the entire recor
d would have to be re-entered.
Records are added and viewed in the format that the user first designed
it. Invalid entries are not handled very well. Entering an illegal value in a
certain field results in a beep and no message, the user is left there to try an
d decide what the error is. Omnifile does support the ability to insert new rec
ords while viewing existing records and to make global or local changes.
Querying can be performed by using an index or using a non-indexed searc
h. If a search for a partial entry is made like ARob@ instead of ARobinson@, a
message is then displayed stating that not an exact match was found.
Overall
These are just a few of the database programs that help start the whole database
management system era. It is apparent that DBMS=s today still use some of the
fundamentals first implemented by these >old= systems. Items like menus, forms,
and portability are still key parts to current applications. However, programs
have come along since then, but still have as their bases the same fundamental
principles.