Database technology can seem complex and complicated. In part this is because database terminology is inconsistent. Similar concepts have different names (for example, object and entity are synonyms in some contexts), and the same names often refer to different concepts (for example, the term object has different meanings depending on the context). This situation exists because database technology did not originate from a single source. In fact the technology has developed within three different contexts: the organizational context, the end-user context, and the distributed database context. To understand this subject you need to learn the evolution of database processing technology within each of these contexts.
The Organizational Context
The initial application of database technology was to resolve the problems with file processing systems we examined earlier. In the mid-1960s, major corporations were producing data at phenomenal rates in file processing systems. The data was becoming difficult to manage, and new systems were becoming increasingly difficult to develop. Further, management wanted to be able to relate the data in one file processing system to that in another. The limitations of file processing prevented easy integration of data, as we have seen. Database technology held out the promise of a solution to these problems, and large companies began to develop multi-application, multi-user databases. Within these databases companies centralized their operational data, such as orders, inventory, and accounting data. The applications were primarily transaction processors. But the technology was new, and early database applications were difficult to develop.
The End-User Context
In 1970, a mathematician named E. E Codd published a landmark paper in which he applied concepts from a branch of mathematics called relational algebra to the problem of storing large amounts of data. This paper started a movement within the database community that within a few years led to the definition of the relational database model. The Relational Model. The beauty of the relational model is that data is stored, at least conceptually, in a way the user can understand and access directly. Unlike the earlier database models, the relational model made it possible for users to get answers to some of their questions without requiring the assistance of MIS professionals. Thus, the relational database model introduced a new context: the end-user context.
Distributed Database Context
Organizational database systems were supposed to solve the problems of file processing and allow more integrated processing of operational data. End-user database systems brought database technology even closer to the user by allowing direct access to the corporate data. Distributed databases are an attempt to allow even more flexibility in terms of data access and processing; however, distributed databases pose many problems not yet solved. Distributed database systems evolved out of a need for users to have even more access to corporate data. In essence, various user groups download, or copy, portions of the corporate database onto their own computer storage equipment, then process it as if it were their own private database. Thus microcomputers, minicomputers, and mainframes all access the same pool of data. Among the more pressing problems with this arrangement are those of security and control. Ensuring that users actually are entitled to access the database is a difficult task because there could be hundreds of concurrent users. Coordinating and synchronizing the data is also very difficult. If one user group downloads and updates part of the database and then transmits the changed data back to the mainframe, how does the system prevent another user from attempting to use the version of the data it finds on the mainframe in the meantime? Imagine this problem involving dozens of files and hundreds of users employing scores of pieces of computer equipment.
Comparing the Three Contexts
There are differences among database systems that have developed within the three contexts. We have noted some of them during this discussion. Although it is important that you recognize the differences, it is equally important that you see the similarities. There is a body of knowledge common to all three contexts, and if you understand that common knowledge, you will go a long way toward understanding applications and products in all three categories.