Philip A. Bernstein

Synthesizing third normal form relations from functional dependencies

It has been proposed that the description of a relational database can be formulated as a set of functional relationships among database attributes. These functional relationships can then be used to synthesize algorithmically a relational scheme. It is the purpose of this paper to present an effective procedure for performing such a synthesis. The schema that results from this procedure is proved to be in Codds third normal form and to contain the fewest possible number of relations. Problems with earlier attempts to construct such a procedure are also discussed.

INTRODUCTION TO PRINCIPLES

This course will also be offered remotely for students who register at an approved remote site. Registered remote sites can choose to view the lectures live via web broadcasting or archived online on the course website https://ippcr.nihtraining.com/ . A certificate will be awarded upon successful completion of the course, which is based on receiving a passing grade on an open-book final examination. This course will be of interest to physicians and all other health professionals planning a career in clinical research.

A multi-level architecture for relational data base systems

Most of the literature on implementation of relations has been directed toward user features, with little attention paid to an overall conceptual view of underlying structures. Performance oriented considerations have been treated only for isolated problems. Toward a solution to these problems we describe a multi-level architecture for relational data base systems. This architecture distinguishes clearly between user oriented features, access path structures, data structures and file organization. It also allows efficiency problems to be isolated within levels and solved independently of each other, without impacting the logical structure of the users virtual machine. Specific problems considered here in the context of this architecture include the mapping of relations into files, the implementation of fast access paths, and some file level optimizations that are particularly useful in relational systems.

CHAPTER 4 – MEMORY MANAGEMENT

Publisher Summary This chapter discusses the memory management functions and the general linkage problem. Memory management may be thought of as three functions, which include naming function, memory function, and content function. A given name may refer to different objects, depending on the context in which it is used. The problem of matching names with their corresponding objects is pervasive in software systems. In block structured programming languages, a given name can refer to several different variables, depending on the block in which it is used. In operating systems the context with which one is generally concerned is that of the user program. Several users may have the same names for different files or procedures. It is the job of the operating system to associate the correct object with every name within each user context. Each separately compiled procedure or data structure, called an object module, is coded relative to address zero. Modules cooperate, so that one module can call a procedure or can access data in another module.

Allocating storage in hierarchical data bases using traces

Abstract This paper describes a class of methods to allocate a hierarchical (i.e. tree structured) data base using traces. A trace is an n-tuple of indices, [x(1),…, x(n)], which describes the unique path from the root of the tree to the node being addressed. That is, one takes the x(1)-th branch from the root, followed by the (2)-th branch from the next node, etc. until the path is completed. The last node on the path is the one being addressed. Given a set of traces that represent a set of nodes in a tree, the problem is to allocate them efficiently on a file.We approach the problem by finding ways of mapping n-tuples (i.e. traces) onto natural numbers (i.e. file indices). An allocation scheme is proposed which uses a 1:1, onto trace-to-address map and is designed to adapt to a changing distribution of nodes within the tree. The scheme is an attempt to solve the problem of efficiently allocating growing data bases.

CHAPTER 2 – PROCESSES

Publisher Summary This chapter discusses the concurrency in hardware systems. Peripheral devices and their channels work concurrently with the central processing unit. The central processor can also exploit hardware parallelism. A number of machines have increased their computing power by increasing the number of processors. In a hardware system with several arithmetic processors and a number of channels all working simultaneously, organizing the computations associated with these devices is a complex task. To organize them efficiently is even more difficult. One user does not usually exercise the facilities of the system uniformly. User jobs, when executing concurrently, generally should not be aware of each others existence. It is found that when a job issues a print command, it is not concerned that another job is currently reading in cards. Hardware devices act in a similar fashion. The printer is usually unaware of the readers presence. To model this adequately, a unit of computation is needed, which reflects this concurrency, namely, the process. Computations do occasionally have to exchange information. To the extent that computations must communicate with each other, they are not completely independent. Processes, which are being used to model computations, must reflect this ability to communicate.

CHAPTER 5 – VIRTUAL MEMORY

Publisher Summary This chapter describes the hardware devices for virtual memory and multilevel memory. There are many well-known hardware devices for information storage and retrieval, including registers, core, drum, fixed-head disk, movable head disk, magnetic tape, punched paper tape, and cards. There are hardware mechanisms especially adapted for virtual memory. In particular, multilevel memory and the paging drum have significantly improved the economic feasibility of virtual memory over conventional hardware design. The most common type of storage organization consists of two levels. Level 1 is a large electronic store such as core which is directly addressable from the central processing unit. Level 2 consists of one or more high-capacity peripheral electromechanical devices such as drum, disk, and tape. It is suggested that if information needed is not located in core, that information must be brought into core from a peripheral device before it can be accessed. This scheme was used in nearly all early paging and segmentation designs and is still found in a majority of small- and medium-sized machines.

CHAPTER 6 – I/O AND FILES

This chapter discusses the basic file system and logical file system. The operation of the physical devices is coordinated by this first level of software. The processes comprising this system operate close to the hardware. They manipulate volumes and read in or write out blocks of information between specified addresses of main and secondary storage. This system is responsible for converting the unique identifier of a file into an object called a file descriptor. The file descriptor provides the physical address of the file and its length. If the file consists of multiple blocks, the file descriptor points to the different blocks that make up the file. The basic file system also provides commands for breaking up files into smaller subfiles. The function of the logical file system is to determine the unique identifier associated with the symbolic name given by the user. The symbolic name is interpreted in the context of the users directory to obtain the unique identifier associated with the file, which corresponds to a particular descriptor at a lower level.

OPERATING SYSTEM FUNCTIONS AND CONCEPTS

This chapter discusses operating system functions and concepts. The operating system is that part of the software that supports the sharing of resources. Not every operating system restricts its operation to include only facilities that aid in sharing. Most systems include a file system that is significantly more complex than what is minimally required to share I/O devices. File systems are mostly a convenience factor rather than a requirement for sharing of I/O devices, and their presence in an operating system enables the user to have a simple access to I/O devices. The nucleus of the system, the software that is directly responsible for the sharing of hardware, has functions that are reasonably invariant across a wide variety of machines. The nucleus provides a means by which processors, main memory, and peripheral devices can be shared. The parts of the operating system that interact with users, such as a batch system or a text-editing system, use the nucleus functions as software base in much the same way that the nucleus uses physical devices as a hardware base.

EXAMPLES OF SYSTEMS

Publisher Summary This chapter describes resources, capabilities, and protection and the ultimate ancestor. Resource claims within the SUE system are managed by means of capabilities. A capability is a 64-bit record, which specifies the availability of some resource to a process. Corresponding to each process, there is a list of capabilities, which determines the process allotment of resources provided by ancestors. Every capability has an associated manager, generally either the facility that originally created the capability or the Kernel. A capability can be modified either explicitly, by the capability manager, or implicitly, by a facility in the Complete Facility Call primitive. Capabilities are useful for both the protection and the management of resources. As nearly all resources in the system are represented as capabilities, there exists a uniform method of creating, manipulating, and destroying them using the capability operations. In transmitting resource information from one process to another, only the slot number of the capability on the capability list is actually passed. The capability lists are protected from the processes so that no process can forge a capability.