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 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 were not included in all menu levels. That
is, dBaseIII is limited to only basic commands and anything above that is not
supported.
Many of the basic capabilities are easy to use, but like Condor, dBaseIII has
inconsistencies and inefficiency. The keys used to move and select items in specific
menus are not always consistent through out. If you mark an item to be selected from a
list, once it=s marked it can not be unmarked. The only way to correct this is to start
over and enter everything again. This is time consuming and obviously inefficient.
Although the menus are helpful and guide you through the stages or levels, there is the
option to turn off the menus and work at a little 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 commands 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 also has a screen design package
which enables you to design how you want your screen to look. The minimum RAM
requirement of 256k for this package really illustrates how old this application is.
The most noticeable problem documented about dBaseIII is inability to edit command lines.
If, for example, an error was made entering the name and address of a customer, simply
backing up and correcting the wrong character is impossible without deleting everything
up to the correction 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 fields. It can also perform
dBaseII conversions. Creating file structures are simple using the menus or the create
command. It has field types that are still being used today by applications such as
Microsoft Access, for example, numeric fields 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. Inserting 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. Calculation 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 and time functions, rounding, and formatting.
Omnifile
Omnifile is a single-file database system. This database is form oriented meaning that
it has a master form with alternate forms attached to it. Therefore, you can work with
one file and all of its subsets at the same time. The idea 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 any fields which displayed confidential
information. The field in need of updating would only display the necessary or relevant
information.
Menus are once again present and used as a guide. The use of function keys 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 exact 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 of the field in braces.
However, editing is a little more difficult. Changing the form can be done by inserting
and deleting, one character at a time. Omnifile 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 record 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 and decide what the error is.
Omnifile does support the ability to insert new records while viewing existing records
and to make global or local changes.
Querying can be performed by using an index or using a non-indexed search. 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.
|