What are the Origins of DBMS??

As we noted in the additional coverage page on Why Databases?, "Although we tend to think of databases as a mainstay of computer programs, they were not always common". At that point, we discussed some of the reasons why they were not commonplace. Here we will talk about some of the reasons why they came into being.

At the beginning of John F. Kennedy's Presidency, he promised the American People that the United States would put a man on the moon by the end of the decade (Government Scientists were NOT amused). The race for space was underway!

The problem was that this required cooperation between a vast number of government contractors. In the early 1960's one of them, North American Rockwell, looked at the data they needed to maintain. They found that over 60% of all the data they maintained (and as you might imagine, there was an enormous amount of data necessary) was duplicated elsewhere, in most cases in many, many different locations (don't forget, this was still the era of COBOL and traditional files).

??? So, what could they do ???

That is what they asked themselves. They tried to combine data and program code using something they called Generalized Update Access Methods (GUAM). The idea was that smaller parts could be merged into a larger whole and used by each of the subunits.

!!! Sounds like a database to me !!!

Not quite, but it was the beginning. In the mid 1960's they began discussing the problem with the largest supplier of software and hardware. IBM (if you think that Microsoft is a giant, you should check-out the history of IBM!!). At any rate, Rockwell and IBM got together as a joint venture to develop something they termed a Database Management System (yes, a DBMS), although it is not quite the same thing as what (or how) we view a DBMS today. It was hierarchical in nature (we will talk more about that in later sections) and assumed that it would only be used by skilled programmers.

By the late 1960's IBM developed a commercial package called the Information Management System (IMS), which became the first commercially DBMS. It was based on the same concepts that Rockwell and IBM discussed a few years earlier. The program became very successful (it is still available today, although it has lost a considerable amount of appeal), and in the 1970's, and into the 1980's, was the most popular DBMS available. Let's not forget, however, we are talking about a time when mainframes were king.

Another point to keep in mind is that at this time (the late 1960's and into the mid 1970's) COBOL was still the predominant programming language. In 1971, a conference called the Conference On DAta SYstems Languages (CODASYL) was held. The main intent was to standardize COBOL usage, not necessarily to discuss DBMS usage. However, one of the subcommittees, The DataBase Task Group (DBTG) was charged with the responsibility of defining a set of standards which would ease database creation, manipulation and maintenance (as you might imagine, using COBOL as the interface). It is interesting that, even then, people were becoming aware that databases were going to be the future wave.

The DBTG focused on three major issues:

1. The Network Schema. This is the over-all view of the database (the physical view). Primarily, it the view that the database administrator or designer is concerned with. It is how the database is physically laid-out.
    

2. The Network Subschema. This is the conceptual organization of the database as seen by the application programs which access it. In other words, it is not necessary for each and every program (remember, we are talking essentially about COBOL programs) to understand the entire physical layout of the database (that is the objective of the Network schema), only those components which are germane to the data which it needs to access.
    

3. A data management program to define and manipulate the data. In other words, commands, functions and subroutines which could be used to create, modify and manipulate the data. At this point it was intended for use by the programmer (the typical user was still considered incapable of actually using a DBMS). This component, however, eventually became the heart of a DBMS.

The DBTG's recommendations were accepted by the American National Standards Institute's (ANSI) as the norm for dealing with databases.

Around this time (the early 1970's) other DBMS packages were becoming available (Although IBM and IMS still dominated the market). One variation, the Network Model (to be discussed later), was the topic of the 1975 ANSI Standards Planning And Requirements Committee (SPARC) which, like the DBTG, in 1975 laid-out the same guidelines for this type of database (The Network Model).

Also around this time (actually before DBTG and SPARC), in 1970, Edgar Codd  wrote a paper called "A Relational Model of Data for Large Shared Data Banks". The paper became a seminal work and spurred development of the Relational DataBase Management System (RDBMS). Codd's DBMS was based on relational algebra and viewed databases as two-dimensional tables (as does a spreadsheet). He further felt that is was the responsibility of the DBMS package to perform all of the physical operations necessary to maintain and update a database (instead of the individual programmer). In other words, it was a way in which the DBMS could be automated; the mundane tasks necessary to keep the database operational were the function of the DBMS. That meant that even a non-programmer (i.e., the end user) could directly manipulate a database (without the involvement of a programmer).

The RDBMS did require a great deal of resources (secondary storage, memory, and CPU time), however. Nonetheless, by the mid 1980's, and certainly into the 1990's, the RDBMS became the most used type of DBMS.

??? What are the components of a DBMS ???

That is our next topic.