Charles W. Bachman

The programmer as navigator

This year the whole world celebrates the five-hundredth birthday of Nicolaus Copernicus, the famous Polish astronomer and mathematician. In 1543, Copernicus published his book, Concerning the Revolutions of Celestial Spheres, which described a new theory about the relative physical movements of the earth, the planets, and the sun. It was in direct contradiction with the earth-centered theories which had been established by Ptolemy 1400 years earlier.

A personal chronicle: creating better information systems, with some guiding principles

The author identifies four guiding principles which have come into play in this work of creating information systems and tools to support information systems. The first principle, open-eyes, is used to characterize information systems that remain open to new information, and consequently can compensate for changes in their mission or inaccuracies in their execution of that mission. The second principle involves abstraction levels, which in information systems are similar to differentiation in calculus. They are used to study the changes within a group of heterogeneous objects, with respect to an object type classification, so as to understand and make use of their patterns and ultimately to control the new objects of each type. The third principle, layered architecture, is used to identify a pattern of successive reimplementations of a set of functions, so as to isolate specific environmentally oriented issues. The fourth principle involves relationships, used to define associations between objects and constraints on those associations and to provide access to objects based on their associations. Reference is made to several specific projects which revealed the operation of these principles. >

The evolution of storage structures

Data base management systems have grown rapidly in their power and complexity over the 15-year history of data processing on commercially available computers. The original concepts have split, and new terms have been adopted to name and refer to these concepts. The Data Structure Diagram graphic technique is used to illustrate the splitting of the concepts and the structural relations which exist between these concepts at each point in the evolution.

The data structure set model

I think we have a discussion today; not a debate. Its real purpose is to increase our understanding of the basic concepts underlying data base structures and their models; to note the similarities and differences between them, and to determine their compatibility or the lack thereof. We are talking about concepts, not about implementations. The reason for all data base structuring is retrieval: retrieval for output, retrieval for decision-making, retrieval for updating. To pinpoint the object of retrieval we must intelligently select the “right” data—the correct single record, the correct group of records, and, in some sense, the correct sequence of records (in those situations where the sequence in which these records are seen is important). For accurate selection, dependent on the particular interests, needs, and requirements of a given person, we want a mechanism for readily defining records to be selected. We want a mechanism that will permit the data base to evolve as the enterprise and information systems change. We want a mechanism which will protect already existing investment in programs and report specifications, while the data base evolves. We want a mechanism which permits the reoptimization of the structure of stored data as things change.

Trends in database management: 1975

The subject of database management systems is receiving attention at an accelerating rate. The work of the COBOL Data Base Task Group (DBTG) has achieved major acceptance. This acceptance can be measured in terms of the number of computer systems for which DBTG software is now available, and the number of customers who have successfully installed application systems based upon this software. While the specifications are yet imperfect and development committees will be refining them for years, it appears to this author that a major step in the evolution of computerized information systems has been accomplished. Integrated database systems are here to stay.

Architecture Definition Technique: Its objectives theory, process, facilities, and practice

The Architectural Definition Technique (ADT) is an approach to arriving at a complete, concise, non-ambiguous functional specification of a software or hardware system which is totally independent of packaging considerations. The Architecture Definition Process (ADP) contains six manageable steps leading to the creation and communication of the desired functional specification. Fundamental to the process and its theory, is (1) the reduction of the user visible entities into the systems state variables as represented by machine processable entity classes, attribute classes and set classes and (2) the establishment of the user interface as machine processable function definition algorithms. The Architecture Definition Facility (ADF) which supports the Architecture Definition Process is described. A case study defining the functionality of a File System is used for tutorial purposes

The Context of Open Systems Interconnection Within Computer-Based Information Systems

The current development within ISO on the “Reference Model of Open Systems Interconnection” and the supportive Service and Protocol Specifications represent a major contribution, which this paper attempts to place into the larger context of computer-based information systems and to show its relationship to complementary functional sub-architectures.

The CODASYL and GUIDE/SHARE proposals on data base management systems

Six panelists will discuss the subject of Data Base Management (DBM) as it relates to CODASYLs Data Base Language Task Group report and Data Definition Language Committee Report and the GUIDE/SHARE published requirements for a DBM and other published GUIDE documents deemed pertinent. Four key issues that best deal with the philosophy, concepts and differences of the CODASYL and GUIDE/SHARE work to date will be addressed.

On a generalized language for file organization and manipulation

I would like to speak on what I call a unified or generalized language for file organization and manipulation. I call it unified because some ideas from which disk file languages were developed are perfectly applicable to magnetic tape files, and would be a great improvement on the way we address files on magnetic tape today.