A data model, called the entity-relationship model, is proposed. This model incorporates some of the important semantic information in the real world. A special diagramatic technique is introduced as a tool for data base design. An example of data base design and description using the model and the diagramatic technique is given. Some implications on data integrity, information retrieval, and data manipulation are discussed.The entity-relationship model can be used as a basis for unification of different views of data: the network model, the relational model, and the entity set model. Semantic ambiguities in these models are analyzed. Possible ways to derive their views of data from the entity-relationship model are presented.

/pdf/the-entity-relationship-model-toward-a-unified-view-of-data-i5q0wnv07u.pdf

The entity-relationship model: toward a unified view of data

A data model, called the entity-relationship model, is proposed. This model incorporates some of the important semantic information about the real world. A special diagrammatic technique is introduced as a tool for database design. An example of database design and description using the model and the diagrammatic technique is given. Some implications for data integrity, information retrieval, and data manipulation are discussed.The entity-relationship model can be used as a basis for unification of different views of data: the network model, the relational model, and the entity set model. Semantic ambiguities in these models are analyzed. Possible ways to derive their views of data from the entity-relationship model are presented.

This paper is a compendium of data base management operating systems folklore. It is an early paper and is still in draft form. It is intended as a set of course notes for a class on data base operating systems. After a brief overview of what a data management system is it focuses on particular issues unique to the transaction management component especially locking and recovery.

Notes on Data Base Operating Systems

Visual notations form an integral part of the language of software engineering (SE). Yet historically, SE researchers and notation designers have ignored or undervalued issues of visual representation. In evaluating and comparing notations, details of visual syntax are rarely discussed. In designing notations, the majority of effort is spent on semantics, with graphical conventions largely an afterthought. Typically, no design rationale, scientific or otherwise, is provided for visual representation choices. While SE has developed mature methods for evaluating and designing semantics, it lacks equivalent methods for visual syntax. This paper defines a set of principles for designing cognitively effective visual notations: ones that are optimized for human communication and problem solving. Together these form a design theory, called the Physics of Notations as it focuses on the physical (perceptual) properties of notations rather than their logical (semantic) properties. The principles were synthesized from theory and empirical evidence from a wide range of fields and rest on an explicit theory of how visual notations communicate. They can be used to evaluate, compare, and improve existing visual notations as well as to construct new ones. The paper identifies serious design flaws in some of the leading SE notations, together with practical suggestions for improving them. It also showcases some examples of visual notation design excellence from SE and other fields.

The “Physics” of Notations: Toward a Scientific Basis for Constructing Visual Notations in Software Engineering

Computer software for, computer apparatus for, and a method of automatically generating a user interface for a relational database comprising extracting schema information from the relational database and automatically generating corresponding schema and user interface metadata, storing the metadata in a repository, and automatically developing from the metadata a user interface appropriate to the relational database.

Automated Generation of Dynamic Data Entry User Interface for Relational Database Management Systems

Successful communication of ideas has been and will continue to be a limiting factor in man's endeavors to survive and to better his life. The invention of algebra, essentially a graphic technique for communicating truths with respect to classes of arithmetic statements, broke the bond that slowed the development of mathematics. Whereas "12+ 13=25 '' and "3+7= 10" and "14+(-2) = 12" are arithmetic statements, "a+b=c '' is an algebraic statement. In particular, it is an algebraic statement controlling an entire class of arithmetic statements such as those listed.

Data structure diagrams

A new data model is described which permits the representation of the different roles which a real world entity may play. This data model is an extension of the network model, as used in I-D-S and its derivative, the CODASYL database system. The concepts of item and set are retained. The record concept has been refined to clarify the old record concept and introduce the new role-segment concept. The record represents the existence of an entity of the real world while the role-segment represents the existence of one of the entity's roles.

A person and a corporation are examples of an entity, while a stockholder and a customer are examples of a role that either the person or corporation can assume. A role-segment occurrence serves to group and name the properties concerning the existence of one role.

This paper shows that the record and role segment concepts can be integrated into the required data description and data manipulation language.

The meta entity types of the role data model are contrasted with those of older data models for the data occurrence domain. The ambigous use of meta types by the older models is thus shown. This ambiguity appears to prohibit those older data models from serving as the basis of a conceptual schema where data transformation support of richer data models is required.

The meta entity types of the role data model are identified, described and related to the real world, data occurrence, conceptual schema, and data description domains.

The role concept in data models

This report has been prepared by the Data Base Task Group which is an ad hoc committee of the CODASYL Programming Language Committee. The report details the recommendation of the Data Base Task Group to its parent committee. It consists of a proposal for a Data Description Language and a Data Manipulation Language.

The Data Description Language is a language for describing a database. The Data Manipulation Language is language which, when associated with the facilities of a host language such as COBOL, PL/1, ALGOL, JOVIAL, FORTRAN..., allows manipulation of databases described by the Data Description Language.

The specification of separate Data Description and Data Manipulation Languages is significant in that it allows databases described by the Data Description Language to be independent of the host languages used for processing the data. Of course, for this to be possible, the host language processors must be able to interface with such independent descriptions of data.

Data base task group report to the CODASYL programming language committee, October 1969

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.

https://dl.acm.org/doi/pdf/10.1145/355611.362534

The programmer as navigator

An arrangement for sharing file information among plural processes in a multiprogrammed computing system. Source program file declarations are compiled into file control structures which are placed in skeletal segments, the segments forming units of potential sharing between active processes. Those segments which contain file control structures are placed in either the address space of (1) all processes, (2) related processes, or (3) a single process, depending upon the declared sharing level of the file. Job control language (JCL) commmands are expanded into JCL file control structures and merged with the source language structures to form a file request control structure. This request may be compared against a catalog of existing external files, a check being made to insure that the account on whose behalf a computing job is requesting file assignment is authorized to obtain the requested access to the file. Further tests are then made to guarantee compatibility between the request and the current status of the file.

Charles W. Bachman

Papers

Data structure diagrams

The role concept in data models

Data base task group report to the CODASYL programming language committee, October 1969

The programmer as navigator

System for protecting shared files in a multiprogrammed computer